From simple-bounces@ietf.org Thu Sep 4 07:36:07 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A36A3A6BEB; Thu, 4 Sep 2008 07:36:07 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4195C3A6BEB for ; Thu, 4 Sep 2008 07:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBbAT-VUr-Tv for ; Thu, 4 Sep 2008 07:36:00 -0700 (PDT) Received: from estacado.net (unknown [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 655673A6BDD for ; Thu, 4 Sep 2008 07:36:00 -0700 (PDT) Received: from [172.16.3.232] (dn3-232.estacado.net [172.16.3.232]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m84EZwDL066156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 4 Sep 2008 09:36:04 -0500 (CDT) (envelope-from rjsparks@estacado.net) Message-Id: From: Robert Sparks To: simple mailing list Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 4 Sep 2008 09:36:04 -0500 X-Mailer: Apple Mail (2.926) Subject: [Simple] Reminder: SIPit registration X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============1663675079==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1663675079== Content-Type: multipart/alternative; boundary=Apple-Mail-85--433887749 --Apple-Mail-85--433887749 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Registration for SIPit 23 closes in 4 weeks. If you are planning to attend, please register today. SIPit 23 will be held in Lannion, France October 13-17, hosted by ETSI with technical support from France-Telecom Orange Labs. Registration is 490Euro per participant, and the deadline for registration is October 3. Attendees are strongly encouraged to make reservations and travel arrangements as soon as possible. More information and links to registration are available at http://www.sipit.net and http://www.etsi.org/plugtests/SIPit/SIPit.htm Thanks, RjS --Apple-Mail-85--433887749 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Registration for SIPit 23 closes in 4 weeks. If you are planning to attend, please register today.

SIPit 23 will be held in Lannion, France October 13-17, hosted by ETSI with technical support from France-Telecom Orange Labs.

Registration is 490Euro per participant, and the deadline for registration is October 3.

Attendees are strongly encouraged to make reservations and travel arrangements as soon as possible.

More information and links to registration are available at
http://www.sipit.net
and
http://www.etsi.org/plugtests/SIPit/SIPit.htm

Thanks,

RjS
--Apple-Mail-85--433887749-- --===============1663675079== 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://www.ietf.org/mailman/listinfo/simple --===============1663675079==-- From simple-bounces@ietf.org Fri Sep 5 13:38:35 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECCE43A6AF8; Fri, 5 Sep 2008 13:38:34 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D9123A6B07; Fri, 5 Sep 2008 13:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpI91FR126oK; Fri, 5 Sep 2008 13:38:32 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id A84313A6850; Fri, 5 Sep 2008 13:38:31 -0700 (PDT) Received: from [172.16.3.232] (dn3-232.estacado.net [172.16.3.232]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m85KcSvh075597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Sep 2008 15:38:29 -0500 (CDT) (envelope-from rjsparks@estacado.net) Message-Id: From: Robert Sparks To: simple mailing list , GEOPRIV Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 5 Sep 2008 15:38:28 -0500 References: <81E0CDE3-1E75-484C-AC04-B058A1315C70@nostrum.com> X-Mailer: Apple Mail (2.926) Subject: [Simple] Fwd: IETF Mailing List Issue X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============0655952052==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============0655952052== Content-Type: multipart/alternative; boundary=Apple-Mail-21--325743244 --Apple-Mail-21--325743244 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Alexa tells me that the below message was affected, so I'm resending it. :) RjS Begin forwarded message: > From: Robert Sparks > Date: September 5, 2008 12:20:34 PM CDT > To: simple mailing list , GEOPRIV > Subject: Fwd: IETF Mailing List Issue > > I know most of you have seen this already, but just in case someone > here isn't on the announce or discussion lists... > > RjS > (If this is the first time you've seen this, please consider > subscribing to -announce). > > Begin forwarded message: > >> From: Alexa Morris >> Date: September 5, 2008 11:02:52 AM CDT >> To: "ietf-announce@ietf.org" >> Cc: Working Group Chairs , IETF Discussion > >, The IESG >> Subject: IETF Mailing List Issue >> >> Last night, after a server reboot, the postconfirm spam checker >> that was >> recently put in front of IETF mailing lists failed to start. >> Unfortunately, >> this resulted in a huge influx of spam to the IETF ticket system, >> and a >> simultaneous failure of IETF list email. Everything is back online >> now and >> functioning; however, email messages sent to IETF lists in the last >> 16 hours >> were lost, and will need to be resent. >> >> We have now installed a direct watcher on postconfirm, to force a >> restart of >> it when it fails. In addition, Henrik is working on the system now >> to find >> out why it failed to start in the first place, and why its failure >> caused >> mail loss rather than mail deferral. >> >> I apologize for any inconvenience this may have caused you. As >> always, >> please feel free to contact me if you have any questions or concerns. >> >> Regards, >> Alexa >> >> ----------- >> Alexa Morris / Executive Director / IETF >> 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 >> Phone: +1.510.492.4089 / Fax: +1.510.492.4001 >> Email: amorris@amsl.com >> >> Managed by Association Management Solutions (AMS) >> Forum Management, Meeting and Event Planning >> www.amsl.com >> >> >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > --Apple-Mail-21--325743244 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Alexa tells me that the below = message was affected, so I'm resending = it.

:)

RjS

=
Begin forwarded message:

From: = Robert Sparks <rjsparks@nostrum.com>
Date: = September 5, 2008 12:20:34 PM CDT
To: simple = mailing list <simple@ietf.org>, = GEOPRIV <geopriv@ietf.org>
Subject: = Fwd: IETF Mailing List Issue

I know most of you have seen = this already, but just in case someone here isn't on the announce or = discussion lists...

RjS
(If this is the = first time you've seen this, please consider subscribing to = -announce).

Begin forwarded message:

From: = Alexa Morris <amorris@amsl.com>
Date: = September 5, 2008 11:02:52 AM CDT
To: "ietf-announce@ietf.org" = <ietf-announce@ietf.org><= /div>
Cc: Working Group Chairs <wgchairs@ietf.org>, IETF = Discussion <ietf@ietf.org>, The = IESG <iesg@ietf.org>
Subject: = IETF Mailing List Issue

Last night, = after a server reboot, the postconfirm spam checker that was
recently = put in front of IETF mailing lists failed to start. =  Unfortunately,
this resulted in a huge influx of spam to the = IETF ticket system, and a
simultaneous failure of IETF list email. = Everything is back online now and
functioning; however, email = messages sent to IETF lists in the last 16 hours
were lost, and will = need to be resent.

We have now installed a direct watcher on = postconfirm, to force a restart of
it when it fails. In addition, = Henrik is working on the system now to find
out why it failed to = start in the first place, and why its failure caused
mail loss rather = than mail deferral.

I apologize for any inconvenience this may = have caused you. As always,
please feel free to contact me if you = have any questions or = concerns.

Regards,
Alexa

-----------
Alexa Morris / = Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA =  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: = amorris@amsl.com

Managed = by Association Management Solutions (AMS)
Forum Management, Meeting = and Event Planning
www.amsl.com = <http://www.amsl.com/>



___= ____________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/m= ailman/listinfo/ietf


= --Apple-Mail-21--325743244-- --===============0655952052== 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://www.ietf.org/mailman/listinfo/simple --===============0655952052==-- From simple-bounces@ietf.org Mon Sep 8 06:56:11 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35D23A6803; Mon, 8 Sep 2008 06:56:11 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D5A3A6803 for ; Mon, 8 Sep 2008 06:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.02 X-Spam-Level: * X-Spam-Status: No, score=1.02 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_20=-0.74, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UU-OqGY2+tSG for ; Mon, 8 Sep 2008 06:56:09 -0700 (PDT) Received: from node05.dns-hosting.info (node05.dns-hosting.info [85.17.186.5]) by core3.amsl.com (Postfix) with ESMTP id 157793A67FD for ; Mon, 8 Sep 2008 06:56:08 -0700 (PDT) Received: from mit.xs4all.nl ([80.101.96.20] helo=[192.168.1.6]) by node05.dns-hosting.info with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.68) (envelope-from ) id 1KchAV-000836-QK; Mon, 08 Sep 2008 15:52:41 +0200 Message-Id: <598FA1D5-CB1A-4532-8650-4B1721B16CD3@ag-projects.com> From: Adrian Georgescu To: simple@ietf.org, users@lists.opensips.org, users@lists.kamailio.org, SER Users , pjsip@lists.pjsip.org Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 8 Sep 2008 15:55:26 +0200 X-Mailer: Apple Mail (2.928.1) X-SA-Exim-Connect-IP: 80.101.96.20 X-SA-Exim-Mail-From: ag@ag-projects.com X-SA-Exim-Version: 4.2.1 (built Tue, 21 Aug 2007 23:39:36 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) Subject: [Simple] New OpenXCAP release 1.0.0 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============1420851417==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1420851417== Content-Type: multipart/alternative; boundary=Apple-Mail-6--90725533 --Apple-Mail-6--90725533 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello, There is a new release of OpenXCAP server available. It contains many bug fixes and additions for important features like XML partial manipulation, xcap-caps, xcap-diff and RLS services that were not available at the initial release last year. With this features OpenXCAP fulfills now most if not all relevant requirements for an XCAP server implementation. A generic xcap client library and command line client is available in the clients directory, you can use it to manipulate documents on OpenXCAP or other XCAP server implementation. The server software is also operational at http://sip2sip.info so you can test against it by registering a SIP account. Changes in version 1.0.0 * Added RLS services (RFC 4662 and RFC 4826) * Added support for xcap-diff based on draft-ietf-simple-xcap-diff-09 * Added partial get/put/delete of elements in the XCAP documents * Added test suite for rls-services, resource-lists and partial updates * Many bug fixes from field experiences * Development status from beta to production * Switched to Python 2.5 * Improved documentation and testing suite * Changed license to GPL * Fixed MySQL operational error (2006) The software can be downloaded from: http://openxcap.org Many thanks to Denis Bilenko who did most of the works for this new release. Kind regards, Adrian Georgescu --Apple-Mail-6--90725533 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello,

There is a new = release of OpenXCAP server available. It contains many bug fixes and = additions for important features like XML partial manipulation, = xcap-caps, xcap-diff and RLS services that were not available at the = initial release last year. With this features = OpenXCAP fulfills now most if not all relevant requirements = for an XCAP server implementation. A generic xcap client library = and command line client is available in the clients directory, you can = use it to manipulate documents on OpenXCAP or other XCAP server = implementation.

The server software is also = operational at http://sip2sip.info = so you can test against it by registering a SIP = account.

Changes in version = 1.0.0

  * Added RLS = services (RFC 4662 and RFC 4826)
  * Added support = for xcap-diff based on = draft-ietf-simple-xcap-diff-09
  * Added partial = get/put/delete of elements in the XCAP documents
  * = Added test suite for rls-services, resource-lists and partial = updates
  * Many bug fixes from field = experiences
  * Development status from beta to = production
  * Switched to Python = 2.5
  * Improved documentation and testing = suite
  * Changed license to = GPL
  * Fixed MySQL operational error = (2006)

The software can be downloaded = from:

http://openxcap.org

Many thanks to Denis Bilenko who did most of the works for this new = release.

Kind regards,
Adrian = Georgescu

= --Apple-Mail-6--90725533-- --===============1420851417== 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://www.ietf.org/mailman/listinfo/simple --===============1420851417==-- From simple-bounces@ietf.org Mon Sep 8 07:41:01 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E7A3A6BDD; Mon, 8 Sep 2008 07:41:01 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244463A6BC7 for ; Mon, 8 Sep 2008 07:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t18CwvEzBe+H for ; Mon, 8 Sep 2008 07:40:59 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 10C0A3A6B77 for ; Mon, 8 Sep 2008 07:40:59 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C8D00210D8 for ; Mon, 8 Sep 2008 16:40:59 +0200 (CEST) X-AuditID: c1b4fb3e-a5e7fbb000007a96-05-48c5397be1ce Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ADEDE211FE for ; Mon, 8 Sep 2008 16:40:59 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 16:40:59 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 16:40:58 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3D0B32463 for ; Mon, 8 Sep 2008 17:40:59 +0300 (EEST) Received: from n82.nomadiclab.com (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 299944DBBB for ; Mon, 8 Sep 2008 17:40:59 +0300 (EEST) Message-ID: <48C5397A.20703@ericsson.com> Date: Mon, 08 Sep 2008 17:40:58 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: simple@ietf.org X-OriginalArrivalTime: 08 Sep 2008 14:40:58.0883 (UTC) FILETIME=[E87F7530:01C911C0] X-Brightmail-Tracker: AAAAAA== Subject: [Simple] sip content delivery vs xmpp X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, I have a general question, and I d like have your opinion and vision on it! do you think it would be reasonable using the SIP Subscribe/Notify mechanism to general delivery content to an application? my question is because I have noticed that is becoming extremely popular to microblogging via XMPP by sending bare chat messages using the PubSub mechanism. XMPP has also specified in a draft how it can be used to transport Atom syndication Data (RFC 4287) ( http://www.xmpp.org/internet-drafts/draft-saintandre-atompub-notify-07.html ) I look forward to read your opinion Sal _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 8 11:46:36 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81DA43A6C3B; Mon, 8 Sep 2008 11:46:36 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20A163A6B15 for ; Mon, 8 Sep 2008 11:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVP8pVt7t5dY for ; Mon, 8 Sep 2008 11:46:00 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 5BF4F28C173 for ; Mon, 8 Sep 2008 11:45:59 -0700 (PDT) Received: from col-dhcp33-244-161.bbn.com ([128.33.244.161]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Kclk7-0007VX-D4; Mon, 08 Sep 2008 14:45:43 -0400 Message-ID: <48C572D6.5060302@bbn.com> Date: Mon, 08 Sep 2008 14:45:42 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: "'simple@ietf.org' WG" Cc: Steve Donovan , Kathleen McMurry Subject: [Simple] Review of draft-ietf-simple-view-sharing-01 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ======================================================================== Document: draft-ietf-simple-view-sharing-01 Reviewer: Richard L. Barnes, BBN Technologies Date: 5 September 2008 ======================================================================== General comments ======================================================================== 1. A seemingly minor but important point: The document is unclearthroughout on whether this mechanism facilitates sharing between "systems" or "domains". The latter is more consistent with Figure 1, and seems like what you're actually going for. In particular, if the RLS is associated with a domain, then it might be possible to avoid manual provisioning (see 6. below) 2. The document does a good job of addressing the risks that the Serving Domain is exposed to through view sharing. However, it doesn't address the privacy risks that the *presentity* is exposed to. The Watching Domain is now explicitly responsible for applying the privacy policies that the user has set (providing different views to different watchers), so the presentity now has to trust the Watching Domain to perform that operation as opposed to just passing through NOTIFYs. The risk is that the Watching Domain fails to apply the Rule Determination Algorithm (as required in 3.2.2), and presence info fromone view leaks into others. You can tell a similar story here to the one you tell for ACLs inthe Security Considerations: Without view sharing, the Watcher already has access to all that presence information, so if it were malicious, it could already leak information between views. Thus the only real risk is non-compliance, which you can't fix in a standard. The only recommendation that seems necessary here is another reminder to the RLS to reinforce the importance of the rules determination algorithm being done correctly. 3. It would be nice to discuss how view sharing interacts with S/MIME protected presence documents. For signed objects (that aren't encrypted), the usage is probably pretty much the same, except that the PA won't be able to modify the presence documents (unless it's the signer). For enveloped/encrypted objects, there's some interaction between the set of authorized watchers and the set of keys that can be used to decrypt the object. 4. It's not clear to me why it's more critical to use TLS with view sharing than otherwise. As you point out in the Security Considerations, no more information is exposed here than with normal SIP events. The risks of identity spoofing and interception are the same. It might even be less so if the peers are using direct links to each other (as in layer-2 peering federations). 5. The document doesn't specify whether or not a single ACL can contain members from many domains. From a privacy perspective, my preference would be to specify that within a single ACL, -- All members MUST have the same domain -- That domain MUST be the domain of the RLS 6. Obviously, the requirement for "explicit provisioning" of trusted domains is kind of a turn-off (for scalability, dynamic extension oftrusted enclaves, etc.). It seems like the critical distinction you're trying to enforce with this requirement is to separate an RLS from a watcher, where an RLS is the entity authorized -- by both domains -- to see all presence transactions between the two domains, and the watcher is only authorized (by either domain) to see its own transactions. Is there a mechanism other than manual provisioning to make this distinction? It seems like the RLS is something that might get advertised in the DNS, for example. Assuming that (1) the PA constrains view-sharing based on the domain of the (supposed) RLS matching an RLS in the DNS and (2) the PA only issues ACLs in which all members are from the same domain (see above), then the privacy risks would be eliminated. A request from a non-view-sharing domain (as in the current example attack) wouldn't come from an RLS, and an attacker that creates his own domain/RLS would only get information for his fake domain. 7. This document claims in the Abstract and the introduction to be an extension to the general SIP events framework. However, the entire introduction is presence-centric, and many of the sections that could be general use presence-specific terminology (e.g., S3.2.2 and S4; see comments below). It should be made clearer which parts are presence-specific, which are more general. 8. The document should clarify whether it is allowable for a PA to initiate the use of view sharing? For example, could you have a PA that only supports view sharing, so that it responds with "Required: view-share", whether or not the SUBSCRIBE asked for it? It may be best to forbid this, since it strengthens the asymmetry discussed in section 2 (PA decides, RLS pays computational burden). Specific comments ======================================================================== S2 Depending on the level of trust, the mechanism trades off inter- domain messaging traffic for increased processing load in the RLS to handle the ACL documents. This raised a red flag for me at first, since the load on the RLS is determined by what the PA decides to do. However, this asymmetry is not so bad because the Serving Domain has to give up potentially sensitive information in order to incur increased processing in the Watching Domain (and presumably, the Watching Domain has to ask for this, see S4 below). It would also be helpful to the reader here to have a brief description of what the logical structure of an ACL looks like, since that matters a lot for sections 3 and 4. S3 This section defines the procedures that are to be followed by the RLS. It is important to note that, even though this specification defines an extension to the SIP events framework, that extension is only useful for the back-end subscriptions generated by an RLS. I found the ordering of this section confusing. I would suggest re-organizing according to the temporal order of things, in the following way: 3.1.1: Current S3.1.3, Determine whether a suitable subscription exists 3.1.2: Current S3.1.2, Establishing a back-end subscription (Current 3.1.1 should be folded into 3.1.2, since it deals with how back-end subscription is sent) S3.1.2 Note that it is possible that two watchers, in a short period of time, both subscribe to their resource lists, both of which include presentity P. Might it be simpler to RECOMMEND these back-end transactions be done serially? S3.1.3 For each ACL Ai in the current ACL list, the RLS performs the rule determination algorithm of Section 5.4 to compute the rule ID R for the watcher W. Since the rule determination algorithm takes an ACL list as an input, shouldn't this say that the RLS performs the rule determination algorithm for W and the current ACL list for the presentity? S3.1.2 o If R is null, it means that the ACL doesn't specify the view ... Change to "If R is null, it means that no ACL in the list specifies the view..." S3.1.2 The RLS SHOULD NOT perform another back-end subscription, and must act as if it had created a back-end subscription which was rejected. Why is this a SHOULD and not a MUST? (Likewise for the subsequent bullet.) S3.2.1 If the contents of the NOTIFY are of type "application/aclinfo+xml", the subscriber processes the body as described here. This is really minor, but given that these aren't the only ACLs around, I would prefer a slightly more specific name, e.g. "application/view-sharing-aclinfo+xml" S3.2.1 The serving domain can change policies at any time. When it does, it sends an updated ACL on one or more subscriptions. The RLS MUST store this ACL. Do you mean for this ACL to be simply stored, or to replace the old ACL? (Not a huge issue because the rule determination algorithm picks the newest.) S3.2.1 Furthermore, if there are now two back-end subscriptions j1 and j2 for which Aj1 = Aj2, the RLS SHOULD terminate one of those two subscriptions. The terms "Aj1" and "Aj2" haven't been defined. Suggest replacing "for which Aj1 = Aj2" with "with equivalent ACLs". S3.2.2 If the contents of the NOTIFY is a presence document, the RLS follows the procedures defined here. The details of this section don't seem to have anything in particular to do with presence. Perhaps this could be re-cast in terms of notifications of event state in general. S4 4. Presence Agent Behavior The terminology used in this section could better reflect the generality of this mechanism. Perhaps use the terms "State Agent" from RFC 3265. S4 When a presence agent receives a SUBSCRIBE request containing a Supported header with the value "view-share", and it wishes to utilize view sharing for this subscription, it follows the procedures defined here. Is it allowable for a PA to initiate the use of view sharing? For example, could you have a PA that only supports view sharing, so that it responds with "Required: view-share", whether or not the SUBSCRIBE asked for it? It may be best to forbid this, since it strengthens the asymmetry discussed in section 2 (PA decides, RLS pays computational burden). S4.1 First, the presence agent MUST have received the SUBSCRIBE request over a mutually authenticated TLS connection. If it had not, view sharing cannot be utilized for this subscription. It's not clear to me why it's more to authenticate SUBSCRIBE requests here than in the general case. As you've argued in the Security Considerations, this extension doesn't grant any more information to the Watching Domain than was already accessible. So the risk due to a fake RLS with this extension is the same as before. S4.2 If an ACL and a presence document are to be delivered, they MUST be delivered in a separate NOTIFY request... Change "a separate NOTIFY request" to "separate NOTIFY requests" S4.3 o There is more than one subscription from the watching domain to this presentity with the same view, but the User-Agent header field in the request differs between them. Should this refer to the "sip-instance" parameter instead? (Likewise in S4.5) S5.1 This contains the list of rules defined by the ACL. Each rule is represented by the element. Seems like "" would be a more appropriate tag name, since there are no actual rule semantics here, just an identifier for a view of the events. S5.1 If two URI are present within elements within the same , it represents a contract by the presence server that both users MUST get the same view. Formally, if the presence server were to receive a subscription from each watcher, both subscriptions would be accepted or both would be rejected, and if accepted, each subscription would receive semantically identical presence documents at approximately the same time. This is the very first time that the term "view" is defined in the scope of this document. It should be closer to the beginning, say a paragraph in the introduction of the following character: " Frequently, several watchers served by an RLS will receive the same "view" of events: If the presence server were to receive a subscription from each watcher, both subscriptions would be accepted or both would be rejected, and if accepted, each subscription would receive semantically identical presence documents at approximately the same time. " Also, "indication" or "statement" would be a better word than "contract". S5.4 it is possible that inconsistent ACL documents exist. In that case, R is assigned the value Ri from the ACL Ai which is the most recently received amonst all ACL. Change "amonst all ACL" to "amongst all ACLs". _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 11 11:56:54 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A2B03A6A8C; Thu, 11 Sep 2008 11:56:54 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B6C3A6A8C; Thu, 11 Sep 2008 11:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.211 X-Spam-Level: X-Spam-Status: No, score=-17.211 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5X4sm3jkFlwz; Thu, 11 Sep 2008 11:56:51 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id B2F453A6A7A; Thu, 11 Sep 2008 11:56:51 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 45AD2154A06; Thu, 11 Sep 2008 11:56:52 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080911185652.45AD2154A06@bosco.isi.edu> Date: Thu, 11 Sep 2008 11:56:52 -0700 (PDT) Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 5196 on Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5196 Title: Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF) Author: M. Lonnfors, K. Kiss Status: Standards Track Date: September 2008 Mailbox: mikko.lonnfors@nokia.com, krisztian.kiss@nokia.com Pages: 30 Characters: 58488 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-prescaps-ext-10.txt URL: http://www.rfc-editor.org/rfc/rfc5196.txt Presence Information Data Format (PIDF) defines a common presence data format for Common Profile for Presence (CPP) compliant presence protocols. This memo defines a PIDF extension to represent SIP User Agent capabilities. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 11 11:57:33 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D5BF28C0EB; Thu, 11 Sep 2008 11:57:33 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 238393A689D; Thu, 11 Sep 2008 11:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.199 X-Spam-Level: X-Spam-Status: No, score=-17.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FbXcUoPU9C4; Thu, 11 Sep 2008 11:57:30 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 20F623A67B0; Thu, 11 Sep 2008 11:57:30 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 34BA0154A08; Thu, 11 Sep 2008 11:57:10 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080911185710.34BA0154A08@bosco.isi.edu> Date: Thu, 11 Sep 2008 11:57:10 -0700 (PDT) Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 5261 on An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5261 Title: An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors Author: J. Urpalainen Status: Standards Track Date: September 2008 Mailbox: jari.urpalainen@nokia.com Pages: 40 Characters: 78036 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-xml-patch-ops-04.txt URL: http://www.rfc-editor.org/rfc/rfc5261.txt Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic , , and directives a set of patches can then be applied to update an existing XML document. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 11 11:58:05 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3822928C105; Thu, 11 Sep 2008 11:58:05 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81E7B28C0F9; Thu, 11 Sep 2008 11:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.188 X-Spam-Level: X-Spam-Status: No, score=-17.188 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+doBumxaeKB; Thu, 11 Sep 2008 11:58:02 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id BA99628C0F0; Thu, 11 Sep 2008 11:57:57 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 4B7F5154A0A; Thu, 11 Sep 2008 11:57:31 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080911185731.4B7F5154A0A@bosco.isi.edu> Date: Thu, 11 Sep 2008 11:57:31 -0700 (PDT) Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 5262 on Presence Information Data Format (PIDF) Extension for Partial Presence X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5262 Title: Presence Information Data Format (PIDF) Extension for Partial Presence Author: M. Lonnfors, E. Leppanen, H. Khartabil, J. Urpalainen Status: Standards Track Date: September 2008 Mailbox: mikko.lonnfors@nokia.com, eva.leppanen@saunalahti.fi, hisham.khartabil@gmail.com, jari.urpalainen@nokia.com Pages: 16 Characters: 28527 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-partial-pidf-format-10.txt URL: http://www.rfc-editor.org/rfc/rfc5262.txt The Presence Information Document Format (PIDF) specifies the baseline XML-based format for describing presence information. One of the characteristics of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist, it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type that enables transporting of either only the changed parts or the full PIDF-based presence information. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 11 11:58:22 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9837B28C10B; Thu, 11 Sep 2008 11:58:22 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5379C28C10B; Thu, 11 Sep 2008 11:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.179 X-Spam-Level: X-Spam-Status: No, score=-17.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8jbSC6sIxUN; Thu, 11 Sep 2008 11:58:17 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 2CA6C28C0EB; Thu, 11 Sep 2008 11:58:17 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id ECCF3154A0C; Thu, 11 Sep 2008 11:57:47 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080911185747.ECCF3154A0C@bosco.isi.edu> Date: Thu, 11 Sep 2008 11:57:47 -0700 (PDT) Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 5263 on Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5263 Title: Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information Author: M. Lonnfors, J. Costa-Requena, E. Leppanen, H. Khartabil Status: Standards Track Date: September 2008 Mailbox: mikko.lonnfors@nokia.com, jose.costa-requena@nokia.com, eva.leppanen@saunalahti.fi, hisham.khartabil@gmail.com Pages: 16 Characters: 32556 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-partial-notify-10.txt URL: http://www.rfc-editor.org/rfc/rfc5263.txt By default, presence delivered using the presence event package for the Session Initiation Protocol (SIP) is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of only the presence data that has actually changed. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 11 11:58:41 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522FE28C0F8; Thu, 11 Sep 2008 11:58:41 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDE453A6A1D; Thu, 11 Sep 2008 11:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.17 X-Spam-Level: X-Spam-Status: No, score=-17.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99RvYUEhbs0D; Thu, 11 Sep 2008 11:58:39 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id E827B28C0F8; Thu, 11 Sep 2008 11:58:38 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 180CB154A0E; Thu, 11 Sep 2008 11:58:06 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080911185806.180CB154A0E@bosco.isi.edu> Date: Thu, 11 Sep 2008 11:58:06 -0700 (PDT) Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 5264 on Publication of Partial Presence Information X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5264 Title: Publication of Partial Presence Information Author: A. Niemi, M. Lonnfors, E. Leppanen Status: Standards Track Date: September 2008 Mailbox: aki.niemi@nokia.com, mikko.lonnfors@nokia.com, eva.leppanen@saunalaht.fi Pages: 15 Characters: 30594 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-partial-publish-07.txt URL: http://www.rfc-editor.org/rfc/rfc5264.txt The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bears a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitute a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 12 04:57:05 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1993A6A73; Fri, 12 Sep 2008 04:57:05 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E1C3A697F for ; Fri, 12 Sep 2008 04:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.632 X-Spam-Level: X-Spam-Status: No, score=-5.632 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZdOrgie+QPy for ; Fri, 12 Sep 2008 04:57:03 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0E5BB3A696A for ; Fri, 12 Sep 2008 04:57:03 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7A1C520B62; Fri, 12 Sep 2008 13:57:09 +0200 (CEST) X-AuditID: c1b4fb3c-ad0ccbb0000015b5-c2-48ca591516d2 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5EC6820D37; Fri, 12 Sep 2008 13:57:09 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Sep 2008 13:57:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Sep 2008 13:57:08 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of draft-blau-simple-msrp-acm Thread-Index: AckUzq7PR2Vc+VmSQ6Oeav1YGGk+Yg== From: "Christer Holmberg" To: X-OriginalArrivalTime: 12 Sep 2008 11:57:09.0089 (UTC) FILETIME=[AF22ED10:01C914CE] X-Brightmail-Tracker: AAAAAA== Cc: Robert Sparks Subject: [Simple] New version of draft-blau-simple-msrp-acm X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============0979913440==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0979913440== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C914CE.AEDD1D9C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C914CE.AEDD1D9C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submited a new version of the msrp-acm draft. Since nobody indicated on the list (I did ask twice :) that he/she wants to be able to use only the comedia part of the draft, I haven't changed that. Instead the draft still specifies the usage of comedia and the SDP c/m routing, and that allowed me to remove the a=3Dmsrp-acm attribute, since the a=3Dsetup attribute is enough to indicate support of the mechanism in the draft. The draft can also be found at: (http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm-01.tx t) Regards, Christer ------_=_NextPart_001_01C914CE.AEDD1D9C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New version of draft-blau-simple-msrp-acm

Hi,

I've submited a new version of the = msrp-acm draft.

Since nobody indicated on the list (I = did ask twice :) that he/she wants to be able to use only the comedia = part of the draft, I haven't changed that. Instead the draft still = specifies the usage of comedia and the SDP c/m routing, and that allowed = me to remove the a=3Dmsrp-acm attribute, since the a=3Dsetup attribute = is enough to indicate support of the mechanism in the draft.

The draft can also be found at:

(http://users.piuha.net/cholmber/drafts/draft-blau-simple-m= srp-acm-01.txt)

Regards,

Christer

------_=_NextPart_001_01C914CE.AEDD1D9C-- --===============0979913440== 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://www.ietf.org/mailman/listinfo/simple --===============0979913440==-- From simple-bounces@ietf.org Fri Sep 12 10:35:41 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1BA03A6C69; Fri, 12 Sep 2008 10:35:41 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73EF73A6C65; Fri, 12 Sep 2008 10:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRvSXEtchth1; Fri, 12 Sep 2008 10:35:39 -0700 (PDT) Received: from estacado.net (unknown [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 1EA6A3A6C63; Fri, 12 Sep 2008 10:35:38 -0700 (PDT) Received: from [172.16.3.232] (dn3-232.estacado.net [172.16.3.232]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m8CHZhTk030580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Sep 2008 12:35:44 -0500 (CDT) (envelope-from rjsparks@estacado.net) Message-Id: <8C25C3F3-9025-4DEB-869E-26B9F16A289C@estacado.net> From: Robert Sparks To: simple mailing list , GEOPRIV Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 12 Sep 2008 12:35:43 -0500 References: <20080912164811.74CF63A6C4E@core3.amsl.com> X-Mailer: Apple Mail (2.926) Subject: [Simple] Fwd: Nomcom call for candidates X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============1842030883==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1842030883== Content-Type: multipart/alternative; boundary=Apple-Mail-14-268091510 --Apple-Mail-14-268091510 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Everyone - The nomcom opened the nomination period recently and has a very short window in which to collect a reasonable set of candidates to consider for each of the opening positions. Please take a moment to think about who you would like to have them consider and send in your nominations. Thanks! RjS Begin forwarded message: > From: NomCom Chair > Date: September 12, 2008 11:48:11 AM CDT > To: Working Group Chairs > Subject: Nomcom call for candidates > > The message below was just sent to the IETF-Annoucne list. > However, it order to get to as many people as possible, I am asking WG > chairs a favor. Please forward the message to your working groups. > > Thank you, > Joel M. Halpern > > The 2008-9 IETF Nominating Committee needs your help. > We have started getting candidates. > If we are going to do our job in time, we have only 3 more weeks to > get > enough candidates to have a reasonable pool for all the jobs. > At the moment, we do not have a reasonable pool for any jobs. > > If you are willing to serve, please nominate yourself. > If there is someone you think would do a good job, please nominate > them. > > The web site at: > http://wiki.tools.ietf.org/group/nomcom/08 > Has the list of positions we are seeking people for, as well as > tools for > providing both nominations and feedback. > > Alternatively, you can submit nominations by sending email to me. > > Please help us. > > Thank you, > Joel M. Halpern > jmh@joelhalpern.com > nomcom-chair@ietf.org --Apple-Mail-14-268091510 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Everyone = -

The nomcom opened the nomination period recently = and has a very short window in which to collect a reasonable set of = candidates to consider for each of the opening = positions.

Please take a moment to think about = who you would like to have them consider and send in your = nominations.

Thanks!

RjS=

Begin forwarded message:

From: = NomCom Chair <nomcom-chair@ietf.org>
Date: = September 12, 2008 11:48:11 AM CDT
To: Working = Group Chairs <wgchairs@ietf.org>
Subject: = Nomcom call for candidates 

The message = below was just sent to the IETF-Annoucne list.
However, it order to = get to as many people as possible, I am asking WG
chairs a favor. =  Please forward the message to your working groups.

Thank = you,
Joel M. Halpern

The 2008-9 IETF Nominating Committee = needs your help.
We have started getting candidates.
If we are = going to do our job in time, we have only 3 more weeks to get
enough = candidates to have a reasonable pool for all the jobs.
At the moment, = we do not have a reasonable pool for any jobs.

If you are willing = to serve, please nominate yourself.
If there is someone you think = would do a good job, please nominate them.

The web site at:
=    http://wiki.tools.ietf= .org/group/nomcom/08
Has the list of positions we are seeking = people for, as well as tools for
providing both nominations and = feedback.

Alternatively, you can submit nominations by sending = email to me.

Please help us.

Thank you,
Joel M. = Halpern
jmh@joelhalpern.com
nomcom-chai= r@ietf.org

= --Apple-Mail-14-268091510-- --===============1842030883== 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://www.ietf.org/mailman/listinfo/simple --===============1842030883==-- From simple-bounces@ietf.org Fri Sep 12 10:57:46 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62D2F28C16A; Fri, 12 Sep 2008 10:57:46 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557AE28C151 for ; Fri, 12 Sep 2008 10:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.049 X-Spam-Level: X-Spam-Status: No, score=-0.049 tagged_above=-999 required=5 tests=[AWL=1.069, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wkmSRkphmgr for ; Fri, 12 Sep 2008 10:57:44 -0700 (PDT) Received: from node05.dns-hosting.info (node05.dns-hosting.info [85.17.186.5]) by core3.amsl.com (Postfix) with ESMTP id 2C0CA28C16A for ; Fri, 12 Sep 2008 10:57:43 -0700 (PDT) Received: from mit.xs4all.nl ([80.101.96.20] helo=[192.168.1.6]) by node05.dns-hosting.info with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.68) (envelope-from ) id 1KeCr3-0004dF-9L; Fri, 12 Sep 2008 19:54:51 +0200 Message-Id: <37A7F9C0-F47A-4020-AC46-C3B3C65E2842@ag-projects.com> From: Adrian Georgescu To: simple@ietf.org Mime-Version: 1.0 (Apple Message framework v928.1) Date: Fri, 12 Sep 2008 19:57:40 +0200 X-Mailer: Apple Mail (2.928.1) X-SA-Exim-Connect-IP: 80.101.96.20 X-SA-Exim-Mail-From: ag@ag-projects.com X-SA-Exim-Version: 4.2.1 (built Tue, 21 Aug 2007 23:39:36 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) Subject: [Simple] New MSRPRelay release 1.0.0 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hello, The first stable release of MSRPRelay, an Open Source implementation of IETF standard RFC 4976 is available. MSRP relay is an extension to the MSRP protocol (RFC 4975). Its main role is to help NAT traversal of Interactive Messaging and file transfer sessions for SIP/MSRP endpoints located behind NAT. For more information visit http://msrprelay.org Changelog * Removed per-domain configuration and certificates in favour of detecting the SIP domain from the To-Path. This assumes SRV records are used to look up the MSRP relay. This also elimites the need for using the TLS server name extension. * Removed any references to CAs and CRLs. * Simplified certificate generation. * Cleaned up test script directory. * Added own runtime directory in /var/run to store runtime files. * Added commandline option to specify the name of the config file to read. * Fixed the "memory" backend to support domain names. * Added username@domain and total session bytecount to logging output. * Several miscellaneous fixes based on field experience. -- Ruud Klaver Mon, 08 Sep 2008 19:14:09 +0200 Kind regards, Adrian Georgescu _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 16 21:24:02 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4093E3A6949; Tue, 16 Sep 2008 21:24:02 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B72803A693E for ; Tue, 16 Sep 2008 21:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqBb8vI9MMHM for ; Tue, 16 Sep 2008 21:23:58 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id C3EF43A68CD for ; Tue, 16 Sep 2008 21:23:58 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2762283rvf.49 for ; Tue, 16 Sep 2008 21:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=hkXN7OeA2cUSunDdGkJtt1YUSPdC7Gtryv1sA/mY1Ow=; b=C4z6fQnDjDzfZ9h2IY8yFp82SkcHjCE69YtjDCIe9i9KwNwgN3qDqDo6lokBuJm/Qm qddXS9My5jhoIRM91z1AuG6iFP49trR/CxmqBUN2CUNeIMBZRquQUWT6NJ9KV/93Vq+s x86zu9OomuapbePyjsPD7y7aRH+12WD7pajzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=Jnwoei7kFPBuJIOrVDEmfPuoUQgafP9koynIOrxsG5YaEYLXaguq51bA8hLOlOqcmA y5E5TZ1Uiczmhop1Iln0G0byZIuttd8Mi0J+PIUYYtzS8wSrQpr66EKRMigb7MFDGdQk G3S0iW1ZJOzsng8JHuT1mmtTMF8cjPDQU38NE= Received: by 10.141.49.18 with SMTP id b18mr6242087rvk.92.1221625451084; Tue, 16 Sep 2008 21:24:11 -0700 (PDT) Received: by 10.141.116.8 with HTTP; Tue, 16 Sep 2008 21:24:11 -0700 (PDT) Message-ID: <66cd252f0809162124k1a861742t650609595759cd77@mail.gmail.com> Date: Wed, 17 Sep 2008 14:24:11 +1000 From: "Hisham Khartabil" To: "Eric Burger" In-Reply-To: MIME-Version: 1.0 References: <1660532724-1210725948-cardhu_decombobulator_blackberry.rim.net-784864713-@bxe033.bisx.prod.on.blackberry> <66cd252f0805131939t6569dab7r45d8ced20471a157@mail.gmail.com> <77384F67-E82C-483C-B555-665BFAF02D4E@standardstrack.com> <66cd252f0805132138m23aa3f42kf01ce0dcb7c42181@mail.gmail.com> <3092F25A-A072-4952-9C44-8C639B1925E2@softarmor.com> <4834C22B.1000407@cisco.com> <437FCCA2-DA86-48D8-9DAA-24A09CDDE677@estacado.net> <66cd252f0806040219x4f3354d0t91b76f729452c3e1@mail.gmail.com> Cc: simple@ietf.org Subject: Re: [Simple] in IMDN X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============1247197582==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1247197582== Content-Type: multipart/alternative; boundary="----=_Part_5772_8618092.1221625451066" ------=_Part_5772_8618092.1221625451066 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline For the sake of moving this draft to completion, I plan to remove the element from IMDNs. If someone is interested in extending the schema to allow an element that carries extra information about the reasons behind a certain disposition status, please write an I-D. Any objections? Regards, Hisham On 04/06/2008, Eric Burger wrote: > > Except: > > 1. I have no clue what language to use in the message, as a human will read > it. > > 2. The field is free-form, so is not amenable for automaton processing. > > 3. The field is free-form, but could be read by the UAC, so it will invite > vendors to put proprietary information into the field. Then users expect > particular behaviors when these values are present. I.e., who needs the > IETF to review protocol element use? Let the random implementor of the day > build a protocol on top of IMDN! > > 4. The field is free-form and displayed to the user, so it will invite > spam. > > If it is useful from a protocol perspective, then create an IANA registry > of values. > > > On Jun 4, 2008, at 5:19 AM, Hisham Khartabil wrote: > > The field is not useless. It carries extra information (a reason >> phrase, if you like) as to why the IM delivery resulted in an error or >> still being processed, etc. >> >> Hisham >> >> 2008/6/4 Ben Campbell : >> >>> >>> On May 23, 2008, at 2:21 PM, Eric Burger wrote: >>> >>> Actually, IMDNs, even the SIMPLE free-form fields, are fairly >>>> constrained. Any mis-match is an opportunity to filter out bad >>>> IMDNs. The field has three problems: >>>> >>>> 1. It cannot be filtered, as any content could be real (which >>>> introduces the attack vector) >>>> >>>> 2. It cannot know what language it should use, and thus is not likely >>>> to be useful to the recipient >>>> >>>> 3. It has no protocol value, and is of no value to the UA >>>> >>>> >>>> So, if something has no useful protocol value and introduces a spam >>>> opportunity, why would we want to include it? >>>> >>>> >>> If something has no useful protocol value, even if it _does_no_harm, >>> why would we want to include it? >>> >>> IMHO, there is no need to prove a vector for harm, if we are fairly >>> certain there is no vector for _utility_. >>> >>> (Note that I am agnostic on whether the field is truly useless--I am >>> merely commenting on the form of the argument.) >>> >>> >>> >>>> >>>> On May 21, 2008, at 7:45 PM, Paul Kyzivat wrote: >>>> >>>> Its kind of late to be thinking about this now. THe problem is >>>>> pervasive >>>>> in MSRP. >>>>> >>>>> In SIP there are lots of unconstrained fields. But they are all >>>>> constrained by the overall size of the message, and people commonly >>>>> put >>>>> limits on that. >>>>> >>>>> In MSRP, because of chunking, a single MSRP message can be gigabytes >>>>> long. So using that to bound the unconstrained parts of the headers >>>>> doesn't work very well. >>>>> >>>>> A robust implementation might take a similar approach - define its >>>>> own >>>>> limit on the total message size, excluding the body. Then it could >>>>> constrain all the unconstrained fields to fit within it. >>>>> >>>>> But picking on one header isn't a solution to the problem. Either >>>>> assume >>>>> the developers will be able to deal with it, or else do and MSRPv2 >>>>> that >>>>> eliminates all unconstrained fields. >>>>> >>>>> Paul >>>>> >>>>> Dean Willis wrote: >>>>> >>>>>> On May 13, 2008, at 11:38 PM, Hisham Khartabil wrote: >>>>>> >>>>>> Can you explain how it is an attack vector? >>>>>>> >>>>>> >>>>>> >>>>>> Unconstrained rich content is one of the most easily exploited >>>>>> attack >>>>>> vectors. >>>>>> >>>>>> Buffer overrun attacks as well as all of the typical MIME compound- >>>>>> component attacks are likely. For example, the common JPEG >>>>>> vulnerabilities might be exploitable: >>>>>> >>>>>> >>>>>> http://www.news.com/Image-virus-spreads-via-chat/2100-7349_3-5390463.html >>>>>> >>>>>> >>>>>> Or the content-execution weakness that caused the Macintosh Safari >>>>>> browse to be most easily exploited in recent hacking contests: >>>>>> >>>>>> >>>>>> http://www.engadget.com/2007/07/23/safari-exploit-gives-hackers-full-control-of-your-iphone/ >>>>>> >>>>>> >>>>>> There have also been exploits against QuickTime, Flash, and most >>>>>> other >>>>>> plugin components from time to time. >>>>>> >>>>>> -- >>>>>> Dean >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/simple >>>>>> >>>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/simple >>>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>> >>> > ------=_Part_5772_8618092.1221625451066 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
For the sake of moving this draft to completion, I plan to remove the <note> element from IMDNs. If someone is interested in extending the schema to allow an element that carries extra information about the reasons behind a certain disposition status, please write an I-D.
 
Any objections?
 
Regards,
Hisham

 
On 04/06/2008, Eric Burger <eburger@standardstrack.com> wrote:
Except:

1. I have no clue what language to use in the message, as a human will read it.

2. The field is free-form, so is not amenable for automaton processing.

3. The field is free-form, but could be read by the UAC, so it will invite vendors to put proprietary information into the field.  Then users expect particular behaviors when these values are present.  I.e., who needs the IETF to review protocol element use?  Let the random implementor of the day build a protocol on top of IMDN!

4. The field is free-form and displayed to the user, so it will invite spam.

If it is useful from a protocol perspective, then create an IANA registry of values.



On Jun 4, 2008, at 5:19 AM, Hisham Khartabil wrote:

The field is not useless. It carries extra information (a reason
phrase, if you like) as to why the IM delivery resulted in an error or
still being processed, etc.

Hisham

2008/6/4 Ben Campbell <ben@estacado.net>:

On May 23, 2008, at 2:21 PM, Eric Burger wrote:

Actually, IMDNs, even the SIMPLE free-form fields, are fairly
constrained.  Any mis-match is an opportunity to filter out bad
IMDNs.  The <note> field has three problems:

1. It cannot be filtered, as any content could be real (which
introduces the attack vector)

2. It cannot know what language it should use, and thus is not likely
to be useful to the recipient

3. It has no protocol value, and is of no value to the UA


So, if something has no useful protocol value and introduces a spam
opportunity, why would we want to include it?


If something has no useful protocol value, even if it _does_no_harm,
why would we want to include it?

IMHO, there is no need to prove a vector for harm, if we are fairly
certain there is no vector for _utility_.

(Note that I am agnostic on whether  the field is truly useless--I am
merely commenting on the form of the argument.)




On May 21, 2008, at 7:45 PM, Paul Kyzivat wrote:

Its kind of late to be thinking about this now. THe problem is
pervasive
in MSRP.

In SIP there are lots of unconstrained fields. But they are all
constrained by the overall size of the message, and people commonly
put
limits on that.

In MSRP, because of chunking, a single MSRP message can be gigabytes
long. So using that to bound the unconstrained parts of the headers
doesn't work very well.

A robust implementation might take a similar approach - define its
own
limit on the total message size, excluding the body. Then it could
constrain all the unconstrained fields to fit within it.

But picking on one header isn't a solution to the problem. Either
assume
the developers will be able to deal with it, or else do and MSRPv2
that
eliminates all unconstrained fields.

   Paul

Dean Willis wrote:
On May 13, 2008, at 11:38 PM, Hisham Khartabil wrote:

Can you explain how it is an attack vector?


Unconstrained rich content is one of the most easily exploited
attack
vectors.

Buffer overrun attacks as well as all of the typical MIME compound-
component attacks are likely. For example, the common JPEG
vulnerabilities might be exploitable:

http://www.news.com/Image-virus-spreads-via-chat/2100-7349_3-5390463.html


Or the content-execution weakness that caused the Macintosh Safari
browse to be most easily exploited in recent hacking contests:

http://www.engadget.com/2007/07/23/safari-exploit-gives-hackers-full-control-of-your-iphone/


There have also been exploits against QuickTime, Flash, and most
other
plugin components from time to time.

--
Dean
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

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

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

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



------=_Part_5772_8618092.1221625451066-- --===============1247197582== 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://www.ietf.org/mailman/listinfo/simple --===============1247197582==-- From simple-bounces@ietf.org Wed Sep 17 03:23:39 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6754428C284; Wed, 17 Sep 2008 03:23:39 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6AB3A6C87 for ; Wed, 17 Sep 2008 03:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wq+EU7hWtXcb for ; Wed, 17 Sep 2008 03:23:37 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 174B13A68CF for ; Wed, 17 Sep 2008 03:23:37 -0700 (PDT) Received: from [209.203.74.95] (port=51665) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KfuBm-0001tk-4k; Wed, 17 Sep 2008 03:23:47 -0700 Message-Id: <99FCA0AC-9644-4462-948D-AA56FC091317@standardstrack.com> From: Eric Burger To: Hisham Khartabil In-Reply-To: <66cd252f0809162124k1a861742t650609595759cd77@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 17 Sep 2008 03:23:10 -0700 References: <1660532724-1210725948-cardhu_decombobulator_blackberry.rim.net-784864713-@bxe033.bisx.prod.on.blackberry> <66cd252f0805131939t6569dab7r45d8ced20471a157@mail.gmail.com> <77384F67-E82C-483C-B555-665BFAF02D4E@standardstrack.com> <66cd252f0805132138m23aa3f42kf01ce0dcb7c42181@mail.gmail.com> <3092F25A-A072-4952-9C44-8C639B1925E2@softarmor.com> <4834C22B.1000407@cisco.com> <437FCCA2-DA86-48D8-9DAA-24A09CDDE677@estacado.net> <66cd252f0806040219x4f3354d0t91b76f729452c3e1@mail.gmail.com> <66cd252f0809162124k1a861742t650609595759cd77@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: simple@ietf.org Subject: Re: [Simple] in IMDN X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============2086835544==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============2086835544== Content-Type: multipart/signed; boundary=Apple-Mail-16-674138859; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-16-674138859 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I cannot argue with that position :-) +1 On Sep 16, 2008, at 9:24 PM, Hisham Khartabil wrote: > For the sake of moving this draft to completion, I plan to remove > the element from IMDNs. If someone is interested in extending > the schema to allow an element that carries extra information about > the reasons behind a certain disposition status, please write an I-D. > > Any objections? > > Regards, > Hisham > > > On 04/06/2008, Eric Burger wrote: Except: > > 1. I have no clue what language to use in the message, as a human > will read it. > > 2. The field is free-form, so is not amenable for automaton > processing. > > 3. The field is free-form, but could be read by the UAC, so it will > invite vendors to put proprietary information into the field. Then > users expect particular behaviors when these values are present. > I.e., who needs the IETF to review protocol element use? Let the > random implementor of the day build a protocol on top of IMDN! > > 4. The field is free-form and displayed to the user, so it will > invite spam. > > If it is useful from a protocol perspective, then create an IANA > registry of values. > > > > On Jun 4, 2008, at 5:19 AM, Hisham Khartabil wrote: > > The field is not useless. It carries extra information (a reason > phrase, if you like) as to why the IM delivery resulted in an error or > still being processed, etc. > > Hisham > > 2008/6/4 Ben Campbell : > > On May 23, 2008, at 2:21 PM, Eric Burger wrote: > > Actually, IMDNs, even the SIMPLE free-form fields, are fairly > constrained. Any mis-match is an opportunity to filter out bad > IMDNs. The field has three problems: > > 1. It cannot be filtered, as any content could be real (which > introduces the attack vector) > > 2. It cannot know what language it should use, and thus is not likely > to be useful to the recipient > > 3. It has no protocol value, and is of no value to the UA > > > So, if something has no useful protocol value and introduces a spam > opportunity, why would we want to include it? > > > If something has no useful protocol value, even if it _does_no_harm, > why would we want to include it? > > IMHO, there is no need to prove a vector for harm, if we are fairly > certain there is no vector for _utility_. > > (Note that I am agnostic on whether the field is truly useless--I am > merely commenting on the form of the argument.) > > > > > On May 21, 2008, at 7:45 PM, Paul Kyzivat wrote: > > Its kind of late to be thinking about this now. THe problem is > pervasive > in MSRP. > > In SIP there are lots of unconstrained fields. But they are all > constrained by the overall size of the message, and people commonly > put > limits on that. > > In MSRP, because of chunking, a single MSRP message can be gigabytes > long. So using that to bound the unconstrained parts of the headers > doesn't work very well. > > A robust implementation might take a similar approach - define its > own > limit on the total message size, excluding the body. Then it could > constrain all the unconstrained fields to fit within it. > > But picking on one header isn't a solution to the problem. Either > assume > the developers will be able to deal with it, or else do and MSRPv2 > that > eliminates all unconstrained fields. > > Paul > > Dean Willis wrote: > On May 13, 2008, at 11:38 PM, Hisham Khartabil wrote: > > Can you explain how it is an attack vector? > > > Unconstrained rich content is one of the most easily exploited > attack > vectors. > > Buffer overrun attacks as well as all of the typical MIME compound- > component attacks are likely. For example, the common JPEG > vulnerabilities might be exploitable: > > http://www.news.com/Image-virus-spreads-via-chat/2100-7349_3-5390463.html > > > Or the content-execution weakness that caused the Macintosh Safari > browse to be most easily exploited in recent hacking contests: > > http://www.engadget.com/2007/07/23/safari-exploit-gives-hackers-full-control-of-your-iphone/ > > > There have also been exploits against QuickTime, Flash, and most > other > plugin components from time to time. > > -- > Dean > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > > > --Apple-Mail-16-674138859 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA5MTcxMDIzMTFaMCMGCSqGSIb3 DQEJBDEWBBTOvACgIa9GbM2/uzbLdJiLRrx+HTCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQBOfTgqFNYzoj1sCyQvzrLV/QrvME03p/VFwFeQXcUEqRf3 rnQ8kcbQ/HQq2pUdLn80lUVO2tfqSskr980o5oJMLUh1dBSLs/z9Mo7Pc3mGHYjV28zaMz9t8+y3 g3gkeTliHgizQ3hApeua8emfQHBDu6n1Zcem8i1AgE+F7YWCwlAGerm3rEwBLmFIOkzVu9LMEmXh KsLHVEHBOTAVqohL3pDlEKJbDQqm8tpZirt1tsMKJPzPleStyetqvVcH+26sQfHVjUDGiVN5BZOx s5U+F3GozloPVnG3VCt7jlzSdSye/ZFLKQ/NO4ND1OnQauYyKTbd5HHeTwJtSBaefFjSAAAAAAAA --Apple-Mail-16-674138859-- --===============2086835544== 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://www.ietf.org/mailman/listinfo/simple --===============2086835544==-- From simple-bounces@ietf.org Wed Sep 17 11:24:51 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DCBD3A6CB6; Wed, 17 Sep 2008 11:24:51 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62FA03A6827; Wed, 17 Sep 2008 11:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPSxASLSD3LF; Wed, 17 Sep 2008 11:24:47 -0700 (PDT) Received: from nostrum.com (unknown [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 85D303A6838; Wed, 17 Sep 2008 11:24:46 -0700 (PDT) Received: from [192.168.2.6] (pool-68-238-148-61.dllstx.fios.verizon.net [68.238.148.61]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.1) with ESMTP id m8HIOvWh064152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Sep 2008 13:24:57 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <3A760625-C47C-4BEB-84B2-EB90C134F88D@nostrum.com> From: Robert Sparks To: "SIP@ietf.org List" , "sip-implementors@lists.cs.columbia.edu Implementors" , sipping LIST , simple mailing list Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 17 Sep 2008 13:24:57 -0500 X-Mailer: Apple Mail (2.926) Received-SPF: pass (nostrum.com: 68.238.148.61 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94/8270/Wed Sep 17 08:15:56 2008 on shaman.nostrum.com X-Virus-Status: Clean Subject: [Simple] SIPit registration closes in 2 weeks X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============1681897012==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1681897012== Content-Type: multipart/alternative; boundary=Apple-Mail-95-703045060 --Apple-Mail-95-703045060 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Registration for SIPit 23 closes 4 weeks from Friday. If you are planning to attend and have not yet registered, please do so today. SIPit 23 will be held in Lannion, France October 13-17, hosted by ETSI with technical support from France-Telecom Orange Labs. Registration is 490Euro per participant, and the deadline for registration is October 3. Attendees are strongly encouraged to make reservations and travel arrangements as soon as possible. More information and links to registration are available at http://www.sipit.net and http://www.etsi.org/plugtests/SIPit/SIPit.htm Thanks, RjS --Apple-Mail-95-703045060 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Registration for SIPit 23 closes 4 weeks from Friday. If you are planning to attend and have not yet registered, please do so today.

SIPit 23 will be held in Lannion, France October 13-17, hosted by ETSI with technical support from France-Telecom Orange Labs.

Registration is 490Euro per participant, and the deadline for registration is October 3.

Attendees are strongly encouraged to make reservations and travel arrangements as soon as possible.

More information and links to registration are available at
http://www.sipit.net
and
http://www.etsi.org/plugtests/SIPit/SIPit.htm

Thanks,

RjS --Apple-Mail-95-703045060-- --===============1681897012== 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://www.ietf.org/mailman/listinfo/simple --===============1681897012==-- From simple-bounces@ietf.org Wed Sep 17 11:27:28 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17FA428C2EF; Wed, 17 Sep 2008 11:27:28 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42C128C0FC; Wed, 17 Sep 2008 11:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-RUcKe5+B6p; Wed, 17 Sep 2008 11:27:24 -0700 (PDT) Received: from nostrum.com (unknown [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A14C83A6CB4; Wed, 17 Sep 2008 11:27:23 -0700 (PDT) Received: from [192.168.2.6] (pool-68-238-148-61.dllstx.fios.verizon.net [68.238.148.61]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.1) with ESMTP id m8HIRYxa064370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Sep 2008 13:27:34 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <9C54997C-DC57-4E7E-A5A2-8369A9027353@nostrum.com> From: Robert Sparks To: Robert Sparks In-Reply-To: <3A760625-C47C-4BEB-84B2-EB90C134F88D@nostrum.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 17 Sep 2008 13:27:34 -0500 References: <3A760625-C47C-4BEB-84B2-EB90C134F88D@nostrum.com> X-Mailer: Apple Mail (2.926) Received-SPF: pass (nostrum.com: 68.238.148.61 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94/8270/Wed Sep 17 08:15:56 2008 on shaman.nostrum.com X-Virus-Status: Clean Cc: "SIP@ietf.org List" , sipping LIST , simple mailing list , "sip-implementors@lists.cs.columbia.edu Implementors" Subject: Re: [Simple] SIPit registration closes in 2 weeks X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============1544038364==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1544038364== Content-Type: multipart/alternative; boundary=Apple-Mail-96-703202317 --Apple-Mail-96-703202317 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Of course, that should have said _2_ weeks from friday. Apologies for having to repeat the crosspost. On Sep 17, 2008, at 1:24 PM, Robert Sparks wrote: > Registration for SIPit 23 closes 4 weeks from Friday. If you are > planning to attend and have not yet registered, please do so today. > > SIPit 23 will be held in Lannion, France October 13-17, hosted by > ETSI with technical support from France-Telecom Orange Labs. > > Registration is 490Euro per participant, and the deadline for > registration is October 3. > > Attendees are strongly encouraged to make reservations and travel > arrangements as soon as possible. > > More information and links to registration are available at > http://www.sipit.net > and > http://www.etsi.org/plugtests/SIPit/SIPit.htm > > Thanks, > > RjS --Apple-Mail-96-703202317 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Of course, that should have = said _2_ weeks from friday. Apologies for having to repeat the = crosspost.

On Sep 17, 2008, at 1:24 PM, Robert = Sparks wrote:

Registration for = SIPit 23 closes 4 weeks from Friday. If you are planning to attend and = have not yet registered, please do so today.

SIPit = 23 will be held in Lannion, France October 13-17, hosted by ETSI with = technical support from France-Telecom Orange Labs.

Registration = is 490Euro per participant, and the deadline for registration is October = 3.

Attendees are strongly encouraged to make reservations and = travel arrangements as soon as possible.

More information and = links to registration are available at
http://www.sipit.net
and
http://www.etsi.org= /plugtests/SIPit/SIPit.htm

Thanks,

RjS

= --Apple-Mail-96-703202317-- --===============1544038364== 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://www.ietf.org/mailman/listinfo/simple --===============1544038364==-- From simple-bounces@ietf.org Wed Sep 17 13:43:36 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461053A68EB; Wed, 17 Sep 2008 13:43:36 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC803A6840 for ; Wed, 17 Sep 2008 13:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iTZe+-wrYGd for ; Wed, 17 Sep 2008 13:43:34 -0700 (PDT) Received: from estacado.net (unknown [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 96CF13A6814 for ; Wed, 17 Sep 2008 13:43:32 -0700 (PDT) Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m8HKheZ7074032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Sep 2008 15:43:41 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: Christer Holmberg In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 17 Sep 2008 15:43:40 -0500 References: X-Mailer: Apple Mail (2.929.2) Cc: simple@ietf.org, Robert Sparks Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============0796573491==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============0796573491== Content-Type: multipart/alternative; boundary=Apple-Mail-2-711368611 --Apple-Mail-2-711368611 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Apologies--I thought I responded to your earlier email, but I can find no evidence that I actually did so. I would still prefer, unless we can site significant technical reasons preventing it, to have a COMEDIA or similar mechanism for the negotiation of connection direction that otherwise uses the MSRP URI path approach. On Sep 12, 2008, at 6:57 AM, Christer Holmberg wrote: > > Hi, > > I've submited a new version of the msrp-acm draft. > > Since nobody indicated on the list (I did ask twice :) that he/she > wants to be able to use only the comedia part of the draft, I > haven't changed that. Instead the draft still specifies the usage of > comedia and the SDP c/m routing, and that allowed me to remove the > a=msrp-acm attribute, since the a=setup attribute is enough to > indicate support of the mechanism in the draft. > > The draft can also be found at: > > (http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm-01.txt > ) > > Regards, > > Christer > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-2-711368611 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Apologies--I thought I = responded to your earlier email, but I can find no evidence that I = actually did so.

I would still prefer, unless = we can site significant technical reasons preventing it, to have a = COMEDIA or similar mechanism for the negotiation of connection direction = that otherwise uses the MSRP URI path = approach.


On Sep 12, 2008, = at 6:57 AM, Christer Holmberg wrote:

=

Hi,

I've = submited a new version of the msrp-acm draft.

Since nobody indicated on the list (I did ask = twice :) that he/she wants to be able to use only the comedia part of = the draft, I haven't changed that. Instead the draft still specifies the = usage of comedia and the SDP c/m routing, and that allowed me to remove = the a=3Dmsrp-acm attribute, since the a=3Dsetup attribute is enough to = indicate support of the mechanism in the draft.

The draft can also be found at: =

(http://users.piuha.net/cholmber/drafts/draft-blau-simple-ms= rp-acm-01.txt) =

Regards,

Christer

= _______________________________________________
Simple mailing = list
Simple@ietf.org
https://www.ietf.or= g/mailman/listinfo/simple

= --Apple-Mail-2-711368611-- --===============0796573491== 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://www.ietf.org/mailman/listinfo/simple --===============0796573491==-- From simple-bounces@ietf.org Thu Sep 18 04:46:56 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E873A6E20; Thu, 18 Sep 2008 04:46:56 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3813A69F5 for ; Thu, 18 Sep 2008 04:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.633 X-Spam-Level: X-Spam-Status: No, score=-5.633 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3yURC7jR608 for ; Thu, 18 Sep 2008 04:46:48 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9CFDA3A6973 for ; Thu, 18 Sep 2008 04:46:47 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8BF88200A5; Thu, 18 Sep 2008 13:46:24 +0200 (CEST) X-AuditID: c1b4fb3e-a9e87bb000007a96-60-48d23f900cfb Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 65F892020D; Thu, 18 Sep 2008 13:46:24 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Sep 2008 13:46:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Sep 2008 13:46:23 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] New version of draft-blau-simple-msrp-acm Thread-Index: AckZBhPaMEz1vzstTWu91aa56X5FuAAT6GYg References: From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 18 Sep 2008 11:46:23.0930 (UTC) FILETIME=[2D11F9A0:01C91984] X-Brightmail-Tracker: AAAAAA== Cc: simple@ietf.org, Robert Sparks Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============0006341992==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0006341992== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C91984.2CEA3626" This is a multi-part message in MIME format. ------_=_NextPart_001_01C91984.2CEA3626 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ben, =20 I cannot think of any technical reason to prevent using only the COMEDIA part. It only means that the a=3Dmsrp-acm attribute has to be put back, since we need an explicit indication for the SDP routing part. =20 Would anyone object to such approach? =20 Regards, =20 Christer ________________________________ From: Ben Campbell [mailto:ben@estacado.net]=20 Sent: 17. syyskuuta 2008 23:44 To: Christer Holmberg Cc: simple@ietf.org; Robert Sparks Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm =09 =09 Apologies--I thought I responded to your earlier email, but I can find no evidence that I actually did so. I would still prefer, unless we can site significant technical reasons preventing it, to have a COMEDIA or similar mechanism for the negotiation of connection direction that otherwise uses the MSRP URI path approach. On Sep 12, 2008, at 6:57 AM, Christer Holmberg wrote: Hi,=20 I've submited a new version of the msrp-acm draft.=20 Since nobody indicated on the list (I did ask twice :) that he/she wants to be able to use only the comedia part of the draft, I haven't changed that. Instead the draft still specifies the usage of comedia and the SDP c/m routing, and that allowed me to remove the a=3Dmsrp-acm attribute, since the a=3Dsetup attribute is enough to = indicate support of the mechanism in the draft. The draft can also be found at:=20 =09 (http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm-01.tx t )=20 Regards,=20 Christer=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple =09 ------_=_NextPart_001_01C91984.2CEA3626 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Ben,
 
I=20 cannot think of any technical reason to prevent using only the COMEDIA = part. It=20 only means that the a=3Dmsrp-acm attribute has to be put back, since we = need an=20 explicit indication for the SDP routing part.
 
Would=20 anyone object to such approach?
 
Regards,
 
Christer

From: Ben Campbell = [mailto:ben@estacado.net]=20
Sent: 17. syyskuuta 2008 23:44
To: Christer=20 Holmberg
Cc: simple@ietf.org; Robert = Sparks
Subject: Re:=20 [Simple] New version of = draft-blau-simple-msrp-acm

Apologies--I thought I responded to your earlier email, but I can = find no=20 evidence that I actually did so.

I would still prefer, unless we can site significant technical = reasons=20 preventing it, to have a COMEDIA or similar mechanism for the = negotiation of=20 connection direction that otherwise uses the MSRP URI path = approach.


On Sep 12, 2008, at 6:57 AM, Christer Holmberg wrote:

Hi,

I've submited a new version of the = msrp-acm=20 draft.

Since nobody indicated on the list (I = did ask=20 twice :) that he/she wants to be able to use only the comedia part = of the=20 draft, I haven't changed that. Instead the draft still specifies the = usage=20 of comedia and the SDP c/m routing, and that allowed me to remove = the=20 a=3Dmsrp-acm attribute, since the a=3Dsetup attribute is enough to = indicate=20 support of the mechanism in the draft.

The draft can also be found = at:

(http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-ac= m-01.txt)

Regards,

Christer=20

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

= ------_=_NextPart_001_01C91984.2CEA3626-- --===============0006341992== 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://www.ietf.org/mailman/listinfo/simple --===============0006341992==-- From simple-bounces@ietf.org Thu Sep 18 17:32:28 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C5E93A69DA; Thu, 18 Sep 2008 17:32:28 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83923A69DA for ; Thu, 18 Sep 2008 17:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhYITSM1dems for ; Thu, 18 Sep 2008 17:32:26 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id B0A983A693C for ; Thu, 18 Sep 2008 17:32:26 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so149053rvf.49 for ; Thu, 18 Sep 2008 17:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=LT0Ete9RLGKPyG63DsUNHFMnQ0Dbp1Fu/V1yAiuYn78=; b=tf2VsC2e7GqO5gEE63uK+nhfT4myox02cY3kZi9UUftDHSNvrllxKs5gj6XW6ldhVg daqpmmzreN0wYu0CQrSDT8FJP6Fi6L1Ah/KyOkoDphxgfKzExyLhEq9iIKKf/ApcioUP 9C+xgAiboRIsp6bgL9jrfGKB9gr47v/Yw8r7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=rIR+OCV/YNxV+ltxb/tS2+dnQOivxIWXRLi1sKScNyqL/w+5QPzfFJ6OX66nEfIbTn MVJdOn4KesVRHlDn60g+VmcgOToT5GgLqzKiCQjKApIIJO0tjz+DnHBseMVum7gYOEJJ EmIag77DZqIzTSLgylhQBQOLASbpIfk12D+DI= Received: by 10.141.137.6 with SMTP id p6mr7996183rvn.279.1221784360213; Thu, 18 Sep 2008 17:32:40 -0700 (PDT) Received: by 10.141.116.8 with HTTP; Thu, 18 Sep 2008 17:32:40 -0700 (PDT) Message-ID: <66cd252f0809181732m299940a8y34264048ff7cf48a@mail.gmail.com> Date: Fri, 19 Sep 2008 10:32:40 +1000 From: "Hisham Khartabil" To: "Christer Holmberg" In-Reply-To: MIME-Version: 1.0 References: Cc: simple@ietf.org, Robert Sparks Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============0544087830==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============0544087830== Content-Type: multipart/alternative; boundary="----=_Part_35927_5922781.1221784360212" ------=_Part_35927_5922781.1221784360212 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't believe we want 2 mechanisms to a path between the 2 parties. What Ben is saying that is we can use the COMEDIA mechanism to determine the path, but not necessarily the SDP extensions used for comedia. The path is then communicated between the 2 parties using the existing MSRP SDP extensions. Regards, Hisham On 18/09/2008, Christer Holmberg wrote: > > Hi Ben, > > I cannot think of any technical reason to prevent using only the COMEDIA > part. It only means that the a=msrp-acm attribute has to be put back, since > we need an explicit indication for the SDP routing part. > > Would anyone object to such approach? > > Regards, > > Christer > > ------------------------------ > *From:* Ben Campbell [mailto:ben@estacado.net] > *Sent:* 17. syyskuuta 2008 23:44 > *To:* Christer Holmberg > *Cc:* simple@ietf.org; Robert Sparks > *Subject:* Re: [Simple] New version of draft-blau-simple-msrp-acm > > > Apologies--I thought I responded to your earlier email, but I can find no > evidence that I actually did so. > > > I would still prefer, unless we can site significant technical reasons > preventing it, to have a COMEDIA or similar mechanism for the negotiation of > connection direction that otherwise uses the MSRP URI path approach. > > > > > On Sep 12, 2008, at 6:57 AM, Christer Holmberg wrote: > > > Hi, > > I've submited a new version of the msrp-acm draft. > > Since nobody indicated on the list (I did ask twice :) that he/she wants to > be able to use only the comedia part of the draft, I haven't changed that. > Instead the draft still specifies the usage of comedia and the SDP c/m > routing, and that allowed me to remove the a=msrp-acm attribute, since the > a=setup attribute is enough to indicate support of the mechanism in the > draft. > > The draft can also be found at: > > (*http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm-01.txt > * > ) > > Regards, > > Christer > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > > ------=_Part_35927_5922781.1221784360212 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I don't believe we want 2 mechanisms to a path between the 2 parties. What Ben is saying that is we can use the COMEDIA mechanism to determine the path, but not necessarily the SDP extensions used for comedia. The path is then communicated between the 2 parties using the existing MSRP SDP extensions.
 
Regards,
Hisham

 
On 18/09/2008, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi Ben,
 
I cannot think of any technical reason to prevent using only the COMEDIA part. It only means that the a=msrp-acm attribute has to be put back, since we need an explicit indication for the SDP routing part.
 
Would anyone object to such approach?
 
Regards,
 
Christer

From: Ben Campbell [mailto:ben@estacado.net]
Sent: 17. syyskuuta 2008 23:44
To: Christer Holmberg
Cc: simple@ietf.org; Robert Sparks
Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm

 
Apologies--I thought I responded to your earlier email, but I can find no evidence that I actually did so.

 
I would still prefer, unless we can site significant technical reasons preventing it, to have a COMEDIA or similar mechanism for the negotiation of connection direction that otherwise uses the MSRP URI path approach.

 

 
On Sep 12, 2008, at 6:57 AM, Christer Holmberg wrote:


Hi,

I've submited a new version of the msrp-acm draft.

Since nobody indicated on the list (I did ask twice :) that he/she wants to be able to use only the comedia part of the draft, I haven't changed that. Instead the draft still specifies the usage of comedia and the SDP c/m routing, and that allowed me to remove the a=msrp-acm attribute, since the a=setup attribute is enough to indicate support of the mechanism in the draft.

The draft can also be found at:

(http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm-01.txt)

Regards,

Christer

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


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


------=_Part_35927_5922781.1221784360212-- --===============0544087830== 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://www.ietf.org/mailman/listinfo/simple --===============0544087830==-- From simple-bounces@ietf.org Thu Sep 18 18:51:51 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A727F3A6CAE; Thu, 18 Sep 2008 18:51:51 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011B73A6BF8 for ; Thu, 18 Sep 2008 18:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Wl40+neyfnp for ; Thu, 18 Sep 2008 18:51:34 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 12D8E3A6CAE for ; Thu, 18 Sep 2008 18:51:33 -0700 (PDT) Received: from [10.0.1.194] (adsl-68-94-39-110.dsl.rcsntx.swbell.net [68.94.39.110]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m8J1pWTs027194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Sep 2008 20:51:37 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <1C32F490-8450-446E-86FC-BA1EF59FAD49@estacado.net> From: Ben Campbell To: "Hisham Khartabil" In-Reply-To: <66cd252f0809181732m299940a8y34264048ff7cf48a@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 18 Sep 2008 20:51:34 -0500 References: <66cd252f0809181732m299940a8y34264048ff7cf48a@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: simple@ietf.org, Robert Sparks Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============1047005078==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1047005078== Content-Type: multipart/alternative; boundary=Apple-Mail-8-816241949 --Apple-Mail-8-816241949 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I suspect Hisham meant to say to use COMEDIA to "determine the connection direction" rather than "determine the path". If I am correct, then he has summarized my opinion perfectly. On Sep 18, 2008, at 7:32 PM, Hisham Khartabil wrote: > I don't believe we want 2 mechanisms to a path between the 2 > parties. What Ben is saying that is we can use the COMEDIA mechanism > to determine the path, but not necessarily the SDP extensions used > for comedia. The path is then communicated between the 2 parties > using the existing MSRP SDP extensions. > > Regards, > Hisham > > > On 18/09/2008, Christer Holmberg > wrote: > Hi Ben, > > I cannot think of any technical reason to prevent using only the > COMEDIA part. It only means that the a=msrp-acm attribute has to be > put back, since we need an explicit indication for the SDP routing > part. > > Would anyone object to such approach? > > Regards, > > Christer > > From: Ben Campbell [mailto:ben@estacado.net] > Sent: 17. syyskuuta 2008 23:44 > To: Christer Holmberg > Cc: simple@ietf.org; Robert Sparks > Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm > > > Apologies--I thought I responded to your earlier email, but I can > find no evidence that I actually did so. > > > I would still prefer, unless we can site significant technical > reasons preventing it, to have a COMEDIA or similar mechanism for > the negotiation of connection direction that otherwise uses the MSRP > URI path approach. > > > > > On Sep 12, 2008, at 6:57 AM, Christer Holmberg wrote: > >> >> Hi, >> >> I've submited a new version of the msrp-acm draft. >> >> Since nobody indicated on the list (I did ask twice :) that he/she >> wants to be able to use only the comedia part of the draft, I >> haven't changed that. Instead the draft still specifies the usage >> of comedia and the SDP c/m routing, and that allowed me to remove >> the a=msrp-acm attribute, since the a=setup attribute is enough to >> indicate support of the mechanism in the draft. >> >> The draft can also be found at: >> >> (http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm-01.txt >> ) >> >> Regards, >> >> Christer >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > > --Apple-Mail-8-816241949 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
I suspect Hisham meant to = say to use COMEDIA to  "determine the connection direction" rather = than "determine the path". If I am correct, then he has summarized my = opinion perfectly.

On Sep 18, 2008, at 7:32 PM, = Hisham Khartabil wrote:

I = don't believe we want 2 mechanisms to a path between the 2 parties. What = Ben is saying that is we can use the COMEDIA mechanism to determine the = path, but not necessarily the SDP extensions used for comedia. The = path is then communicated between the 2 parties using the existing = MSRP SDP extensions.
 
Regards,
=
Hisham

 
On = 18/09/2008, Christer Holmberg <christer.holmberg@ericsson.= com> wrote:
Hi Ben,
=
 
I cannot think of any technical reason to = prevent using only the COMEDIA part. It only means that the a=3Dmsrp-acm = attribute has to be put back, since we need an explicit indication for = the SDP routing part.
 
Would anyone object to such = approach?
 
Regards,
=
 
Christer

=
From: Ben = Campbell [mailto:ben@estacado.net]
Sent: 17. syyskuuta = 2008 23:44
To: Christer Holmberg
Cc: simple@ietf.org; = Robert Sparks
Subject: Re: [Simple] New version of = draft-blau-simple-msrp-acm

 
Apologies--I = thought I responded to your earlier email, but I can find no evidence = that I actually did so.

 
I would still = prefer, unless we can site significant technical reasons preventing it, = to have a COMEDIA or similar mechanism for the negotiation of connection = direction that otherwise uses the MSRP URI path approach.
=

 

 
On Sep 12, 2008, = at 6:57 AM, Christer Holmberg wrote:

=

Hi,

I've submited a new version of the msrp-acm = draft.

Since nobody = indicated on the list (I did ask twice :) that he/she wants to be able = to use only the comedia part of the draft, I haven't changed that. = Instead the draft still specifies the usage of comedia and the SDP c/m = routing, and that allowed me to remove the a=3Dmsrp-acm attribute, since = the a=3Dsetup attribute is enough to indicate support of the mechanism = in the draft.

The draft can = also be found at:

(http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-a= cm-01.txt) =

Regards,

Christer =

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

=

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


= --Apple-Mail-8-816241949-- --===============1047005078== 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://www.ietf.org/mailman/listinfo/simple --===============1047005078==-- From simple-bounces@ietf.org Thu Sep 18 21:38:54 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E1428C102; Thu, 18 Sep 2008 21:38:54 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5026C28C102 for ; Thu, 18 Sep 2008 21:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.635 X-Spam-Level: X-Spam-Status: No, score=-5.635 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkM1+4eM9goz for ; Thu, 18 Sep 2008 21:38:51 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1D7033A6844 for ; Thu, 18 Sep 2008 21:38:50 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B23DF205AA; Fri, 19 Sep 2008 06:39:04 +0200 (CEST) X-AuditID: c1b4fb3c-aa8c7bb0000015b5-a3-48d32ce818c1 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9848220453; Fri, 19 Sep 2008 06:39:04 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Sep 2008 06:39:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Sep 2008 06:39:00 +0200 Message-ID: In-Reply-To: <1C32F490-8450-446E-86FC-BA1EF59FAD49@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] New version of draft-blau-simple-msrp-acm Thread-Index: AckZ+kkeYtysz+BeQ1WWrzyxSSgNegAFqUxA References: <66cd252f0809181732m299940a8y34264048ff7cf48a@mail.gmail.com> <1C32F490-8450-446E-86FC-BA1EF59FAD49@estacado.net> From: "Christer Holmberg" To: "Ben Campbell" , "Hisham Khartabil" X-OriginalArrivalTime: 19 Sep 2008 04:39:03.0999 (UTC) FILETIME=[A4E4BCF0:01C91A11] X-Brightmail-Tracker: AAAAAA== Cc: simple@ietf.org, Robert Sparks Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, >I suspect Hisham meant to say to use COMEDIA to "determine the connection direction" rather than "determine the path". If I am correct, then he has summarized my opinion perfectly. I think that is what I am trying to say also: COMEDIA is used to determine the TCP connection direction. The SDP c/m/a=msrp-acm method, OR the existing MSRP URI method, is then used for the actual routing of the MSRP messages. Regards, Christer On Sep 18, 2008, at 7:32 PM, Hisham Khartabil wrote: I don't believe we want 2 mechanisms to a path between the 2 parties. What Ben is saying that is we can use the COMEDIA mechanism to determine the path, but not necessarily the SDP extensions used for comedia. The path is then communicated between the 2 parties using the existing MSRP SDP extensions. Regards, Hisham On 18/09/2008, Christer Holmberg wrote: Hi Ben, I cannot think of any technical reason to prevent using only the COMEDIA part. It only means that the a=msrp-acm attribute has to be put back, since we need an explicit indication for the SDP routing part. Would anyone object to such approach? Regards, Christer ________________________________ From: Ben Campbell [mailto:ben@estacado.net] Sent: 17. syyskuuta 2008 23:44 To: Christer Holmberg Cc: simple@ietf.org; Robert Sparks Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm Apologies--I thought I responded to your earlier email, but I can find no evidence that I actually did so. I would still prefer, unless we can site significant technical reasons preventing it, to have a COMEDIA or similar mechanism for the negotiation of connection direction that otherwise uses the MSRP URI path approach. On Sep 12, 2008, at 6:57 AM, Christer Holmberg wrote: Hi, I've submited a new version of the msrp-acm draft. Since nobody indicated on the list (I did ask twice :) that he/she wants to be able to use only the comedia part of the draft, I haven't changed that. Instead the draft still specifies the usage of comedia and the SDP c/m routing, and that allowed me to remove the a=msrp-acm attribute, since the a=setup attribute is enough to indicate support of the mechanism in the draft. The draft can also be found at: (http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm-01.tx t ) Regards, Christer _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 18 21:55:16 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9413A69BF; Thu, 18 Sep 2008 21:55:16 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FAE03A67F4 for ; Thu, 18 Sep 2008 21:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjYWgRQR-Mp1 for ; Thu, 18 Sep 2008 21:55:13 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 3FD683A69BF for ; Thu, 18 Sep 2008 21:55:13 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so230048rvf.49 for ; Thu, 18 Sep 2008 21:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=dkMPwUhX0K30o9TFLISdoBj35BuK6FThishBj9L9WT0=; b=CHdYENRtbu/uKGoaS0Gdwf77PyXzyu2CbXzy+hCxSlMzjUHm0fjsTJZG3ONYIVjjnY johfGN2YciTtRIhPhOJA0IRTQipjNRNrhzF0oza8FJqEBmgwG8MI7u1MUdFPcBraRSpt NtQuzh9EPC9vAd6LkhpKl9srkxDwpBC3ZknVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=LW09edbvqzRwjU5Qjx6putw1FKzgHKyPKayUSz+TlyY7I7yShtvqP4IMCLapC1YL3N 7cHNEH5fgx1Di5SuiDBtas7oo3RccoFcRdZzpgp2Bg1NIaZLv8+i6KYXIf3OFGmueFo8 ReO+dDpwDK80edZmjoVJuGX5MQSWniXh9h0Io= Received: by 10.140.201.15 with SMTP id y15mr8138037rvf.145.1221800127349; Thu, 18 Sep 2008 21:55:27 -0700 (PDT) Received: by 10.141.116.8 with HTTP; Thu, 18 Sep 2008 21:55:27 -0700 (PDT) Message-ID: <66cd252f0809182155j1fe157fcp6573ea68ff10711e@mail.gmail.com> Date: Fri, 19 Sep 2008 14:55:27 +1000 From: "Hisham Khartabil" To: "Christer Holmberg" In-Reply-To: MIME-Version: 1.0 References: <66cd252f0809181732m299940a8y34264048ff7cf48a@mail.gmail.com> <1C32F490-8450-446E-86FC-BA1EF59FAD49@estacado.net> Cc: simple@ietf.org, Robert Sparks Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============1873207244==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1873207244== Content-Type: multipart/alternative; boundary="----=_Part_37704_18166753.1221800127336" ------=_Part_37704_18166753.1221800127336 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline No OR. COMEDIA is used to determine the TCP connection direction. The existing MSRP URI method, is then used for the actual routing of the MSRP messages. Hisham On 19/09/2008, Christer Holmberg wrote: > > > Hi, > > >I suspect Hisham meant to say to use COMEDIA to "determine the > connection direction" rather than "determine the path". If I am correct, > then he has summarized my opinion perfectly. > > I think that is what I am trying to say also: COMEDIA is used to > determine the TCP connection direction. The SDP c/m/a=msrp-acm method, > OR the existing MSRP URI method, is then used for the actual routing of > the MSRP messages. > > Regards, > > Christer > > > > > > > On Sep 18, 2008, at 7:32 PM, Hisham Khartabil wrote: > > > I don't believe we want 2 mechanisms to a path between > the 2 parties. What Ben is saying that is we can use the COMEDIA > mechanism to determine the path, but not necessarily the SDP extensions > used for comedia. The path is then communicated between the 2 parties > using the existing MSRP SDP extensions. > > Regards, > Hisham > > > On 18/09/2008, Christer Holmberg > wrote: > > Hi Ben, > > I cannot think of any technical reason to > prevent using only the COMEDIA part. It only means that the a=msrp-acm > attribute has to be put back, since we need an explicit indication for > the SDP routing part. > > Would anyone object to such approach? > > Regards, > > Christer > > > ________________________________ > > From: Ben Campbell > [mailto:ben@estacado.net] > Sent: 17. syyskuuta 2008 23:44 > To: Christer Holmberg > Cc: simple@ietf.org; Robert Sparks > Subject: Re: [Simple] New version of > draft-blau-simple-msrp-acm > > > > Apologies--I thought I responded to your earlier email, but I can find > no evidence that I actually did so. > > > I would still prefer, unless we can site > significant technical reasons preventing it, to have a COMEDIA or > similar mechanism for the negotiation of connection direction that > otherwise uses the MSRP URI path approach. > > > > > On Sep 12, 2008, at 6:57 AM, Christer > Holmberg wrote: > > > > Hi, > > I've submited a new version of > the msrp-acm draft. > > Since nobody indicated on the > list (I did ask twice :) that he/she wants to be able to use only the > comedia part of the draft, I haven't changed that. Instead the draft > still specifies the usage of comedia and the SDP c/m routing, and that > allowed me to remove the a=msrp-acm attribute, since the a=setup > attribute is enough to indicate support of the mechanism in the draft. > > The draft can also be found at: > > > (http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm-01.tx > t > t> ) > > Regards, > > Christer > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > > > > > > ------=_Part_37704_18166753.1221800127336 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
No OR. COMEDIA is used to determine the TCP connection direction. The existing MSRP URI method, is then used for the actual routing of
the MSRP messages.
 
Hisham

 
On 19/09/2008, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

>I suspect Hisham meant to say to use COMEDIA to  "determine the
connection direction" rather than "determine the path". If I am correct,
then he has summarized my opinion perfectly.

I think that is what I am trying to say also: COMEDIA is used to
determine the TCP connection direction. The SDP c/m/a=msrp-acm method,
OR the existing MSRP URI method, is then used for the actual routing of
the MSRP messages.

Regards,

Christer






       On Sep 18, 2008, at 7:32 PM, Hisham Khartabil wrote:


               I don't believe we want 2 mechanisms to a path between
the 2 parties. What Ben is saying that is we can use the COMEDIA
mechanism to determine the path, but not necessarily the SDP extensions
used for comedia. The path is then communicated between the 2 parties
using the existing MSRP SDP extensions.

               Regards,
               Hisham


               On 18/09/2008, Christer Holmberg
<christer.holmberg@ericsson.com> wrote:

                       Hi Ben,

                       I cannot think of any technical reason to
prevent using only the COMEDIA part. It only means that the a=msrp-acm
attribute has to be put back, since we need an explicit indication for
the SDP routing part.

                       Would anyone object to such approach?

                       Regards,

                       Christer


________________________________

                               From: Ben Campbell
[mailto:ben@estacado.net]
                               Sent: 17. syyskuuta 2008 23:44
                               To: Christer Holmberg
                               Cc: simple@ietf.org; Robert Sparks
                               Subject: Re: [Simple] New version of
draft-blau-simple-msrp-acm



Apologies--I thought I responded to your earlier email, but I can find
no evidence that I actually did so.


                               I would still prefer, unless we can site
significant technical reasons preventing it, to have a COMEDIA or
similar mechanism for the negotiation of connection direction that
otherwise uses the MSRP URI path approach.




                               On Sep 12, 2008, at 6:57 AM, Christer
Holmberg wrote:



                                       Hi,

                                       I've submited a new version of
the msrp-acm draft.

                                       Since nobody indicated on the
list (I did ask twice :) that he/she wants to be able to use only the
comedia part of the draft, I haven't changed that. Instead the draft
still specifies the usage of comedia and the SDP c/m routing, and that
allowed me to remove the a=msrp-acm attribute, since the a=setup
attribute is enough to indicate support of the mechanism in the draft.

                                       The draft can also be found at:


(http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm-01.tx
t
<http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm-01.tx
t> )

                                       Regards,

                                       Christer


_______________________________________________
                                       Simple mailing list
                                       Simple@ietf.org

https://www.ietf.org/mailman/listinfo/simple




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






------=_Part_37704_18166753.1221800127336-- --===============1873207244== 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://www.ietf.org/mailman/listinfo/simple --===============1873207244==-- From simple-bounces@ietf.org Thu Sep 18 22:11:59 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715BD3A680C; Thu, 18 Sep 2008 22:11:59 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1093A680C for ; Thu, 18 Sep 2008 22:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.635 X-Spam-Level: X-Spam-Status: No, score=-5.635 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4H6oaVyyumeg for ; Thu, 18 Sep 2008 22:11:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4C8483A67B6 for ; Thu, 18 Sep 2008 22:11:56 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 22B2F20516; Fri, 19 Sep 2008 07:12:10 +0200 (CEST) X-AuditID: c1b4fb3c-af8d1bb0000015b5-0f-48d334a9c46d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DB81D203F1; Fri, 19 Sep 2008 07:12:09 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Sep 2008 07:12:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Sep 2008 07:12:09 +0200 Message-ID: In-Reply-To: <66cd252f0809182155j1fe157fcp6573ea68ff10711e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] New version of draft-blau-simple-msrp-acm Thread-Index: AckaE/Ar9r3ARvksTRmekewjq73XdAAAifzw References: <66cd252f0809181732m299940a8y34264048ff7cf48a@mail.gmail.com> <1C32F490-8450-446E-86FC-BA1EF59FAD49@estacado.net> <66cd252f0809182155j1fe157fcp6573ea68ff10711e@mail.gmail.com> From: "Christer Holmberg" To: "Hisham Khartabil" X-OriginalArrivalTime: 19 Sep 2008 05:12:09.0391 (UTC) FILETIME=[444783F0:01C91A16] X-Brightmail-Tracker: AAAAAA== Cc: simple@ietf.org, Robert Sparks Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============0070528051==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0070528051== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C91A16.443987F8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C91A16.443987F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Yes OR. The new routing method MAY be used, but one can also choose to use the existing method. =20 I don't thin Ben ever said one MUST use the existing method, but that it should be allowed to use the existing method. =20 Regards, =20 Christer ________________________________ From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com]=20 Sent: 19. syyskuuta 2008 7:55 To: Christer Holmberg Cc: Ben Campbell; simple@ietf.org; Robert Sparks Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm =09 =09 No OR. COMEDIA is used to determine the TCP connection direction. The existing MSRP URI method, is then used for the actual routing of the MSRP messages. =20 Hisham =09 =20 On 19/09/2008, Christer Holmberg wrote:=20 Hi, =09 >I suspect Hisham meant to say to use COMEDIA to "determine the connection direction" rather than "determine the path". If I am correct, then he has summarized my opinion perfectly. =09 I think that is what I am trying to say also: COMEDIA is used to determine the TCP connection direction. The SDP c/m/a=3Dmsrp-acm method, OR the existing MSRP URI method, is then used for the actual routing of the MSRP messages. =09 Regards, =09 Christer =09 =09 =09 =09 =09 =09 On Sep 18, 2008, at 7:32 PM, Hisham Khartabil wrote: =09 =09 I don't believe we want 2 mechanisms to a path between the 2 parties. What Ben is saying that is we can use the COMEDIA mechanism to determine the path, but not necessarily the SDP extensions used for comedia. The path is then communicated between the 2 parties using the existing MSRP SDP extensions. =09 Regards, Hisham =09 =09 On 18/09/2008, Christer Holmberg wrote: =09 Hi Ben, =09 I cannot think of any technical reason to prevent using only the COMEDIA part. It only means that the a=3Dmsrp-acm attribute has to be put back, since we need an explicit indication for the SDP routing part. =09 Would anyone object to such approach? =09 Regards, =09 Christer =09 =09 ________________________________ =09 From: Ben Campbell [mailto:ben@estacado.net] Sent: 17. syyskuuta 2008 23:44 To: Christer Holmberg Cc: simple@ietf.org; Robert Sparks Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm =09 =09 =09 Apologies--I thought I responded to your earlier email, but I can find no evidence that I actually did so. =09 =09 I would still prefer, unless we can site significant technical reasons preventing it, to have a COMEDIA or similar mechanism for the negotiation of connection direction that otherwise uses the MSRP URI path approach. =09 =09 =09 =09 On Sep 12, 2008, at 6:57 AM, Christer Holmberg wrote: =09 =09 =09 Hi, =09 I've submited a new version of the msrp-acm draft. =09 Since nobody indicated on the list (I did ask twice :) that he/she wants to be able to use only the comedia part of the draft, I haven't changed that. Instead the draft still specifies the usage of comedia and the SDP c/m routing, and that allowed me to remove the a=3Dmsrp-acm attribute, since the a=3Dsetup attribute is enough to indicate support of the mechanism in the draft. =09 The draft can also be found at: =09 =09 =09 (http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm-01.tx t =09 ) =09 Regards, =09 Christer =09 =09 _______________________________________________ Simple mailing list Simple@ietf.org =09 https://www.ietf.org/mailman/listinfo/simple =09 =09 =09 =09 =09 _______________________________________________ Simple mailing list Simple@ietf.org =09 https://www.ietf.org/mailman/listinfo/simple =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C91A16.443987F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Yes=20 OR. The new routing method MAY be used, but one can also choose to use = the=20 existing method.
 
I=20 don't thin Ben ever said one MUST use the existing method, but that it = should be=20 allowed to use the existing method.
 
Regards,
 
Christer

From: Hisham Khartabil=20 [mailto:hisham.khartabil@gmail.com]
Sent: 19. syyskuuta = 2008=20 7:55
To: Christer Holmberg
Cc: Ben Campbell;=20 simple@ietf.org; Robert Sparks
Subject: Re: [Simple] New = version of=20 draft-blau-simple-msrp-acm

No OR. COMEDIA is used to determine the TCP connection direction. = The=20 existing MSRP URI method, is then used for the actual routing = of
the MSRP=20 messages.
 
Hisham

 
On 19/09/2008, Christer=20 Holmberg <christer.holmberg@ericsson= .com>=20 wrote:=20

Hi,

>I=20 suspect Hisham meant to say to use COMEDIA to  "determine=20 the
connection direction" rather than "determine the path". If I = am=20 correct,
then he has summarized my opinion perfectly.

I = think that=20 is what I am trying to say also: COMEDIA is used to
determine the = TCP=20 connection direction. The SDP c/m/a=3Dmsrp-acm method,
OR the = existing MSRP=20 URI method, is then used for the actual routing of
the MSRP=20 = messages.

Regards,

Christer






&nbs= p;     =20 On Sep 18, 2008, at 7:32 PM, Hisham Khartabil=20 = wrote:


         &= nbsp;    =20 I don't believe we want 2 mechanisms to a path between
the 2 = parties.=20 What Ben is saying that is we can use the COMEDIA
mechanism to = determine=20 the path, but not necessarily the SDP extensions
used for = comedia. The=20 path is then communicated between the 2 parties
using the = existing MSRP=20 SDP=20 = extensions.

         =      =20 = Regards,
          &= nbsp;   =20 = Hisham


         &= nbsp;    =20 On 18/09/2008, Christer Holmberg
<christer.holmberg@ericsson= .com>=20 = wrote:

          = ;            = =20 Hi=20 = Ben,

          &= nbsp;           =20 I cannot think of any technical reason to
prevent using only the = COMEDIA=20 part. It only means that the a=3Dmsrp-acm
attribute has to be put = back,=20 since we need an explicit indication for
the SDP routing=20 = part.

          =              = Would anyone object to such=20 = approach?

         &n= bsp;           &nb= sp;=20 = Regards,

         &nb= sp;           &nbs= p;=20 = Christer


________________________________

  &= nbsp;           &n= bsp;           &nb= sp;   =20 From: Ben Campbell
[mailto:ben@estacado.net]
  &nb= sp;           &nbs= p;            = ;   =20 Sent: 17. syyskuuta 2008=20 = 23:44
          &nbs= p;            = ;       =20 To: Christer=20 = Holmberg
          &= nbsp;           &n= bsp;       =20 Cc: simple@ietf.org; Robert=20 = Sparks
          &nb= sp;           &nbs= p;       =20 Subject: Re: [Simple] New version=20 of
draft-blau-simple-msrp-acm



Apologies--I thought = I=20 responded to your earlier email, but I can find
no evidence that = I=20 actually did=20 = so.


         &nbs= p;            = ;        =20 I would still prefer, unless we can site
significant technical = reasons=20 preventing it, to have a COMEDIA or
similar mechanism for the = negotiation=20 of connection direction that
otherwise uses the MSRP URI path=20 = approach.




       &n= bsp;           &nb= sp;          =20 On Sep 12, 2008, at 6:57 AM, Christer
Holmberg=20 = wrote:



        &nb= sp;           &nbs= p;            = ;     =20 = Hi,

          &n= bsp;           &nb= sp;           &nbs= p;   =20 I've submited a new version of
the msrp-acm=20 = draft.

          = ;            =             &= nbsp;   =20 Since nobody indicated on the
list (I did ask twice :) that = he/she wants=20 to be able to use only the
comedia part of the draft, I haven't = changed=20 that. Instead the draft
still specifies the usage of comedia and = the SDP=20 c/m routing, and that
allowed me to remove the a=3Dmsrp-acm = attribute,=20 since the a=3Dsetup
attribute is enough to indicate support of = the=20 mechanism in the=20 = draft.

          = ;            =             &= nbsp;   =20 The draft can also be found at:


(http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm= -01.tx
t
<http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm= -01.tx
t>=20 = )

          &nbs= p;            = ;            =    =20 = Regards,

         &nb= sp;           &nbs= p;            = ;    =20 = Christer


_______________________________________________
&n= bsp;           &nb= sp;           &nbs= p;            = ; =20 Simple mailing=20 = list
           = ;            =             &= nbsp;  =20 Simple@ietf.org

https://www.ietf.or= g/mailman/listinfo/simple




    =             &= nbsp;     =20 = _______________________________________________
   &nbs= p;            = ;      =20 Simple mailing=20 = list
           = ;           =20 Simple@ietf.org
   =             &= nbsp;      =20 https://www.ietf.or= g/mailman/listinfo/simple





<= BR> ------_=_NextPart_001_01C91A16.443987F8-- --===============0070528051== 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://www.ietf.org/mailman/listinfo/simple --===============0070528051==-- From simple-bounces@ietf.org Fri Sep 19 06:18:59 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10453A698B; Fri, 19 Sep 2008 06:18:59 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15DBB3A69BD for ; Fri, 19 Sep 2008 06:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SqygMqOeiH4 for ; Fri, 19 Sep 2008 06:18:56 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id B9DDC3A67F8 for ; Fri, 19 Sep 2008 06:18:55 -0700 (PDT) Received: from [10.0.1.194] (adsl-68-94-39-110.dsl.rcsntx.swbell.net [68.94.39.110]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m8JDIvDT031403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Sep 2008 08:19:02 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: Christer Holmberg In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 19 Sep 2008 08:19:00 -0500 References: <66cd252f0809181732m299940a8y34264048ff7cf48a@mail.gmail.com> <1C32F490-8450-446E-86FC-BA1EF59FAD49@estacado.net> <66cd252f0809182155j1fe157fcp6573ea68ff10711e@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: simple@ietf.org, Robert Sparks Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============0698881179==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============0698881179== Content-Type: multipart/alternative; boundary=Apple-Mail-2-857488229 --Apple-Mail-2-857488229 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit To clarify my position: I very much prefer to be able to use the existing method. I also prefer, but not quite as strongly, not to have two methods. On Sep 19, 2008, at 12:12 AM, Christer Holmberg wrote: > > Yes OR. The new routing method MAY be used, but one can also choose > to use the existing method. > > I don't thin Ben ever said one MUST use the existing method, but > that it should be allowed to use the existing method. > To clarify my position: I very much prefer to be able to use the existing method. I also prefer, but not _quite_ as strongly, not to have two methods. > > Regards, > > Christer > > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > Sent: 19. syyskuuta 2008 7:55 > To: Christer Holmberg > Cc: Ben Campbell; simple@ietf.org; Robert Sparks > Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm > > No OR. COMEDIA is used to determine the TCP connection direction. > The existing MSRP URI method, is then used for the actual routing of > the MSRP messages. > > Hisham > > > On 19/09/2008, Christer Holmberg > wrote: > > Hi, > > >I suspect Hisham meant to say to use COMEDIA to "determine the > connection direction" rather than "determine the path". If I am > correct, > then he has summarized my opinion perfectly. > > I think that is what I am trying to say also: COMEDIA is used to > determine the TCP connection direction. The SDP c/m/a=msrp-acm method, > OR the existing MSRP URI method, is then used for the actual routing > of > the MSRP messages. > > Regards, > > Christer > > > > > > > On Sep 18, 2008, at 7:32 PM, Hisham Khartabil wrote: > > > I don't believe we want 2 mechanisms to a path between > the 2 parties. What Ben is saying that is we can use the COMEDIA > mechanism to determine the path, but not necessarily the SDP > extensions > used for comedia. The path is then communicated between the 2 parties > using the existing MSRP SDP extensions. > > Regards, > Hisham > > > On 18/09/2008, Christer Holmberg > wrote: > > Hi Ben, > > I cannot think of any technical reason to > prevent using only the COMEDIA part. It only means that the a=msrp-acm > attribute has to be put back, since we need an explicit indication for > the SDP routing part. > > Would anyone object to such approach? > > Regards, > > Christer > > > ________________________________ > > From: Ben Campbell > [mailto:ben@estacado.net] > Sent: 17. syyskuuta 2008 23:44 > To: Christer Holmberg > Cc: simple@ietf.org; Robert Sparks > Subject: Re: [Simple] New version of > draft-blau-simple-msrp-acm > > > > Apologies--I thought I responded to your earlier email, but I can find > no evidence that I actually did so. > > > I would still prefer, unless we can > site > significant technical reasons preventing it, to have a COMEDIA or > similar mechanism for the negotiation of connection direction that > otherwise uses the MSRP URI path approach. > > > > > On Sep 12, 2008, at 6:57 AM, Christer > Holmberg wrote: > > > > Hi, > > I've submited a new version of > the msrp-acm draft. > > Since nobody indicated on the > list (I did ask twice :) that he/she wants to be able to use only the > comedia part of the draft, I haven't changed that. Instead the draft > still specifies the usage of comedia and the SDP c/m routing, and that > allowed me to remove the a=msrp-acm attribute, since the a=setup > attribute is enough to indicate support of the mechanism in the draft. > > The draft can also be found at: > > > (http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm-01.tx > t > t> ) > > Regards, > > Christer > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > > > > > > --Apple-Mail-2-857488229 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
To clarify my = position:

I very much prefer to be able to use = the existing method. I also prefer, but not quite as strongly, not to = have two methods.

On Sep 19, 2008, at 12:12 AM, = Christer Holmberg wrote:

=
 
=
Yes OR. The new routing method MAY be used, = but one can also choose to use the existing method.
=
 
I don't thin Ben ever said one MUST use the existing method, = but that it should be allowed to use the existing = method.


=
To clarify my position:

I very much prefer = to be able to use the existing method. I also prefer, but not _quite_ as = strongly, not to have two = methods.


 
Regards,
 
Christer

From: Hisham Khartabil [mailto:hisham.khartabil@gmail.c= om]
Sent: 19. syyskuuta 2008 7:55
To: = Christer Holmberg
Cc: Ben Campbell; simple@ietf.org; Robert = Sparks
Subject: Re: [Simple] New version of = draft-blau-simple-msrp-acm

No = OR. COMEDIA is used to determine the TCP connection direction. The = existing MSRP URI method, is then used for the actual routing of
the = MSRP messages.
 
=
Hisham

 
On = 19/09/2008, Christer Holmberg <christer.holmberg@ericsson.= com> wrote:

Hi,

>I suspect Hisham meant to say to use = COMEDIA to  "determine the
connection direction" rather = than "determine the path". If I am correct,
then he has = summarized my opinion perfectly.

I think that is what I am = trying to say also: COMEDIA is used to
determine the TCP = connection direction. The SDP c/m/a=3Dmsrp-acm method,
OR the = existing MSRP URI method, is then used for the actual routing = of
the MSRP = messages.

Regards,

Christer






 = ;      On Sep 18, 2008, at 7:32 PM, Hisham = Khartabil = wrote:


         &n= bsp;     I don't believe we want 2 mechanisms to = a path between
the 2 parties. What Ben is saying that is we can = use the COMEDIA
mechanism to determine the path, but not = necessarily the SDP extensions
used for comedia. The path is then = communicated between the 2 parties
using the existing MSRP SDP = = extensions.

         &= nbsp;     = Regards,
          &n= bsp;    = Hisham


         &n= bsp;     On 18/09/2008, Christer = Holmberg
<christer.holmberg@ericsson.= com> = wrote:

          =              = Hi = Ben,

          &n= bsp;            = I cannot think of any technical reason to
prevent using only the = COMEDIA part. It only means that the a=3Dmsrp-acm
attribute has = to be put back, since we need an explicit indication for
the SDP = routing = part.

          &= nbsp;            = Would anyone object to such = approach?

         &nb= sp;            = ; = Regards,

         &nbs= p;            = = Christer


________________________________

  &n= bsp;           &nbs= p;            =     From: Ben Campbell
[mailto:ben@estacado.net]
  &nbs= p;            =             &n= bsp;   Sent: 17. syyskuuta 2008 = 23:44
           = ;            &= nbsp;       To: Christer = Holmberg
          &n= bsp;           &nbs= p;        Cc: simple@ietf.org; Robert = Sparks
          &nbs= p;            =         Subject: Re: [Simple] New = version of
draft-blau-simple-msrp-acm



Apologies--I = thought I responded to your earlier email, but I can find
no = evidence that I actually did = so.


          = ;            &= nbsp;        I would still = prefer, unless we can site
significant technical reasons = preventing it, to have a COMEDIA or
similar mechanism for the = negotiation of connection direction that
otherwise uses the MSRP = URI path = approach.




       &nb= sp;            = ;           On Sep = 12, 2008, at 6:57 AM, Christer
Holmberg = wrote:



        &nbs= p;            =             &n= bsp;     = Hi,

          &nb= sp;            = ;            &= nbsp;   I've submited a new version of
the msrp-acm = draft.

          =             &n= bsp;           &nbs= p;    Since nobody indicated on the
list (I did = ask twice :) that he/she wants to be able to use only the
comedia = part of the draft, I haven't changed that. Instead the = draft
still specifies the usage of comedia and the SDP c/m = routing, and that
allowed me to remove the a=3Dmsrp-acm attribute, = since the a=3Dsetup
attribute is enough to indicate support of the = mechanism in the = draft.

          =             &n= bsp;           &nbs= p;    The draft can also be found at:


(http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm-0= 1.tx
t
<http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm-0= 1.tx
t> = )

           = ;            &= nbsp;           &nb= sp;   = Regards,

         &nbs= p;            =             &n= bsp;    = Christer


_______________________________________________
&nb= sp;            = ;            &= nbsp;           &nb= sp; Simple mailing = list
           =             &n= bsp;           &nbs= p;   Simple@ietf.org

https://www.ietf.org= /mailman/listinfo/simple




    &n= bsp;           &nbs= p;      = _______________________________________________
    = ;            &= nbsp;      Simple mailing = list
           =             = Simple@ietf.org
   &= nbsp;           &nb= sp;       https://www.ietf.org= /mailman/listinfo/simple






= --Apple-Mail-2-857488229-- --===============0698881179== 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://www.ietf.org/mailman/listinfo/simple --===============0698881179==-- From simple-bounces@ietf.org Sat Sep 20 05:25:11 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFB493A68F7; Sat, 20 Sep 2008 05:25:11 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D26328C0DD for ; Sat, 20 Sep 2008 05:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.636 X-Spam-Level: X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCC7s4xVHLAq for ; Sat, 20 Sep 2008 05:25:08 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A614828C0F1 for ; Sat, 20 Sep 2008 05:25:07 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2BC022039B; Sat, 20 Sep 2008 14:25:21 +0200 (CEST) X-AuditID: c1b4fb3e-a6e81bb000007a96-57-48d4ebb0ea2d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0026820190; Sat, 20 Sep 2008 14:25:20 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 Sep 2008 14:25:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 20 Sep 2008 14:25:20 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] New version of draft-blau-simple-msrp-acm Thread-Index: AckaWkurESLZmrHVQoGzWR26R0kltwAv+Zig References: <66cd252f0809181732m299940a8y34264048ff7cf48a@mail.gmail.com> <1C32F490-8450-446E-86FC-BA1EF59FAD49@estacado.net> <66cd252f0809182155j1fe157fcp6573ea68ff10711e@mail.gmail.com> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 20 Sep 2008 12:25:20.0798 (UTC) FILETIME=[F2C73BE0:01C91B1B] X-Brightmail-Tracker: AAAAAA== Cc: simple@ietf.org, Robert Sparks Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, >To clarify my position: > >I very much prefer to be able to use the existing method. I also prefer, but not quite as >strongly, not to have two methods. I wouldn't mind having a single method - if it was the method in the draft :) The main reason we are proposing this new method in the first place is because the current one is very "expensive" to deploy. You cannot use generic NAT traversal mechanism (people who are e.g. deploying ICE and are buying TURN servers do not want to spend extra on MSRP relays just for a single media type), and it doesn't work with media-unaware ALGs (they are out there, no matter if we want or not). The new mechanism allows MSRP to be routed and NATted like any other type of media, and we think it's essential for the success of MSRP. Success is also based on backward compability, and the new method does consider that. However, I have no problem if people want to only be able to use the COMEDIA part of the draft, together with the existing routing mechanism. Regards, Christer On Sep 19, 2008, at 12:12 AM, Christer Holmberg wrote: Yes OR. The new routing method MAY be used, but one can also choose to use the existing method. I don't thin Ben ever said one MUST use the existing method, but that it should be allowed to use the existing method. To clarify my position: I very much prefer to be able to use the existing method. I also prefer, but not _quite_ as strongly, not to have two methods. Regards, Christer ________________________________ From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] Sent: 19. syyskuuta 2008 7:55 To: Christer Holmberg Cc: Ben Campbell; simple@ietf.org; Robert Sparks Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm No OR. COMEDIA is used to determine the TCP connection direction. The existing MSRP URI method, is then used for the actual routing of the MSRP messages. Hisham On 19/09/2008, Christer Holmberg wrote: Hi, >I suspect Hisham meant to say to use COMEDIA to "determine the connection direction" rather than "determine the path". If I am correct, then he has summarized my opinion perfectly. I think that is what I am trying to say also: COMEDIA is used to determine the TCP connection direction. The SDP c/m/a=msrp-acm method, OR the existing MSRP URI method, is then used for the actual routing of the MSRP messages. Regards, Christer On Sep 18, 2008, at 7:32 PM, Hisham Khartabil wrote: I don't believe we want 2 mechanisms to a path between the 2 parties. What Ben is saying that is we can use the COMEDIA mechanism to determine the path, but not necessarily the SDP extensions used for comedia. The path is then communicated between the 2 parties using the existing MSRP SDP extensions. Regards, Hisham On 18/09/2008, Christer Holmberg wrote: Hi Ben, I cannot think of any technical reason to prevent using only the COMEDIA part. It only means that the a=msrp-acm attribute has to be put back, since we need an explicit indication for the SDP routing part. Would anyone object to such approach? Regards, Christer ________________________________ From: Ben Campbell [mailto:ben@estacado.net] Sent: 17. syyskuuta 2008 23:44 To: Christer Holmberg Cc: simple@ietf.org; Robert Sparks Subject: Re: [Simple] New version of draft-blau-simple-msrp-acm Apologies--I thought I responded to your earlier email, but I can find no evidence that I actually did so. I would still prefer, unless we can site significant technical reasons preventing it, to have a COMEDIA or similar mechanism for the negotiation of connection direction that otherwise uses the MSRP URI path approach. On Sep 12, 2008, at 6:57 AM, Christer Holmberg wrote: Hi, I've submited a new version of the msrp-acm draft. Since nobody indicated on the list (I did ask twice :) that he/she wants to be able to use only the comedia part of the draft, I haven't changed that. Instead the draft still specifies the usage of comedia and the SDP c/m routing, and that allowed me to remove the a=msrp-acm attribute, since the a=setup attribute is enough to indicate support of the mechanism in the draft. The draft can also be found at: (http://users.piuha.net/cholmber/drafts/draft-blau-simple-msrp-acm-01.tx t ) Regards, Christer _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 23 10:22:04 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2C23A6852; Tue, 23 Sep 2008 10:22:04 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9E303A6852 for ; Tue, 23 Sep 2008 10:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9i6eiZXWKWs for ; Tue, 23 Sep 2008 10:21:55 -0700 (PDT) Received: from mtagate8.de.ibm.com (mtagate8.de.ibm.com [195.212.29.157]) by core3.amsl.com (Postfix) with ESMTP id 0AC7C3A6821 for ; Tue, 23 Sep 2008 10:21:54 -0700 (PDT) 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 m8NHL5jm533516 for ; Tue, 23 Sep 2008 17:21:05 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 v9.1) with ESMTP id m8NHL5he4046982 for ; Tue, 23 Sep 2008 19:21:05 +0200 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 m8NHL2WF032323 for ; Tue, 23 Sep 2008 19:21:02 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8NHL1ti032318; Tue, 23 Sep 2008 19:21:01 +0200 In-Reply-To: <487507EF.7080403@entel.upc.es> References: <487507EF.7080403@entel.upc.es> To: =?ISO-8859-1?Q?Victoria_Beltr=E1n_Mart=EDnez?= , simple@ietf.org MIME-Version: 1.0 X-KeepSent: F3C4DBDA:5D61ADED-C22574C5:005AC8BE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 February 07, 2008 From: Avshalom Houri Message-ID: Date: Tue, 23 Sep 2008 20:20:59 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0.1|February 07, 2008) at 23/09/2008 20:21:01, Serialize complete at 23/09/2008 20:21:01 Subject: Re: [Simple] ietf-simple-interdomain-scaling-analysis-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============1236403456==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1236403456== Content-Type: multipart/alternative; boundary="=_alternative 005F4586C22574CD_=" This is a multipart message in MIME format. --=_alternative 005F4586C22574CD_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Victoria, Thanks for the careful review and apologies for my late response. Victoria Beltr=E1n Mart=EDnez wrote on 09/07/2008 = 21:48:15: > Victoria Beltr=E1n Mart=EDnez =20 > Sent by: simple-bounces@ietf.org >=20 > 09/07/2008 22:30 >=20 > To >=20 > simple@ietf.org >=20 > cc >=20 > Subject >=20 > [Simple] ietf-simple-interdomain-scaling-analysis-04 >=20 > Hello, >=20 >=20 > I have some comments about this draft which I would like to discuss: >=20 >=20 > 1- In page 10, the description of C14 variable could lead to confusion=20 > saing ?(per each contact)? since a multipart boundary is also used for=20 > the resource list. Will remove "(per each contact)". >=20 > 2- In page 11, When S03 variable is calculated and dialog optimization=20 > is applied, the multipart boundary of the resource list is missing. The=20 > most correct is (C06*C04)*((S01*(C09+C11+C13+C14+C15+C14))+(S02*C10)) Will fix. Impact should be very small. >=20 > 3- In page 12, when the T07 variable is calculated and dialog=20 > optimization is used, it is assumed that only a single presentity is=20 > changed. But, In my opinion, considering presence changes in terminating = > notifies does not make sense since the NOTIFY message is sent in=20 > response to a terminating SUBSCRIBE. RFC 4662 makes no difference which=20 > presentities have changed their state when the RLS sends a terminating=20 > NOTIFY. This RFC only specifies that the terminating NOTIFY should be=20 > full-state as well as the initial NOTIFY. So, I think that T07 variable=20 > should be calculated by=20 > (T03*C06*(C09+C14+C15))+(T03*C06*C04*(C11+C13+C14)) in the case of=20 > dialog optimization. Will fix. >=20 > 4- The total number and bytes of messages in section 2.4 is calculated=20 > assuming presence documents of 3000 bytes. However, the next section 2.5 = > uses presence documents of 350 bytes. If the aim is to compare the case=20 > No optimizations with the Dialog optimization case, the same document=20 > size should be used. If we assume a size of 3000 bytes for Dialog=20 > optimization, it generates more bytes than the No optimizations case=20 does. >=20 In the bottom line both calculations (3000 & 350 bytes) are given for=20 each. >=20 > Regards, > Victoria >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --=_alternative 005F4586C22574CD_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Victoria,

Thanks for the careful review and apologies for my late response.

Victoria Beltr=E1n Mart=EDnez <vbeltran@entel.upc= .edu> wrote on 09/07/2008 21:48:15:

> Victoria Beltr=E1n Mart=EDnez <vbeltran@entel.upc.edu>
> Sent by: simple-bounces@ietf.org
>
> 09/07/2008 22:30
>
> To
>
> simple@ietf.org
>
> cc
>
> Subject
>
> [Simple] ietf-simple-interdomain-scaling-analysis-04
>
> Hello,
>
>
> I have some comments about this draft which I would like to discuss: >
>
> 1- In page 10, the description of C14 variable could lead to confusion
> saing “(per each contact)” since a multipart boundary is a= lso used for
> the resource list.

Will remove "(per each contact)".

>
> 2- In page 11, When S03 variable is calculated and dialog optimization
> is applied, the multipart boundary of the resource list is missing. The
> most correct is (C06*C04)*((S01*(C09+C11+C13+C14+C15+C14))+(S02*C10))<= br>
Will fix. Impact should be very small.

>
> 3- In page 12, when the T07 variable is calculated and dialog
> optimization is used, it is assumed that only a single presentity is
> changed. But, In my opinion, considering presence changes in terminati= ng
> notifies does not make sense since the NOTIFY message is sent in
> response to a terminating SUBSCRIBE. RFC 4662 makes no difference which
> presentities have changed their state when the RLS sends a terminating
> NOTIFY. This RFC only specifies that the terminating NOTIFY should be
> full-state as well as the initial NOTIFY. So, I think that T07 variable
> should be calculated by
> (T03*C06*(C09+C14+C15))+(T03*C06*C04*(C11+C13+C14)) in the case of
> dialog optimization.
Will fix.

>
> 4- The total number and bytes of messages in section 2.4 is calculated
> assuming presence documents of 3000 bytes. However, the next section 2.5
> uses presence documents of 350 bytes. If the aim is to compare the case
> No optimizations with the Dialog optimization case, the same document
> size should be used. If we assume a size of 3000 bytes for Dialog
> optimization, it generates more bytes than the No optimizations case does.
>

In the bottom line both calculations (3000 & 350 bytes) are given for each.

>
> Regards,
> Victoria
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple
 --=_alternative 005F4586C22574CD_=-- --===============1236403456== 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://www.ietf.org/mailman/listinfo/simple --===============1236403456==-- From simple-bounces@ietf.org Thu Sep 25 01:37:46 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01D13A67C0; Thu, 25 Sep 2008 01:37:46 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09BD3A67C0 for ; Thu, 25 Sep 2008 01:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS1DgtCAXrlj for ; Thu, 25 Sep 2008 01:37:44 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by core3.amsl.com (Postfix) with ESMTP id D61373A63D3 for ; Thu, 25 Sep 2008 01:37:43 -0700 (PDT) Received: from htcasmad1.hi.inet (htcasmad1.hi.inet [10.95.67.73]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7Q00IRDT8P0A@tid.hi.inet> for simple@ietf.org; Thu, 25 Sep 2008 10:36:25 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([13.13.13.1]) with mapi; Thu, 25 Sep 2008 10:36:25 +0200 Date: Thu, 25 Sep 2008 10:36:24 +0200 From: Gustavo Garcia Bernardo To: "simple@ietf.org" Message-id: MIME-version: 1.0 Content-language: en-US Accept-Language: en-US Thread-topic: Feedback on draft-garcia-simple-poke-00 Thread-index: AQHJHunL7GBcxmTsBEarQeSFYlLpWw== acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Simple] Feedback on draft-garcia-simple-poke-00 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org We submitted this draft (http://tools.ietf.org/html/draft-garcia-simple-poke-00) some months ago and we would like to get more feedback from the list before trying to submit a new version. There was only some feedback from the XMPP people. - Is this feature something interesting to be standarized here? Taking into account that most of the IM solutions provide it to the users. - Should we remove all the "bells and whistles" from the document and leave only the basic message? It seems that some people in the list feel more confortable with that approach. This would leave the door open for propietary extensions or a future "Rich Poke" specification. Regards, G. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 26 11:16:02 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE7928C0FD; Fri, 26 Sep 2008 11:16:02 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9E63A6810; Fri, 26 Sep 2008 11:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmDp9Mwqq7PE; Fri, 26 Sep 2008 11:15:58 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 5A47B3A68D2; Fri, 26 Sep 2008 11:15:58 -0700 (PDT) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.1) with ESMTP id m8QIG57b081642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Sep 2008 13:16:06 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Robert Sparks In-Reply-To: <3A760625-C47C-4BEB-84B2-EB90C134F88D@nostrum.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 26 Sep 2008 13:16:05 -0500 References: <3A760625-C47C-4BEB-84B2-EB90C134F88D@nostrum.com> X-Mailer: Apple Mail (2.926) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94/8344/Fri Sep 26 10:34:14 2008 on shaman.nostrum.com X-Virus-Status: Clean Cc: "SIP@ietf.org List" , sipping LIST , simple mailing list , "sip-implementors@lists.cs.columbia.edu Implementors" Subject: [Simple] SIPit registration closes next friday X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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="===============1970088530==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1970088530== Content-Type: multipart/alternative; boundary=Apple-Mail-13--667369950 --Apple-Mail-13--667369950 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Registration for SIPit 23 closes this Friday October 3. If you are planning to attend and have not yet registered, please do so as soon as possible. SIPit 23 will be held in Lannion, France October 13-17, hosted by ETSI with technical support from France-Telecom Orange Labs. Registration is 490Euro per participant. More information and links to registration are available at http://www.sipit.net and http://www.etsi.org/plugtests/SIPit/SIPit.htm Thanks, RjS --Apple-Mail-13--667369950 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
--Apple-Mail-13--667369950-- --===============1970088530== 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://www.ietf.org/mailman/listinfo/simple --===============1970088530==-- From fuyuanturbo_sale@sina.com Sat Sep 27 19:11:16 2008 Return-Path: X-Original-To: ietfarch-simple-archive@core3.amsl.com Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B4623A69BC; Sat, 27 Sep 2008 19:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.999 X-Spam-Level: * X-Spam-Status: No, score=1.999 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, DEAR_SOMETHING=1.605, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, SARE_SPEC_LEO_BORD=0.639] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZI0lgWsWKVV; Sat, 27 Sep 2008 19:11:15 -0700 (PDT) Received: from smtp.sina.com.cn (mail3-163.sinamail.sina.com.cn [202.108.3.163]) by core3.amsl.com (Postfix) with ESMTP id 5E1183A699C; Sat, 27 Sep 2008 19:11:06 -0700 (PDT) Received: from mail5-203.sinamail.sina.com.cn (unknown [10.55.5.203]) by smtp.sina.com.cn (SINAMAIL) with ESMTP id 4C4C25F9D9B; Sun, 28 Sep 2008 10:11:17 +0800 (CST) Received: from unknown (HELO PC-200808261017) ([124.193.174.150]) by mail5-203.sinamail.sina.com.cn with ESMTP; 28 Sep 2008 10:11:16 +0800 Date: Sun, 28 Sep 2008 10:12:13 +0800 From: "fuyuanturbo_sale" To: "phoffman" , "phoffman" , "I-D-Announce" , "sip" , "l-admin" , "johnnie.rodgersjm" , "221668aa" <221668aa@alphawest.com.au>, "housley" , "housley" , "phoffman" , "ietf-smime-examples-request" , "paul.hoffman" , "phoffvpnc" , "5b1d8e96" <5b1d8e96@12.com.au>, "eakypwtn" , "simple-archive" , "oslgr" , "giga_586" , "anders.rundgren" , "stefans" , "cae6933d" , "kendallrb" , "mgthcmaiopxtkw" References: <200809171044186407643@sina.com>, <200809171259050469894@sina.com>, <200809171302294849270@sina.com>, <200809171304256569576@sina.com>, <200809171309199680598@sina.com>, <200809171312208285803@sina.com>, <200809171320250460545@sina.com>, <200809171346426717438@sina.com>, <200809171347465786594@sina.com>, <200809171358422653859@sina.com>, <200809171419282034545@sina.com>, <200809171456227187566@sina.com>, <200809171500515622310@sina.com>, <200809171615367962678@sina.com>, <200809171705532180227@sina.com>, <200809171724445008240@sina.com>, <200809180826396407473@sina.com>, <200809180837144849144@sina.com>, <200809181030418752693@sina.com>, <200809181235214216059@sina.com>, <200809181333073287701@sina.com>, <200809181345509375994@sina.com>, <200809181446077031365@sina.com>, <200809181457310319691@sina.com>, <200809181458187034932@sina.com>, <200809181459441561725@sina.com>, <200809190918541251401@sina.com>, <200809191124493120291@sina.com>, <200809191310000784383@sina.com>, <200809191315569689341@sina.com>, <200809191321436874636@sina.com>, <200809191341054069305@sina.com>, <200809191412444684116@sina.com>, <200809191448045001625@sina.com>, <200809191517351564228@sina.com>, <200809191525252036325@sina.com>, <200809191531496879300@sina.com>, <200809191535147961702@sina.com>, <200809191541493284659@sina.com>, <200809191551110156919@sina.com>, <200809191608058907489@sina.com>, <200809191648400462380@sina.com>, <200809191655562818808@sina.com>, <200809191715017186665@sina.com>, <200809191721465157401@sina.com>, <200809191727022180350@sina.com>, <200809191729204068977@sina.com>, <200809221714134530601@sina.com>, <200809231745432945941@sina.com>, <200809241741280628474@sina.com>, <200809250915259846203@sina.com>, <200809251020017036826@sina.com>, <200809251039451096619@sina.com>, <200809251319188905156@sina.com>, <200809251419071876524@sina.com>, <200809251522407653768@sina.com>, <200809261438354846282@sina.com> Subject: turbocharger cooperation Message-ID: <200809271620087039572@sina.com> X-mailer: Foxmail 6, 10, 201, 20 [cn] Disposition-Notification-To: "fuyuanturbo_sale" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon764878804080_=====" This is a multi-part message in MIME format. --=====003_Dragon764878804080_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpEZWFyIFNpcnM6DQogDQpXZSBhcmUgRnVZdWFuIFR1cmJvY2hhcmdlcnMgQ28uLCBMdGQuLCB0 aGUgbGFyZ2VzdCB0dXJib2NoYXJnZXIgbWFudWZhY3R1cmVyIGluIE5vcnRoIG9mIENoaW5hLiBX ZSB3cml0ZSB0aGlzIGVtYWlsIGluIG9yZGVyIHRvIHNlZWsgb3Bwb3J0dW5pdGllcyBvZiBlc3Rh Ymxpc2hpbmcgYnVzaW5lc3MgcmVsYXRpb25zaGlwIGJldHdlZW4gdXMuIA0KIA0KRnVZdWFuIFR1 cmJvY2hhcmdlcnMgQ28uLCBMdGQuIGxvY2F0ZXMgaW4gU2hhbmRvbmcgUHJvdmluY2UsIENoaW5h LiBJdCBjb3ZlcnMgYW4gYXJlYSBvZiAxNDAsMDAwbTIgYW5kIGhhcyBhbiBhbm51YWwgcHJvZHVj dGlvbiBjYXBhY2l0eSBvZiA0MDAsMDAwIHNldHMuIFRoZSBkaWFtZXRlciBvZiB0aGUgaW1wZWxs ZXIgaXMgZnJvbSCmtTMwbW0gdG8gprUyMDBtbSB3aGljaCBjYW4gbWVldCB0aGUgbmVlZCBvZiAz MC0yNDAwa1cgZGllc2VsIGVuZ2luZSwgbmF0dXJhbCBnYXMgZW5naW5lIGFuZCBjb2FsIGdhcyBl bmdpbmUgZm9yIGNhcnMsIHRydWNrcywgZ2VuZXJhdG9yIHVuaXRzLCBtYXJpbmVzLCBlbmdpbmVl cmluZyBtYWNoaW5lcnksIGV0Yy4gKGh0dHA6Ly93d3cuZnV5dWFudHVyYm8uY29tKQ0KIA0KRnVZ dWFuIGlzIGFuIElTTzkwMDEsIElTTy9UUzE2OTQ5LCBJU08xNDAwMSBhbmQgT0hTQVMxODAwMSBj ZXJ0aWZpY2F0ZWQgY29tcGFueS4gV2UgY2FuIGRlc2lnbiBhbmQgbWFudWZhY3R1cmUgdHVyYm9j aGFyZ2VycyBmb3Igb3VyIGN1c3RvbWVycyB0byBtYXRjaCB0aGVpciBlbmdpbmVzIGFuZCBjYXJy eSBvdXQgbWF0Y2hpbmcgdGVzdHMuIE91ciBSJkQgYW5kIG9wZW5pbmcgbW91bGQgd291bGQgYmUg ZnJlZSBvZiBjaGFyZ2VzLiBJbiBDaGluYSwgd2UgYXJlIE9FTSBzdXBwbGllciBvZiBZdWNoYWkg YW5kIFdlaWNoYWkgc2FtZSBhcyBHYXJyZXR0IGFuZCBCb3Jnd2FybmVyLiBXZSBhcmUgYWxzbyBz dXBwbGllciBvZiBvdGhlciBJQyBlbmdpbmUgbWFudWZhY3R1cmVycyBpbmNsdWRpbmcgRm90b24s IFBlcmtpbnMsIFN0ZXlyZSwgRHVldHosIGV0YyBpbiBDaGluYS4gV2Ugc3VwcGx5IHRvIHRoZW0g bW9yZSB0aGFuIDIwMCwwMDBzZXRzIHBlciB5ZWFyLiBHYXJyZXR0KCBDaGluYSkgYWxzbyBhc2tz IHVzIHRvIHN1cHBseSB0aGUgY29yZSBwYXJ0cyB0byB0aGVtLiBJbiBmb3JlaWduIG1hcmtldHMs IHdlIGhhdmUgY29vcGVyYXRlZCB3aXRoIFJ1c3NpYW4gVEtQIGZvciBtYW55IHllYXJzLiBXZSBl eHBvcnQgdG8gUnVzc2lhIGF0IHRoZSBxdWFudGl0eSBvZiAxMDAsMDAwc2V0cyBwZXIgeWVhci4g DQogDQpJZiB5b3UgYXJlIGxvb2tpbmcgZm9yIGEgcGFydG5lciBvZiBzdXBwbHlpbmcgdHVyYm9j aGFyZ2VyLCBwbGVhc2Uga2luZGx5IGNvbnRhY3QgdXMuIFRoYW5rIHlvdS4NCiANCklmIHRoaXMg bGV0dGVyIGlzIG5vdCByZWxhdGVkIHRvIHlvdXIgd29yaywgcGxlYXNlIGhlbHAgdXMgdG8gcGFz cyB0byB0aGUgcmVsYXRlZCB0dXJib2NoYXJnZXIgZGVwYXJ0bWVudCBvciBSJkQgZGVwYXJ0bWVu dC4gVGhhbmsgeW91Lg0KIA0KQmVzdCByZWdhcmRzDQogDQpjZWxpYSBjaGVuDQpJbnRlcm5hdGlv bmFsIFRyYWRlIERlcHQuIG9mDQpGdVl1YW4gVHVyYm9jaGFyZ2VycyBDby4sIEx0ZC4NClRlbDow MDg2LTEwLTgzOTkzODMyLCA4Mzk5Mzg4Nw0KRmF4OiAwMDg2LTEwLTgzOTkzODMyDQpFbWFpbDog ZnV5dWFudHVyYm9fc2FsZUBzaW5hLmNvbQ0KV2Vic2l0ZTogd3d3LmZ1eXVhbnR1cmJvLmNvbQ0K --=====003_Dragon764878804080_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zOm8geG1sbnM6c3QxPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1D b250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PUdCMjMxMiI+DQo8TUVUQSBj b250ZW50PSJNU0hUTUwgNi4wMC4yOTAwLjMzOTUiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBm b250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiDLzszlOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1m YW1pbHk6IFZlcmRhbmE7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQMvOzOU7DQp9 DQpAcGFnZSBTZWN0aW9uMSB7c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5 MC4wcHQgNzIuMHB0IDkwLjBwdDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwg ew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFS R0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFM SUdOOiBqdXN0aWZ5DQp9DQpMSS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRl b2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1J TFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9y bWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7 IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVY VC1BTElHTjoganVzdGlmeQ0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFU SU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVY VC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsg VEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQg ew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVt YWlsU3R5bGUxNyB7DQoJRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZP TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjog bm9uZTsgbXNvLXN0eWxlLXR5cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7 DQoJcGFnZTogU2VjdGlvbjENCn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxP Q0tRVU9URSB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1M RUZUOiAyZW0NCn0NCk9MIHsNCglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0K fQ0KVUwgew0KCU1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxF Pg0KPC9IRUFEPg0KPEJPRFkgDQpzdHlsZT0iQk9SREVSLVRPUC1XSURUSDogMHB4OyBCT1JERVIt TEVGVC1XSURUSDogMHB4OyBGT05ULVNJWkU6IDEwcHQ7IEJPUkRFUi1CT1RUT00tV0lEVEg6IDBw eDsgRk9OVC1GQU1JTFk6IHZlcmRhbmE7IEJPUkRFUi1SSUdIVC1XSURUSDogMHB4Ij4NCjxESVY+ PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMD4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxG T05UIHNpemU9Mj48L0ZPTlQ+PC9GT05UPjwvRElWPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZl cmRhbmEgc2l6ZT0yPg0KPERJVj48Rk9OVCBjb2xvcj0jYzBjMGMwPjxGT05UIGZhY2U9VmVyZGFu YSBzaXplPTI+PEZPTlQgY29sb3I9I2MwYzBjMD48Rk9OVCANCmZhY2U9VmVyZGFuYSBzaXplPTI+ PEZPTlQgY29sb3I9I2MwYzBjMD48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxGT05UIA0KY29s b3I9I2MwYzBjMD48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxGT05UIGNvbG9yPSNjMGMwYzA+ PEZPTlQgZmFjZT1WZXJkYW5hIA0Kc2l6ZT0yPjxGT05UIGNvbG9yPSNjMGMwYzA+PEZPTlQgZmFj ZT1WZXJkYW5hIHNpemU9Mj48Rk9OVCBjb2xvcj0jYzBjMGMwPjxGT05UIA0KZmFjZT1WZXJkYW5h IHNpemU9Mj48Rk9OVCBjb2xvcj0jYzBjMGMwPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PEZP TlQgDQpjb2xvcj0jYzBjMGMwPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PEZPTlQgY29sb3I9 I2MwYzBjMD48Rk9OVCBmYWNlPVZlcmRhbmEgDQpzaXplPTI+PEZPTlQgY29sb3I9I2MwYzBjMD48 Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxGT05UIGNvbG9yPSNjMGMwYzA+PEZPTlQgDQpmYWNl PVZlcmRhbmEgc2l6ZT0yPjxGT05UIGNvbG9yPSNjMGMwYzA+PEZPTlQgZmFjZT1WZXJkYW5hIHNp emU9Mj48Rk9OVCANCmNvbG9yPSNjMGMwYzA+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48Rk9O VCBjb2xvcj0jYzBjMGMwPjxGT05UIGZhY2U9VmVyZGFuYSANCnNpemU9Mj48Rk9OVCBjb2xvcj0j YzBjMGMwPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PEZPTlQgY29sb3I9I2MwYzBjMD48Rk9O VCANCmZhY2U9VmVyZGFuYSBzaXplPTI+PEZPTlQgY29sb3I9I2MwYzBjMD48Rk9OVCBmYWNlPVZl cmRhbmEgc2l6ZT0yPjxGT05UIA0KY29sb3I9I2MwYzBjMD48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6 ZT0yPjxGT05UIGNvbG9yPSNjMGMwYzA+PEZPTlQgZmFjZT1WZXJkYW5hIA0Kc2l6ZT0yPjxGT05U IGNvbG9yPSNjMGMwYzA+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48Rk9OVCBjb2xvcj0jYzBj MGMwPjxGT05UIA0KZmFjZT1WZXJkYW5hIHNpemU9Mj48Rk9OVCBjb2xvcj0jYzBjMGMwPjxGT05U IGZhY2U9VmVyZGFuYSBzaXplPTI+PEZPTlQgDQpjb2xvcj0jYzBjMGMwPjxGT05UIGZhY2U9VmVy ZGFuYSBzaXplPTI+PEZPTlQgY29sb3I9I2MwYzBjMD48Rk9OVCBmYWNlPVZlcmRhbmEgDQpzaXpl PTI+PEZPTlQgY29sb3I9I2MwYzBjMD48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxGT05UIGNv bG9yPSNjMGMwYzA+PEZPTlQgDQpmYWNlPVZlcmRhbmEgc2l6ZT0yPjxGT05UIGNvbG9yPSNjMGMw YzA+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48Rk9OVCANCmNvbG9yPSNjMGMwYzA+PEZPTlQg ZmFjZT1WZXJkYW5hIHNpemU9Mj48Rk9OVCBjb2xvcj0jYzBjMGMwPjxGT05UIGZhY2U9VmVyZGFu YSANCnNpemU9Mj48Rk9OVCBjb2xvcj0jYzBjMGMwPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+ PEZPTlQgY29sb3I9I2MwYzBjMD48Rk9OVCANCmZhY2U9VmVyZGFuYSBzaXplPTI+PEZPTlQgY29s b3I9I2MwYzBjMD48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxGT05UIA0KY29sb3I9I2MwYzBj MD48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxGT05UIGNvbG9yPSNjMGMwYzA+PEZPTlQgZmFj ZT1WZXJkYW5hIA0Kc2l6ZT0yPjxGT05UIGNvbG9yPSNjMGMwYzA+PEZPTlQgZmFjZT1WZXJkYW5h IHNpemU9Mj48Rk9OVCBjb2xvcj0jYzBjMGMwPjxGT05UIA0KZmFjZT1WZXJkYW5hIHNpemU9Mj48 Rk9OVCBjb2xvcj0jYzBjMGMwPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PEZPTlQgDQpjb2xv cj0jYzBjMGMwPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PEZPTlQgY29sb3I9I2MwYzBjMD48 Rk9OVCBmYWNlPVZlcmRhbmEgDQpzaXplPTI+PEZPTlQgY29sb3I9I2MwYzBjMD48Rk9OVCBmYWNl PVZlcmRhbmEgc2l6ZT0yPjxGT05UIGNvbG9yPSNjMGMwYzA+PEZPTlQgDQpmYWNlPVZlcmRhbmEg c2l6ZT0yPjxGT05UIGNvbG9yPSNjMGMwYzA+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48Rk9O VCANCmNvbG9yPSNjMGMwYzA+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48Rk9OVCBjb2xvcj0j YzBjMGMwPjxGT05UIGZhY2U9VmVyZGFuYSANCnNpemU9Mj48Rk9OVCBjb2xvcj0jYzBjMGMwPjxG T05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PEZPTlQgY29sb3I9I2MwYzBjMD48Rk9OVCANCmZhY2U9 VmVyZGFuYSBzaXplPTI+PEZPTlQgY29sb3I9I2MwYzBjMD48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6 ZT0yPjxGT05UIA0KY29sb3I9I2MwYzBjMD48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxGT05U IGNvbG9yPSNjMGMwYzA+PEZPTlQgZmFjZT1WZXJkYW5hIA0Kc2l6ZT0yPjxGT05UIGNvbG9yPSNj MGMwYzA+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48Rk9OVCBjb2xvcj0jYzBjMGMwPjxGT05U IA0KZmFjZT1WZXJkYW5hIHNpemU9Mj48Rk9OVCBjb2xvcj0jYzBjMGMwPjxGT05UIGZhY2U9VmVy ZGFuYSBzaXplPTI+PEZPTlQgDQpjb2xvcj0jYzBjMGMwPjxGT05UIGZhY2U9VmVyZGFuYSBzaXpl PTI+PEZPTlQgY29sb3I9I2MwYzBjMD48Rk9OVCBmYWNlPVZlcmRhbmEgDQpzaXplPTI+PEZPTlQg Y29sb3I9I2MwYzBjMD48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxGT05UIGZhY2U9VmVyZGFu YSANCnNpemU9Mj48Rk9OVCBjb2xvcj0jMDAwMDAwPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIiANCnNpemU9Mz5EZWFyIFNpcnM6PC9GT05UPjwvU1BBTj48L0ZP TlQ+PC9ESVY+DQo8RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPERJVj4NCjxESVY+DQo8RElW Pg0KPERJVj4NCjxESVY+DQo8RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPERJVj4NCjxESVY+ DQo8RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPERJVj4N CjxESVY+DQo8RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0K PERJVj4NCjxESVY+DQo8RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPERJVj4NCjxESVY+DQo8 RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPERJVj4NCjxE SVY+DQo8RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPERJ Vj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQi PjxTUEFOIGxhbmc9RU4tVVM+PG86cD48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29s b3I9IzAwMDAwMCBzaXplPTM+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+ PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPldlIGFy ZSBGdVl1YW4gVHVyYm9jaGFyZ2VycyBDby4sIA0KTHRkLiwgdGhlIGxhcmdlc3QgdHVyYm9jaGFy Z2VyIG1hbnVmYWN0dXJlciBpbiBOb3J0aCBvZiBDaGluYS4gV2Ugd3JpdGUgdGhpcyANCmVtYWls IGluIG9yZGVyIHRvIHNlZWsgb3Bwb3J0dW5pdGllcyBvZiBlc3RhYmxpc2hpbmcgYnVzaW5lc3Mg cmVsYXRpb25zaGlwIA0KYmV0d2VlbiB1cy4gPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PG86 cD48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9IzAwMDAwMCBzaXplPTM+Jm5i c3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B UkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgDQpmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPkZ1WXVhbiBUdXJib2NoYXJnZXJzIENvLiwg THRkLiANCmxvY2F0ZXMgaW4gU2hhbmRvbmcgUHJvdmluY2UsIENoaW5hLiBJdCBjb3ZlcnMgYW4g YXJlYSBvZiA8c3QxOmNobWV0Y252IA0KdzpzdD0ib24iIFRDU0M9IjAiIE51bWJlclR5cGU9IjEi IE5lZ2F0aXZlPSJGYWxzZSIgSGFzU3BhY2U9IkZhbHNlIiANClNvdXJjZVZhbHVlPSIxNDAwMDAi IFVuaXROYW1lPSJtMiI+MTQwLDAwMG08U1VQPjI8L1NVUD48L3N0MTpjaG1ldGNudj48U1VQPiAN CjwvU1VQPmFuZCBoYXMgYW4gYW5udWFsIHByb2R1Y3Rpb24gY2FwYWNpdHkgb2YgNDAwLDAwMCBz ZXRzLiBUaGUgZGlhbWV0ZXIgb2YgdGhlIA0KaW1wZWxsZXIgaXMgZnJvbSCmtTxzdDE6Y2htZXRj bnYgdzpzdD0ib24iIFRDU0M9IjAiIE51bWJlclR5cGU9IjEiIA0KTmVnYXRpdmU9IkZhbHNlIiBI YXNTcGFjZT0iRmFsc2UiIFNvdXJjZVZhbHVlPSIzMCIgDQpVbml0TmFtZT0ibW0iPjMwbW08L3N0 MTpjaG1ldGNudj4gdG8gprU8c3QxOmNobWV0Y252IHc6c3Q9Im9uIiBUQ1NDPSIwIiANCk51bWJl clR5cGU9IjEiIE5lZ2F0aXZlPSJGYWxzZSIgSGFzU3BhY2U9IkZhbHNlIiBTb3VyY2VWYWx1ZT0i MjAwIiANClVuaXROYW1lPSJtbSI+MjAwbW08L3N0MTpjaG1ldGNudj4gd2hpY2ggY2FuIG1lZXQg dGhlIG5lZWQgb2YgMzAtMjQwMGtXIGRpZXNlbCANCmVuZ2luZSwgbmF0dXJhbCBnYXMgZW5naW5l IGFuZCBjb2FsIGdhcyBlbmdpbmUgZm9yIGNhcnMsIHRydWNrcywgZ2VuZXJhdG9yIA0KdW5pdHMs IG1hcmluZXMsIGVuZ2luZWVyaW5nIG1hY2hpbmVyeSwgZXRjLiANCihodHRwOi8vd3d3LmZ1eXVh bnR1cmJvLmNvbSk8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0i TUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48bzpwPjxGT05UIA0KZmFjZT0i VGltZXMgTmV3IFJvbWFuIiBjb2xvcj0jMDAwMDAwIHNpemU9Mz4mbmJzcDs8L0ZPTlQ+PC9vOnA+ PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBw dCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9 IzAwMDAwMCBzaXplPTM+RnVZdWFuIGlzIGFuIElTTzkwMDEsIElTTy9UUzE2OTQ5LCANCklTTzE0 MDAxIGFuZCBPSFNBUzE4MDAxIGNlcnRpZmljYXRlZCBjb21wYW55LiBXZSBjYW4gZGVzaWduIGFu ZCBtYW51ZmFjdHVyZSANCnR1cmJvY2hhcmdlcnMgZm9yIG91ciBjdXN0b21lcnMgdG8gbWF0Y2gg dGhlaXIgZW5naW5lcyBhbmQgY2Fycnkgb3V0IG1hdGNoaW5nIA0KdGVzdHMuIE91ciBSJmFtcDtE IGFuZCBvcGVuaW5nIG1vdWxkIHdvdWxkIGJlIGZyZWUgb2YgY2hhcmdlcy4gSW4gQ2hpbmEsIHdl IGFyZSANCk9FTSBzdXBwbGllciBvZiBZdWNoYWkgYW5kIFdlaWNoYWkgc2FtZSBhcyBHYXJyZXR0 IGFuZCBCb3Jnd2FybmVyLiBXZSBhcmUgYWxzbyANCnN1cHBsaWVyIG9mIG90aGVyIElDIGVuZ2lu ZSBtYW51ZmFjdHVyZXJzIGluY2x1ZGluZyBGb3RvbiwgUGVya2lucywgU3RleXJlLCANCkR1ZXR6 LCBldGMgaW4gQ2hpbmEuIFdlIHN1cHBseSB0byB0aGVtIG1vcmUgdGhhbiAyMDAsMDAwc2V0cyBw ZXIgeWVhci4gR2FycmV0dCggDQo8c3QxOmNvdW50cnktcmVnaW9uIHc6c3Q9Im9uIj48c3QxOnBs YWNlIA0KdzpzdD0ib24iPkNoaW5hPC9zdDE6cGxhY2U+PC9zdDE6Y291bnRyeS1yZWdpb24+KSBh bHNvIGFza3MgdXMgdG8gc3VwcGx5IHRoZSANCmNvcmUgcGFydHMgdG8gdGhlbS4gSW4gZm9yZWln biBtYXJrZXRzLCB3ZSBoYXZlIGNvb3BlcmF0ZWQgd2l0aCBSdXNzaWFuIFRLUCBmb3IgDQptYW55 IHllYXJzLiBXZSBleHBvcnQgdG8gUnVzc2lhIGF0IHRoZSBxdWFudGl0eSBvZiAxMDAsMDAwc2V0 cyBwZXIgeWVhci4gDQo8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48bzpwPjxGT05UIA0KZmFj ZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj0jMDAwMDAwIHNpemU9Mz4mbmJzcDs8L0ZPTlQ+PC9v OnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29s b3I9IzAwMDAwMCBzaXplPTM+SWYgeW91IGFyZSBsb29raW5nIGZvciBhIHBhcnRuZXIgb2YgDQpz dXBwbHlpbmcgdHVyYm9jaGFyZ2VyLCBwbGVhc2Uga2luZGx5IGNvbnRhY3QgdXMuIFRoYW5rIHlv dS48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAw Y20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48bzpwPjxGT05UIA0KZmFjZT0iVGltZXMgTmV3 IFJvbWFuIiBjb2xvcj0jMDAwMDAwIHNpemU9Mz4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwv UD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4g bGFuZz1FTi1VUz48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9IzAwMDAwMCBz aXplPTM+SWYgdGhpcyBsZXR0ZXIgaXMgbm90IHJlbGF0ZWQgdG8gDQp5b3VyIHdvcmssIHBsZWFz ZSBoZWxwIHVzIHRvIHBhc3MgdG8gdGhlIHJlbGF0ZWQgdHVyYm9jaGFyZ2VyIGRlcGFydG1lbnQg b3IgDQpSJmFtcDtEIGRlcGFydG1lbnQuIFRoYW5rIHlvdS48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQ IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1F Ti1VUz48bzpwPjxGT05UIA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj0jMDAwMDAwIHNp emU9Mz4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCANCmZhY2U9 IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9IzAwMDAwMCBzaXplPTM+QmVzdCByZWdhcmRzPC9GT05U PjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAw cHQiPjxTUEFOIGxhbmc9RU4tVVM+PG86cD48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiIg Y29sb3I9IzAwMDAwMCBzaXplPTM+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxGT05UIGNvbG9yPSMw MDAwMDA+Y2VsaWEgDQpjaGVuPC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0i TUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCANCmZhY2U9IlRpbWVz IE5ldyBSb21hbiIgY29sb3I9IzAwMDAwMCBzaXplPTM+SW50ZXJuYXRpb25hbCBUcmFkZSBEZXB0 LiANCm9mPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcg Um9tYW4iIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPkZ1WXVhbiBUdXJib2NoYXJnZXJzIENvLiwgDQpM dGQuPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjog MGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9t YW4iIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPlRlbDowMDg2LTEwLTgzOTkzODMyLCANCjgzOTkzODg3 PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IGNvbG9yPSMwMDAwMDAgc2l6ZT0zPkZheDogDQowMDg2LTEwLTgzOTkzODMyPC9GT05UPjwvU1BB Tj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxT UEFOIGxhbmc9RU4tVVM+PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48Rk9O VCBjb2xvcj0jMDAwMDAwPkVtYWlsOiA8L0ZPTlQ+PEEgDQpocmVmPSJtYWlsdG86ZnV5dWFudHVy Ym9fc2FsZUBzaW5hLmNvbSI+PEZPTlQgDQpjb2xvcj0jMDAwMDAwPmZ1eXVhbnR1cmJvX3NhbGVA c2luYS5jb208L0ZPTlQ+PC9BPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIA0KZmFj ZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+V2Vic2l0ZTogPEEgDQpocmVmPSJodHRwOi8vd3d3 LmZ1eXVhbnR1cmJvLmNvbS8iPnd3dy5mdXl1YW50dXJiby5jb208L0E+PC9GT05UPjwvU1BBTj48 L1A+PC9GT05UPjwvRElWPjxGT05UIA0KZmFjZT1WZXJkYW5hIA0Kc2l6ZT0yPjwvRk9OVD48L0ZP TlQ+PC9ESVY+PC9GT05UPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9GT05UPjwvRElWPjwvRk9OVD48 L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9GT05UPjwvRElWPjwvRk9O VD48L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9GT05UPjwvRElWPjwv Rk9OVD48L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9GT05UPjwvRElW PjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9GT05UPjwv RElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9GT05U PjwvRElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9G T05UPjwvRElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRk9OVD48L0RJVj48L0ZPTlQ+ PC9GT05UPjwvRElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRk9OVD48L0RJVj48L0ZP TlQ+PC9GT05UPjwvRElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRk9OVD48L0RJVj48 L0ZPTlQ+PC9GT05UPjwvRElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRk9OVD48L0RJ Vj48L0ZPTlQ+PC9GT05UPjwvRElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRk9OVD48 L0RJVj48L0ZPTlQ+PC9GT05UPjwvRElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRk9O VD48L0RJVj48L0ZPTlQ+PC9GT05UPjwvRElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9GT05UPjwv Rk9OVD48L0RJVj48L0ZPTlQ+PC9GT05UPjwvRElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9GT05U PjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9GT05UPjwvRElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9G T05UPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9GT05UPjwvRElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+ PC9GT05UPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9GT05UPjwvRElWPjwvRk9OVD48L0ZPTlQ+PC9E SVY+PC9GT05UPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9GT05UPjwvRElWPjwvRk9OVD48L0ZPTlQ+ PC9ESVY+PC9GT05UPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9GT05UPjwvRElWPjwvRk9OVD48L0JP RFk+PC9IVE1MPg0K --=====003_Dragon764878804080_=====-- From newsadwords@google.com Mon Sep 29 22:48:00 2008 Return-Path: X-Original-To: ietfarch-simple-archive@core3.amsl.com Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 888B43A68FA for ; Mon, 29 Sep 2008 22:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -47.629 X-Spam-Level: X-Spam-Status: No, score=-47.629 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ir6tZz1mcs22 for ; Mon, 29 Sep 2008 22:47:59 -0700 (PDT) Received: from shpd-92-101-154-236.vologda.ru (shpd-92-101-154-236.vologda.ru [92.101.154.236]) by core3.amsl.com (Postfix) with ESMTP id 677E03A6897 for ; Mon, 29 Sep 2008 22:47:59 -0700 (PDT) Date: Tue, 30 Sep 2008 04:00:58 +0000 Message-ID: <42686.laurae@armond> From: "Google Adwords Support" To: Subject: Account Protection! Google Adwords is dedicated to protecting your privacy MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_nfAeYEqcjYCKzs" This is a multi-part message in MIME format. --=_nfAeYEqcjYCKzs Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Attention GOOGLE ADWORDS Customers!=20 For certain services, such as our advertising programs, we request = 128-bit SSL security information which we maintain in encrypted form on = secure servers.=20 We take appropriate security measures to protect against unauthorized = access to our unauthorized alteration, disclosure or destruction of = data. Please download latest SSL protection certificate Read more>> Unprotected browsers will not be able to Log in after September 30, 2008 Sincerely, Fletcher Barnhart. 2008 Google Adwords, Developing new services. --=_nfAeYEqcjYCKzs Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Attention GOOGLE ADWORDS Customers!

For certain services, such as our advertising programs, we request = 128-bit SSL security information which we maintain in encrypted form on = secure servers.
We take appropriate security measures to protect against unauthorized = access to our unauthorized alteration, disclosure or destruction of = data.
Please download latest SSL protection certificate

Read = more>>

Unprotected browsers will not be able to Log in after September 30, = 2008
Sincerely, Fletcher Barnhart.

2008 Google Adwords, Developing new services.
--=_nfAeYEqcjYCKzs-- From simple-bounces@ietf.org Tue Sep 30 15:27:43 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3913A68C8; Tue, 30 Sep 2008 15:27:42 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4443A6800 for ; Tue, 30 Sep 2008 15:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.062 X-Spam-Level: X-Spam-Status: No, score=0.062 tagged_above=-999 required=5 tests=[AWL=1.172, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdvuDpvzZtEh for ; Tue, 30 Sep 2008 15:26:23 -0700 (PDT) Received: from casper2.cs.uct.ac.za (casper2.cs.uct.ac.za [137.158.59.4]) by core3.amsl.com (Postfix) with ESMTP id 7D29D28C188 for ; Tue, 30 Sep 2008 15:26:23 -0700 (PDT) Received: from webmail.cs.uct.ac.za ([137.158.59.26]) by casper2.cs.uct.ac.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kkng4-000M4I-7X for simple@ietf.org; Wed, 01 Oct 2008 00:26:44 +0200 Received: from 137.158.59.231 (SquirrelMail authenticated user aragalo) by webmail.cs.uct.ac.za with HTTP; Wed, 1 Oct 2008 00:26:35 +0200 (SAST) Message-ID: <4491.137.158.59.231.1222813595.squirrel@webmail.cs.uct.ac.za> Date: Wed, 1 Oct 2008 00:26:35 +0200 (SAST) From: aragalo@cs.uct.ac.za To: simple@ietf.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-Spam-casper2-Score: -1.6 X-Spam-casper2-Report: (-1.6 points, 5.0 required) 1.0 NO_REAL_NAME From: does not include a real name -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.7 BAYES_20 BODY: Bayesian spam probability is 5 to 20% [score: 0.1429] 0.0 AWL AWL: From: address is in the auto white-list Subject: [Simple] XMPP vs SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, I am a Masters in Computer Science student working on a project that compares XMPP and SIMPLE as presence protocols. Specifically, I am looking at Rich Presence, the aggregation of presence information from various assorted devices belonging to the same individual to provide a single and consistent user presence. I want to determine which is the better protocol for Rich Presence. My question is: Is it possible that the UDP version of SIMPLE could be more bandwidth efficient than XMPP over TCP for the conveyance of presence information? Evidently SIMPLE is more verbose than XMPP, however UDP is a much lighter transport layer protocol than TCP. Thanks. Anisa Ragalo, MSc Student, Department of Computer Science, University of Cape Town. Email: aragalo@cs.uct.ac.za Cellphone: +27760335309 _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 30 15:54:36 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440F23A691B; Tue, 30 Sep 2008 15:54:36 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6B053A6906 for ; Tue, 30 Sep 2008 15:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+efKehNAIBi for ; Tue, 30 Sep 2008 15:54:34 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0E8613A688E for ; Tue, 30 Sep 2008 15:54:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,340,1220227200"; d="scan'208";a="22779782" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Sep 2008 22:54:55 +0000 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 m8UMstPi002548; Tue, 30 Sep 2008 18:54:55 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8UMstQ4018619; Tue, 30 Sep 2008 22:54:55 GMT 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 Sep 2008 18:54:55 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Sep 2008 18:54:55 -0400 Message-ID: <48E2AE42.8050401@cisco.com> Date: Tue, 30 Sep 2008 18:54:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: aragalo@cs.uct.ac.za References: <4491.137.158.59.231.1222813595.squirrel@webmail.cs.uct.ac.za> In-Reply-To: <4491.137.158.59.231.1222813595.squirrel@webmail.cs.uct.ac.za> X-OriginalArrivalTime: 30 Sep 2008 22:54:55.0087 (UTC) FILETIME=[8E23CFF0:01C9234F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1433; t=1222815295; x=1223679295; c=relaxed/simple; s=rtpdkim1001; 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]=20XMPP=20vs=20SIMPLE |Sender:=20 |To:=20aragalo@cs.uct.ac.za; bh=b+wVa79CqBVQKqA8PpcZTDLVg+S+zMusCGOa7Mqj9zE=; b=YK0QLY/PGtfw8PNVZq5tk/rvz67yVrrqMiYPSfa8hFbQWMCbEsDUG7NTTi MJHxD2ZjkzCBxnO9JP5UtQwkbwxeU13Al0q0bk8ud1FNkcNqikXaT2NRFwFe /3O5xS+Jsq; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: simple@ietf.org Subject: Re: [Simple] XMPP vs SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org aragalo@cs.uct.ac.za wrote: > Hi, > > I am a Masters in Computer Science student working on a project that > compares XMPP and SIMPLE as presence protocols. Specifically, I am looking > at Rich Presence, the aggregation of presence information from various > assorted devices belonging to the same individual to provide a single and > consistent user presence. I want to determine which is the better protocol > for Rich Presence. > > My question is: Is it possible that the UDP version of SIMPLE could be > more bandwidth efficient than XMPP over TCP for the conveyance of presence > information? Evidently SIMPLE is more verbose than XMPP, however UDP is a > much lighter transport layer protocol than TCP. Its quite likely that the UDP form of SIMPLE isn't viable for presence, for a couple of reasons: - if the presence document is big enough to push the NOTIFY message over the PDU size, then you can't use UDP - you probably want the security of TLS for presence. So arguing for SIP over XMPP based on use of UDP isn't a great argument. Good Luck, Paul > Thanks. > > Anisa Ragalo, > MSc Student, > Department of Computer Science, > University of Cape Town. > > Email: aragalo@cs.uct.ac.za > Cellphone: +27760335309 > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 30 16:06:38 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA233A6938; Tue, 30 Sep 2008 16:06:38 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295683A6938 for ; Tue, 30 Sep 2008 16:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvT6OmvXNrhU for ; Tue, 30 Sep 2008 16:06:37 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 4EF6B3A68BD for ; Tue, 30 Sep 2008 16:06:37 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_09_30_18_23_37 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 30 Sep 2008 18:23:37 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Sep 2008 18:06:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Sep 2008 18:06:54 -0500 Message-ID: In-Reply-To: <48E2AE42.8050401@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] XMPP vs SIMPLE Thread-Index: AckjT5E+LMWx67SDR9evZdmDuiP1WQAARRmw References: <4491.137.158.59.231.1222813595.squirrel@webmail.cs.uct.ac.za> <48E2AE42.8050401@cisco.com> From: "Winterbottom, James" To: "Paul Kyzivat" , X-OriginalArrivalTime: 30 Sep 2008 23:06:56.0711 (UTC) FILETIME=[3C42E570:01C92351] Cc: simple@ietf.org Subject: Re: [Simple] XMPP vs SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I might throw in a bit of heresy here too. XMPP over BOSH works just great through my corporate firewall and web-proxy and the IS guys are none-the-wiser. If I were to move to SIP, well..... *8)... I know this isn't a composition comment, but it is an access to the service issue. Cheers James > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Wednesday, 1 October 2008 8:55 AM > To: aragalo@cs.uct.ac.za > Cc: simple@ietf.org > Subject: Re: [Simple] XMPP vs SIMPLE > > > > aragalo@cs.uct.ac.za wrote: > > Hi, > > > > I am a Masters in Computer Science student working on a project that > > compares XMPP and SIMPLE as presence protocols. Specifically, I am > looking > > at Rich Presence, the aggregation of presence information from various > > assorted devices belonging to the same individual to provide a single > and > > consistent user presence. I want to determine which is the better > protocol > > for Rich Presence. > > > > My question is: Is it possible that the UDP version of SIMPLE could be > > more bandwidth efficient than XMPP over TCP for the conveyance of > presence > > information? Evidently SIMPLE is more verbose than XMPP, however UDP is > a > > much lighter transport layer protocol than TCP. > > Its quite likely that the UDP form of SIMPLE isn't viable for presence, > for a couple of reasons: > - if the presence document is big enough to push the NOTIFY > message over the PDU size, then you can't use UDP > > - you probably want the security of TLS for presence. > > So arguing for SIP over XMPP based on use of UDP isn't a great argument. > > Good Luck, > Paul > > > Thanks. > > > > Anisa Ragalo, > > MSc Student, > > Department of Computer Science, > > University of Cape Town. > > > > Email: aragalo@cs.uct.ac.za > > Cellphone: +27760335309 > > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple