From ben@nostrum.com Thu Oct 1 09:24:57 2009 Return-Path: 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 5FA9528C171 for ; Thu, 1 Oct 2009 09:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 BbNV9w8ZGTN4 for ; Thu, 1 Oct 2009 09:24:56 -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 81A9D28C165 for ; Thu, 1 Oct 2009 09:24:55 -0700 (PDT) Received: from [10.0.1.193] (adsl-68-94-23-33.dsl.rcsntx.swbell.net [68.94.23.33]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n91GQBp3031579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Oct 2009 11:26:11 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-9--918223884 From: Ben Campbell In-Reply-To: Date: Thu, 1 Oct 2009 11:26:06 -0500 Message-Id: <139F8261-F37A-44F3-A2CB-41A8F22C295F@nostrum.com> References: <39E0CF0AE5F81649AA77FC1758A2BEF03D23B2200B@XMSCLUSTER-MBX.etsihq.org> To: "Rauschenbach, Uwe (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1076) Received-SPF: pass (nostrum.com: 68.94.23.33 is authenticated by a trusted mechanism) Cc: adam@nostrum.com, Louise.Clarke@forapolis.com, simple@ietf.org, dean.willis@softarmor.com Subject: Re: [Simple] Liaison statement from OMA to IETF SIMPLE on XML validation issues of IANA copies of XML schemas from RFC 4826 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: , X-List-Received-Date: Thu, 01 Oct 2009 16:24:57 -0000 --Apple-Mail-9--918223884 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, The attachment is too large to send to the SIMPLE list directly. I am working on submitting this to the IETF liaison statement page. When it's there, I will send a link to the list and the submitter. Thanks! Ben. On Oct 1, 2009, at 7:47 AM, Rauschenbach, Uwe (NSN - DE/Munich) wrote: > Dear IETF colleagues, > > the recently-sent LS below did not appear on the SIMPLE mailing list. > This is another attempt (with the attachment converted to PDF) to > get it through. > > OMA kindly asks the SIMPLE working group to address the issue > reported in the enclosed LS. > Kind regards, > Uwe Rauschenbach > > -- > Dr. Uwe Rauschenbach > Senior Specialist > Nokia Siemens Networks GmbH & Co. KG > Research, Technology & Platforms > St.-Martin-Str. 53, D-80240 Munich, Germany > Tel.: +49 89 5159 29751 > Mobile: +49 173 3083573 > > > > > From: ext Louise Clarke [mailto:Louise.Clarke@forapolis.com] > Sent: Wednesday, September 23, 2009 9:52 AM > To: dean.willis@softarmor.com; adam@nostrum.com; simple@ietf.org > Cc: OMA-PLENARY@MAIL.OPENMOBILEALLIANCE.ORG; OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG > ; UNMEHOPA, Musa (Musa); Rauschenbach, Uwe (NSN - DE/ > Munich);kyungtak.lee@samsung.com > Subject: > > To: IETF > Cc: OMA-TP, OMA-Liaison, ARC Chair, MWG Chair > > Dear IETF, > > Please find attached a Liaison Statement from OMA Architecture and > Messaging Working Groups on XML validation issues for your > consideration > > Kind Regards > > Louise Clarke > Document Support Officer > Open Mobile Alliance > Louise.Clarke@forapolis.com > > Tel: +33(0) 492 944912 > Mob:+33(0) 607590853 > > < A.zip>> > > A.pdf> --Apple-Mail-9--918223884 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

The attachment is = too large to send to the SIMPLE list directly. I am working on = submitting this to the IETF liaison statement page. When it's there, I = will send a link to the list and the = submitter.

Thanks!

Ben.<= /div>



On Oct 1, 2009, at 7:47 = AM, Rauschenbach, Uwe (NSN - DE/Munich) wrote:

Dear IETF = colleagues,
 
the recently-sent LS below did not appear = on the SIMPLE mailing list.
This is = another attempt (with the attachment converted to PDF) to get it = through. 
 
OMA kindly asks the SIMPLE working group to address the issue = reported in the enclosed LS.

Kind = regards,
Uwe Rauschenbach

--
Dr. Uwe Rauschenbach 
Senior = Specialist
Nokia Siemens Networks GmbH & Co. KG
Research, = Technology & Platforms
St.-Martin-Str. 53, D-80240 Munich, = Germany
Tel.: = +49 89 5159 29751 
Mobile: +49 173 = 3083573

 

From: ext Louise Clarke = [mailto:Louise.Clarke@forapolis.com] 
Sent: Wednesday, September 23, = 2009 9:52 AM
To: dean.willis@softarmor.com; adam@nostrum.com; simple@ietf.org
Cc:   

<= /div>
X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B08133A68EB; Sat, 3 Oct 2009 08:33:50 -0700 (PDT) From: Dean Willis(OMA) To: simple@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091003153350.B08133A68EB@core3.amsl.com> Date: Sat, 3 Oct 2009 08:33:50 -0700 (PDT) X-Mailman-Approved-At: Sat, 03 Oct 2009 18:12:19 -0700 Cc: fluffy@cisco.com, Kyung-Tak Lee , Musa Unmehopa , rjs@nostrum.com Subject: [Simple] New Liaison Statement, "OMA-LS_834 XML validation issues of IANA copies of XML schemas from RFC 4826" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: OMA-LIAISON@mail.openmobilealliance.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 15:33:50 -0000 Title: OMA-LS_834 XML validation issues of IANA copies of XML schemas from RFC 4826 Submission Date: 2009-10-03 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=592 Please reply by 2009-11-01 From: Dean Willis(OMA) To: IETF SIMPLE Working Group(simple@ietf.org) Cc: ben@nostrum.com rjs@nostrum.com fluffy@cisco.com Reponse Contact: Uwe Rauschenbach Musa Unmehopa Kyung-Tak Lee Technical Contact: Uwe Rauschenbach Musa Unmehopa Kyung-Tak Lee Purpose: For action Body: 1 Overview This Liaison Statement reports XML validation problems in the XML schemas that were introduced in RFC 4826 and asks for correction. 2 Proposal In the specifications of Parlay X (Web Service Interfaces for Parlay) and PoC (Push to Talk over Cellular), the Open Mobile Alliance references the XML schemas that have been developed by IETF in RFC 4826. This RFC defines two XML schemas: resource-lists (urn:ietf:params:xml:ns:resource-lists) and rls-services (urn:ietf:params:xml:ns:rls-services). During ongoing specification work, the following XML validation problems have been identified in the instances of these schemas that are provided by IANA in the XML schema repository [1]. Validation problems in urn:ietf:params:xml:ns:resource-lists Schema as available from [2] This file triggers the following validation errors (using Xerces): SystemID:http://www.iana.org/assignments/xml-registry/schema/resource-lists.xsd Position: 4:35 Description: cos-nonambig: WC[##other:"urn:ietf:params:xml:ns:resource-lists"] and WC[##other:"urn:ietf:params:xml:ns:resource-lists"] (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles. URL: http://www.w3.org/TR/xmlschema-1/#cos-nonambig SystemID: http://www.iana.org/assignments/xml-registry/schema/resource-lists.xsd Position: 10:29 Description: cos-nonambig: WC[##other:"urn:ietf:params:xml:ns:resource-lists"] and WC[##other:"urn:ietf:params:xml:ns:resource-lists"] (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles. URL: http://www.w3.org/TR/xmlschema-1/#cos-nonambig A comparison has shown that the file in the IANA repository is different from what has been defined in section 3.2 of RFC 4826. Furthermore, it has been noted that the schema in RFC 4826 actually does validate. Validation problems in urn:ietf:params:xml:ns:rls-services Schema as available from [3] This XML schema imports the resource-lists schema, however does not provide a schema location for it. Due to this, the rls-services schema does not validate because the validator can not fetch the referenced schema. It is therefore suggested to add a schemaLocation attribute to the declaration of the rls-services XML schema instance in the IANA repository. OMA ARC and MWG would furthermore like to inform you of the following finding (even though it does not constitute a validation error of the schema): The rls-services schema defined in section 4.2 of RFC 4826 differs from the instance in [3] in one processing instruction. More precisely, the version in RFC 4826 contains �processContents="lax"� which is not contained in [3] as highlighted below: References [1] IANA XML Registry, URL: http://www.iana.org/assignments/xml-registry/schema.html [2] http://www.iana.org/assignments/xml-registry/schema/resource-lists.xsd [3] http://www.iana.org/assignments/xml-registry/schema/rls-services.xsd 3 Requested Action(s) IETF is kindly requested to fix the issues indicated above. 4 Conclusion The OMA ARC and MWG groups wish to thank IETF in advance for considering our request, and are looking forward to continued collaboration and exchange. Attachment(s): PDF of original LS from OMA (https://datatracker.ietf.org/documents/LIAISON/file708.pdf) From root@core3.amsl.com Mon Oct 5 07:15:01 2009 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 53B7C3A697D; Mon, 5 Oct 2009 07:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091005141501.53B7C3A697D@core3.amsl.com> Date: Mon, 5 Oct 2009 07:15:01 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-chat-05.txt 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: , X-List-Received-Date: Mon, 05 Oct 2009 14:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Multi-party Chat Using the Message Session Relay Protocol (MSRP) Author(s) : A. Niemi, et al. Filename : draft-ietf-simple-chat-05.txt Pages : 32 Date : 2009-10-05 The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-simple-chat-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-05071237.I-D@ietf.org> --NextPart-- From geir.sandbakken@tandberg.com Mon Oct 5 07:20:07 2009 Return-Path: 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 F3F3C3A68BB for ; Mon, 5 Oct 2009 07:20:06 -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 d4++PRgVW+7Z for ; Mon, 5 Oct 2009 07:20:06 -0700 (PDT) Received: from mail186.messagelabs.com (mail186.messagelabs.com [85.158.138.131]) by core3.amsl.com (Postfix) with SMTP id 73B3E3A6805 for ; Mon, 5 Oct 2009 07:20:05 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: geir.sandbakken@tandberg.com X-Msg-Ref: server-15.tower-186.messagelabs.com!1254752499!3282432!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 8087 invoked from network); 5 Oct 2009 14:21:39 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-15.tower-186.messagelabs.com with SMTP; 5 Oct 2009 14:21:39 -0000 Received: from ultra.eu.tandberg.int ([10.47.1.15]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 16:21:39 +0200 Received: from [10.47.2.105] (GSandbakkenT61.rd.tandberg.com [10.47.2.105]) by ultra.eu.tandberg.int (8.13.1/8.13.1) with ESMTP id n95ELcCe014106 for ; Mon, 5 Oct 2009 16:21:38 +0200 Message-ID: <4ACA00F2.60709@tandberg.com> Date: Mon, 05 Oct 2009 16:21:38 +0200 From: Geir Arne Sandbakken User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Simple Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 05 Oct 2009 14:21:39.0051 (UTC) FILETIME=[271D23B0:01CA45C7] Subject: [Simple] Multi-party Chat version 05 submitted 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: , X-List-Received-Date: Mon, 05 Oct 2009 14:20:07 -0000 A new version of “Multi-party Chat Using the Message Session Relay Protocol (MSRP)” has been submitted. The new version can be found here: http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-05.txt Additions and changes from -04 based on the WGLC Summary: 1. Architectural diagrams or descriptions clarifying MSRP switch role towards MSRP relay, endpoints and focus - Added diagram showing Focus UA, MSRP relays and MSRP switch. - Added reference to MSRP relays to make implementers compare mechanisms. 2. Clean up Section 6.2 on Private Messages - Removed text regarding reports and responses. - Made reference to regular messages - and removed duplicate text. 3. Various Nickname clarifications: terminology, privacy and security - The review listed the Nickname as a missing identifier. Nicknames in simple-chat are not part of the identifiers of which one can populate in the To header field of the Message/CPIM wrapper. Nicknames are more like display names, but unique inside a chat room. - Rephrased section 7.1, and cleaned up the terminology. - Added a Nickname paragraph under the security considerations. - Did not add a time out - as a Nickname is not an identifier to be used for message relaying. Only used for display purposes, and it is the policy of the focus to apply any constraints. 4. Add normative reference to P-Asserted-Identity - Done. 5. Example of a Conference Event Package notification with a nickname element - Done 6. Lots of requirement clean ups. Scary. - Removed REQ-2 talking about other media types - Rephrased REQ-8 - Cleaned up REQ-9 - Cleaned up REQ-10 7. Clarification around conference "unaware" participants - Added text under 5.2 "Joining a chat room". - Made clear that the rest of the document requires clients to be conference aware. 8. MSRP switch needs to be made Message-Id stateful. Add text. - Added text under section 6 "Sending and receiving IM messages" 9. More reporting model update - and removal. - Removed a lot of normative text. - Added separate section for report and response handling 10. Remove mixed media references - Removed REQ-2 talking about other media types - Removed all references to other media types. 11. Add text on side effect when removing chat rooms. - Added text to section 5.x 12. Add Multi-chunk example - Done 13. Remove GRUU example - Done 14. Add error response on private message - Done 15. Various editorial fixes and simplifications - Done 16. Add Mary and Ben to Acknowledgements - Done Thanks, Geir From Jari.Urpalainen@nokia.com Fri Oct 9 01:00:11 2009 Return-Path: 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 8B98928C108 for ; Fri, 9 Oct 2009 01:00:11 -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 U5Ck5Q2GD-JQ for ; Fri, 9 Oct 2009 01:00:10 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 9342028C0E0 for ; Fri, 9 Oct 2009 01:00:10 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9981Wp9010240; Fri, 9 Oct 2009 03:01:51 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 11:00:59 +0300 Received: from mgw-da02.ext.nokia.com ([147.243.128.26]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 11:00:57 +0300 Received: from [172.21.37.235] (esdhcp037235.research.nokia.com [172.21.37.235]) by mgw-da02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9980sbq005627; Fri, 9 Oct 2009 11:00:55 +0300 From: Jari Urpalainen To: ext Ben Campbell In-Reply-To: References: Content-Type: text/plain Date: Fri, 09 Oct 2009 11:00:54 +0300 Message-Id: <1255075254.18223.43.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2009 08:00:58.0356 (UTC) FILETIME=[A2A6AB40:01CA48B6] X-Nokia-AV: Clean Cc: "Louise.Clarke@forapolis.com" , Simple WG , Dean Willis Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance 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: , X-List-Received-Date: Fri, 09 Oct 2009 08:00:11 -0000 On Fri, 2009-10-02 at 20:12 +0200, ext Ben Campbell wrote: > (as SIMPLE co-chair) > > OMA sent a liaison statement to the SIMPLE working group. The > statement's overview reads as follows: > > "This Liaison Statement reports XML validation problems in the XML > schemas that were introduced in RFC 4826 and asks for correction." > > Please read the LS, and send your opinions to the SIMPLE list. A PDF > is available at https://datatracker.ietf.org/documents/LIAISON/file707.pdf > > Thanks! > > Ben. I looked at the statement, and except the copy-paste bugs of IANA files from rfc4826, there's a proposal to add a "schemaLocation" attribute to rls-services schema. This attribute value provides a hint from the author to a processor regarding the location of a schema document. It is an optional value which may help the validation task. Typically however, validators have some means to combine multiple schemas (e.g. does also some magic with multiple schemas), and as such it has also security implications (if tools e.g. try to fetch some external schemas). So imo, in any sane practical service, you'll disable these hints. So they _can_ exist in specs, but they don't help practical work where you must most likely anyhow tweak with these uris. (and fyi, my preference is to use the registered urn's which don't much help practical work either) br, Jari From geir.sandbakken@tandberg.com Fri Oct 9 01:37:41 2009 Return-Path: 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 4E5C428C1E2 for ; Fri, 9 Oct 2009 01:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.67 X-Spam-Level: X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=-2.929, BAYES_20=-0.74] 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 uRmuulvPgzIK for ; Fri, 9 Oct 2009 01:37:40 -0700 (PDT) Received: from mail204.messagelabs.com (mail204.messagelabs.com [194.106.221.19]) by core3.amsl.com (Postfix) with SMTP id 1BB7428C1E9 for ; Fri, 9 Oct 2009 01:37:39 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: geir.sandbakken@tandberg.com X-Msg-Ref: server-14.tower-204.messagelabs.com!1255077560!6554107!8 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 28628 invoked from network); 9 Oct 2009 08:39:23 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-14.tower-204.messagelabs.com with SMTP; 9 Oct 2009 08:39:23 -0000 Received: from oslexcp1.eu.tandberg.int ([10.47.136.29]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 10:39:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Oct 2009 10:39:19 +0200 Message-ID: <9F6ACAE02B6DD040A1E259977622CFDB05154F7E@oslexcp1.eu.tandberg.int> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multi-party chat WGLC? Thread-Index: AcpIu/5lcJ0z/A7ASE+m5A89XL95Rw== From: "Geir Arne Sandbakken" To: X-OriginalArrivalTime: 09 Oct 2009 08:39:21.0393 (UTC) FILETIME=[FF5E3A10:01CA48BB] Subject: [Simple] Multi-party chat WGLC? 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: , X-List-Received-Date: Fri, 09 Oct 2009 08:37:41 -0000 Experts, =20 The 05 version resolves the issues raised in the first WGLC of the = draft. Does the WG think it is ready for another WGLC? =20 Thanks, Geir Arne From ag@ag-projects.com Fri Oct 9 16:37:20 2009 Return-Path: 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 135283A6A6F for ; Fri, 9 Oct 2009 16:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[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 NJm3kC8JDkcZ for ; Fri, 9 Oct 2009 16:37:19 -0700 (PDT) Received: from node05.dns-hosting.info (node05.dns-hosting.info [85.17.186.5]) by core3.amsl.com (Postfix) with ESMTP id 358E03A6A82 for ; Fri, 9 Oct 2009 16:37:18 -0700 (PDT) Received: from cpe-76-186-219-94.tx.res.rr.com ([76.186.219.94] helo=[192.168.66.100]) by node05.dns-hosting.info with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1MwOtH-0003qL-Nj; Sat, 10 Oct 2009 01:28:54 +0200 Message-Id: From: Adrian Georgescu To: Geir Arne Sandbakken In-Reply-To: <9F6ACAE02B6DD040A1E259977622CFDB05154F7E@oslexcp1.eu.tandberg.int> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Oct 2009 18:38:51 -0500 References: <9F6ACAE02B6DD040A1E259977622CFDB05154F7E@oslexcp1.eu.tandberg.int> X-Mailer: Apple Mail (2.936) X-SA-Exim-Connect-IP: 76.186.219.94 X-SA-Exim-Mail-From: ag@ag-projects.com X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) Cc: simple@ietf.org Subject: Re: [Simple] Multi-party chat WGLC? 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: , X-List-Received-Date: Fri, 09 Oct 2009 23:37:20 -0000 I am interested to see this moving forward. I will review it and get back to the list with my comments. -- Adrian On Oct 9, 2009, at 3:39 AM, Geir Arne Sandbakken wrote: > Experts, > > The 05 version resolves the issues raised in the first WGLC of the > draft. Does the WG think it is ready for another WGLC? > > Thanks, > Geir Arne > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From deepanshu@huawei.com Sun Oct 11 20:09:26 2009 Return-Path: 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 2AA483A68D9 for ; Sun, 11 Oct 2009 20:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 mAZRIfOeu0lT for ; Sun, 11 Oct 2009 20:09:25 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 181F83A6828 for ; Sun, 11 Oct 2009 20:09:25 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRD00HV7SRCY6@szxga01-in.huawei.com> for simple@ietf.org; Mon, 12 Oct 2009 11:09:12 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRD00ALWSRCRB@szxga01-in.huawei.com> for simple@ietf.org; Mon, 12 Oct 2009 11:09:12 +0800 (CST) Received: from d57531v ([10.168.86.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRD007NKSRB0J@szxml04-in.huawei.com> for simple@ietf.org; Mon, 12 Oct 2009 11:09:12 +0800 (CST) Date: Mon, 12 Oct 2009 11:09:14 +0800 From: Deepanshu Gautam To: simple@ietf.org Message-id: <008601ca4ae9$60bdb040$4056a80a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_1E0/3JIIrAGCQXljtCscHg)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Simple] New Draft Posted 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: , X-List-Received-Date: Mon, 12 Oct 2009 03:09:26 -0000 This is a multi-part message in MIME format. --Boundary_(ID_1E0/3JIIrAGCQXljtCscHg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Dear All, Moving forward with the concept of "Quick Answer", i have just posted a draft with detaild proposal and intentions. The draft can be found at http://www.ietf.org/id/draft-gautam-simple-quick-answer-00.txt I would appreciate any comments/suggestions/questions from the group. Regards Deepanshu Gautam --Boundary_(ID_1E0/3JIIrAGCQXljtCscHg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Dear All,
 
Moving forward with the concept of "Quick Answer", i have just posted a draft with detaild proposal and intentions. The draft can be found at
 
I would appreciate any comments/suggestions/questions from the group.
 
 
Regards
Deepanshu Gautam
--Boundary_(ID_1E0/3JIIrAGCQXljtCscHg)-- From pkyzivat@cisco.com Mon Oct 12 06:22:30 2009 Return-Path: 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 7E6D63A6836 for ; Mon, 12 Oct 2009 06:22:30 -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 MeJJU3yfqkIL for ; Mon, 12 Oct 2009 06:22:29 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 486533A63EC for ; Mon, 12 Oct 2009 06:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2504; q=dns/txt; s=rtpiport01001; t=1255353750; x=1256563350; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20I-D=20Action:draft-gautam-simple-quick-answer-00 .txt|Date:=20Mon,=2012=20Oct=202009=2009:22:28=20-0400 |Message-ID:=20<4AD32D94.3020102@cisco.com>|To:=20Deepans hu=20Gautam=20|CC:=20Simple=20WG=20 |MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<200910 12031501.6F0183A68E5@core3.amsl.com>|References:=20<20091 012031501.6F0183A68E5@core3.amsl.com>; bh=Ly/MdxQMcA6hF3ZbUXV/oqMcRPnxWs0qEHWgs0492y0=; b=m+pYWasuPz3Wm6rzxSU+OgXcYGl2ITQrJDCLSeGRAl4rC5LObBTTbym4 e/lmxgItZPT2eqWQv9099Y7f/ujA9QeniUWYX1g92tcbh6RsogXw6/gRx QKEM6+LIs2hTCT5OpVHDTTh1yIRjVqTpP3z7LTG/Kwkv9J3tyoznejv2z 0=; Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANnK0kpAZnwM/2dsb2JhbADAKJZmhC0E X-IronPort-AV: E=Sophos;i="4.44,546,1249257600"; d="scan'208";a="62563439" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 12 Oct 2009 13:22:29 +0000 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.14.3) with ESMTP id n9CDMTCG017304; Mon, 12 Oct 2009 13:22:29 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 09:22:29 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 09:22:28 -0400 Message-ID: <4AD32D94.3020102@cisco.com> Date: Mon, 12 Oct 2009 09:22:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Deepanshu Gautam References: <20091012031501.6F0183A68E5@core3.amsl.com> In-Reply-To: <20091012031501.6F0183A68E5@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2009 13:22:28.0788 (UTC) FILETIME=[0BE23F40:01CA4B3F] Cc: Simple WG Subject: Re: [Simple] I-D Action:draft-gautam-simple-quick-answer-00.txt 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: , X-List-Received-Date: Mon, 12 Oct 2009 13:22:30 -0000 I just did a quick skim of this draft. AFAICT, this draft is proposing a mechanism for configuring/provisioning UACs with some information, and for updating the information that is included in that provisioning. I cannot think of any good reason why there should be a *unique* mechanism for this particular configuration information, in contrast to all the other information that a UA may need to be configured with. For instance, the management of this information is conceptually no different than ring tone data that I might want to configure for my UA(s), or buddies I might want to have in my buddy list. There is already a framework for getting configuration data into the UA, but less of one for updating that information. IMO it would make for sense to focus on that general problem, and on fitting this particular data into that framework. Thanks, Paul The existing Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Quick Answer for SIMPLE > Author(s) : D. Gautamn > Filename : draft-gautam-simple-quick-answer-00.txt > Pages : 10 > Date : 2009-10-11 > > In instant messaging system, it is useful to have some readily > available IM (text, audio or video) which can be sent in case of the > receiver is too busy to type/speak/record for a reply. These short > IM (here after referred as QA - Quick Answer) can be created, stored > and used when needed. This document defines a new QA content type > and XML namespace that conveys QA between two entities. The QAs are > delivered to the instant messaging sender in the same manner as the > instant messages themselves. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-gautam-simple-quick-answer-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From ben@nostrum.com Mon Oct 12 14:19:33 2009 Return-Path: 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 836543A67FD for ; Mon, 12 Oct 2009 14:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 od4BCT3QGmsO for ; Mon, 12 Oct 2009 14:19:32 -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 B09823A67FC for ; Mon, 12 Oct 2009 14:19:31 -0700 (PDT) Received: from [172.16.3.213] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9CLJUif008881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 12 Oct 2009 16:19:30 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Mon, 12 Oct 2009 16:19:30 -0500 Message-Id: <44AA4BAD-2C70-4109-AF11-6B7BCEAF4100@nostrum.com> To: Simple WG Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Simple] IETF76 Agenda Requests 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: , X-List-Received-Date: Mon, 12 Oct 2009 21:19:33 -0000 The Hiroshima meeting is coming up soon. We don't have a lot of meeting time, so we really need to spend use this time to discuss open issues on workgroup milestone items. Please send any agenda requests to the SIMPLE chairs no later than Friday, 23 October. Please include the name of the draft(s), and the open issues that we need to address. Thanks! Ben. From ben@estacado.net Mon Oct 12 15:05:31 2009 Return-Path: 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 DB3CF3A67EA for ; Mon, 12 Oct 2009 15:05:31 -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 Ol6tVgvjLPnP for ; Mon, 12 Oct 2009 15:05:31 -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 9F4223A6902 for ; Mon, 12 Oct 2009 15:05:30 -0700 (PDT) Received: from [172.16.3.213] (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n9CM5Sse001082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Oct 2009 17:05:29 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Ben Campbell In-Reply-To: <9F6ACAE02B6DD040A1E259977622CFDB05154F7E@oslexcp1.eu.tandberg.int> Date: Mon, 12 Oct 2009 17:05:28 -0500 Content-Transfer-Encoding: 7bit Message-Id: <1A746A4E-4154-4BA5-B7E7-AD88BFD12BC5@estacado.net> References: <9F6ACAE02B6DD040A1E259977622CFDB05154F7E@oslexcp1.eu.tandberg.int> To: Geir Arne Sandbakken X-Mailer: Apple Mail (2.1076) Cc: simple@ietf.org Subject: [Simple] Message Stateful MSRP Switches (was Re: Multi-party chat WGLC?) 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: , X-List-Received-Date: Mon, 12 Oct 2009 22:05:32 -0000 I'm still in the process of reviewing this version, but I want to point out one particular change that went in as a result of the previous WGLC feedback: Both versions rely on "message/cpim" metatdata for certain MSRP message routing and authorization decisions. The previous version overlooked the possibility of a large message being sent as a series of chunks. Chunking occurs after MIME encoding. When a message/cpim document gets chunked, the metadata will only be present in the first chunk. Revision 4 assumed that each MSRP send request would include the metatdata. Revision 5 deals with this by requiring the MSRP switch to be message stateful. It has to remember the message/cpim metadata until it processes all chunks of a given message. This metadata "state" is indexed by the MSRP Message-ID header field., which is the same for all chunks of a given message. IMO, this is the best approach of any that I have heard of so far. It is unfortunate that we need to keep message state, but I don't see an alternative short of forbidding chunking of messages to an MSRP switch. What do other people think about this? Thanks! Ben. On Oct 9, 2009, at 3:39 AM, Geir Arne Sandbakken wrote: > Experts, > > The 05 version resolves the issues raised in the first WGLC of the > draft. Does the WG think it is ready for another WGLC? > > Thanks, > Geir Arne > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Mon Oct 12 19:17:35 2009 Return-Path: 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 63CDF28C2E3 for ; Mon, 12 Oct 2009 19:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 dUfbSAjNp3Vw for ; Mon, 12 Oct 2009 19:17:34 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 28B3028C2CB for ; Mon, 12 Oct 2009 19:17:33 -0700 (PDT) X-AuditID: c1b4fb3e-b7b81ae0000009d4-2d-4ad3e33d8b9a Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 94.F1.02516.D33E3DA4; Tue, 13 Oct 2009 04:17:33 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 04:17:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2009 04:17:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSRP-ACM: c/m versus a=path, and how to update 4975 session matching Thread-Index: AcpJ61LScuFSZY5zT/KkD5h60f9nfw== From: "Christer Holmberg" To: X-OriginalArrivalTime: 13 Oct 2009 02:17:33.0215 (UTC) FILETIME=[52AEAAF0:01CA4BAB] X-Brightmail-Tracker: AAAAAA== Subject: [Simple] MSRP-ACM: c/m versus a=path, and how to update 4975 session matching 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: , X-List-Received-Date: Tue, 13 Oct 2009 02:17:35 -0000 Hi, One of the remaining open issues of MSRP ACM was whether we should use = the SDP c/m line for routing (as for other media), which is what is = currently described in the draft, or whether we should continue using = the a=3Dpath attribute as in legacy MSRP (RFC 4975). A group of interested people have been discussing this quite much since = Stockholm, and our suggestion would be that we would use the a=3Dpath = attribute. The reason is that it does not re-define the MSRP routing = mechanism completely, and we do not need to describe how To/From-Path = headers are build based on c/m lines etc. But, if anyone still thinks = that we should use the c/m line for routing, please indicate so on the = list asap. The next issue, which was briefly discussed already in Stockholm, is the = issue regarding ACM-legacy interoperability when an intermediate = modifies the SDP a=3Dpath attribute (or, in case of c/m routing, the c/m = parameters). Section 7.3 RFC 4975 defines a session maching procdure, how a client = when it receives an MSRP message checks whether the message belongs to = an ongoing session. The client does that by comparing the received = To-Path URI with SDP a=3Dpath URIs for ongoing session(s). The whole = URI (address information part, session-id part etc) is used for the = check, so if a ACM supporting intermediate modifies the SDP a=3Dpath = attribute (but do not modify the associated MSRP messages), the session = match will produce a failure at the legacy client. The proposed mechanism to solve that is to update RFC 4975 (most likely = only a change to section 7.3 is needed), and say that only the = session-id part of the URI is used for the matching. Again, this was = discussed briefly already in Stockholm, but we decided to first deal = with the a=3Dpath versus c/m routing issue. The exact procedure for the 4975 update is still to be discussed, and = our intention is to spend meeting time in Hiroshima for that. Thanks! Christer From deepanshu@huawei.com Tue Oct 13 01:44:55 2009 Return-Path: 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 E11DA3A682D for ; Tue, 13 Oct 2009 01:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 3a2OL+C7V3-s for ; Tue, 13 Oct 2009 01:44:55 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A573028C0FF for ; Tue, 13 Oct 2009 01:44:54 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRG000CB2XWF6@szxga03-in.huawei.com> for simple@ietf.org; Tue, 13 Oct 2009 16:44:21 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRG0063B2XWJE@szxga03-in.huawei.com> for simple@ietf.org; Tue, 13 Oct 2009 16:44:20 +0800 (CST) Received: from d57531v ([10.168.86.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRG0046S2XW5B@szxml04-in.huawei.com> for simple@ietf.org; Tue, 13 Oct 2009 16:44:20 +0800 (CST) Date: Tue, 13 Oct 2009 16:44:20 +0800 From: Deepanshu Gautam To: Paul Kyzivat Message-id: <018e01ca4be1$5b523740$4056a80a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20091012031501.6F0183A68E5@core3.amsl.com> <4AD32D94.3020102@cisco.com> Cc: Simple WG Subject: Re: [Simple] I-D Action:draft-gautam-simple-quick-answer-00.txt 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: , X-List-Received-Date: Tue, 13 Oct 2009 08:44:56 -0000 Hi, Thanks for your comments, some clarification are provided inline >I just did a quick skim of this draft. > AFAICT, this draft is proposing a mechanism for configuring/provisioning > UACs with some information, and for updating the information that is > included in that provisioning. This draft is not proposing a configuration/provisioning mechanism itself instead it is proposing things (platform or base or protocol ) needed for that kind of configuration. It does explains what kind of configuration is needed but doesn't say how to do it. The type of information (i.e Quick Answer) also plays a significant role in the feasibility of the proposal. The draft is not intending for all the information but for one specific information with particular characterstics. Further, it is not saying anything about updation, but for sure its a good thing to include. > > I cannot think of any good reason why there should be a *unique* mechanism > for this particular configuration information, in contrast to all the > other information that a UA may need to be configured with. Because the solution proposed for this information involves MESSAGE carrying something which is not a regular IM (firstly, the draft tries to make this possible) and require some special behavior (secondly, the draft tries to specify those behavior) from the involved entities such as registrar, UAC, UAS. The question is whether we think that this solution is feasible for the concept of Quick Answer or not. > > For instance, the management of this information is conceptually no > different than ring tone data that I might want to configure for my UA(s), > or buddies I might want to have in my buddy list. Differences would be: You may not want to change/choose the ring tone everytime you get a message or call. You generally don't create a ring tone (some sort of user generated content), you just get it from SP You may not want to synchronize ring tones between your UA and server. ... > > There is already a framework for getting configuration data into the UA, > but less of one for updating that information. IMO it would make for sense > to focus on that general problem, and on fitting this particular data into > that framework. I think trying to fit this data in the avaliable configuration framework (in other words, trying to make it possible on the top of that framework) will involve much of overhead which may not be required/worth-taking for such a simple concept. This can be simple done as stated in 1-2 (technical solutions) pages in the draft. For instance, there is no need to define a profile data, sending subsequent subscription request (enrolling) and getting corresponding notification, retrieving content, ... for this. I duly agree with you on the feasibility of the concept of updation here and will work on that part. Adding updation concept to the whole avaliable configuration framework is, for sure, a right thing to do as well, but it is not something being considered here at this point of time with this draft. > > Thanks, > Paul ----- Original Message ----- From: "Paul Kyzivat" To: "Deepanshu Gautam" Cc: "Simple WG" Sent: Monday, October 12, 2009 9:22 PM Subject: Re: I-D Action:draft-gautam-simple-quick-answer-00.txt >I just did a quick skim of this draft. > AFAICT, this draft is proposing a mechanism for configuring/provisioning > UACs with some information, and for updating the information that is > included in that provisioning. > > I cannot think of any good reason why there should be a *unique* mechanism > for this particular configuration information, in contrast to all the > other information that a UA may need to be configured with. > > For instance, the management of this information is conceptually no > different than ring tone data that I might want to configure for my UA(s), > or buddies I might want to have in my buddy list. > > There is already a framework for getting configuration data into the UA, > but less of one for updating that information. IMO it would make for sense > to focus on that general problem, and on fitting this particular data into > that framework. > > Thanks, > Paul > > The existing > > Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Quick Answer for SIMPLE >> Author(s) : D. Gautamn >> Filename : draft-gautam-simple-quick-answer-00.txt >> Pages : 10 >> Date : 2009-10-11 >> >> In instant messaging system, it is useful to have some readily >> available IM (text, audio or video) which can be sent in case of the >> receiver is too busy to type/speak/record for a reply. These short >> IM (here after referred as QA - Quick Answer) can be created, stored >> and used when needed. This document defines a new QA content type >> and XML namespace that conveys QA between two entities. The QAs are >> delivered to the instant messaging sender in the same manner as the >> instant messages themselves. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-gautam-simple-quick-answer-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From geir.sandbakken@tandberg.com Tue Oct 13 03:03:43 2009 Return-Path: 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 B93DF3A67E7 for ; Tue, 13 Oct 2009 03:03:43 -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 jSbAwH2uOUt1 for ; Tue, 13 Oct 2009 03:03:43 -0700 (PDT) Received: from mail193.messagelabs.com (mail193.messagelabs.com [85.158.140.195]) by core3.amsl.com (Postfix) with SMTP id 8FEC93A680B for ; Tue, 13 Oct 2009 03:03:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: geir.sandbakken@tandberg.com X-Msg-Ref: server-15.tower-193.messagelabs.com!1255428222!26882628!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 15088 invoked from network); 13 Oct 2009 10:03:42 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-15.tower-193.messagelabs.com with SMTP; 13 Oct 2009 10:03:42 -0000 Received: from oslexcp1.eu.tandberg.int ([10.47.136.29]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 12:03:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2009 12:03:41 +0200 Message-ID: <9F6ACAE02B6DD040A1E259977622CFDB0673BC9C@oslexcp1.eu.tandberg.int> In-Reply-To: <1A746A4E-4154-4BA5-B7E7-AD88BFD12BC5@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Message Stateful MSRP Switches (was Re: Multi-party chatWGLC?) Thread-Index: AcpLiCS46ki45zZ1SyK0BKecgXFEqQAYvngA References: <9F6ACAE02B6DD040A1E259977622CFDB05154F7E@oslexcp1.eu.tandberg.int> <1A746A4E-4154-4BA5-B7E7-AD88BFD12BC5@estacado.net> From: "Geir Arne Sandbakken" To: "Ben Campbell" X-OriginalArrivalTime: 13 Oct 2009 10:03:42.0651 (UTC) FILETIME=[71C3E8B0:01CA4BEC] Cc: simple@ietf.org Subject: Re: [Simple] Message Stateful MSRP Switches (was Re: Multi-party chatWGLC?) 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: , X-List-Received-Date: Tue, 13 Oct 2009 10:03:43 -0000 Ben, It will be hard to avoid being stateful. The headers of the "message/cpim" wrapper might be split in two chunks. The switch must be stateful until a full header set is received. The chunk example in -05 shows a split in the headers of the "message/cpim" wrapper. Thanks, Geir Arne -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Ben Campbell Sent: 13. oktober 2009 00:05 To: Geir Arne Sandbakken Cc: simple@ietf.org Subject: [Simple] Message Stateful MSRP Switches (was Re: Multi-party chatWGLC?) I'm still in the process of reviewing this version, but I want to =20 point out one particular change that went in as a result of the =20 previous WGLC feedback: Both versions rely on "message/cpim" metatdata for certain MSRP =20 message routing and authorization decisions. The previous version =20 overlooked the possibility of a large message being sent as a series =20 of chunks. Chunking occurs after MIME encoding. When a message/cpim =20 document gets chunked, the metadata will only be present in the first =20 chunk. Revision 4 assumed that each MSRP send request would include =20 the metatdata. Revision 5 deals with this by requiring the MSRP switch to be message =20 stateful. It has to remember the message/cpim metadata until it =20 processes all chunks of a given message. This metadata "state" is =20 indexed by the MSRP Message-ID header field., which is the same for =20 all chunks of a given message. IMO, this is the best approach of any that I have heard of so far. It =20 is unfortunate that we need to keep message state, but I don't see an =20 alternative short of forbidding chunking of messages to an MSRP switch. What do other people think about this? Thanks! Ben. On Oct 9, 2009, at 3:39 AM, Geir Arne Sandbakken wrote: > Experts, > > The 05 version resolves the issues raised in the first WGLC of the =20 > draft. Does the WG think it is ready for another WGLC? > > Thanks, > Geir Arne > _______________________________________________ > 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 ben@estacado.net Tue Oct 13 06:15:17 2009 Return-Path: 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 9ACB928C190 for ; Tue, 13 Oct 2009 06:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[AWL=2.450, 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 QBODyC5DQhhb for ; Tue, 13 Oct 2009 06:15:16 -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 3C47528C170 for ; Tue, 13 Oct 2009 06:15:15 -0700 (PDT) Received: from [10.0.1.8] (adsl-68-94-15-159.dsl.rcsntx.swbell.net [68.94.15.159]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n9DDF7w7064335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Oct 2009 08:15:13 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Ben Campbell In-Reply-To: <9F6ACAE02B6DD040A1E259977622CFDB0673BC9C@oslexcp1.eu.tandberg.int> Date: Tue, 13 Oct 2009 08:15:04 -0500 Content-Transfer-Encoding: 7bit Message-Id: <0D02189B-9FDE-41EE-8075-F1D3FA08622E@estacado.net> References: <9F6ACAE02B6DD040A1E259977622CFDB05154F7E@oslexcp1.eu.tandberg.int> <1A746A4E-4154-4BA5-B7E7-AD88BFD12BC5@estacado.net> <9F6ACAE02B6DD040A1E259977622CFDB0673BC9C@oslexcp1.eu.tandberg.int> To: "Geir Arne Sandbakken" X-Mailer: Apple Mail (2.1076) Cc: simple@ietf.org Subject: Re: [Simple] Message Stateful MSRP Switches (was Re: Multi-party chatWGLC?) 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: , X-List-Received-Date: Tue, 13 Oct 2009 13:15:17 -0000 On Oct 13, 2009, at 5:03 AM, Geir Arne Sandbakken wrote: > Ben, > > It will be hard to avoid being stateful. The headers of the > "message/cpim" wrapper might be split in two chunks. The switch > must be > stateful until a full header set is received. The chunk example in -05 > shows a split in the headers of the "message/cpim" wrapper. > Just to be clear--I agree that it will be hard not to be stateful. I didn't mean to object to the change--I'm just trying to make sure everyone notices and understands it. > Thanks, > Geir Arne > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf > Of Ben Campbell > Sent: 13. oktober 2009 00:05 > To: Geir Arne Sandbakken > Cc: simple@ietf.org > Subject: [Simple] Message Stateful MSRP Switches (was Re: Multi-party > chatWGLC?) > > > > I'm still in the process of reviewing this version, but I want to > point out one particular change that went in as a result of the > previous WGLC feedback: > > Both versions rely on "message/cpim" metatdata for certain MSRP > message routing and authorization decisions. The previous version > overlooked the possibility of a large message being sent as a series > of chunks. Chunking occurs after MIME encoding. When a message/cpim > document gets chunked, the metadata will only be present in the first > chunk. Revision 4 assumed that each MSRP send request would include > the metatdata. > > Revision 5 deals with this by requiring the MSRP switch to be message > stateful. It has to remember the message/cpim metadata until it > processes all chunks of a given message. This metadata "state" is > indexed by the MSRP Message-ID header field., which is the same for > all chunks of a given message. > > IMO, this is the best approach of any that I have heard of so far. It > is unfortunate that we need to keep message state, but I don't see an > alternative short of forbidding chunking of messages to an MSRP > switch. > > What do other people think about this? > > Thanks! > > Ben. > > > > On Oct 9, 2009, at 3:39 AM, Geir Arne Sandbakken wrote: > >> Experts, >> >> The 05 version resolves the issues raised in the first WGLC of the >> draft. Does the WG think it is ready for another WGLC? >> >> Thanks, >> Geir Arne >> _______________________________________________ >> 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 pkyzivat@cisco.com Tue Oct 13 06:16:11 2009 Return-Path: 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 580F528C198 for ; Tue, 13 Oct 2009 06:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 O2iFgQDmkgz0 for ; Tue, 13 Oct 2009 06:16:10 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DC9D628C16C for ; Tue, 13 Oct 2009 06:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=8218; q=dns/txt; s=rtpiport01001; t=1255439771; x=1256649371; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20I-D=20Action:draft-gautam-simple-quick-answer-00 .txt|Date:=20Tue,=2013=20Oct=202009=2009:16:09=20-0400 |Message-ID:=20<4AD47D99.1070506@cisco.com>|To:=20Deepans hu=20Gautam=20|CC:=20Simple=20WG=20 |MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<018e01 ca4be1$5b523740$4056a80a@china.huawei.com>|References:=20 <20091012031501.6F0183A68E5@core3.amsl.com>=20<4AD32D94.3 020102@cisco.com>=20<018e01ca4be1$5b523740$4056a80a@china .huawei.com>; bh=GgZkayhrqWMN+tSCCHqOkvkzUMPi9lkf6ayX303W4YU=; b=Bn673HxFh6k2drTWqGzlW3BBbtVu/j+tNY2olhwM7AROh7bQa9MUNQyr KZY9a8+rB3+TO5yW06fQvdwie+Mjb15t+pySZIoycTdKOFpqrim+gcPBD THSjyC48qA9Vtadm+q/BBatMsYUECqZbExVRybpspe/1VV+GKXzU7QSBm A=; Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADMa1EpAZnwN/2dsb2JhbAC/RJd3hC0E X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208";a="62760967" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 13 Oct 2009 13:16:10 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9DDGA4Y008682; Tue, 13 Oct 2009 13:16:10 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.3959); Tue, 13 Oct 2009 09:16:10 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 09:16:10 -0400 Message-ID: <4AD47D99.1070506@cisco.com> Date: Tue, 13 Oct 2009 09:16:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Deepanshu Gautam References: <20091012031501.6F0183A68E5@core3.amsl.com> <4AD32D94.3020102@cisco.com> <018e01ca4be1$5b523740$4056a80a@china.huawei.com> In-Reply-To: <018e01ca4be1$5b523740$4056a80a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Oct 2009 13:16:10.0033 (UTC) FILETIME=[548A9210:01CA4C07] Cc: Simple WG Subject: Re: [Simple] I-D Action:draft-gautam-simple-quick-answer-00.txt 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: , X-List-Received-Date: Tue, 13 Oct 2009 13:16:11 -0000 In general it is easier, in the short term, to make a specific solution for a specific problem than it is to generalize the problem and solve that. But if you make lots of little focused mechanisms things overall get very complex and difficult to implement. I personally find the problem itself not very interesting, and especially not compelling enough to design a specific mechanism for. If it were simply one more piece of configuration information that you were integrating into a general mechanism, then that wouldn't be an issue. A bit more inlne... Deepanshu Gautam wrote: > Hi, > > Thanks for your comments, some clarification are provided inline > >> I just did a quick skim of this draft. >> AFAICT, this draft is proposing a mechanism for configuring/provisioning >> UACs with some information, and for updating the information that is >> included in that provisioning. > This draft is not proposing a configuration/provisioning mechanism itself > instead it is proposing things (platform or base or protocol ) needed for > that kind of configuration. It does explains what kind of configuration is > needed but doesn't say how to do it. > The type of information (i.e Quick Answer) also plays a significant role in > the feasibility of the proposal. The draft is not intending for all the > information but for one specific information with particular > characterstics. > Further, it is not saying anything > about updation, but for sure its a good thing to include. As I read the draft, the "QA Holder" is a provisioning server for this information. The UA is "provisioned/configured" with quick answers by the QA holder, and the UA can update the QA Holder with new/revised quick answers. So the QA Holder is a "micro" provisioning server, dedicated to this one kind of information. >> I cannot think of any good reason why there should be a *unique* >> mechanism >> for this particular configuration information, in contrast to all the >> other information that a UA may need to be configured with. > Because the solution proposed for this information involves MESSAGE > carrying > something which is not a regular IM (firstly, the draft tries to make this > possible) and require some special behavior (secondly, the draft tries to > specify those behavior) from the involved entities such as registrar, UAC, > UAS. The question is whether we think that this solution is feasible for > the > concept of Quick Answer or not. The use of MESSAGE is just a mechanism for achieving your end. It is in no way integral to the concept. >> For instance, the management of this information is conceptually no >> different than ring tone data that I might want to configure for my >> UA(s), >> or buddies I might want to have in my buddy list. > Differences would be: > You may not want to change/choose the ring tone everytime you get a message > or call. I might not what to change my quick answers every time I get a message or call either. > You generally don't create a ring tone (some sort of user generated > content), you just get it from SP > You may not want to synchronize ring tones between your UA and server. I might not, but then I might. E.g. I might hunt up and download my new favorite ring tone while using one phone, and then want that same ring tone on my other phones. (Of course the SP would prefer that I pay for it again for each phone, but that's another story.) >> >> There is already a framework for getting configuration data into the UA, >> but less of one for updating that information. IMO it would make for >> sense >> to focus on that general problem, and on fitting this particular data >> into >> that framework. > I think trying to fit this data in the avaliable configuration framework > (in > other words, trying to make it possible on the top of that framework) will > involve much of overhead which may not be required/worth-taking for such a > simple concept. You can say the same about almost everything. The first use of sub/not was (I think) for message waiting. Certainly there were other ways that the MWI info could have been hacked into sip. But it made more sense to have a generic mechanism. There has been a lot of criticism of the configuration framework, including proposals to start over on it. Those have some merit. But I think there is little doubt that some sort of generic configuration mechanism is important. Building a separate mechanism for each piece of configuration information that comes along does not appeal to me. Thanks, Paul > This can be simple done as stated in 1-2 (technical > solutions) pages in the draft. For instance, there is no need to define a > profile data, sending subsequent subscription request (enrolling) and > getting corresponding notification, retrieving content, ... for this. > I duly agree with you on the feasibility of the concept of updation here > and > will work on that part. Adding updation concept to the whole avaliable > configuration framework is, for sure, a right thing to do as well, but it > is not something being considered here at this point of time with this > draft. >> >> Thanks, >> Paul > > ----- Original Message ----- From: "Paul Kyzivat" > To: "Deepanshu Gautam" > Cc: "Simple WG" > Sent: Monday, October 12, 2009 9:22 PM > Subject: Re: I-D Action:draft-gautam-simple-quick-answer-00.txt > > >> I just did a quick skim of this draft. >> AFAICT, this draft is proposing a mechanism for configuring/provisioning >> UACs with some information, and for updating the information that is >> included in that provisioning. >> >> I cannot think of any good reason why there should be a *unique* >> mechanism >> for this particular configuration information, in contrast to all the >> other information that a UA may need to be configured with. >> >> For instance, the management of this information is conceptually no >> different than ring tone data that I might want to configure for my >> UA(s), >> or buddies I might want to have in my buddy list. >> >> There is already a framework for getting configuration data into the UA, >> but less of one for updating that information. IMO it would make for >> sense >> to focus on that general problem, and on fitting this particular data >> into >> that framework. >> >> Thanks, >> Paul >> >> The existing >> >> Internet-Drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : Quick Answer for SIMPLE >>> Author(s) : D. Gautamn >>> Filename : draft-gautam-simple-quick-answer-00.txt >>> Pages : 10 >>> Date : 2009-10-11 >>> >>> In instant messaging system, it is useful to have some readily >>> available IM (text, audio or video) which can be sent in case of the >>> receiver is too busy to type/speak/record for a reply. These short >>> IM (here after referred as QA - Quick Answer) can be created, stored >>> and used when needed. This document defines a new QA content type >>> and XML namespace that conveys QA between two entities. The QAs are >>> delivered to the instant messaging sender in the same manner as the >>> instant messages themselves. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-gautam-simple-quick-answer-00.txt >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > From deepanshu@huawei.com Wed Oct 14 01:50:35 2009 Return-Path: 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 C347628C104 for ; Wed, 14 Oct 2009 01:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, SARE_LWSHORTT=1.24, STOX_REPLY_TYPE=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 dWIDoBe8zzqt for ; Wed, 14 Oct 2009 01:50:34 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 097C53A6878 for ; Wed, 14 Oct 2009 01:50:34 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRH00867XW9AQ@szxga03-in.huawei.com> for simple@ietf.org; Wed, 14 Oct 2009 16:50:33 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRH006LAXW8II@szxga03-in.huawei.com> for simple@ietf.org; Wed, 14 Oct 2009 16:50:33 +0800 (CST) Received: from d57531v ([10.168.86.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRH0089IXW8MK@szxml06-in.huawei.com> for simple@ietf.org; Wed, 14 Oct 2009 16:50:32 +0800 (CST) Date: Wed, 14 Oct 2009 16:50:32 +0800 From: Deepanshu Gautam To: Paul Kyzivat Message-id: <013d01ca4cab$638639a0$4056a80a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20091012031501.6F0183A68E5@core3.amsl.com> <4AD32D94.3020102@cisco.com> <018e01ca4be1$5b523740$4056a80a@china.huawei.com> <4AD47D99.1070506@cisco.com> Cc: Simple WG Subject: Re: [Simple] I-D Action:draft-gautam-simple-quick-answer-00.txt 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: , X-List-Received-Date: Wed, 14 Oct 2009 08:50:35 -0000 The issues with using config. framework for this would be: 1. The framework doesn't address the creation of profile data, which is the integral part of this concept, in terms of QA Creation. 2. In case of sub/not: *subsequent* subscribe request are required to remain subscribed for the requested content (which would be QA here). QA need to be fetched eveytime a UA gets registered or UA Holder is updated, which will happen pretty often, i guess. As i said before, why to define a profile data, send subsequent subscription request (enrolling) and get corresponding notification, retrieve content (all what in there in config. framework), if it can be simplified to some extent as stated in the draft. MWI used sub/not because that may be considered optimal for that. For this, sub/not is not required at all, things (configuration/synchronization) can be initiated simply on registration. Anyway, i can think of the following to fit this in the general framework: 1. Depict QA Holder as PDS. And, extend the behavior of PDS as they are defined for QA Holder. In this way there will be no seperate entity proposed, instead the one in config. framework will be extended. 2. As the config. framework leaves the creation of profile data for further standardization activities, the MESSAGE can be considered serving that purpose. Above two are just some initial thoughts, to make it work. Let me know opinion on the above two points, if that seems to be a way forward. I hope we can find a way out. This is a problem which needs to be solved (as simply as it can) . There are real-world requirement for this. For instance, OMA-IM has requirements for this function. one more inline......... ----- Original Message ----- From: "Paul Kyzivat" To: "Deepanshu Gautam" Cc: "Simple WG" Sent: Tuesday, October 13, 2009 9:16 PM Subject: Re: I-D Action:draft-gautam-simple-quick-answer-00.txt > In general it is easier, in the short term, to make a specific solution > for a specific problem than it is to generalize the problem and solve > that. But if you make lots of little focused mechanisms things overall get > very complex and difficult to implement. > > I personally find the problem itself not very interesting, and especially > not compelling enough to design a specific mechanism for. If it were > simply one more piece of configuration information that you were > integrating into a general mechanism, then that wouldn't be an issue. > > A bit more inlne... > > Deepanshu Gautam wrote: >> Hi, >> >> Thanks for your comments, some clarification are provided inline >> >>> I just did a quick skim of this draft. >>> AFAICT, this draft is proposing a mechanism for configuring/provisioning >>> UACs with some information, and for updating the information that is >>> included in that provisioning. >> This draft is not proposing a configuration/provisioning mechanism itself >> instead it is proposing things (platform or base or protocol ) needed for >> that kind of configuration. It does explains what kind of configuration >> is >> needed but doesn't say how to do it. >> The type of information (i.e Quick Answer) also plays a significant role >> in >> the feasibility of the proposal. The draft is not intending for all the >> information but for one specific information with particular >> characterstics. >> Further, it is not saying anything >> about updation, but for sure its a good thing to include. > > As I read the draft, the "QA Holder" is a provisioning server for this > information. The UA is "provisioned/configured" with quick answers by the > QA holder, and the UA can update the QA Holder with new/revised quick > answers. > > So the QA Holder is a "micro" provisioning server, dedicated to this one > kind of information. > >>> I cannot think of any good reason why there should be a *unique* >>> mechanism >>> for this particular configuration information, in contrast to all the >>> other information that a UA may need to be configured with. >> Because the solution proposed for this information involves MESSAGE >> carrying >> something which is not a regular IM (firstly, the draft tries to make >> this >> possible) and require some special behavior (secondly, the draft tries to >> specify those behavior) from the involved entities such as registrar, >> UAC, >> UAS. The question is whether we think that this solution is feasible for >> the >> concept of Quick Answer or not. > > The use of MESSAGE is just a mechanism for achieving your end. It is in no > way integral to the concept. Its not about achieving ends, it is about what is correct and right to do. I agree, there MAY be other ways but what we have on table, at this point of time, is this. Regards Deepanshu > >>> For instance, the management of this information is conceptually no >>> different than ring tone data that I might want to configure for my >>> UA(s), >>> or buddies I might want to have in my buddy list. >> Differences would be: >> You may not want to change/choose the ring tone everytime you get a >> message >> or call. > > I might not what to change my quick answers every time I get a message or > call either. > >> You generally don't create a ring tone (some sort of user generated >> content), you just get it from SP >> You may not want to synchronize ring tones between your UA and server. > > I might not, but then I might. E.g. I might hunt up and download my new > favorite ring tone while using one phone, and then want that same ring > tone on my other phones. > > (Of course the SP would prefer that I pay for it again for each phone, but > that's another story.) > >>> >>> There is already a framework for getting configuration data into the UA, >>> but less of one for updating that information. IMO it would make for >>> sense >>> to focus on that general problem, and on fitting this particular data >>> into >>> that framework. >> I think trying to fit this data in the avaliable configuration framework >> (in >> other words, trying to make it possible on the top of that framework) >> will >> involve much of overhead which may not be required/worth-taking for such >> a >> simple concept. > > You can say the same about almost everything. > The first use of sub/not was (I think) for message waiting. > Certainly there were other ways that the MWI info could have been hacked > into sip. But it made more sense to have a generic mechanism. > > There has been a lot of criticism of the configuration framework, > including proposals to start over on it. Those have some merit. But I > think there is little doubt that some sort of generic configuration > mechanism is important. Building a separate mechanism for each piece of > configuration information that comes along does not appeal to me. > > Thanks, > Paul > >> This can be simple done as stated in 1-2 (technical >> solutions) pages in the draft. For instance, there is no need to define a >> profile data, sending subsequent subscription request (enrolling) and >> getting corresponding notification, retrieving content, ... for this. >> I duly agree with you on the feasibility of the concept of updation here >> and >> will work on that part. Adding updation concept to the whole avaliable >> configuration framework is, for sure, a right thing to do as well, but >> it >> is not something being considered here at this point of time with this >> draft. >>> >>> Thanks, >>> Paul >> >> ----- Original Message ----- From: "Paul Kyzivat" >> To: "Deepanshu Gautam" >> Cc: "Simple WG" >> Sent: Monday, October 12, 2009 9:22 PM >> Subject: Re: I-D Action:draft-gautam-simple-quick-answer-00.txt >> >> >>> I just did a quick skim of this draft. >>> AFAICT, this draft is proposing a mechanism for configuring/provisioning >>> UACs with some information, and for updating the information that is >>> included in that provisioning. >>> >>> I cannot think of any good reason why there should be a *unique* >>> mechanism >>> for this particular configuration information, in contrast to all the >>> other information that a UA may need to be configured with. >>> >>> For instance, the management of this information is conceptually no >>> different than ring tone data that I might want to configure for my >>> UA(s), >>> or buddies I might want to have in my buddy list. >>> >>> There is already a framework for getting configuration data into the UA, >>> but less of one for updating that information. IMO it would make for >>> sense >>> to focus on that general problem, and on fitting this particular data >>> into >>> that framework. >>> >>> Thanks, >>> Paul >>> >>> The existing >>> >>> Internet-Drafts@ietf.org wrote: >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> Title : Quick Answer for SIMPLE >>>> Author(s) : D. Gautamn >>>> Filename : draft-gautam-simple-quick-answer-00.txt >>>> Pages : 10 >>>> Date : 2009-10-11 >>>> >>>> In instant messaging system, it is useful to have some readily >>>> available IM (text, audio or video) which can be sent in case of the >>>> receiver is too busy to type/speak/record for a reply. These short >>>> IM (here after referred as QA - Quick Answer) can be created, stored >>>> and used when needed. This document defines a new QA content type >>>> and XML namespace that conveys QA between two entities. The QAs are >>>> delivered to the instant messaging sender in the same manner as the >>>> instant messages themselves. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-gautam-simple-quick-answer-00.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> From pkyzivat@cisco.com Wed Oct 14 09:51:11 2009 Return-Path: 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 A3C1828C1AC for ; Wed, 14 Oct 2009 09:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 j8LA849v6zyK for ; Wed, 14 Oct 2009 09:51:09 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C33833A67EF for ; Wed, 14 Oct 2009 09:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=11177; q=dns/txt; s=sjiport02001; t=1255539072; x=1256748672; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20I-D=20Action:draft-gautam-simple-quick-answer-00 .txt|Date:=20Wed,=2014=20Oct=202009=2012:51:08=20-0400 |Message-ID:=20<4AD6017C.9060201@cisco.com>|To:=20Deepans hu=20Gautam=20|CC:=20Simple=20WG=20 |MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<013d01 ca4cab$638639a0$4056a80a@china.huawei.com>|References:=20 <20091012031501.6F0183A68E5@core3.amsl.com>=20<4AD32D94.3 020102@cisco.com>=20<018e01ca4be1$5b523740$4056a80a@china .huawei.com>=20<4AD47D99.1070506@cisco.com>=20<013d01ca4c ab$638639a0$4056a80a@china.huawei.com>; bh=pPHHGmhD6ipuzfQjesuCG6MIseR2s9q0j1O4S5rJmRU=; b=kQhQET2tPBEV/2ua4Uc5i9//LcThWk4Yk6kSeWz9LJHbyHOAtqHdqi/D pfG/OLdlycsuoKzzLkBZpxcpb4Cjmhh+TgGJxsU3ceKr+b3quUY2NWIAu 3JmUX9IU5Yf5hhBNAJmmXwFw95wxIpZ60pXwpjIbjGWsYqRJKDBG8nKJc o=; Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFOe1UqrR7H+/2dsb2JhbADCJJhZhC4E X-IronPort-AV: E=Sophos;i="4.44,559,1249257600"; d="scan'208";a="214452589" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2009 16:51:11 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9EGoxWF023902; Wed, 14 Oct 2009 16:51:11 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:51:09 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:51:09 -0400 Message-ID: <4AD6017C.9060201@cisco.com> Date: Wed, 14 Oct 2009 12:51:08 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Deepanshu Gautam References: <20091012031501.6F0183A68E5@core3.amsl.com> <4AD32D94.3020102@cisco.com> <018e01ca4be1$5b523740$4056a80a@china.huawei.com> <4AD47D99.1070506@cisco.com> <013d01ca4cab$638639a0$4056a80a@china.huawei.com> In-Reply-To: <013d01ca4cab$638639a0$4056a80a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2009 16:51:09.0318 (UTC) FILETIME=[87870260:01CA4CEE] Cc: Simple WG Subject: Re: [Simple] I-D Action:draft-gautam-simple-quick-answer-00.txt 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: , X-List-Received-Date: Wed, 14 Oct 2009 16:51:11 -0000 I guess the first step is to find out if anyone else considers this a problem they would like to see solved. Thanks, Paul Deepanshu Gautam wrote: > The issues with using config. framework for this would be: > > 1. The framework doesn't address the creation of profile data, which is the > integral part of this concept, in terms of QA Creation. > 2. In case of sub/not: *subsequent* subscribe request are required to > remain > subscribed for the requested content (which would be QA here). QA need > to be > fetched eveytime a UA gets registered or UA Holder is updated, which will > happen pretty often, i guess. As i said before, why to define a profile > data, send subsequent subscription request (enrolling) and get > corresponding > notification, retrieve content (all what in there in config. framework), if > it can be simplified to some extent as stated in the draft. MWI used > sub/not > because that may be considered optimal for that. For this, sub/not is not > required at all, things (configuration/synchronization) can be initiated > simply on registration. > > Anyway, i can think of the following to fit this in the general framework: > 1. Depict QA Holder as PDS. And, extend the behavior of PDS as they are > defined for QA Holder. In this way there will be no seperate entity > proposed, instead the one in config. framework will be extended. > 2. As the config. framework leaves the creation of profile data for further > standardization activities, the MESSAGE can be considered serving that > purpose. > > Above two are just some initial thoughts, to make it work. Let me know > opinion on the above two points, if that seems to be a way forward. > > I hope we can find a way out. This is a problem which needs to be solved > (as > simply as it can) . There are real-world requirement for this. For > instance, > OMA-IM has requirements for this function. > > one more inline......... > > ----- Original Message ----- From: "Paul Kyzivat" > To: "Deepanshu Gautam" > Cc: "Simple WG" > Sent: Tuesday, October 13, 2009 9:16 PM > Subject: Re: I-D Action:draft-gautam-simple-quick-answer-00.txt > > >> In general it is easier, in the short term, to make a specific solution >> for a specific problem than it is to generalize the problem and solve >> that. But if you make lots of little focused mechanisms things overall >> get >> very complex and difficult to implement. >> >> I personally find the problem itself not very interesting, and especially >> not compelling enough to design a specific mechanism for. If it were >> simply one more piece of configuration information that you were >> integrating into a general mechanism, then that wouldn't be an issue. >> >> A bit more inlne... >> >> Deepanshu Gautam wrote: >>> Hi, >>> >>> Thanks for your comments, some clarification are provided inline >>> >>>> I just did a quick skim of this draft. >>>> AFAICT, this draft is proposing a mechanism for >>>> configuring/provisioning >>>> UACs with some information, and for updating the information that is >>>> included in that provisioning. >>> This draft is not proposing a configuration/provisioning mechanism >>> itself >>> instead it is proposing things (platform or base or protocol ) needed >>> for >>> that kind of configuration. It does explains what kind of configuration >>> is >>> needed but doesn't say how to do it. >>> The type of information (i.e Quick Answer) also plays a significant role >>> in >>> the feasibility of the proposal. The draft is not intending for all the >>> information but for one specific information with particular >>> characterstics. >>> Further, it is not saying anything >>> about updation, but for sure its a good thing to include. >> >> As I read the draft, the "QA Holder" is a provisioning server for this >> information. The UA is "provisioned/configured" with quick answers by the >> QA holder, and the UA can update the QA Holder with new/revised quick >> answers. >> >> So the QA Holder is a "micro" provisioning server, dedicated to this one >> kind of information. >> >>>> I cannot think of any good reason why there should be a *unique* >>>> mechanism >>>> for this particular configuration information, in contrast to all the >>>> other information that a UA may need to be configured with. >>> Because the solution proposed for this information involves MESSAGE >>> carrying >>> something which is not a regular IM (firstly, the draft tries to make >>> this >>> possible) and require some special behavior (secondly, the draft >>> tries to >>> specify those behavior) from the involved entities such as registrar, >>> UAC, >>> UAS. The question is whether we think that this solution is feasible for >>> the >>> concept of Quick Answer or not. >> >> The use of MESSAGE is just a mechanism for achieving your end. It is >> in no >> way integral to the concept. > Its not about achieving ends, it is about what is correct and right to > do. I > agree, there MAY be other ways but what we have on table, at this point of > time, is this. > > Regards > Deepanshu >> >>>> For instance, the management of this information is conceptually no >>>> different than ring tone data that I might want to configure for my >>>> UA(s), >>>> or buddies I might want to have in my buddy list. >>> Differences would be: >>> You may not want to change/choose the ring tone everytime you get a >>> message >>> or call. >> >> I might not what to change my quick answers every time I get a message or >> call either. >> >>> You generally don't create a ring tone (some sort of user generated >>> content), you just get it from SP >>> You may not want to synchronize ring tones between your UA and server. >> >> I might not, but then I might. E.g. I might hunt up and download my new >> favorite ring tone while using one phone, and then want that same ring >> tone on my other phones. >> >> (Of course the SP would prefer that I pay for it again for each phone, >> but >> that's another story.) >> >>>> >>>> There is already a framework for getting configuration data into the >>>> UA, >>>> but less of one for updating that information. IMO it would make for >>>> sense >>>> to focus on that general problem, and on fitting this particular data >>>> into >>>> that framework. >>> I think trying to fit this data in the avaliable configuration framework >>> (in >>> other words, trying to make it possible on the top of that framework) >>> will >>> involve much of overhead which may not be required/worth-taking for such >>> a >>> simple concept. >> >> You can say the same about almost everything. >> The first use of sub/not was (I think) for message waiting. >> Certainly there were other ways that the MWI info could have been hacked >> into sip. But it made more sense to have a generic mechanism. >> >> There has been a lot of criticism of the configuration framework, >> including proposals to start over on it. Those have some merit. But I >> think there is little doubt that some sort of generic configuration >> mechanism is important. Building a separate mechanism for each piece of >> configuration information that comes along does not appeal to me. >> >> Thanks, >> Paul >> >>> This can be simple done as stated in 1-2 (technical >>> solutions) pages in the draft. For instance, there is no need to >>> define a >>> profile data, sending subsequent subscription request (enrolling) and >>> getting corresponding notification, retrieving content, ... for this. >>> I duly agree with you on the feasibility of the concept of updation here >>> and >>> will work on that part. Adding updation concept to the whole avaliable >>> configuration framework is, for sure, a right thing to do as well, but >>> it >>> is not something being considered here at this point of time with this >>> draft. >>>> >>>> Thanks, >>>> Paul >>> >>> ----- Original Message ----- From: "Paul Kyzivat" >>> To: "Deepanshu Gautam" >>> Cc: "Simple WG" >>> Sent: Monday, October 12, 2009 9:22 PM >>> Subject: Re: I-D Action:draft-gautam-simple-quick-answer-00.txt >>> >>> >>>> I just did a quick skim of this draft. >>>> AFAICT, this draft is proposing a mechanism for >>>> configuring/provisioning >>>> UACs with some information, and for updating the information that is >>>> included in that provisioning. >>>> >>>> I cannot think of any good reason why there should be a *unique* >>>> mechanism >>>> for this particular configuration information, in contrast to all the >>>> other information that a UA may need to be configured with. >>>> >>>> For instance, the management of this information is conceptually no >>>> different than ring tone data that I might want to configure for my >>>> UA(s), >>>> or buddies I might want to have in my buddy list. >>>> >>>> There is already a framework for getting configuration data into the >>>> UA, >>>> but less of one for updating that information. IMO it would make for >>>> sense >>>> to focus on that general problem, and on fitting this particular data >>>> into >>>> that framework. >>>> >>>> Thanks, >>>> Paul >>>> >>>> The existing >>>> >>>> Internet-Drafts@ietf.org wrote: >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> Title : Quick Answer for SIMPLE >>>>> Author(s) : D. Gautamn >>>>> Filename : draft-gautam-simple-quick-answer-00.txt >>>>> Pages : 10 >>>>> Date : 2009-10-11 >>>>> >>>>> In instant messaging system, it is useful to have some readily >>>>> available IM (text, audio or video) which can be sent in case of the >>>>> receiver is too busy to type/speak/record for a reply. These short >>>>> IM (here after referred as QA - Quick Answer) can be created, stored >>>>> and used when needed. This document defines a new QA content type >>>>> and XML namespace that conveys QA between two entities. The QAs are >>>>> delivered to the instant messaging sender in the same manner as the >>>>> instant messages themselves. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-gautam-simple-quick-answer-00.txt >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> Below is the data which will enable a MIME compliant mail reader >>>>> implementation to automatically retrieve the ASCII version of the >>>>> Internet-Draft. >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> > > From ibc@aliax.net Wed Oct 14 10:27:16 2009 Return-Path: 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 7C7343A68FB for ; Wed, 14 Oct 2009 10:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_8BIT_HEADER=0.3] 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 DrnpYe0eXx6A for ; Wed, 14 Oct 2009 10:27:15 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 8E90A3A68EB for ; Wed, 14 Oct 2009 10:27:15 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so33393fga.13 for ; Wed, 14 Oct 2009 10:27:14 -0700 (PDT) Received: by 10.86.229.18 with SMTP id b18mr7915523fgh.34.1255541234415; Wed, 14 Oct 2009 10:27:14 -0700 (PDT) Received: from ibc-laptop.localnet (120.pool85-58-10.dynamic.orange.es [85.58.10.120]) by mx.google.com with ESMTPS id d6sm83380fga.0.2009.10.14.10.27.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 14 Oct 2009 10:27:13 -0700 (PDT) From: =?iso-8859-1?q?I=F1aki_Baz_Castillo?= To: simple@ietf.org Date: Wed, 14 Oct 2009 19:27:10 +0200 User-Agent: KMail/1.12.2 (Linux/2.6.28-15-generic; KDE/4.3.2; x86_64; ; ) References: <20091012031501.6F0183A68E5@core3.amsl.com> <013d01ca4cab$638639a0$4056a80a@china.huawei.com> <4AD6017C.9060201@cisco.com> In-Reply-To: <4AD6017C.9060201@cisco.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200910141927.10905.ibc@aliax.net> Subject: Re: [Simple] I-D Action:draft-gautam-simple-quick-answer-00.txt 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: , X-List-Received-Date: Wed, 14 Oct 2009 17:27:16 -0000 El Mi=E9rcoles, 14 de Octubre de 2009, Paul Kyzivat escribi=F3: > I guess the first step is to find out if anyone else considers this a > problem they would like to see solved. Isn't the IETF purpose to deliver solutions nobody has required and also to provide half-done specifications (as SIMPLE/XCAP) so other specifications in top of them (as OMA's XDM) are needed to build an interoperable and feasible vendor solution? =2D-=20 I=F1aki Baz Castillo From christer.holmberg@ericsson.com Wed Oct 14 12:11:19 2009 Return-Path: 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 8CC623A6955 for ; Wed, 14 Oct 2009 12:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_110=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 ZPPDj3UdGRQ6 for ; Wed, 14 Oct 2009 12:11:19 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id A5FA73A6842 for ; Wed, 14 Oct 2009 12:11:18 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-7e-4ad622579c8e Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 64.A2.08816.75226DA4; Wed, 14 Oct 2009 21:11:19 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 21:11:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Oct 2009 21:11:18 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSRP-ACM open issue: usage of COMEDIA a=connection attribute Thread-Index: AcpJ61LScuFSZY5zT/KkD5h60f9nfwDFhRRQ References: From: "Christer Holmberg" To: X-OriginalArrivalTime: 14 Oct 2009 19:11:19.0563 (UTC) FILETIME=[1C6C8DB0:01CA4D02] X-Brightmail-Tracker: AAAAAA== Subject: [Simple] MSRP-ACM open issue: usage of COMEDIA a=connection attribute 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: , X-List-Received-Date: Wed, 14 Oct 2009 19:11:19 -0000 Hi, An open ACM issue is regarding the usage of the a=3Dconnection attribute for COMEDIA. The issue was presented in Stockholm, and some people requested time to think about it. I have not seen any input from those people, so my suggestion is that we do NOT use the attribute, since: 1. MSRP already specifies connection reuse=20 2. How would the attrbiute be sent to MSRP relays? Please let me know if you do not agree to this suggestion. Regards, Christer From ben@nostrum.com Wed Oct 14 12:24:14 2009 Return-Path: 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 2BB223A67AF for ; Wed, 14 Oct 2009 12:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, 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 FBiiZqZjNp0P for ; Wed, 14 Oct 2009 12:24:13 -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 1F6113A657C for ; Wed, 14 Oct 2009 12:24:12 -0700 (PDT) Received: from dn3-213.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9EJOBxC024611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Oct 2009 14:24:11 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Ben Campbell In-Reply-To: Date: Wed, 14 Oct 2009 14:24:11 -0500 Content-Transfer-Encoding: 7bit Message-Id: <9F346C3A-1F26-4CC1-8764-9D0395E7AF97@nostrum.com> References: To: "Christer Holmberg" X-Mailer: Apple Mail (2.1076) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: simple@ietf.org Subject: Re: [Simple] MSRP-ACM open issue: usage of COMEDIA a=connection attribute 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: , X-List-Received-Date: Wed, 14 Oct 2009 19:24:14 -0000 On Oct 14, 2009, at 2:11 PM, Christer Holmberg wrote: > > Hi, > > An open ACM issue is regarding the usage of the a=connection attribute > for COMEDIA. > > The issue was presented in Stockholm, and some people requested time > to > think about it. > > I have not seen any input from those people, so my suggestion is > that we > do NOT use the attribute, since: > > 1. MSRP already specifies connection reuse > 2. How would the attrbiute be sent to MSRP relays? > > Please let me know if you do not agree to this suggestion. I concur with your suggestion and the reasoning behind it. Thanks! Ben. From bmccolgan@rim.com Thu Oct 15 12:48:18 2009 Return-Path: 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 DF6073A68ED for ; Thu, 15 Oct 2009 12:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 LZ3fuRl0231L for ; Thu, 15 Oct 2009 12:48:11 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id EFFF53A6898 for ; Thu, 15 Oct 2009 12:48:10 -0700 (PDT) X-AuditID: 0a666446-b7beeae000001113-e7-4ad77c7d9995 Received: from XCH38YKF.rim.net ( [10.64.31.208]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 66.5D.04371.D7C77DA4; Thu, 15 Oct 2009 15:48:13 -0400 (EDT) Received: from XCH67YKF.rim.net ([10.64.31.86]) by XCH38YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 15:48:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4DD0.58FD5348" Date: Thu, 15 Oct 2009 15:47:37 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Simple] Liaison Statement from the Open Mobile Alliance thread-index: AcpN0Flku3sK1NZHQY+VwEmjBSG4aA== From: "Brian McColgan" To: X-OriginalArrivalTime: 15 Oct 2009 19:48:13.0061 (UTC) FILETIME=[6E2F4B50:01CA4DD0] X-Brightmail-Tracker: AAAAAgAAAZERQwms Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance 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: , X-List-Received-Date: Thu, 15 Oct 2009 19:48:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4DD0.58FD5348 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable On Fri, 09 Oct 2009 11:00:54 +0300 Jari wrote: > I looked at the statement, and except the copy-paste bugs of IANA files > from rfc4826, there's a proposal to add a "schemaLocation" attribute to > rls- services schema. This attribute value provides a hint from the author > to a processor regarding the location of a schema document. It is an > optional value which may help the validation task. Typically however, > validators have some means to combine multiple schemas (e.g. > does also some magic with multiple > schemas), and as such it has also security implications (if tools e.g. > try to fetch some external schemas). So imo, in any sane practical service, > you'll disable these hints. So they _can_ exist in specs, but they don't > help practical work where you must most likely anyhow tweak with these > uris. > (and fyi, my preference is to use the registered urn's which don't much > help practical work either) > > br, Jari Hello Jari, As you correctly noted, "schemaLocation" is a 'hint'. A 'hint' by its very definition is a 'helpful suggestion' - Reference http://dictionary.reference.com/browse/hint. With that in mind, why would IETF not wish to be helpful and direct a reader/implementor to the location of the relevant XSD? I would assume that is one reason that IANA provides these XSD files (i.e. so that the public at large may discover and make use of these as required). If IETF were to add an appropriate 'proviso' (e.g. in the Schema header) that readers/implementors are discouraged from referring to an XSD file (from a public location - e.g. IANA) on an _ongoing basis_ for the purposes of validation/etc, would that address your concerns? I would also think that IETF would not wish to place a permanent dependancy on any specific 'validation tool' as each tool has different behavior (i.e. in terms of gathering or combining referent XSD files). I would think that would only come into play if the behavior in question fulfilled a mandatory aspect of the validation process, as set out by the W3C. IMHO, a schemaLocation could (and hopefully will) be added as a helpful convenience to those making use of IETF XMLSchema definitions. Of course, suitable 'hints' regarding ongoing use/reference should be included. br, Brian. ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01CA4DD0.58FD5348 Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

On Fri, 09 Oct 2009 11:00:54 +0300 Jari wrote:

> I looked at the statement, and except the copy-= paste bugs of IANA files

> from rfc4826, there's a proposal to add a "schemaLocation" attribute to

> rls- services schema. This attribute value prov= ides a hint from the author

> to a  processor regarding the location of= a schema document. It is an

> optional value which may help the validation ta= sk. Typically however,

> validators have some means to combine multiple= schemas (e.g.

> <http://validate.openlaboratory.net/> does also some magic with multiple

> schemas), and as such it has also security implications (if tools e.g.

> try to fetch some external schemas). So imo, in= any sane practical service, > you'll disable these hints. So they _can_ exist= in specs, but they don't

> help practical work where you must most likely anyhow tweak with these

> uris.

> (and fyi, my preference is to use the registere= d urn's which don't much

> help practical work either)

> 

> br, Jari

 

Hello Jari, 

 

As you correctly noted, “schemaLocation” is a ‘hint’. A= ‘hint’ by its very definition is a ‘helpful suggestion’ – Referen= ce http://dictionary.refer= ence.com/browse/hint.  With that in mind, why would IETF not wish to be helpful and direct a reader/implementor to the location of the relevant XSD?  I would assume that is one reason that IANA provides these XSD files (i.e. so that the publ= ic at large may discover and make use of these as required).<= /p>

 

If IETF were to add an appropriate ‘proviso’ (e.g. in the Schema header) that readers/implementors are discouraged from referring to an XSD file (fro= m a public location – e.g. IANA) on an _ongoing basis_ for the purposes of validation/etc, would that address your concerns?  I would= also think that IETF would not wish to place a permanent dependancy on any specif= ic ‘validation tool’ as each tool has different behavior (i.e. in terms of gathering= or combining referent XSD files).  I would think that would only come into play if the behavior in question fulfilled a mandatory aspect of the validat= ion process, as set out by the W3C.

 

IMHO, a schemaLocation could (and hopefully will) be added as a helpful convenienc= e to those making use of IETF XMLSchema definitions.  Of course, suitable= ‘hints’ regarding ongoing use/reference should be included.

 

br, Brian.

---------------------------------------------------------------------
= =0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01CA4DD0.58FD5348-- From ben@nostrum.com Thu Oct 15 13:39:59 2009 Return-Path: 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 8CC943A67F4 for ; Thu, 15 Oct 2009 13:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 8XvLoFf7fLTl for ; Thu, 15 Oct 2009 13:39: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 626163A657C for ; Thu, 15 Oct 2009 13:39:58 -0700 (PDT) Received: from [10.0.1.8] (adsl-68-94-15-159.dsl.rcsntx.swbell.net [68.94.15.159]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9FKduqc067171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Oct 2009 15:39:57 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Ben Campbell In-Reply-To: <1255075254.18223.43.camel@localhost> Date: Thu, 15 Oct 2009 15:39:51 -0500 Content-Transfer-Encoding: 7bit Message-Id: <86D6FDDE-7033-4997-AB82-46499114CD38@nostrum.com> References: <1255075254.18223.43.camel@localhost> To: Jari Urpalainen X-Mailer: Apple Mail (2.1076) Received-SPF: pass (nostrum.com: 68.94.15.159 is authenticated by a trusted mechanism) Cc: "Louise.Clarke@forapolis.com" , Simple WG , Dean Willis Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance 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: , X-List-Received-Date: Thu, 15 Oct 2009 20:39:59 -0000 On Oct 9, 2009, at 3:00 AM, Jari Urpalainen wrote: > On Fri, 2009-10-02 at 20:12 +0200, ext Ben Campbell wrote: >> (as SIMPLE co-chair) >> >> OMA sent a liaison statement to the SIMPLE working group. The >> statement's overview reads as follows: > [...] > I looked at the statement, and except the copy-paste bugs of IANA > files > from rfc4826, there's a proposal to add a "schemaLocation" attribute > to > rls-services schema. This attribute value provides a hint from the > author to a processor regarding the location of a schema document. > It is > an optional value which may help the validation task. Typically > however, > validators have some means to combine multiple schemas (e.g. > does also some magic with > multiple > schemas), and as such it has also security implications (if tools e.g. > try to fetch some external schemas). So imo, in any sane practical > service, you'll disable these hints. So they _can_ exist in specs, but > they don't help practical work where you must most likely anyhow tweak > with these uris. (and fyi, my preference is to use the registered > urn's > which don't much help practical work either) > Am I correct in assuming the schemaLocation attribute is also not in the version in the RFC? (I guess that would be a tricky thing to put in an RFC due to document lifetime issues.) Thanks! Ben. From Jari.Urpalainen@nokia.com Fri Oct 16 02:56:19 2009 Return-Path: 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 B1DF93A679F for ; Fri, 16 Oct 2009 02:56:19 -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 Wf4i-ETwADS2 for ; Fri, 16 Oct 2009 02:56:18 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 79B7A3A67A1 for ; Fri, 16 Oct 2009 02:56:18 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9G9uCLn020557; Fri, 16 Oct 2009 12:56:16 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 12:56:04 +0300 Received: from mgw-da02.ext.nokia.com ([147.243.128.26]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 12:56:03 +0300 Received: from [172.21.37.235] (esdhcp037235.research.nokia.com [172.21.37.235]) by mgw-da02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9G9tx8E014611; Fri, 16 Oct 2009 12:56:00 +0300 From: Jari Urpalainen To: ext Ben Campbell In-Reply-To: <86D6FDDE-7033-4997-AB82-46499114CD38@nostrum.com> References: <1255075254.18223.43.camel@localhost> <86D6FDDE-7033-4997-AB82-46499114CD38@nostrum.com> Content-Type: text/plain Date: Fri, 16 Oct 2009 12:55:59 +0300 Message-Id: <1255686959.19531.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2009 09:56:04.0170 (UTC) FILETIME=[DFBA82A0:01CA4E46] X-Nokia-AV: Clean Cc: "Louise.Clarke@forapolis.com" , Simple WG , Dean Willis Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance 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: , X-List-Received-Date: Fri, 16 Oct 2009 09:56:19 -0000 On Thu, 2009-10-15 at 22:39 +0200, ext Ben Campbell wrote: > On Oct 9, 2009, at 3:00 AM, Jari Urpalainen wrote: > > > On Fri, 2009-10-02 at 20:12 +0200, ext Ben Campbell wrote: > >> (as SIMPLE co-chair) > >> > >> OMA sent a liaison statement to the SIMPLE working group. The > >> statement's overview reads as follows: > > > > [...] > > > I looked at the statement, and except the copy-paste bugs of IANA > > files > > from rfc4826, there's a proposal to add a "schemaLocation" attribute > > to > > rls-services schema. This attribute value provides a hint from the > > author to a processor regarding the location of a schema document. > > It is > > an optional value which may help the validation task. Typically > > however, > > validators have some means to combine multiple schemas (e.g. > > does also some magic with > > multiple > > schemas), and as such it has also security implications (if tools e.g. > > try to fetch some external schemas). So imo, in any sane practical > > service, you'll disable these hints. So they _can_ exist in specs, but > > they don't help practical work where you must most likely anyhow tweak > > with these uris. (and fyi, my preference is to use the registered > > urn's > > which don't much help practical work either) > > > > Am I correct in assuming the schemaLocation attribute is also not in > the version in the RFC? (I guess that would be a tricky thing to put > in an RFC due to document lifetime issues.) > > Thanks! > > Ben. Right, it is not there, i.e. the rfc is ok. br, Jari From uwe.rauschenbach@nsn.com Fri Oct 16 03:42:55 2009 Return-Path: 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 D745728C1EE for ; Fri, 16 Oct 2009 03:42:55 -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 cDMynncbp4Rx for ; Fri, 16 Oct 2009 03:42:54 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 35E3828C1E6 for ; Fri, 16 Oct 2009 03:42:53 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9GAgroo003472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Oct 2009 12:42:53 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9GAgqS5006387; Fri, 16 Oct 2009 12:42:52 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 12:42:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Oct 2009 12:42:55 +0200 Message-ID: In-Reply-To: <1255686959.19531.10.camel@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Liaison Statement from the Open Mobile Alliance Thread-Index: AcpORvGtYrgNtRSARHiH2ULB+wQ8FQABhQnA References: <1255075254.18223.43.camel@localhost><86D6FDDE-7033-4997-AB82-46499114CD38@nostrum.com> <1255686959.19531.10.camel@localhost> From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: "ext Jari Urpalainen" , "ext Ben Campbell" X-OriginalArrivalTime: 16 Oct 2009 10:42:51.0259 (UTC) FILETIME=[68E24CB0:01CA4E4D] Cc: Louise.Clarke@forapolis.com, Simple WG , Dean Willis Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance 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: , X-List-Received-Date: Fri, 16 Oct 2009 10:42:56 -0000 Hi all, SchemaLocation refers to where documents are stored. Therefore it makes sense to add it to the schema document instances in the IANA repository, but it is not required to add it to the RFC. Kind regards, Uwe=20 =20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of ext Jari Urpalainen > Sent: Friday, October 16, 2009 11:56 AM > To: ext Ben Campbell > Cc: Louise.Clarke@forapolis.com; Simple WG; Dean Willis > Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance >=20 > On Thu, 2009-10-15 at 22:39 +0200, ext Ben Campbell wrote: > > On Oct 9, 2009, at 3:00 AM, Jari Urpalainen wrote: > >=20 > > > On Fri, 2009-10-02 at 20:12 +0200, ext Ben Campbell wrote: > > >> (as SIMPLE co-chair) > > >> > > >> OMA sent a liaison statement to the SIMPLE working group. The > > >> statement's overview reads as follows: > > > > >=20 > > [...] > >=20 > > > I looked at the statement, and except the copy-paste bugs=20 > of IANA =20 > > > files > > > from rfc4826, there's a proposal to add a=20 > "schemaLocation" attribute =20 > > > to > > > rls-services schema. This attribute value provides a hint from the > > > author to a processor regarding the location of a schema=20 > document. =20 > > > It is > > > an optional value which may help the validation task. Typically =20 > > > however, > > > validators have some means to combine multiple schemas (e.g. > > > does also some magic with =20 > > > multiple > > > schemas), and as such it has also security implications=20 > (if tools e.g. > > > try to fetch some external schemas). So imo, in any sane practical > > > service, you'll disable these hints. So they _can_ exist=20 > in specs, but > > > they don't help practical work where you must most likely=20 > anyhow tweak > > > with these uris. (and fyi, my preference is to use the=20 > registered =20 > > > urn's > > > which don't much help practical work either) > > > > >=20 > > Am I correct in assuming the schemaLocation attribute is=20 > also not in =20 > > the version in the RFC? (I guess that would be a tricky=20 > thing to put =20 > > in an RFC due to document lifetime issues.) > >=20 > > Thanks! > >=20 > > Ben. > Right, it is not there, i.e. the rfc is ok.=20 >=20 > br, Jari =20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From bmccolgan@rim.com Fri Oct 16 12:44:06 2009 Return-Path: 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 638093A67B1 for ; Fri, 16 Oct 2009 12:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.995 X-Spam-Level: X-Spam-Status: No, score=-3.995 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 jgnrQ-fZW+QH for ; Fri, 16 Oct 2009 12:44:05 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 7D1423A68B7 for ; Fri, 16 Oct 2009 12:44:04 -0700 (PDT) X-AuditID: 0a666446-b7b08ae000007bbc-cf-4ad8cd08e16c Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs04ykf.rim.net (RIM Mail) with SMTP id EC.64.31676.80DC8DA4; Fri, 16 Oct 2009 15:44:08 -0400 (EDT) Received: from XCH67YKF.rim.net ([10.64.31.86]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 15:44:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Fri, 16 Oct 2009 15:44:05 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Liaison Statement from the Open Mobile Alliance thread-index: AcpOkuxQjJkmhgQxTl2eUtdU6lpOsgABSJ/Q References: From: "Brian McColgan" To: X-OriginalArrivalTime: 16 Oct 2009 19:44:07.0728 (UTC) FILETIME=[065E3300:01CA4E99] X-Brightmail-Tracker: AAAAAQAAAZE= Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance 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: , X-List-Received-Date: Fri, 16 Oct 2009 19:44:06 -0000 > On Fri, 2009-10-02 at 20:12 +0200, ext Ben Campbell wrote: > > Am I correct in assuming the schemaLocation attribute is also not in > the version in the RFC? (I guess that would be a tricky thing to put > in an RFC due to document lifetime issues.) > Thanks! > > Ben. My apologies if I was not completely clear in my first response to Jari. I was referring to the XSD files _as they exist_ on the public IANA site (_not_ as provided in the IETF rfc's). As Ben has noted, that would indeed be a tricky issue to deal with, in terms of maintaining the RFC, etc. Hope this clarifies, thanks! Brian. ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From Martin.Thomson@andrew.com Sun Oct 18 15:32:11 2009 Return-Path: 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 D98FA3A6994 for ; Sun, 18 Oct 2009 15:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 AQFIEtjB-d1d for ; Sun, 18 Oct 2009 15:32:11 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id D8B363A690D for ; Sun, 18 Oct 2009 15:32:10 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:25609 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S4581577AbZJRWcO (ORCPT ); Sun, 18 Oct 2009 17:32:14 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 18 Oct 2009 17:32:14 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 19 Oct 2009 06:32:10 +0800 From: "Thomson, Martin" To: "Rauschenbach, Uwe (NSN - DE/Munich)" , ext Jari Urpalainen , ext Ben Campbell Date: Mon, 19 Oct 2009 06:32:34 +0800 Thread-Topic: [Simple] Liaison Statement from the Open Mobile Alliance Thread-Index: AcpORvGtYrgNtRSARHiH2ULB+wQ8FQABhQnAAH1F6lA= Message-ID: <8B0A9FCBB9832F43971E38010638454F0F1E9FFB@SISPE7MB1.commscope.com> References: <1255075254.18223.43.camel@localhost><86D6FDDE-7033-4997-AB82-46499114CD38@nostrum.com> <1255686959.19531.10.camel@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "Louise.Clarke@forapolis.com" , Simple WG , Dean Willis Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance 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: , X-List-Received-Date: Sun, 18 Oct 2009 22:32:11 -0000 SGF2aW5nIGRlYWx0IHdpdGggYSBzaW1pbGFyIHByb2JsZW0gaW4gYW4gT01BIGdyb3VwIGp1c3Qg cmVjZW50bHksIHRoZWlyIGFwcHJvYWNoIHJlcXVpcmVzIGEgcHVibGlzaGVkIGxvY2F0aW9uLg0K DQpJIHN1cHBvcnQgSmFyaSdzIGFwcHJvYWNoLiAgSW4gZ2VuZXJhbCwgbWFuYWdpbmcgc2NoZW1h IGRvY3VtZW50cyBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgYW4gaW1wbGVtZW50YXRpb24uICBJ dCdzIG5vdCByZWFsbHkgYWxsIHRoYXQgaGFyZC4NCg0KLS1NYXJ0aW4NCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaW1wbGUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OnNpbXBsZS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgUmF1c2NoZW5iYWNoLCBV d2UgKE5TTiAtIERFL011bmljaCkNCj4gU2VudDogRnJpZGF5LCAxNiBPY3RvYmVyIDIwMDkgOTo0 MyBQTQ0KPiBUbzogZXh0IEphcmkgVXJwYWxhaW5lbjsgZXh0IEJlbiBDYW1wYmVsbA0KPiBDYzog TG91aXNlLkNsYXJrZUBmb3JhcG9saXMuY29tOyBTaW1wbGUgV0c7IERlYW4gV2lsbGlzDQo+IFN1 YmplY3Q6IFJlOiBbU2ltcGxlXSBMaWFpc29uIFN0YXRlbWVudCBmcm9tIHRoZSBPcGVuIE1vYmls ZSBBbGxpYW5jZQ0KPiANCj4gSGkgYWxsLA0KPiANCj4gU2NoZW1hTG9jYXRpb24gcmVmZXJzIHRv IHdoZXJlIGRvY3VtZW50cyBhcmUgc3RvcmVkLg0KPiANCj4gVGhlcmVmb3JlIGl0IG1ha2VzIHNl bnNlIHRvIGFkZCBpdCB0byB0aGUgc2NoZW1hIGRvY3VtZW50IGluc3RhbmNlcyBpbg0KPiB0aGUg SUFOQSByZXBvc2l0b3J5LCBidXQgaXQgaXMgbm90IHJlcXVpcmVkIHRvIGFkZCBpdCB0byB0aGUg UkZDLg0KPiANCj4gS2luZCByZWdhcmRzLA0KPiBVd2UNCj4gDQo+IA0KPiANCj4gDQo+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBzaW1wbGUtYm91bmNlc0BpZXRmLm9y Zw0KPiA+IFttYWlsdG86c2ltcGxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQg SmFyaSBVcnBhbGFpbmVuDQo+ID4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDE2LCAyMDA5IDExOjU2 IEFNDQo+ID4gVG86IGV4dCBCZW4gQ2FtcGJlbGwNCj4gPiBDYzogTG91aXNlLkNsYXJrZUBmb3Jh cG9saXMuY29tOyBTaW1wbGUgV0c7IERlYW4gV2lsbGlzDQo+ID4gU3ViamVjdDogUmU6IFtTaW1w bGVdIExpYWlzb24gU3RhdGVtZW50IGZyb20gdGhlIE9wZW4gTW9iaWxlIEFsbGlhbmNlDQo+ID4N Cj4gPiBPbiBUaHUsIDIwMDktMTAtMTUgYXQgMjI6MzkgKzAyMDAsIGV4dCBCZW4gQ2FtcGJlbGwg d3JvdGU6DQo+ID4gPiBPbiBPY3QgOSwgMjAwOSwgYXQgMzowMCBBTSwgSmFyaSBVcnBhbGFpbmVu IHdyb3RlOg0KPiA+ID4NCj4gPiA+ID4gT24gRnJpLCAyMDA5LTEwLTAyIGF0IDIwOjEyICswMjAw LCBleHQgQmVuIENhbXBiZWxsIHdyb3RlOg0KPiA+ID4gPj4gKGFzIFNJTVBMRSBjby1jaGFpcikN Cj4gPiA+ID4+DQo+ID4gPiA+PiBPTUEgc2VudCBhIGxpYWlzb24gc3RhdGVtZW50IHRvIHRoZSBT SU1QTEUgd29ya2luZyBncm91cC4gVGhlDQo+ID4gPiA+PiBzdGF0ZW1lbnQncyBvdmVydmlldyBy ZWFkcyBhcyBmb2xsb3dzOg0KPiA+ID4gPg0KPiA+ID4NCj4gPiA+IFsuLi5dDQo+ID4gPg0KPiA+ ID4gPiBJIGxvb2tlZCBhdCB0aGUgc3RhdGVtZW50LCBhbmQgZXhjZXB0IHRoZSBjb3B5LXBhc3Rl IGJ1Z3MNCj4gPiBvZiBJQU5BDQo+ID4gPiA+IGZpbGVzDQo+ID4gPiA+IGZyb20gcmZjNDgyNiwg dGhlcmUncyBhIHByb3Bvc2FsIHRvIGFkZCBhDQo+ID4gInNjaGVtYUxvY2F0aW9uIiBhdHRyaWJ1 dGUNCj4gPiA+ID4gdG8NCj4gPiA+ID4gcmxzLXNlcnZpY2VzIHNjaGVtYS4gVGhpcyBhdHRyaWJ1 dGUgdmFsdWUgcHJvdmlkZXMgYSBoaW50IGZyb20NCj4gdGhlDQo+ID4gPiA+IGF1dGhvciB0byBh IHByb2Nlc3NvciByZWdhcmRpbmcgdGhlIGxvY2F0aW9uIG9mIGEgc2NoZW1hDQo+ID4gZG9jdW1l bnQuDQo+ID4gPiA+IEl0IGlzDQo+ID4gPiA+IGFuIG9wdGlvbmFsIHZhbHVlIHdoaWNoIG1heSBo ZWxwIHRoZSB2YWxpZGF0aW9uIHRhc2suIFR5cGljYWxseQ0KPiA+ID4gPiBob3dldmVyLA0KPiA+ ID4gPiB2YWxpZGF0b3JzIGhhdmUgc29tZSBtZWFucyB0byBjb21iaW5lIG11bHRpcGxlIHNjaGVt YXMgKGUuZy4NCj4gPiA+ID4gPGh0dHA6Ly92YWxpZGF0ZS5vcGVubGFib3JhdG9yeS5uZXQvPiBk b2VzIGFsc28gc29tZSBtYWdpYyB3aXRoDQo+ID4gPiA+IG11bHRpcGxlDQo+ID4gPiA+IHNjaGVt YXMpLCBhbmQgYXMgc3VjaCBpdCBoYXMgYWxzbyBzZWN1cml0eSBpbXBsaWNhdGlvbnMNCj4gPiAo aWYgdG9vbHMgZS5nLg0KPiA+ID4gPiB0cnkgdG8gZmV0Y2ggc29tZSBleHRlcm5hbCBzY2hlbWFz KS4gU28gaW1vLCBpbiBhbnkgc2FuZQ0KPiBwcmFjdGljYWwNCj4gPiA+ID4gc2VydmljZSwgeW91 J2xsIGRpc2FibGUgdGhlc2UgaGludHMuIFNvIHRoZXkgX2Nhbl8gZXhpc3QNCj4gPiBpbiBzcGVj cywgYnV0DQo+ID4gPiA+IHRoZXkgZG9uJ3QgaGVscCBwcmFjdGljYWwgd29yayB3aGVyZSB5b3Ug bXVzdCBtb3N0IGxpa2VseQ0KPiA+IGFueWhvdyB0d2Vhaw0KPiA+ID4gPiB3aXRoIHRoZXNlIHVy aXMuIChhbmQgZnlpLCBteSBwcmVmZXJlbmNlIGlzIHRvIHVzZSB0aGUNCj4gPiByZWdpc3RlcmVk DQo+ID4gPiA+IHVybidzDQo+ID4gPiA+IHdoaWNoIGRvbid0IG11Y2ggaGVscCBwcmFjdGljYWwg d29yayBlaXRoZXIpDQo+ID4gPiA+DQo+ID4gPg0KPiA+ID4gQW0gSSBjb3JyZWN0IGluIGFzc3Vt aW5nIHRoZSBzY2hlbWFMb2NhdGlvbiBhdHRyaWJ1dGUgaXMNCj4gPiBhbHNvIG5vdCBpbg0KPiA+ ID4gdGhlIHZlcnNpb24gaW4gdGhlIFJGQz8gKEkgZ3Vlc3MgdGhhdCB3b3VsZCBiZSBhIHRyaWNr eQ0KPiA+IHRoaW5nIHRvIHB1dA0KPiA+ID4gaW4gYW4gUkZDIGR1ZSB0byBkb2N1bWVudCBsaWZl dGltZSBpc3N1ZXMuKQ0KPiA+ID4NCj4gPiA+IFRoYW5rcyENCj4gPiA+DQo+ID4gPiBCZW4uDQo+ ID4gUmlnaHQsIGl0IGlzIG5vdCB0aGVyZSwgaS5lLiB0aGUgcmZjIGlzIG9rLg0KPiA+DQo+ID4g YnIsIEphcmkNCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiBTaW1wbGUgbWFpbGluZyBsaXN0DQo+ID4gU2ltcGxlQGlldGYu b3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUNCj4g Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBT aW1wbGUgbWFpbGluZyBsaXN0DQo+IFNpbXBsZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZQ0KDQo= From ag@ag-projects.com Tue Oct 20 03:18:02 2009 Return-Path: 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 D12AB3A68E0 for ; Tue, 20 Oct 2009 03:18:02 -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 AYP4KhbTgYAs for ; Tue, 20 Oct 2009 03:18:02 -0700 (PDT) Received: from node05.dns-hosting.info (node05.dns-hosting.info [85.17.186.5]) by core3.amsl.com (Postfix) with ESMTP id B6D673A68AA for ; Tue, 20 Oct 2009 03:18:00 -0700 (PDT) Received: from mit.xs4all.nl ([80.101.96.20] helo=[192.168.1.6]) by node05.dns-hosting.info with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1N0Bd0-00021O-M4; Tue, 20 Oct 2009 12:07:46 +0200 Message-Id: <4B097D60-F7A6-4141-9871-5BF4683B7EC1@ag-projects.com> From: Adrian Georgescu To: Geir Arne Sandbakken In-Reply-To: <4ACA00F2.60709@tandberg.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Oct 2009 12:17:56 +0200 References: <4ACA00F2.60709@tandberg.com> X-Mailer: Apple Mail (2.936) 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 Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) Cc: Simple Subject: Re: [Simple] Multi-party Chat version 05 submitted 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: , X-List-Received-Date: Tue, 20 Oct 2009 10:18:02 -0000 After reviewing this document, from an implementor perspective the =20 draft addresses all my needs to build such a conference system based =20 on MSRP protocol. I personally have no further suggestions for =20 improving it and I would like to see this going through the process =20 for becoming a proposed standard. -- Adrian On Oct 5, 2009, at 4:21 PM, Geir Arne Sandbakken wrote: > A new version of =93Multi-party Chat Using the Message Session Relay =20= > Protocol (MSRP)=94 has been submitted. > > The new version can be found here: > http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-05.txt > > Additions and changes from -04 based on the WGLC Summary: > 1. Architectural diagrams or descriptions clarifying MSRP switch =20 > role towards MSRP relay, endpoints and focus > - Added diagram showing Focus UA, MSRP relays and MSRP switch. - =20 > Added reference to MSRP relays to make implementers compare =20 > mechanisms. > 2. Clean up Section 6.2 on Private Messages > - Removed text regarding reports and responses. > - Made reference to regular messages - and removed duplicate text. > 3. Various Nickname clarifications: terminology, privacy and security > - The review listed the Nickname as a missing identifier. Nicknames =20= > in simple-chat are not part of the identifiers of which one can =20 > populate in the To header field of the Message/CPIM wrapper. =20 > Nicknames are more like display names, but unique inside a chat =20 > room. - Rephrased section 7.1, and cleaned up the terminology. > - Added a Nickname paragraph under the security considerations. > - Did not add a time out - as a Nickname is not an identifier to be =20= > used for message relaying. Only used for display purposes, and it is =20= > the policy of the focus to apply any constraints. > 4. Add normative reference to P-Asserted-Identity > - Done. > 5. Example of a Conference Event Package notification with a =20 > nickname element > - Done > 6. Lots of requirement clean ups. Scary. > - Removed REQ-2 talking about other media types > - Rephrased REQ-8 > - Cleaned up REQ-9 > - Cleaned up REQ-10 > 7. Clarification around conference "unaware" participants > - Added text under 5.2 "Joining a chat room". - Made clear that the =20= > rest of the document requires clients to be conference aware. > 8. MSRP switch needs to be made Message-Id stateful. Add text. > - Added text under section 6 "Sending and receiving IM messages" > 9. More reporting model update - and removal. > - Removed a lot of normative text. - Added separate section for =20 > report and response handling > 10. Remove mixed media references > - Removed REQ-2 talking about other media types > - Removed all references to other media types. > 11. Add text on side effect when removing chat rooms. > - Added text to section 5.x > 12. Add Multi-chunk example > - Done > 13. Remove GRUU example > - Done > 14. Add error response on private message > - Done > 15. Various editorial fixes and simplifications > - Done > 16. Add Mary and Ben to Acknowledgements > - Done > > > Thanks, > Geir > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From AVSHALOM@il.ibm.com Tue Oct 27 08:28:52 2009 Return-Path: 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 EF8083A6962 for ; Tue, 27 Oct 2009 08:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.154 X-Spam-Level: X-Spam-Status: No, score=-5.154 tagged_above=-999 required=5 tests=[AWL=1.444, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 iVi2eDQdKefs for ; Tue, 27 Oct 2009 08:28:51 -0700 (PDT) Received: from mtagate1.de.ibm.com (mtagate1.de.ibm.com [195.212.17.161]) by core3.amsl.com (Postfix) with ESMTP id 503C83A68FF for ; Tue, 27 Oct 2009 08:28:51 -0700 (PDT) Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id n9RFSuCh030603 for ; Tue, 27 Oct 2009 15:28:59 GMT Received: from d12av05.megacenter.de.ibm.com (d12av05.megacenter.de.ibm.com [9.149.165.216]) by d12nrmr1507.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9RFSmXN1261606 for ; Tue, 27 Oct 2009 16:28:54 +0100 Received: from d12av05.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av05.megacenter.de.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9RFSlEK019971 for ; Tue, 27 Oct 2009 16:28:47 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av05.megacenter.de.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9RFSlBE019968 for ; Tue, 27 Oct 2009 16:28:47 +0100 To: simple@ietf.org MIME-Version: 1.0 X-KeepSent: 09C934CA:F238A62C-C225765C:005241B6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Avshalom Houri Message-ID: Date: Tue, 27 Oct 2009 17:28:47 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 27/10/2009 17:28:48, Serialize complete at 27/10/2009 17:28:48 Content-Type: multipart/alternative; boundary="=_alternative 0054D6E2C225765C_=" Subject: [Simple] Suggested next actions with draft-ietf-simple-interdomain-scaling-analysis 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: , X-List-Received-Date: Tue, 27 Oct 2009 15:28:53 -0000 This is a multipart message in MIME format. --=_alternative 0054D6E2C225765C_= Content-Type: text/plain; charset="US-ASCII" The IESG had substantial comments on the draft: https://datatracker.ietf.org/idtracker/draft-ietf-simple-interdomain-scaling-analysis/comment/102863/ The following is a plan for revising the draft to address these comments. The plan is based on discussions with Ben, Cullen and Robert. One very important thing that will help us a lot in this work is getting real data from actual deployments of SIMPLE regarding the following: - Message sizes. - Different refresh (re-subscribe) rates used and when they are used. - Presence document data sizes - Geolocation presence document data sizes. - Size of data per subscription that the presence server needs to allocate - Any other data that we can get from the field. **** Any numbers here will be greatly appreciated and will help a lot in creating the new revision of the document **** Note that the above numbers are more SIP specific and we need to get them from actual SIP deployments. They are different from the general constants of buddy list size, rate of state changes per day etc. which are more usage numbers. General Changes: ---------------- * Remove subjective language as much as possible * The document should not be written as a protocol comparison document but as a document that provides input that will help deployment considerations for SIMPLE and directions for optimizations. * Clarify the assumptions behind the chosen input values. * Discuss elasticity of inputs and which inputs have more effect. * Make it clear that we are talking only about inter-domain traffic. * The document will have to go through the working group last call again. Changes in Phase I ------------------- * Separate the scenarios into enterprise and consumer related scenarios. Number as the time that a user will be logged in which is reasonable to be 8 in an enterprise will be different for a consumer network. The rate of status changes will be different also. * Since we can not mention explicit numbers from actual deployments, we should say e.g. "hypothetical consumer service"... * Add per active (logged in) user calculations * Section 2.2: The 2000/4000 difference in login/logouts is probably a typo mistake that needs to be clarified. It does NOT affect the calculations. * Add a section describing changes with different constants. Provide several points on the possible reasonable values. * Add geolocation information as part of the model. * Provide different calculations for the refresh time. The 3600 seconds from the RFC is not the number that is usually used. Provide both extremes. * Message sizes: Need to do sanity check of messages. Talk to people that may have these numbers. * Section 2.10 - Change to 48 changes per day from 24. It was done in order to show that the optimized protocol can be better even with doubling the number notifications. This is probably confusing and need to be fixed. * Sizes for state calculations. Need to revisit the numbers that are used. Get actual numbers from the same sources that we will get message sizes. * Talk about the limits that are imposed by privacy constraints on the way that SIMPLE works and possible optimizations. * Provide numbers for when SIGCOMP compression is used. Phase II -------- * Revisit Processing Complexities, Current Optimizations, Summary and Conclusions sections after doing the changes in the main part of the document. Thanks --Avshalom --=_alternative 0054D6E2C225765C_= Content-Type: text/html; charset="US-ASCII" The IESG had substantial comments on the draft:
https://datatracker.ietf.org/idtracker/draft-ietf-simple-interdomain-scaling-analysis/comment/102863/

The following is a plan for revising the draft to address these comments.
The plan is based on discussions with Ben, Cullen and Robert.

One very important thing that will help us a lot in this work is getting
real data from actual deployments of SIMPLE regarding the following:

- Message sizes.
- Different refresh (re-subscribe) rates used and when they are used.
- Presence document data sizes
- Geolocation presence document data sizes.
- Size of data per subscription that the presence server needs to
  allocate

- Any other data that we can get from the field.
**** Any numbers here will be greatly appreciated and will help a lot
in creating the new revision of the document ****

Note that the above numbers are more SIP specific and we need to get  
them from actual SIP deployments. They are different from the  
general constants of buddy list size, rate of state changes per day etc.
which are more usage numbers.

General Changes:
----------------
* Remove subjective language as much as possible

* The document should not be written as a protocol comparison document
but as a document that provides input that will help deployment  
considerations for SIMPLE and directions for optimizations.
* Clarify the assumptions behind the chosen input values.
* Discuss elasticity of inputs and which inputs have more effect.

* Make it clear that we are talking only about inter-domain  
traffic.
* The document will have to go through the working group last call  
again.

Changes in Phase I
-------------------
* Separate the scenarios into enterprise and consumer related  
scenarios. Number as the time that a user will be logged in which is
reasonable to be 8 in an enterprise will be different for a consumer
network. The rate of status changes will be different also.
* Since we can not mention explicit numbers from actual deployments,  
we should say e.g. "hypothetical consumer service"...

* Add per active (logged in) user calculations
* Section 2.2: The 2000/4000 difference in login/logouts is probably  
a typo mistake that needs to be clarified. It does NOT affect the  
calculations.
* Add a section describing changes with different constants. Provide  
several points on the possible reasonable values.
* Add geolocation information as part of the model.

* Provide different calculations for the refresh time. The 3600  
seconds from the RFC is not the number that is usually used.
Provide both extremes.

* Message sizes: Need to do sanity check of messages. Talk to people  
that may have these numbers.

* Section 2.10 - Change to 48 changes per day from 24. It was done  
in order to show that the optimized protocol can be better even with
doubling the number notifications. This is probably confusing and need to
be fixed.
* Sizes for state calculations. Need to revisit the numbers that are  
used. Get actual numbers from the same sources that we will get message
sizes.
* Talk about the limits that are imposed by privacy constraints on  
the way that SIMPLE works and possible optimizations.
* Provide numbers for when SIGCOMP compression is used.
Phase II
--------
* Revisit Processing Complexities, Current Optimizations, Summary and
Conclusions sections after doing the changes in the main part of the  
document.
Thanks
--Avshalom

 --=_alternative 0054D6E2C225765C_=-- From ben@nostrum.com Wed Oct 28 15:43:38 2009 Return-Path: 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 EFBE03A6A3A for ; Wed, 28 Oct 2009 15:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 99f5sV+6JKa3 for ; Wed, 28 Oct 2009 15:43:38 -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 E8C713A67FB for ; Wed, 28 Oct 2009 15:43:37 -0700 (PDT) Received: from [10.0.1.8] (adsl-68-94-40-237.dsl.rcsntx.swbell.net [68.94.40.237]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9SMhmrN050702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 28 Oct 2009 17:43:51 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 28 Oct 2009 17:43:43 -0500 Message-Id: <4B1C2189-D8D8-43ED-ACC8-8A793E17DF66@nostrum.com> To: Simple WG Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Received-SPF: pass (nostrum.com: 68.94.40.237 is authenticated by a trusted mechanism) Subject: [Simple] Draft Agenda SIMPLE@IETF76 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: , X-List-Received-Date: Wed, 28 Oct 2009 22:43:39 -0000 Please send comments/change requests quickly: SIMPLE: Tuesday, November 10, 2009 1710-1810 10 min Agenda Bashing and Work Group Status update 40 min MSRP-ACM - Christer http://tools.ietf.org/html/draft-ietf-simple-msrp-acm-01 10 min Quick Answer Draft - Deepanshu (if time permits) http://tools.ietf.org/html/draft-gautam-simple-quick-answer-00