From simple-bounces@ietf.org Thu Mar 01 09:31:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMmJo-00081u-Iq; Thu, 01 Mar 2007 09:31:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMmJn-00081h-9w for simple@ietf.org; Thu, 01 Mar 2007 09:31:39 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMmJl-0003qT-Lg for simple@ietf.org; Thu, 01 Mar 2007 09:31:39 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l21EVBMH023106; Thu, 1 Mar 2007 08:31:36 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 08:31:33 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 15:31:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Internal WG Review: Recharter of SIP forInstant Messaging and Presence Leveraging Extensions (simple) Date: Thu, 1 Mar 2007 15:31:26 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180D76C2B@DEEXC1U01.de.lucent.com> In-Reply-To: <45E344EE.2050800@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Internal WG Review: Recharter of SIP forInstant Messaging and Presence Leveraging Extensions (simple) Thread-Index: AcdZ5hMsW2NfN1V5SqmJtEX+YVbMTACJ46Zg From: "Drage, Keith \(Keith\)" To: "Jonathan Rosenberg" , "Avshalom Houri" X-OriginalArrivalTime: 01 Mar 2007 14:31:30.0345 (UTC) FILETIME=[4D88B190:01C75C0E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.5 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Note that SIP has chartered the ETAGs work that was mentioned in the last SIMPLE meeting. Sep 2007 Extension for use of etags in conditional notification to WGLC =20 Dec 2007 Extension for use in etags in conditional notification to IESG (PS) =20 Any bugfixes to RFC 3265 also should come straight to SIP. Otherwise cultivate away - then send to SIP as per normal process. Regards Keith=20 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: 26 February 2007 20:37 To: Avshalom Houri Cc: simple@ietf.org Subject: Re: [Simple] Internal WG Review: Recharter of SIP forInstant Messaging and Presence Leveraging Extensions (simple) THey would have to fomally be done in SIP, but I think it makes sense to cultivate them in SIMPLE. Sort of like RFC 4662 worked. -Jonathan R. Avshalom Houri wrote: >=20 > Regarding: >=20 > Mar 2007 Submission of a performance and scalability analysis of the > SIMPLE presence mechanisms to the IESG for publication as Informational >=20 > Assuming that we will find things that need to be improved in e.g. 3265 > what will be the mechanism for the improvements? Via SIP WG? >=20 > --Avshalom >=20 >=20 >=20 > *IESG Secretary * >=20 > 30/01/2007 23:33 >=20 > =09 > To > iesg@ietf.org, iab@iab.org, simple@ietf.org, Robert Sparks=20 > , Hisham Khartabil > cc > =09 > Subject > [Simple] Internal WG Review: Recharter of SIP for Instant Messaging and=20 > Presence Leveraging Extensions (simple) >=20 >=20 > =09 >=20 >=20 >=20 >=20 >=20 > A new charter for the SIP for Instant Messaging and Presence Leveraging > Extensions (simple) working group in the Real-time Applications and > Infrastructure Area of the IETF is being considered. The draft charter > is provided below for your review and comment. >=20 > Review time is one week. >=20 > The IETF Secretariat >=20 > +++ >=20 > SIP for Instant Messaging and Presence Leveraging Extensions (simple) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Last Modified: 2007-1-24 >=20 > Current Status: Active Working Group >=20 > Chair(s): > Robert Sparks > Hisham Khartabil >=20 >=20 > Real-time Applications and Infrastructure Area Director(s): > Jon Peterson > Cullen Jennings >=20 > Real-time Applications and Infrastructure Area Advisor: > Jon Peterson >=20 > Technical Advisor(s): > Jon Peterson >=20 > Mailing Lists: > General Discussion: simple@ietf.org > To Subscribe: simple-request@ietf.org > In Body: subscribe > Archive: http://www.ietf.org/mail-archive/web/simple/index.html >=20 > Description of Working Group: >=20 > This working group focuses on the application of the Session Initiation > Protocol (SIP, RFC 3261) to the suite of services collectively known as > instant messaging and presence (IMP). The IETF has committed to > producing an interoperable standard for these services compliant to > the requirements for IM outlined in RFC 2779 (including the security > and privacy requirements there) and in the Common Presence and Instant > Messaging (CPIM) specification, developed within the IMPP working > group. As the most common services for which SIP is used share quite a > bit in common with IMP, the adaptation of SIP to IMP seems a natural > choice given the widespread support for (and relative maturity of) the > SIP standard. >=20 > This group has completed the majority of its primary goals and will > focus on the remaining tasks documented here and concluding. Any > proposed new work should be socialized with the chairs and AD early to > determine if this WG is an appropriate venue. >=20 > The primary remaining work of this group will be to complete: >=20 > 1. The MSRP proposed standard mechanism for transporting sessions of > messages initiated using the SIP, compliant to the requirments of RFC > 2779, CPIM and BCP 41. >=20 > 2. The XCAP framework for representing and carrying configuration and > policy information in SIMPLE systems. >=20 > 3. A mechanism for representing partial changes (patches) to XML > documents and extensions to the SIMPLE publication and notification > mechanisms to convey these partial changes. >=20 > 4. A mechanism for initiating and managing Instant Message group chat. >=20 > 5. An annotated overview of the SIMPLE protocol definition documents. >=20 > Any SIP extensions proposed in the course of this development will, > after a last call process, be transferred to the SIP WG for > consideration as formal SIP extensions. >=20 > Any mechanisms created for managing Instant Message group chat are > intended to provide a bridge to the conferencing protocols that will > be defined in XCON. They will be limited in scope to address only > simple Instant Message chat with nicknames and will not attempt > to address complex conferencing concepts such as sidebars. Their > design must anticipate operating in conjunction with the conferencing > protocols XCON is working towards. >=20 > The working group will work within the framework for presence and IM > described in RFC 2778. The extensions it defines must also be > compliant with the SIP processes for extensions. The group cannot > modify baseline SIP behavior or define a new version of SIP for IM and > presence. If the group determines that any capabilities requiring an > extension to SIP are needed, the group will seek to define such > extensions within the SIP working group, and then use them here. >=20 > Goals and Milestones: > Done Submission of event package for presence to IESG for publication as=20 > Proposed Standard > Done Submission of watcher information drafts to IESG for publication as=20 > Proposed Standards > Done Submission of proposed event list mechanism to the SIP working group > Done Submission of requirements for event publishing to the IESG for > publication as Proposed Standard > Done Submission of proposed mechanism for event publishing to the SIP > working group > Done Submission of SIMPLE PIDF profile to IESG for publication as=20 > Proposed Standard > Done Submission of base XCAP draft to IESG for publication as Proposed > Standard > Done Submission of indication of instant message preparation using SIP > to IESG for publication as a Proposed Standard > Done Submission of XCAP usage for manipulation of presence document > content > Done Submission of XCAP usage for setting presence authorization to IESG=20 > for publication as Proposed Standard > Done Submission of Filtering mechanisms to IESG for publication as a > Proposed Standard > Done Submission of instant messaging session draft to IESG for=20 > publication as a Proposed Standard > Done Submission of instant messaging session relay drafts to IESG for > publication as Proposed Standards > Done Submission of Partial Notification mechanism to IESG for=20 > publication as a Proposed Standard > Feb 2007 Submission of an Instant Message Disposition Notification > mechanism to the IESG for publication as a Proposed Standard > Feb 2007 Submission of XCAP event package to IESG or appropriate working=20 > group targeting publication as Proposed Standard > Feb 2007 Submission of proposed mechanisms meeting the advanced=20 > messaging requirements to the IESG or appropriate working group > Mar 2007 Submission of a performance and scalability analysis of the > SIMPLE presence mechanisms to the IESG for publication as Informational > Jun 2007 Submission of SIMPLE protocol annotated overview draft to IESG > for publication as Informational > Aug 2007 Submission of proposed mechanisms for initiating and managing > Instant Message group chat to the IESG for publication as Proposed > Standard > Aug 2007 Conclusion of SIMPLE >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 01 15:50:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMsED-0000mt-QH; Thu, 01 Mar 2007 15:50:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMsDz-0000ai-HW; Thu, 01 Mar 2007 15:50:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMsDy-0001Xc-Ua; Thu, 01 Mar 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id AB8F326F04; Thu, 1 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMsDy-0002cW-CW; Thu, 01 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-09.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org --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 : Presence Authorization Rules Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-rules-09.txt Pages : 29 Date : 2007-3-1 Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presence-rules-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presence-rules-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-1103507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-rules-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-rules-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-1103507.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Thu Mar 01 17:03:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMtMY-0000NO-Bb; Thu, 01 Mar 2007 17:02:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMtMW-0000MH-L1 for simple@ietf.org; Thu, 01 Mar 2007 17:02:56 -0500 Received: from extmail11.cingular.com ([170.35.225.26] helo=cingular.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMtMT-0005rd-RO for simple@ietf.org; Thu, 01 Mar 2007 17:02:56 -0500 Received: from ([10.148.14.28]) by extmail11.cingular.com with ESMTP id KP-VYHG4.115477418; Thu, 01 Mar 2007 17:02:26 -0500 Received: from TBDCEXCH10.US.Cingular.Net ([10.148.14.47]) by TD02XSMTP006.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 16:02:26 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Date: Thu, 1 Mar 2007 16:02:25 -0600 Message-ID: <451C9AB8BFB6B64EA11547A3D966DB360A88B9B2@TBDCEXCH10.US.Cingular.Net> In-Reply-To: <1170682783.3489.55.camel@n95.nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Thread-Index: AcdJKxUOAqCkAIkfTbusnzX/yjMoXATHTOtg To: X-OriginalArrivalTime: 01 Mar 2007 22:02:26.0505 (UTC) FILETIME=[4C431390:01C75C4D] From: "Stafford, Matthew" X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Since I've been very slow in answering this, here's an attempted overview of the discussion to date, followed by a question about where this leads: First of all, I think the telegraphic summary (was it provided by Miguel?) is pretty good: > - An MSRP session is intercepted by a store-and-forward server. The=20 > sender would like to be informed when the final recipient receives or=20 > reads the message(s). I guess it's an open question whether the group is interested in disposition notification functionality for sessions as a whole. (That wasn't what we were thinking about when we put together the draft.) The main *concern* that came up was: in an interactive session with numerous messages, you wouldn't want to have sender(s) requesting disposition notification on a per-message basis.=20 That concern led to the idea of: you'd need a way to distinguish between large message mode and a "true" session based experience. Jerry Shih's clarification at the time- regarding OMA's large message mode definition- was that the large message originator's client would specify send-only in the SDP session negotiation. So, if the intended recipient *did* happen to be online, said recipient would not be able to misconstrue and jump into a back-and-forth exchange where it too was asking for disposition notification. So it looks like we've got it boiled down to a question of the session initiator's behavior. My question now: suppose we were to say the originator MUST NOT incorporate DN requests in multiple MSRP messages in the same session, and moreover MUST specify send-only if it wants to request DN. (Even if a single message were chunked into multiple MSRP SENDs, I'm assuming you wouldn't want to have DN headers in each chunk- I'm thinking of the DN business as residing at a higher layer.) Would this sort of requirements be adequate? Or are we talking instead about a feature-tag or some other explicit identifier that we are in large message mode?=20 Best, Matt Stafford -----Original Message----- From: Salvatore Loreto (JO/LMF) [mailto:salvatore.loreto@ericsson.com]=20 Sent: Monday, February 05, 2007 7:40 AM To: Miguel Garcia Cc: Stafford, Matthew; 'simple@ietf.org' Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Hi Miguel, see the discussion on line br /sal > > On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote: > >> Hi: > >> > >> So, a summary of draft-stafford-simple-dmdn is that there is a use case=20 > >> that is not covered by the current IMDN, which is: > >> > >> - An MSRP session is intercepted by a store-and-forward server. The > >> sender would like to be informed when the final recipient receives or=20 > >> reads the message(s). > >> > >> One first question about the use case. It appears form the text in the=20 > >> draft that the use case applies only to large messages. However, I can=20 > >> envision store-and-forward servers that store a complete MSRP session=20 > >> (not only ONE large message). > >=20 > > you are right, if you have a store-and-forward in the path this is a > > possible scenario, even if I can not imagine at present a specific use > > case. (e.g. Why someone would establish a MSRP session with an off-line > > user and start to chat with him?) >=20 >=20 > Well, look at commercial systems. They do it. I can do it. I actually do=20 > it... I establish a session with some offline friend to send a few=20 > messages, or pending items, such as my latest pictures. This is a real > use case. Yes I am aware that some IM programs behave in this way. What I don't see is the necessity to have or provide a delivery notification in this scenario, and in fact they don't do. But I understand and fully agree with your concern about adding some header for Deliver Notification in the CPIM headers of each MSRP SEND request. >=20 >=20 > >> I think it is important to consider these collections of MSRP messages,=20 > >> because, imagine we add something to the CPIM headers of each MSRP SEND=20 > >> requesting delivery disposition notification, then the sender will=20 > >> receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND=20 > >> request. I guess this is not reasonable. > >=20 > > I agree.=20 > > A solution could be that the store-and-forward server collect all the > > message in one single big message, but in this case it shouldn't be any > > more a simple store-and-forward. >=20 > Certainly that is one possibility. Another one is to promote the IMDN=20 > request to the INVITE, and provide a "session-level" IMDN. yes, promoting the IMDN request to the INVITE could work in both the scenario: the only one large message and several short/normal messages. It can say to the final recipient to send an IMDN to the original sender when as soon as he has received the whole large message or all the short messages. For example as soon the store and forward server close the MSRP session. But promoting the IMDN request to the INVITE levels means we have also put at this level same information about the original sender. what do you think about? >=20 > In any case, I think these should be dependent on the presence of a=20 > store-and-forward server in the path. >=20 >=20 >=20 > /Miguel >=20 >=20 > >=20 > >> On the other hand, if there isn't a store-and-forward server in the > >> path, then there is no need for the sender to receive additional=20 > >> notifications, because the success reports in MSRP will do the job. > >> > >> So, I guess where we are going is to get some sort of conditional IMDN=20 > >> for MSRP. The condition being the unavailability of the recipient to get=20 > >> the messages and a store-and-forward server storing them. This will > >> obviously apply to either large messages or short ones. > >=20 > > I don't have a clear view on this, > > but maybe if we introduce a indication that an MRSP session is > > established for just sending one message, this indication could help. > >=20 > >=20 > >> Any views on this? > >> > >> BR, > >> > >> Miguel > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 01 17:26:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMtis-0006wh-HW; Thu, 01 Mar 2007 17:26:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMtir-0006wa-GS for simple@ietf.org; Thu, 01 Mar 2007 17:26:01 -0500 Received: from extmail10.cingular.com ([170.35.225.25] helo=cingular.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMtiq-0001Kt-6G for simple@ietf.org; Thu, 01 Mar 2007 17:26:01 -0500 Received: from ([10.148.14.29]) by extmail10.cingular.com with ESMTP id KP-VYFP6.93837218; Thu, 01 Mar 2007 17:25:33 -0500 Received: from TBDCEXCH10.US.Cingular.Net ([10.148.14.47]) by TD02XSMTP007.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 16:25:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Date: Thu, 1 Mar 2007 16:25:31 -0600 Message-ID: <451C9AB8BFB6B64EA11547A3D966DB360A88B9D6@TBDCEXCH10.US.Cingular.Net> In-Reply-To: <1170680541.3489.36.camel@n95.nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Thread-Index: AcdJJeIAPRx28cgzSOuhel6AyQxx7wTKazBw To: X-OriginalArrivalTime: 01 Mar 2007 22:25:32.0624 (UTC) FILETIME=[86740D00:01C75C50] From: "Stafford, Matthew" X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org One more comment about this, regarding use cases for "deferring" a whole session: what it brings to my mind is a multiparty scenario where some of my intended recipients are online and others are not. Those of us who *are* online go ahead and have our chat; the result is stored; and those who weren't available can sift through a "recording" of the session later. OMA actually defines a history function that can cover this use case, among others.=20 My main interest, at least to date, is basically feature parity between page mode and large message mode- feature parity that extends to deferred messaging use cases. Best, Matt -----Original Message----- From: Salvatore Loreto (JO/LMF) [mailto:salvatore.loreto@ericsson.com]=20 Sent: Monday, February 05, 2007 7:02 AM To: Miguel Garcia Cc: Stafford, Matthew; 'simple@ietf.org' Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Hi , some comments in line br /sal On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote: > Hi: >=20 > So, a summary of draft-stafford-simple-dmdn is that there is a use case=20 > that is not covered by the current IMDN, which is: >=20 > - An MSRP session is intercepted by a store-and-forward server. The=20 > sender would like to be informed when the final recipient receives or=20 > reads the message(s). >=20 > One first question about the use case. It appears form the text in the > draft that the use case applies only to large messages. However, I can > envision store-and-forward servers that store a complete MSRP session=20 > (not only ONE large message). you are right, if you have a store-and-forward in the path this is a possible scenario, even if I can not imagine at present a specific use case. (e.g. Why someone would establish a MSRP session with an off-line user and start to chat with him?) >=20 > I think it is important to consider these collections of MSRP messages,=20 > because, imagine we add something to the CPIM headers of each MSRP SEND=20 > requesting delivery disposition notification, then the sender will=20 > receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND=20 > request. I guess this is not reasonable. I agree.=20 A solution could be that the store-and-forward server collect all the message in one single big message, but in this case it shouldn't be any more a simple store-and-forward. >=20 > On the other hand, if there isn't a store-and-forward server in the=20 > path, then there is no need for the sender to receive additional=20 > notifications, because the success reports in MSRP will do the job. >=20 > So, I guess where we are going is to get some sort of conditional IMDN > for MSRP. The condition being the unavailability of the recipient to get=20 > the messages and a store-and-forward server storing them. This will=20 > obviously apply to either large messages or short ones. I don't have a clear view on this, but maybe if we introduce a indication that an MRSP session is established for just sending one message, this indication could help. > Any views on this? >=20 > BR, >=20 > Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 01 17:48:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMu4a-0004r5-Ve; Thu, 01 Mar 2007 17:48:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMtYJ-0004ac-94 for simple@ietf.org; Thu, 01 Mar 2007 17:15:07 -0500 Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=roundabout.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMtWn-0007lu-Gs for simple@ietf.org; Thu, 01 Mar 2007 17:13:36 -0500 Received: from roundabout.local (localhost [127.0.0.1]) by roundabout.local (Postfix) with ESMTP id E76E35ED6DE; Thu, 1 Mar 2007 15:13:31 -0700 (MST) Message-ID: <45E7500B.5080001@jabber.org> Date: Thu, 01 Mar 2007 15:13:31 -0700 From: Peter Saint-Andre Organization: XMPP Standards Foundation User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2pre) Gecko/20070116 Thunderbird/2.0b2 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: simple@ietf.org, xmppwg@xmpp.org Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: Subject: [Simple] [Fwd: I-D ACTION:draft-saintandre-xmpp-simple-09.txt] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1345794242==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1345794242== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050802090803060604050502" This is a cryptographically signed message in MIME format. --------------ms050802090803060604050502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. -------- Original Message -------- To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 01 Mar 2007 15:50:03 -0500 Subject: I-D ACTION:draft-saintandre-xmpp-simple-09.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Basic Messaging and Presence Interworking between the Extensible Messaging and Presence Protocol (XMPP) and Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Author(s) : P. Saint-Andre, et al. Filename : draft-saintandre-xmpp-simple-09.txt Pages : 35 Date : 2007-3-1 This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of presence information and single instant messages between systems that implement the Extensible Messaging and Presence Protocol (XMPP) and those that implement the basic extensions to the Session Initiation Protocol (SIP) for instant messaging and presence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-simple-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-saintandre-xmpp-simple-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-saintandre-xmpp-simple-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------ms050802090803060604050502 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA3MDMwMTIyMTMzMVowIwYJKoZIhvcNAQkEMRYEFNaEgUBNcscy/M4jfHHSJ6fVnhRcMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBABqfffL5zxNHYUB+AQEdKJ75UmldMQ3uo6EdPxc+1Vaq FxzvIoU79zNpJMlrPnTyJjAlzstIxEVQAYVBWsO+Ih5DggNTuQ8PNEJ+EL4kVXTh1+ds2Xbu YX2FygJhNXxRy6ziBrUfjKhs4iNG0I9f2bybmmwK/JvIu4j/YKySl1Xkh4qRtZmHMGuz7ggi Ax+aTSZitc9vvhWe2SorZVeq7UX2Cpbaw70oHZF4VPvWuu4mzEt5dmYemPTknHxf9UXe4TOu klHeSBT6dvdshAMRRHkaIq4/u99UpwtbTYa9JGMmr2b3aD9449MSb8gLehmeH6USiDPh4iPx VkQdMf60rqEAAAAAAAA= --------------ms050802090803060604050502-- --===============1345794242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1345794242==-- From simple-bounces@ietf.org Thu Mar 01 18:18:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMuXM-0006Ec-R5; Thu, 01 Mar 2007 18:18:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMuLF-0000Vp-5f for simple@ietf.org; Thu, 01 Mar 2007 18:05:41 -0500 Received: from extmail10.cingular.com ([170.35.225.25] helo=cingular.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMuJq-0005pM-Bn for simple@ietf.org; Thu, 01 Mar 2007 18:04:15 -0500 Received: from ([10.148.14.28]) by extmail10.cingular.com with ESMTP id KP-VYFP6.93859358; Thu, 01 Mar 2007 18:00:21 -0500 Received: from TBDCEXCH10.US.Cingular.Net ([10.148.14.47]) by TD02XSMTP006.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 17:00:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Date: Thu, 1 Mar 2007 17:00:19 -0600 Message-ID: <451C9AB8BFB6B64EA11547A3D966DB360A88BA03@TBDCEXCH10.US.Cingular.Net> In-Reply-To: <95D8C1105D54EB41864F8831E6C4EB7502906B43@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Thread-Index: AcdJLLd0xL7iQuDFQEyjNxalySfZ0gBVdXMgBHSv49A= To: X-OriginalArrivalTime: 01 Mar 2007 23:00:20.0834 (UTC) FILETIME=[631F9C20:01C75C55] From: "Stafford, Matthew" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org That's the main thing we had in mind when we wrote the draft. Best, Matt -----Original Message----- From: Nancy Greene (QA/EMC) [mailto:nancy.greene@ericsson.com]=20 Sent: Wednesday, February 07, 2007 12:59 AM To: Miguel Garcia; Salvatore Loreto (JO/LMF) Cc: simple@ietf.org Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt We can have CPIM in an MSRP SEND though, so that is where we should be concentrating. Especially if we have this large message mode where only one message is sent within the SIP session and that is the one that is actually deferred. Nancy=20 -----Original Message----- From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20 Sent: Monday, February 05, 2007 8:43 AM To: Salvatore Loreto (JO/LMF) Cc: 'simple@ietf.org' Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Salvatore Loreto (JO/LMF) wrote: > But promoting the IMDN request to the INVITE levels means we have also > put at this level same information about the original sender. what do=20 > you think about? >=20 I think it is not a straight forward option. At least, I would like to re-use IMDN as much as possible. Including IMDN requests in INVITE requests is not feasible today, since IMDN requests are embedded in CPIM messages, and we don't have CPIM in INVITE requests. /Miguel --=20 Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 01 23:07:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMz1v-0004Ub-Rh; Thu, 01 Mar 2007 23:06:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMz1u-0004ST-EF for simple@ietf.org; Thu, 01 Mar 2007 23:06:02 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMz1q-0008Ae-0H for simple@ietf.org; Thu, 01 Mar 2007 23:06:02 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 01 Mar 2007 20:05:57 -0800 X-IronPort-AV: i="4.14,239,1170662400"; d="scan'208"; a="363674394:sNHT49169856" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l2245vNW028670; Thu, 1 Mar 2007 20:05:57 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2245uDk027833; Thu, 1 Mar 2007 20:05:57 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 23:05:56 -0500 Received: from [192.168.1.104] ([10.86.241.21]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 23:05:56 -0500 Message-ID: <45E7A2A3.7000307@cisco.com> Date: Thu, 01 Mar 2007 23:05:55 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] A new draft on using ICE with MSRP References: <45E4B4F0.1080606@nokia.com> In-Reply-To: <45E4B4F0.1080606@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2007 04:05:56.0140 (UTC) FILETIME=[13D146C0:01C75C80] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2308; t=1172808357; x=1173672357; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Simple]=20A=20new=20draft=20on=20using=20ICE=20with= 20MSRP |Sender:=20; bh=2Uqx+mwneOx+GutxRooUxTa3Ijs5dQFOaODN2EOC/Eo=; b=oIytflELcABuOAfewLHYNx9ZCHHT9pShun7v7rCELGk5UPsg3jzRXs3hsQW4it0Vq4Ipcu13 L1V0WF71xs0scQDu8t+C1Yv6kh+jmpzvvyEEvMv6pe4fEy8K9XHpFqd+; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I read this with much interest. I've thought about this too, on and off, as ICE matured and gained new functionality. TCP, and then TLS got added, and the ability to have two TURN relays for a trapezoid configuration. I think the main thing that needs to be pointed out here is that, with ICE, you will end up with a separate TCP connection between a particular relay pair, for each session. One of the initial goals of MRSP relays was to allow connection reuse between peer networks. This has pros and cons; the scalability goes down, but now you can do cool stuff like e2e TLS, and if you combine that with self-signed certs and exchange of fingerprints you get a nice solution for e2e media encryption. Unfortunately I have no doubt that many folks won't want that because of the need to enforce policies on who can say what to whom, but at least the capability is there. On your open issue regarding framing, I see no problem with using the framing in RFC4571 with MSRP. I chose it because it will work with ANYTHING. I think it'd be great to work on this further and fully flesh out the pros/cons, backwards compatibility considerations and so on. -Jonathan R. Aki Niemi wrote: > Hi all, > > I've submitted a straw man proposal for using Interactive Connectivity > Establishment (ICE) with MSRP. The idea is to have the ability to use > the same NAT-traversal infrastructure with MSRP as with other media > sessions. Until it appears at the I-D directories, copies can be fetched > here: > > http://people.nokia.net/~aki/drafts/draft-niemi-simple-msrp-ice-00.txt > http://people.nokia.net/~aki/drafts/draft-niemi-simple-msrp-ice-00.html > > Comments are most welcome. The draft is a little rough around the edges, > apologies for that. > > Cheers, > Aki > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 02 01:09:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN0wT-0002w3-UE; Fri, 02 Mar 2007 01:08:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN0wR-0002Zi-V7 for simple@ietf.org; Fri, 02 Mar 2007 01:08:32 -0500 Received: from extmail10.cingular.com ([170.35.225.25] helo=cingular.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMuC6-0004yo-II for simple@ietf.org; Thu, 01 Mar 2007 17:56:15 -0500 Received: from ([10.148.14.27]) by extmail10.cingular.com with ESMTP id KP-VYFP6.93855942; Thu, 01 Mar 2007 17:55:18 -0500 Received: from TBDCEXCH10.US.Cingular.Net ([10.148.14.47]) by TD02XSMTP005.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 16:55:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] New Draft: Deferred Messaging Disposition Notification Date: Thu, 1 Mar 2007 16:55:19 -0600 Message-ID: <451C9AB8BFB6B64EA11547A3D966DB360A88B9F4@TBDCEXCH10.US.Cingular.Net> In-Reply-To: <95D8C1105D54EB41864F8831E6C4EB7502906B44@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] New Draft: Deferred Messaging Disposition Notification Thread-Index: AccivrzyD0uDK4agSi2n0Jz4+p42YQZI/3SQANlhM6ACzrlyIARzYVpg To: "Nancy Greene \(QA/EMC\)" , X-OriginalArrivalTime: 01 Mar 2007 22:55:21.0123 (UTC) FILETIME=[B07B5730:01C75C54] From: "Stafford, Matthew" X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: "Shih, Jerry" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Thank you for your comments and sorry for the (extremely) slow response. Inline. -----Original Message----- From: Nancy Greene (QA/EMC) [mailto:nancy.greene@ericsson.com]=20 Sent: Wednesday, February 07, 2007 12:59 AM To: Stafford, Matthew; simple@ietf.org Cc: Shih, Jerry Subject: RE: [Simple] New Draft: Deferred Messaging Disposition Notification I have a couple of comments on the DMDN draft: - in the flow in fig 1, it seems that steps 11-12 need to be followed by a step 12 a carrying a REPORT going from Bob's UA to the App server. This report, whether it is a success REPORT or failure REPORT is then translated into an IMDN in a SIP MESSAGE as shown in steps 15-16. Note that the BYE in steps 13-14 needs to be moved to be after the IMDN SIP MESSAGE in steps 15-16.=20 [MS]> I've mulled this over but I think I'm still missing something. Looking [MS]> at the first paragraph, section 5.3 of draft-...message-sessions-19 [MS]> (MSRP Transaction and Report Model), I tried to compare the XMPP [MS]> [MS]> interworking example that is briefly mentioned there to Fig 1 in our [MS]> DMDN I-D. It seems to me that the analogous behavior would be for the [MS]> App Server in the middle of the diagram to send an MSRP REPORT to [MS]> Alice's UA. We argue in the comments below the figure, though, that [MS]> since the MSRP session is already over and done with, and setting [MS]> a new MSRP session entails significant overhead, it would be great if [MS]> you could do the job with a SIP MESSAGE. (Provided that makes sense & [MS]> potentially represents a consensus view, perhaps I could amplify that [MS]> part of the text.)=20 [MS]> Regarding the order of SIP MESSAGE (step 15)- agree that nothing says=20 [MS]> you have to wait for the SIP BYE/200 OK to send the thing. Maybe it [MS]> would help to say that the ordering there is somewhat arbitrary and [MS]> this looked like a clean way to draw the diagram? - to set the IMDN Route header, it seems it would be straightforward - any Record-Route header in the INVITE kept when the message was deferred is later used to set the IMDN Route header in the SIP MESSAGE carrying the MSRP REPORT. [MS]> Would it really be necessary to encapsulate an MSRP REPORT in a SIP [MS]> MESSAGE? I guess what I was hoping is that the CPIM header with the IM [MS]> info would live at a higher layer and its meaning would be independent [MS]> of whether it happened to be encapsulated in SIP or MSRP. Nancy -----Original Message----- From: Stafford, Matthew [mailto:matthew.stafford@cingular.com]=20 Sent: Tuesday, January 23, 2007 6:48 PM To: simple@ietf.org Cc: Shih, Jerry Subject: RE: [Simple] New Draft: Deferred Messaging Disposition Notification Prague agenda item request: we would like to have a timeslot (20 minutes if possible) to present & discuss this draft. One of my co-authors, Jerry Shih, will be attending the session. Thanks, Matt -----Original Message----- From: Stafford, Matthew Sent: Friday, January 19, 2007 10:45 AM To: simple@ietf.org Cc: Wuthnow, Mark; Shih, Jerry Subject: [Simple] New Draft: Deferred Messaging Disposition Notification We had some discussion about a month ago re: pulling MSRP out of the IMDN draft. Thanks to Ben, Miguel and Hisham for their responses. I'd say the upshot of that discussion was twofold: the "slimmed-down" IMDN draft needs to go ahead, and any push to expand IMDN's applicability needs to start with clear documentation of requirements. Jointly with two colleagues at Cingular/AT&T, I have submitted an I-D to address the latter point. It is now posted at http://www.ietf.org/internet-drafts/draft-stafford-simple-dmdn-00.txt This draft is intended to start the ball rolling by presenting use cases. It makes a straw proposal that IMDN usage be extended to MSRP. (I do understand that there may be other, better ways to meet the requirements- but this draft still seems to be a reasonable starting point.) Best, Matt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 02 08:38:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN7xL-00005p-QJ; Fri, 02 Mar 2007 08:37:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN7xK-00005j-Ef for simple@ietf.org; Fri, 02 Mar 2007 08:37:54 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN7xE-0002vp-S2 for simple@ietf.org; Fri, 02 Mar 2007 08:37:54 -0500 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l22E1w7b001288; Fri, 2 Mar 2007 08:01:58 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 07:37:45 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Date: Fri, 2 Mar 2007 08:37:46 -0500 Message-ID: <95D8C1105D54EB41864F8831E6C4EB7502BE265E@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <451C9AB8BFB6B64EA11547A3D966DB360A88B9B2@TBDCEXCH10.US.Cingular.Net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Thread-Index: AcdJKxUOAqCkAIkfTbusnzX/yjMoXATHTOtgACHYLEA= From: "Nadia Bishai \(QA/EMC\)" To: "Stafford, Matthew" , X-OriginalArrivalTime: 02 Mar 2007 13:37:45.0061 (UTC) FILETIME=[F5872950:01C75CCF] X-Spam-Score: 0.1 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Matthew In OMA we have just accepted a CR to add a feature tag for Large Message mode. This will make it easier for both the client and the server to distinguish between different session types. Nadia Bishai=20 -----Original Message----- From: Stafford, Matthew [mailto:matthew.stafford@cingular.com]=20 Sent: March 1, 2007 5:02 PM To: simple@ietf.org Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Since I've been very slow in answering this, here's an attempted overview of the discussion to date, followed by a question about where this leads: First of all, I think the telegraphic summary (was it provided by Miguel?) is pretty good: > - An MSRP session is intercepted by a store-and-forward server. The=20 > sender would like to be informed when the final recipient receives or=20 > reads the message(s). I guess it's an open question whether the group is interested in disposition notification functionality for sessions as a whole. (That wasn't what we were thinking about when we put together the draft.) The main *concern* that came up was: in an interactive session with numerous messages, you wouldn't want to have sender(s) requesting disposition notification on a per-message basis.=20 That concern led to the idea of: you'd need a way to distinguish between large message mode and a "true" session based experience. Jerry Shih's clarification at the time- regarding OMA's large message mode definition- was that the large message originator's client would specify send-only in the SDP session negotiation. So, if the intended recipient *did* happen to be online, said recipient would not be able to misconstrue and jump into a back-and-forth exchange where it too was asking for disposition notification. So it looks like we've got it boiled down to a question of the session initiator's behavior. My question now: suppose we were to say the originator MUST NOT incorporate DN requests in multiple MSRP messages in the same session, and moreover MUST specify send-only if it wants to request DN. (Even if a single message were chunked into multiple MSRP SENDs, I'm assuming you wouldn't want to have DN headers in each chunk- I'm thinking of the DN business as residing at a higher layer.) Would this sort of requirements be adequate? Or are we talking instead about a feature-tag or some other explicit identifier that we are in large message mode?=20 Best, Matt Stafford -----Original Message----- From: Salvatore Loreto (JO/LMF) [mailto:salvatore.loreto@ericsson.com] Sent: Monday, February 05, 2007 7:40 AM To: Miguel Garcia Cc: Stafford, Matthew; 'simple@ietf.org' Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Hi Miguel, see the discussion on line br /sal > > On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote: > >> Hi: > >> > >> So, a summary of draft-stafford-simple-dmdn is that there is a use case=20 > >> that is not covered by the current IMDN, which is: > >> > >> - An MSRP session is intercepted by a store-and-forward server. The > >> sender would like to be informed when the final recipient receives or=20 > >> reads the message(s). > >> > >> One first question about the use case. It appears form the text in the=20 > >> draft that the use case applies only to large messages. However, I can=20 > >> envision store-and-forward servers that store a complete MSRP session=20 > >> (not only ONE large message). > >=20 > > you are right, if you have a store-and-forward in the path this is a > > possible scenario, even if I can not imagine at present a specific use > > case. (e.g. Why someone would establish a MSRP session with an off-line > > user and start to chat with him?) >=20 >=20 > Well, look at commercial systems. They do it. I can do it. I actually do=20 > it... I establish a session with some offline friend to send a few=20 > messages, or pending items, such as my latest pictures. This is a real > use case. Yes I am aware that some IM programs behave in this way. What I don't see is the necessity to have or provide a delivery notification in this scenario, and in fact they don't do. But I understand and fully agree with your concern about adding some header for Deliver Notification in the CPIM headers of each MSRP SEND request. >=20 >=20 > >> I think it is important to consider these collections of MSRP messages,=20 > >> because, imagine we add something to the CPIM headers of each MSRP SEND=20 > >> requesting delivery disposition notification, then the sender will=20 > >> receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND=20 > >> request. I guess this is not reasonable. > >=20 > > I agree.=20 > > A solution could be that the store-and-forward server collect all the > > message in one single big message, but in this case it shouldn't be any > > more a simple store-and-forward. >=20 > Certainly that is one possibility. Another one is to promote the IMDN=20 > request to the INVITE, and provide a "session-level" IMDN. yes, promoting the IMDN request to the INVITE could work in both the scenario: the only one large message and several short/normal messages. It can say to the final recipient to send an IMDN to the original sender when as soon as he has received the whole large message or all the short messages. For example as soon the store and forward server close the MSRP session. But promoting the IMDN request to the INVITE levels means we have also put at this level same information about the original sender. what do you think about? >=20 > In any case, I think these should be dependent on the presence of a=20 > store-and-forward server in the path. >=20 >=20 >=20 > /Miguel >=20 >=20 > >=20 > >> On the other hand, if there isn't a store-and-forward server in the > >> path, then there is no need for the sender to receive additional=20 > >> notifications, because the success reports in MSRP will do the job. > >> > >> So, I guess where we are going is to get some sort of conditional IMDN=20 > >> for MSRP. The condition being the unavailability of the recipient to get=20 > >> the messages and a store-and-forward server storing them. This will > >> obviously apply to either large messages or short ones. > >=20 > > I don't have a clear view on this, > > but maybe if we introduce a indication that an MRSP session is=20 > > established for just sending one message, this indication could help. > >=20 > >=20 > >> Any views on this? > >> > >> BR, > >> > >> Miguel > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 02 09:03:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN8LP-0008Gc-5M; Fri, 02 Mar 2007 09:02:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN8LN-0008GU-L4 for simple@ietf.org; Fri, 02 Mar 2007 09:02:45 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN8LL-0008FU-U7 for simple@ietf.org; Fri, 02 Mar 2007 09:02:45 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2007 06:02:43 -0800 X-IronPort-AV: i="4.14,241,1170662400"; d="scan'208"; a="44511418:sNHT76161006" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l22E2hjp000530; Fri, 2 Mar 2007 06:02:43 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l22E2gnH001729; Fri, 2 Mar 2007 06:02:43 -0800 (PST) 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.1830); Fri, 2 Mar 2007 09:02:30 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 09:02:29 -0500 Message-ID: <45E82E75.4000500@cisco.com> Date: Fri, 02 Mar 2007 09:02:29 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Nadia Bishai (QA/EMC)" Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt References: <95D8C1105D54EB41864F8831E6C4EB7502BE265E@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <95D8C1105D54EB41864F8831E6C4EB7502BE265E@ecamlmw720.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2007 14:02:29.0684 (UTC) FILETIME=[6A6EA740:01C75CD3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7639; t=1172844163; x=1173708163; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20Comments=20to=20draft-stafford-simple-dmdn -00.txt |Sender:=20; bh=Aeftxu00FIFGPL5FcJHWDBTRHJhfulhRL5P2pE05vAQ=; b=vbdU5+Y1mCfNcLjkLW9EV/qUHm0U/T26DI5tJABhwiR0ap6EG//DAfStOeWs7EzFznhE8Uyh KwIf1r0NcZkfOPm0ZfZHW5whqv7J7GhW1sOlja65RGj/jPIq75LtCaMG; Authentication-Results: sj-dkim-8; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Nadia Bishai (QA/EMC) wrote: > Hi Matthew > > In OMA we have just accepted a CR to add a feature tag for Large Message > mode. This will make it easier for both the client and the server to > distinguish between different session types. A *feature tag* ??? Do you mean a callee-caps feature tag? Can you explain further how that will be used? Feature tags describe *capabilities* that are supported or desired. They don't specify capabilities that are necessarily being *used*. And they apply to the UA, not to a particular media stream a UA might be using. So, using a feature tag might be fine if it means "I have the capability to support large message mode". But it isn't fine if it is intended to mean "This INVITE is being used to establish a session using Large Message Mode". Paul > Nadia Bishai > > -----Original Message----- > From: Stafford, Matthew [mailto:matthew.stafford@cingular.com] > Sent: March 1, 2007 5:02 PM > To: simple@ietf.org > Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt > > Since I've been very slow in answering this, here's an attempted > overview of the discussion to date, followed by a question about where > this leads: > > First of all, I think the telegraphic summary (was it provided by > Miguel?) is pretty good: >> - An MSRP session is intercepted by a store-and-forward server. The >> sender would like to be informed when the final recipient receives or >> reads the message(s). > > I guess it's an open question whether the group is interested in > disposition notification functionality for sessions as a whole. (That > wasn't what we were thinking about when we put together the draft.) > > The main *concern* that came up was: in an interactive session with > numerous messages, you wouldn't want to have sender(s) requesting > disposition notification on a per-message basis. > > That concern led to the idea of: you'd need a way to distinguish between > large message mode and a "true" session based experience. Jerry Shih's > clarification at the time- regarding OMA's large message mode > definition- was that the large message originator's client would specify > send-only in the SDP session negotiation. So, if the intended recipient > *did* happen to be online, said recipient would not be able to > misconstrue and jump into a back-and-forth exchange where it too was > asking for disposition notification. So it looks like we've got it > boiled down to a question of the session initiator's behavior. > > My question now: suppose we were to say the originator MUST NOT > incorporate DN requests in multiple MSRP messages in the same session, > and moreover MUST specify send-only if it wants to request DN. (Even if > a single message were chunked into multiple MSRP SENDs, I'm assuming you > wouldn't want to have DN headers in each chunk- I'm thinking of the DN > business as residing at a higher layer.) > > Would this sort of requirements be adequate? Or are we talking instead > about a feature-tag or some other explicit identifier that we are in > large message mode? > > Best, > Matt Stafford > > -----Original Message----- > From: Salvatore Loreto (JO/LMF) [mailto:salvatore.loreto@ericsson.com] > Sent: Monday, February 05, 2007 7:40 AM > To: Miguel Garcia > Cc: Stafford, Matthew; 'simple@ietf.org' > Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt > > Hi Miguel, > > see the discussion on line > > br > /sal > >>> On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote: >>>> Hi: >>>> >>>> So, a summary of draft-stafford-simple-dmdn is that there is a use > case >>>> that is not covered by the current IMDN, which is: >>>> >>>> - An MSRP session is intercepted by a store-and-forward server. The > >>>> sender would like to be informed when the final recipient receives > or >>>> reads the message(s). >>>> >>>> One first question about the use case. It appears form the text in > the >>>> draft that the use case applies only to large messages. However, I > can >>>> envision store-and-forward servers that store a complete MSRP > session >>>> (not only ONE large message). >>> you are right, if you have a store-and-forward in the path this is a > >>> possible scenario, even if I can not imagine at present a specific > use >>> case. (e.g. Why someone would establish a MSRP session with an > off-line >>> user and start to chat with him?) >> >> Well, look at commercial systems. They do it. I can do it. I actually > do >> it... I establish a session with some offline friend to send a few >> messages, or pending items, such as my latest pictures. This is a real > >> use case. > > Yes I am aware that some IM programs behave in this way. > What I don't see is the necessity to have or provide a delivery > notification in this scenario, and in fact they don't do. > But I understand and fully agree with your concern about adding some > header for Deliver Notification in the CPIM headers of each MSRP SEND > request. > >> >>>> I think it is important to consider these collections of MSRP > messages, >>>> because, imagine we add something to the CPIM headers of each MSRP > SEND >>>> requesting delivery disposition notification, then the sender will >>>> receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND >>>> request. I guess this is not reasonable. >>> I agree. >>> A solution could be that the store-and-forward server collect all > the >>> message in one single big message, but in this case it shouldn't be > any >>> more a simple store-and-forward. >> Certainly that is one possibility. Another one is to promote the IMDN >> request to the INVITE, and provide a "session-level" IMDN. > > yes, promoting the IMDN request to the INVITE could work in both the > scenario: the only one large message and several short/normal messages. > It can say to the final recipient to send an IMDN to the original sender > when as soon as he has received the whole large message or all the short > messages. For example as soon the store and forward server close the > MSRP session. > But promoting the IMDN request to the INVITE levels means we have also > put at this level same information about the original sender. what do > you think about? > > > >> In any case, I think these should be dependent on the presence of a >> store-and-forward server in the path. >> >> >> >> /Miguel >> >> >>>> On the other hand, if there isn't a store-and-forward server in the > >>>> path, then there is no need for the sender to receive additional >>>> notifications, because the success reports in MSRP will do the job. >>>> >>>> So, I guess where we are going is to get some sort of conditional > IMDN >>>> for MSRP. The condition being the unavailability of the recipient > to get >>>> the messages and a store-and-forward server storing them. This will > >>>> obviously apply to either large messages or short ones. >>> I don't have a clear view on this, >>> but maybe if we introduce a indication that an MRSP session is >>> established for just sending one message, this indication could > help. >>> >>>> Any views on this? >>>> >>>> BR, >>>> >>>> Miguel > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 02 12:29:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNBYg-0000PW-FL; Fri, 02 Mar 2007 12:28:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNBYc-0000Dd-1a; Fri, 02 Mar 2007 12:28:38 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNBYa-0005cg-RJ; Fri, 02 Mar 2007 12:28:38 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id C8B6D3289C; Fri, 2 Mar 2007 17:28:36 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HNBYa-0002AW-N2; Fri, 02 Mar 2007 12:28:36 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 02 Mar 2007 12:28:36 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: simple@ietf.org Subject: [Simple] Last Call: draft-ietf-simple-presence-rules (Presence Authorization Rules) to Proposed Standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'Presence Authorization Rules ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-03-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Note that the document includes a Normative Reference to RFC 3325 which is Informational. This is a Downward Reference as per RFC 3967. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11777&rfc_flag=0 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 02 15:37:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNEUe-0002N2-Oi; Fri, 02 Mar 2007 15:36:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNEUe-0002Ms-1e for simple@ietf.org; Fri, 02 Mar 2007 15:36:44 -0500 Received: from extmail12.cingular.com ([170.35.225.27] helo=cingular.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNEUb-0008Ta-BV for simple@ietf.org; Fri, 02 Mar 2007 15:36:44 -0500 Received: from ([10.148.14.29]) by extmail12.cingular.com with ESMTP id KP-VYHH4.101174661; Fri, 02 Mar 2007 15:36:28 -0500 Received: from TBDCEXCH10.US.Cingular.Net ([10.148.14.47]) by TD02XSMTP007.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 14:35:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Date: Fri, 2 Mar 2007 14:35:58 -0600 Message-ID: <451C9AB8BFB6B64EA11547A3D966DB360AAC97E0@TBDCEXCH10.US.Cingular.Net> In-Reply-To: <95D8C1105D54EB41864F8831E6C4EB7502BE265E@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Thread-Index: AcdJKxUOAqCkAIkfTbusnzX/yjMoXATHTOtgACHYLEAADqywEA== To: X-OriginalArrivalTime: 02 Mar 2007 20:35:59.0844 (UTC) FILETIME=[632F2A40:01C75D0A] From: "Stafford, Matthew" X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Thx. -----Original Message----- From: Nadia Bishai (QA/EMC) [mailto:nadia.bishai@ericsson.com]=20 Sent: Friday, March 02, 2007 7:38 AM To: Stafford, Matthew; simple@ietf.org Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Hi Matthew In OMA we have just accepted a CR to add a feature tag for Large Message mode. This will make it easier for both the client and the server to distinguish between different session types. Nadia Bishai=20 -----Original Message----- From: Stafford, Matthew [mailto:matthew.stafford@cingular.com]=20 Sent: March 1, 2007 5:02 PM To: simple@ietf.org Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Since I've been very slow in answering this, here's an attempted overview of the discussion to date, followed by a question about where this leads: First of all, I think the telegraphic summary (was it provided by Miguel?) is pretty good: > - An MSRP session is intercepted by a store-and-forward server. The=20 > sender would like to be informed when the final recipient receives or=20 > reads the message(s). I guess it's an open question whether the group is interested in disposition notification functionality for sessions as a whole. (That wasn't what we were thinking about when we put together the draft.) The main *concern* that came up was: in an interactive session with numerous messages, you wouldn't want to have sender(s) requesting disposition notification on a per-message basis.=20 That concern led to the idea of: you'd need a way to distinguish between large message mode and a "true" session based experience. Jerry Shih's clarification at the time- regarding OMA's large message mode definition- was that the large message originator's client would specify send-only in the SDP session negotiation. So, if the intended recipient *did* happen to be online, said recipient would not be able to misconstrue and jump into a back-and-forth exchange where it too was asking for disposition notification. So it looks like we've got it boiled down to a question of the session initiator's behavior. My question now: suppose we were to say the originator MUST NOT incorporate DN requests in multiple MSRP messages in the same session, and moreover MUST specify send-only if it wants to request DN. (Even if a single message were chunked into multiple MSRP SENDs, I'm assuming you wouldn't want to have DN headers in each chunk- I'm thinking of the DN business as residing at a higher layer.) Would this sort of requirements be adequate? Or are we talking instead about a feature-tag or some other explicit identifier that we are in large message mode?=20 Best, Matt Stafford -----Original Message----- From: Salvatore Loreto (JO/LMF) [mailto:salvatore.loreto@ericsson.com] Sent: Monday, February 05, 2007 7:40 AM To: Miguel Garcia Cc: Stafford, Matthew; 'simple@ietf.org' Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Hi Miguel, see the discussion on line br /sal > > On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote: > >> Hi: > >> > >> So, a summary of draft-stafford-simple-dmdn is that there is a use case=20 > >> that is not covered by the current IMDN, which is: > >> > >> - An MSRP session is intercepted by a store-and-forward server. The > >> sender would like to be informed when the final recipient receives or=20 > >> reads the message(s). > >> > >> One first question about the use case. It appears form the text in the=20 > >> draft that the use case applies only to large messages. However, I can=20 > >> envision store-and-forward servers that store a complete MSRP session=20 > >> (not only ONE large message). > >=20 > > you are right, if you have a store-and-forward in the path this is a > > possible scenario, even if I can not imagine at present a specific use > > case. (e.g. Why someone would establish a MSRP session with an off-line > > user and start to chat with him?) >=20 >=20 > Well, look at commercial systems. They do it. I can do it. I actually do=20 > it... I establish a session with some offline friend to send a few=20 > messages, or pending items, such as my latest pictures. This is a real > use case. Yes I am aware that some IM programs behave in this way. What I don't see is the necessity to have or provide a delivery notification in this scenario, and in fact they don't do. But I understand and fully agree with your concern about adding some header for Deliver Notification in the CPIM headers of each MSRP SEND request. >=20 >=20 > >> I think it is important to consider these collections of MSRP messages,=20 > >> because, imagine we add something to the CPIM headers of each MSRP SEND=20 > >> requesting delivery disposition notification, then the sender will=20 > >> receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND=20 > >> request. I guess this is not reasonable. > >=20 > > I agree.=20 > > A solution could be that the store-and-forward server collect all the > > message in one single big message, but in this case it shouldn't be any > > more a simple store-and-forward. >=20 > Certainly that is one possibility. Another one is to promote the IMDN=20 > request to the INVITE, and provide a "session-level" IMDN. yes, promoting the IMDN request to the INVITE could work in both the scenario: the only one large message and several short/normal messages. It can say to the final recipient to send an IMDN to the original sender when as soon as he has received the whole large message or all the short messages. For example as soon the store and forward server close the MSRP session. But promoting the IMDN request to the INVITE levels means we have also put at this level same information about the original sender. what do you think about? >=20 > In any case, I think these should be dependent on the presence of a=20 > store-and-forward server in the path. >=20 >=20 >=20 > /Miguel >=20 >=20 > >=20 > >> On the other hand, if there isn't a store-and-forward server in the > >> path, then there is no need for the sender to receive additional=20 > >> notifications, because the success reports in MSRP will do the job. > >> > >> So, I guess where we are going is to get some sort of conditional IMDN=20 > >> for MSRP. The condition being the unavailability of the recipient to get=20 > >> the messages and a store-and-forward server storing them. This will > >> obviously apply to either large messages or short ones. > >=20 > > I don't have a clear view on this, > > but maybe if we introduce a indication that an MRSP session is=20 > > established for just sending one message, this indication could help. > >=20 > >=20 > >> Any views on this? > >> > >> BR, > >> > >> Miguel > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From axaepsvi@nes-peo.com Sat Mar 03 13:13:07 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNYjD-0000JH-8m for simple-archive@lists.ietf.org; Sat, 03 Mar 2007 13:13:07 -0500 Received: from [66.255.95.74] (helo=nesdnssrvr.nes-peo.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HNYjA-0000kB-OX for simple-archive@lists.ietf.org; Sat, 03 Mar 2007 13:13:07 -0500 From: "what. Taylor" To: simple-archive@lists.ietf.org Subject: Approval process Date: Sat, 3 Mar 2007 13:13:46 +0500 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C75D95.C667A520" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcddlcZnheYz8OztSSOW5/BmNCurmQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <1973BB9023ECD4F.F93C1CC960@nes-peo.com> X-Spam-Score: 2.6 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ------=_NextPart_000_0001_01C75D95.C667A520 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
--- Your order was successfully submitted ---

Your order is pending, your card has not yet been charged.....
we will process your order within 24hrs,
once it has passed a series of fraud checks.

Please visit the confirmation link http://skuliod.com/et/

Thank you for shopping with us!
------=_NextPart_000_0001_01C75D95.C667A520-- From virlgzvxsn@cntrx.com Sun Mar 04 01:39:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNkNc-00041M-NK for simple-archive@lists.ietf.org; Sun, 04 Mar 2007 01:39:36 -0500 Received: from [121.24.52.238] (helo=[121.24.52.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNkNb-0004cB-30 for simple-archive@lists.ietf.org; Sun, 04 Mar 2007 01:39:36 -0500 From: "Idea." To: simple-archive@lists.ietf.org Subject: Traders Daily Report Date: Sun, 4 Mar 2007 14:39:22 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C75E6A.E633B080" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdeauYzjv/y5YZgRxK6w3jHkCnxfg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.8 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ------=_NextPart_000_0005_01C75E6A.E633B080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
GDKI IS GETTING READY FOR ANOTHER HUGE BREAKDANCE MONDAY!
HIP-HOP is more than just music... HIP-HOP IS A CULTURE!

GOLDMARK IND - www [dot] goldmarkentertainment [dot] com

CHECK *GDKI* OUT ON - MONDAY FEB 05 2007
RADAR: GDKI
SHARES OPEN MON AT: $0.105

GOLDMARK INDUSTRIES, specializes in the production and distribution of Music, Feature Films and Television entertainment for North America's most rapidly growing demographic, with a total consumer-based purchasing power of over 1 Trillion dollars: the Hip-Hop community.

GDKI THE RISING STAR, IS SET FOR SUPERNOVA STATUS ON 03/05/07!
HABANA.. HABANA.. HABANA BLUES!!
------=_NextPart_000_0005_01C75E6A.E633B080-- From pejjdnkh@bezeqint.net Sun Mar 04 09:42:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNrvD-0002dW-AH for simple-archive@lists.ietf.org; Sun, 04 Mar 2007 09:42:47 -0500 Received: from bzq-88-153-72-17.red.bezeqint.net ([88.153.72.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNrvB-0000Rw-RH for simple-archive@lists.ietf.org; Sun, 04 Mar 2007 09:42:47 -0500 From: "T::Z" To: simple-archive@lists.ietf.org Subject: Wall Street Alert Date: Sun, 4 Mar 2007 16:46:21 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0004_01C75E7C.A3AC4440" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdefKOsTqb07YTVR0iswpl65aIZPw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <4C49E36827941E0.E7EDB4FD1E@bezeqint.net> X-Spam-Score: 4.4 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ------=_NextPart_000_0004_01C75E7C.A3AC4440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
GDKI IS GETTING READY FOR ANOTHER HUGE BREAKDANCE MONDAY!
HIP-HOP is more than just music... HIP-HOP IS A CULTURE!

GOLDMARK IND - www [dot] goldmarkentertainment [dot] com

CHECK *GDKI* OUT ON - MONDAY FEB 05 2007
RADAR: GDKI
SHARES OPEN MON AT: $0.105

GOLDMARK INDUSTRIES, specializes in the production and distribution of Music, Feature Films and Television entertainment for North America's most rapidly growing demographic, with a total consumer-based purchasing power of over 1 Trillion dollars: the Hip-Hop community.

GDKI THE RISING STAR, IS SET FOR SUPERNOVA STATUS ON 03/05/07!
HABANA.. HABANA.. HABANA BLUES!!
------=_NextPart_000_0004_01C75E7C.A3AC4440-- From simple-bounces@ietf.org Sun Mar 04 16:13:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNy0H-0001N7-5v; Sun, 04 Mar 2007 16:12:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNy0E-0001M8-Iz for simple@ietf.org; Sun, 04 Mar 2007 16:12:22 -0500 Received: from wx-out-0506.google.com ([66.249.82.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNy0E-0007WQ-3j for simple@ietf.org; Sun, 04 Mar 2007 16:12:22 -0500 Received: by wx-out-0506.google.com with SMTP id h31so1459773wxd for ; Sun, 04 Mar 2007 13:12:21 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=lkXSPDRB702qIAYfk+7KIz3IYGLh+5bxQLFuAJPOFQ4mAt1PY3v11iWt9g22moiCVCqp68hYGy86MSEDibv+VIxpMLUZ5/jtt8uDwCu2sMNhcY54ozlqlgdBFTyUe/rR6q4U5/yDJe3JjkK7HHyAJshkkFdxgHWN3JJW1XSnkTY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=uPcDN0CUnxrp7knkE096W7JhF9HaP7IxCwUewtxlRAoqqNfVLo9OXrFm2au1JcwZornGrEFN+u0uSEdafWM6EvkYiof9IZA6ItkG3rmhzr7GPTDxtG9enJ+OYWQT98w5jaPAUQjNGnNObGRzKKF0paobs3768Yn7rTgw6dMD8nU= Received: by 10.114.111.1 with SMTP id j1mr1034821wac.1173042740910; Sun, 04 Mar 2007 13:12:20 -0800 (PST) Received: by 10.114.88.2 with HTTP; Sun, 4 Mar 2007 13:12:20 -0800 (PST) Message-ID: Date: Sun, 4 Mar 2007 21:12:20 +0000 From: "Eduardo Martins" To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Subject: [Simple] Response to an Invalid XCAP URI? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0477633657==" Errors-To: simple-bounces@ietf.org --===============0477633657== Content-Type: multipart/alternative; boundary="----=_Part_129752_9004444.1173042740619" ------=_Part_129752_9004444.1173042740619 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I have some doubts on what response error should be returned, by the server, when it receives a request with an invalid resource selector. Possible reasons for an invalid xcap uri: 1. Invalid document selector or node selector draft says, in Server Behavior: "... When the server receives a request, the treatment depends on the URI. If the URI refers to an application usage not understood by the server, the server MUST reject the request with a 404 (Not Found) response. If the URI refers to a user that is not recognized by the server, it MUST reject the request with a 404 (Not Found). ... Next, the server makes sure that it can properly evaluate the request URI. The server MUST check the node selector in the request URI, if present. If any qualified names are present that use a namespace prefix, and that prefix is not defined in an xmlns() expression in the query component of the request URI, the server MUST reject the request with a 400 response. " So what should be returned if after the auid comes something else besides global or users? then in PUT handling " ... The first step the server performs is to locate the parent, whether it is a directory or element, in which the resource is to be placed. To do that, the server removes the last path segment from the URI. The rest of the URI refers to the parent. This parent can be a document, element, or prefix of a document selector (called a directory, even though this specification does not mandate that documents are actually stored in a filesystem). This URI is called the parent URI. The path segment that was removed is called the target selector, and the node (element, document or attribute) it describes is called the target node. ... If the parent URI has a node selector separator, the document selector is extracted, and that document is retrieved. If the document does not exist, the server MUST return a 409 response, and SHOULD include a detailed conflict report including the element. If it does exist, the node selector is extracted, and decoded (recall that the node selector is percent-encoded). The node selector is applied to the document based on the matching operations discussed in Section 6.3. If the result is a no-match or invalid, the server MUST return a 409 response, and SHOULD include a detailed conflict report including the element." This mean that if an invalid node selector is received the server should find an existing ancestor. As an example, consider a node selector like /resource-lists//list[@id='example'] Considering also that resource-lists exists in the document this means it will return it as the ancestor, but I'm not sure it such a reply would make sense to the client. Wouldn't be better to have an invalid URI XCAP error? Now lets check the GET handling: "... If the request URI contains a node selector, the server obtains the document specified by the document selector, and if it is found, evaluates the node-selector within that document. If no document is found, or if the node-selector is a no-match or invalid, the server returns a 404 response." then in DELETE handling: "... If the request URI contains only a document selector, the server deletes the document specified by the URI if it exists and returns a 200 OK, else returns a 404 response. If the request URI contains a node selector, the server obtains the document specified by the document selector, and if it is found, evaluates the node-selector within that document. If no document is found, or if the node-selector is a no-match or invalid (note that it will be invalid if multiple elements or attributes are selected), the server returns a 404 response." Ok, for GET and DELETE the error on an invalid document and node selector it's always a 404. 2. Invalid query component Nothing is said here, what would be the expected error for an xpointer diff than xmlns? Best regards, Eduardo Martins ------=_Part_129752_9004444.1173042740619 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I have some doubts on what response error should be returned, by the server, when it receives a request with an invalid resource selector.

Possible reasons for an invalid xcap uri:

1. Invalid document selector or node selector

draft says, in Server Behavior:

"... When the server receives a request, the treatment depends on the URI.
  If the URI refers to an application usage not understood by the
  server, the server MUST reject the request with a 404 (Not Found)
  response.  If the URI refers to a user that is not recognized by the
  server, it MUST reject the request with a 404 (Not Found).

... Next, the server makes sure that it can properly evaluate the request
   URI.  The server MUST check the node selector in the request URI, if
   present.  If any qualified names are present that use a namespace
   prefix, and that prefix is not defined in an xmlns() expression in
   the query component of the request URI, the server MUST reject the
   request with a 400 response.
"
So what should be returned if after the auid comes something else besides
global or users?

then in PUT handling

"  ... The first step the server performs is to locate the parent, whether
   it is a directory or element, in which the resource is to be placed.
   To do that, the server removes the last path segment from the URI.
   The rest of the URI refers to the parent.  This parent can be a
   document, element, or prefix of a document selector (called a
   directory, even though this specification does not mandate that
   documents are actually stored in a filesystem).  This URI is called
   the parent URI.  The path segment that was removed is called the
   target selector, and the node (element, document or attribute) it
   describes is called the target node.

   ... If the parent URI has a node selector separator, the document
   selector is extracted, and that document is retrieved.  If the
   document does not exist, the server MUST return a 409 response, and
   SHOULD include a detailed conflict report including the <no-parent>
   element.  If it does exist, the node selector is extracted, and
   decoded (recall that the node selector is percent-encoded).  The node
   selector is applied to the document based on the matching operations
   discussed in Section 6.3.  If the result is a no-match or invalid,
   the server MUST return a 409 response, and SHOULD include a detailed
   conflict report including the <no-parent> element. "

This mean that if an invalid node selector is received the server should find an
existing ancestor.

As an example, consider a node selector like

/resource-lists//list[@id='example']

Considering also that resource-lists exists in the document this means it will
return it as the ancestor, but I'm not sure it such a reply would make sense to the client.
Wouldn't be better to have an invalid URI XCAP error?

Now lets check the GET handling:

"... If the request URI contains a node selector, the server obtains the
   document specified by the document selector, and if it is found,
   evaluates the node-selector within that document.  If no document is
   found, or if the node-selector is a no-match or invalid, the server
   returns a 404 response."

then in DELETE handling:

"... If the request URI contains only a document selector, the server
   deletes the document specified by the URI if it exists and returns a
   200 OK, else returns a 404 response.

   If the request URI contains a node selector, the server obtains the
   document specified by the document selector, and if it is found,
   evaluates the node-selector within that document.  If no document is
   found, or if the node-selector is a no-match or invalid (note that it
   will be invalid if multiple elements or attributes are selected), the
   server returns a 404 response."

Ok, for GET and DELETE the error on an invalid document and node selector it's always a 404.

2. Invalid query component

Nothing is said here, what would be the expected error for an xpointer diff than xmlns?

Best regards,

Eduardo Martins
------=_Part_129752_9004444.1173042740619-- --===============0477633657== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0477633657==-- From mnrdagfutj@iae.nl Mon Mar 05 10:13:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEst-0003F7-EJ for simple-archive@lists.ietf.org; Mon, 05 Mar 2007 10:13:55 -0500 Received: from dsl-121-068.iae.nl ([212.61.121.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOEss-0004La-18 for simple-archive@lists.ietf.org; Mon, 05 Mar 2007 10:13:55 -0500 From: "BROWSE BOOKSNEW" To: simple-archive@lists.ietf.org Subject: Next Big market Winner Date: Mon, 5 Mar 2007 16:25:26 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0003_01C75F42.E19299F0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdfQuGSX5F6HrNmRhS1FIjbf1hiUQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 2.7 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 ------=_NextPart_000_0003_01C75F42.E19299F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
GDKI STEPS UP TO BAT FOR ANOTHER HOMERUN MONDAY!
GOLDMARK - FULL SCALE PRODUCTION AND DISTRIBUTION OF WORLD WIDE ENTERTAINMENT!

TICKER: GDKI
OPENING: $0.105
WHEN? - MONDAY FEB 05 2007

The strength of Goldmark Industries is the result of its highly reputable and continuously growing management team. The knowledge and experience that each team member brings consistently supports the growing success of each division at Goldmark Industries. In addition, they are associated with some of the world's leading entertainment companies and top distribution channels worldwide, providing Goldmark Industries with the relationships to continually move forward.

HABANA BLUES STILL MAKING NEWS!! HEADING FOR THE TOP OF THE MOUNTAIN!
------=_NextPart_000_0003_01C75F42.E19299F0-- From simple-bounces@ietf.org Mon Mar 05 12:03:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOGZF-0003Vs-C2; Mon, 05 Mar 2007 12:01:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOGZB-0003Cl-JK for simple@ietf.org; Mon, 05 Mar 2007 12:01:41 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOGVx-0001t0-UQ for simple@ietf.org; Mon, 05 Mar 2007 11:58:24 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-2.cisco.com with ESMTP; 05 Mar 2007 08:58:21 -0800 X-IronPort-AV: i="4.14,251,1170662400"; d="scan'208"; a="364015724:sNHT41877468" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l25GwKSd001585 for ; Mon, 5 Mar 2007 11:58:20 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l25GwFZb023801 for ; Mon, 5 Mar 2007 16:58:20 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.1830); Mon, 5 Mar 2007 11:58:18 -0500 Received: from [192.168.1.104] ([10.86.242.117]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 11:58:17 -0500 Message-ID: <45EC4C28.70907@cisco.com> Date: Mon, 05 Mar 2007 11:58:16 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2007 16:58:17.0653 (UTC) FILETIME=[78C03E50:01C75F47] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=594; t=1173113900; x=1173977900; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Minor=20update=20to=20xcap-diff |Sender:=20 |To:=20Simple=20WG=20; bh=ukMxQuZHPKlqB7E2Ts2qNoLOYvtOQIWk4Ivew31LnW4=; b=hmfO2JbI2Rd/nwP4JTZUEoogA7/tCQjKVjYpfywnGYi5KNJFWehCBir9C8xioiLt7QZp3VWD q9uweh67IM3mvM3nQ804KcTywEQJe9je3t5TjPZe7qznziLFrYANQE01; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Simple] Minor update to xcap-diff X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Until it appears in the archives: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-diff-05.txt This makes a schema change to eliminate ambiguity on the root element, as suggested by Martin Hynar. This document was, and still is, ready to go. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 05 14:56:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOJGy-0002Or-Mz; Mon, 05 Mar 2007 14:55:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOJGw-0002NB-UJ for simple@ietf.org; Mon, 05 Mar 2007 14:55:02 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOJGv-00083n-Jt for simple@ietf.org; Mon, 05 Mar 2007 14:55:02 -0500 Received: from [172.17.1.65] ([172.17.1.65]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l25JsxT6041973 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 5 Mar 2007 13:54:59 -0600 (CST) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <468ECB41-A8FA-4982-82FB-F0ABD7CE802D@estacado.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: simple@ietf.org From: Robert Sparks Date: Mon, 5 Mar 2007 13:54:57 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Simple] SIMPLE agenda planning X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org We have two hours of SIMPLE meeting in Prague. I will send a detailed agenda tomorrow. This is the general content I'm expecting it to reflect. We're going to spend some time going through our new charter and finalizing plans to finish the milestones reflected there. To that end, I will provide an update on where IMDN is as of that time. Aki and Miguel will discuss the work on chat. Avshalom will discuss what we need to do to finish and publish the interdomain analysis draft. There has been some discussion here and elsewhere on DMDN. I plan to spend some meeting time building clarity around where and what work on this idea will continue. We are not looking for new work in SIMPLE. There are a couple of recent drafts that make sense to discuss briefly in this context, however, if time allows. In this set, we have a draft from Aki on using ICE with MSRP, and a draft from Vishal on a package for vehicle information. If there are others that I've missed, let me know. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 05 16:48:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOL2F-0003hI-Ga; Mon, 05 Mar 2007 16:47:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOL2D-0003gF-Jr for simple@ietf.org; Mon, 05 Mar 2007 16:47:57 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOL1i-0007XR-Q8 for simple@ietf.org; Mon, 05 Mar 2007 16:47:56 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l25LdCt21042 for ; Mon, 5 Mar 2007 16:39:12 -0500 (EST) 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: Mon, 5 Mar 2007 15:47:23 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated: draft-boulton-xcon-msrp-conferencing-04 Thread-index: AcdfbqF6X/G9u5AFQfmtfMVN0Tbi0QAAATKw From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Simple] FW: Updated: draft-boulton-xcon-msrp-conferencing-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Just an FYI since this topic (multi-party IM sessions - aka SIMPLE chat) has been discussed in SIMPLE in the past and is proposed for the IETF-68 agenda.=20 =20 As background, the document below describes how the multiparty sessions based on MSRP can be accomplished within the XCON framework. Feedback on this document should be directed to the XCON mailing list. Mary. -----Original Message----- From: Barnes, Mary (RICH2:AR00)=20 Sent: Monday, March 05, 2007 3:39 PM To: 'xcon@ietf.org' Cc: 'cboulton@ubiquitysoftware.com' Subject: Updated: draft-boulton-xcon-msrp-conferencing-04 We've updated the draft describing MSRP conferencing: http://www.ietf.org/internet-drafts/draft-boulton-xcon-msrp-conferencing -04.txt The primary changes were updating references and adding alot of content describing the basic (create, join, delete) and advanced (Text sidebars and private messaging) protocol operations. Feedback would be appreciated. =20 Regard, Mary=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 05 19:39:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HONhR-0007BY-0i; Mon, 05 Mar 2007 19:38:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HONhP-0007BH-H0 for simple@ietf.org; Mon, 05 Mar 2007 19:38:39 -0500 Received: from smtp3.versatel.nl ([62.58.50.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HONhO-0004Nh-4d for simple@ietf.org; Mon, 05 Mar 2007 19:38:39 -0500 Received: (qmail 23748 invoked by uid 0); 6 Mar 2007 00:38:15 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 6 Mar 2007 00:38:15 -0000 Message-ID: <005301c75f87$c1020ff0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" , "Simple WG" References: <45EC4C28.70907@cisco.com> Subject: Re: [Simple] Minor update to xcap-diff Date: Tue, 6 Mar 2007 01:38:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Probably considerably late, and not sure if appreciated, but here's a comment: The bit about the optional "hash" attribute and using canonicalization and SHA1 sounds like a quick but limited way of doing XML-signature (http://www.w3.org/TR/xmldsig-core/). If I were a W3C person, I would argue that since there is already a standard for doing this, why not use that? It seems a rather isolated feature and feels a bit out of place to me. Would it be an idea to remove it? I mean, server MAY include it, client MAY ignore it, and what is supposed to happen when server includes it, client checks it, and check fails? Regards, Jeroen PS the reference to XML is outdated: http://www.w3.org/TR/REC-xml/ is newer than http://www.w3.org/TR/2004/REC-xml-20040204/ Jonathan Rosenberg wrote: > Until it appears in the archives: > http://www.jdrosen.net/papers/draft-ietf-simple-xcap-diff-05.txt > > This makes a schema change to eliminate ambiguity on the root element, > as suggested by Martin Hynar. > > This document was, and still is, ready to go. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 06 02:06:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOTk7-0005TM-SQ; Tue, 06 Mar 2007 02:05:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOTk4-0005Q2-Us for simple@ietf.org; Tue, 06 Mar 2007 02:05:48 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOTk1-0002mp-Eo for simple@ietf.org; Tue, 06 Mar 2007 02:05:48 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2675KUa001241 for ; Tue, 6 Mar 2007 09:05:41 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 09:05:29 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 09:05:27 +0200 Received: from [172.21.58.61] ([172.21.58.61]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 09:05:27 +0200 Message-ID: <45ED12B7.8080703@nokia.com> Date: Tue, 06 Mar 2007 09:05:27 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "'simple@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2007 07:05:27.0675 (UTC) FILETIME=[D1CE14B0:01C75FBD] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070306090541-7EB6ABB0-32B70560/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Niemi Aki Subject: [Simple] MSRP chat version -06 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Yesterday we submitted version -06 of the MSRP chat draft. It may take a few hours/days until it is officially available. In the meantime, you can get a copy from: http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-06.txt http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-06.html This version tries to put a scope on the draft to solve only two issues: nicknames and private messaging. We added a bunch of examples as well, so hopefully this will increase readability. Comments, as usually, are welcomed. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 06 02:08:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOTmL-0006eC-2n; Tue, 06 Mar 2007 02:08:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOTmJ-0006b6-U4 for simple@ietf.org; Tue, 06 Mar 2007 02:08:07 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOTmI-0003B0-Eu for simple@ietf.org; Tue, 06 Mar 2007 02:08:07 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2677dep007110 for ; Tue, 6 Mar 2007 09:08:04 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 09:07:57 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 09:07:57 +0200 Received: from [172.21.58.61] ([172.21.58.61]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 09:07:57 +0200 Message-ID: <45ED134D.9070809@nokia.com> Date: Tue, 06 Mar 2007 09:07:57 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "'simple@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2007 07:07:57.0764 (UTC) FILETIME=[2B43D840:01C75FBE] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070306090804-1B505BB0-5A902663/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Simple] Sigcomp presence dictionary -02 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Yesterday I submitted version -02 of the presence dictionary draft. Until it becomes officially available you can download a copy from: http://people.nokia.net/~miguel/drafts/draft-garcia-simple-presence-dictionary-02.txt http://people.nokia.net/~miguel/drafts/draft-garcia-simple-presence-dictionary-02.html This version completes the missing presence documents, so it should contain strings from all the known presence standards as for today. Comments are welcomed. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 06 07:09:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOYSt-0000co-Ep; Tue, 06 Mar 2007 07:08:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOYSo-0000Yh-5r for simple@ietf.org; Tue, 06 Mar 2007 07:08:18 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOYKl-0005TF-1A for simple@ietf.org; Tue, 06 Mar 2007 07:00:00 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l26BxIWt027910; Tue, 6 Mar 2007 13:59:52 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 13:59:46 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 13:59:46 +0200 Received: from [172.21.41.168] (esdhcp041168.research.nokia.com [172.21.41.168]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l26BxhkH010575; Tue, 6 Mar 2007 13:59:44 +0200 Message-ID: <45ED57AF.9060608@nokia.com> Date: Tue, 06 Mar 2007 13:59:43 +0200 From: Aki Niemi Organization: Nokia User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Simple] A new draft on using ICE with MSRP References: <45E4B4F0.1080606@nokia.com> <45E7A2A3.7000307@cisco.com> In-Reply-To: <45E7A2A3.7000307@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2007 11:59:46.0057 (UTC) FILETIME=[EF055790:01C75FE6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Jonathan, ext Jonathan Rosenberg wrote: > I think the main thing that needs to be pointed out here is that, with > ICE, you will end up with a separate TCP connection between a particular > relay pair, for each session. Yes, this is perhaps the biggest issue that needs to be clearly spelled out. The ripple effect of it is that you could now drop the To-Path and From-Path from MSRP SENDs, since ICE does connection validation, and strictly e2e streams don't need this embedded routing information either. I understand these may be going too far into redesigning the entire protocol, but certainly topics worth discussing. > One of the initial goals of MRSP relays > was to allow connection reuse between peer networks. This has pros and > cons; the scalability goes down, but now you can do cool stuff like e2e > TLS, and if you combine that with self-signed certs and exchange of > fingerprints you get a nice solution for e2e media encryption. Very true. > Unfortunately I have no doubt that many folks won't want that because of > the need to enforce policies on who can say what to whom, but at least > the capability is there. Right. I also tend to think that some form of logging and/or limited policy enforcement will be possible (i.e., you can cat the stream into a file and store it at the TURN relay), but emphasizing the work "limited" here. > On your open issue regarding framing, I see no problem with using the > framing in RFC4571 with MSRP. I chose it because it will work with > ANYTHING. Correct, it will work, but will also not be strictly needed. My point was that since MSRP does framing just fine, you can already mux MSRP and STUN, right? For other protocols, such as RTP/RTCP or, say, DNS-over-UDP (wha?), RFC4571 is certainly required. > I think it'd be great to work on this further and fully flesh out the > pros/cons, backwards compatibility considerations and so on. Excellent. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 06 08:41:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOZuM-0002EV-3e; Tue, 06 Mar 2007 08:40:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOZuK-0002EP-B3 for simple@ietf.org; Tue, 06 Mar 2007 08:40:48 -0500 Received: from mail-out.sbs.be ([193.109.72.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOZuF-0004dd-EU for simple@ietf.org; Tue, 06 Mar 2007 08:40:48 -0500 Received: from bruc002x.sbs.be (bruc002x.sbs.be [193.210.175.98]) by mail-out.sbs.be (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l26DedtP000487; Tue, 6 Mar 2007 14:40:39 +0100 Received: from bru0032a.ww018.siemens.net (bru0032a.ww018.siemens.net [193.210.175.90]) by bruc002x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l26DeeFr026051; Tue, 6 Mar 2007 14:40:40 +0100 Received: from BRU0038A.ww018.siemens.net ([193.210.175.64]) by bru0032a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 14:40:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Mar 2007 14:40:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Last Call: draft-ietf-simple-presence-rules (Presence Authorization Rules) to Proposed Standard Thread-Index: Acdf9QcFRL67WK99Rv6wdwsus326Yw== From: "Vrancken, Johnny" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 06 Mar 2007 13:40:39.0713 (UTC) FILETIME=[0747F110:01C75FF5] X-Spam-Score: 0.1 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: simple@ietf.org Subject: [Simple] RE: Last Call: draft-ietf-simple-presence-rules (Presence Authorization Rules) to Proposed Standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1770298203==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1770298203== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75FF5.0781B9E1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75FF5.0781B9E1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Jonathan, I'd appreciate your opinion on the following issues: Comment #1: For completeness, it is recommended to add a statement on how to deal = with the child element of a document as defined in RFC = 3863. You may e.g. state that this always is included (if available), = or that it is never included unless a proper permission (e.g. a boolean = valued ) is introduced for controlling the = permission of this specific presence item. The permission = as defined in section 3.3.2.13 only covers the element within a = , or .=20 Comment #2: Extract from = http://www1.ietf.org/mail-archive/web/simple/current/msg07059.html =3D=3D=3DBEGIN=3D=3D=3D =20 > =A73.3 Transformations > Considering the statements in =A73.3.1 and =A73.3.2, you need both a = fine=20 > gained access permission (=A73.3.2) and a corresponding coarse grained = > access permission (=A73.3.1)to grant access to presence attributes. >=20 > So the most compact form of granting access of all presence attributes = > to all watchers is the following rule: > > allow > > > > > > > correct. =3D=3D=3DEND=3D=3D=3D It would be nice to have a more compact way of expressing that access is = granted to all presence attributes in currently defined and new data = components. Data components (like , and ) are = defined as a grouped collection of presence attributes. In the current = solution, you always have to enumerate the coarse grained permission = controls for the data components (i.e. , = , ). In order to deal with the = introduction of new (yet unknown) data components, one could define 2 = new coarse grained permissions * , empty typed, as a short-hand for = referencing all data components, and * , unknownBooleanPermission typed, to = allow to include proprietary or new data components other than , = and .=20 The syntax and the semantics of these new coarse grained permissions are = straightforward. At least the description of the fine grained = permission in section 3.3.2.15 should slightly be adapted, so this fine = grained permission also can be applied to data components other than = , and . The most compact form of granting access of all presence attributes to = all watchers then would look like (assuming that all presence attributes = are grouped into data components): allow This extension -if acknowledged as a meaningful extension- could be = described in a new document but due to its basic nature, I'd prefer to = include it in the simple presence rules document. Kind regards, Johnny Vrancken ------_=_NextPart_001_01C75FF5.0781B9E1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Last Call: draft-ietf-simple-presence-rules (Presence = Authorization Rules) to Proposed Standard

Dear = Jonathan,

I'd appreciate = your opinion on the following issues:

Comment = #1:
For completeness, = it is recommended to add a statement on how to deal with the = <note> child element of a <presence> document as defined in = RFC 3863.

You may e.g. state = that this <note> always is included (if available), or that it is = never included unless a proper permission (e.g. a boolean valued = <provide-presence-note>) is introduced for controlling the = permission of this specific presence item. The <provide-note> = permission as defined in section  3.3.2.13 only covers the = <note> element within a <tuple>, <person> or = <device>.

Comment = #2:
Extract from = http://www1.ietf.org/mail-archive/web/simple/current/msg07= 059.html
=3D=3D=3DBEGIN=3D=3D=3D 
> =A73.3 = Transformations
> = Considering the statements in =A73.3.1 and =A73.3.2, you need both a = fine
> gained = access permission (=A73.3.2) and a corresponding coarse grained =
> access = permission (=A73.3.1)to grant access to presence = attributes.
> =
> So the = most compact form of granting access of all presence attributes =
> to all = watchers is the following rule:
> = <rule id=3D"GrantAll" >
>   <actions> = <sub-handling>allow</sub-handling> = </actions>
>   <transformations>
>     <provide-persons> = <all-persons/> </provide-persons>
>     <provide-services> = <all-services/> </provide-services>
>     <provide-devices> = <all-devices/> </provide-devices>
>     = <provide-all-attributes/>
>   </transformations>
> = </rule>

correct.
=3D=3D=3DEND=3D=3D=3D
It would be nice = to have a more compact way of expressing that access is granted to all = presence attributes in currently defined and new data components. Data = components (like <tuple>, <person> and <device>) are = defined as a grouped collection of presence attributes. In the current = solution, you always have to enumerate the coarse grained permission = controls for the data components (i.e. <provide-persons>, = <provide-services>, <provide-devices>). In order to deal = with the introduction of new (yet unknown) data components, one could = define 2 new coarse grained permissions

  • <provide-all-data-components>, empty typed, as a = short-hand for referencing all data components, and
  • <provide-unknown-data-component>, = unknownBooleanPermission typed, to allow to include proprietary or new = data components other than <tuple>, <person> and = <device>.

The syntax and the = semantics of these new coarse grained permissions are = straightforward.
At least the = description of the <provide-all-attributes> fine grained = permission in section 3.3.2.15 should slightly be adapted, so this fine = grained permission also can be applied to data components other than = <tuple>, <person> and <device>.

The most compact = form of granting access of all presence attributes to all watchers then = would look like (assuming that all presence attributes are grouped into = data components):

 <rule id=3D"GrantAll" >
   <actions> = <sub-handling>allow</sub-handling> = </actions>
   <transformations>
     = <provide-all-data-components/>
     = <provide-all-attributes/>
   </transformations>
 </rule>

This extension = -if acknowledged as a meaningful extension- could be described in a new = document but due to its basic nature, I'd prefer to include it in the = simple presence rules document.


Kind = regards,
Johnny = Vrancken

------_=_NextPart_001_01C75FF5.0781B9E1-- --===============1770298203== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1770298203==-- From simple-bounces@ietf.org Tue Mar 06 14:09:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOf1Y-0001PI-Pu; Tue, 06 Mar 2007 14:08:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOf1X-0001PD-Mj for simple@ietf.org; Tue, 06 Mar 2007 14:08:35 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOf1V-00012w-C4 for simple@ietf.org; Tue, 06 Mar 2007 14:08:35 -0500 Received: from [172.17.1.65] ([172.17.1.65]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l26J8Ud6083436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 6 Mar 2007 13:08:30 -0600 (CST) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: quoted-printable Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed To: simple@ietf.org From: Robert Sparks Date: Tue, 6 Mar 2007 13:08:27 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Simple] Agenda for the SIMPLE meeting in Prague X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Here is the current plan: =E2=96=BC 20m - Administrivia and Planning =E2=80=A2 Chairs =E2=96=BC 20m - Performance and Scaling Analysis =E2=80=A2 Avshalom Houri =E2=80=A2 = draft-ietf-simple-interdomain-scaling-analysis-00.txt =E2=96=BC 30m - Multiparty IM sessions using MSRP =E2=80=A2 Miguel Garcia/Aki Neimi =E2=80=A2 draft-niemi-simple-chat-06.txt =E2=96=BC 5m - Update: XCON IM sessions using MSRP =E2=80=A2 Mary Barnes =E2=80=A2 draft-boulton-xcon-msrp-conferencing-04.txt =E2=96=BC 15m - Deferred Message Disposition Notification =E2=80=A2 Jerry Shih =E2=80=A2 draft-stafford-simple-dmdn-00.txt =E2=96=BC 10m - Establishing MSRP sessions using ICE =E2=80=A2 Aki Neimi =E2=80=A2 draft-niemi-simple-msrp-ice-00.txt =E2=96=BC 10m - Vehicle Information Event Package =E2=80=A2 Henning Schulzrinne =E2=80=A2 draft-singh-simple-vehicle-info-00.txt =E2=96=BC 10m - Sigcomp Presence Dictionary =E2=80=A2 Miguel Garcia =E2=80=A2 draft-garcia-simple-presence-dictionary-02.txt All presenters, particularly for the last 4 items, should be prepared to compress their conversation into shorter time in case the already chartered discussions need to expand. Let me know if I've missed anything. RjS= _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 07 15:31:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP2mE-0005yC-CX; Wed, 07 Mar 2007 15:30:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP2mC-0005ol-Io for simple@ietf.org; Wed, 07 Mar 2007 15:30:20 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP2m9-0007Db-Hl for simple@ietf.org; Wed, 07 Mar 2007 15:30:20 -0500 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l27KsZVp026396; Wed, 7 Mar 2007 14:54:36 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 14:30:06 -0600 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Date: Wed, 7 Mar 2007 15:30:05 -0500 Message-ID: <95D8C1105D54EB41864F8831E6C4EB7502C6BF61@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <45E82E75.4000500@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Thread-Index: Acdc03XFdFmQ7ZF/RxqWPpWPFZpckAEI4eKA From: "Nadia Bishai \(QA/EMC\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 07 Mar 2007 20:30:06.0645 (UTC) FILETIME=[64BA0650:01C760F7] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Actually we use it as a Caller Prefernce in the Accept-Contact header, to indicate to the recipient preferred handling of the request. Nadia=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: March 2, 2007 9:02 AM To: Nadia Bishai (QA/EMC) Cc: Stafford, Matthew; simple@ietf.org Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Nadia Bishai (QA/EMC) wrote: > Hi Matthew >=20 > In OMA we have just accepted a CR to add a feature tag for Large=20 > Message mode. This will make it easier for both the client and the=20 > server to distinguish between different session types. A *feature tag* ??? Do you mean a callee-caps feature tag? Can you explain further how that will be used? Feature tags describe *capabilities* that are supported or desired. They don't specify capabilities that are necessarily being *used*. And they apply to the UA, not to a particular media stream a UA might be using. So, using a feature tag might be fine if it means "I have the capability to support large message mode". But it isn't fine if it is intended to mean "This INVITE is being used to establish a session using Large Message Mode". Paul > Nadia Bishai >=20 > -----Original Message----- > From: Stafford, Matthew [mailto:matthew.stafford@cingular.com] > Sent: March 1, 2007 5:02 PM > To: simple@ietf.org > Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >=20 > Since I've been very slow in answering this, here's an attempted=20 > overview of the discussion to date, followed by a question about where > this leads: >=20 > First of all, I think the telegraphic summary (was it provided by > Miguel?) is pretty good: >> - An MSRP session is intercepted by a store-and-forward server. The=20 >> sender would like to be informed when the final recipient receives or >> reads the message(s). >=20 > I guess it's an open question whether the group is interested in=20 > disposition notification functionality for sessions as a whole. (That=20 > wasn't what we were thinking about when we put together the draft.) >=20 > The main *concern* that came up was: in an interactive session with=20 > numerous messages, you wouldn't want to have sender(s) requesting=20 > disposition notification on a per-message basis. >=20 > That concern led to the idea of: you'd need a way to distinguish=20 > between large message mode and a "true" session based experience.=20 > Jerry Shih's clarification at the time- regarding OMA's large message=20 > mode > definition- was that the large message originator's client would=20 > specify send-only in the SDP session negotiation. So, if the intended=20 > recipient > *did* happen to be online, said recipient would not be able to=20 > misconstrue and jump into a back-and-forth exchange where it too was=20 > asking for disposition notification. So it looks like we've got it=20 > boiled down to a question of the session initiator's behavior. >=20 > My question now: suppose we were to say the originator MUST NOT=20 > incorporate DN requests in multiple MSRP messages in the same session, > and moreover MUST specify send-only if it wants to request DN. (Even=20 > if a single message were chunked into multiple MSRP SENDs, I'm=20 > assuming you wouldn't want to have DN headers in each chunk- I'm=20 > thinking of the DN business as residing at a higher layer.) >=20 > Would this sort of requirements be adequate? Or are we talking instead > about a feature-tag or some other explicit identifier that we are in=20 > large message mode? >=20 > Best, > Matt Stafford >=20 > -----Original Message----- > From: Salvatore Loreto (JO/LMF) [mailto:salvatore.loreto@ericsson.com] > Sent: Monday, February 05, 2007 7:40 AM > To: Miguel Garcia > Cc: Stafford, Matthew; 'simple@ietf.org' > Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >=20 > Hi Miguel, >=20 > see the discussion on line >=20 > br > /sal >=20 >>> On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote: >>>> Hi: >>>> >>>> So, a summary of draft-stafford-simple-dmdn is that there is a use > case >>>> that is not covered by the current IMDN, which is: >>>> >>>> - An MSRP session is intercepted by a store-and-forward server. The >=20 >>>> sender would like to be informed when the final recipient receives > or >>>> reads the message(s). >>>> >>>> One first question about the use case. It appears form the text in > the >>>> draft that the use case applies only to large messages. However, I > can >>>> envision store-and-forward servers that store a complete MSRP > session >>>> (not only ONE large message). >>> you are right, if you have a store-and-forward in the path this is a >=20 >>> possible scenario, even if I can not imagine at present a specific > use >>> case. (e.g. Why someone would establish a MSRP session with an > off-line >>> user and start to chat with him?) >> >> Well, look at commercial systems. They do it. I can do it. I actually > do >> it... I establish a session with some offline friend to send a few=20 >> messages, or pending items, such as my latest pictures. This is a=20 >> real >=20 >> use case. >=20 > Yes I am aware that some IM programs behave in this way. > What I don't see is the necessity to have or provide a delivery=20 > notification in this scenario, and in fact they don't do. > But I understand and fully agree with your concern about adding some=20 > header for Deliver Notification in the CPIM headers of each MSRP SEND=20 > request. >=20 >> >>>> I think it is important to consider these collections of MSRP > messages, >>>> because, imagine we add something to the CPIM headers of each MSRP > SEND >>>> requesting delivery disposition notification, then the sender will=20 >>>> receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND=20 >>>> request. I guess this is not reasonable. >>> I agree.=20 >>> A solution could be that the store-and-forward server collect all > the >>> message in one single big message, but in this case it shouldn't be > any >>> more a simple store-and-forward. >> Certainly that is one possibility. Another one is to promote the IMDN >> request to the INVITE, and provide a "session-level" IMDN. >=20 > yes, promoting the IMDN request to the INVITE could work in both the > scenario: the only one large message and several short/normal messages. > It can say to the final recipient to send an IMDN to the original=20 > sender when as soon as he has received the whole large message or all=20 > the short messages. For example as soon the store and forward server=20 > close the MSRP session. > But promoting the IMDN request to the INVITE levels means we have also > put at this level same information about the original sender. what do=20 > you think about? >=20 >=20 >=20 >> In any case, I think these should be dependent on the presence of a=20 >> store-and-forward server in the path. >> >> >> >> /Miguel >> >> >>>> On the other hand, if there isn't a store-and-forward server in the >=20 >>>> path, then there is no need for the sender to receive additional=20 >>>> notifications, because the success reports in MSRP will do the job. >>>> >>>> So, I guess where we are going is to get some sort of conditional > IMDN >>>> for MSRP. The condition being the unavailability of the recipient > to get >>>> the messages and a store-and-forward server storing them. This will >=20 >>>> obviously apply to either large messages or short ones. >>> I don't have a clear view on this, >>> but maybe if we introduce a indication that an MRSP session is=20 >>> established for just sending one message, this indication could > help. >>> >>>> Any views on this? >>>> >>>> BR, >>>> >>>> Miguel >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 07 18:09:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5FV-0001A1-UW; Wed, 07 Mar 2007 18:08:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5FU-00017h-Pv for simple@ietf.org; Wed, 07 Mar 2007 18:08:44 -0500 Received: from c243-111.rim.net ([216.9.243.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP5FT-0004sP-4Y for simple@ietf.org; Wed, 07 Mar 2007 18:08:44 -0500 Received: from ngw01ykf.rim.net ([10.102.108.30]) by c243-111.rim.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 18:08:28 -0500 Importance: normal Received: from XCH20YKF.rim.net ([10.102.100.35]) by ngw01ykf.rim.net (SAVSMTP 3.1.6.45) with SMTP id M2007030718082710157 ; Wed, 07 Mar 2007 18:08:27 -0500 Priority: normal Received: from XCH47YKF.rim.net ([10.64.31.217]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Mar 2007 18:08:28 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Date: Wed, 7 Mar 2007 18:08:27 -0500 Message-ID: <61968779B8AC4C4BAB421D4C12F008C0070CF553@XCH47YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Comments to draft-stafford-simple-dmdn-00.txt thread-index: Acdc03XFdFmQ7ZF/RxqWPpWPFZpckAEI4eKAAAL933kAAf1joAAAplsS From: "Andrew Allen" To: , X-OriginalArrivalTime: 07 Mar 2007 23:08:28.0201 (UTC) FILETIME=[84186990:01C7610D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Nadia So is the feature tag +g.oma.sip-im is used as a service identifier = then? Andrew -------------------------- Andrew Allen Manager Standards Research In Motion Ltd BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ Sent from my BlackBerry Wireless Handheld ----- Original Message ----- From: Nadia Bishai (QA/EMC) To: Andrew Allen; pkyzivat@cisco.com Cc: simple@ietf.org Sent: Wed Mar 07 18:01:12 2007 Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Hi Andrew,=20 Please see answers below=20 Nadia=20 -----Original Message-----=20 From: Andrew Allen [mailto:aallen@rim.com ]=20 Sent: March 7, 2007 4:53 PM=20 To: Nadia Bishai (QA/EMC); pkyzivat@cisco.com=20 Cc: simple@ietf.org=20 Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt=20 Nadia=20 Is this feature tag being used as a service identifier?=20 Nadia: Not in the sense of a communication service identifier used by = 3GPP. But as an indication of desired treatment by the recipient. Does this feature tag also trigger routing to IM servers based on filter = criteria?=20 Nadia: No. Routing is based on other iFCs, namely the +g.oma.sip-im = and/or the Request Type.=20 Do SIP requests for MSRP sessions get rejected if the tag doesn't appear = in Accept-Contact?=20 Nadia: No=20 Is the tag used for charging and authorisation purpose?=20 Nadia: No=20 Andrew=20 --------------------------=20 Andrew Allen=20 Manager Standards=20 Research In Motion Ltd=20 BlackBerry Mobile +1 847 809 8636=20 http://www.rim.com/ =20 Sent from my BlackBerry Wireless Handheld=20 ----- Original Message -----=20 From: Nadia Bishai (QA/EMC) =20 To: Paul Kyzivat =20 Cc: simple@ietf.org =20 Sent: Wed Mar 07 15:30:05 2007=20 Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt=20 Hi=20 Actually we use it as a Caller Prefernce in the Accept-Contact header, = to indicate to the recipient preferred handling of the request. Nadia=20 -----Original Message-----=20 From: Paul Kyzivat [mailto:pkyzivat@cisco.com = ]=20 Sent: March 2, 2007 9:02 AM=20 To: Nadia Bishai (QA/EMC)=20 Cc: Stafford, Matthew; simple@ietf.org=20 Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt=20 Nadia Bishai (QA/EMC) wrote:=20 > Hi Matthew=20 >=20 > In OMA we have just accepted a CR to add a feature tag for Large=20 > Message mode. This will make it easier for both the client and the=20 > server to distinguish between different session types.=20 A *feature tag* ???=20 Do you mean a callee-caps feature tag? Can you explain further how that=20 will be used?=20 Feature tags describe *capabilities* that are supported or desired. They = don't specify capabilities that are necessarily being *used*. And they=20 apply to the UA, not to a particular media stream a UA might be using.=20 So, using a feature tag might be fine if it means "I have the capability = to support large message mode". But it isn't fine if it is intended to=20 mean "This INVITE is being used to establish a session using Large=20 Message Mode".=20 Paul=20 > Nadia Bishai=20 >=20 > -----Original Message-----=20 > From: Stafford, Matthew [mailto:matthew.stafford@cingular.com = ]=20 > Sent: March 1, 2007 5:02 PM=20 > To: simple@ietf.org=20 > Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt=20 >=20 > Since I've been very slow in answering this, here's an attempted=20 > overview of the discussion to date, followed by a question about where = > this leads:=20 >=20 > First of all, I think the telegraphic summary (was it provided by=20 > Miguel?) is pretty good:=20 >> - An MSRP session is intercepted by a store-and-forward server. The=20 >> sender would like to be informed when the final recipient receives or = >> reads the message(s).=20 >=20 > I guess it's an open question whether the group is interested in=20 > disposition notification functionality for sessions as a whole. (That=20 > wasn't what we were thinking about when we put together the draft.)=20 >=20 > The main *concern* that came up was: in an interactive session with=20 > numerous messages, you wouldn't want to have sender(s) requesting=20 > disposition notification on a per-message basis.=20 >=20 > That concern led to the idea of: you'd need a way to distinguish=20 > between large message mode and a "true" session based experience.=20 > Jerry Shih's clarification at the time- regarding OMA's large message=20 > mode=20 > definition- was that the large message originator's client would=20 > specify send-only in the SDP session negotiation. So, if the intended=20 > recipient=20 > *did* happen to be online, said recipient would not be able to=20 > misconstrue and jump into a back-and-forth exchange where it too was=20 > asking for disposition notification. So it looks like we've got it=20 > boiled down to a question of the session initiator's behavior.=20 >=20 > My question now: suppose we were to say the originator MUST NOT=20 > incorporate DN requests in multiple MSRP messages in the same session, = > and moreover MUST specify send-only if it wants to request DN. (Even=20 > if a single message were chunked into multiple MSRP SENDs, I'm=20 > assuming you wouldn't want to have DN headers in each chunk- I'm=20 > thinking of the DN business as residing at a higher layer.)=20 >=20 > Would this sort of requirements be adequate? Or are we talking instead = > about a feature-tag or some other explicit identifier that we are in=20 > large message mode?=20 >=20 > Best,=20 > Matt Stafford=20 >=20 > -----Original Message-----=20 > From: Salvatore Loreto (JO/LMF) [mailto:salvatore.loreto@ericsson.com = ]=20 > Sent: Monday, February 05, 2007 7:40 AM=20 > To: Miguel Garcia=20 > Cc: Stafford, Matthew; 'simple@ietf.org'=20 > Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt=20 >=20 > Hi Miguel,=20 >=20 > see the discussion on line=20 >=20 > br=20 > /sal=20 >=20 >>> On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote:=20 >>>> Hi:=20 >>>>=20 >>>> So, a summary of draft-stafford-simple-dmdn is that there is a use = > case=20 >>>> that is not covered by the current IMDN, which is:=20 >>>>=20 >>>> - An MSRP session is intercepted by a store-and-forward server. The = >=20 >>>> sender would like to be informed when the final recipient receives=20 > or=20 >>>> reads the message(s).=20 >>>>=20 >>>> One first question about the use case. It appears form the text in=20 > the=20 >>>> draft that the use case applies only to large messages. However, I=20 > can=20 >>>> envision store-and-forward servers that store a complete MSRP=20 > session=20 >>>> (not only ONE large message).=20 >>> you are right, if you have a store-and-forward in the path this is a = >=20 >>> possible scenario, even if I can not imagine at present a specific=20 > use=20 >>> case. (e.g. Why someone would establish a MSRP session with an=20 > off-line=20 >>> user and start to chat with him?)=20 >>=20 >> Well, look at commercial systems. They do it. I can do it. I actually = > do=20 >> it... I establish a session with some offline friend to send a few=20 >> messages, or pending items, such as my latest pictures. This is a=20 >> real=20 >=20 >> use case.=20 >=20 > Yes I am aware that some IM programs behave in this way.=20 > What I don't see is the necessity to have or provide a delivery=20 > notification in this scenario, and in fact they don't do.=20 > But I understand and fully agree with your concern about adding some=20 > header for Deliver Notification in the CPIM headers of each MSRP SEND=20 > request.=20 >=20 >>=20 >>>> I think it is important to consider these collections of MSRP=20 > messages,=20 >>>> because, imagine we add something to the CPIM headers of each MSRP=20 > SEND=20 >>>> requesting delivery disposition notification, then the sender will=20 >>>> receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND=20 >>>> request. I guess this is not reasonable.=20 >>> I agree.=20 >>> A solution could be that the store-and-forward server collect all=20 > the=20 >>> message in one single big message, but in this case it shouldn't be=20 > any=20 >>> more a simple store-and-forward.=20 >> Certainly that is one possibility. Another one is to promote the IMDN = >> request to the INVITE, and provide a "session-level" IMDN.=20 >=20 > yes, promoting the IMDN request to the INVITE could work in both the=20 > scenario: the only one large message and several short/normal=20 messages.=20 > It can say to the final recipient to send an IMDN to the original=20 > sender when as soon as he has received the whole large message or all=20 > the short messages. For example as soon the store and forward server=20 > close the MSRP session.=20 > But promoting the IMDN request to the INVITE levels means we have also = > put at this level same information about the original sender. what do=20 > you think about?=20 >=20 >=20 >=20 >> In any case, I think these should be dependent on the presence of a=20 >> store-and-forward server in the path.=20 >>=20 >>=20 >>=20 >> /Miguel=20 >>=20 >>=20 >>>> On the other hand, if there isn't a store-and-forward server in the = >=20 >>>> path, then there is no need for the sender to receive additional=20 >>>> notifications, because the success reports in MSRP will do the job. = >>>>=20 >>>> So, I guess where we are going is to get some sort of conditional=20 > IMDN=20 >>>> for MSRP. The condition being the unavailability of the recipient=20 > to get=20 >>>> the messages and a store-and-forward server storing them. This will = >=20 >>>> obviously apply to either large messages or short ones.=20 >>> I don't have a clear view on this,=20 >>> but maybe if we introduce a indication that an MRSP session is=20 >>> established for just sending one message, this indication could=20 > help.=20 >>>=20 >>>> Any views on this?=20 >>>>=20 >>>> BR,=20 >>>>=20 >>>> Miguel=20 >=20 >=20 > _______________________________________________=20 > Simple mailing list=20 > Simple@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/simple = =20 >=20 > _______________________________________________=20 > Simple mailing list=20 > Simple@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/simple = =20 >=20 _______________________________________________=20 Simple mailing list=20 Simple@ietf.org=20 https://www1.ietf.org/mailman/listinfo/simple = =20 ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client 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 immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client 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 immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 07 18:17:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5Nt-00047m-05; Wed, 07 Mar 2007 18:17:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP52z-0006Nn-QH for simple@ietf.org; Wed, 07 Mar 2007 17:55:49 -0500 Received: from c243-111.rim.net ([216.9.243.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP44K-00029Z-1P for simple@ietf.org; Wed, 07 Mar 2007 16:53:11 -0500 Received: from ngw02ykf.rim.net ([10.102.108.31]) by c243-111.rim.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 16:52:53 -0500 Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw02ykf.rim.net (SAVSMTP 3.1.6.45) with SMTP id M2007030716525306205 ; Wed, 07 Mar 2007 16:52:53 -0500 Importance: normal Priority: normal Received: from XCH47YKF.rim.net ([10.64.31.217]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Mar 2007 16:52:53 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Date: Wed, 7 Mar 2007 16:52:52 -0500 Message-ID: <61968779B8AC4C4BAB421D4C12F008C0070CF551@XCH47YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Comments to draft-stafford-simple-dmdn-00.txt thread-index: Acdc03XFdFmQ7ZF/RxqWPpWPFZpckAEI4eKAAAL933k= From: "Andrew Allen" To: , X-OriginalArrivalTime: 07 Mar 2007 21:52:53.0491 (UTC) FILETIME=[F5329430:01C76102] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Nadia Is this feature tag being used as a service identifier?=20 Does this feature tag also trigger routing to IM servers based on filter = criteria? Do SIP requests for MSRP sessions get rejected if the tag doesn't appear = in Accept-Contact? Is the tag used for charging and authorisation purpose? Andrew -------------------------- Andrew Allen Manager Standards Research In Motion Ltd BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ Sent from my BlackBerry Wireless Handheld ----- Original Message ----- From: Nadia Bishai (QA/EMC) To: Paul Kyzivat Cc: simple@ietf.org Sent: Wed Mar 07 15:30:05 2007 Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Hi Actually we use it as a Caller Prefernce in the Accept-Contact header, to indicate to the recipient preferred handling of the request. Nadia=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: March 2, 2007 9:02 AM To: Nadia Bishai (QA/EMC) Cc: Stafford, Matthew; simple@ietf.org Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Nadia Bishai (QA/EMC) wrote: > Hi Matthew >=20 > In OMA we have just accepted a CR to add a feature tag for Large=20 > Message mode. This will make it easier for both the client and the=20 > server to distinguish between different session types. A *feature tag* ??? Do you mean a callee-caps feature tag? Can you explain further how that will be used? Feature tags describe *capabilities* that are supported or desired. They don't specify capabilities that are necessarily being *used*. And they apply to the UA, not to a particular media stream a UA might be using. So, using a feature tag might be fine if it means "I have the capability to support large message mode". But it isn't fine if it is intended to mean "This INVITE is being used to establish a session using Large Message Mode". Paul > Nadia Bishai >=20 > -----Original Message----- > From: Stafford, Matthew [mailto:matthew.stafford@cingular.com] > Sent: March 1, 2007 5:02 PM > To: simple@ietf.org > Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >=20 > Since I've been very slow in answering this, here's an attempted=20 > overview of the discussion to date, followed by a question about where > this leads: >=20 > First of all, I think the telegraphic summary (was it provided by > Miguel?) is pretty good: >> - An MSRP session is intercepted by a store-and-forward server. The=20 >> sender would like to be informed when the final recipient receives or >> reads the message(s). >=20 > I guess it's an open question whether the group is interested in=20 > disposition notification functionality for sessions as a whole. (That=20 > wasn't what we were thinking about when we put together the draft.) >=20 > The main *concern* that came up was: in an interactive session with=20 > numerous messages, you wouldn't want to have sender(s) requesting=20 > disposition notification on a per-message basis. >=20 > That concern led to the idea of: you'd need a way to distinguish=20 > between large message mode and a "true" session based experience.=20 > Jerry Shih's clarification at the time- regarding OMA's large message=20 > mode > definition- was that the large message originator's client would=20 > specify send-only in the SDP session negotiation. So, if the intended=20 > recipient > *did* happen to be online, said recipient would not be able to=20 > misconstrue and jump into a back-and-forth exchange where it too was=20 > asking for disposition notification. So it looks like we've got it=20 > boiled down to a question of the session initiator's behavior. >=20 > My question now: suppose we were to say the originator MUST NOT=20 > incorporate DN requests in multiple MSRP messages in the same session, > and moreover MUST specify send-only if it wants to request DN. (Even=20 > if a single message were chunked into multiple MSRP SENDs, I'm=20 > assuming you wouldn't want to have DN headers in each chunk- I'm=20 > thinking of the DN business as residing at a higher layer.) >=20 > Would this sort of requirements be adequate? Or are we talking instead > about a feature-tag or some other explicit identifier that we are in=20 > large message mode? >=20 > Best, > Matt Stafford >=20 > -----Original Message----- > From: Salvatore Loreto (JO/LMF) [mailto:salvatore.loreto@ericsson.com] > Sent: Monday, February 05, 2007 7:40 AM > To: Miguel Garcia > Cc: Stafford, Matthew; 'simple@ietf.org' > Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >=20 > Hi Miguel, >=20 > see the discussion on line >=20 > br > /sal >=20 >>> On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote: >>>> Hi: >>>> >>>> So, a summary of draft-stafford-simple-dmdn is that there is a use > case >>>> that is not covered by the current IMDN, which is: >>>> >>>> - An MSRP session is intercepted by a store-and-forward server. The >=20 >>>> sender would like to be informed when the final recipient receives > or >>>> reads the message(s). >>>> >>>> One first question about the use case. It appears form the text in > the >>>> draft that the use case applies only to large messages. However, I > can >>>> envision store-and-forward servers that store a complete MSRP > session >>>> (not only ONE large message). >>> you are right, if you have a store-and-forward in the path this is a >=20 >>> possible scenario, even if I can not imagine at present a specific > use >>> case. (e.g. Why someone would establish a MSRP session with an > off-line >>> user and start to chat with him?) >> >> Well, look at commercial systems. They do it. I can do it. I actually > do >> it... I establish a session with some offline friend to send a few=20 >> messages, or pending items, such as my latest pictures. This is a=20 >> real >=20 >> use case. >=20 > Yes I am aware that some IM programs behave in this way. > What I don't see is the necessity to have or provide a delivery=20 > notification in this scenario, and in fact they don't do. > But I understand and fully agree with your concern about adding some=20 > header for Deliver Notification in the CPIM headers of each MSRP SEND=20 > request. >=20 >> >>>> I think it is important to consider these collections of MSRP > messages, >>>> because, imagine we add something to the CPIM headers of each MSRP > SEND >>>> requesting delivery disposition notification, then the sender will=20 >>>> receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND=20 >>>> request. I guess this is not reasonable. >>> I agree.=20 >>> A solution could be that the store-and-forward server collect all > the >>> message in one single big message, but in this case it shouldn't be > any >>> more a simple store-and-forward. >> Certainly that is one possibility. Another one is to promote the IMDN >> request to the INVITE, and provide a "session-level" IMDN. >=20 > yes, promoting the IMDN request to the INVITE could work in both the > scenario: the only one large message and several short/normal messages. > It can say to the final recipient to send an IMDN to the original=20 > sender when as soon as he has received the whole large message or all=20 > the short messages. For example as soon the store and forward server=20 > close the MSRP session. > But promoting the IMDN request to the INVITE levels means we have also > put at this level same information about the original sender. what do=20 > you think about? >=20 >=20 >=20 >> In any case, I think these should be dependent on the presence of a=20 >> store-and-forward server in the path. >> >> >> >> /Miguel >> >> >>>> On the other hand, if there isn't a store-and-forward server in the >=20 >>>> path, then there is no need for the sender to receive additional=20 >>>> notifications, because the success reports in MSRP will do the job. >>>> >>>> So, I guess where we are going is to get some sort of conditional > IMDN >>>> for MSRP. The condition being the unavailability of the recipient > to get >>>> the messages and a store-and-forward server storing them. This will >=20 >>>> obviously apply to either large messages or short ones. >>> I don't have a clear view on this, >>> but maybe if we introduce a indication that an MRSP session is=20 >>> established for just sending one message, this indication could > help. >>> >>>> Any views on this? >>>> >>>> BR, >>>> >>>> Miguel >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client 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 immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 08 07:00:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPHHE-0008SU-CQ; Thu, 08 Mar 2007 06:59:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPHHC-0008Rg-Rk for simple@ietf.org; Thu, 08 Mar 2007 06:59:18 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPHH0-0001Ln-US for simple@ietf.org; Thu, 08 Mar 2007 06:59:18 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 22A06207EA; Thu, 8 Mar 2007 12:58:56 +0100 (CET) X-AuditID: c1b4fb3c-a94ecbb0000073d5-56-45effa80920c Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0F25920B67; Thu, 8 Mar 2007 12:58:56 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 12:58:55 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 12:58:55 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3311F2370; Thu, 8 Mar 2007 13:58:55 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E380A4DBEA; Thu, 8 Mar 2007 13:58:54 +0200 (EET) Received: from localhost.localdomain (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8651B4DBD8; Thu, 8 Mar 2007 13:58:54 +0200 (EET) Subject: Re: [Simple] MSRP chat version -06 From: "Salvatore Loreto (JO/LMF)" To: Miguel Garcia In-Reply-To: <45ED12B7.8080703@nokia.com> References: <45ED12B7.8080703@nokia.com> Content-Type: text/plain Date: Thu, 08 Mar 2007 13:59:46 +0200 Message-Id: <1173355186.3465.72.camel@n95.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 08 Mar 2007 11:58:55.0428 (UTC) FILETIME=[25AB7840:01C76179] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "'simple@ietf.org'" , Niemi Aki X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, some comments on the draft: REQ-9 states that "it must be possible that a participant is only known by their nick name and not their real identity to the rest of the conference". Maybe I din't understand well the mechanism, but because the nickname is set by NICKNAME MSRP method, even if it is reserved as soon an user joins the chat room, prior to send any message, there is no way to prevent the SIP conference event package to send out the real identity information before the NICKNAME has been set. So for me the Req-9 seems not to be fulfilled. Another comment is about the second last paragraph in the section 6.1. It seems MUST contain a Proposed-Nickname in anyway, even if in the Set-Nickname there is a valid nickname. Can you clarify this point? thanks a lot Sal On Tue, 2007-03-06 at 09:05 +0200, Miguel Garcia wrote: > Yesterday we submitted version -06 of the MSRP chat draft. It may take a > few hours/days until it is officially available. In the meantime, you > can get a copy from: > > http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-06.txt > http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-06.html > > This version tries to put a scope on the draft to solve only two issues: > nicknames and private messaging. We added a bunch of examples as well, > so hopefully this will increase readability. > > Comments, as usually, are welcomed. > > /Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 08 07:47:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPI1d-0001Uo-55; Thu, 08 Mar 2007 07:47:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPI1c-0001Ue-4E for simple@ietf.org; Thu, 08 Mar 2007 07:47:16 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPI1Y-0000X2-JQ for simple@ietf.org; Thu, 08 Mar 2007 07:47:16 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l28Cl0oU029432; Thu, 8 Mar 2007 14:47:07 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 14:46:46 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 14:46:46 +0200 Received: from [172.21.58.61] ([172.21.58.61]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 14:46:46 +0200 Message-ID: <45F005B8.2090904@nokia.com> Date: Thu, 08 Mar 2007 14:46:48 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Salvatore Loreto (JO/LMF)" Subject: Re: [Simple] MSRP chat version -06 References: <45ED12B7.8080703@nokia.com> <1173355186.3465.72.camel@n95.nomadiclab.com> In-Reply-To: <1173355186.3465.72.camel@n95.nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2007 12:46:46.0128 (UTC) FILETIME=[D4BD8700:01C7617F] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070308144707-71429BB0-1E81131F/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: "'simple@ietf.org'" , Niemi Aki X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Sal: Thanks for your comments. Let's discuss inline. Salvatore Loreto (JO/LMF) wrote: > Hi, > > some comments on the draft: > > REQ-9 states that "it must be possible that a participant is only known > by their nick name and not their real identity to the rest of the > conference". > Maybe I din't understand well the mechanism, but because the nickname is > set by NICKNAME MSRP method, even if it is reserved as soon an user > joins the chat room, prior to send any message, there is no way to > prevent the SIP conference event package to send out the real identity > information before the NICKNAME has been set. > So for me the Req-9 seems not to be fulfilled. There are several issues here: 1) A participant wants to remain anonymous to the rest of the participants in the conference. The solution for that is indicated in RFC 4575 (Conference Event Package), Section 5.6. To cut a long story short: the participant chooses an anonymous From header and an appropriate level of anonymity in the Privacy header. With this, the focus will not disclose his URI to other participants through the conference event package. 2) How to setup a nickname? Using the NICKNAME method. The conference server could, afterwards, send an update to the conference event package indicating the nickname of this user. Other participants will know this user by his nickname, not by his real URI. So, to me Req-9 is fulfilled. > > > Another comment is about the second last paragraph in the section 6.1. > It seems MUST contain a Proposed-Nickname in anyway, even if in the > Set-Nickname there is a valid nickname. > Can you clarify this point? I guess you are pointing a problem with this sentence: "Set-Nickname header field MUST only be included in a NICKNAME request." I think the above text is not correct. The Set-Nickname header may include one *or more* nickname proposals. So, the 200 OK response needs to include another Set-Nickname header that contains the selected nickname, otherwise the participant won't know which nickname has been chosen by the MSRP switch. Fortunately the example in Section 9.2, in particular flow F4, seems to be correct. I will fix that text in the next version. Thanks, Miguel > > thanks a lot > Sal > > > > On Tue, 2007-03-06 at 09:05 +0200, Miguel Garcia wrote: >> Yesterday we submitted version -06 of the MSRP chat draft. It may take a >> few hours/days until it is officially available. In the meantime, you >> can get a copy from: >> >> http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-06.txt >> http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-06.html >> >> This version tries to put a scope on the draft to solve only two issues: >> nicknames and private messaging. We added a bunch of examples as well, >> so hopefully this will increase readability. >> >> Comments, as usually, are welcomed. >> >> /Miguel > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 08 08:38:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPIoG-00083e-E0; Thu, 08 Mar 2007 08:37:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPIoF-00083Z-OC for simple@ietf.org; Thu, 08 Mar 2007 08:37:31 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPIoE-0006gC-9f for simple@ietf.org; Thu, 08 Mar 2007 08:37:31 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l28Daxgs030127; Thu, 8 Mar 2007 15:37:28 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 15:37:18 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 15:37:14 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l28DbDbe017425; Thu, 8 Mar 2007 15:37:13 +0200 Received: from [172.21.43.170] (esdhcp043170.research.nokia.com [172.21.43.170]) by kusti.research.nokia.com (Postfix) with ESMTP id 37C8293B77; Thu, 8 Mar 2007 15:37:13 +0200 (EET) Message-ID: <45F0105E.7040605@nokia.com> Date: Thu, 08 Mar 2007 15:32:14 +0200 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: WebDAV , simple@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2007 13:37:14.0574 (UTC) FILETIME=[E1D5B6E0:01C76186] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070308153728-7533DBB0-40079741/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [Simple] xcap co-operation with dav X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org hi ! Sorry for cross-posting. I've updated the i-d: which describes some conventions for XCAP usage with WebDAV. Any comments ? thanks, jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 08 09:06:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJFT-0000iZ-NA; Thu, 08 Mar 2007 09:05:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJFR-0000bm-SV for simple@ietf.org; Thu, 08 Mar 2007 09:05:37 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPJFP-0001u6-3u for simple@ietf.org; Thu, 08 Mar 2007 09:05:37 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2007 06:05:32 -0800 X-IronPort-AV: i="4.14,264,1170662400"; d="scan'208"; a="46575649:sNHT128873133" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l28E5WsL028082; Thu, 8 Mar 2007 06:05:32 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l28E5Hxh029357; Thu, 8 Mar 2007 14:05:32 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.1830); Thu, 8 Mar 2007 09:05:22 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 09:05:22 -0500 Message-ID: <45F01821.6020002@cisco.com> Date: Thu, 08 Mar 2007 09:05:21 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Nadia Bishai (QA/EMC)" Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt References: <95D8C1105D54EB41864F8831E6C4EB7502C6C089@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <95D8C1105D54EB41864F8831E6C4EB7502C6C089@ecamlmw720.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2007 14:05:22.0404 (UTC) FILETIME=[CFDC2240:01C7618A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10660; t=1173362732; x=1174226732; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20Comments=20to=20draft-stafford-simple-dmdn -00.txt |Sender:=20; bh=rUscfjfZgRg1Vnv2lQZT2GOC35Dvoq5WcFLZuIJY7FQ=; b=XJI1V8viVo0sKB52N5uDEru5H4kTHcCJvQu2kF0MqmDGBFoZWwxDJkMJ3DzDwYR8rxcOXy9J 5pCyMiHiOaGwLwOOchhrRC79ObY1N5VtJARidemK7x3+eBlrwKg1rmR8; Authentication-Results: sj-dkim-5; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: Andrew Allen , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Nadia Bishai (QA/EMC) wrote: > Hi Andrew, > > Please see answers below [snip] > Is this feature tag being used as a service identifier? > Nadia: Not in the sense of a communication service identifier used by > 3GPP. But as an indication of desired treatment by the recipient. > > Does this feature tag also trigger routing to IM servers based on filter > criteria? > Nadia: No. Routing is based on other iFCs, namely the +g.oma.sip-im > and/or the Request Type. > > Do SIP requests for MSRP sessions get rejected if the tag doesn't appear > in Accept-Contact? > > Nadia: No > Is the tag used for charging and authorisation purpose? > > Nadia: No I'm glad to see the answers above, except for one. Is the iFC matching on +g.oma.sip-im done when it is present in an Accept-Contact header? Or as a capability in a Contact header? If in Accept-Contact, can you explain in detail how that will be done so that it doesn't make an incorrect decision when Accept-Contact and Reject-Contact are used in complex ways? Thanks, Paul > ----- Original Message ----- > From: Nadia Bishai (QA/EMC) > To: Paul Kyzivat > Cc: simple@ietf.org > Sent: Wed Mar 07 15:30:05 2007 > Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt > > Hi > > Actually we use it as a Caller Prefernce in the Accept-Contact header, > to indicate to the recipient preferred handling of the request. > > Nadia > > -----Original Message----- > From: Paul Kyzivat [_mailto:pkyzivat@cisco.com_] > Sent: March 2, 2007 9:02 AM > To: Nadia Bishai (QA/EMC) > Cc: Stafford, Matthew; simple@ietf.org > Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt > > > > Nadia Bishai (QA/EMC) wrote: >> Hi Matthew >> >> In OMA we have just accepted a CR to add a feature tag for Large >> Message mode. This will make it easier for both the client and the >> server to distinguish between different session types. > > A *feature tag* ??? > > Do you mean a callee-caps feature tag? Can you explain further how that > will be used? > > Feature tags describe *capabilities* that are supported or desired. They > don't specify capabilities that are necessarily being *used*. And they > apply to the UA, not to a particular media stream a UA might be using. > > So, using a feature tag might be fine if it means "I have the capability > to support large message mode". But it isn't fine if it is intended to > mean "This INVITE is being used to establish a session using Large > Message Mode". > > Paul > >> Nadia Bishai >> >> -----Original Message----- >> From: Stafford, Matthew [_mailto:matthew.stafford@cingular.com_] >> Sent: March 1, 2007 5:02 PM >> To: simple@ietf.org >> Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >> >> Since I've been very slow in answering this, here's an attempted >> overview of the discussion to date, followed by a question about where > >> this leads: >> >> First of all, I think the telegraphic summary (was it provided by >> Miguel?) is pretty good: >> > - An MSRP session is intercepted by a store-and-forward server. The >> > sender would like to be informed when the final recipient receives or > >> > reads the message(s). >> >> I guess it's an open question whether the group is interested in >> disposition notification functionality for sessions as a whole. (That >> wasn't what we were thinking about when we put together the draft.) >> >> The main *concern* that came up was: in an interactive session with >> numerous messages, you wouldn't want to have sender(s) requesting >> disposition notification on a per-message basis. >> >> That concern led to the idea of: you'd need a way to distinguish >> between large message mode and a "true" session based experience. >> Jerry Shih's clarification at the time- regarding OMA's large message >> mode >> definition- was that the large message originator's client would >> specify send-only in the SDP session negotiation. So, if the intended >> recipient >> *did* happen to be online, said recipient would not be able to >> misconstrue and jump into a back-and-forth exchange where it too was >> asking for disposition notification. So it looks like we've got it >> boiled down to a question of the session initiator's behavior. >> >> My question now: suppose we were to say the originator MUST NOT >> incorporate DN requests in multiple MSRP messages in the same session, > >> and moreover MUST specify send-only if it wants to request DN. (Even >> if a single message were chunked into multiple MSRP SENDs, I'm >> assuming you wouldn't want to have DN headers in each chunk- I'm >> thinking of the DN business as residing at a higher layer.) >> >> Would this sort of requirements be adequate? Or are we talking instead > >> about a feature-tag or some other explicit identifier that we are in >> large message mode? >> >> Best, >> Matt Stafford >> >> -----Original Message----- >> From: Salvatore Loreto (JO/LMF) [_mailto:salvatore.loreto@ericsson.com_] >> Sent: Monday, February 05, 2007 7:40 AM >> To: Miguel Garcia >> Cc: Stafford, Matthew; 'simple@ietf.org' >> Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >> >> Hi Miguel, >> >> see the discussion on line >> >> br >> /sal >> >> >> On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote: >> >>> Hi: >> >>> >> >>> So, a summary of draft-stafford-simple-dmdn is that there is a use >> case >> >>> that is not covered by the current IMDN, which is: >> >>> >> >>> - An MSRP session is intercepted by a store-and-forward server. The >> >> >>> sender would like to be informed when the final recipient receives >> or >> >>> reads the message(s). >> >>> >> >>> One first question about the use case. It appears form the text in >> the >> >>> draft that the use case applies only to large messages. However, I >> can >> >>> envision store-and-forward servers that store a complete MSRP >> session >> >>> (not only ONE large message). >> >> you are right, if you have a store-and-forward in the path this is a >> >> >> possible scenario, even if I can not imagine at present a specific >> use >> >> case. (e.g. Why someone would establish a MSRP session with an >> off-line >> >> user and start to chat with him?) >> > >> > Well, look at commercial systems. They do it. I can do it. I actually >> do >> > it... I establish a session with some offline friend to send a few >> > messages, or pending items, such as my latest pictures. This is a >> > real >> >> > use case. >> >> Yes I am aware that some IM programs behave in this way. >> What I don't see is the necessity to have or provide a delivery >> notification in this scenario, and in fact they don't do. >> But I understand and fully agree with your concern about adding some >> header for Deliver Notification in the CPIM headers of each MSRP SEND >> request. >> >> > >> >>> I think it is important to consider these collections of MSRP >> messages, >> >>> because, imagine we add something to the CPIM headers of each MSRP >> SEND >> >>> requesting delivery disposition notification, then the sender will >> >>> receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND >> >>> request. I guess this is not reasonable. >> >> I agree. >> >> A solution could be that the store-and-forward server collect all >> the >> >> message in one single big message, but in this case it shouldn't be >> any >> >> more a simple store-and-forward. >> > Certainly that is one possibility. Another one is to promote the IMDN > >> > request to the INVITE, and provide a "session-level" IMDN. >> >> yes, promoting the IMDN request to the INVITE could work in both the >> scenario: the only one large message and several short/normal > messages. >> It can say to the final recipient to send an IMDN to the original >> sender when as soon as he has received the whole large message or all >> the short messages. For example as soon the store and forward server >> close the MSRP session. >> But promoting the IMDN request to the INVITE levels means we have also > >> put at this level same information about the original sender. what do >> you think about? >> >> >> >> > In any case, I think these should be dependent on the presence of a >> > store-and-forward server in the path. >> > >> > >> > >> > /Miguel >> > >> > >> >>> On the other hand, if there isn't a store-and-forward server in the >> >> >>> path, then there is no need for the sender to receive additional >> >>> notifications, because the success reports in MSRP will do the job. >> >>> >> >>> So, I guess where we are going is to get some sort of conditional >> IMDN >> >>> for MSRP. The condition being the unavailability of the recipient >> to get >> >>> the messages and a store-and-forward server storing them. This will >> >> >>> obviously apply to either large messages or short ones. >> >> I don't have a clear view on this, >> >> but maybe if we introduce a indication that an MRSP session is >> >> established for just sending one message, this indication could >> help. >> >> >> >>> Any views on this? >> >>> >> >>> BR, >> >>> >> >>> Miguel >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> _https://www1.ietf.org/mailman/listinfo/simple_ >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> _https://www1.ietf.org/mailman/listinfo/simple_ >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > _https://www1.ietf.org/mailman/listinfo/simple_ > > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client 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 immediately reply to the sender and delete > this information from your system. Use, dissemination, distribution, or > reproduction of this transmission by unintended recipients is not > authorized and may be unlawful. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 08 09:14:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJNY-0006A4-JD; Thu, 08 Mar 2007 09:14:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJNX-00069w-Ek for simple@ietf.org; Thu, 08 Mar 2007 09:13:59 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPJNV-0003Ms-Og for simple@ietf.org; Thu, 08 Mar 2007 09:13:59 -0500 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l28EDsrw030331; Thu, 8 Mar 2007 08:13:54 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 08:13:54 -0600 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Date: Thu, 8 Mar 2007 09:13:47 -0500 Message-ID: <95D8C1105D54EB41864F8831E6C4EB7502C6C258@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <61968779B8AC4C4BAB421D4C12F008C0070CF553@XCH47YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Thread-Index: Acdc03XFdFmQ7ZF/RxqWPpWPFZpckAEI4eKAAAL933kAAf1joAAAplsSAB+XHfA= From: "Nadia Bishai \(QA/EMC\)" To: "Andrew Allen" , X-OriginalArrivalTime: 08 Mar 2007 14:13:54.0276 (UTC) FILETIME=[00F59A40:01C7618C] X-Spam-Score: 0.1 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi It is my understanding that the OMA feature tags are used to identify the service. nadia=20 -----Original Message----- From: Andrew Allen [mailto:aallen@rim.com]=20 Sent: March 7, 2007 6:08 PM To: Nadia Bishai (QA/EMC); pkyzivat@cisco.com Cc: simple@ietf.org Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Nadia So is the feature tag +g.oma.sip-im is used as a service identifier then? Andrew -------------------------- Andrew Allen Manager Standards Research In Motion Ltd BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ Sent from my BlackBerry Wireless Handheld ----- Original Message ----- From: Nadia Bishai (QA/EMC) To: Andrew Allen; pkyzivat@cisco.com Cc: simple@ietf.org Sent: Wed Mar 07 18:01:12 2007 Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Hi Andrew,=20 Please see answers below=20 Nadia=20 -----Original Message----- From: Andrew Allen [mailto:aallen@rim.com ] Sent: March 7, 2007 4:53 PM To: Nadia Bishai (QA/EMC); pkyzivat@cisco.com Cc: simple@ietf.org Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt=20 Nadia=20 Is this feature tag being used as a service identifier?=20 Nadia: Not in the sense of a communication service identifier used by 3GPP. But as an indication of desired treatment by the recipient. Does this feature tag also trigger routing to IM servers based on filter criteria?=20 Nadia: No. Routing is based on other iFCs, namely the +g.oma.sip-im and/or the Request Type.=20 Do SIP requests for MSRP sessions get rejected if the tag doesn't appear in Accept-Contact?=20 Nadia: No Is the tag used for charging and authorisation purpose?=20 Nadia: No=20 Andrew=20 -------------------------- Andrew Allen Manager Standards Research In Motion Ltd BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ =20 Sent from my BlackBerry Wireless Handheld=20 ----- Original Message ----- From: Nadia Bishai (QA/EMC) To: Paul Kyzivat Cc: simple@ietf.org Sent: Wed Mar 07 15:30:05 2007 Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt=20 Hi=20 Actually we use it as a Caller Prefernce in the Accept-Contact header, to indicate to the recipient preferred handling of the request. Nadia=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com ] Sent: March 2, 2007 9:02 AM To: Nadia Bishai (QA/EMC) Cc: Stafford, Matthew; simple@ietf.org Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt=20 Nadia Bishai (QA/EMC) wrote:=20 > Hi Matthew >=20 > In OMA we have just accepted a CR to add a feature tag for Large=20 > Message mode. This will make it easier for both the client and the=20 > server to distinguish between different session types. A *feature tag* ???=20 Do you mean a callee-caps feature tag? Can you explain further how that will be used?=20 Feature tags describe *capabilities* that are supported or desired. They don't specify capabilities that are necessarily being *used*. And they apply to the UA, not to a particular media stream a UA might be using.=20 So, using a feature tag might be fine if it means "I have the capability to support large message mode". But it isn't fine if it is intended to mean "This INVITE is being used to establish a session using Large Message Mode".=20 Paul=20 > Nadia Bishai >=20 > -----Original Message----- > From: Stafford, Matthew [mailto:matthew.stafford@cingular.com=20 > ] > Sent: March 1, 2007 5:02 PM > To: simple@ietf.org > Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >=20 > Since I've been very slow in answering this, here's an attempted=20 > overview of the discussion to date, followed by a question about where > this leads:=20 >=20 > First of all, I think the telegraphic summary (was it provided by > Miguel?) is pretty good:=20 >> - An MSRP session is intercepted by a store-and-forward server. The=20 >> sender would like to be informed when the final recipient receives or >> reads the message(s).=20 >=20 > I guess it's an open question whether the group is interested in=20 > disposition notification functionality for sessions as a whole. (That=20 > wasn't what we were thinking about when we put together the draft.) >=20 > The main *concern* that came up was: in an interactive session with=20 > numerous messages, you wouldn't want to have sender(s) requesting=20 > disposition notification on a per-message basis. >=20 > That concern led to the idea of: you'd need a way to distinguish=20 > between large message mode and a "true" session based experience. > Jerry Shih's clarification at the time- regarding OMA's large message=20 > mode > definition- was that the large message originator's client would=20 > specify send-only in the SDP session negotiation. So, if the intended=20 > recipient > *did* happen to be online, said recipient would not be able to=20 > misconstrue and jump into a back-and-forth exchange where it too was=20 > asking for disposition notification. So it looks like we've got it=20 > boiled down to a question of the session initiator's behavior. >=20 > My question now: suppose we were to say the originator MUST NOT=20 > incorporate DN requests in multiple MSRP messages in the same session, > and moreover MUST specify send-only if it wants to request DN. (Even=20 > if a single message were chunked into multiple MSRP SENDs, I'm=20 > assuming you wouldn't want to have DN headers in each chunk- I'm=20 > thinking of the DN business as residing at a higher layer.) >=20 > Would this sort of requirements be adequate? Or are we talking instead > about a feature-tag or some other explicit identifier that we are in=20 > large message mode? >=20 > Best, > Matt Stafford >=20 > -----Original Message----- > From: Salvatore Loreto (JO/LMF) [mailto:salvatore.loreto@ericsson.com=20 > ] > Sent: Monday, February 05, 2007 7:40 AM > To: Miguel Garcia > Cc: Stafford, Matthew; 'simple@ietf.org'=20 > Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >=20 > Hi Miguel, >=20 > see the discussion on line >=20 > br > /sal >=20 >>> On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote:=20 >>>> Hi:=20 >>>>=20 >>>> So, a summary of draft-stafford-simple-dmdn is that there is a use > case >>>> that is not covered by the current IMDN, which is:=20 >>>>=20 >>>> - An MSRP session is intercepted by a store-and-forward server. The >=20 >>>> sender would like to be informed when the final recipient receives > or >>>> reads the message(s).=20 >>>>=20 >>>> One first question about the use case. It appears form the text in > the >>>> draft that the use case applies only to large messages. However, I > can >>>> envision store-and-forward servers that store a complete MSRP > session >>>> (not only ONE large message).=20 >>> you are right, if you have a store-and-forward in the path this is a >=20 >>> possible scenario, even if I can not imagine at present a specific > use >>> case. (e.g. Why someone would establish a MSRP session with an > off-line >>> user and start to chat with him?) >>=20 >> Well, look at commercial systems. They do it. I can do it. I actually > do >> it... I establish a session with some offline friend to send a few=20 >> messages, or pending items, such as my latest pictures. This is a=20 >> real >=20 >> use case.=20 >=20 > Yes I am aware that some IM programs behave in this way.=20 > What I don't see is the necessity to have or provide a delivery=20 > notification in this scenario, and in fact they don't do. > But I understand and fully agree with your concern about adding some=20 > header for Deliver Notification in the CPIM headers of each MSRP SEND=20 > request. >=20 >>=20 >>>> I think it is important to consider these collections of MSRP > messages, >>>> because, imagine we add something to the CPIM headers of each MSRP > SEND >>>> requesting delivery disposition notification, then the sender will=20 >>>> receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND=20 >>>> request. I guess this is not reasonable. >>> I agree.=20 >>> A solution could be that the store-and-forward server collect all > the >>> message in one single big message, but in this case it shouldn't be > any >>> more a simple store-and-forward.=20 >> Certainly that is one possibility. Another one is to promote the IMDN >> request to the INVITE, and provide a "session-level" IMDN.=20 >=20 > yes, promoting the IMDN request to the INVITE could work in both the > scenario: the only one large message and several short/normal messages.=20 > It can say to the final recipient to send an IMDN to the original=20 > sender when as soon as he has received the whole large message or all=20 > the short messages. For example as soon the store and forward server=20 > close the MSRP session. > But promoting the IMDN request to the INVITE levels means we have also > put at this level same information about the original sender. what do=20 > you think about? >=20 >=20 >=20 >> In any case, I think these should be dependent on the presence of a=20 >> store-and-forward server in the path. >>=20 >>=20 >>=20 >> /Miguel >>=20 >>=20 >>>> On the other hand, if there isn't a store-and-forward server in the >=20 >>>> path, then there is no need for the sender to receive additional=20 >>>> notifications, because the success reports in MSRP will do the job. >>>>=20 >>>> So, I guess where we are going is to get some sort of conditional > IMDN >>>> for MSRP. The condition being the unavailability of the recipient > to get >>>> the messages and a store-and-forward server storing them. This will >=20 >>>> obviously apply to either large messages or short ones.=20 >>> I don't have a clear view on this, >>> but maybe if we introduce a indication that an MRSP session is=20 >>> established for just sending one message, this indication could > help.=20 >>>=20 >>>> Any views on this?=20 >>>>=20 >>>> BR, >>>>=20 >>>> Miguel >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple=20 > >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple=20 > >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple =20 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client 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 immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client 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 immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 08 09:17:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJQc-0006l2-R7; Thu, 08 Mar 2007 09:17:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJQb-0006kT-7P for simple@ietf.org; Thu, 08 Mar 2007 09:17:09 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPJQa-0003th-K0 for simple@ietf.org; Thu, 08 Mar 2007 09:17:09 -0500 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l28EH7BB031230; Thu, 8 Mar 2007 08:17:07 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 08:17:07 -0600 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Date: Thu, 8 Mar 2007 09:17:00 -0500 Message-ID: <95D8C1105D54EB41864F8831E6C4EB7502C6C25B@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <45F01821.6020002@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Thread-Index: AcdhivO28pN8tyZORUaep7fGNxOUTgAAS6DA From: "Nadia Bishai \(QA/EMC\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 08 Mar 2007 14:17:07.0610 (UTC) FILETIME=[743207A0:01C7618C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d Cc: Andrew Allen , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Paul, In answer to your question: =20 Is the iFC matching on +g.oma.sip-im done when it is present in an Accept-Contact header? Or as a capability in a Contact header? This is not specified in the OMA IM specifications, since the specifications only address the service layer, i.e., after the SIP/IP core has triggered on the iFCs and sent the requests to the IM Application server. Nadia =20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: March 8, 2007 9:05 AM To: Nadia Bishai (QA/EMC) Cc: Andrew Allen; simple@ietf.org Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Nadia Bishai (QA/EMC) wrote: > Hi Andrew, >=20 > Please see answers below [snip] > Is this feature tag being used as a service identifier? > Nadia: Not in the sense of a communication service identifier used by=20 > 3GPP. But as an indication of desired treatment by the recipient. >=20 > Does this feature tag also trigger routing to IM servers based on=20 > filter criteria? > Nadia: No. Routing is based on other iFCs, namely the +g.oma.sip-im=20 > and/or the Request Type. >=20 > Do SIP requests for MSRP sessions get rejected if the tag doesn't=20 > appear in Accept-Contact? >=20 > Nadia: No > Is the tag used for charging and authorisation purpose? >=20 > Nadia: No I'm glad to see the answers above, except for one. Is the iFC matching on +g.oma.sip-im done when it is present in an Accept-Contact header? Or as a capability in a Contact header? If in Accept-Contact, can you explain in detail how that will be done so that it doesn't make an incorrect decision when Accept-Contact and Reject-Contact are used in complex ways? Thanks, Paul > ----- Original Message ----- > From: Nadia Bishai (QA/EMC) > To: Paul Kyzivat > Cc: simple@ietf.org > Sent: Wed Mar 07 15:30:05 2007 > Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >=20 > Hi >=20 > Actually we use it as a Caller Prefernce in the Accept-Contact header, > to indicate to the recipient preferred handling of the request. >=20 > Nadia >=20 > -----Original Message----- > From: Paul Kyzivat [_mailto:pkyzivat@cisco.com_] > Sent: March 2, 2007 9:02 AM > To: Nadia Bishai (QA/EMC) > Cc: Stafford, Matthew; simple@ietf.org > Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >=20 >=20 >=20 > Nadia Bishai (QA/EMC) wrote: >> Hi Matthew >> >> In OMA we have just accepted a CR to add a feature tag for Large =20 >> Message mode. This will make it easier for both the client and the =20 >> server to distinguish between different session types. >=20 > A *feature tag* ??? >=20 > Do you mean a callee-caps feature tag? Can you explain further how=20 > that will be used? >=20 > Feature tags describe *capabilities* that are supported or desired.=20 > They don't specify capabilities that are necessarily being *used*. And > they apply to the UA, not to a particular media stream a UA might be using. >=20 > So, using a feature tag might be fine if it means "I have the=20 > capability to support large message mode". But it isn't fine if it is=20 > intended to mean "This INVITE is being used to establish a session=20 > using Large Message Mode". >=20 > Paul >=20 >> Nadia Bishai >> >> -----Original Message----- >> From: Stafford, Matthew [_mailto:matthew.stafford@cingular.com_] >> Sent: March 1, 2007 5:02 PM >> To: simple@ietf.org >> Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >> >> Since I've been very slow in answering this, here's an attempted =20 >> overview of the discussion to date, followed by a question about=20 >> where >=20 >> this leads: >> >> First of all, I think the telegraphic summary (was it provided by >> Miguel?) is pretty good: >> > - An MSRP session is intercepted by a store-and-forward server. The >> > sender would like to be informed when the final recipient receives=20 >> > or >=20 >> > reads the message(s). >> >> I guess it's an open question whether the group is interested in =20 >> disposition notification functionality for sessions as a whole. (That >> wasn't what we were thinking about when we put together the draft.) >> >> The main *concern* that came up was: in an interactive session with >> numerous messages, you wouldn't want to have sender(s) requesting =20 >> disposition notification on a per-message basis. >> >> That concern led to the idea of: you'd need a way to distinguish =20 >> between large message mode and a "true" session based experience. >> Jerry Shih's clarification at the time- regarding OMA's large=20 >> message mode >> definition- was that the large message originator's client would =20 >> specify send-only in the SDP session negotiation. So, if the intended >> recipient >> *did* happen to be online, said recipient would not be able to =20 >> misconstrue and jump into a back-and-forth exchange where it too was >> asking for disposition notification. So it looks like we've got it =20 >> boiled down to a question of the session initiator's behavior. >> >> My question now: suppose we were to say the originator MUST NOT =20 >> incorporate DN requests in multiple MSRP messages in the same=20 >> session, >=20 >> and moreover MUST specify send-only if it wants to request DN. (Even >> if a single message were chunked into multiple MSRP SENDs, I'm =20 >> assuming you wouldn't want to have DN headers in each chunk- I'm =20 >> thinking of the DN business as residing at a higher layer.) >> >> Would this sort of requirements be adequate? Or are we talking=20 >> instead >=20 >> about a feature-tag or some other explicit identifier that we are in >> large message mode? >> >> Best, >> Matt Stafford >> >> -----Original Message----- >> From: Salvatore Loreto (JO/LMF)=20 >> [_mailto:salvatore.loreto@ericsson.com_] >> Sent: Monday, February 05, 2007 7:40 AM >> To: Miguel Garcia >> Cc: Stafford, Matthew; 'simple@ietf.org' >> Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >> >> Hi Miguel, >> >> see the discussion on line >> >> br >> /sal >> >> >> On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote: >> >>> Hi: >> >>> >> >>> So, a summary of draft-stafford-simple-dmdn is that there is a=20 >> >>> use >> case >> >>> that is not covered by the current IMDN, which is: >> >>> >> >>> - An MSRP session is intercepted by a store-and-forward server.=20 >> >>> The >> >> >>> sender would like to be informed when the final recipient=20 >> >>> receives >> or >> >>> reads the message(s). >> >>> >> >>> One first question about the use case. It appears form the text=20 >> >>> in >> the >> >>> draft that the use case applies only to large messages. However,=20 >> >>> I >> can >> >>> envision store-and-forward servers that store a complete MSRP >> session >> >>> (not only ONE large message). >> >> you are right, if you have a store-and-forward in the path this is >> >> a >> >> >> possible scenario, even if I can not imagine at present a specific >> use >> >> case. (e.g. Why someone would establish a MSRP session with an >> off-line >> >> user and start to chat with him?) >> > >> > Well, look at commercial systems. They do it. I can do it. I=20 >> > actually >> do >> > it... I establish a session with some offline friend to send a few=20 >> > messages, or pending items, such as my latest pictures. This is a=20 >> > real >> >> > use case. >> >> Yes I am aware that some IM programs behave in this way. >> What I don't see is the necessity to have or provide a delivery =20 >> notification in this scenario, and in fact they don't do. >> But I understand and fully agree with your concern about adding some >> header for Deliver Notification in the CPIM headers of each MSRP SEND >> request. >> >> > >> >>> I think it is important to consider these collections of MSRP >> messages, >> >>> because, imagine we add something to the CPIM headers of each=20 >> >>> MSRP >> SEND >> >>> requesting delivery disposition notification, then the sender=20 >> >>> will receive one MESSAGE request (message 15 in Figure 1) per=20 >> >>> MSRP SEND request. I guess this is not reasonable. >> >> I agree. >> >> A solution could be that the store-and-forward server collect all >> the >> >> message in one single big message, but in this case it shouldn't=20 >> >> be >> any >> >> more a simple store-and-forward. >> > Certainly that is one possibility. Another one is to promote the=20 >> > IMDN >=20 >> > request to the INVITE, and provide a "session-level" IMDN. >> >> yes, promoting the IMDN request to the INVITE could work in both the >> scenario: the only one large message and several short/normal > messages. >> It can say to the final recipient to send an IMDN to the original =20 >> sender when as soon as he has received the whole large message or all >> the short messages. For example as soon the store and forward server >> close the MSRP session. >> But promoting the IMDN request to the INVITE levels means we have=20 >> also >=20 >> put at this level same information about the original sender. what=20 >> do you think about? >> >> >> >> > In any case, I think these should be dependent on the presence of a >> > store-and-forward server in the path. >> > >> > >> > >> > /Miguel >> > >> > >> >>> On the other hand, if there isn't a store-and-forward server in=20 >> >>> the >> >> >>> path, then there is no need for the sender to receive additional=20 >> >>> notifications, because the success reports in MSRP will do the job. >> >>> >> >>> So, I guess where we are going is to get some sort of conditional >> IMDN >> >>> for MSRP. The condition being the unavailability of the recipient >> to get >> >>> the messages and a store-and-forward server storing them. This=20 >> >>> will >> >> >>> obviously apply to either large messages or short ones. >> >> I don't have a clear view on this, but maybe if we introduce a=20 >> >> indication that an MRSP session is established for just sending=20 >> >> one message, this indication could >> help. >> >> >> >>> Any views on this? >> >>> >> >>> BR, >> >>> >> >>> Miguel >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> _https://www1.ietf.org/mailman/listinfo/simple_ >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> _https://www1.ietf.org/mailman/listinfo/simple_ >> >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > _https://www1.ietf.org/mailman/listinfo/simple_ >=20 >=20 >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the=20 > solicitor-client or other applicable privileges), or constitute=20 > non-public information. Any use of this information by anyone other=20 > than the intended recipient is prohibited. If you have received this=20 > transmission in error, please immediately reply to the sender and=20 > delete this information from your system. Use, dissemination,=20 > distribution, or reproduction of this transmission by unintended=20 > recipients is not authorized and may be unlawful. >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 08 10:05:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPKBd-0003fC-6m; Thu, 08 Mar 2007 10:05:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPKBc-0003aG-A1 for simple@ietf.org; Thu, 08 Mar 2007 10:05:44 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPKBa-0002Sc-HV for simple@ietf.org; Thu, 08 Mar 2007 10:05:44 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2007 07:05:42 -0800 X-IronPort-AV: i="4.14,264,1170662400"; d="scan'208"; a="46589358:sNHT402019335" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l28F5fdP029852; Thu, 8 Mar 2007 07:05:41 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l28F5CaH026581; Thu, 8 Mar 2007 15:05:41 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.1830); Thu, 8 Mar 2007 10:05:26 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 10:05:25 -0500 Message-ID: <45F02635.7010102@cisco.com> Date: Thu, 08 Mar 2007 10:05:25 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Nadia Bishai (QA/EMC)" Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt References: <95D8C1105D54EB41864F8831E6C4EB7502C6C25B@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <95D8C1105D54EB41864F8831E6C4EB7502C6C25B@ecamlmw720.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2007 15:05:25.0803 (UTC) FILETIME=[33A72FB0:01C76193] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12559; t=1173366341; x=1174230341; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20Comments=20to=20draft-stafford-simple-dmdn -00.txt |Sender:=20; bh=EIJt4V5YyICmm1HGvAY+w4WxMvq0cROf8yHd6czKgz0=; b=IhKTmuGBqg1TbGtyv2UuHpTVsJk+poSj0y55H32Z/Kf84J5jnraz7mwPGbW2ZTZgPzGq/HHp hjayxqxcXaHe7jgPvHUbyjQ5I7gAi51xn3sv9WzGVck3yWvnykQ4MVKS; Authentication-Results: sj-dkim-7; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: Andrew Allen , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Nadia Bishai (QA/EMC) wrote: > Hi Paul, > > In answer to your question: > > Is the iFC matching on +g.oma.sip-im done when it is present in an > Accept-Contact header? Or as a capability in a Contact header? > > This is not specified in the OMA IM specifications, since the > specifications only address the service layer, i.e., after the SIP/IP > core has triggered on the iFCs and sent the requests to the IM > Application server. Not the answer I was looking for. IMO this is an important question, in that it impacts whether this method of encoding service ids is valid. So let me ask the question again another way: - Is there any way of constructing an iFC to select an IM-specific application server based on presence of +g.oma.sip-im in a request, that will always correctly deduce whether the request will ultimately select a contact with the +g.oma.sip-im capability? (Even when the caller has used some complex combination of Accept-Contact and Reject-Contact headers.) IMO this can't be done without imposing restrictions on the caller regarding how Accept-Contact and Reject-Contact are used. If using this method for specifying service ids imposes restrictions on the use of 3841 then I think that needs to be made clear. Paul > Nadia > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: March 8, 2007 9:05 AM > To: Nadia Bishai (QA/EMC) > Cc: Andrew Allen; simple@ietf.org > Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt > > > > Nadia Bishai (QA/EMC) wrote: >> Hi Andrew, >> >> Please see answers below > > [snip] > >> Is this feature tag being used as a service identifier? >> Nadia: Not in the sense of a communication service identifier used by >> 3GPP. But as an indication of desired treatment by the recipient. >> >> Does this feature tag also trigger routing to IM servers based on >> filter criteria? >> Nadia: No. Routing is based on other iFCs, namely the +g.oma.sip-im >> and/or the Request Type. >> >> Do SIP requests for MSRP sessions get rejected if the tag doesn't >> appear in Accept-Contact? >> >> Nadia: No >> Is the tag used for charging and authorisation purpose? >> >> Nadia: No > > I'm glad to see the answers above, except for one. > > Is the iFC matching on +g.oma.sip-im done when it is present in an > Accept-Contact header? Or as a capability in a Contact header? > > If in Accept-Contact, can you explain in detail how that will be done so > that it doesn't make an incorrect decision when Accept-Contact and > Reject-Contact are used in complex ways? > > Thanks, > Paul > >> ----- Original Message ----- >> From: Nadia Bishai (QA/EMC) >> To: Paul Kyzivat >> Cc: simple@ietf.org >> Sent: Wed Mar 07 15:30:05 2007 >> Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >> >> Hi >> >> Actually we use it as a Caller Prefernce in the Accept-Contact header, > >> to indicate to the recipient preferred handling of the request. >> >> Nadia >> >> -----Original Message----- >> From: Paul Kyzivat [_mailto:pkyzivat@cisco.com_] >> Sent: March 2, 2007 9:02 AM >> To: Nadia Bishai (QA/EMC) >> Cc: Stafford, Matthew; simple@ietf.org >> Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >> >> >> >> Nadia Bishai (QA/EMC) wrote: >>> Hi Matthew >>> >>> In OMA we have just accepted a CR to add a feature tag for Large >>> Message mode. This will make it easier for both the client and the >>> server to distinguish between different session types. >> A *feature tag* ??? >> >> Do you mean a callee-caps feature tag? Can you explain further how >> that will be used? >> >> Feature tags describe *capabilities* that are supported or desired. >> They don't specify capabilities that are necessarily being *used*. And > >> they apply to the UA, not to a particular media stream a UA might be > using. >> So, using a feature tag might be fine if it means "I have the >> capability to support large message mode". But it isn't fine if it is >> intended to mean "This INVITE is being used to establish a session >> using Large Message Mode". >> >> Paul >> >>> Nadia Bishai >>> >>> -----Original Message----- >>> From: Stafford, Matthew [_mailto:matthew.stafford@cingular.com_] >>> Sent: March 1, 2007 5:02 PM >>> To: simple@ietf.org >>> Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >>> >>> Since I've been very slow in answering this, here's an attempted >>> overview of the discussion to date, followed by a question about >>> where >>> this leads: >>> >>> First of all, I think the telegraphic summary (was it provided by >>> Miguel?) is pretty good: >>>> - An MSRP session is intercepted by a store-and-forward server. The > >>>> sender would like to be informed when the final recipient receives >>>> or >>>> reads the message(s). >>> I guess it's an open question whether the group is interested in >>> disposition notification functionality for sessions as a whole. (That > >>> wasn't what we were thinking about when we put together the draft.) >>> >>> The main *concern* that came up was: in an interactive session with > >>> numerous messages, you wouldn't want to have sender(s) requesting >>> disposition notification on a per-message basis. >>> >>> That concern led to the idea of: you'd need a way to distinguish >>> between large message mode and a "true" session based experience. >>> Jerry Shih's clarification at the time- regarding OMA's large >>> message mode >>> definition- was that the large message originator's client would >>> specify send-only in the SDP session negotiation. So, if the intended > >>> recipient >>> *did* happen to be online, said recipient would not be able to >>> misconstrue and jump into a back-and-forth exchange where it too was > >>> asking for disposition notification. So it looks like we've got it >>> boiled down to a question of the session initiator's behavior. >>> >>> My question now: suppose we were to say the originator MUST NOT >>> incorporate DN requests in multiple MSRP messages in the same >>> session, >>> and moreover MUST specify send-only if it wants to request DN. (Even > >>> if a single message were chunked into multiple MSRP SENDs, I'm >>> assuming you wouldn't want to have DN headers in each chunk- I'm >>> thinking of the DN business as residing at a higher layer.) >>> >>> Would this sort of requirements be adequate? Or are we talking >>> instead >>> about a feature-tag or some other explicit identifier that we are in > >>> large message mode? >>> >>> Best, >>> Matt Stafford >>> >>> -----Original Message----- >>> From: Salvatore Loreto (JO/LMF) >>> [_mailto:salvatore.loreto@ericsson.com_] >>> Sent: Monday, February 05, 2007 7:40 AM >>> To: Miguel Garcia >>> Cc: Stafford, Matthew; 'simple@ietf.org' >>> Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >>> >>> Hi Miguel, >>> >>> see the discussion on line >>> >>> br >>> /sal >>> >>>>> On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote: >>>>>> Hi: >>>>>> >>>>>> So, a summary of draft-stafford-simple-dmdn is that there is a >>>>>> use >>> case >>>>>> that is not covered by the current IMDN, which is: >>>>>> >>>>>> - An MSRP session is intercepted by a store-and-forward server. >>>>>> The >>>>>> sender would like to be informed when the final recipient >>>>>> receives >>> or >>>>>> reads the message(s). >>>>>> >>>>>> One first question about the use case. It appears form the text >>>>>> in >>> the >>>>>> draft that the use case applies only to large messages. However, >>>>>> I >>> can >>>>>> envision store-and-forward servers that store a complete MSRP >>> session >>>>>> (not only ONE large message). >>>>> you are right, if you have a store-and-forward in the path this is > >>>>> a >>>>> possible scenario, even if I can not imagine at present a specific >>> use >>>>> case. (e.g. Why someone would establish a MSRP session with an >>> off-line >>>>> user and start to chat with him?) >>>> Well, look at commercial systems. They do it. I can do it. I >>>> actually >>> do >>>> it... I establish a session with some offline friend to send a few >>>> messages, or pending items, such as my latest pictures. This is a >>>> real >>>> use case. >>> Yes I am aware that some IM programs behave in this way. >>> What I don't see is the necessity to have or provide a delivery >>> notification in this scenario, and in fact they don't do. >>> But I understand and fully agree with your concern about adding some > >>> header for Deliver Notification in the CPIM headers of each MSRP SEND > >>> request. >>> >>>>>> I think it is important to consider these collections of MSRP >>> messages, >>>>>> because, imagine we add something to the CPIM headers of each >>>>>> MSRP >>> SEND >>>>>> requesting delivery disposition notification, then the sender >>>>>> will receive one MESSAGE request (message 15 in Figure 1) per >>>>>> MSRP SEND request. I guess this is not reasonable. >>>>> I agree. >>>>> A solution could be that the store-and-forward server collect all >>> the >>>>> message in one single big message, but in this case it shouldn't >>>>> be >>> any >>>>> more a simple store-and-forward. >>>> Certainly that is one possibility. Another one is to promote the >>>> IMDN >>>> request to the INVITE, and provide a "session-level" IMDN. >>> yes, promoting the IMDN request to the INVITE could work in both the >>> scenario: the only one large message and several short/normal >> messages. >>> It can say to the final recipient to send an IMDN to the original >>> sender when as soon as he has received the whole large message or all > >>> the short messages. For example as soon the store and forward server > >>> close the MSRP session. >>> But promoting the IMDN request to the INVITE levels means we have >>> also >>> put at this level same information about the original sender. what >>> do you think about? >>> >>> >>> >>>> In any case, I think these should be dependent on the presence of a > >>>> store-and-forward server in the path. >>>> >>>> >>>> >>>> /Miguel >>>> >>>> >>>>>> On the other hand, if there isn't a store-and-forward server in >>>>>> the >>>>>> path, then there is no need for the sender to receive additional >>>>>> notifications, because the success reports in MSRP will do the > job. >>>>>> So, I guess where we are going is to get some sort of conditional >>> IMDN >>>>>> for MSRP. The condition being the unavailability of the recipient >>> to get >>>>>> the messages and a store-and-forward server storing them. This >>>>>> will >>>>>> obviously apply to either large messages or short ones. >>>>> I don't have a clear view on this, but maybe if we introduce a >>>>> indication that an MRSP session is established for just sending >>>>> one message, this indication could >>> help. >>>>>> Any views on this? >>>>>> >>>>>> BR, >>>>>> >>>>>> Miguel >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> _https://www1.ietf.org/mailman/listinfo/simple_ >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> _https://www1.ietf.org/mailman/listinfo/simple_ >>> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> _https://www1.ietf.org/mailman/listinfo/simple_ >> >> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential > >> information, privileged material (including material protected by the >> solicitor-client 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 immediately reply to the sender and >> delete this information from your system. Use, dissemination, >> distribution, or reproduction of this transmission by unintended >> recipients is not authorized and may be unlawful. >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 08 10:23:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPKSL-00010F-1g; Thu, 08 Mar 2007 10:23:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPKSJ-0000uw-0n for simple@ietf.org; Thu, 08 Mar 2007 10:22:59 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPKSH-000589-QA for simple@ietf.org; Thu, 08 Mar 2007 10:22:58 -0500 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l28FlM9K002822; Thu, 8 Mar 2007 09:47:22 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 09:22:52 -0600 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Date: Thu, 8 Mar 2007 10:22:44 -0500 Message-ID: <95D8C1105D54EB41864F8831E6C4EB7502C6C2FB@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <45F02635.7010102@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Thread-Index: Acdhk0fucOOWmCWNReqt9OsZyoqMiAAAiViw From: "Nadia Bishai \(QA/EMC\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 08 Mar 2007 15:22:52.0163 (UTC) FILETIME=[A3550D30:01C76195] X-Spam-Score: 0.1 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 Cc: Andrew Allen , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The only answer I can give you is that when the SIP/IP core is 3GPP/3GPP2 IMS/MMD, the trigerring mechanism decribed there will be followed. Nadia=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: March 8, 2007 10:05 AM To: Nadia Bishai (QA/EMC) Cc: Andrew Allen; simple@ietf.org Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Nadia Bishai (QA/EMC) wrote: > Hi Paul, >=20 > In answer to your question: =20 >=20 > Is the iFC matching on +g.oma.sip-im done when it is present in an=20 > Accept-Contact header? Or as a capability in a Contact header? >=20 > This is not specified in the OMA IM specifications, since the=20 > specifications only address the service layer, i.e., after the SIP/IP=20 > core has triggered on the iFCs and sent the requests to the IM=20 > Application server. Not the answer I was looking for. IMO this is an important question, in that it impacts whether this method of encoding service ids is valid. So let me ask the question again another way: - Is there any way of constructing an iFC to select an IM-specific application server based on presence of +g.oma.sip-im in a request, that will always correctly deduce whether the request will ultimately select a contact with the +g.oma.sip-im capability? (Even when the caller has used some complex combination of Accept-Contact and Reject-Contact headers.) IMO this can't be done without imposing restrictions on the caller regarding how Accept-Contact and Reject-Contact are used. If using this method for specifying service ids imposes restrictions on the use of 3841 then I think that needs to be made clear. Paul > Nadia >=20 > =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: March 8, 2007 9:05 AM > To: Nadia Bishai (QA/EMC) > Cc: Andrew Allen; simple@ietf.org > Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >=20 >=20 >=20 > Nadia Bishai (QA/EMC) wrote: >> Hi Andrew, >> >> Please see answers below >=20 > [snip] >=20 >> Is this feature tag being used as a service identifier? >> Nadia: Not in the sense of a communication service identifier used by >> 3GPP. But as an indication of desired treatment by the recipient. >> >> Does this feature tag also trigger routing to IM servers based on=20 >> filter criteria? >> Nadia: No. Routing is based on other iFCs, namely the +g.oma.sip-im=20 >> and/or the Request Type. >> >> Do SIP requests for MSRP sessions get rejected if the tag doesn't=20 >> appear in Accept-Contact? >> >> Nadia: No >> Is the tag used for charging and authorisation purpose? >> >> Nadia: No >=20 > I'm glad to see the answers above, except for one. >=20 > Is the iFC matching on +g.oma.sip-im done when it is present in an=20 > Accept-Contact header? Or as a capability in a Contact header? >=20 > If in Accept-Contact, can you explain in detail how that will be done=20 > so that it doesn't make an incorrect decision when Accept-Contact and=20 > Reject-Contact are used in complex ways? >=20 > Thanks, > Paul >=20 >> ----- Original Message ----- >> From: Nadia Bishai (QA/EMC) >> To: Paul Kyzivat >> Cc: simple@ietf.org >> Sent: Wed Mar 07 15:30:05 2007 >> Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >> >> Hi >> >> Actually we use it as a Caller Prefernce in the Accept-Contact=20 >> header, >=20 >> to indicate to the recipient preferred handling of the request. >> >> Nadia >> >> -----Original Message----- >> From: Paul Kyzivat [_mailto:pkyzivat@cisco.com_] >> Sent: March 2, 2007 9:02 AM >> To: Nadia Bishai (QA/EMC) >> Cc: Stafford, Matthew; simple@ietf.org >> Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >> >> >> >> Nadia Bishai (QA/EMC) wrote: >>> Hi Matthew >>> >>> In OMA we have just accepted a CR to add a feature tag for Large=20 >>> Message mode. This will make it easier for both the client and the=20 >>> server to distinguish between different session types. >> A *feature tag* ??? >> >> Do you mean a callee-caps feature tag? Can you explain further how=20 >> that will be used? >> >> Feature tags describe *capabilities* that are supported or desired.=20 >> They don't specify capabilities that are necessarily being *used*.=20 >> And >=20 >> they apply to the UA, not to a particular media stream a UA might be > using. >> So, using a feature tag might be fine if it means "I have the=20 >> capability to support large message mode". But it isn't fine if it is >> intended to mean "This INVITE is being used to establish a session=20 >> using Large Message Mode". >> >> Paul >> >>> Nadia Bishai >>> >>> -----Original Message----- >>> From: Stafford, Matthew [_mailto:matthew.stafford@cingular.com_] >>> Sent: March 1, 2007 5:02 PM >>> To: simple@ietf.org >>> Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >>> >>> Since I've been very slow in answering this, here's an attempted=20 >>> overview of the discussion to date, followed by a question about=20 >>> where this leads: >>> >>> First of all, I think the telegraphic summary (was it provided by >>> Miguel?) is pretty good: >>>> - An MSRP session is intercepted by a store-and-forward server. The >=20 >>>> sender would like to be informed when the final recipient receives=20 >>>> or reads the message(s). >>> I guess it's an open question whether the group is interested in=20 >>> disposition notification functionality for sessions as a whole.=20 >>> (That >=20 >>> wasn't what we were thinking about when we put together the draft.) >>> >>> The main *concern* that came up was: in an interactive session with >=20 >>> numerous messages, you wouldn't want to have sender(s) requesting=20 >>> disposition notification on a per-message basis. >>> >>> That concern led to the idea of: you'd need a way to distinguish=20 >>> between large message mode and a "true" session based experience. >>> Jerry Shih's clarification at the time- regarding OMA's large=20 >>> message mode >>> definition- was that the large message originator's client would=20 >>> specify send-only in the SDP session negotiation. So, if the=20 >>> intended >=20 >>> recipient >>> *did* happen to be online, said recipient would not be able to=20 >>> misconstrue and jump into a back-and-forth exchange where it too was >=20 >>> asking for disposition notification. So it looks like we've got it=20 >>> boiled down to a question of the session initiator's behavior. >>> >>> My question now: suppose we were to say the originator MUST NOT=20 >>> incorporate DN requests in multiple MSRP messages in the same=20 >>> session, and moreover MUST specify send-only if it wants to request >>> DN. (Even >=20 >>> if a single message were chunked into multiple MSRP SENDs, I'm=20 >>> assuming you wouldn't want to have DN headers in each chunk- I'm=20 >>> thinking of the DN business as residing at a higher layer.) >>> >>> Would this sort of requirements be adequate? Or are we talking=20 >>> instead about a feature-tag or some other explicit identifier that=20 >>> we are in >=20 >>> large message mode? >>> >>> Best, >>> Matt Stafford >>> >>> -----Original Message----- >>> From: Salvatore Loreto (JO/LMF) >>> [_mailto:salvatore.loreto@ericsson.com_] >>> Sent: Monday, February 05, 2007 7:40 AM >>> To: Miguel Garcia >>> Cc: Stafford, Matthew; 'simple@ietf.org' >>> Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt >>> >>> Hi Miguel, >>> >>> see the discussion on line >>> >>> br >>> /sal >>> >>>>> On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote: >>>>>> Hi: >>>>>> >>>>>> So, a summary of draft-stafford-simple-dmdn is that there is a=20 >>>>>> use >>> case >>>>>> that is not covered by the current IMDN, which is: >>>>>> >>>>>> - An MSRP session is intercepted by a store-and-forward server.=20 >>>>>> The >>>>>> sender would like to be informed when the final recipient=20 >>>>>> receives >>> or >>>>>> reads the message(s). >>>>>> >>>>>> One first question about the use case. It appears form the text=20 >>>>>> in >>> the >>>>>> draft that the use case applies only to large messages. However,=20 >>>>>> I >>> can >>>>>> envision store-and-forward servers that store a complete MSRP >>> session >>>>>> (not only ONE large message). >>>>> you are right, if you have a store-and-forward in the path this is >=20 >>>>> a >>>>> possible scenario, even if I can not imagine at present a specific >>> use >>>>> case. (e.g. Why someone would establish a MSRP session with an >>> off-line >>>>> user and start to chat with him?) >>>> Well, look at commercial systems. They do it. I can do it. I=20 >>>> actually >>> do >>>> it... I establish a session with some offline friend to send a few=20 >>>> messages, or pending items, such as my latest pictures. This is a=20 >>>> real use case. >>> Yes I am aware that some IM programs behave in this way. >>> What I don't see is the necessity to have or provide a delivery=20 >>> notification in this scenario, and in fact they don't do. >>> But I understand and fully agree with your concern about adding=20 >>> some >=20 >>> header for Deliver Notification in the CPIM headers of each MSRP=20 >>> SEND >=20 >>> request. >>> >>>>>> I think it is important to consider these collections of MSRP >>> messages, >>>>>> because, imagine we add something to the CPIM headers of each=20 >>>>>> MSRP >>> SEND >>>>>> requesting delivery disposition notification, then the sender=20 >>>>>> will receive one MESSAGE request (message 15 in Figure 1) per=20 >>>>>> MSRP SEND request. I guess this is not reasonable. >>>>> I agree. >>>>> A solution could be that the store-and-forward server collect all >>> the >>>>> message in one single big message, but in this case it shouldn't=20 >>>>> be >>> any >>>>> more a simple store-and-forward. >>>> Certainly that is one possibility. Another one is to promote the=20 >>>> IMDN request to the INVITE, and provide a "session-level" IMDN. >>> yes, promoting the IMDN request to the INVITE could work in both=20 >>> the >>> scenario: the only one large message and several short/normal >> messages. >>> It can say to the final recipient to send an IMDN to the original=20 >>> sender when as soon as he has received the whole large message or=20 >>> all >=20 >>> the short messages. For example as soon the store and forward server >=20 >>> close the MSRP session. >>> But promoting the IMDN request to the INVITE levels means we have=20 >>> also put at this level same information about the original sender.=20 >>> what do you think about? >>> >>> >>> >>>> In any case, I think these should be dependent on the presence of a >=20 >>>> store-and-forward server in the path. >>>> >>>> >>>> >>>> /Miguel >>>> >>>> >>>>>> On the other hand, if there isn't a store-and-forward server in=20 >>>>>> the >>>>>> path, then there is no need for the sender to receive additional=20 >>>>>> notifications, because the success reports in MSRP will do the > job. >>>>>> So, I guess where we are going is to get some sort of conditional >>> IMDN >>>>>> for MSRP. The condition being the unavailability of the recipient >>> to get >>>>>> the messages and a store-and-forward server storing them. This=20 >>>>>> will >>>>>> obviously apply to either large messages or short ones. >>>>> I don't have a clear view on this, but maybe if we introduce a=20 >>>>> indication that an MRSP session is established for just sending=20 >>>>> one message, this indication could >>> help. >>>>>> Any views on this? >>>>>> >>>>>> BR, >>>>>> >>>>>> Miguel >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> _https://www1.ietf.org/mailman/listinfo/simple_ >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> _https://www1.ietf.org/mailman/listinfo/simple_ >>> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> _https://www1.ietf.org/mailman/listinfo/simple_ >> >> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential >=20 >> information, privileged material (including material protected by the >> solicitor-client or other applicable privileges), or constitute=20 >> non-public information. Any use of this information by anyone other=20 >> than the intended recipient is prohibited. If you have received this=20 >> transmission in error, please immediately reply to the sender and=20 >> delete this information from your system. Use, dissemination,=20 >> distribution, or reproduction of this transmission by unintended=20 >> recipients is not authorized and may be unlawful. >> >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 08 16:02:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPk5-0004PH-3T; Thu, 08 Mar 2007 16:01:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPZq-0007w0-13; Thu, 08 Mar 2007 15:51:06 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPPZn-00026I-DJ; Thu, 08 Mar 2007 15:51:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 970892AD07; Thu, 8 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYp-0007Gd-BO; Thu, 08 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-diff-05.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-diff-05.txt Pages : 13 Date : 2007-3-8 This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). This format indicates the document that has changed and its former and new entity tags. It also can indicate the specific change that was made in the document, using an XML patch format. XCAP diff documents can be delivered to clients using a number of means, including a Session Initiation Protocol (SIP) event package. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-xcap-diff-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xcap-diff-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-8115447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-diff-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-diff-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8115447.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Fri Mar 09 19:47:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPpjK-0003ON-54; Fri, 09 Mar 2007 19:46:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPpjI-0003OI-PE for simple@ietf.org; Fri, 09 Mar 2007 19:46:36 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPpjH-0004N6-Ic for simple@ietf.org; Fri, 09 Mar 2007 19:46:36 -0500 Received: from lion.cs.columbia.edu (IDENT:oYWqUeMnCxquwd6ii9pyU8lO/3tZTALw@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l2A0kWft021885 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 9 Mar 2007 19:46:32 -0500 (EST) Received: from [128.59.23.96] (vs2140pc.cs.columbia.edu [128.59.23.96]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id l2A0kQbA014556 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 9 Mar 2007 19:46:32 -0500 Message-ID: <45F20003.3070404@cs.columbia.edu> Date: Fri, 09 Mar 2007 19:46:59 -0500 From: Vishal Kumar Singh User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.5 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Simple] Vehicle Info Event Package Draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello All, We have submitted a new Internet-draft: Vehicle Info Event Package The draft is available at: http://www1.cs.columbia.edu/~vs2140/presence/vehicle-info/draft-singh-simple-vehicle-info-00.txt Please find the abstract below: This document defines a new SIP event package for updating and retrieving status information of vehicles. The information can include the vehicle's status and diagnostic information distributed by vehicle telematics systems. This event package is useful for fleet management and vehicle tracking applications. The event package is called as vehicle-info event package and is applicable to all types of vehicles like cars, buses, ships and air crafts. However, this document focuses on automobiles. Please send your comments. Regards, Vishal -- Not everything that can be counted counts, and not everything that counts can be counted. -By Albert Einstein _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 10 15:49:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8TP-0002Wf-Ng; Sat, 10 Mar 2007 15:47:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8TP-0002WF-02 for simple@ietf.org; Sat, 10 Mar 2007 15:47:27 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ8TM-0005n4-AJ for simple@ietf.org; Sat, 10 Mar 2007 15:47:26 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 10 Mar 2007 12:47:24 -0800 X-IronPort-AV: i="4.14,270,1170662400"; d="scan'208"; a="399803723:sNHT40255056" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l2AKlNfb010425 for ; Sat, 10 Mar 2007 12:47:23 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l2AKlNa4010402 for ; Sat, 10 Mar 2007 20:47:23 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <2404F098-B4EC-4B50-92A1-FCF5292E85E7@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: simple@ietf.org From: Cullen Jennings Date: Sat, 10 Mar 2007 12:46:59 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=477; t=1173559643; x=1174423643; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-singh-simple-vehicle-info-00 |Sender:=20; bh=ps606JP4azfd0xjoUl4pMpMSmm3vlnxMaoSj2Gt/Xyk=; b=Yp7FhFKtbOthRkrCd4/ndtVI2aTQ2TxzxoDy9KxIvUQGDiVFXpfk4woMBNyrGXLGVLTlDolF N9R8Aen7kvG8ayJW8OAU2lU7QZOG4yc71t31jwWiSee74/sUs14dAOMa; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Simple] draft-singh-simple-vehicle-info-00 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Interesting draft. There are a lot of privacy issues here - I think the draft needs a better model about how the user of the car and the car (the device in this case) get bound together and more importantly how they get unbound. If you imagine that the car is used by multiple users but by using bluetooth to a cell phone (or something else like an individual key) you know who is in the car at a given point of time. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 10 17:04:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ9fS-0006Zx-8r; Sat, 10 Mar 2007 17:03:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ9fR-0006Zs-9f for simple@ietf.org; Sat, 10 Mar 2007 17:03:57 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ9fQ-0004hj-1p for simple@ietf.org; Sat, 10 Mar 2007 17:03:57 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-3.cisco.com with ESMTP; 10 Mar 2007 14:03:55 -0800 X-IronPort-AV: i="4.14,270,1170662400"; d="scan'208"; a="469778060:sNHT41227648" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l2AM3tIo023975 for ; Sat, 10 Mar 2007 14:03:55 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l2AM3txS025383 for ; Sat, 10 Mar 2007 22:03:55 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: simple@ietf.org From: Cullen Jennings Date: Sat, 10 Mar 2007 14:03:30 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=127; t=1173564235; x=1174428235; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-niemi-simple-msrp-ice-00=20 |Sender:=20; bh=tgLa6zDSXk0Uq4PjHYfZtbVSu4GZwizM1irsf2MwfsA=; b=rZEio6Jms3T5B+XetP/HF/ZTwzx3zGfPB9hRzQfGHvs/lsio/KQ71ghP90S+JbB077/MMWQk p/QO9psZWPGX4JtRswkn46DMJPry9l54Tr71fDazhU1dgyNxyE+8/Lbb; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Simple] draft-niemi-simple-msrp-ice-00 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I've been hoping someone would write something like this for a long time - thanks. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 12 04:06:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQfX5-0005pW-A9; Mon, 12 Mar 2007 04:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQfX4-0005pR-Py for simple@ietf.org; Mon, 12 Mar 2007 04:05:26 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQfX3-0000KU-6e for simple@ietf.org; Mon, 12 Mar 2007 04:05:26 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2C855Lm018244; Mon, 12 Mar 2007 10:05:22 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 10:05:12 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 10:05:12 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2C85Aqa022585; Mon, 12 Mar 2007 10:05:10 +0200 Received: from [172.21.43.170] (esdhcp043170.research.nokia.com [172.21.43.170]) by kusti.research.nokia.com (Postfix) with ESMTP id 5102993B77; Mon, 12 Mar 2007 10:05:10 +0200 (EET) Message-ID: <45F5086E.6070506@nokia.com> Date: Mon, 12 Mar 2007 09:59:42 +0200 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: ext Julian Reschke References: <45F0105E.7040605@nokia.com> <45F1C840.5060708@gmx.de> In-Reply-To: <45F1C840.5060708@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Mar 2007 08:05:12.0209 (UTC) FILETIME=[28D51010:01C7647D] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070312100522-39725BB0-258D45B2/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: WebDAV , simple@ietf.org Subject: [Simple] Re: xcap co-operation with dav X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org ext Julian Reschke wrote: > Jari Urpalainen schrieb: >> >> hi ! >> >> Sorry for cross-posting. I've updated the i-d: >> >> which describes some conventions for XCAP usage with WebDAV. Any >> comments ? >> thanks, jari > > Hi Jari, > > I currently don't have time to do a real review, but here are some > quick comments: > > The owners of documents are principals which are manifested to > clients as a WebDAV resource, identified by a URI. A server that > implements both WebDAV and XCAP MUST support the same principal > namespace for both WebDAV ACL usage and XCAP user identities (XUI). > > There is no requirement that a WebDAV principal actually is > represented as a WebDAV resource (only HTTP(s) is required). > right, the line between http & dav is pretty vague... > > XCAP recommends an XCAP root URI like "http://xcap.example.com" for a > domain "example.com". It is thus RECOMMENDED that the principal URI > is of the form "http://xcap.example.com/principals/joe/self" for a > user "joe" (XUI). > > Note: The host and path segments of principal URIs may be > different in actual deployments, as path segment "principals" is > not part of an XCAP Application Usage. However, note that an XUI > SHOULD still represent a collection. > > It's not really clear what the requirement here is... If it's not the > path, then are you referring to the host (that is, principal URIs must > be on the same server)? Why? > I'd rather have this as a real requirement, but it would easily break existing deployments if any. The purpose of the note was to clarify that it that the "principals" path could overlap with a similar name XCAP AU. Having different hosts is definitely allowed, although acl-processor needs to have access to this (and preferably local). But I'll try to rephrase. > > > 4.6. Other WebDAV methods > > With any other WebDAV methods when accessing XCAP resources, the > request URI may not contain an XCAP node selector. > > I'm not sure what this is saying... Clients MUST NOT attempt WebDAV > verbs on XCAP nodes? Why? If the server can't execute them, it should > fail the request. Right, the purpose is to fail the request, I'll rephrase. The reason to drop DAV stuff from XCAP components is very pragmatic, it is _very_ complex and there are several error cases which are not at all that clear. So the specification/implementation complexity is way too complex, imo. So I am looking for a real no-brainer use-case here. > > > If WebDAV methods (other than GET, PUT or DELETE) are used with > request URIs which contain an otherwise valid XCAP node selector the > server SHOULD respond with 403 (Not Authorized). The corresponding > precondition error element is defined formally by the RELAX NG Schema > [5] given in Section 7.1. > > 401 Not Authorized or 403 Forbidden???? This was already a discussion item in the previous version. Personally I don't care what's the error number, unless there's a recommendation (once again a MUST requirement would be nice, but it seems too hard from implementation point of view...). So what's your proposal ? > > > Finally, it seems to me that the spec tries to profile RFC3744. That > may be the right thing to do, but it would make things easier to > understand if it would state that more clearly, and also provide a > motivation for it. > > > Best regards, Julian Right, I would be more than happy to have a similar feature in rfc3744bis, which is the proper place for this. Thanks Julian for your comments. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 13 01:59:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR01V-0002K0-7Z; Tue, 13 Mar 2007 01:58:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR01T-0002Jj-TK for Simple@ietf.org; Tue, 13 Mar 2007 01:58:11 -0400 Received: from ik-out-1112.google.com ([66.249.90.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR01S-0008K1-Kl for Simple@ietf.org; Tue, 13 Mar 2007 01:58:11 -0400 Received: by ik-out-1112.google.com with SMTP id c21so1907030ika for ; Mon, 12 Mar 2007 22:58:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=aHvdRGZ1WTAYYSkcNTK0djtw3D51pAAxmfFu8L8e9CLXeBg7Ry7zBDejHhmo8rQi0fAS7G/4SVTLK04MNqNM+6M34pwclSiebm+bdT1vgAJgOAlylTYdqwdgz0LD0tBsR+OnhFVWEp6v9vmQGCOY4eqOwJgWBrMh9l/4zxhLoc8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=iJycHxTqhY9v79HmAXBpV4bEhylN9ejP3Bx6WAVjuMGDLzsD5BNRNxKIpTmlNMyh9cbSj7OtqXn4dAIz+MPiUlEWsYRMog4I5UXD5X3FhIRjC/1yKeme4XFvynomfO2kNeupppkOR9ZtPNYUR+tW2EWe7L1/7up797HrSWlMHuk= Received: by 10.114.124.1 with SMTP id w1mr2234791wac.1173765489069; Mon, 12 Mar 2007 22:58:09 -0700 (PDT) Received: by 10.114.103.12 with HTTP; Mon, 12 Mar 2007 22:58:04 -0700 (PDT) Message-ID: <52db68bc0703122258h7e990599rc7aac03873645d57@mail.gmail.com> Date: Tue, 13 Mar 2007 11:28:04 +0530 From: "Sudhir Kumar Reddy " To: Simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Simple] query in content types X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0712332394==" Errors-To: simple-bounces@ietf.org --===============0712332394== Content-Type: multipart/alternative; boundary="----=_Part_20378_24368105.1173765484044" ------=_Part_20378_24368105.1173765484044 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, Could anyone tell me about the differences between application/xpidf+xml, application/msrtcpidf+xml and application/pidf+xml? Is there any advantages between these content types? any repsonse is highly appericated thanks in advnace regards sudhir ------=_Part_20378_24368105.1173765484044 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,

Could anyone tell me about the differences between application/xpidf+xml, application/msrtcpidf+xml and application/pidf+xml? Is there any advantages between these content types?

any repsonse is highly appericated

thanks in advnace

regards
sudhir ------=_Part_20378_24368105.1173765484044-- --===============0712332394== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0712332394==-- From simple-bounces@ietf.org Tue Mar 13 11:05:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8YC-0004vL-BF; Tue, 13 Mar 2007 11:04:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8YB-0004uO-3x for simple@ietf.org; Tue, 13 Mar 2007 11:04:31 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR8Y7-0006lz-Pk for simple@ietf.org; Tue, 13 Mar 2007 11:04:31 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2DF3mWE032405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 13 Mar 2007 09:04:27 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <6F1A207E-52AA-4B6A-B50C-DBD0215D172A@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: simple@ietf.org From: Robert Sparks Date: Tue, 13 Mar 2007 10:04:25 -0500 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Simple] SIPit 20 registration deadline is March 30 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org If you plan to attend SIPit 20 in Antwerp, Belgium April 16-20 and have not yet registered, now's the time. Registration closes in just over two weeks (March 30). See www.sipit.net for more information and the registration link. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 13 15:51:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRD0l-0003QN-PL; Tue, 13 Mar 2007 15:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRD0k-0003P3-DA for simple@ietf.org; Tue, 13 Mar 2007 15:50:18 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRD0i-0004n3-VL for simple@ietf.org; Tue, 13 Mar 2007 15:50:18 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2DJmWkw020045; Tue, 13 Mar 2007 21:48:54 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 21:48:45 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 21:48:45 +0200 Received: from [10.162.64.97] ([10.162.64.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 21:48:45 +0200 Message-ID: <45F7001C.7020303@nokia.com> Date: Tue, 13 Mar 2007 21:48:44 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ben Campbell , Cullen Jennings , Rohan Mahy Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2007 19:48:45.0152 (UTC) FILETIME=[9C1EBE00:01C765A8] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070313214856-4DF2DBB0-7618EC94/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "'simple@ietf.org'" Subject: [Simple] MSRP: 200 OK for chunked SEND request. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi: In MSRP, a question about a 200 OK for a chunked SEND request. It is not clear in the draft if the response ends with a "$" or "+" sign. For example. If the chunked request is: MSRP dkei38sd SEND From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp Message-ID: 4564dpWd Byte-Range: 1-*/8 Content-Type: text/plain abcd -------dkei38sd+ Then, which one is the correct response? Option A: Ending '+', so copied from the request. MSRP dkei38sd 200 OK From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp Message-ID: 4564dpWd -------dkei38sd+ Option B: ending '$', so all the 200 OK responses end with a '$', no matter whether they acknowledge a chunk or a complete message. MSRP dkei38sd 200 OK From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp Message-ID: 4564dpWd -------dkei38sd$ Whatever is the answer, please write it down in the draft. This has already created interoperability problems. BR, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 13 15:58:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRD7u-0005jy-QQ; Tue, 13 Mar 2007 15:57:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRD7s-0005en-Mo; Tue, 13 Mar 2007 15:57:40 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRD7q-00068x-50; Tue, 13 Mar 2007 15:57:40 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2DJvbA5046251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Mar 2007 13:57:37 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) To: simple@ietf.org, behave@ietf.org Message-Id: <7A9E866C-74BC-4111-8159-2A7B9165110B@nostrum.com> From: Robert Sparks Date: Tue, 13 Mar 2007 14:57:36 -0500 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: Subject: [Simple] dealing with the SIMPLE/BEHAVE conflict X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: simple-chairs@tools.ietf.org, behave-chairs@tools.ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0582231066==" Errors-To: simple-bounces@ietf.org --===============0582231066== Content-Type: multipart/alternative; boundary=Apple-Mail-26-87644206 --Apple-Mail-26-87644206 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Please forgive the crosspost. Unless you have a compelling reason to reply to the lists, please reply only to the chairs. SIMPLE and BEHAVE are meeting at the same time. In order to facilitate having the right people in the right place at =20 the right time, we're adjusting the order of topics in the SIMPLE =20 meeting. The current plan is to follow the agenda below. RjS =E2=96=BC 20m - Administrivia and Planning =E2=80=A2 Chairs =E2=96=BC 15m - Deferred Message Disposition Notification =E2=80=A2 Jerry Shih =E2=80=A2 draft-stafford-simple-dmdn-00.txt =E2=96=BC 10m - Sigcomp Presence Dictionary =E2=80=A2 Miguel Garcia =E2=80=A2 draft-garcia-simple-presence-dictionary-02.txt =E2=96=BC 10m - Vehicle Information Event Package =E2=80=A2 Henning Schulzrinne =E2=80=A2 draft-singh-simple-vehicle-info-00.txt =E2=96=BC 20m - Performance and Scaling Analysis =E2=80=A2 Avshalom Houri =E2=80=A2 = draft-ietf-simple-interdomain-scaling-analysis-00.txt =E2=96=BC 30m - Multiparty IM sessions using MSRP =E2=80=A2 Miguel Garcia/Aki Neimi =E2=80=A2 draft-niemi-simple-chat-06.txt =E2=96=BC 5m - Update: XCON IM sessions using MSRP =E2=80=A2 Mary Barnes =E2=80=A2 draft-boulton-xcon-msrp-conferencing-04.txt =E2=96=BC 10m - Establishing MSRP sessions using ICE =E2=80=A2 Aki Neimi =E2=80=A2 draft-niemi-simple-msrp-ice-00.txt --Apple-Mail-26-87644206 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Please forgive the crosspost. = Unless you have a compelling reason to
reply to the lists, please = reply only to the chairs.

SIMPLE and BEHAVE are = meeting at the same time.

In order to facilitate = having the right people in the right place at the right time, we're = adjusting the order of topics in the SIMPLE meeting. The current plan is = to follow the agenda below.

RjS

=E2=96=BC 20m - = Administrivia and Planning
=E2=80=A2 Chairs
=E2=96=BC 15m - Deferred Message = Disposition Notification
=E2=80=A2 Jerry Shih
=E2=80=A2 = draft-stafford-simple-dmdn-00.txt
=E2=96=BC 10m - = Sigcomp Presence Dictionary
=E2=80=A2 Miguel Garcia
=E2=80=A2 = draft-garcia-simple-presence-dictionary-02.txt
=E2=96=BC 10m - Vehicle Information Event = Package
=E2=80=A2 Henning = Schulzrinne
=E2=80=A2 = draft-singh-simple-vehicle-info-00.txt
=E2=96=BC 20m - Performance and Scaling = Analysis
=E2=80=A2 Avshalom = Houri
=E2=80=A2 = draft-ietf-simple-interdomain-scaling-analysis-00.txt
=E2=96=BC 30m - Multiparty IM sessions = using MSRP
=E2=80=A2 Miguel = Garcia/Aki Neimi
=E2=80=A2 = draft-niemi-simple-chat-06.txt
=E2=96=BC 5m - = Update: XCON IM sessions using MSRP
=E2=80=A2 Mary Barnes
=E2=80=A2 = draft-boulton-xcon-msrp-conferencing-04.txt
=E2=96=BC 10m - Establishing MSRP sessions = using ICE
=E2=80=A2 Aki = Neimi
=E2=80=A2 = draft-niemi-simple-msrp-ice-00.txt

= --Apple-Mail-26-87644206-- --===============0582231066== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0582231066==-- From simple-bounces@ietf.org Tue Mar 13 16:45:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRDrb-00055D-H1; Tue, 13 Mar 2007 16:44:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRDra-00053s-UR for simple@ietf.org; Tue, 13 Mar 2007 16:44:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRDrZ-0007K9-Lo for simple@ietf.org; Tue, 13 Mar 2007 16:44:54 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Mar 2007 16:44:53 -0400 X-IronPort-AV: i="4.14,280,1170651600"; d="scan'208"; a="54685916:sNHT50366208" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2DKirKn003016; Tue, 13 Mar 2007 16:44:53 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2DKila3001535; Tue, 13 Mar 2007 20:44:52 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.1830); Tue, 13 Mar 2007 16:44:43 -0400 Received: from [161.44.182.121] ([161.44.182.121]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 16:44:42 -0400 Message-ID: <45F70D3A.9050403@cisco.com> Date: Tue, 13 Mar 2007 16:44:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] MSRP: 200 OK for chunked SEND request. References: <45F7001C.7020303@nokia.com> In-Reply-To: <45F7001C.7020303@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2007 20:44:42.0775 (UTC) FILETIME=[6D6B5A70:01C765B0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1532; t=1173818693; x=1174682693; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20MSRP=3A=20200=20OK=20for=20chunked=20SEND= 20request. |Sender:=20 |To:=20Miguel=20Garcia=20; bh=BwZWEXnM5lylTj36sK2fy9ZUkjqmBH0dibS6kOLoK8U=; b=IQPWg9WwYKSp8GvePNfDQAWTbD7lPJgOGaFfwhcAmIHUjiaCOF9f7TayeEiX8WlyoTTgENux 7ZQtmw8I6ySQsIV7rKHfXQHBT3IAN2s+hzLxVtV8f86SgoBlmzXOjGLC; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Cullen Jennings , "'simple@ietf.org'" , Rohan Mahy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Miguel, What am I missing? What you are talking about is part of the *body* of the send. The response doesn't have a body at all, so it shouldn't have either + or $. Paul Miguel Garcia wrote: > Hi: > > In MSRP, a question about a 200 OK for a chunked SEND request. It is not > clear in the draft if the response ends with a "$" or "+" sign. > > For example. If the chunked request is: > > MSRP dkei38sd SEND > From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp > To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp > Message-ID: 4564dpWd > Byte-Range: 1-*/8 > Content-Type: text/plain > > abcd > -------dkei38sd+ > > Then, which one is the correct response? > > Option A: Ending '+', so copied from the request. > > MSRP dkei38sd 200 OK > From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp > To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp > Message-ID: 4564dpWd > -------dkei38sd+ > > Option B: ending '$', so all the 200 OK responses end with a '$', no > matter whether they acknowledge a chunk or a complete message. > > MSRP dkei38sd 200 OK > From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp > To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp > Message-ID: 4564dpWd > -------dkei38sd$ > > > Whatever is the answer, please write it down in the draft. This has > already created interoperability problems. > > BR, > > Miguel > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 13 16:56:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRE1t-00022Q-5R; Tue, 13 Mar 2007 16:55:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRE1r-000223-NE for simple@ietf.org; Tue, 13 Mar 2007 16:55:31 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRE1n-0001lY-Vp for simple@ietf.org; Tue, 13 Mar 2007 16:55:31 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2DKrwel006549; Tue, 13 Mar 2007 22:54:05 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 22:53:55 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 22:53:55 +0200 Received: from [10.162.64.97] ([10.162.64.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 22:53:54 +0200 Message-ID: <45F70F61.6010904@nokia.com> Date: Tue, 13 Mar 2007 22:53:53 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] MSRP: 200 OK for chunked SEND request. References: <45F7001C.7020303@nokia.com> <45F70D3A.9050403@cisco.com> In-Reply-To: <45F70D3A.9050403@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2007 20:53:54.0933 (UTC) FILETIME=[B687FA50:01C765B1] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070313225408-17544BB0-3D49220D/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Cullen Jennings , "'simple@ietf.org'" , Rohan Mahy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Paul: While is true that the 200 OK does not have a body, it still contains the frame delimiter composed by the seven hyphens (-), the transaction identifier, and the continuation flag, the same like a request. Now, if you receive a chunked MSRP, i.e., one where the continuation flag is a '+', you need to generate a 200 OK. Which continuation flag do you put in the 200 OK? MSRP does not say anything (at least anything that I was able to find the the draft). /Miguel Paul Kyzivat wrote: > Miguel, > > What am I missing? What you are talking about is part of the *body* of > the send. The response doesn't have a body at all, so it shouldn't have > either + or $. > > Paul > > Miguel Garcia wrote: >> Hi: >> >> In MSRP, a question about a 200 OK for a chunked SEND request. It is >> not clear in the draft if the response ends with a "$" or "+" sign. >> >> For example. If the chunked request is: >> >> MSRP dkei38sd SEND >> From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >> To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >> Message-ID: 4564dpWd >> Byte-Range: 1-*/8 >> Content-Type: text/plain >> >> abcd >> -------dkei38sd+ >> >> Then, which one is the correct response? >> >> Option A: Ending '+', so copied from the request. >> >> MSRP dkei38sd 200 OK >> From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >> To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >> Message-ID: 4564dpWd >> -------dkei38sd+ >> >> Option B: ending '$', so all the 200 OK responses end with a '$', no >> matter whether they acknowledge a chunk or a complete message. >> >> MSRP dkei38sd 200 OK >> From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >> To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >> Message-ID: 4564dpWd >> -------dkei38sd$ >> >> >> Whatever is the answer, please write it down in the draft. This has >> already created interoperability problems. >> >> BR, >> >> Miguel >> -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 13 16:59:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRE5W-0002qH-KU; Tue, 13 Mar 2007 16:59:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRE5V-0002qC-EW for simple@ietf.org; Tue, 13 Mar 2007 16:59:17 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRE5T-0002nL-UG for simple@ietf.org; Tue, 13 Mar 2007 16:59:17 -0400 Received: from [10.240.24.241] (m815f36d0.tmodns.net [208.54.95.129]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l2DKw7Ba041775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Mar 2007 15:58:12 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <45F70D3A.9050403@cisco.com> References: <45F7001C.7020303@nokia.com> <45F70D3A.9050403@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: 200 OK for chunked SEND request. Date: Tue, 13 Mar 2007 15:57:59 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Miguel Garcia , Cullen Jennings , "'simple@ietf.org'" , Rohan Mahy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Mar 13, 2007, at 3:44 PM, Paul Kyzivat wrote: > Miguel, > > What am I missing? What you are talking about is part of the *body* > of the send. The response doesn't have a body at all, so it > shouldn't have either + or $. > It is required by the current syntax. The presence of an end-line is not contingent upon the presence of a body. From the abnf: msrp-req-or-resp = msrp-request / msrp-response msrp-request = req-start headers [content-stuff] end-line msrp-response = resp-start headers end-line [...] end-line = "-------" transact-id continuation-flag CRLF continuation-flag = "+" / "$" / "#" The whole point was to be able to use the same framing mechanism for requests and responses. One interpretation would be that it really doesn't matter what you put in a response continuation flag. We haven't assigned it any meaning one way or another. Another would be that since it is never chunked, the value should always be "$". The value of the continuation flag in a response is not in any way connected to that of the associated request. Perhaps an auth-48 change on the order of "the sender of a response MUSt always use a $, but the recipient of the response MUST NOT care. > Paul > > Miguel Garcia wrote: >> Hi: >> In MSRP, a question about a 200 OK for a chunked SEND request. It >> is not clear in the draft if the response ends with a "$" or "+" >> sign. >> For example. If the chunked request is: >> MSRP dkei38sd SEND >> From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >> To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >> Message-ID: 4564dpWd >> Byte-Range: 1-*/8 >> Content-Type: text/plain >> abcd >> -------dkei38sd+ >> Then, which one is the correct response? >> Option A: Ending '+', so copied from the request. >> MSRP dkei38sd 200 OK >> From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >> To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >> Message-ID: 4564dpWd >> -------dkei38sd+ >> Option B: ending '$', so all the 200 OK responses end with a '$', >> no matter whether they acknowledge a chunk or a complete message. >> MSRP dkei38sd 200 OK >> From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >> To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >> Message-ID: 4564dpWd >> -------dkei38sd$ >> Whatever is the answer, please write it down in the draft. This >> has already created interoperability problems. >> BR, >> Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 13 17:14:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HREIv-0008Ah-Fb; Tue, 13 Mar 2007 17:13:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HREIu-00089h-Kd for simple@ietf.org; Tue, 13 Mar 2007 17:13:08 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HREIt-00052B-9C for simple@ietf.org; Tue, 13 Mar 2007 17:13:08 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2DLCDVB049736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Mar 2007 15:12:14 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <45F70F61.6010904@nokia.com> References: <45F7001C.7020303@nokia.com> <45F70D3A.9050403@cisco.com> <45F70F61.6010904@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6BDED0A4-1E22-4B22-AAF9-DC4F7E130BA4@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Simple] MSRP: 200 OK for chunked SEND request. Date: Tue, 13 Mar 2007 16:12:12 -0500 To: Miguel Garcia X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Cullen Jennings , Rohan Mahy , Paul Kyzivat , "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Miguel - the draft does say you can't chunk (or rechunk) responses. Where did the text mislead you into thinking the response and request framing would be related at all? They are independent uses of the same mechanism. Ben's reply came in while I was typing. If any clarification is needed, something along the lines of what he proposed sounds good to me (but please answer my above question anyhow). RjS On Mar 13, 2007, at 3:53 PM, Miguel Garcia wrote: > Paul: > > While is true that the 200 OK does not have a body, it still > contains the frame delimiter composed by the seven hyphens (-), the > transaction identifier, and the continuation flag, the same like a > request. > > Now, if you receive a chunked MSRP, i.e., one where the > continuation flag is a '+', you need to generate a 200 OK. Which > continuation flag do you put in the 200 OK? MSRP does not say > anything (at least anything that I was able to find the the draft). > > /Miguel > > Paul Kyzivat wrote: >> Miguel, >> What am I missing? What you are talking about is part of the >> *body* of the send. The response doesn't have a body at all, so it >> shouldn't have either + or $. >> Paul >> Miguel Garcia wrote: >>> Hi: >>> >>> In MSRP, a question about a 200 OK for a chunked SEND request. It >>> is not clear in the draft if the response ends with a "$" or "+" >>> sign. >>> >>> For example. If the chunked request is: >>> >>> MSRP dkei38sd SEND >>> From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >>> To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >>> Message-ID: 4564dpWd >>> Byte-Range: 1-*/8 >>> Content-Type: text/plain >>> >>> abcd >>> -------dkei38sd+ >>> >>> Then, which one is the correct response? >>> >>> Option A: Ending '+', so copied from the request. >>> >>> MSRP dkei38sd 200 OK >>> From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >>> To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >>> Message-ID: 4564dpWd >>> -------dkei38sd+ >>> >>> Option B: ending '$', so all the 200 OK responses end with a '$', >>> no matter whether they acknowledge a chunk or a complete message. >>> >>> MSRP dkei38sd 200 OK >>> From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >>> To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >>> Message-ID: 4564dpWd >>> -------dkei38sd$ >>> >>> >>> Whatever is the answer, please write it down in the draft. This >>> has already created interoperability problems. >>> >>> BR, >>> >>> Miguel >>> > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 13 17:20:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HREPV-0003SV-DL; Tue, 13 Mar 2007 17:19:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HREPU-0003SQ-3j for simple@ietf.org; Tue, 13 Mar 2007 17:19:56 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HREPQ-0006Im-6I for simple@ietf.org; Tue, 13 Mar 2007 17:19:56 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2DLISsw028538; Tue, 13 Mar 2007 23:18:51 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 23:18:28 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 23:18:28 +0200 Received: from [10.162.64.97] ([10.162.64.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 23:18:28 +0200 Message-ID: <45F71523.7080007@nokia.com> Date: Tue, 13 Mar 2007 23:18:27 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Simple] MSRP: 200 OK for chunked SEND request. References: <45F7001C.7020303@nokia.com> <45F70D3A.9050403@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2007 21:18:28.0417 (UTC) FILETIME=[24CBCB10:01C765B5] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070313231851-68696BB0-4E80A541/1674484196-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Cullen Jennings , Rohan Mahy , Paul Kyzivat , "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Ben: Yes, I think your proposal will clarify the spec. Please try to get it into the document before is RFCed. /Miguel Ben Campbell wrote: > > > On Mar 13, 2007, at 3:44 PM, Paul Kyzivat wrote: > >> Miguel, >> >> What am I missing? What you are talking about is part of the *body* of >> the send. The response doesn't have a body at all, so it shouldn't >> have either + or $. >> > > It is required by the current syntax. The presence of an end-line is not > contingent upon the presence of a body. From the abnf: > > msrp-req-or-resp = msrp-request / msrp-response > msrp-request = req-start headers [content-stuff] end-line > msrp-response = resp-start headers end-line > > [...] > > end-line = "-------" transact-id continuation-flag CRLF > continuation-flag = "+" / "$" / "#" > > The whole point was to be able to use the same framing mechanism for > requests and responses. One interpretation would be that it really > doesn't matter what you put in a response continuation flag. We haven't > assigned it any meaning one way or another. Another would be that since > it is never chunked, the value should always be "$". > > The value of the continuation flag in a response is not in any way > connected to that of the associated request. Perhaps an auth-48 change > on the order of "the sender of a response MUSt always use a $, but the > recipient of the response MUST NOT care. > > > > > >> Paul >> >> Miguel Garcia wrote: >>> Hi: >>> In MSRP, a question about a 200 OK for a chunked SEND request. It is >>> not clear in the draft if the response ends with a "$" or "+" sign. >>> For example. If the chunked request is: >>> MSRP dkei38sd SEND >>> From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >>> To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >>> Message-ID: 4564dpWd >>> Byte-Range: 1-*/8 >>> Content-Type: text/plain >>> abcd >>> -------dkei38sd+ >>> Then, which one is the correct response? >>> Option A: Ending '+', so copied from the request. >>> MSRP dkei38sd 200 OK >>> From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >>> To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >>> Message-ID: 4564dpWd >>> -------dkei38sd+ >>> Option B: ending '$', so all the 200 OK responses end with a '$', no >>> matter whether they acknowledge a chunk or a complete message. >>> MSRP dkei38sd 200 OK >>> From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >>> To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >>> Message-ID: 4564dpWd >>> -------dkei38sd$ >>> Whatever is the answer, please write it down in the draft. This has >>> already created interoperability problems. >>> BR, >>> Miguel > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 13 17:20:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HREQG-0003YI-7B; Tue, 13 Mar 2007 17:20:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HREQE-0003Xw-5a for simple@ietf.org; Tue, 13 Mar 2007 17:20:42 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HREQC-0006QO-Rq for simple@ietf.org; Tue, 13 Mar 2007 17:20:42 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Mar 2007 17:20:05 -0400 X-IronPort-AV: i="4.14,280,1170651600"; d="scan'208"; a="54689357:sNHT10411686542" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2DLJtNg021872; Tue, 13 Mar 2007 17:19:55 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2DLJaZZ011928; Tue, 13 Mar 2007 21:19:50 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 17:19:29 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 17:19:29 -0400 Message-ID: <45F71560.9000805@cisco.com> Date: Tue, 13 Mar 2007 17:19:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Simple] MSRP: 200 OK for chunked SEND request. References: <45F7001C.7020303@nokia.com> <45F70D3A.9050403@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2007 21:19:29.0088 (UTC) FILETIME=[48F57400:01C765B5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2798; t=1173820795; x=1174684795; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20MSRP=3A=20200=20OK=20for=20chunked=20SEND= 20request. |Sender:=20 |To:=20Ben=20Campbell=20; bh=EAjpcQFAk0rbyyr1fUHxNd3m8b9ayTQvonGLiOw9P4Y=; b=QFCj0o6bY49J7iGQ36Ms1ZtQiCMxL3br5d4gGncel/tVAA9/x/4/g0wx+tRQVbIRW5a1vCHo gCOKndHbwJiEflVNqYC7hkTuUKpgoVXteRminvxqZCvH+0/PwoTT+Qt0; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Miguel Garcia , Cullen Jennings , "'simple@ietf.org'" , Rohan Mahy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Sorry. That will teach me to reply without first refreshing my memory. Paul Ben Campbell wrote: > > > On Mar 13, 2007, at 3:44 PM, Paul Kyzivat wrote: > >> Miguel, >> >> What am I missing? What you are talking about is part of the *body* of >> the send. The response doesn't have a body at all, so it shouldn't >> have either + or $. >> > > It is required by the current syntax. The presence of an end-line is not > contingent upon the presence of a body. From the abnf: > > msrp-req-or-resp = msrp-request / msrp-response > msrp-request = req-start headers [content-stuff] end-line > msrp-response = resp-start headers end-line > > [...] > > end-line = "-------" transact-id continuation-flag CRLF > continuation-flag = "+" / "$" / "#" > > The whole point was to be able to use the same framing mechanism for > requests and responses. One interpretation would be that it really > doesn't matter what you put in a response continuation flag. We haven't > assigned it any meaning one way or another. Another would be that since > it is never chunked, the value should always be "$". > > The value of the continuation flag in a response is not in any way > connected to that of the associated request. Perhaps an auth-48 change > on the order of "the sender of a response MUSt always use a $, but the > recipient of the response MUST NOT care. > > > > > >> Paul >> >> Miguel Garcia wrote: >>> Hi: >>> In MSRP, a question about a 200 OK for a chunked SEND request. It is >>> not clear in the draft if the response ends with a "$" or "+" sign. >>> For example. If the chunked request is: >>> MSRP dkei38sd SEND >>> From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >>> To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >>> Message-ID: 4564dpWd >>> Byte-Range: 1-*/8 >>> Content-Type: text/plain >>> abcd >>> -------dkei38sd+ >>> Then, which one is the correct response? >>> Option A: Ending '+', so copied from the request. >>> MSRP dkei38sd 200 OK >>> From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >>> To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >>> Message-ID: 4564dpWd >>> -------dkei38sd+ >>> Option B: ending '$', so all the 200 OK responses end with a '$', no >>> matter whether they acknowledge a chunk or a complete message. >>> MSRP dkei38sd 200 OK >>> From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >>> To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >>> Message-ID: 4564dpWd >>> -------dkei38sd$ >>> Whatever is the answer, please write it down in the draft. This has >>> already created interoperability problems. >>> BR, >>> Miguel > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 13 17:23:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRESb-0004A4-Ag; Tue, 13 Mar 2007 17:23:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRESZ-00049f-PZ for simple@ietf.org; Tue, 13 Mar 2007 17:23:07 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRESY-0007Mj-8c for simple@ietf.org; Tue, 13 Mar 2007 17:23:07 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2DLLq8Q023855; Tue, 13 Mar 2007 23:22:12 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 23:22:08 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 23:22:03 +0200 Received: from [10.162.64.97] ([10.162.64.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 23:22:02 +0200 Message-ID: <45F715F9.3090100@nokia.com> Date: Tue, 13 Mar 2007 23:22:01 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Simple] MSRP: 200 OK for chunked SEND request. References: <45F7001C.7020303@nokia.com> <45F70D3A.9050403@cisco.com> <45F70F61.6010904@nokia.com> <6BDED0A4-1E22-4B22-AAF9-DC4F7E130BA4@nostrum.com> In-Reply-To: <6BDED0A4-1E22-4B22-AAF9-DC4F7E130BA4@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2007 21:22:02.0989 (UTC) FILETIME=[A4B0E1D0:01C765B5] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070313232212-5C8CABB0-3AF2F0C9/1674528379-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: Cullen Jennings , Rohan Mahy , Paul Kyzivat , "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Robert: Inline comments. Robert Sparks wrote: > Miguel - the draft does say you can't chunk (or rechunk) responses. Agreed, this is not an issue. It is clear that responses can't be chunked. > > Where did the text mislead you into thinking the response and request > framing would be related at all? They are independent uses of the same > mechanism. Well, that is the problem, I wasn't able to find any text that would make me lean towards one or the other side. I was even looking for an example, but didn't find it either. > > Ben's reply came in while I was typing. If any clarification is needed, > something > along the lines of what he proposed sounds good to me (but please answer > my above question anyhow). I agree with Ben's answers. This would be the required clarification. /Miguel > > RjS > > > On Mar 13, 2007, at 3:53 PM, Miguel Garcia wrote: > >> Paul: >> >> While is true that the 200 OK does not have a body, it still contains >> the frame delimiter composed by the seven hyphens (-), the transaction >> identifier, and the continuation flag, the same like a request. >> >> Now, if you receive a chunked MSRP, i.e., one where the continuation >> flag is a '+', you need to generate a 200 OK. Which continuation flag >> do you put in the 200 OK? MSRP does not say anything (at least >> anything that I was able to find the the draft). >> >> /Miguel >> >> Paul Kyzivat wrote: >>> Miguel, >>> What am I missing? What you are talking about is part of the *body* >>> of the send. The response doesn't have a body at all, so it shouldn't >>> have either + or $. >>> Paul >>> Miguel Garcia wrote: >>>> Hi: >>>> >>>> In MSRP, a question about a 200 OK for a chunked SEND request. It is >>>> not clear in the draft if the response ends with a "$" or "+" sign. >>>> >>>> For example. If the chunked request is: >>>> >>>> MSRP dkei38sd SEND >>>> From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >>>> To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >>>> Message-ID: 4564dpWd >>>> Byte-Range: 1-*/8 >>>> Content-Type: text/plain >>>> >>>> abcd >>>> -------dkei38sd+ >>>> >>>> Then, which one is the correct response? >>>> >>>> Option A: Ending '+', so copied from the request. >>>> >>>> MSRP dkei38sd 200 OK >>>> From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >>>> To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >>>> Message-ID: 4564dpWd >>>> -------dkei38sd+ >>>> >>>> Option B: ending '$', so all the 200 OK responses end with a '$', no >>>> matter whether they acknowledge a chunk or a complete message. >>>> >>>> MSRP dkei38sd 200 OK >>>> From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp >>>> To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp >>>> Message-ID: 4564dpWd >>>> -------dkei38sd$ >>>> >>>> >>>> Whatever is the answer, please write it down in the draft. This has >>>> already created interoperability problems. >>>> >>>> BR, >>>> >>>> Miguel >>>> >> >> --Miguel A. Garcia tel:+358-50-4804586 >> Nokia Research Center Helsinki, Finland >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 14 06:57:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRR9c-0002kn-A8; Wed, 14 Mar 2007 06:56:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRR9a-0002ki-Rg for simple@ietf.org; Wed, 14 Mar 2007 06:56:22 -0400 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRR9Z-0003W7-C4 for simple@ietf.org; Wed, 14 Mar 2007 06:56:22 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id l2EAuK4U185760 for ; Wed, 14 Mar 2007 10:56:20 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l2EAuKEY1224752 for ; Wed, 14 Mar 2007 11:56:20 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l2EAuJ2Y003916 for ; Wed, 14 Mar 2007 11:56:19 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l2EAuJ44003913 for ; Wed, 14 Mar 2007 11:56:19 +0100 To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Wed, 14 Mar 2007 12:56:18 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 14/03/2007 12:56:19, Serialize complete at 14/03/2007 12:56:19 X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Simple] Publish from different source of same tuple ID X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0240278575==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0240278575== Content-Type: multipart/alternative; boundary="=_alternative 003C3F44C225729E_=" This is a multipart message in MIME format. --=_alternative 003C3F44C225729E_= Content-Type: text/plain; charset="US-ASCII" Assuming a publish of tuples IDs: 1,2,3 and then another initial publish of tuples IDs: 1,7,8. Assuming that the first publish have not expired yet. What should happen in the ESC? * Possibility 1 - Forget the first publish and regard only the last publish. * Possibility 2 - The second publish masks the first publish and is the relevant one. If the latter expires and the previous one has not expired yet, the ESC returns to the previous one. * Possibility 3 - The aggregated document will contain: 1 (new), 2, 3,, 7, 8 Other possibilities? Thanks --Avshalom --=_alternative 003C3F44C225729E_= Content-Type: text/html; charset="US-ASCII"
Assuming a publish of tuples IDs: 1,2,3 and then another
initial publish of tuples IDs: 1,7,8.

Assuming that the first publish have not expired yet.

What should happen in the ESC?

* Possibility 1 - Forget the first publish and regard only the
  last publish.

* Possibility 2 - The second publish masks the first publish and is
  the relevant one. If the latter expires and the previous one has
  not expired yet, the ESC returns to the previous one.

* Possibility 3 - The aggregated document will contain:
  1 (new), 2, 3,, 7, 8

Other possibilities?

Thanks
--Avshalom


 --=_alternative 003C3F44C225729E_=-- --===============0240278575== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0240278575==-- From simple-bounces@ietf.org Mon Mar 19 08:58:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTHPZ-0006RL-DW; Mon, 19 Mar 2007 08:56:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTHPY-0006RC-E1 for simple@ietf.org; Mon, 19 Mar 2007 08:56:28 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTHPW-0008Lu-Vu for simple@ietf.org; Mon, 19 Mar 2007 08:56:28 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2JCu1rJ010562; Mon, 19 Mar 2007 14:56:20 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 14:56:03 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 14:56:02 +0200 Received: from [10.162.253.231] (essapo-nirac253231.europe.nokia.com [10.162.253.231]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2JCu1AL011280; Mon, 19 Mar 2007 14:56:01 +0200 Message-ID: <45FE8860.8050106@nokia.com> Date: Mon, 19 Mar 2007 13:56:00 +0100 From: Aki Niemi User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: ext Avshalom Houri Subject: Re: [Simple] Publish from different source of same tuple ID References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2007 12:56:02.0962 (UTC) FILETIME=[F32EE720:01C76A25] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070319145620-290F3BB0-7848BCC3/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org ext Avshalom Houri wrote: > Assuming a publish of tuples IDs: 1,2,3 and then another > initial publish of tuples IDs: 1,7,8. > > Assuming that the first publish have not expired yet. > > What should happen in the ESC? > > * Possibility 1 - Forget the first publish and regard only the > last publish. > > * Possibility 2 - The second publish masks the first publish and is > the relevant one. If the latter expires and the previous one has > not expired yet, the ESC returns to the previous one. > > * Possibility 3 - The aggregated document will contain: > 1 (new), 2, 3,, 7, 8 One clarifying question first. Is the collision intentional or accidental here? If it's intentional, I would go with approach #3. But I would also be interested to hear how real-life systems are intending to handle the situation. Currently, all the standard (PUBLISH method) says is how you publish the documents, and the rest is left to the compositor, which at this point is a black box. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 19 09:06:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTHYR-0003f4-1E; Mon, 19 Mar 2007 09:05:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTHYO-0003eu-Vt for simple@ietf.org; Mon, 19 Mar 2007 09:05:36 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTHYM-0001db-KQ for simple@ietf.org; Mon, 19 Mar 2007 09:05:36 -0400 Received: from [10.0.0.210] (dhcp-4009.ietf68.org [130.129.64.9]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2JD5Uuj092770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2007 07:05:33 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <45FE8860.8050106@nokia.com> References: <45FE8860.8050106@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Simple] Publish from different source of same tuple ID Date: Mon, 19 Mar 2007 14:05:27 +0100 To: Aki Niemi X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 130.129.64.9 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ext Avshalom Houri , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Let me state what I think Aki's pointing to more strongly: There are many many possibilities here. You're talking about composition policies, and those are arbitrary. For what you propose with (3). It's been awhile since I looked hard at this, but this is what my memory is telling me: The uniqueness of tuple-ids is scoped to the source of the information. It is not global uniqueness. In the scope of an entity tag, the publisher must keep the tuple-ids consistent (3390 section 10.4). Outside of the scope of that tag (the new initial publish from that source or somewhere else), an entirely different set of ids can be used. There is some pressure on a new initial publish coming from the same source to be consistent with its tuple ids that you can derive from 3863, but IIRC you can only state this as a "good idea". Further, the tuple ids coming out of a compositor do not have to relate in any way to the tuple ids going into the compositor. The compositor just has to be consistent with the ids it generates within the scope of the etag. So, for 3 below, in particular, if the second publish didn't come from the same source, you don't want to be interpreting the 1's from each document to mean the same thing. RjS On Mar 19, 2007, at 1:56 PM, Aki Niemi wrote: > > ext Avshalom Houri wrote: >> Assuming a publish of tuples IDs: 1,2,3 and then another >> initial publish of tuples IDs: 1,7,8. >> >> Assuming that the first publish have not expired yet. >> >> What should happen in the ESC? >> >> * Possibility 1 - Forget the first publish and regard only the >> last publish. >> >> * Possibility 2 - The second publish masks the first publish and is >> the relevant one. If the latter expires and the previous one has >> not expired yet, the ESC returns to the previous one. >> >> * Possibility 3 - The aggregated document will contain: >> 1 (new), 2, 3,, 7, 8 > > One clarifying question first. Is the collision intentional or > accidental here? > > If it's intentional, I would go with approach #3. But I would also be > interested to hear how real-life systems are intending to handle the > situation. Currently, all the standard (PUBLISH method) says is how > you > publish the documents, and the rest is left to the compositor, > which at > this point is a black box. > > Cheers, > Aki > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 21 04:22:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTw50-0003qW-2g; Wed, 21 Mar 2007 04:21:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTw4y-0003qA-Gp for simple@ietf.org; Wed, 21 Mar 2007 04:21:56 -0400 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTw4s-0007zw-55 for simple@ietf.org; Wed, 21 Mar 2007 04:21:55 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id l2L8Lj9g127826 for ; Wed, 21 Mar 2007 08:21:45 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l2L8LjHS2150638 for ; Wed, 21 Mar 2007 09:21:45 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l2L8Lj4U024027 for ; Wed, 21 Mar 2007 09:21:45 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l2L8LjrF024022; Wed, 21 Mar 2007 09:21:45 +0100 In-Reply-To: To: Aki Niemi , Robert Sparks Subject: Re: [Simple] Publish from different source of same tuple ID MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Wed, 21 Mar 2007 10:21:45 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 21/03/2007 10:21:44, Serialize complete at 21/03/2007 10:21:44 X-Spam-Score: 0.1 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1314695550==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1314695550== Content-Type: multipart/alternative; boundary="=_alternative 002E18DAC22572A5_=" This is a multipart message in MIME format. --=_alternative 002E18DAC22572A5_= Content-Type: text/plain; charset="US-ASCII" Robert Sparks wrote on 19/03/2007 15:05:27: > Let me state what I think Aki's pointing to more strongly: > > There are many many possibilities here. You're talking about > composition policies, > and those are arbitrary. > > For what you propose with (3). It's been awhile since I looked > hard at this, but this is what my memory is telling me: > > The uniqueness of tuple-ids is scoped to the source of the information. > It is not global uniqueness. In the scope of an entity tag, the > publisher > must keep the tuple-ids consistent (3390 section 10.4). Outside of the > scope of that tag (the new initial publish from that source or somewhere > else), an entirely different set of ids can be used. There is some > pressure > on a new initial publish coming from the same source to be consistent > with its tuple ids that you can derive from 3863, but IIRC you can only > state this as a "good idea". RFC 3903 say that but RFC 3863 4.1.2 says: The element MUST contain an 'id' attribute which is used to distinguish this tuple from other tuples in the same PRESENTITY. The value of an 'id' attribute MUST be unique within 'id' attribute values of other tuples for the same PRESENTITY. An 'id' value is used by applications processing the presence document to identify the corresponding tuple in the previously acquired PRESENCE INFORMATION of the same PRESENTITY. The value of the 'id' attribute is an arbitrary string, and has no significance beyond providing a means to distinguish values, as noted above. Seems as though there is a contradiction between 3903 and 3863. > > Further, the tuple ids coming out of a compositor do not have to > relate in any > way to the tuple ids going into the compositor. The compositor just has > to be consistent with the ids it generates within the scope of the etag. > > So, for 3 below, in particular, if the second publish didn't come > from the same > source, you don't want to be interpreting the 1's from each document > to mean > the same thing. The problem is that the compositor does not know weather the new publish is coming from the same source (device crashed) or from a different source. Remapping the IDs can be a way to solve the presumed contradiction between 3903 and 3863. > > RjS > > On Mar 19, 2007, at 1:56 PM, Aki Niemi wrote: > > > > > ext Avshalom Houri wrote: > >> Assuming a publish of tuples IDs: 1,2,3 and then another > >> initial publish of tuples IDs: 1,7,8. > >> > >> Assuming that the first publish have not expired yet. > >> > >> What should happen in the ESC? > >> > >> * Possibility 1 - Forget the first publish and regard only the > >> last publish. > >> > >> * Possibility 2 - The second publish masks the first publish and is > >> the relevant one. If the latter expires and the previous one has > >> not expired yet, the ESC returns to the previous one. > >> > >> * Possibility 3 - The aggregated document will contain: > >> 1 (new), 2, 3,, 7, 8 > > > > One clarifying question first. Is the collision intentional or > > accidental here? > > > > If it's intentional, I would go with approach #3. But I would also be > > interested to hear how real-life systems are intending to handle the > > situation. Currently, all the standard (PUBLISH method) says is how > > you > > publish the documents, and the rest is left to the compositor, > > which at > > this point is a black box. It is not possible to know if the second publish is coming from a different device or from the same device that has crashed and has lost the entity tag. Seems as though the fact that composition is open may create a lot of interop issues. With one compositor certain presence doc will be created, with a different compositor another presence doc may be created. Not sure that it is an acute problem but in deployments people may not like this situation. > > > > Cheers, > > Aki > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple --=_alternative 002E18DAC22572A5_= Content-Type: text/html; charset="US-ASCII"

Robert Sparks <rjsparks@nostrum.com> wrote on 19/03/2007 15:05:27:

> Let me state what I think Aki's pointing to more strongly:
>
> There are many many possibilities here. You're talking about  
> composition policies,
> and those are arbitrary.
>
> For what you propose with (3). It's been awhile since I looked
> hard at this, but this is what my memory is telling me:
>
> The uniqueness of tuple-ids is scoped to the source of the information.
> It is not global uniqueness. In the scope of an entity tag, the  
> publisher
> must keep the tuple-ids consistent  (3390 section 10.4). Outside of the
> scope of that tag (the new initial publish from that source or somewhere
> else), an entirely different set of ids can be used. There is some  
> pressure
> on a new initial publish coming from the same source to be consistent
> with its tuple ids that you can derive from 3863, but IIRC you can only
> state this as a "good idea".
RFC 3903 say that but RFC 3863 4.1.2 says:


   The <tuple> element MUST contain an 'id' attribute which is used to
   distinguish this tuple from other tuples in the same PRESENTITY.  The
   value of an 'id' attribute MUST be unique within 'id' attribute
   values of other tuples for the same PRESENTITY.  An 'id' value is
   used by applications processing the presence document to identify the
   corresponding tuple in the previously acquired PRESENCE INFORMATION
   of the same PRESENTITY.  The value of the 'id' attribute is an
   arbitrary string, and has no significance beyond providing a means to
   distinguish <tuple> values, as noted above.

Seems as though there is a contradiction between 3903 and 3863.

>
> Further, the tuple ids coming out of a compositor do not have to  
> relate in any
> way to the tuple ids going into the compositor. The compositor just has
> to be consistent with the ids it generates within the scope of the etag.
>
> So, for 3 below, in particular, if the second publish didn't come  
> from the same
> source, you don't want to be interpreting the 1's from each document  
> to mean
> the same thing.

The problem is that the compositor does not know weather the new publish is
coming from the same source (device crashed) or from a different source.
Remapping the IDs can be a way to solve the presumed contradiction between
3903 and 3863.

>
> RjS
>
> On Mar 19, 2007, at 1:56 PM, Aki Niemi wrote:
>
> >
> > ext Avshalom Houri wrote:
> >> Assuming a publish of tuples IDs: 1,2,3 and then another
> >> initial publish of tuples IDs: 1,7,8.
> >>
> >> Assuming that the first publish have not expired yet.
> >>
> >> What should happen in the ESC?
> >>
> >> * Possibility 1 - Forget the first publish and regard only the
> >>   last publish.
> >>
> >> * Possibility 2 - The second publish masks the first publish and is
> >>   the relevant one. If the latter expires and the previous one has
> >>   not expired yet, the ESC returns to the previous one.
> >>
> >> * Possibility 3 - The aggregated document will contain:
> >>   1 (new), 2, 3,, 7, 8
> >
> > One clarifying question first. Is the collision intentional or
> > accidental here?
> >
> > If it's intentional, I would go with approach #3. But I would also be
> > interested to hear how real-life systems are intending to handle the
> > situation. Currently, all the standard (PUBLISH method) says is how  
> > you
> > publish the documents, and the rest is left to the compositor,  
> > which at
> > this point is a black box.
It is not possible to know if the second publish is coming from
a different device or from the same device that has crashed and has lost
the entity tag.
Seems as though the fact that composition is open may create a lot of interop issues.
With one compositor certain presence doc will be created, with a different compositor
another presence doc may be created. Not sure that it is an acute problem but in
deployments people may not like this situation.
> >
> > Cheers,
> > Aki
> >
> > _______________________________________________
> > Simple mailing list
> > Simple@ietf.org
> > https://www1.ietf.org/mailman/listinfo/simple
>
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
 --=_alternative 002E18DAC22572A5_=-- --===============1314695550== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1314695550==-- From simple-bounces@ietf.org Wed Mar 21 10:51:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU28e-00046V-HU; Wed, 21 Mar 2007 10:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU28Z-00044p-RZ; Wed, 21 Mar 2007 10:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU28Y-0005S9-GB; Wed, 21 Mar 2007 10:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 62A1126E33; Wed, 21 Mar 2007 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HU28Y-0007Wv-9M; Wed, 21 Mar 2007 10:50:02 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Wed, 21 Mar 2007 10:50:02 -0400 X-Spam-Score: -2.3 (--) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Robert Sparks , simple@ietf.org Subject: [Simple] WG Action: RECHARTER: SIP for Instant Messaging and Presence Leveraging Extensions (simple) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The SIP for Instant Messaging and Presence Leveraging Extensions (simple) working group in the Real-time Applications and Infrastructure Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. +++ SIP for Instant Messaging and Presence Leveraging Extensions (simple) ====================================================================== Current Status: Active Working Group Chair(s): Robert Sparks Hisham Khartabil Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Jon Peterson Technical Advisor(s): Jon Peterson Mailing Lists: General Discussion: simple@ietf.org To Subscribe: simple-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/simple/index.html Description of Working Group: This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compliant to the requirements for IM outlined in RFC 2779 (including the security and privacy requirements there) and in the Common Profile for Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard. This group has completed the majority of its primary goals and will focus on the remaining tasks documented here and concluding. Any proposed new work will require a recharter. The primary remaining work of this group will be to complete: 1. The MSRP proposed standard mechanism for transporting sessions of messages initiated using the SIP, compliant to the requirments of RFC 2779, CPIM and BCP 41. 2. The XCAP framework for representing and carrying configuration and policy information in SIMPLE systems. 3. A mechanism for representing partial changes (patches) to XML documents and extensions to the SIMPLE publication and notification mechanisms to convey these partial changes. 4. A mechanism for initiating and managing Instant Message group chat. 5. An annotated overview of the SIMPLE protocol definition documents. Any SIP extensions proposed in the course of this development will, after a last call process, be transferred to the SIP WG for consideration as formal SIP extensions. Any mechanisms created for managing Instant Message group chat are intended to provide a bridge to the conferencing protocols that will be defined in XCON. They will be limited in scope to address only simple Instant Message chat with nicknames and will not attempt to address complex conferencing concepts such as sidebars. Their design must anticipate operating in conjunction with the conferencing protocols XCON is working towards. The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group, and then use them here. Goals and Milestones: Done Submission of event package for presence to IESG for publication as Proposed Standard Done Submission of watcher information drafts to IESG for publication as Proposed Standards Done Submission of proposed event list mechanism to the SIP working group Done Submission of requirements for event publishing to the IESG for publication as Proposed Standard Done Submission of proposed mechanism for event publishing to the SIP working group Done Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard Done Submission of base XCAP draft to IESG for publication as Proposed Standard Done Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard Done Submission of XCAP usage for manipulation of presence document content Done Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard Done Submission of Filtering mechanisms to IESG for publication as a Proposed Standard Done Submission of instant messaging session draft to IESG for publication as a Proposed Standard Done Submission of instant messaging session relay drafts to IESG for publication as Proposed Standards Done Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard Feb 2007 Submission of an Instant Message Disposition Notification mechanism to the IESG for publication as a Proposed Standard Feb 2007 Submission of XCAP event package to IESG or appropriate working group targeting publication as Proposed Standard Feb 2007 Submission of proposed mechanisms meeting the advanced messaging requirements to the IESG or appropriate working group Mar 2007 Submission of a performance and scalability analysis of the SIMPLE presence mechanisms to the IESG for publication as Informational Jun 2007 Submission of SIMPLE protocol annotated overview draft to IESG for publication as Informational Aug 2007 Submission of proposed mechanisms for initiating and managing Instant Message group chat to the IESG for publication as Proposed Standard Aug 2007 Conclusion of SIMPLE _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 22 05:43:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJoM-0000cu-7R; Thu, 22 Mar 2007 05:42:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJoL-0000YC-3j for simple@ietf.org; Thu, 22 Mar 2007 05:42:21 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJoH-0005iQ-I8 for simple@ietf.org; Thu, 22 Mar 2007 05:42:21 -0400 Received: from [130.129.16.51] (dhcp-1033.ietf68.org [130.129.16.51]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l2M9g8pr081329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 22 Mar 2007 04:42:14 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <6981A4FA-59B8-497A-87AB-CF7CCC5C7219@estacado.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Simple WG From: Ben Campbell Date: Thu, 22 Mar 2007 10:42:02 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Simple] Comments on interdomain scaling analysis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, Here are some comments on draft-ietf-simple-interdomain-scaling- analysis-00.txt. One big concern is this draft claims to be standards track. That seems incorrect. The only milestone I see in the new charter that this could fall under is for an informational RFC. I have a few nits on the model for the non optimized model, and a concern about the approach for the optimized models. First the approach concern: I'm starting to be uncomfortable with the idea of this draft talking about optimizations at all. We're doing sort of a backwards strawman here--putting up a potential optimization that has not been thought through by the work group as a whole, then assigning a value to it through optimization. This risks sending us down some false trails, or going down rat-holes arguing about the optimizations in the draft. it also risks getting us prematurely attached to a particular optimization, which could later turn out to be technically unfeasible. Bottom line is, I think discussion of particular optimizations should be treated in a separate document than the analysis of the status quo. Analysis model for non-optimized SIMPLE: I think there are at least 2 errors and two areas that are likely to be misinterpreted. Errors: 1) I think we have one too many rounds of subscription refreshes in the 8 hour period. Looking at a timeline, there should be an initial subscription at t=0, one refresh at each of t=1 through t=7, and one tear-down at t=8. That's 1 initiation, 1 teardown, and _7_ refreshes, not 8. 2) The bandwidth calculation multiplies the number of messages times a size factor that includes an assumed request and response for each. But we already accounted for responses in the previous calculations on which this depends. Doing it here again causes a false doubling. (Not really quite double, since we assume a different size for responses than requests.) Areas that should be clarified: 1) There are several lines labeled in the form of /200 OK. That makes me think we are counting transactions. But in fact, we are counting messages. I think messages are the appropriate choice for this analysis, so it might make more sense to have a line item for each request type and a separate line for the associated responses. A misinterpretation here will make people think the numbers are twice as bad as they really are. 2) The population is listed as 20,000. But there is a buried assumption in the calculation that one domain has 20K people, and the peer domain also has 20K people, and the interdomain link is carrying traffic from all 40K people. People are likely to misinterpret this so that the numbers appear twice as bad as they really are. I suggest just acknowledging the population is 40K and removing the multiplier. Keep in mind that if people fall into _both_ of this traps, they will misinterpret the numbers by a factor of 4. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 22 05:57:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUK2I-00089x-5p; Thu, 22 Mar 2007 05:56:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUK2G-00088z-0N for simple@ietf.org; Thu, 22 Mar 2007 05:56:44 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUK25-00022S-0x for simple@ietf.org; Thu, 22 Mar 2007 05:56:43 -0400 Received: from [130.129.22.41] (dhcp-1629.ietf68.org [130.129.22.41]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2M9tPYF041615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 03:55:27 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4602528C.2060106@nostrum.com> Date: Thu, 22 Mar 2007 10:55:24 +0100 From: Adam Roach User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Vishal Kumar Singh Subject: Re: [Simple] Vehicle Info Event Package Draft References: <45F20003.3070404@cs.columbia.edu> In-Reply-To: <45F20003.3070404@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.22.41 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org RFC 3265 includes text intended to guide potential event package designers with regards to what *kind* of things are appropriate for SIP event packages, and what *kind* of things are not. Section 4.4 gives two specific examples meant to illustrate types of information that are far outside the realm of appropriateness. Specifically: When designing an event package using the methods described in this document for event notification, it is important to consider: is SIP an appropriate mechanism for the problem set? Is SIP being selected because of some unique feature provided by the protocol (e.g., user mobility), or merely because "it can be done?" If you find yourself defining event packages for notifications related to, for example, network management or the temperature inside your car's engine, you may want to reconsider your selection of protocols. Given the foregoing, I am a bit perplexed by the proposal on the table, which seems to have taken this section of RFC 3265 as a challenge rather than as guidance: 20 /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 22 06:30:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUKY7-0003jA-Vw; Thu, 22 Mar 2007 06:29:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUKXo-0003cn-Nh for simple@ietf.org; Thu, 22 Mar 2007 06:29:21 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUKXl-0004B6-VL for simple@ietf.org; Thu, 22 Mar 2007 06:29:20 -0400 Received: from [130.129.22.41] (dhcp-1629.ietf68.org [130.129.22.41]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2MATF1l043211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 04:29:16 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <46025A7B.1090108@nostrum.com> Date: Thu, 22 Mar 2007 11:29:15 +0100 From: Adam Roach User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: miguel.an.garcia@nokia.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.22.41 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "'simple@ietf.org'" Subject: [Simple] Presence dictionary for Sigcomp X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Just as a minor comment on the actual entries... From a practical perspective, just about any compression algorithm that accesses entries out of a static dictionary is going to have a break-even point around three or four characters -- meaning that any dictionary entry this size or shorter would be smaller to encode as those characters instead of a reference to a dictionary. As a consequence, I would argue that all entries in the current dictionary that are two or three characters long should be removed: they won't really help anyone's compression ratios, and they server to make the dictionary larger (which has some obvious disadvantages). For what it's worth, this reduces the dictionary from 403 entries down to 368 entries, and from 3641 bytes to 3480 bytes. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 22 07:58:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HULuy-0003Ie-JZ; Thu, 22 Mar 2007 07:57:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HULuw-0003D4-RQ for simple@ietf.org; Thu, 22 Mar 2007 07:57:18 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HULuv-0001Ts-C8 for simple@ietf.org; Thu, 22 Mar 2007 07:57:18 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2MBurIT017820; Thu, 22 Mar 2007 13:57:15 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 13:56:51 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 13:56:51 +0200 Received: from [10.162.88.48] ([10.162.88.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 13:56:51 +0200 Message-ID: <46026F02.8070604@nokia.com> Date: Thu, 22 Mar 2007 13:56:50 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Adam Roach References: <46025A7B.1090108@nostrum.com> In-Reply-To: <46025A7B.1090108@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Mar 2007 11:56:51.0548 (UTC) FILETIME=[2D9D61C0:01C76C79] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "'simple@ietf.org'" Subject: [Simple] Re: Presence dictionary for Sigcomp X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Good advice, thanks. Next version of the draft will follow your suggestion. /Miguel Adam Roach wrote: > Just as a minor comment on the actual entries... > > From a practical perspective, just about any compression algorithm that > accesses entries out of a static dictionary is going to have a > break-even point around three or four characters -- meaning that any > dictionary entry this size or shorter would be smaller to encode as > those characters instead of a reference to a dictionary. > > As a consequence, I would argue that all entries in the current > dictionary that are two or three characters long should be removed: they > won't really help anyone's compression ratios, and they server to make > the dictionary larger (which has some obvious disadvantages). > > For what it's worth, this reduces the dictionary from 403 entries down > to 368 entries, and from 3641 bytes to 3480 bytes. > > /a -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 22 10:05:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUNue-0008Ha-36; Thu, 22 Mar 2007 10:05:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUNuc-0008H4-HY for simple@ietf.org; Thu, 22 Mar 2007 10:05:06 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUNua-0003Zu-Nz for simple@ietf.org; Thu, 22 Mar 2007 10:05:06 -0400 Received: from [130.129.18.89] (dhcp-1259.ietf68.org [130.129.18.89]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l2MDB6V2015160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Mar 2007 07:11:08 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <96A8A38F-2232-4FA6-9185-4D4D04D534D3@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Thu, 22 Mar 2007 15:04:45 +0100 To: "Robert Sparks " X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Cc: simple@ietf.org Subject: [Simple] SIMPLE notes 68 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Raw Notes on SIMPLE at IETF 68 reported by Dean Willis Topic: Status lead: Robert Sparks Slides presented Issue: Advanced Messaging Draft: Should we revive or let expire? Discussion indicated might depend on following conversation. Issue: OMA LS on XCAP DIFF: Meeting held yesterday. We understand issues and are working on it. Issue: Remaining Milestones IMDN submission should occur soon. Adam Roach will edit SIMPEL Protocol Annotated Review for Chicago Question: If SIMPLE concludes this year, where would further work go? Answer: to RAI ADs or individuals as appropriate. Issue: IMDN Bug found in extension of message.cpim namespace. Corrective changes made and under review. Will submit to ISG LC if review OK. Topic: DMDM lead: Jerry Shih Slides presented OMA SIMPLE IM is based on Background based on IETF SIMPLE IM. Presentation overviewed messaging model. Questions on Read notification for Large Message Mode slide: Henry: If we don't get an error message, we presume it has been delivered, and if we did get a notification we would be aggravated. Also people often delete messages without reading them. How do you define "being read"? Answer: Delivery notification is optional and used only if desired, so won't annoy people who don't use it. Determining if a message has been read is implementation dependent. The implication is that the message has been rendered to a user interface and acted on by a user. Discussion followed broadly. Concerns about regulatory implications were raised. Noted that IMDN has a comparable capability. Further discussion deferred by order of he chair. Questions on slide Delivery Notification for Session based Deferred Messaging Ben Campbell noted that he resisted IMDN in MSRP, because we had no explored the use cases enough to understand how it needs to work. For example, the current slides talk about delivery after an MSRP session ends, which requires deliver on an alternate path and is forbidden explicitly in the current spec. It would be good to have a broader set of use cases to make sure we get this right. Miguel Garcia noted that there is value in delivery notification and/ or read notification and it should be explored, but that the use case requires clarification on when it is needed. It needs to be more session based. Noted there is a spam harvesting risk that might need to be addressed (although 200 OK may have leaked that same information). Q: do we have delayed notification, and is declining a message a UI issue? ANs: Not yet, and yes. Proposed by Dean Willis that that the OMA messaging protocol provides a session layer mechanism that spans multiple IETF protocols, and it is probably required that the OMA delivery notification mechanism operate at that same level. IETF protocols might each require a delivery notification capability, but the aggregation of this into the OMA "read" condition has to happen at an OMA layer. Topic: Presence Specific Dictionary for SIGCOMP lead: Miguel Angel Garcia-Martin Slides presented Document "mostly ready" to ship. Recently received input to remove small (less than 4 char) entries from dictionary. Help is needed in reviewing, specifically around "priorities" (probably of use) classification for strings. This might require analyzing a large body of messages in different languages and dialects for best fit, but analysis for distribution in things like PIDF might also be very useful. Poll: Who will give feedback on this draft: 5 hands presented. Question to AD: Can this progress without a WG or should it go through here? Ans: (JonP) If you can find reviewers, AD will take as AD-sponsored individual Topic: Vehicle Event Package lead: Henning Schulzrinne Slides presented Noted that US government application CAP uses XMPP for somehing very similar, but needs to be broadened. Issue: Previously, asynchronous events outside of presence and MWI have been considered out of scope. Options: 1) Not at all in IETF, 2) Use XMPP, 3) make a per-case decision by expertise, size, etc. 4) build a general-purpose asynch event mechanism using SIMPLE as a basis Discussion: There are a lot of examples of information sources like this in Public Safety arena, where much work has been done on formatting the messages but not on transporting them. Brian Rosen expressed strong interest in the work. Question: Why here and not SIPPING? And: SIPPING was too busy this week. Question (Adam Roach) We originally had explicit instruction from IESG about not doing a general subscription notification message system like TIBCO. Will we be receiving guidance from the IESG that the language in 3265 no longer applies, or does the guidance stand. Noted that the same concerns would apply to XMPP and the rest of RAI. Noted by Miguel Garcia that there are concepts in the drafts he is scheduled to present in SIPPING tomorrow that relate to this work. Avshalom Houri expressed interest in the work. Not sure where it should be done. Henning noted that the whole set of things we've built, including partials, diffs, filtering, etc are perfectly applicable. Issue: Group Management. Miguel's work includes concept of "Communities" that are similar and should be coordinated. AD Guidance: Original guidance is that SIMPLE is in support of human real-time communications. Noted also that event packages are "informational required" and do not have to be done only in SIMPLE/ SIPPING. Poll: Interest level in room is relatively high. Topic: SIMPEL Problem Statement lead: Avshalom Houri Slides presented Intro by chair: Not certain that current draft universally hits the main point for the analysis required in the charter. We will need to make some decisions about how to arrange this. Note: "Numbers" slide, 5th column is messages per 8 hour day Discussion from brian Rosen: Agreed that this shows a problem, but it would be useful to get a better handle on the size of the problem. This isn't protocol specific, it's presence-specific. Discussion from HGS: There were some papers about AT&T's network that we might could extract useful data from. But it is hard to put an upper limit on a scary number. Guidance from chair: This draft is now at the point where its model could be usefully compared to real experience. Please do so. Request from Ben Campbell: Would like to see feedback on his analysis as posted. Question from Henry Sinnreich: If you think this is the usage scenario, is this an argument that these big-load applications (like presence) should be handled in the endpoints and not the servers? Ans: maybe . . . Issue: Optimizations Comment from HGS: Google seems to be doing something like that already. The goal is reducing load, not shifting it around. Comment from Adam Roach: There are two sets of stuff here 1) existing mechanisms 2) new mechanisms for which we have not yet done an adequate requirements analysis. The document can be split along these lines. Adam would support the further optimization work. Comment from HGS: Could also have an informational on "lazy" approaches that can be implemented in today's protocols without change. Comment from Sriram: Young users often use their presence status to communicate like a broadcast message, perhaps 3-4 times per minute. This isn't true of enterprise users, o teh distribution could be very large. Topic: SIMPLE Chat draft lead: Miguel Angel Garcia-Martin Slides presented Issue: nicknames. Discussion: In other sessions, nicknames are a property of the use, not a property of the chat. Do we need to sove this or the general prolem? Adam noted that everything we do here will apply to xcon. Aki will look through xcon data model for a way to do it, and we'll have a system-wide capability. Ben noted that we have to be careful, because once the approach is in code, the feature requirement will be there forever. That will make it hard to change over. Mary asks that we make sure what we do here is NOT the general model for xcon. Adam confirms that these features will hag around, but that would not be as bad as not having the capabilities now. in his opinion the amount of work involved is relatively small. Question from Ben: Does the draft contain motivation for doing this in media stream instead of in SIP TO DO: Find this motivation and put it in draft. Comment from ben: Doing it this way will require ability to provision both focus and mixer with nickname. Comment from Brian Rosen: Ben's comment makes sense. Don't remember any discussion of this in the past. We should make this nicknaming SIP-wide. Comment from Adam: XCON does operations towards the focus, not the mixer, so may need to look at this. Comment from Aki: We previously said that if we put this stuff in teh SDP then we're negotiating both session and nickname. This requires new response codes for "nickname taken". Also not pretty to have to use a reinvite to change nicknames mid-chat. Issue: Will you work on this? Comment from Brian Rosen: Yes. Comment from Ben: Yes, and we need to analyze impact on end-to-end encryption. Comment from Henry: We must do this to be able to use SIMPEL instead of XMPP. But we need to think about how this works in a serverless environment. Comment from Brian: End-system (multicast, broadcast, many-cast) mixing can meet the serverless. Poll from chair: Do we still have consensus to keep this as a basis for a WG item to meet our charter? Ans: We have consensus on doing this work. Topic: XCON work on MSRP conferencing lead: Mary Barnes Slides presented No discussion from room. Topic: MSRP ICE lead: Aki Niemi Slides presented Intended as a replacement for MSRP relays. Current draft is a strawman intended to get discussion going. Issue; Dropping To-Path, From-Path Comment from Ben campbell. Would be a chore to change MSRP just to do the discard of To-path and From-Path as suggested. Would also like to see case where one end uses relay, one end uses ICE. Comment from Adam. Dropping them is much like dropping tags in SIP and breaking forking. Comment from Robert Sparks Comment from Hadriel Kaplan: This is probably too much of a change This raises the question: if you keep them, what do you put there? Issue: RFC 4571 framing. Why are we doing this in ice-tcp? Comment from Adam Roach: We probably need to do something different from 4571 because it has a length header and this messes up arbitrary chunking. We probably need to come up with yet another mechanism. Comment from Henry: This draft is very useful because it moves more things to the endpoints. We should do it. From chair: If you want to work on this: DO SO! Meeting closed. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 22 13:01:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUQdr-0001xQ-Fa; Thu, 22 Mar 2007 12:59:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUQdp-0001tK-Mu for simple@ietf.org; Thu, 22 Mar 2007 12:59:57 -0400 Received: from sjcc86x81.sjccnet.com ([207.86.63.81] helo=roundabout.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUQdk-0006z4-Q9 for simple@ietf.org; Thu, 22 Mar 2007 12:59:57 -0400 Received: from roundabout.local (localhost [127.0.0.1]) by roundabout.local (Postfix) with ESMTP id AD7A25F56AF; Thu, 22 Mar 2007 10:59:55 -0600 (MDT) Message-ID: <4602B60B.4000702@jabber.org> Date: Thu, 22 Mar 2007 10:59:55 -0600 From: Peter Saint-Andre Organization: XMPP Standards Foundation User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2pre) Gecko/20070116 Thunderbird/2.0b2 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Simple] Comments on interdomain scaling analysis References: <6981A4FA-59B8-497A-87AB-CF7CCC5C7219@estacado.net> In-Reply-To: <6981A4FA-59B8-497A-87AB-CF7CCC5C7219@estacado.net> Jabber-ID: stpeter@jabber.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0348849977==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0348849977== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060706050000000301040005" This is a cryptographically signed message in MIME format. --------------ms060706050000000301040005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ben Campbell wrote: > I'm starting to be uncomfortable with the idea of this draft talking > about optimizations at all. We're doing sort of a backwards strawman > here--putting up a potential optimization that has not been thought > through by the work group as a whole, then assigning a value to it > through optimization. This risks sending us down some false trails, or > going down rat-holes arguing about the optimizations in the draft. it > also risks getting us prematurely attached to a particular optimization, > which could later turn out to be technically unfeasible. > > Bottom line is, I think discussion of particular optimizations should be > treated in a separate document than the analysis of the status quo. +1. BTW I am working on a similar analysis for XMPP presence scaling. For purposes of comparison of presence technologies if for nothing else, I think it would be best for the analysis documents to analyze only, leaving discussion of improvements to other specifications. Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml --------------ms060706050000000301040005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA3MDMyMjE2NTk1NVowIwYJKoZIhvcNAQkEMRYEFM0Q9YAJCOuajAYJpJO9Nt9MazcVMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBAB6wCfFSroe2k+MXcocGZ5agWo/tlkZKSsRbjGukugdU Ad/P77DJplvfrx5qwxh1uCUK6pQBpTqJduqqpPR4VJksCg4Juz0KOfrqSMBrVxKyGQudMNGt DWt6ckUaIPTwCLI9qV80Bks4dIpQGAfaB2OFZcbLausNGViN5xsPhNATZoTCORhgSWM2MlWa PqusMl00kz7VoRREM8PobCFCvsMLIhVhA6MXJGKowB5lY2qOsKEn3A7tHwvJe5p66KMZTqxc //BUgw/isZzzPIHFdS1Xi3pm/ODiZA1m8FStBO/RSqJiZGzTlcmBHu3nDZsg2uKvQljJj2JM OQG24ZAGbZkAAAAAAAA= --------------ms060706050000000301040005-- --===============0348849977== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0348849977==-- From simple-bounces@ietf.org Thu Mar 22 16:57:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUULN-0005Gc-Mp; Thu, 22 Mar 2007 16:57:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUULM-0005GW-Pa for simple@ietf.org; Thu, 22 Mar 2007 16:57:08 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUULK-0008NM-5N for simple@ietf.org; Thu, 22 Mar 2007 16:57:08 -0400 Received: from [130.129.22.195] (dhcp-16c3.ietf68.org [130.129.22.195]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2MKv4tI008947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 22 Mar 2007 16:57:05 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <7550FCE4-3BE5-4C56-8509-2EC1C1BA2747@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: simple@ietf.org From: Henning Schulzrinne Date: Thu, 22 Mar 2007 16:57:04 -0400 X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Simple] General events list set up X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org As discussed in the SIMPLE meeting today, I've set up a mailing list to discuss the use of SIP events for general event notification, beyond the uses today (presence, call-related events). If you're interested in using event notification for things like medical alerts, emergency alerting or similar asynchronous event notification applications, you can subscribe to the list at https://lists.cs.columbia.edu/cucslists/listinfo/general-events A public archive will be available. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 23 07:42:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUi8e-0002Gx-P9; Fri, 23 Mar 2007 07:40:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUi8d-0002Gn-3w for simple@ietf.org; Fri, 23 Mar 2007 07:40:55 -0400 Received: from datnt07.tieto.com ([194.110.47.24] helo=mail2.tieto.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUi8K-0003xK-BL for simple@ietf.org; Fri, 23 Mar 2007 07:40:55 -0400 X-AuditID: c26e2f18-0000144000002078-c4-4603bc946d12 Received: from veyron.eu.tieto.com ([194.110.47.230]) by mail2.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Mar 2007 13:40:04 +0200 Received: from sagaris.eu.tieto.com ([131.207.197.143]) by veyron.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Mar 2007 13:40:20 +0200 Received: from 10.15.1.32 ([10.15.1.32]) by sagaris.eu.tieto.com ([131.207.197.143]) via Exchange Front-End Server email2.tietoenator.com ([192.176.143.12]) with Microsoft Exchange Server HTTP-DAV ; Fri, 23 Mar 2007 11:40:20 +0000 Received: from brcalnik by email2.tietoenator.com; 23 Mar 2007 12:40:52 +0100 From: Martin Hynar To: IETF WG SIMPLE Date: Fri, 23 Mar 2007 12:40:52 +0100 Message-Id: <1174650052.4309.34.camel@brcalnik> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-1.fc6) X-OriginalArrivalTime: 23 Mar 2007 11:40:20.0569 (UTC) FILETIME=[095BBC90:01C76D40] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Subject: [Simple] Pres URI X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0691405756==" Errors-To: simple-bounces@ietf.org --===============0691405756== Content-Type: multipart/alternative; boundary="=-9EuU1QExT283tC2QYjyz" --=-9EuU1QExT283tC2QYjyz Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, I have looked at the syntax of pres uri and one thing surprised me. Let me cite the ABNF: PRES-URI = "pres:" [ to ] [ headers ] to = mailbox headers = "?" header *( "&" header ) header = hname "=" hvalue hname = *uric hvalue = *uric Both "to" and "header" parts are optional, so the resulting Pres URI might have form "pres:"? Was this some intention or is it just combinatorial possibility? In addition, I am missing some use case even for existence of Pres URI, can somebody put some light on this for me? Thanks much in advance, Martin Hynar +-------------------------------------+ Martin Hynar Software Specialist TietoEnator Czech Software Center Phone: +420 597 459 713 Mobile: +420 724 432 817 E-mail: Martin.Hynar@TietoEnator.com Vystavni 292/13 CZ-709 16 Ostrava www.tietoenator.com Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. --=-9EuU1QExT283tC2QYjyz Content-Type: text/html; charset=utf-8 Hello,

I have looked at the syntax of pres uri and one thing surprised me. Let me cite the ABNF:

PRES-URI = "pres:" [ to ] [ headers ] 
   to             =  mailbox
   headers        =  "?" header *( "&" header )
   header         =  hname "=" hvalue
   hname          =  *uric
   hvalue         =  *uric


Both "to" and "header" parts are optional, so the resulting Pres URI might have form "pres:"? Was this some intention or is it just combinatorial possibility? In addition, I am missing some use case even for existence of Pres URI, can somebody put some light on this for me?

Thanks much in advance, Martin Hynar


+-------------------------------------+
  Martin Hynar
  Software Specialist

  TietoEnator
  Czech Software Center
  Phone: +420 597 459 713
  Mobile: +420 724 432 817
  E-mail: Martin.Hynar@TietoEnator.com

  Vystavni 292/13
  CZ-709 16 Ostrava

www.tietoenator.com


Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You.
--=-9EuU1QExT283tC2QYjyz-- --===============0691405756== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0691405756==-- From simple-bounces@ietf.org Sun Mar 25 13:50:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVWnG-0006F0-6H; Sun, 25 Mar 2007 13:46:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVWnD-0006Ec-JS; Sun, 25 Mar 2007 13:46:11 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HVWnB-0007L5-Kq; Sun, 25 Mar 2007 13:46:11 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm184606fb4e; Mon, 26 Mar 2007 01:56:20 +0800 Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm904601d3f6; Thr, 22 Mar 2007 07:54:35 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Thr, 22 Mar 2007 07:54:35 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU28e-00046S-EZ; Wed, 21 Mar 2007 10:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU28Z-00044p-RZ; Wed, 21 Mar 2007 10:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU28Y-0005S9-GB; Wed, 21 Mar 2007 10:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 62A1126E33; Wed, 21 Mar 2007 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HU28Y-0007Wv-9M; Wed, 21 Mar 2007 10:50:02 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Wed, 21 Mar 2007 10:50:02 -0400 X-Spam-Score: -2.3 (--) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-Spam-Score: 2.4 (++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: Robert Sparks , simple@ietf.org Subject: [Simple] WG Action: RECHARTER: SIP for Instant Messaging and Presence Leveraging Extensions (simple) X-BeenThere: simple@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The SIP for Instant Messaging and Presence Leveraging Extensions (simple) working group in the Real-time Applications and Infrastructure Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. +++ SIP for Instant Messaging and Presence Leveraging Extensions (simple) ====================================================================== Current Status: Active Working Group Chair(s): Robert Sparks Hisham Khartabil Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Jon Peterson Technical Advisor(s): Jon Peterson Mailing Lists: General Discussion: simple@ietf.org To Subscribe: simple-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/simple/index.html Description of Working Group: This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compliant to the requirements for IM outlined in RFC 2779 (including the security and privacy requirements there) and in the Common Profile for Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard. This group has completed the majority of its primary goals and will focus on the remaining tasks documented here and concluding. Any proposed new work will require a recharter. The primary remaining work of this group will be to complete: 1. The MSRP proposed standard mechanism for transporting sessions of messages initiated using the SIP, compliant to the requirments of RFC 2779, CPIM and BCP 41. 2. The XCAP framework for representing and carrying configuration and policy information in SIMPLE systems. 3. A mechanism for representing partial changes (patches) to XML documents and extensions to the SIMPLE publication and notification mechanisms to convey these partial changes. 4. A mechanism for initiating and managing Instant Message group chat. 5. An annotated overview of the SIMPLE protocol definition documents. Any SIP extensions proposed in the course of this development will, after a last call process, be transferred to the SIP WG for consideration as formal SIP extensions. Any mechanisms created for managing Instant Message group chat are intended to provide a bridge to the conferencing protocols that will be defined in XCON. They will be limited in scope to address only simple Instant Message chat with nicknames and will not attempt to address complex conferencing concepts such as sidebars. Their design must anticipate operating in conjunction with the conferencing protocols XCON is working towards. The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group, and then use them here. Goals and Milestones: Done Submission of event package for presence to IESG for publication as Proposed Standard Done Submission of watcher information drafts to IESG for publication as Proposed Standards Done Submission of proposed event list mechanism to the SIP working group Done Submission of requirements for event publishing to the IESG for publication as Proposed Standard Done Submission of proposed mechanism for event publishing to the SIP working group Done Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard Done Submission of base XCAP draft to IESG for publication as Proposed Standard Done Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard Done Submission of XCAP usage for manipulation of presence document content Done Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard Done Submission of Filtering mechanisms to IESG for publication as a Proposed Standard Done Submission of instant messaging session draft to IESG for publication as a Proposed Standard Done Submission of instant messaging session relay drafts to IESG for publication as Proposed Standards Done Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard Feb 2007 Submission of an Instant Message Disposition Notification mechanism to the IESG for publication as a Proposed Standard Feb 2007 Submission of XCAP event package to IESG or appropriate working group targeting publication as Proposed Standard Feb 2007 Submission of proposed mechanisms meeting the advanced messaging requirements to the IESG or appropriate working group Mar 2007 Submission of a performance and scalability analysis of the SIMPLE presence mechanisms to the IESG for publication as Informational Jun 2007 Submission of SIMPLE protocol annotated overview draft to IESG for publication as Informational Aug 2007 Submission of proposed mechanisms for initiating and managing Instant Message group chat to the IESG for publication as Proposed Standard Aug 2007 Conclusion of SIMPLE _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 28 17:34:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWfmB-0003pM-9v; Wed, 28 Mar 2007 17:33:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWfm6-0003mU-CC for simple@ietf.org; Wed, 28 Mar 2007 17:33:46 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWfh8-0006aW-H1 for simple@ietf.org; Wed, 28 Mar 2007 17:28:39 -0400 Received: from [172.17.1.65] ([172.17.1.65]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l2SLSZCv022338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Mar 2007 16:28:36 -0500 (CDT) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13598F70-F312-4610-B03F-D484D5C594EC@estacado.net> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Wed, 28 Mar 2007 16:28:33 -0500 To: simple@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Miguel Garcia Subject: [Simple] Volunteers to review the SIGCOMP presence dictionary X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org During the SIMPLE meeting at IETF68, we determined that Miguel's SIGCOMP Presence Dictionary draft could move forward as an AD-sponsored individual submission IF it received sufficient review. Several people raised their hands volunteering as reviewers. I would like those people, and any others who have the time to review this draft, to send an email to Miguel, copying me. Thanks! RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 28 17:35:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWfnO-0005CV-TP; Wed, 28 Mar 2007 17:35:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWfmP-0003xD-0c for simple@ietf.org; Wed, 28 Mar 2007 17:34:05 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWfb0-0005Wj-GO for simple@ietf.org; Wed, 28 Mar 2007 17:22:21 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2SLMHx5002270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 28 Mar 2007 15:22:17 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <9DABA64B-31AE-42FD-9798-61F50EECBE88@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: simple@ietf.org From: Robert Sparks Date: Wed, 28 Mar 2007 16:22:16 -0500 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 Subject: [Simple] draft minutes: SIMPLE at ietf68 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Please review as soon as possible. Send comments/corrections to the me or the list. Thanks, RjS ---------------------------------------- Minutes : SIMPLE : IETF 68 March 22, 2007 - Thursday Afternoon I Chair: Robert Sparks Notetaker: Dean Willis Summary: * MSRP has been approved. * A technical error in the IANA registration section of the IMDN draft has been identified and corrected. The document will not be re- WGLCed. Reviewers should pay special attention to this correction during IETF last call. * There was interest in discussing IMDN for MSRP messages. Some concern was expressed over the notion of "read" vs "delivered". * The Presence SIGCOMP dictionary will progress as an AD-sponsored individual submission. Several attendees volunteered to review the document. * Some interest was expressed in exploring the use of SIP Events outside the realm of real-time communications. Henning has created a list on which to start those discussions. * The new mechanism suggestions in the Interdomain Optimization Analysis draft will be removed to a separate document. The group will focus on reviewing the model and analysis in the document with the expectation that we will last call and request publication of this draft achieving the associated milestone item before the Chicago meeting. * The attendees reconfirmed accepting neimi-chat as the basis for meeting our IM chat milestone. Conversation indicated we are making progress on providing an immediate solution that will be compatible with the long term XCON solution * There was significant pushback against optimizing MSRP by dropping To-path and From-path in Aki's MSRP-ice proposal. There was interest in continuing to discuss the remainder of the document. Raw Notes ---------------------------------- Topic: Status lead: Robert Sparks Slides presented Issue: Advanced Messaging Draft: Should we revive or let expire? Discussion indicated might depend on following conversation. Issue: OMA LS on XCAP DIFF: Meeting held yesterday. We understand issues and are working on it. Issue: Remaining Milestones IMDN submission should occur soon. Adam Roach will edit SIMPLE Protocol Annotated Review for Chicago Question: If SIMPLE concludes this year, where would further work go? Answer: to RAI ADs or individuals as appropriate. Issue: IMDN Bug found in extension of cpim namespace. Corrective changes made and under review. Will submit to IESG LC if review OK. Topic: DMDN lead: Jerry Shih Slides presented OMA SIMPLE IM is based on IETF SIMPLE IM. Presentation overviewed messaging model. Questions on Read notification for Large Message Mode slide: Henry: If we don't get an error message, we presume it has been delivered, and if we did get a notification we would be aggravated. Also people often delete messages without reading them. How do you define "being read"? Answer: Delivery notification is optional and used only if desired, so won't annoy people who don't use it. Determining if a message has been read is implementation dependent. The implication is that the message has been rendered to a user interface and acted on by a user. Discussion followed broadly. Concerns about regulatory implications were raised. Noted that IMDN has a comparable capability. Further discussion deferred by order of the chair. Questions on slide Delivery Notification for Session based Deferred Messaging Ben Campbell noted that he resisted IMDN in MSRP, because we had no explored the use cases enough to understand how it needs to work. For example, the current slides talk about delivery after an MSRP session ends, which requires deliver on an alternate path and is forbidden explicitly in the current spec. It would be good to have a broader set of use cases to make sure we get this right. Miguel Garcia noted that there is value in delivery notification and/ or read notification and it should be explored, but that the use case requires clarification on when it is needed. It needs to be more session based. Noted there is a spam harvesting risk that might need to be addressed (although 200 OK may have leaked that same information). Q: do we have delayed notification, and is declining a message a UI issue? ANs: Not yet, and yes. Proposed by Dean Willis that that the OMA messaging protocol provides a session layer mechanism that spans multiple IETF protocols, and it is probably required that the OMA delivery notification mechanism operate at that same level. IETF protocols might each require a delivery notification capability, but the aggregation of this into the OMA "read" condition has to happen at an OMA layer. Topic: Presence Specific Dictionary for SIGCOMP lead: Miguel Angel Garcia-Martin Slides presented Document "mostly ready" to ship. Recently received input to remove small (less than 4 char) entries from dictionary. Help is needed in reviewing, specifically around "priorities" (probably of use) classification for strings. This might require analyzing a large body of messages in different languages and dialects for best fit, but analysis for distribution in things like PIDF might also be very useful. Poll: Who will give feedback on this draft: 5 hands presented. Question to AD: Can this progress without a WG or should it go through here? Ans: (JonP) If you can find reviewers, AD will take as AD-sponsored individual Topic: Vehicle Event Package lead: Henning Schulzrinne Slides presented Noted that US government application CAP uses XMPP for somehing very similar, but needs to be broadened. Issue: Previously, asynchronous events outside of presence and MWI have been considered out of scope. Options: 1) Not at all in IETF, 2) Use XMPP, 3) make a per-case decision by expertise, size, etc. 4) build a general-purpose asynch event mechanism using SIMPLE as a basis Discussion: There are a lot of examples of information sources like this in Public Safety arena, where much work has been done on formatting the messages but not on transporting them. Brian Rosen expressed strong interest in the work. Question: Why here and not SIPPING? And: SIPPING was too busy this week. Question (Adam Roach) We originally had explicit instruction from IESG about not doing a general subscription notification message system like TIBCO. Will we be receiving guidance from the IESG that the language in 3265 no longer applies, or does the guidance stand. Noted that the same concerns would apply to XMPP and the rest of RAI. Noted by Miguel Garcia that there are concepts in the drafts he is scheduled to present in SIPPING tomorrow that relate to this work. Avshalom Houri expressed interest in the work. Not sure where it should be done. Henning noted that the whole set of things we've built, including partials, diffs, filtering, etc are perfectly applicable. Issue: Group Management. Miguel's work includes concept of "Communities" that are similar and should be coordinated. AD Guidance: Original guidance is that SIMPLE is in support of human real-time communications. Noted also that event packages are "informational required" and do not have to be done only in SIMPLE/ SIPPING. Poll: Interest level in room is relatively high. Topic: SIMPLE Problem Statement lead: Avshalom Houri Slides presented Intro by chair: Not certain that current draft universally hits the main point for the analysis required in the charter. We will need to make some decisions about how to arrange this. Note: "Numbers" slide, 5th column is messages per 8 hour day Discussion from Brian Rosen: Agreed that this shows a problem, but it would be useful to get a better handle on the size of the problem. This isn't protocol specific, it's presence-specific. Discussion from HGS: There were some papers about AT&T's network that we might could extract useful data from. But it is hard to put an upper limit on a scary number. Guidance from chair: This draft is now at the point where its model could be usefully compared to real experience. Please do so. Request from Ben Campbell: Would like to see feedback on his analysis as posted. Question from Henry Sinnreich: If you think this is the usage scenario, is this an argument that these big-load applications (like presence) should be handled in the endpoints and not the servers? Ans: maybe . . . Issue: Optimizations Comment from HGS: Google seems to be doing something like that already. The goal is reducing load, not shifting it around. Comment from Adam Roach: There are two sets of stuff here 1) existing mechanisms 2) new mechanisms for which we have not yet done an adequate requirements analysis. The document can be split along these lines. Adam would support the further optimization work. Comment from HGS: Could also have an informational on "lazy" approaches that can be implemented in today's protocols without change. Comment from Sriram: Young users often use their presence status to communicate like a broadcast message, perhaps 3-4 times per minute. This isn't true of enterprise users, the distribution could be very large. Topic: SIMPLE Chat draft lead: Miguel Angel Garcia-Martin Slides presented Issue: nicknames. Discussion: In other sessions, nicknames are a property of the use, not a property of the chat. Do we need to sove this or the general prolem? Adam noted that everything we do here will apply to xcon. Aki will look through xcon data model for a way to do it, and we'll have a system-wide capability. Ben noted that we have to be careful, because once the approach is in code, the feature requirement will be there forever. That will make it hard to change over. Mary asks that we make sure what we do here is NOT the general model for xcon. Adam confirms that these features will hag around, but that would not be as bad as not having the capabilities now. in his opinion the amount of work involved is relatively small. Question from Ben: Does the draft contain motivation for doing this in media stream instead of in SIP TO DO: Find this motivation and put it in draft. Comment from ben: Doing it this way will require ability to provision both focus and mixer with nickname. Comment from Brian Rosen: Ben's comment makes sense. Don't remember any discussion of this in the past. We should make this nicknaming SIP-wide. Comment from Adam: XCON does operations towards the focus, not the mixer, so may need to look at this. Comment from Aki: We previously said that if we put this stuff in the SDP then we're negotiating both session and nickname. This requires new response codes for "nickname taken". Also not pretty to have to use a reinvite to change nicknames mid-chat. Issue: Will you work on this? Comment from Brian Rosen: Yes. Comment from Ben: Yes, and we need to analyze impact on end-to-end encryption. Comment from Henry: We must do this to be able to use SIMPLE instead of XMPP. But we need to think about how this works in a serverless environment. Comment from Brian: End-system (multicast, broadcast, many-cast) mixing can meet the serverless. Poll from chair: Do we still have consensus to keep this as a basis for a WG item to meet our charter? Ans: We have consensus on doing this work. Topic: XCON work on MSRP conferencing lead: Mary Barnes Slides presented No discussion from room. Topic: MSRP ICE lead: Aki Niemi Slides presented Intended as a replacement for MSRP relays. Current draft is a strawman intended to get discussion going. Issue; Dropping To-Path, From-Path Comment from Ben campbell. Would be a chore to change MSRP just to do the discard of To-path and From-Path as suggested. Would also like to see case where one end uses relay, one end uses ICE. Comment from Adam. Dropping them is much like dropping tags in SIP and breaking forking. Comment from Robert Sparks Comment from Hadriel Kaplan: This is probably too much of a change This raises the question: if you keep them, what do you put there? Issue: RFC 4571 framing. Why are we doing this in ice-tcp? Comment from Adam Roach: We probably need to do something different from 4571 because it has a length header and this messes up arbitrary chunking. We probably need to come up with yet another mechanism. Comment from Henry: This draft is very useful because it moves more things to the endpoints. We should do it. From chair: If you want to work on this: DO SO! Meeting closed. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 29 02:24:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWo20-0002q1-GY; Thu, 29 Mar 2007 02:22:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWo1y-0002fp-SB for simple@ietf.org; Thu, 29 Mar 2007 02:22:42 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWo1v-0003pO-Bi for simple@ietf.org; Thu, 29 Mar 2007 02:22:42 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2T6MA8Y005521; Thu, 29 Mar 2007 09:22:30 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 09:22:19 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 09:22:18 +0300 Received: from [172.21.157.61] ([172.21.157.61]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 09:22:18 +0300 Message-ID: <460B5B1A.7040007@nokia.com> Date: Thu, 29 Mar 2007 09:22:18 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "'simple@ietf.org'" , Adam Roach , "Kiss Krisztian (Nokia-SIR/PaloAlto)" , Andrew Allen Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Mar 2007 06:22:18.0420 (UTC) FILETIME=[99FD5F40:01C771CA] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070329092231-10299BB0-34EBF504/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Simple] Presence dictionary. Reviewers needed X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi: A new version of the presence dictionary is available: http://www.ietf.org/internet-drafts/draft-garcia-simple-presence-dictionary-03.txt This version has removed those strings that are 3 characters or less, as per Adam's suggestion. At this time, I am soliciting for reviewers of the document. During the meeting in Prague we got a few volunteers. I remember Adam Roach, Krisztian Kiss, and Andrew Allen volunteered, but there were more volunteers, although I didn't get their names. Please send me a note if you want to review the document. A few guidelines for the reviewers: You should focus on two aspects in the draft: 1) Are all the the RFCs and Internet-Drafts that we can see in presence XML documents included in the dictionary or is there any missing extension? 2) Is the priority value for each string correct? Please send your comments to the list and copy myself too. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 30 09:35:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXHF2-0004aR-SE; Fri, 30 Mar 2007 09:34:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXHF1-0004aJ-25 for simple@ietf.org; Fri, 30 Mar 2007 09:34:07 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HXHEy-0006iT-G2 for simple@ietf.org; Fri, 30 Mar 2007 09:34:06 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 Mar 2007 09:34:05 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2UDY4Hw021165; Fri, 30 Mar 2007 09:34:04 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2UDXTlk010807; Fri, 30 Mar 2007 13:34:04 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 09:33:50 -0400 Received: from [192.168.1.104] ([10.86.240.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 09:33:50 -0400 Message-ID: <460D11BD.3020906@cisco.com> Date: Fri, 30 Mar 2007 09:33:49 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Hynar Subject: Re: [Simple] Pres URI References: <1174650052.4309.34.camel@brcalnik> In-Reply-To: <1174650052.4309.34.camel@brcalnik> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2007 13:33:50.0395 (UTC) FILETIME=[0D38F8B0:01C772D0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2891; t=1175261644; x=1176125644; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Simple]=20Pres=20URI |Sender:=20 |To:=20Martin=20Hynar=20; bh=fyZmGDd4tfpGviApJrU+aRwVU4rO59UEzLg7+SkEoMM=; b=xCqwi9+UrHNJHWNEdXg+67QdT0NzQb5ay8BnP5SEsqYxCg0CDtdCrsWOz6o94bIrTAkTvXcF cPxZKiPkcs4WWHcgrbDKJRRlWn6m34Uk/J9+lqhJvlr7jQWeGV/o3kF2; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: IETF WG SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org We just copied the mailto URI scheme, which works exactly the same way. I think the idea there is that if you see a link like mailto: , clicking on it just brings up an email and you need to fill in everything. For pres URI, it makes no sense to omit mailbox when the pres URI is, say, in a presence document, but one can imagine something like a web page has: hey, click here to subscribe to me! and that would bring up your IM program's add buddy screen. Of course, practically speaking, no one AFAIK is using pres URI at the moment. RFC 4479 says to set the presentity URI in the document to the URI scheme used to obtain the document, which is you are using SIMPLE, will be a SIP URI. -Jonathan R. Martin Hynar wrote: > Hello, > > I have looked at the syntax of pres uri and one thing surprised me. Let > me cite the ABNF: > > PRES-URI = "pres:" [ to ] [ headers ] > > to = mailbox > headers = "?" header *( "&" header ) > header = hname "=" hvalue > hname = *uric > hvalue = *uric > > > > Both "to" and "header" parts are optional, so the resulting Pres URI > might have form "pres:"? Was this some intention or is it just > combinatorial possibility? In addition, I am missing some use case even > for existence of Pres URI, can somebody put some light on this for me? > > Thanks much in advance, Martin Hynar > > > *+-------------------------------------+* > * **Martin Hynar* > Software Specialist > > * **TietoEnator* > Czech Software Center > Phone: +420 597 459 713 > Mobile: +420 724 432 817 > E-mail:*_ _**_Martin.Hynar@TietoEnator.com_* > > Vystavni 292/13 > CZ-709 16 Ostrava > > *_www.tietoenator.com _* > > > /Please note: The information contained in this message may be legally > privileged and confidential and protected from disclosure. If the reader > of this message is not the intended recipient, you are hereby notified > that any unauthorized use, distribution or copying of this communication > is strictly prohibited. If you have received this communication in > error, please notify us immediately by replying to the message and > deleting it from your computer. Thank You./ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 30 12:17:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJn0-0004q7-Df; Fri, 30 Mar 2007 12:17:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJmy-0004pX-Ag for simple@ietf.org; Fri, 30 Mar 2007 12:17:20 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXJmw-0008F2-TP for simple@ietf.org; Fri, 30 Mar 2007 12:17:20 -0400 Received: from [172.17.2.92] ([172.17.2.92]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l2UGHGqc078907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Mar 2007 11:17:16 -0500 (CDT) (envelope-from matthias@estacado.net) In-Reply-To: <460B5B1A.7040007@nokia.com> References: <460B5B1A.7040007@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Matthias Granberry Subject: Re: [Simple] Presence dictionary. Reviewers needed Date: Fri, 30 Mar 2007 11:17:01 -0500 To: Miguel Garcia X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0529771342==" Errors-To: simple-bounces@ietf.org --===============0529771342== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--604273814; protocol="application/pkcs7-signature" --Apple-Mail-3--604273814 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed There are mismatches between Appendix A and figure 3. The 3- character strings haven't been removed from the appendix. On Mar 29, 2007, at 1:22 AM, Miguel Garcia wrote: > Hi: > > A new version of the presence dictionary is available: > http://www.ietf.org/internet-drafts/draft-garcia-simple-presence- > dictionary-03.txt > > This version has removed those strings that are 3 characters or > less, as per Adam's suggestion. > > At this time, I am soliciting for reviewers of the document. During > the meeting in Prague we got a few volunteers. I remember Adam > Roach, Krisztian Kiss, and Andrew Allen volunteered, but there were > more volunteers, although I didn't get their names. Please send me > a note if you want to review the document. > > A few guidelines for the reviewers: > > You should focus on two aspects in the draft: > > 1) Are all the the RFCs and Internet-Drafts that we can see in > presence XML documents included in the dictionary or is there any > missing extension? > > 2) Is the priority value for each string correct? > > Please send your comments to the list and copy myself too. > > /Miguel > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple --Apple-Mail-3--604273814 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOTCCBTUw ggMdoAMCAQICAwLlrTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNjExMTUwNDI2MThaFw0w NzExMTUwNDI2MThaMGcxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjElMCMGCSqGSIb3DQEJARYW bWF0dGhpYXNAZ3JhbmJlcnJ5cy51czEkMCIGCSqGSIb3DQEJARYVbWF0dGhpYXNAZXN0YWNhZG8u bmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA36AOCu7Mn1FsViPuDM67zTbSMlDY m0FpuW+52MoLUkcammHZ8X2N+UuLhEO4pxN9gtCHWDC4Tqu9uexRZJ7vNvGb0tYUBcmdDdyZm/ax aiFGaFgJHAcQuZeypmcsjo8Eb2Pp4OdHKCzI2TiIVO4lataSzIP+zkPyo0B2t5amzzy6767/S51U WttZ8QtuEwRk6MWieUF1+ph8FT4dG+x6klJkh+UI9cjNlwRsr0p3mCpth6zAP30395DbTJFS5p6u XRX2CKCSsYU8CmRu/JqSRbYqYwqfkXU1t9FjH5LIF0n1cbmgvAg9NCZE3EfsFhg1wu0s5Z0vqUJ0 cJ+Lam0vzwIDAQABo4HXMIHUMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5 b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9y ZzA4BgNVHREEMTAvgRZtYXR0aGlhc0BncmFuYmVycnlzLnVzgRVtYXR0aGlhc0Blc3RhY2Fkby5u ZXQwDQYJKoZIhvcNAQEFBQADggIBAHCEcuT1H2h0WN+Q0A35X+TrLBOkPGZXAgeR8CHRGoVpM0HG dAnk/42uBVg5d4H+IBA7+BabEW3dewp80GXV6gBLPE7B/IN3PN1pdPJLq01CvPLL5OXPkZTfhclH PbcKXdTQSZIbNXL5Oxac1WZQ4/4KMilfTt2FP6T43hE88/CBiDP9qEes8Dd9HZetV2lWqQcyAMFs vbZkY+35wehqFrYWWaa1Emtm27Lvg5Xm2oALg+z4Nw/zExC5IVaVg6ngrYZVYbf4CrKk8tu+ndVI ecAa11vl1CeVNh8S+132Och9LJS6B0JTcU5tkPEI5C6waprP63UgQz0OrOvwwlecOqDJWfzEu4al pnl2tx8LvR6adrNM0MDSkNMtzjIYnOiHP/fjm+qtiWUghp/UP+0ZbBuQ9TJ10BJ/9TlAgutwtDPj LF+XnmDGWBw1iHMCesppRt9CvDS5IguX7j5MqVkTXxu4ul6uU7Xv7Pa5CsUPENc3wNoA5RPnN3kT Yvz4Fr9PVgJlmhTVc6icQL1zWD38ikwYQVSnTBVbSO8d0WzRoPy1JzRl4tVK7DR61jIoRzkVKaGI O3uiPUqah2Fux0t6TM/flRGR+Hs0ttlXsm2pzaJNVRmCEmShf4xVAISeXAkb3So/3qJ0QtFML7C+ QFIizEJWP5PXbRnS5GU366xQLJ5xMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEe MBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcg QXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwLlrTAJBgUrDgMC GgUAoIIBhzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzAzMzAx NjE3MDJaMCMGCSqGSIb3DQEJBDEWBBRoYnY1/lT2z6ioFbePIzU+7xyiezCBkQYJKwYBBAGCNxAE MYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3Vw cG9ydEBjYWNlcnQub3JnAgMC5a0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jv b3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBT aWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMC5a0w DQYJKoZIhvcNAQEBBQAEggEAv9Pbt8MC9xSDtVSOJdwHv1QfmX6VL6oCjFwnKdaP7NWVUyO+kNcP S1KxWk2Q9e1wSGG8VGCd7btLuU8kbFR3Cb7fSAAw3F+UYdLFvIWqLyJZ0iLxDMhB3eB4JXB4it+l uS2Erv8EnT00e5jtUN2vk3hGAvZ0yhn15PeaJqiGWSGSyaVuOWoOeJWRllq6A8ZoQMC4TiEaWpmx 85ArLLaIUI0UfF5F0B3sUmMkBFzwRFYSDWP5jzLYH4KvN0GfDkHpQem2rsFjX8c3xBoiU3VK5uGM Z0MfwWRdHBNq6cx4BGtUrCQ4GQSBx/nW0TU+Od9QTxWcx0YzJLC9OfFcde+9PAAAAAAAAA== --Apple-Mail-3--604273814-- --===============0529771342== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0529771342==-- From simple-bounces@ietf.org Sat Mar 31 03:03:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXXaq-0007Sb-QE; Sat, 31 Mar 2007 03:01:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXXap-0007ST-Nn for simple@ietf.org; Sat, 31 Mar 2007 03:01:43 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXXao-00028l-8u for simple@ietf.org; Sat, 31 Mar 2007 03:01:43 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2V71TJv019796; Sat, 31 Mar 2007 10:01:30 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 Mar 2007 10:01:29 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 Mar 2007 10:01:29 +0300 Received: from [10.162.75.229] ([10.162.75.229]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 Mar 2007 10:01:29 +0300 Message-ID: <460E0748.8050600@nokia.com> Date: Sat, 31 Mar 2007 10:01:28 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Matthias Granberry Subject: Re: [Simple] Presence dictionary. Reviewers needed References: <460B5B1A.7040007@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Mar 2007 07:01:29.0054 (UTC) FILETIME=[67E727E0:01C77362] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070331100133-4C2B0BB0-31F1DEC1/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Andrew Allen , Avshalom Houri , "Kiss Krisztian \(Nokia-SIR/PaloAlto\)" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Ouch, this is an embarrassing oversight. I forgot to update the Appendix, although the binary dictionary was correctly updated. I will create a new version and submitted in the next hours. Reviewers, please, hold your review until a new version is out. Matthias, thanks for pointing this out. /Miguel Matthias Granberry wrote: > There are mismatches between Appendix A and figure 3. The 3-character > strings haven't been removed from the appendix. > > On Mar 29, 2007, at 1:22 AM, Miguel Garcia wrote: > >> Hi: >> >> A new version of the presence dictionary is available: >> http://www.ietf.org/internet-drafts/draft-garcia-simple-presence-dictionary-03.txt >> >> >> This version has removed those strings that are 3 characters or less, >> as per Adam's suggestion. >> >> At this time, I am soliciting for reviewers of the document. During >> the meeting in Prague we got a few volunteers. I remember Adam Roach, >> Krisztian Kiss, and Andrew Allen volunteered, but there were more >> volunteers, although I didn't get their names. Please send me a note >> if you want to review the document. >> >> A few guidelines for the reviewers: >> >> You should focus on two aspects in the draft: >> >> 1) Are all the the RFCs and Internet-Drafts that we can see in >> presence XML documents included in the dictionary or is there any >> missing extension? >> >> 2) Is the priority value for each string correct? >> >> Please send your comments to the list and copy myself too. >> >> /Miguel >> >> --Miguel A. Garcia tel:+358-50-4804586 >> Nokia Research Center Helsinki, Finland >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple