From simple-bounces@ietf.org Sun Sep 02 10:32: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 1IRqT6-0001bw-1N; Sun, 02 Sep 2007 10:30:28 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IRqT4-0001Xh-Jg for simple-confirm+ok@megatron.ietf.org; Sun, 02 Sep 2007 10:30:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRqT4-0001Wl-9J for simple@ietf.org; Sun, 02 Sep 2007 10:30:26 -0400 Received: from [85.17.186.5] (helo=node05.dns-hosting.info) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRqT3-0005B0-9a for simple@ietf.org; Sun, 02 Sep 2007 10:30:25 -0400 Received: from mit.xs4all.nl ([213.84.95.205] helo=[192.168.0.34]) by node05.dns-hosting.info with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.67) (envelope-from ) id 1IRqSx-0003Ld-5o for simple@ietf.org; Sun, 02 Sep 2007 16:30:23 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <441C1DB4-60A7-41BA-97C0-871548268429@ag-projects.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: simple@ietf.org From: Adrian Georgescu Date: Sun, 2 Sep 2007 16:29:55 +0200 X-Mailer: Apple Mail (2.752.3) X-SA-Exim-Connect-IP: 213.84.95.205 X-SA-Exim-Mail-From: ag@ag-projects.com X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on node05.dns-hosting.info X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-SA-Exim-Version: 4.2.1 (built Thu, 26 Apr 2007 18:30:04 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Simple] OpenXCAP launch 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, I would like to announce the launch of OpenXCAP.org OpenXCAP is an open source, easy extensible, fully featured XCAP server with TLS security and support for multiple realms. OpenXCAP server can be used in combination with a SIP server that supports PUBLISH/SUBSCRIBE/NOTIFY methods to provide a complete SIP SIMPLE server solution The server is written in the Python programming language and is based on the following RFCs: - The Extensible Markup Language Configuration Access Protocol RFC 4825 - Formats for Representing Resource Lists RFC 4826 - Usage for Manipulating Presence Document Contents RFC 4827 - Presence Authorization Rules draft-ietf-simple-presence-rules-10 The server supports TLS security, multiple back-end storage systems and works out of the box with OpenSER Proxy/Registrar/Presence server. The software is provided under the BSD license. I wish to thank here to my IETF friends who helped me with advice, testing and guidance during the development phase of this project. I would also like to thank to Mircea Amarascu, the author of the software, without his passion and dedication this project would not have been possible. The project is hosted at: http://openxcap.org The project is supported via the wiki collaboration system setup by AG Projects. To open ticket please Register first. We are looking forward your feedback from real-life field deployments. Kind regards, Adrian Georgescu AG Projects _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Sep 02 21:44:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS0xn-0003WC-1h; Sun, 02 Sep 2007 21:42:51 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IS0xl-0003W2-T0 for simple-confirm+ok@megatron.ietf.org; Sun, 02 Sep 2007 21:42:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS0xl-0003Vu-JR for simple@ietf.org; Sun, 02 Sep 2007 21:42:49 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IS0xj-0004xI-9Q for simple@ietf.org; Sun, 02 Sep 2007 21:42:49 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNR005QSRE3S8@szxga04-in.huawei.com> for simple@ietf.org; Mon, 03 Sep 2007 09:42:03 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNR00E6ZRE2M9@szxga04-in.huawei.com> for simple@ietf.org; Mon, 03 Sep 2007 09:42:03 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNR008SLRDYRI@szxml03-in.huawei.com> for simple@ietf.org; Mon, 03 Sep 2007 09:42:02 +0800 (CST) Date: Mon, 03 Sep 2007 09:41:56 +0800 From: Qian Sun To: simple@ietf.org Message-id: <002601c7edcb$9cb9e140$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: Acfty5xaAITcjys4QS+mmDsWhKoO9g== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Simple] New I-D: Sieve Notification Mechanism: SIP MESSAGE 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 Everybody, We have submitted a new Internet-draft: Sieve Notification Mechanism: SIP MESSAGE. Since this new draft involves instant messaging, I send this information to SIMPLE maillist. Authors : A. Melnikov, H. Schulzrinne, Q. Sun Abstract : This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the SIP MESSAGE. A URL for this Internet-Draft is: http://tools.ietf.org/html/draft-melnikov-sieve-notify-sip-message-00 Your comments are welcome! Cheers, Qian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Sep 02 22:53:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS22f-0004n5-3Z; Sun, 02 Sep 2007 22:51:57 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IS22d-0004k0-6f for simple-confirm+ok@megatron.ietf.org; Sun, 02 Sep 2007 22:51:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS22c-0004js-TN for simple@ietf.org; Sun, 02 Sep 2007 22:51:54 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IS22b-0005vx-Jm for simple@ietf.org; Sun, 02 Sep 2007 22:51:54 -0400 Received: by py-out-1112.google.com with SMTP id d32so4440652pye for ; Sun, 02 Sep 2007 19:51:53 -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:cc:in-reply-to:mime-version:content-type:references; b=PqAiuSaL7db2+AuCrPvrtwX8lrkESF0Su5CvW7PjZTwKsFejQoc5uzkx+4aCfF2lR9X9PF0YbE1DVl1PAfxPyguAnLF4ujSQv7NYrXZL4b8jI0EqCAdIU5PrOolgvRRUE8FRKqZwpBrojn6EEd6+ccSgtZyX5AKfsT23csrB3EI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tHOmXhVNv354H6rtJD55VopXs8qk9ai7VkChiAq6ejk6Q46eV/qh/03dU+R5jRvN/vXXhpWMC9EWKfZ9ZXEafQM0XyAKwoeLjn8SJ3qa1jGUEY3yZFPdkt6uBFM+Dq/ukjRL/G9DDspJP6TaafExQC3r4S+kyZOhTL33GM/h7CI= Received: by 10.64.213.3 with SMTP id l3mr1417378qbg.1188787912975; Sun, 02 Sep 2007 19:51:52 -0700 (PDT) Received: by 10.65.254.11 with HTTP; Sun, 2 Sep 2007 19:51:52 -0700 (PDT) Message-ID: <66cd252f0709021951t628d7a84ybe2229b370225467@mail.gmail.com> Date: Mon, 3 Sep 2007 12:51:52 +1000 From: "Hisham Khartabil" To: "Brian Rosen" Subject: Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI In-Reply-To: <00be01c7e0ea$65d53870$0700a8c0@cis.neustar.com> MIME-Version: 1.0 References: <46C5C495.8030601@cisco.com> <000601c7e0e9$47648400$0601a8c0@BEMBUSTER> <00be01c7e0ea$65d53870$0700a8c0@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: simple@ietf.org, Paul Kyzivat , miguel.garcia@nsn.com, aki.niemi@nokia.com 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="===============0152415049==" Errors-To: simple-bounces@ietf.org --===============0152415049== Content-Type: multipart/alternative; boundary="----=_Part_10236_29515784.1188787912931" ------=_Part_10236_29515784.1188787912931 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I've read this thread and seem to agree mostly with Aki, but I think Brian and Paul have some valid points. I think the system should be designed as follows: - Agencies: No external nicknames (I think it defeats the purpose of having a nickname if external ones are allowed). Effectively I'm saying that every domain runs its own nickname agency and to join one of its chatrooms, you need to create a local nickname. - Scope: nicknames are reserved per domain. I want to participate in one or more chatrooms serviced by the same domain discussing slightly different topics. People certainly do that in IRC today and we don't want that feature to disappear. Also, I don't want to go reserve my nickname 10 different times in 10 different chatroom in the same domain. - Permanency: a nickname is temporary in nature until the user exits the domain (logs off). A user can reserve a permanent nickname by doing an out of band transaction with the domain administrators. Perhaps the domain wants you to pay $$$ for doing that. - Uniqueness: I think nicknames should be unique. There seems to be people who want clashing nicknames. Fair enough, different people have different agendas. So, I think its a fair compramise if we allow collisions, but device a mechanism for servers force nickname uniqueness and rejects conflicting nichnames (error responses etc). - Routability: I don't see myself joining a chatroom and wanting to display my AoR, but some people might want to in order to enable other users to contact them directly for private messages outside the chatroom service, invite them to a voice call or whatever media. In this case, an AoR display in warranted. For me, I will request anonymity, for Brain, he will not and will diplay his AoR to the rest of the participants. A compramise is to have an AoR as well as a routable nickname. A user is reachable on both. AoR is used to reach a user directly, the nickname is used to reach the user via the chatroom. Perhaps diplaying both for users not requesting anonymity and just the routable nickname for those who do request anonymity. One problem, however, is present in the last point: since some servers will allow collisions in nicknames, a nickname can no longer be routable (if 2 or more users sharing the same nickname are all anonymous) and therefore requires a uniqueness attribute. Regards, Hisham On 18/08/07, Brian Rosen wrote: > > The "generalized" mechanism will (eventually) have a way to authenticate a > nickname at a domain against an AoR. > > Brian > > > -----Original Message----- > > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > Sent: Friday, August 17, 2007 12:12 PM > > To: Paul Kyzivat; aki.niemi@nokia.com > > Cc: br@brianrosen.net; miguel.garcia@nsn.com; simple@ietf.org > > Subject: Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname > URI > > > > > What you want can be achieved by a policy that restricts nicknames to > > > those in a domain chosen by the conference, having relatively long > > > term assignments of nicknames in that domain, and not allowing > > > duplicates within that domain. > > > > This would also require authentication of users against that domain > > > > Is this needed in the conference data model? Could it work without being > > standardized? > > > > Regards, > > Jeroen > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > ------=_Part_10236_29515784.1188787912931 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I've read this thread and seem to agree mostly with Aki, but I think Brian and Paul have some valid points.
 
I think the system should be designed as follows:
 
- Agencies: No external nicknames (I think it defeats the purpose of having a nickname if external ones are allowed). Effectively I'm saying that every domain runs its own nickname agency and to join one of its chatrooms, you need to create a local nickname.
 
- Scope: nicknames are reserved per domain. I want to participate in one or more chatrooms serviced by the same domain discussing slightly different topics. People certainly do that in IRC today and we don't want that feature to disappear. Also, I don't want to go reserve my nickname 10 different times in 10 different chatroom in the same domain.
 
- Permanency: a nickname is temporary in nature until the user exits the domain (logs off). A user can reserve a permanent nickname by doing an out of band transaction with the domain administrators. Perhaps the domain wants you to pay $$$ for doing that.
 
- Uniqueness: I think nicknames should be unique. There seems to be people who want clashing nicknames. Fair enough, different people have different agendas. So, I think its a fair compramise if we allow collisions, but device a mechanism for servers force nickname uniqueness and rejects conflicting nichnames (error responses etc).
 
- Routability: I don't see myself joining a chatroom and wanting to display my AoR, but some people might want to in order to enable other users to contact them directly for private messages outside the chatroom service, invite them to a voice call or whatever media. In this case, an AoR display in warranted. For me, I will request anonymity, for Brain, he will not and will diplay his AoR to the rest of the participants. A compramise is to have an AoR  as well as a routable nickname. A user is reachable on both. AoR is used to reach a user directly, the nickname is used to reach the user via the chatroom. Perhaps diplaying both for users not requesting anonymity and just the routable nickname for those who do request anonymity.
 
One problem, however, is present in the last point: since some servers will allow collisions in nicknames, a nickname can no longer be routable (if 2 or more users sharing the same nickname are all anonymous) and therefore requires a uniqueness attribute.
 
Regards,
Hisham
 
On 18/08/07, Brian Rosen <br@brianrosen.net> wrote:
The "generalized" mechanism will (eventually) have a way to authenticate a
nickname at a domain against an AoR.

Brian

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]
> Sent: Friday, August 17, 2007 12:12 PM
> To: Paul Kyzivat; aki.niemi@nokia.com
> Cc: br@brianrosen.net; miguel.garcia@nsn.com; simple@ietf.org
> Subject: Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI
>
> > What you want can be achieved by a policy that restricts nicknames to
> > those in a domain chosen by the conference, having relatively long
> > term assignments of nicknames in that domain, and not allowing
> > duplicates within that domain.
>
> This would also require authentication of users against that domain
>
> Is this needed in the conference data model? Could it work without being
> standardized?
>
> Regards,
> Jeroen



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

------=_Part_10236_29515784.1188787912931-- --===============0152415049== 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 --===============0152415049==-- From simple-bounces@ietf.org Mon Sep 03 02:10: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 1IS57K-0002Sv-1e; Mon, 03 Sep 2007 02:08:58 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IS57I-0002Sl-EJ for simple-confirm+ok@megatron.ietf.org; Mon, 03 Sep 2007 02:08:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS57H-0002Sc-WD for simple@ietf.org; Mon, 03 Sep 2007 02:08:56 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IS57G-0006Qy-CR for simple@ietf.org; Mon, 03 Sep 2007 02:08:55 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNS006HS3PM82@szxga04-in.huawei.com> for simple@ietf.org; Mon, 03 Sep 2007 14:08:10 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNS00L2O3PL37@szxga04-in.huawei.com> for simple@ietf.org; Mon, 03 Sep 2007 14:08:10 +0800 (CST) Received: from z67324 ([10.85.29.44]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNS00IIK3PK7T@szxml04-in.huawei.com> for simple@ietf.org; Mon, 03 Sep 2007 14:08:09 +0800 (CST) Date: Mon, 03 Sep 2007 14:08:06 +0800 From: ZhangYing Subject: Re: [Simple] Report with a body To: Arie Reches , simple@ietf.org Message-id: <003601c7edf0$cb720650$2c1d550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <30F0D7625E0DEC4E83A2A94596BC18B701F70255@VRZIL-EX01.il.veraznetworks.com> X-Spam-Score: 2.1 (++) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0468013198==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0468013198== Content-type: multipart/alternative; boundary="Boundary_(ID_9jzXJhMCwzXvMX7d/nmJow)" This is a multi-part message in MIME format. --Boundary_(ID_9jzXJhMCwzXvMX7d/nmJow) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Arie I think you can get the clarification from the section 7.1.2 of draft-ietf draft-ietf-simple-message-sessions-19.And I attached the key context in the following. REPORT requests will normally not include a body, as the REPORT request header fields can carry sufficient information in most cases. However, REPORT requests MAY include a body containing additional information about the status of the associated SEND request. Such a body is informational only, and the sender of the REPORT request SHOULD NOT assume that the recipient pays any attention to the body. REPORT requests are not interruptible. Ying Zhang ----- Original Message ----- From: Arie Reches To: simple@ietf.org Sent: Thursday, August 30, 2007 3:02 PM Subject: [Simple] Report with a body Hi, In section 4.1.2 of draft-ietf-simple-message-sessions-19 mentioned that a REPORT message may include a body. The problem is that the Byte-Range header of the REPORT message is relating SEND message. Can you give an example of REPORT message with Body. The example for report message without a body is: MSRP dkei38sd REPORT To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp Message-ID: 12339sdqwer Byte-Range: 1-106/106 Status: 000 200 OK -------dkei38sd$ How the same report with a body shall be formatted? Arie ------------------------------------------------------------------------------ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --Boundary_(ID_9jzXJhMCwzXvMX7d/nmJow) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Hi Arie
  
   I think you can get the clarification from the section 7.1.2 of draft-ietf draft-ietf-simple-message-sessions-19.And I attached the key context in the following.
  
   
   REPORT requests will normally not include a body, as the REPORT
   request header fields can carry sufficient information in most cases.
   However, REPORT requests MAY include a body containing additional
   information about the status of the associated SEND request.  Such a
   body is informational only, and the sender of the REPORT request
   SHOULD NOT assume that the recipient pays any attention to the body.
   REPORT requests are not interruptible.
 
 
 
Ying Zhang
 
 
----- Original Message -----
Sent: Thursday, August 30, 2007 3:02 PM
Subject: [Simple] Report with a body

Hi,

 

            In section 4.1.2 of draft-ietf-simple-message-sessions-19 mentioned that a REPORT message may include a body.

 

            The problem is that the Byte-Range header of the REPORT message is relating SEND message.

 

            Can you give an example of REPORT message with Body.

 

            The example for report message without a body is:

               MSRP dkei38sd REPORT

   To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp

   From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp

   Message-ID: 12339sdqwer

   Byte-Range: 1-106/106

   Status: 000 200 OK

   -------dkei38sd$

 

            How the same report with a body shall be formatted?

Arie

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
--Boundary_(ID_9jzXJhMCwzXvMX7d/nmJow)-- --===============0468013198== 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 --===============0468013198==-- From simple-bounces@ietf.org Tue Sep 04 10:50: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 1ISZhb-0000Nr-Fh; Tue, 04 Sep 2007 10:48:27 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ISZhZ-0000Ni-OQ for simple-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 10:48:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISZhZ-0000NV-Ba for simple@ietf.org; Tue, 04 Sep 2007 10:48:25 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISZhY-00037u-RD for simple@ietf.org; Tue, 04 Sep 2007 10:48:25 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1ISZhH-0006X9-IJ; Tue, 04 Sep 2007 09:48:08 -0500 From: "Brian Rosen" To: "'Hisham Khartabil'" References: <46C5C495.8030601@cisco.com> <000601c7e0e9$47648400$0601a8c0@BEMBUSTER> <00be01c7e0ea$65d53870$0700a8c0@cis.neustar.com> <66cd252f0709021951t628d7a84ybe2229b370225467@mail.gmail.com> Subject: RE: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Tue, 4 Sep 2007 10:48:12 -0400 Message-ID: <070401c7ef02$a04555a0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <66cd252f0709021951t628d7a84ybe2229b370225467@mail.gmail.com> Thread-Index: Acft1WawYR+u72dETNKxQpBXLaptLwBKTnxA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9724479da43a8325ad975c1a9b841870 Cc: simple@ietf.org, 'Paul Kyzivat' , miguel.garcia@nsn.com, aki.niemi@nokia.com 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="===============1296546841==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1296546841== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0705_01C7EEE1.1933B5A0" This is a multi-part message in MIME format. ------=_NextPart_000_0705_01C7EEE1.1933B5A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit _____ From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] Sent: Sunday, September 02, 2007 10:52 PM To: Brian Rosen Cc: Jeroen van Bemmel; Paul Kyzivat; aki.niemi@nokia.com; miguel.garcia@nsn.com; simple@ietf.org Subject: Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI I've read this thread and seem to agree mostly with Aki, but I think Brian and Paul have some valid points. I think the system should be designed as follows: - Agencies: No external nicknames (I think it defeats the purpose of having a nickname if external ones are allowed). Effectively I'm saying that every domain runs its own nickname agency and to join one of its chatrooms, you need to create a local nickname. I think you are clear on this: you want to completely disallow a domain from accepting a nickname registered in another domain. So, for example, you would prohibit allowing a domain to use an AOL screen name as a nick name; they have to declare the nickname within the local domain. You feel strongly that the mechanism should not be made such that some domains could allow this feature (by, for example, including the domain in the nickname, and using some other mechanism for constructing a URI for the nickname). - Scope: nicknames are reserved per domain. I want to participate in one or more chatrooms serviced by the same domain discussing slightly different topics. People certainly do that in IRC today and we don't want that feature to disappear. Also, I don't want to go reserve my nickname 10 different times in 10 different chatroom in the same domain. what is a domain then? Is chat34.example.com a domain? Did you mean to imply that example.com is the domain? So, for example, hotmail.com is a different domain from msn.com, right? You would prefer to register your nickname in 100 different chat servers you might use, rather than asking them to use one your registered somewhere else, right? Again, you want to prohibit this kind of behavior, or perhaps more positive, you don't want the mechanism complicated in any way to allow such a capability. - Permanency: a nickname is temporary in nature until the user exits the domain (logs off). A user can reserve a permanent nickname by doing an out of band transaction with the domain administrators. Perhaps the domain wants you to pay $$$ for doing that. So you would not want to have, at any time, a standardized way to request a permanent nickname. You might want to explain a little about how you use a permanent as opposed to a temporary nickname. Let's say, for example, that there was a chat where I was not in that particular chat, but someone else wanted to use my nickname. Would you allow that? I'm a little unclear if you would find any value in a registered nickname. - Uniqueness: I think nicknames should be unique. There seems to be people who want clashing nicknames. Fair enough, different people have different agendas. So, I think its a fair compramise if we allow collisions, but device a mechanism for servers force nickname uniqueness and rejects conflicting nichnames (error responses etc). Here we have common ground. You want to allow a service to allow collisions, and you want a way for a service to not allow collisions. I agree. It's policy at the service, and clients have to cope with either policy. - Routability: I don't see myself joining a chatroom and wanting to display my AoR, but some people might want to in order to enable other users to contact them directly for private messages outside the chatroom service, invite them to a voice call or whatever media. In this case, an AoR display in warranted. For me, I will request anonymity, for Brain, he will not and will diplay his AoR to the rest of the participants. A compramise is to have an AoR as well as a routable nickname. A user is reachable on both. AoR is used to reach a user directly, the nickname is used to reach the user via the chatroom. Perhaps diplaying both for users not requesting anonymity and just the routable nickname for those who do request anonymity. I think we're agreeing on principal, but disagreeing on mechanism. We agree that you should be able to be addressed by AoR if you are okay with that, and we agree you should be addressable by some other URI if you don't want to be addressable by your AoR. We agree that your nickname is associated with the URI (be it an AoR or something else). Is there a particular reason why you need to have the nickname itself in the alternate AoR? Would some other anonymous URI, associated by all with your nickname in the roster, be an acceptable URI or does it have to be nick@domain? Is there some advantage to having the nick itself in the URI? One problem, however, is present in the last point: since some servers will allow collisions in nicknames, a nickname can no longer be routable (if 2 or more users sharing the same nickname are all anonymous) and therefore requires a uniqueness attribute. Yes ------=_NextPart_000_0705_01C7EEE1.1933B5A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: = Hisham Khartabil [mailto:hisham.khartabil@gmail.com]
Sent: Sunday, September = 02, 2007 10:52 PM
To: Brian Rosen
Cc: Jeroen van Bemmel; = Paul Kyzivat; aki.niemi@nokia.com; miguel.garcia@nsn.com; simple@ietf.org
Subject: Re: VS: Re: = [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI

 

I've read this thread and seem to agree mostly with Aki, but I = think Brian and Paul have some valid points.

 

I think the system should be designed as = follows:

 

- Agencies: No external nicknames (I think it defeats the = purpose of having a nickname if external ones are allowed). Effectively I'm saying = that every domain runs its own nickname agency and to join one of its = chatrooms, you need to create a local nickname.

<brian>I think you are clear = on this: you want to completely disallow a domain from accepting a nickname = registered in another domain.  So, for example, you would prohibit allowing a = domain to use an AOL screen name as a nick name; they have to declare the = nickname within the local domain.  You feel strongly that the mechanism = should not be made such that some domains could allow this feature (by, for = example, including the domain in the nickname, and using some other mechanism for constructing a URI for the nickname).  =

 

- Scope: nicknames are reserved per domain. I want to participate in one or more chatrooms serviced by the same domain = discussing slightly different topics. People certainly do that in IRC today and we = don't want that feature to disappear. Also, I don't want to go reserve my = nickname 10 different times in 10 different chatroom in the same domain.
<brian>what is a domain then?  Is chat34.example.com a = domain?  Did you mean to imply that example.com is the domain?  So, for = example, hotmail.com is a different domain from msn.com, = right?

You would prefer to register your = nickname in 100 different chat servers you might use, rather than asking them to use = one your registered somewhere else, right?   Again, you want to = prohibit this kind of behavior, or perhaps more positive, you don’t want = the mechanism complicated in any way to allow such a = capability.

 

- Permanency: a nickname is temporary in nature until the user = exits the domain (logs off). A user can reserve a permanent nickname by doing = an out of band transaction with the domain administrators. Perhaps the domain = wants you to pay $$$ for doing that.

So you would not want to have, at = any time, a standardized way to request a permanent nickname.  You might want = to explain a little about how you use a permanent as opposed to a temporary nickname.  Let’s say, for example, that there was a chat = where I was not in that particular chat, but someone else wanted to use my = nickname.  Would you allow that?

 

=

I’m a little unclear if you = would find any value in a registered nickname.

 

- Uniqueness: I think nicknames should be unique. There seems to = be people who want clashing nicknames. Fair enough, different people have different agendas. So, I think its a fair compramise if we allow = collisions, but device a mechanism for servers force nickname uniqueness and rejects conflicting nichnames (error responses etc). =

Here we have common ground.  = You want to allow a service to allow collisions, and you want a way for a service = to not allow collisions.  I agree.  It’s policy at the service, = and clients have to cope with either policy.

 

- Routability: I don't see myself joining a chatroom and = wanting to display my AoR, but some people might want to in order to enable = other users to contact them directly for private messages outside the chatroom = service, invite them to a voice call or whatever media. In this case, an AoR = display in warranted. For me, I will request anonymity, for Brain, he will not = and will diplay his AoR to the rest of the participants. A compramise = is to have an AoR  as well as a routable nickname. A user is reachable on = both. AoR is used to reach a user directly, the nickname is used to reach the = user via the chatroom. Perhaps diplaying both for users not requesting = anonymity and just the routable nickname for those who do request anonymity. =

I think we’re agreeing on = principal, but disagreeing on mechanism.  We agree that you should be able to = be addressed by AoR if you are okay with that, and we agree you should be addressable by some other URI if you don’t want to be addressable = by your AoR.  We agree that your nickname is associated with the URI (be it = an AoR or something else).  Is there a particular reason why you need to = have the nickname itself in the alternate AoR?  Would some other anonymous = URI, associated by all with your nickname in the roster, be an acceptable URI = or does it have to be nick@domain?

 

=

Is there some advantage to having = the nick itself in the URI?

 

=

 

One problem, however, is present in the last point: since some = servers will allow collisions in nicknames, a nickname can no longer be routable = (if 2 or more users sharing the same nickname are all anonymous) and therefore requires a uniqueness attribute.

Yes

 

------=_NextPart_000_0705_01C7EEE1.1933B5A0-- --===============1296546841== 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 --===============1296546841==-- From simple-bounces@ietf.org Tue Sep 04 11:34: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 1ISaOT-00047y-1g; Tue, 04 Sep 2007 11:32:45 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ISaOS-00047t-9J for simple-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 11:32:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISaOR-00047d-ST for simple@ietf.org; Tue, 04 Sep 2007 11:32:43 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISaOQ-0004gL-KB for simple@ietf.org; Tue, 04 Sep 2007 11:32:43 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 04 Sep 2007 11:32:42 -0400 X-IronPort-AV: i="4.20,207,1186372800"; d="scan'208"; a="70001851:sNHT80164976" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l84FWgA7007440; Tue, 4 Sep 2007 11:32:42 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l84FWbpw021528; Tue, 4 Sep 2007 15:32:37 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); Tue, 4 Sep 2007 11:32:29 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 11:32:29 -0400 Message-ID: <46DD7A8B.1070905@cisco.com> Date: Tue, 04 Sep 2007 11:32:27 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Rosen Subject: Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46C5C495.8030601@cisco.com> <000601c7e0e9$47648400$0601a8c0@BEMBUSTER> <00be01c7e0ea$65d53870$0700a8c0@cis.neustar.com> <66cd252f0709021951t628d7a84ybe2229b370225467@mail.gmail.com> <070401c7ef02$a04555a0$640fa8c0@cis.neustar.com> In-Reply-To: <070401c7ef02$a04555a0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Sep 2007 15:32:29.0576 (UTC) FILETIME=[CDDA4880:01C7EF08] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6851; t=1188919962; x=1189783962; 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=20VS=3A=20Re=3A=20[Simple]=20[MSRP=20chat]=20Issue=207= 3A=20Syntax=20of=20Nickname=20URI |Sender:=20 |To:=20Brian=20Rosen=20; bh=z4jaiO/BzO7HUShOd4xKqnUODZM8OjZOvGfqQv+LKoA=; b=PJNSf5RbjZIHkeX9vk8exXrqbm1N95BIQ9GFceGmFEfUDPAvffNKNmbrMBiq1lArjTmHFViK ujDLOKZwSdQ1vWaCL7gO7O2ZpwerCIlmz5qK7Ia+RkbzN07RHzv9deRE; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: simple@ietf.org, aki.niemi@nokia.com, miguel.garcia@nsn.com 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 Brian Rosen wrote: > > > > > ------------------------------------------------------------------------ > > *From:* Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > *Sent:* Sunday, September 02, 2007 10:52 PM > *To:* Brian Rosen > *Cc:* Jeroen van Bemmel; Paul Kyzivat; aki.niemi@nokia.com; > miguel.garcia@nsn.com; simple@ietf.org > *Subject:* Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > > > I've read this thread and seem to agree mostly with Aki, but I think > Brian and Paul have some valid points. > > > > I think the system should be designed as follows: > > > > - Agencies: No external nicknames (I think it defeats the purpose of > having a nickname if external ones are allowed). Effectively I'm saying > that every domain runs its own nickname agency and to join one of its > chatrooms, you need to create a local nickname. > > I think you are clear on this: you want to completely disallow a > domain from accepting a nickname registered in another domain. So, for > example, you would prohibit allowing a domain to use an AOL screen name > as a nick name; they have to declare the nickname within the local > domain. You feel strongly that the mechanism should not be made such > that some domains could allow this feature (by, for example, including > the domain in the nickname, and using some other mechanism for > constructing a URI for the nickname). > - Scope: nicknames are reserved per domain. I want to participate in one > or more chatrooms serviced by the same domain discussing slightly > different topics. People certainly do that in IRC today and we don't > want that feature to disappear. Also, I don't want to go reserve my > nickname 10 different times in 10 different chatroom in the same domain. > what is a domain then? Is chat34.example.com a domain? Did you > mean to imply that example.com is the domain? So, for example, > hotmail.com is a different domain from msn.com, right? > > You would prefer to register your nickname in 100 different chat servers > you might use, rather than asking them to use one your registered > somewhere else, right? Again, you want to prohibit this kind of > behavior, or perhaps more positive, you don’t want the mechanism > complicated in any way to allow such a capability. I'm with Brian here - I'm sympathetic to arguments that we don't want this to get too complicated so that it slows down availability of *something*. But I think this is a desirable capability, so we should keep in mind that it is something we want eventually, and so avoid doing something that precludes it. > - Permanency: a nickname is temporary in nature until the user exits the > domain (logs off). A user can reserve a permanent nickname by doing an > out of band transaction with the domain administrators. Perhaps the > domain wants you to pay $$$ for doing that. > > So you would not want to have, at any time, a standardized way to > request a permanent nickname. You might want to explain a little about > how you use a permanent as opposed to a temporary nickname. Let’s say, > for example, that there was a chat where I was not in that particular > chat, but someone else wanted to use my nickname. Would you allow that? > > I’m a little unclear if you would find any value in a registered nickname. > > - Uniqueness: I think nicknames should be unique. There seems to be > people who want clashing nicknames. Fair enough, different people have > different agendas. So, I think its a fair compramise if we allow > collisions, but device a mechanism for servers force nickname uniqueness > and rejects conflicting nichnames (error responses etc). > > Here we have common ground. You want to allow a service to allow > collisions, and you want a way for a service to not allow collisions. I > agree. It’s policy at the service, and clients have to cope with either > policy. IMO, a nickname (when qualified with its domain) should be expected to uniquely identify a single "individual". There could be multiple sessions within a given conference using the same nickname with the expectation that they are sessions belonging to the same individual. Having multiple sessions of this sort should be fine. There should however be authentication of the user of a particular nickname so provide some assurance it is the same person. (Or at least a group of people that are actively collaborating to pretend to be a single person.) OTOH, two nicknames with different domains might have the same "user part". IMO it should be assumed that these could identify unrelated individuals. In principle I see no reason not to allow conflicts of this sort within a conference. But I can go along with a policy that doesn't allow it, if that is what it takes to get consensus. > - Routability: I don't see myself joining a chatroom and wanting to > display my AoR, but some people might want to in order to enable other > users to contact them directly for private messages outside the chatroom > service, invite them to a voice call or whatever media. In this case, an > AoR display in warranted. For me, I will request anonymity, for Brain, > he will not and will diplay his AoR to the rest of the participants. A > compramise is to have an AoR as well as a routable nickname. A user is > reachable on both. AoR is used to reach a user directly, the nickname is > used to reach the user via the chatroom. Perhaps diplaying both for > users not requesting anonymity and just the routable nickname for those > who do request anonymity. > > I think we’re agreeing on principal, but disagreeing on mechanism. We > agree that you should be able to be addressed by AoR if you are okay > with that, and we agree you should be addressable by some other URI if > you don’t want to be addressable by your AoR. We agree that your > nickname is associated with the URI (be it an AoR or something else). > Is there a particular reason why you need to have the nickname itself in > the alternate AoR? Would some other anonymous URI, associated by all > with your nickname in the roster, be an acceptable URI or does it have > to be nick@domain? > > Is there some advantage to having the nick itself in the URI? > > One problem, however, is present in the last point: since some servers > will allow collisions in nicknames, a nickname can no longer be routable > (if 2 or more users sharing the same nickname are all anonymous) and > therefore requires a uniqueness attribute. In that case I think we assume they are multiple instances serving the same individual, and just fork to them all, just like an AOR. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 04 16:16: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 1ISenj-0006zR-RU; Tue, 04 Sep 2007 16:15:07 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ISeng-0006wL-3j for simple-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 16:15:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISenf-0006vV-Oq; Tue, 04 Sep 2007 16:15:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISene-0003QK-KN; Tue, 04 Sep 2007 16:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 8D7D832896; Tue, 4 Sep 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ISene-0000uR-FY; Tue, 04 Sep 2007 16:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 04 Sep 2007 16:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-08.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 : Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF) Author(s) : M. Lonnfors, K. Kiss Filename : draft-ietf-simple-prescaps-ext-08.txt Pages : 30 Date : 2007-9-4 Presence Information Data Format (PIDF) defines a common presence data format for Common Profile for Presence (CPP) compliant Presence protocols. This memo defines an extension to represent SIP User Agent capabilities in the Presence Information Document Format (PIDF) compliant presence documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext-08.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-prescaps-ext-08.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-prescaps-ext-08.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-9-4154830.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-prescaps-ext-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-prescaps-ext-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-4154830.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 Tue Sep 04 19:38: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 1IShwk-0004oz-Id; Tue, 04 Sep 2007 19:36:38 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IShwi-0004oq-Q9 for simple-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 19:36:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IShwi-0004oi-GO for simple@ietf.org; Tue, 04 Sep 2007 19:36:36 -0400 Received: from nz-out-0506.google.com ([64.233.162.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IShwh-0008RM-0F for simple@ietf.org; Tue, 04 Sep 2007 19:36:36 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1087423nzf for ; Tue, 04 Sep 2007 16:36:34 -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:cc:in-reply-to:mime-version:content-type:references; b=sT/mSusz1K739dZzDrkGEzhP/0pnuX55R3XQZ52Pr7WeqrAf1DpUtnoD1GmZfgP5o7JOjoi/t6Pr9+Aa7QExljoIZiaKlOQpmVglx3RvGMGF3xmp+eljfFBRv/JsnYV3bk7LreapXH2G/GViEz8kiecuMEjP8+i4gov4kiBGjc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ZF0u8vt82UgUHlEE8URrllYlXjSBkQciIMD7vQPuIcYzc3UnZpk7mhFIuk340zJA9YRrKM5jMS0Iy6wjUuLFMfrrvug1GI505MBfqCx6TLBJiZ9QbTyCOTD0ldHRh42lapX0HGdwwh08x8SX67MWC1crnfNCGd4ETjxlBlTGrU4= Received: by 10.64.196.9 with SMTP id t9mr11506449qbf.1188948993019; Tue, 04 Sep 2007 16:36:33 -0700 (PDT) Received: by 10.65.254.11 with HTTP; Tue, 4 Sep 2007 16:36:32 -0700 (PDT) Message-ID: <66cd252f0709041636n50083b56m19e2f1f67dab58c5@mail.gmail.com> Date: Wed, 5 Sep 2007 09:36:32 +1000 From: "Hisham Khartabil" To: "Brian Rosen" Subject: Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI In-Reply-To: <070401c7ef02$a04555a0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 References: <46C5C495.8030601@cisco.com> <000601c7e0e9$47648400$0601a8c0@BEMBUSTER> <00be01c7e0ea$65d53870$0700a8c0@cis.neustar.com> <66cd252f0709021951t628d7a84ybe2229b370225467@mail.gmail.com> <070401c7ef02$a04555a0$640fa8c0@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Cc: simple@ietf.org, Paul Kyzivat , miguel.garcia@nsn.com, aki.niemi@nokia.com 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="===============1542680992==" Errors-To: simple-bounces@ietf.org --===============1542680992== Content-Type: multipart/alternative; boundary="----=_Part_30032_4918984.1188948992604" ------=_Part_30032_4918984.1188948992604 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Please keep in mind that my scope is MSRP chat in SIMPLE (the niemi draft) and not the general mechanism to be addressed in the future. More comments inline... On 05/09/07, Brian Rosen wrote: > > > > > ------------------------------ > > *From:* Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > *Sent:* Sunday, September 02, 2007 10:52 PM > *To:* Brian Rosen > *Cc:* Jeroen van Bemmel; Paul Kyzivat; aki.niemi@nokia.com; > miguel.garcia@nsn.com; simple@ietf.org > *Subject:* Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname > URI > > > > I've read this thread and seem to agree mostly with Aki, but I think Brian > and Paul have some valid points. > > > > I think the system should be designed as follows: > > > > - Agencies: No external nicknames (I think it defeats the purpose of > having a nickname if external ones are allowed). Effectively I'm saying that > every domain runs its own nickname agency and to join one of its chatrooms, > you need to create a local nickname. > > I think you are clear on this: you want to completely disallow a > domain from accepting a nickname registered in another domain. So, for > example, you would prohibit allowing a domain to use an AOL screen name as a > nick name; they have to declare the nickname within the local domain. You > feel strongly that the mechanism should not be made such that some domains > could allow this feature (by, for example, including the domain in the > nickname, and using some other mechanism for constructing a URI for the > nickname). > > > I don't want to disallow. I want to be silent on the issue of external nicknames in this draft. Just define a mechanism for local nicknames in this draft. - Scope: nicknames are reserved per domain. I want to participate in one > or more chatrooms serviced by the same domain discussing slightly different > topics. People certainly do that in IRC today and we don't want that feature > to disappear. Also, I don't want to go reserve my nickname 10 different > times in 10 different chatroom in the same domain. > what is a domain then? Is chat34.example.com a domain? Did you > mean to imply that example.com is the domain? So, for example, > hotmail.com is a different domain from msn.com, right? > right. You would prefer to register your nickname in 100 different chat servers > you might use, rather than asking them to use one your registered somewhere > else, right? > Yes, but only for this draft's scope. Again, the general mechanism should allow for your requirement. Again, you want to prohibit this kind of behavior, or perhaps more > positive, you don't want the mechanism complicated in any way to allow such > a capability. > Again, I don't want to prohibit. I want to be silent on the issue. > > - Permanency: a nickname is temporary in nature until the user exits the > domain (logs off). A user can reserve a permanent nickname by doing an out > of band transaction with the domain administrators. Perhaps the domain wants > you to pay $$$ for doing that. > > So you would not want to have, at any time, a standardized way to request > a permanent nickname. > Yes, but only for this draft's scope. Again, the general mechanism should allow for your requirement. You might want to explain a little about how you use a permanent as > opposed to a temporary nickname. Let's say, for example, that there was a > chat where I was not in that particular chat, but someone else wanted to use > my nickname. Would you allow that? > I would not allow that since my client paid me to "permanently" reserve this nickname. This is policy. > > I'm a little unclear if you would find any value in a registered nickname. > > I'm not yet convinced that there is value. But I can be. > > - Uniqueness: I think nicknames should be unique. There seems to be people > who want clashing nicknames. Fair enough, different people have different > agendas. So, I think its a fair compramise if we allow collisions, but > device a mechanism for servers force nickname uniqueness and rejects > conflicting nichnames (error responses etc). > > Here we have common ground. You want to allow a service to allow > collisions, and you want a way for a service to not allow collisions. I > agree. It's policy at the service, and clients have to cope with either > policy. > > > > - Routability: I don't see myself joining a chatroom and wanting to > display my AoR, but some people might want to in order to enable other users > to contact them directly for private messages outside the chatroom service, > invite them to a voice call or whatever media. In this case, an AoR display > in warranted. For me, I will request anonymity, for Brain, he will not and > will diplay his AoR to the rest of the participants. A compramise is to have > an AoR as well as a routable nickname. A user is reachable on both. AoR is > used to reach a user directly, the nickname is used to reach the user via > the chatroom. Perhaps diplaying both for users not requesting anonymity and > just the routable nickname for those who do request anonymity. > > I think we're agreeing on principal, but disagreeing on mechanism. We > agree that you should be able to be addressed by AoR if you are okay with > that, and we agree you should be addressable by some other URI if you don't > want to be addressable by your AoR. We agree that your nickname is > associated with the URI (be it an AoR or something else). Is there a > particular reason why you need to have the nickname itself in the alternate > AoR? Would some other anonymous URI, associated by all with your nickname > in the roster, be an acceptable URI or does it have to be nick@domain? > > > > Is there some advantage to having the nick itself in the URI? > Yes. It might get Aki to agree :) > > > > One problem, however, is present in the last point: since some servers > will allow collisions in nicknames, a nickname can no longer be routable (if > 2 or more users sharing the same nickname are all anonymous) and therefore > requires a uniqueness attribute. > > Yes > So does having a uniquess attribute still clasify them as conflicting? Regards, Hisham > ------=_Part_30032_4918984.1188948992604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Please keep in mind that my scope is MSRP chat in SIMPLE (the niemi draft) and not the general mechanism to be addressed in the future. More comments inline...

On 05/09/07, Brian Rosen <br@brianrosen.net> wrote:

 

 

From: Hisham Khartabil [mailto: hisham.khartabil@gmail.com]
Sent: Sunday, September 02, 2007 10:52 PM
To: Brian Rosen
Cc: Jeroen van Bemmel; Paul Kyzivat; aki.niemi@nokia.com; miguel.garcia@nsn.com; simple@ietf.org
Subject: Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI

 

I've read this thread and seem to agree mostly with Aki, but I think Brian and Paul have some valid points.

 

I think the system should be designed as follows:

 

- Agencies: No external nicknames (I think it defeats the purpose of having a nickname if external ones are allowed). Effectively I'm saying that every domain runs its own nickname agency and to join one of its chatrooms, you need to create a local nickname.

<brian>I think you are clear on this: you want to completely disallow a domain from accepting a nickname registered in another domain.  So, for example, you would prohibit allowing a domain to use an AOL screen name as a nick name; they have to declare the nickname within the local domain.  You feel strongly that the mechanism should not be made such that some domains could allow this feature (by, for example, including the domain in the nickname, and using some other mechanism for constructing a URI for the nickname). 

 

 
I don't want to disallow. I want to be silent on the issue of external nicknames in this draft. Just define a mechanism for local nicknames in this draft.

- Scope: nicknames are reserved per domain. I want to participate in one or more chatrooms serviced by the same domain discussing slightly different topics. People certainly do that in IRC today and we don't want that feature to disappear. Also, I don't want to go reserve my nickname 10 different times in 10 different chatroom in the same domain.
<brian>what is a domain then?  Is chat34.example.com a domain?  Did you mean to imply that example.com is the domain?  So, for example, hotmail.com is a different domain from msn.com, right?

 
right.

You would prefer to register your nickname in 100 different chat servers you might use, rather than asking them to use one your registered somewhere else, right?  

 
Yes, but only for this draft's scope. Again, the general mechanism should allow for your requirement.

Again, you want to prohibit this kind of behavior, or perhaps more positive, you don't want the mechanism complicated in any way to allow such a capability.

Again, I don't want to prohibit. I want to be silent on the issue.
 

 

- Permanency: a nickname is temporary in nature until the user exits the domain (logs off). A user can reserve a permanent nickname by doing an out of band transaction with the domain administrators. Perhaps the domain wants you to pay $$$ for doing that.

So you would not want to have, at any time, a standardized way to request a permanent nickname.

Yes, but only for this draft's scope. Again, the general mechanism should allow for your requirement.
 

  You might want to explain a little about how you use a permanent as opposed to a temporary nickname.  Let's say, for example, that there was a chat where I was not in that particular chat, but someone else wanted to use my nickname.  Would you allow that?

 
I would not allow that since my client paid me to "permanently" reserve this nickname. This is policy.

 

I'm a little unclear if you would find any value in a registered nickname.

 
I'm not yet convinced that there is value. But I can be.

 

- Uniqueness: I think nicknames should be unique. There seems to be people who want clashing nicknames. Fair enough, different people have different agendas. So, I think its a fair compramise if we allow collisions, but device a mechanism for servers force nickname uniqueness and rejects conflicting nichnames (error responses etc).

Here we have common ground.  You want to allow a service to allow collisions, and you want a way for a service to not allow collisions.  I agree.  It's policy at the service, and clients have to cope with either policy.

 

- Routability: I don't see myself joining a chatroom and wanting to display my AoR, but some people might want to in order to enable other users to contact them directly for private messages outside the chatroom service, invite them to a voice call or whatever media. In this case, an AoR display in warranted. For me, I will request anonymity, for Brain, he will not and will diplay his AoR to the rest of the participants. A compramise is to have an AoR  as well as a routable nickname. A user is reachable on both. AoR is used to reach a user directly, the nickname is used to reach the user via the chatroom. Perhaps diplaying both for users not requesting anonymity and just the routable nickname for those who do request anonymity.

I think we're agreeing on principal, but disagreeing on mechanism.  We agree that you should be able to be addressed by AoR if you are okay with that, and we agree you should be addressable by some other URI if you don't want to be addressable by your AoR.  We agree that your nickname is associated with the URI (be it an AoR or something else).  Is there a particular reason why you need to have the nickname itself in the alternate AoR?  Would some other anonymous URI, associated by all with your nickname in the roster, be an acceptable URI or does it have to be nick@domain?

 

Is there some advantage to having the nick itself in the URI?

 
Yes. It might get Aki to agree :)

 

 

One problem, however, is present in the last point: since some servers will allow collisions in nicknames, a nickname can no longer be routable (if 2 or more users sharing the same nickname are all anonymous) and therefore requires a uniqueness attribute.

Yes

 
So does having a uniquess attribute still clasify them as conflicting?
 
Regards,
Hisham

 


------=_Part_30032_4918984.1188948992604-- --===============1542680992== 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 --===============1542680992==-- From simple-bounces@ietf.org Tue Sep 04 19:40:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IShyj-0006fE-On; Tue, 04 Sep 2007 19:38:41 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IShyj-0006f9-1d for simple-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 19:38:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IShyi-0006f1-OF for simple@ietf.org; Tue, 04 Sep 2007 19:38:40 -0400 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IShyh-0008UR-Bl for simple@ietf.org; Tue, 04 Sep 2007 19:38:40 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1087741nzf for ; Tue, 04 Sep 2007 16:38:39 -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:cc:in-reply-to:mime-version:content-type:references; b=CbI2tXRH6nH2JR69AZnaIIPaOx2diQnMl4fRcjjgpp7EClw7P9CnyWOiBpoz1+Q7JIxjMRkMnYqwYHVp9ZFwQfE9ELHRk5Y8wwdgBodRSAqxTZgD3PJMl+gHG7o0+0HHEA6wN2dD4lpXpnQu1pa/FL68VslXBAksPYymjmmkwo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=maeec+/3f+vXOaqJjrbPQnKsH5Bk/UzqHsh0UCNSvADhLkPFU+crlG/F8+NcrsQoBWUcK3WsOJSHHCBKSMFlLj5QtOlDJy8eC1XRSltYMyID0yI35PqZ0COu9ybMDQldi5yPMJ3tmLuKMzglhQ+0A39tGQr9qpkfm0vqZwFy9Fs= Received: by 10.65.214.19 with SMTP id r19mr11576341qbq.1188949117944; Tue, 04 Sep 2007 16:38:37 -0700 (PDT) Received: by 10.65.254.11 with HTTP; Tue, 4 Sep 2007 16:38:37 -0700 (PDT) Message-ID: <66cd252f0709041638s74841a23yb1d0de85169629e4@mail.gmail.com> Date: Wed, 5 Sep 2007 09:38:37 +1000 From: "Hisham Khartabil" To: "Paul Kyzivat" Subject: Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI In-Reply-To: <46DD7A8B.1070905@cisco.com> MIME-Version: 1.0 References: <46C5C495.8030601@cisco.com> <000601c7e0e9$47648400$0601a8c0@BEMBUSTER> <00be01c7e0ea$65d53870$0700a8c0@cis.neustar.com> <66cd252f0709021951t628d7a84ybe2229b370225467@mail.gmail.com> <070401c7ef02$a04555a0$640fa8c0@cis.neustar.com> <46DD7A8B.1070905@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: simple@ietf.org, aki.niemi@nokia.com, miguel.garcia@nsn.com 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="===============1585514373==" Errors-To: simple-bounces@ietf.org --===============1585514373== Content-Type: multipart/alternative; boundary="----=_Part_30052_10820425.1188949117879" ------=_Part_30052_10820425.1188949117879 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 05/09/07, Paul Kyzivat wrote: > > > > Brian Rosen wrote: > > > > > > > > > > ------------------------------------------------------------------------ > > > > *From:* Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > > *Sent:* Sunday, September 02, 2007 10:52 PM > > *To:* Brian Rosen > > *Cc:* Jeroen van Bemmel; Paul Kyzivat; aki.niemi@nokia.com; > > miguel.garcia@nsn.com; simple@ietf.org > > *Subject:* Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname > URI > > > > > > > > I've read this thread and seem to agree mostly with Aki, but I think > > Brian and Paul have some valid points. > > > > > > > > I think the system should be designed as follows: > > > > > > > > - Agencies: No external nicknames (I think it defeats the purpose of > > having a nickname if external ones are allowed). Effectively I'm saying > > that every domain runs its own nickname agency and to join one of its > > chatrooms, you need to create a local nickname. > > > > I think you are clear on this: you want to completely disallow a > > domain from accepting a nickname registered in another domain. So, for > > example, you would prohibit allowing a domain to use an AOL screen name > > as a nick name; they have to declare the nickname within the local > > domain. You feel strongly that the mechanism should not be made such > > that some domains could allow this feature (by, for example, including > > the domain in the nickname, and using some other mechanism for > > constructing a URI for the nickname). > > > - Scope: nicknames are reserved per domain. I want to participate in one > > or more chatrooms serviced by the same domain discussing slightly > > different topics. People certainly do that in IRC today and we don't > > want that feature to disappear. Also, I don't want to go reserve my > > nickname 10 different times in 10 different chatroom in the same domain. > > what is a domain then? Is chat34.example.com a domain? Did you > > mean to imply that example.com is the domain? So, for example, > > hotmail.com is a different domain from msn.com, right? > > > > You would prefer to register your nickname in 100 different chat servers > > you might use, rather than asking them to use one your registered > > somewhere else, right? Again, you want to prohibit this kind of > > behavior, or perhaps more positive, you don't want the mechanism > > complicated in any way to allow such a capability. > > I'm with Brian here - I'm sympathetic to arguments that we don't want > this to get too complicated so that it slows down availability of > *something*. But I think this is a desirable capability, so we should > keep in mind that it is something we want eventually, and so avoid doing > something that precludes it. > > > - Permanency: a nickname is temporary in nature until the user exits the > > domain (logs off). A user can reserve a permanent nickname by doing an > > out of band transaction with the domain administrators. Perhaps the > > domain wants you to pay $$$ for doing that. > > > > So you would not want to have, at any time, a standardized way to > > request a permanent nickname. You might want to explain a little about > > how you use a permanent as opposed to a temporary nickname. Let's say, > > for example, that there was a chat where I was not in that particular > > chat, but someone else wanted to use my nickname. Would you allow that? > > > > I'm a little unclear if you would find any value in a registered > nickname. > > > > - Uniqueness: I think nicknames should be unique. There seems to be > > people who want clashing nicknames. Fair enough, different people have > > different agendas. So, I think its a fair compramise if we allow > > collisions, but device a mechanism for servers force nickname uniqueness > > and rejects conflicting nichnames (error responses etc). > > > > Here we have common ground. You want to allow a service to allow > > collisions, and you want a way for a service to not allow collisions. I > > agree. It's policy at the service, and clients have to cope with either > > policy. > > IMO, a nickname (when qualified with its domain) should be expected to > uniquely identify a single "individual". There could be multiple > sessions within a given conference using the same nickname with the > expectation that they are sessions belonging to the same individual. > Having multiple sessions of this sort should be fine. There should > however be authentication of the user of a particular nickname so > provide some assurance it is the same person. (Or at least a group of > people that are actively collaborating to pretend to be a single person.) > > OTOH, two nicknames with different domains might have the same "user > part". IMO it should be assumed that these could identify unrelated > individuals. In principle I see no reason not to allow conflicts of this > sort within a conference. But I can go along with a policy that doesn't > allow it, if that is what it takes to get consensus. > > > - Routability: I don't see myself joining a chatroom and wanting to > > display my AoR, but some people might want to in order to enable other > > users to contact them directly for private messages outside the chatroom > > service, invite them to a voice call or whatever media. In this case, an > > AoR display in warranted. For me, I will request anonymity, for Brain, > > he will not and will diplay his AoR to the rest of the participants. A > > compramise is to have an AoR as well as a routable nickname. A user is > > reachable on both. AoR is used to reach a user directly, the nickname is > > used to reach the user via the chatroom. Perhaps diplaying both for > > users not requesting anonymity and just the routable nickname for those > > who do request anonymity. > > > > I think we're agreeing on principal, but disagreeing on mechanism. We > > agree that you should be able to be addressed by AoR if you are okay > > with that, and we agree you should be addressable by some other URI if > > you don't want to be addressable by your AoR. We agree that your > > nickname is associated with the URI (be it an AoR or something else). > > Is there a particular reason why you need to have the nickname itself in > > the alternate AoR? Would some other anonymous URI, associated by all > > with your nickname in the roster, be an acceptable URI or does it have > > to be nick@domain? > > > > Is there some advantage to having the nick itself in the URI? > > > > One problem, however, is present in the last point: since some servers > > will allow collisions in nicknames, a nickname can no longer be routable > > (if 2 or more users sharing the same nickname are all anonymous) and > > therefore requires a uniqueness attribute. > > In that case I think we assume they are multiple instances serving the > same individual, and just fork to them all, just like an AOR. Are you sure you want that? We are talking about private messages here. Hisham Paul > ------=_Part_30052_10820425.1188949117879 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 05/09/07, Paul Kyzivat <pkyzivat@cisco.com> wrote:


Brian Rosen wrote:
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:* Hisham Khartabil [mailto:hisham.khartabil@gmail.com]
> *Sent:* Sunday, September 02, 2007 10:52 PM
> *To:* Brian Rosen
> *Cc:* Jeroen van Bemmel; Paul Kyzivat; aki.niemi@nokia.com;
> miguel.garcia@nsn.com; simple@ietf.org
> *Subject:* Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI
>
>
>
> I've read this thread and seem to agree mostly with Aki, but I think
> Brian and Paul have some valid points.
>
>
>
> I think the system should be designed as follows:
>
>
>
> - Agencies: No external nicknames (I think it defeats the purpose of
> having a nickname if external ones are allowed). Effectively I'm saying
> that every domain runs its own nickname agency and to join one of its
> chatrooms, you need to create a local nickname.
>
> <brian>I think you are clear on this: you want to completely disallow a
> domain from accepting a nickname registered in another domain.  So, for
> example, you would prohibit allowing a domain to use an AOL screen name
> as a nick name; they have to declare the nickname within the local
> domain.  You feel strongly that the mechanism should not be made such
> that some domains could allow this feature (by, for example, including
> the domain in the nickname, and using some other mechanism for
> constructing a URI for the nickname).

> - Scope: nicknames are reserved per domain. I want to participate in one
> or more chatrooms serviced by the same domain discussing slightly
> different topics. People certainly do that in IRC today and we don't
> want that feature to disappear. Also, I don't want to go reserve my
> nickname 10 different times in 10 different chatroom in the same domain.
> <brian>what is a domain then?  Is chat34.example.com a domain?  Did you
> mean to imply that example.com is the domain?  So, for example,
> hotmail.com is a different domain from msn.com, right?
>
> You would prefer to register your nickname in 100 different chat servers
> you might use, rather than asking them to use one your registered
> somewhere else, right?   Again, you want to prohibit this kind of
> behavior, or perhaps more positive, you don't want the mechanism
> complicated in any way to allow such a capability.

I'm with Brian here - I'm sympathetic to arguments that we don't want
this to get too complicated so that it slows down availability of
*something*. But I think this is a desirable capability, so we should
keep in mind that it is something we want eventually, and so avoid doing
something that precludes it.

> - Permanency: a nickname is temporary in nature until the user exits the
> domain (logs off). A user can reserve a permanent nickname by doing an
> out of band transaction with the domain administrators. Perhaps the
> domain wants you to pay $$$ for doing that.
>
> So you would not want to have, at any time, a standardized way to
> request a permanent nickname.  You might want to explain a little about
> how you use a permanent as opposed to a temporary nickname.  Let's say,
> for example, that there was a chat where I was not in that particular
> chat, but someone else wanted to use my nickname.  Would you allow that?
>
> I'm a little unclear if you would find any value in a registered nickname.
>
> - Uniqueness: I think nicknames should be unique. There seems to be
> people who want clashing nicknames. Fair enough, different people have
> different agendas. So, I think its a fair compramise if we allow
> collisions, but device a mechanism for servers force nickname uniqueness
> and rejects conflicting nichnames (error responses etc).
>
> Here we have common ground.  You want to allow a service to allow
> collisions, and you want a way for a service to not allow collisions.  I
> agree.  It's policy at the service, and clients have to cope with either
> policy.

IMO, a nickname (when qualified with its domain) should be expected to
uniquely identify a single "individual". There could be multiple
sessions within a given conference using the same nickname with the
expectation that they are sessions belonging to the same individual.
Having multiple sessions of this sort should be fine. There should
however be authentication of the user of a particular nickname so
provide some assurance it is the same person.  (Or at least a group of
people that are actively collaborating to pretend to be a single person.)

OTOH, two nicknames with different domains might have the same "user
part". IMO it should be assumed that these could identify unrelated
individuals. In principle I see no reason not to allow conflicts of this
sort within a conference. But I can go along with a policy that doesn't
allow it, if that is what it takes to get consensus.

> - Routability: I don't see myself joining a chatroom and wanting to
> display my AoR, but some people might want to in order to enable other
> users to contact them directly for private messages outside the chatroom
> service, invite them to a voice call or whatever media. In this case, an
> AoR display in warranted. For me, I will request anonymity, for Brain,
> he will not and will diplay his AoR to the rest of the participants. A
> compramise is to have an AoR  as well as a routable nickname. A user is
> reachable on both. AoR is used to reach a user directly, the nickname is
> used to reach the user via the chatroom. Perhaps diplaying both for
> users not requesting anonymity and just the routable nickname for those
> who do request anonymity.
>
> I think we're agreeing on principal, but disagreeing on mechanism.  We
> agree that you should be able to be addressed by AoR if you are okay
> with that, and we agree you should be addressable by some other URI if
> you don't want to be addressable by your AoR.  We agree that your
> nickname is associated with the URI (be it an AoR or something else).
> Is there a particular reason why you need to have the nickname itself in
> the alternate AoR?  Would some other anonymous URI, associated by all
> with your nickname in the roster, be an acceptable URI or does it have
> to be nick@domain?
>
> Is there some advantage to having the nick itself in the URI?
>
> One problem, however, is present in the last point: since some servers
> will allow collisions in nicknames, a nickname can no longer be routable
> (if 2 or more users sharing the same nickname are all anonymous) and
> therefore requires a uniqueness attribute.

In that case I think we assume they are multiple instances serving the
same individual, and just fork to them all, just like an AOR.
 
 
Are you sure you want that? We are talking about private messages here.
 
Hisham

       Paul

------=_Part_30052_10820425.1188949117879-- --===============1585514373== 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 --===============1585514373==-- From simple-bounces@ietf.org Wed Sep 05 08:22: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 1IStsa-0006tx-N7; Wed, 05 Sep 2007 08:21:08 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IStsZ-0006ts-BY for simple-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 08:21:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IStsY-0006tk-VV for simple@ietf.org; Wed, 05 Sep 2007 08:21:06 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IStsX-0001YE-FS for simple@ietf.org; Wed, 05 Sep 2007 08:21:06 -0400 Received: from [24.154.127.115] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IStsJ-0004So-Hk; Wed, 05 Sep 2007 07:20:51 -0500 From: "Brian Rosen" To: "'Hisham Khartabil'" References: <46C5C495.8030601@cisco.com> <000601c7e0e9$47648400$0601a8c0@BEMBUSTER> <00be01c7e0ea$65d53870$0700a8c0@cis.neustar.com> <66cd252f0709021951t628d7a84ybe2229b370225467@mail.gmail.com> <070401c7ef02$a04555a0$640fa8c0@cis.neustar.com> <66cd252f0709041636n50083b56m19e2f1f67dab58c5@mail.gmail.com> Subject: RE: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Wed, 5 Sep 2007 08:20:56 -0400 Message-ID: <092901c7efb7$373544c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <66cd252f0709041636n50083b56m19e2f1f67dab58c5@mail.gmail.com> Thread-Index: AcfvTGjoHJZrN9UpSFa1m7f0DkthDwAaUkhA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69aba9e925a1047819f53b40fa4fc4e6 Cc: simple@ietf.org, 'Paul Kyzivat' , miguel.garcia@nsn.com, aki.niemi@nokia.com 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="===============1841709517==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1841709517== Content-Type: multipart/alternative; boundary="----=_NextPart_000_092A_01C7EF95.B023A4C0" This is a multi-part message in MIME format. ------=_NextPart_000_092A_01C7EF95.B023A4C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I believe the current proposal from Paul, which I am happy with is: >> - The MSRP nickname request be allowed with either just or with >> @. >> >> - The name-only form is a request to assign the name within >> a domain unique to the focus, for the duration of participation, and >> then associate it with the participant. This can fail if the name >> is already in use by a participant with a different identity. >> >> - The @ form requests that the focus verify with a >> server for the domain that the requester is allowed to use >> the nickname, and then associate it with the participant. >> This can fail if the focus doesn't support it, if it doesn't >> know how to do verification with that domain, or if verification >> fails. >> >> - Eventually there will be some other, more general, mechanism for >> doing temporary nickname assignment and nickname association, >> independent of MSRP. That is still TBD. >> >> - Nicknames don't appear in CPIM From/To headers. Instead, the >> sip contact address of the participant appears. If the user is >> anonymous, then a surrogate URI provided by the focus appears. >> >> - The association between nicknames and contact addresses is learned >> by each participant via an enhancement to the conference event >> package. The nicknames delivered this way always are of the >> @ form. >> >> - The chat UI is responsible for obtaining nicknames corresponding >> to received messages and rendering them in a user-friendly way. >> If this is burdensome, we could consider having the focus >> include the nickname as a display name in the CPIM From header. >> (I'm not wild about it, but it is a possible optimization.) >From your position, it would seem we are asking for the "@domain" to be permitted in the nick request and conference roster, and that the contact URI is used in MSRP From/To. Do you have an objection to that? I'd be okay with saying MSRP chat doesn't define how "the focus verify with a server for the domain that the requester is allowed to use the nickname". That can be something the generalized mechanism supports. Brian ------=_NextPart_000_092A_01C7EF95.B023A4C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I believe the current proposal from = Paul, which I am happy with is:

>> - The MSRP = nickname request be allowed with either just <name> or = with

>>    <name>@<domain>.

>> 

>> - The = name-only form is a request to assign the name within

>>    a domain unique to the focus, for the duration of participation, = and

>>    then associate it with the participant. This can fail if the = name

>>    is already in use by a participant with a different = identity.

>> 

>> - The <name>@<domain> form requests that the focus verify with = a

>>    server for the domain that the requester is allowed to = use

>>    the nickname, and then associate it with the = participant.

>>    This can fail if the focus doesn't support it, if it = doesn't

>>    know how to do verification with that domain, or if = verification

>>    fails.

>> 

>> - = Eventually there will be some other, more general, mechanism = for

>>    doing temporary nickname assignment and nickname = association,

>>    independent of MSRP. That is still TBD.

>> 

>> - = Nicknames don't appear in CPIM From/To headers. Instead, = the

>>    sip contact address of the participant appears. If the user = is

>>    anonymous, then a surrogate URI provided by the focus = appears.

>> 

>> - The = association between nicknames and contact addresses is = learned

>>    by each participant via an enhancement to the conference = event

>>    package. The nicknames delivered this way always are of = the

>>    <name>@<domain> form.

>> 

>> - The chat = UI is responsible for obtaining nicknames = corresponding

>>    to received messages and rendering them in a user-friendly = way.

>>    If this is burdensome, we could consider having the = focus

>>    include the nickname as a display name in the CPIM From = header.

>>    (I'm not wild about it, but it is a possible = optimization.)

From your position, it would seem = we are asking for the “@domain” to be permitted in the nick request = and conference roster, and that the contact URI is used in MSRP = From/To.  Do you have an objection to that?

 

I’d be okay with saying MSRP = chat doesn’t define how “the focus verify with a server for the = domain that the requester is allowed to use the nickname”.  That can be something the generalized mechanism = supports.

 

Brian

------=_NextPart_000_092A_01C7EF95.B023A4C0-- --===============1841709517== 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 --===============1841709517==-- From simple-bounces@ietf.org Thu Sep 06 04:53: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 1ITD5K-000057-1O; Thu, 06 Sep 2007 04:51:34 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ITD5I-000050-Gk for simple-confirm+ok@megatron.ietf.org; Thu, 06 Sep 2007 04:51:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITD5I-00004s-4U for simple@ietf.org; Thu, 06 Sep 2007 04:51:32 -0400 Received: from [85.17.186.5] (helo=node05.dns-hosting.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITD5G-0008Kh-NL for simple@ietf.org; Thu, 06 Sep 2007 04:51:32 -0400 Received: from 5571fc03.ftth.concepts.nl ([85.113.252.3] helo=[192.168.1.200]) by node05.dns-hosting.info with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.67) (envelope-from ) id 1ITD5F-0006I5-1L for simple@ietf.org; Thu, 06 Sep 2007 10:51:29 +0200 Message-ID: <46DFBF8E.9000609@ag-projects.com> Date: Thu, 06 Sep 2007 10:51:26 +0200 From: Ruud Klaver User-Agent: Thunderbird 2.0.0.6 (X11/20070903) MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 85.113.252.3 X-SA-Exim-Mail-From: ruud@ag-projects.com X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on node05.dns-hosting.info X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.1 X-SA-Exim-Version: 4.2.1 (built Thu, 26 Apr 2007 18:30:04 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Simple] MSRP relay implementation issue; domains & scalability 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, I am planning on implementing a MSRP relay according to the specification and have come across an issue. In the interest of scalability I would like a pool of relays to be able to service users from several domains. However, the current specification has no provision for the authenticating endpoint to supply a domain, only a username and assword. In practice, this means running a separate server instance for each domain, which is not very scalable. My question is, what would be the preferred solution to this? -- Ruud Klaver http://www.ag-projects.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 06 09:06: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 1ITH2A-0001i1-G8; Thu, 06 Sep 2007 09:04:34 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ITH29-0001hl-10 for simple-confirm+ok@megatron.ietf.org; Thu, 06 Sep 2007 09:04:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITH28-0001hb-Nf for simple@ietf.org; Thu, 06 Sep 2007 09:04:32 -0400 Received: from [196.31.225.71] (helo=students.polytechnic.edu.na) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITH22-00069t-Tl for simple@ietf.org; Thu, 06 Sep 2007 09:04:32 -0400 Received: from localhost.polytechnic.edu.na ([127.0.0.1]:58782 helo=students.polytechnic.edu.na) by students.polytechnic.edu.na with esmtp (Exim 4.43) id 1ITGmW-00050a-K1 for simple@ietf.org; Thu, 06 Sep 2007 14:48:25 +0200 From: "s200516914" To: simple@ietf.org Date: Thu, 6 Sep 2007 14:48:24 +0200 Message-Id: <20070906124753.M66159@students.polytechnic.edu.na> In-Reply-To: References: X-Mailer: Open WebMail 2.51 20050627 X-OriginatingIP: 10.1.1.101 (s200516914) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Subject: [Simple] Re: Simple Digest, Vol 41, Issue 5 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 don't send me e-mails anymore. On Wed, 05 Sep 2007 12:01:38 -0400, simple-request wrote > Send Simple mailing list submissions to > simple@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/simple > or, via email, send a message with subject or body 'help' to > simple-request@ietf.org > > You can reach the person managing the list at > simple-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Simple digest..." > > Today's Topics: > > 1. RE: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname > URI (Brian Rosen) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 5 Sep 2007 08:20:56 -0400 > From: "Brian Rosen" > Subject: RE: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname > URI > To: "'Hisham Khartabil'" > Cc: simple@ietf.org, 'Paul Kyzivat' , > miguel.garcia@nsn.com, aki.niemi@nokia.com > Message-ID: <092901c7efb7$373544c0$640fa8c0@cis.neustar.com> > Content-Type: text/plain; charset="us-ascii" > > I believe the current proposal from Paul, which I am happy with is: > > >> - The MSRP nickname request be allowed with either just or with > > >> @. > > >> > > >> - The name-only form is a request to assign the name within > > >> a domain unique to the focus, for the duration of participation, and > > >> then associate it with the participant. This can fail if the name > > >> is already in use by a participant with a different identity. > > >> > > >> - The @ form requests that the focus verify with a > > >> server for the domain that the requester is allowed to use > > >> the nickname, and then associate it with the participant. > > >> This can fail if the focus doesn't support it, if it doesn't > > >> know how to do verification with that domain, or if verification > > >> fails. > > >> > > >> - Eventually there will be some other, more general, mechanism for > > >> doing temporary nickname assignment and nickname association, > > >> independent of MSRP. That is still TBD. > > >> > > >> - Nicknames don't appear in CPIM From/To headers. Instead, the > > >> sip contact address of the participant appears. If the user is > > >> anonymous, then a surrogate URI provided by the focus appears. > > >> > > >> - The association between nicknames and contact addresses is learned > > >> by each participant via an enhancement to the conference event > > >> package. The nicknames delivered this way always are of the > > >> @ form. > > >> > > >> - The chat UI is responsible for obtaining nicknames corresponding > > >> to received messages and rendering them in a user-friendly way. > > >> If this is burdensome, we could consider having the focus > > >> include the nickname as a display name in the CPIM From header. > > >> (I'm not wild about it, but it is a possible optimization.) > > >From your position, it would seem we are asking for the "@domain" to be > permitted in the nick request and conference roster, and that the contact > URI is used in MSRP From/To. Do you have an objection to that? > > I'd be okay with saying MSRP chat doesn't define how "the focus > verify with a server for the domain that the requester is allowed to > use the nickname". That can be something the generalized mechanism supports. > > Brian > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www1.ietf.org/pipermail/simple/attachments/20070905/1a119106/attachment -0001.html > > ------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > End of Simple Digest, Vol 41, Issue 5 > ************************************* -- Open WebMail Project (http://openwebmail.org) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 07 02:40: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 1ITXUa-0005S7-3S; Fri, 07 Sep 2007 02:39:00 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ITXUZ-0005S1-JD for simple-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 02:38:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITXUY-0005Rt-Qk for simple@ietf.org; Fri, 07 Sep 2007 02:38:58 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITXUY-0004CL-0I for simple@ietf.org; Fri, 07 Sep 2007 02:38:58 -0400 Received: by py-out-1112.google.com with SMTP id d32so1369798pye for ; Thu, 06 Sep 2007 23:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=FlHWyCI6hB8swK/H8vNGf8yGcPmZYa+8nZU0nFi2Xb4=; b=iS2OcwqbMVKfH8t5M+K0TybXmG8pqbhjUQlJYXsOpYsFN3tiRACmYkBFpjK6h4aQ5Y5O5gG3hmaMsW+TnoL/ljBh9czRATnM+AK3ms1pncPzBxjy0ihQVkNNp2zLVfKT/b0O8xkGe9VOI7XMRiqCe7Vr/NYBPHTiun5eHh9eTAA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=bhmwAvcYWM3IirAE371N5YXJq8ehxk/UQYMVXF3JHTqaN8pgTXA1WHDaSm9ltIXtFP3/g+pcvhVM2/oAe5g5yzfusLGokP+RRZQOxV2Rs/JsgXYruoWxo3UJD8N6lH6zRUUzDI5l1qVsQgAbehQPL1bAobQXP19Z98s9xZxMZ98= Received: by 10.65.191.3 with SMTP id t3mr2801825qbp.1189147136629; Thu, 06 Sep 2007 23:38:56 -0700 (PDT) Received: by 10.65.213.1 with HTTP; Thu, 6 Sep 2007 23:38:56 -0700 (PDT) Message-ID: <66cd252f0709062338y70e547bm955f7a0a0c52c01b@mail.gmail.com> Date: Fri, 7 Sep 2007 16:38:56 +1000 From: "Hisham Khartabil" To: "Brian Rosen" Subject: Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI In-Reply-To: <092901c7efb7$373544c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 References: <46C5C495.8030601@cisco.com> <000601c7e0e9$47648400$0601a8c0@BEMBUSTER> <00be01c7e0ea$65d53870$0700a8c0@cis.neustar.com> <66cd252f0709021951t628d7a84ybe2229b370225467@mail.gmail.com> <070401c7ef02$a04555a0$640fa8c0@cis.neustar.com> <66cd252f0709041636n50083b56m19e2f1f67dab58c5@mail.gmail.com> <092901c7efb7$373544c0$640fa8c0@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: simple@ietf.org, Paul Kyzivat , miguel.garcia@nsn.com, aki.niemi@nokia.com 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="===============1248373260==" Errors-To: simple-bounces@ietf.org --===============1248373260== Content-Type: multipart/alternative; boundary="----=_Part_72572_13014228.1189147136577" ------=_Part_72572_13014228.1189147136577 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 05/09/07, Brian Rosen wrote: > > I believe the current proposal from Paul, which I am happy with is: > > >> - The MSRP nickname request be allowed with either just or with > > >> @. > > >> > > >> - The name-only form is a request to assign the name within > > >> a domain unique to the focus, for the duration of participation, and > > >> then associate it with the participant. This can fail if the name > > >> is already in use by a participant with a different identity. > > >> > > >> - The @ form requests that the focus verify with a > > >> server for the domain that the requester is allowed to use > > >> the nickname, and then associate it with the participant. > > >> This can fail if the focus doesn't support it, if it doesn't > > >> know how to do verification with that domain, or if verification > > >> fails. > > >> > > >> - Eventually there will be some other, more general, mechanism for > > >> doing temporary nickname assignment and nickname association, > > >> independent of MSRP. That is still TBD. > > >> > > >> - Nicknames don't appear in CPIM From/To headers. Instead, the > > >> sip contact address of the participant appears. If the user is > > >> anonymous, then a surrogate URI provided by the focus appears. > > >> > > >> - The association between nicknames and contact addresses is learned > > >> by each participant via an enhancement to the conference event > > >> package. The nicknames delivered this way always are of the > > >> @ form. > > >> > > >> - The chat UI is responsible for obtaining nicknames corresponding > > >> to received messages and rendering them in a user-friendly way. > > >> If this is burdensome, we could consider having the focus > > >> include the nickname as a display name in the CPIM From header. > > >> (I'm not wild about it, but it is a possible optimization.) > > From your position, it would seem we are asking for the "@domain" to be > permitted in the nick request and conference roster, and that the contact > URI is used in MSRP From/To. Do you have an objection to that? > Why can't the nickname "the version with @domain" be represented in the From/To? I'd be okay with saying MSRP chat doesn't define how "the focus verify > with a server for the domain that the requester is allowed to use the > nickname". That can be something the generalized mechanism supports. > We can agree on that. Hisham > > Brian > ------=_Part_72572_13014228.1189147136577 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 05/09/07, Brian Rosen <br@brianrosen.net> wrote:

I believe the current proposal from Paul, which I am happy with is:

>> - The MSRP nickname request be allowed with either just <name> or with

>>    <name>@<domain>.

>> 

>> - The name-only form is a request to assign the name within

>>    a domain unique to the focus, for the duration of participation, and

>>    then associate it with the participant. This can fail if the name

>>    is already in use by a participant with a different identity.

>> 

>> - The <name>@<domain> form requests that the focus verify with a

>>    server for the domain that the requester is allowed to use

>>    the nickname, and then associate it with the participant.

>>    This can fail if the focus doesn't support it, if it doesn't

>>    know how to do verification with that domain, or if verification

>>    fails.

>> 

>> - Eventually there will be some other, more general, mechanism for

>>    doing temporary nickname assignment and nickname association,

>>    independent of MSRP. That is still TBD.

>> 

>> - Nicknames don't appear in CPIM From/To headers. Instead, the

>>    sip contact address of the participant appears. If the user is

>>    anonymous, then a surrogate URI provided by the focus appears.

>> 

>> - The association between nicknames and contact addresses is learned

>>    by each participant via an enhancement to the conference event

>>    package. The nicknames delivered this way always are of the

>>    <name>@<domain> form.

>> 

>> - The chat UI is responsible for obtaining nicknames corresponding

>>    to received messages and rendering them in a user-friendly way.

>>    If this is burdensome, we could consider having the focus

>>    include the nickname as a display name in the CPIM From header.

>>    (I'm not wild about it, but it is a possible optimization.)

From your position, it would seem we are asking for the "@domain" to be permitted in the nick request and conference roster, and that the contact URI is used in MSRP From/To.  Do you have an objection to that?

 
Why can't the nickname "the version with @domain" be represented in the From/To?

I'd be okay with saying MSRP chat doesn't define how "the focus verify with a server for the domain that the requester is allowed to use the nickname".  That can be something the generalized mechanism supports.

 
We can agree on that.
 
Hisham

 

Brian


------=_Part_72572_13014228.1189147136577-- --===============1248373260== 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 --===============1248373260==-- From simple-bounces@ietf.org Sun Sep 09 18:04: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 1IUUrB-0007Ez-V8; Sun, 09 Sep 2007 18:02:17 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IUUrA-0007Eu-ER for simple-confirm+ok@megatron.ietf.org; Sun, 09 Sep 2007 18:02:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUUrA-0007Em-2h for simple@ietf.org; Sun, 09 Sep 2007 18:02:16 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUUr9-0006oI-O6 for simple@ietf.org; Sun, 09 Sep 2007 18:02:15 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IUUqk-0001b4-KI; Sun, 09 Sep 2007 17:01:50 -0500 From: "Brian Rosen" To: "'Hisham Khartabil'" References: <46C5C495.8030601@cisco.com> <000601c7e0e9$47648400$0601a8c0@BEMBUSTER> <00be01c7e0ea$65d53870$0700a8c0@cis.neustar.com> <66cd252f0709021951t628d7a84ybe2229b370225467@mail.gmail.com> <070401c7ef02$a04555a0$640fa8c0@cis.neustar.com> <66cd252f0709041636n50083b56m19e2f1f67dab58c5@mail.gmail.com> <092901c7efb7$373544c0$640fa8c0@cis.neustar.com> <66cd252f0709062338y70e547bm955f7a0a0c52c01b@mail.gmail.com> Subject: RE: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Sun, 9 Sep 2007 18:02:00 -0400 Message-ID: <015201c7f32d$0e245b10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfxGccX0K32QF0mSSCoB5wyERJ85ACElcJQ In-Reply-To: <66cd252f0709062338y70e547bm955f7a0a0c52c01b@mail.gmail.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: simple@ietf.org, 'Paul Kyzivat' , miguel.garcia@nsn.com, aki.niemi@nokia.com 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="===============1728834230==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1728834230== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0153_01C7F30B.8712BB10" This is a multi-part message in MIME format. ------=_NextPart_000_0153_01C7F30B.8712BB10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >From your position, it would seem we are asking for the "@domain" to be permitted in the nick request and conference roster, and that the contact URI is used in MSRP From/To. Do you have an objection to that? Why can't the nickname "the version with @domain" be represented in the From/To? In the proposal we have, the URI doesn't have the nickname in it (because collisions might be acceptable and if you allowed them, you would have non-unique URIs). Rather than inventing new syntax just to be able to have the nickname be in the From/To, we simply propose that the MSRP server put a unique URI in the Roster. Users never see the URIs. Furthermore, there are complications with constructing URIs with nicknames in them. The example used is when the domain is chat34@msrp.example.com (and not chat34.example.com). If that is the domain of the chat, then you can't just put the nickname before the @ and the domain after the @, you need some kind of construction rule. When you get into construction rules, you have trouble with weird nicknames, or you limit the syntax on a nickname, or something breaks. So we proposed to just not have a construction rule. You get the URI out of the roster. Brian ------=_NextPart_000_0153_01C7F30B.8712BB10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From your position, it would seem we are asking for = the "@domain" to be permitted in the nick request and conference = roster, and that the contact URI is used in MSRP From/To.  Do you have an objection to that?

 

Why can't the nickname "the version with @domain" be represented in the From/To?

 

In the proposal we have, the URI = doesn’t have the nickname in it (because collisions might be acceptable and if = you allowed them, you would have non-unique URIs).  Rather than inventing new = syntax just to be able to have the nickname be in the From/To, we simply = propose that the MSRP server put a unique URI in the = Roster.

 

Users never see the URIs. =

 

Furthermore, there are = complications with constructing URIs with nicknames in them.  The example used is when = the domain is chat34@msrp.example.com (and not chat34.example.com).  If that is the domain of the chat, then = you can’t just put the nickname before the @ and the domain after the @, you need = some kind of construction rule.  When you get into construction rules, = you have trouble with weird nicknames, or you limit the syntax on a nickname, or something breaks.  So we proposed to just not have a construction rule.  You get the URI out of the = roster.

 

Brian

------=_NextPart_000_0153_01C7F30B.8712BB10-- --===============1728834230== 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 --===============1728834230==-- From nancygarr7@bigsky.net Tue Sep 11 04:48:18 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV1Pu-0007uI-6r for simple-archive@lists.ietf.org; Tue, 11 Sep 2007 04:48:18 -0400 Received: from [62.248.91.229] (helo=62.248.91.229) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV1Pq-0005Bj-W9 for simple-archive@lists.ietf.org; Tue, 11 Sep 2007 04:48:17 -0400 Received: from [62.248.91.229] by mdyagem.bigsky.net; Tue, 11 Sep 2007 08:48:18 +0000 Message-ID: <000601c7f450$0257ead6$25943e88@dyagemne> From: "Trudy Heller" To: "Florence Valdez" Subject: Re: Thanks, we are ready to give your company a loan Date: Tue, 11 Sep 2007 07:00:56 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7F450.025675D5" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C7F450.025675D5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you have your own business and need IMMEDIATE ready money to spend = ANY way you like or require Extra money to give the company a boost or = need A low interest loan - NO STRINGS ATTACHED, here is best deal we can = offer you TONIGHT (hurry, this offer will expire THIS EVENING):   $50,000+ loan   Hurry, when the deal is gone, it is gone. Simply Call Us Free on=20 877-503-8916 ------=_NextPart_000_0003_01C7F450.025675D5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you have your own business and need = IMMEDIATE ready money to spend ANY way you like or require Extra money = to give the company a boost or need A low interest loan - NO STRINGS = ATTACHED, here is best deal we can offer you TONIGHT (hurry, this offer = will expire THIS EVENING):
=20
 
$50,000+ loan
 
Hurry, when the deal is gone, it is = gone. Simply Call Us Free on 877-503-8916
------=_NextPart_000_0003_01C7F450.025675D5-- From simple-bounces@ietf.org Tue Sep 11 10:40:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6sP-00016L-4M; Tue, 11 Sep 2007 10:38:05 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IV6sN-00016B-77 for simple-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 10:38:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6sM-000163-Tw; Tue, 11 Sep 2007 10:38:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV6sL-0004hx-I8; Tue, 11 Sep 2007 10:38:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 68EE126E74; Tue, 11 Sep 2007 14:38:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IV6sL-0004Rj-9F; Tue, 11 Sep 2007 10:38:01 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 11 Sep 2007 10:38:01 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: simple@ietf.org Subject: [Simple] Last Call: draft-ietf-simple-prescaps-ext (Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)) 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: - 'Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF) ' 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-09-25. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11411&rfc_flag=0 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 11 15:21: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 1IVBGe-0007Yc-Is; Tue, 11 Sep 2007 15:19:24 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IVBGd-0007Xj-Fm for simple-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 15:19:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBGd-0007XK-4A; Tue, 11 Sep 2007 15:19:23 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVBGc-0004Qi-0n; Tue, 11 Sep 2007 15:19:23 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id F2B8332880; Tue, 11 Sep 2007 19:19:21 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IVBGb-0001LA-T5; Tue, 11 Sep 2007 15:19:21 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 11 Sep 2007 15:19:21 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: simple@ietf.org Subject: [Simple] Last Call: draft-ietf-simple-xml-patch-ops (An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors) 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: - 'An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors ' 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-09-25. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch-ops-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14052&rfc_flag=0 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 13 18:07:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVwqH-0005ZW-D0; Thu, 13 Sep 2007 18:07:21 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IVwqG-0005ZM-0K for simple-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 18:07:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVwqF-0005ZE-GD for simple@ietf.org; Thu, 13 Sep 2007 18:07:19 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVwqF-0005hZ-0z for simple@ietf.org; Thu, 13 Sep 2007 18:07:19 -0400 Received: from orthrus.local (67-64-136-242.ded.swbell.net [67.64.136.242]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l8DM78aU033947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Sep 2007 17:07:10 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46E9B48C.3030109@nostrum.com> Date: Thu, 13 Sep 2007 17:07:08 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ruud Klaver Subject: Re: [Simple] MSRP relay implementation issue; domains & scalability References: <46DFBF8E.9000609@ag-projects.com> In-Reply-To: <46DFBF8E.9000609@ag-projects.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 67.64.136.242 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4264/Thu Sep 13 01:06:05 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 On 9/6/07 3:51 AM, Ruud Klaver wrote: > I am planning on implementing a MSRP relay according to the > specification and have come across an issue. In the interest of > scalability I would like a pool of relays to be able to service users > from several domains. > > However, the current specification has no provision for the > authenticating endpoint to supply a domain, only a username and > assword. In practice, this means running a separate server instance for > each domain, which is not very scalable. > > My question is, what would be the preferred solution to this? > > I think the key problem you're going to run into here isn't with user authentication, but with server authentication. In particular, relay connections are required to be over TLS; and, the certificate presented by the relay must match the name used by the client to connect to that relay. This problem is very similar to the difficulty found in running multiple https virtual hosts on a single web server. The traditional solution in that case is to use multiple IP addresses on the same host, so that the HTTP server knows which certificate to present based on the IP address the request arrives on. Fortunately for MSRP, the problem is a little bit easier -- for https, using a port number other than 443 is a significant hardship, which is why most people use IP addresses instead of ports to disambiguate multiple domains hosted on a single server. For MSRP, this isn't an issue. So, instead of using IP addresses to determine which certificate to present, MSRP servers can simply listen on a different *port* for each domain they service, and use the port number to determine which certificate to present. Now, since you already need to use multiple ports to determine which certificate to present, it becomes pretty obvious that you can also use the destination port to determine which domain the username is scoped to. Of course, the usernames themselves are simply a quoted string -- so, for example, if you wanted to make the _usernames_ to be of the form "user@domain", that will work -- it's a private matter of how you provision your system, and doesn't require any protocol support. However, doing this isn't really even necessary, for the reasons I describe above. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Corina_neese@universal-rubber.co.uk Fri Sep 14 08:38:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWARD-0004Sw-7S for simple-archive@lists.ietf.org; Fri, 14 Sep 2007 08:38:23 -0400 Received: from tdxrbgdz2f.adsl.datanet.hu ([195.56.90.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWARB-0003at-Fb for simple-archive@lists.ietf.org; Fri, 14 Sep 2007 08:38:23 -0400 Received: from Kelemen ([185.195.156.158] helo=Kelemen) by tdxrbgdz2f.adsl.datanet.hu ( sendmail 8.13.3/8.13.1) with esmtpa id 1zeoOt-000MOF-oZ for simple-archive@lists.ietf.org; Fri, 14 Sep 2007 14:38:56 +0200 Message-ID: <000a01c7f6cc$23035250$e45a38c3@Kelemen> From: "Corina neese" To: Subject: refoiled Date: Fri, 14 Sep 2007 14:38:22 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7F6DC.E68C2250" 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: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0009_01C7F6DC.E68C2250 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable http://www.ncdst.com/ hello simple-archive I went from being mr little too mr big boy within 6 months. Corina neese ------=_NextPart_000_0009_01C7F6DC.E68C2250 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
http://www.ncdst.com/
hello simple-archive
I went from being mr little too mr big boy = within 6 months.
Corina neese
------=_NextPart_000_0009_01C7F6DC.E68C2250-- From simple-bounces@ietf.org Fri Sep 14 11:18: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 1IWCvi-0005aW-0W; Fri, 14 Sep 2007 11:18:02 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IWCvg-0005aR-8v for simple-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 11:18:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWCvf-0005aH-U3 for simple@ietf.org; Fri, 14 Sep 2007 11:17:59 -0400 Received: from n2.bullet.in.yahoo.com ([202.43.219.98]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IWCvf-0001ar-1P for simple@ietf.org; Fri, 14 Sep 2007 11:17:59 -0400 Received: from [202.86.4.170] by n2.bullet.in.yahoo.com with NNFMP; 14 Sep 2007 15:17:56 -0000 Received: from [203.104.17.88] by t1.bullet.in.yahoo.com with NNFMP; 14 Sep 2007 15:17:56 -0000 Received: from [127.0.0.1] by omp102.mail.in2.yahoo.com with NNFMP; 14 Sep 2007 15:17:56 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 807939.15655.bm@omp102.mail.in2.yahoo.com Received: (qmail 79242 invoked by uid 60001); 14 Sep 2007 15:17:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=SNhI65HKdQ97OKpzLEBldeEsEI+vqPv1SHcvmZKcpCYJC92FfSr2Nod4ckLZyOldutrWAI08H2VGW8r+kKsX4gZCRoYMifsW6UVyqEcRnvlmLNuEK1/NPezCVWcG4F1wqphDL1XYMywQEcHOHnGg3qXkQx1gpqOSX68Lnj8hyZ4=; X-YMail-OSG: Qx6rMC0VM1kfrINtzsb7q1QrgmY2Burj0sanSMsXC5nv.7sUW4bLXQrRNzEPtlYeFdXerR4felj.AnGom6KpnZzpYgjlF4oXfe2t Received: from [220.225.231.67] by web7811.mail.in.yahoo.com via HTTP; Fri, 14 Sep 2007 16:17:56 BST Date: Fri, 14 Sep 2007 16:17:56 +0100 (BST) From: Allen Allen To: simple@ietf.org MIME-Version: 1.0 Message-ID: <761103.78846.qm@web7811.mail.in.yahoo.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Simple] how the presence come to know changes in xcap ??? 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="===============1492015315==" Errors-To: simple-bounces@ietf.org --===============1492015315== Content-Type: multipart/alternative; boundary="0-246131930-1189783076=:78846" Content-Transfer-Encoding: 8bit --0-246131930-1189783076=:78846 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear All, I am facing one problem in Presence server design. Any one please help me.. Problem: userA subscribes to Presence server . Presence server sends watcher info notify to user B containing watcher as userA status pending. Now the userB changes authorizaion policy such that it allows or denies userA. Now the question is how presence server comes to know whether userB done changes or not. is there any interface between xcap server and presence server ? userB can do changes in authorization policy any time. how it triggers presence server such that presence server sends notify to userA with userB presentity. Thanks in advance.. Regards Allen --------------------------------- Travelling to a new city? Search for ATMs in that city. Click here. --0-246131930-1189783076=:78846 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Dear All,
I am facing one problem in Presence server design. Any one please help me..
Problem:
userA subscribes to Presence server . Presence server sends watcher info notify to user B containing watcher as userA status pending. Now the userB changes authorizaion policy such that it allows or denies userA. Now the question is how presence server comes to know whether userB done changes or not. is there any interface between xcap server and presence server ?
userB can do changes in authorization policy any time. how it triggers presence server such that presence server sends notify to userA with userB presentity.
 
 
Thanks in advance..
Regards
Allen
 

Travelling to a new city? Search for ATMs in that city. Click here. --0-246131930-1189783076=:78846-- --===============1492015315== 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 --===============1492015315==-- From simple-bounces@ietf.org Fri Sep 14 13:54: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 1IWFNJ-0004lQ-5w; Fri, 14 Sep 2007 13:54:41 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IWFNI-0004l5-Bl for simple-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 13:54:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFNI-0004kc-0q for simple@ietf.org; Fri, 14 Sep 2007 13:54:40 -0400 Received: from [85.17.186.5] (helo=node05.dns-hosting.info) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWFNE-0006T8-W0 for simple@ietf.org; Fri, 14 Sep 2007 13:54:37 -0400 Received: from mit.xs4all.nl ([213.84.95.205] helo=[192.168.0.33]) by node05.dns-hosting.info with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.67) (envelope-from ) id 1IWFMy-0002Ic-2Q for simple@ietf.org; Fri, 14 Sep 2007 19:54:35 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49A94E70-952C-4A98-A59B-C7FB39E0AAF1@ag-projects.com> Content-Transfer-Encoding: 7bit From: Adrian Georgescu Date: Fri, 14 Sep 2007 19:53:41 +0200 To: simple@ietf.org X-Mailer: Apple Mail (2.752.3) X-SA-Exim-Connect-IP: 213.84.95.205 X-SA-Exim-Mail-From: ag@ag-projects.com X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on node05.dns-hosting.info X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 Subject: Re: [Simple] how the presence come to know changes in xcap ??? X-SA-Exim-Version: 4.2.1 (built Thu, 26 Apr 2007 18:30:04 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Allen, Your XCAP server must communicate the changes of policy to the Presence agent, by using some out of band mechanism and the Presence agent must update all watchers statuses and send Notify to qualified recipients. See an example of such implementation between OpenXCAP server and OpenSER Presence agent, the refreshWathers() management interface implementation: OpenSER http://www.openser.org/docs/modules/1.3.x/presence.html#AEN306 OpenXCAP http://www.openxcap.org/browser/xcap/interfaces/openser.py Regards, Adrian > From: Allen Allen > Subject: [Simple] how the presence come to know changes in xcap ??? > To: simple@ietf.org > Message-ID: <761103.78846.qm@web7811.mail.in.yahoo.com> > Content-Type: text/plain; charset="iso-8859-1" > > Dear All, > I am facing one problem in Presence server design. Any one please > help me.. > Problem: > userA subscribes to Presence server . Presence server sends > watcher info notify to user B containing watcher as userA status > pending. Now the userB changes authorizaion policy such that it > allows or denies userA. Now the question is how presence server > comes to know whether userB done changes or not. is there any > interface between xcap server and presence server ? > userB can do changes in authorization policy any time. how it > triggers presence server such that presence server sends notify to > userA with userB presentity. > > > Thanks in advance.. > Regards > Allen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Sep 15 06:02: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 1IWUTh-00032k-T1; Sat, 15 Sep 2007 06:02:17 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IWUTg-0002yq-Dw for simple-confirm+ok@megatron.ietf.org; Sat, 15 Sep 2007 06:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWUTg-0002yc-4C for simple@ietf.org; Sat, 15 Sep 2007 06:02:16 -0400 Received: from smtpoutwbe05.prod.mesa1.secureserver.net ([208.109.78.207]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IWUTe-0002Er-K4 for simple@ietf.org; Sat, 15 Sep 2007 06:02:15 -0400 Received: (qmail 25912 invoked from network); 15 Sep 2007 10:02:13 -0000 Received: from unknown (HELO gem-wbe34.prod.mesa1.secureserver.net) (64.202.189.30) by smtpoutwbe05.prod.mesa1.secureserver.net with SMTP; 15 Sep 2007 10:02:12 -0000 Received: (qmail 28734 invoked by uid 99); 15 Sep 2007 10:02:12 -0000 Date: Sat, 15 Sep 2007 03:02:12 -0700 From: david.viamonte@genaker.net Subject: RE: [Simple] how the presence come to know changes in xcap ??? To: Adrian Georgescu Message-ID: <20070915030212.c55cf0821f35f73ca3a32b18343b22d1.a10d0ff631.wbe@email.secureserver.net> MIME-Version: 1.0 User-Agent: Web-Based Email 4.10.22 X-Originating-IP: 62.57.136.134 X-Spam-Score: 1.7 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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="===============0744309058==" Errors-To: simple-bounces@ietf.org --===============0744309058== Content-Type: TEXT/html; CHARSET=US-ASCII
Hi,
 
Just to add on this, my understanding is that the standard way of sending XCAP resource change notifications will be based in:
 
 
once this mechanism gets approved... Am I right? This way the Presence Server will be able to subscribe to receive a notification when the Presence policy of the Presentity changes.
Are the OpenSER and OpenXCAP functions based already on a similar mechanism?
 
Regards,
 
David
 
 


-------- Original Message --------
Subject: Re: [Simple] how the presence come to know changes in xcap ???
From: Adrian Georgescu <ag@ag-projects.com>
Date: Fri, September 14, 2007 7:53 pm
To: simple@ietf.org

Hi Allen,

Your XCAP server must communicate the changes of policy to the
Presence agent, by using some out of band mechanism and the Presence
agent must update all watchers statuses and send Notify to qualified
recipients.

See an example of such implementation between OpenXCAP server and
OpenSER Presence agent, the refreshWathers() management interface
implementation:

OpenSER

http://www.openser.org/docs/modules/1.3.x/presence.html#AEN306

OpenXCAP

http://www.openxcap.org/browser/xcap/interfaces/openser.py

Regards,
Adrian


> From: Allen Allen <allen_forums@yahoo.co.in>
> Subject: [Simple] how the presence come to know changes in xcap ???
> To: simple@ietf.org
> Message-ID: <761103.78846.qm@web7811.mail.in.yahoo.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Dear All,
> I am facing one problem in Presence server design. Any one please
> help me..
> Problem:
> userA subscribes to Presence server . Presence server sends
> watcher info notify to user B containing watcher as userA status
> pending. Now the userB changes authorizaion policy such that it
> allows or denies userA. Now the question is how presence server
> comes to know whether userB done changes or not. is there any
> interface between xcap server and presence server ?
> userB can do changes in authorization policy any time. how it
> triggers presence server such that presence server sends notify to
> userA with userB presentity.
>
>
> Thanks in advance..
> Regards
> Allen



_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
--===============0744309058== 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 --===============0744309058==-- From karppanen@aperda.de Sun Sep 16 05:40:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWqc9-0003mo-Id for simple-archive@lists.ietf.org; Sun, 16 Sep 2007 05:40:29 -0400 Received: from alille-257-1-38-171.w83-204.abo.wanadoo.fr ([83.204.73.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWqc6-0004Eq-Vk for simple-archive@lists.ietf.org; Sun, 16 Sep 2007 05:40:27 -0400 Received: from nom-eb85c523610 by aperda.de with ASMTP id 2DB8D1D7 for ; Sun, 16 Sep 2007 11:41:26 +0200 Received: from nom-eb85c523610 ([146.143.178.195]) by aperda.de with ESMTP id F4BEA0E472F3 for ; Sun, 16 Sep 2007 11:41:26 +0200 Message-ID: <000a01c7f845$ac072610$ab49cc53@nomeb85c523610> From: "Bipin karppanen" To: Subject: itawis Date: Sun, 16 Sep 2007 11:40:52 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7F856.6F8FF610" 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-Antivirus: avast! (VPS 000774-7, 15/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.5 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f ------=_NextPart_000_0004_01C7F856.6F8FF610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://boseb.com/ Good evening simple-archive When I looked in the mirror after every shower, I couldn=92t help but = wonder whether or not I was average. After doing some research online, I = realized that I was slightly under-average Bipin karppanen ------=_NextPart_000_0004_01C7F856.6F8FF610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://boseb.com/
Good evening simple-archive
When I looked in the mirror after every = shower, I=20 couldn=92t help but wonder whether or not I was average. After doing = some research=20 online, I realized that I was slightly under-average
Bipin karppanen
------=_NextPart_000_0004_01C7F856.6F8FF610-- From Jaron.DESAI@advancedsepticsolutionsinc.com Sun Sep 16 23:03:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX6tb-0007XT-Fi for simple-archive@lists.ietf.org; Sun, 16 Sep 2007 23:03:35 -0400 Received: from [151.53.146.235] (helo=[151.53.135.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IX6ta-0005kX-Rh for simple-archive@lists.ietf.org; Sun, 16 Sep 2007 23:03:35 -0400 Received: from manuel-n4uvl3rd ([134.180.197.194] helo=manuel-n4uvl3rd) by [151.53.135.17] ( sendmail 8.13.3/8.13.1) with esmtpa id 1NYVcY-000JLK-ii for simple-archive@lists.ietf.org; Mon, 17 Sep 2007 05:12:39 +0200 Message-ID: <000c01c7f8d8$94b235c0$11873597@manueln4uvl3rd> From: "Jaron DESAI" To: Subject: ytilaicn Date: Mon, 17 Sep 2007 05:12:29 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7F8E9.583B05C0" 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: 2.1 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0004_01C7F8E9.583B05C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.cybertwn.com/ Compliments simple-archive Cure and prevent impotence - Temporary impotence will be a thing of the = past! Jaron DESAI ------=_NextPart_000_0004_01C7F8E9.583B05C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.cybertwn.com/
Compliments simple-archive
Cure and prevent impotence - Temporary = impotence will be=20 a thing of the past!
Jaron DESAI
------=_NextPart_000_0004_01C7F8E9.583B05C0-- From simple-bounces@ietf.org Mon Sep 17 05:03:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXCW3-0005JY-C0; Mon, 17 Sep 2007 05:03:39 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IXCW1-0005JJ-Hw for simple-confirm+ok@megatron.ietf.org; Mon, 17 Sep 2007 05:03:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXCW1-0005J9-6h for simple@ietf.org; Mon, 17 Sep 2007 05:03:37 -0400 Received: from [85.17.186.5] (helo=node05.dns-hosting.info) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXCVz-0007Fa-UL for simple@ietf.org; Mon, 17 Sep 2007 05:03:36 -0400 Received: from 5571fc03.ftth.concepts.nl ([85.113.252.3] helo=[192.168.1.200] ident=fmalibu) by node05.dns-hosting.info with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.67) (envelope-from ) id 1IXCVx-0000KL-4S; Mon, 17 Sep 2007 11:03:33 +0200 Message-ID: <46EE42E0.3040701@ag-projects.com> Date: Mon, 17 Sep 2007 11:03:28 +0200 From: Ruud Klaver User-Agent: Thunderbird 2.0.0.6 (X11/20070903) MIME-Version: 1.0 To: Adam Roach References: <46DFBF8E.9000609@ag-projects.com> <46E9B48C.3030109@nostrum.com> In-Reply-To: <46E9B48C.3030109@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 85.113.252.3 X-SA-Exim-Mail-From: ruud@ag-projects.com X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on node05.dns-hosting.info X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 Subject: Re: [Simple] MSRP relay implementation issue; domains & scalability X-SA-Exim-Version: 4.2.1 (built Thu, 26 Apr 2007 18:30:04 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 Adam Roach, Adam Roach wrote: > On 9/6/07 3:51 AM, Ruud Klaver wrote: >> I am planning on implementing a MSRP relay according to the >> specification and have come across an issue. In the interest of >> scalability I would like a pool of relays to be able to service users >> from several domains. >> >> However, the current specification has no provision for the >> authenticating endpoint to supply a domain, only a username and >> assword. In practice, this means running a separate server instance for >> each domain, which is not very scalable. >> >> My question is, what would be the preferred solution to this? >> >> > > I think the key problem you're going to run into here isn't with user > authentication, but with server authentication. In particular, relay > connections are required to be over TLS; and, the certificate presented > by the relay must match the name used by the client to connect to that > relay. This problem is very similar to the difficulty found in running > multiple https virtual hosts on a single web server. The traditional > solution in that case is to use multiple IP addresses on the same host, > so that the HTTP server knows which certificate to present based on the > IP address the request arrives on. > > Fortunately for MSRP, the problem is a little bit easier -- for https, > using a port number other than 443 is a significant hardship, which is > why most people use IP addresses instead of ports to disambiguate > multiple domains hosted on a single server. For MSRP, this isn't an > issue. So, instead of using IP addresses to determine which certificate > to present, MSRP servers can simply listen on a different *port* for > each domain they service, and use the port number to determine which > certificate to present. > > Now, since you already need to use multiple ports to determine which > certificate to present, it becomes pretty obvious that you can also use > the destination port to determine which domain the username is scoped to. > > Of course, the usernames themselves are simply a quoted string -- so, > for example, if you wanted to make the _usernames_ to be of the form > "user@domain", that will work -- it's a private matter of how you > provision your system, and doesn't require any protocol support. > However, doing this isn't really even necessary, for the reasons I > describe above. > > /a Thank you for the suggestions, and yes the TLS certificate is domain specific as well and needs to be dealt with. However, this makes your second suggestion unusable, as the TLS certificate needs to be presented to the client before it authenticates. To be honest I had already considered your first suggestion myself, but it does not seem the most elegant of solutions, especially when servicing a lot of domains. It was suggested to me that TLS includes an extension that allows the connecting client to indicate the name of the server it is contacting (section 3.1 of RFC 3546). This would allow the MSRP relay to present the client with the correct certificate for a domain and further authenticate it within that domain. However, this would rely on some support of the connecting client. Wouldn't this solution be preferable to having a relay listen on lots of different ports? -- Ruud Klaver http://www.ag-projects.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 17 11:41: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 1IXIiU-00040Z-Ky; Mon, 17 Sep 2007 11:40:54 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IXIiS-00040Q-Tw for simple-confirm+ok@megatron.ietf.org; Mon, 17 Sep 2007 11:40:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXIiS-00040I-KJ for simple@ietf.org; Mon, 17 Sep 2007 11:40:52 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXIiS-0006u2-0X for simple@ietf.org; Mon, 17 Sep 2007 11:40:52 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l8HFeRKR015709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Sep 2007 10:40:28 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46EE9FF0.9060904@nostrum.com> Date: Mon, 17 Sep 2007 10:40:32 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ruud Klaver Subject: Re: [Simple] MSRP relay implementation issue; domains & scalability References: <46DFBF8E.9000609@ag-projects.com> <46E9B48C.3030109@nostrum.com> <46EE42E0.3040701@ag-projects.com> In-Reply-To: <46EE42E0.3040701@ag-projects.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4310/Mon Sep 17 07:47:06 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 On 9/17/07 4:03 AM, Ruud Klaver wrote: > Thank you for the suggestions, and yes the TLS certificate is domain > specific as well and needs to be dealt with. However, this makes your > second suggestion unusable, as the TLS certificate needs to be presented > to the client before it authenticates. > I guess I wasn't particularly clear about that use case: if, for some reason, the internal architecture of your software makes it difficult to get information about which domain the request is associate with up to the level that performs authentication, it is trivial to encode the domain as part of the username field. This is never _necessary_, but it may simplify your design. > To be honest I had already considered your first suggestion myself, but > it does not seem the most elegant of solutions, especially when > servicing a lot of domains. > > It was suggested to me that TLS includes an extension that allows the > connecting client to indicate the name of the server it is contacting > (section 3.1 of RFC 3546). This would allow the MSRP relay to present > the client with the correct certificate for a domain and further > authenticate it within that domain. However, this would rely on some > support of the connecting client. Wouldn't this solution be preferable > to having a relay listen on lots of different ports? > > It would -- but I suspect most clients won't implement this specific SSL feature. If you think this is particularly important, I would propose that you put together a "best current practices" internet-draft that describes client and server behavior to support MSRP relay multi-homing on a single IP address and port. Although it's basically the same demultiplexing as I was describing with port numbers, I want to make sure you don't overlook this: if you use the "server_name" extension during TLS establishment, then the indicated domain can be used to scope the username presented by the client. More generally: *whatever* mechanism you use to determine what server cert to present (IP address, port number, server_name, etc) can be used to scope the client username. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From damjanhubbs@alanpattersondesign.com Mon Sep 17 19:51:53 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXQNd-0002Dk-6x for simple-archive@lists.ietf.org; Mon, 17 Sep 2007 19:51:53 -0400 Received: from ool-457497c0.dyn.optonline.net ([69.116.151.192]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXQNS-0000oD-9X for simple-archive@lists.ietf.org; Mon, 17 Sep 2007 19:51:42 -0400 Received: by 10.228.215.67 with SMTP id JKwUQHFQZvrmU; Mon, 17 Sep 2007 19:52:57 -0400 (GMT) Received: by 192.168.102.91 with SMTP id rHJtpsHajqbcWT.3737102431814; Mon, 17 Sep 2007 19:52:55 -0400 (GMT) Message-ID: <000e01c7f985$dc0c03d0$c0977445@TLGAF3F880D3EE> From: "damjan hubbs" To: Subject: gfw Date: Mon, 17 Sep 2007 19:52:52 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7F964.54FA63D0" 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: 4.2 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0003_01C7F964.54FA63D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.fzxcdz.com/ Greeting simple-archive If you feel insecure about your penis size then it affects how you act = and behave damjan hubbs ------=_NextPart_000_0003_01C7F964.54FA63D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.fzxcdz.com/
Greeting simple-archive
If you feel insecure about your penis size = then it=20 affects how you act and behave
damjan hubbs
------=_NextPart_000_0003_01C7F964.54FA63D0-- From simple-bounces@ietf.org Tue Sep 18 03:59: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 1IXXv4-0000EF-0Y; Tue, 18 Sep 2007 03:54:54 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IXXv2-0000AQ-8b for simple-confirm+ok@megatron.ietf.org; Tue, 18 Sep 2007 03:54:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXXv1-00007g-Un for simple@ietf.org; Tue, 18 Sep 2007 03:54:51 -0400 Received: from [85.17.186.5] (helo=node05.dns-hosting.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXXut-0007xS-Kr for simple@ietf.org; Tue, 18 Sep 2007 03:54:49 -0400 Received: from 5571fc03.ftth.concepts.nl ([85.113.252.3] helo=[192.168.1.200] ident=fmalibu) by node05.dns-hosting.info with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.67) (envelope-from ) id 1IXXtv-0000y8-IS; Tue, 18 Sep 2007 09:53:56 +0200 Message-ID: <46EF8403.305@ag-projects.com> Date: Tue, 18 Sep 2007 09:53:39 +0200 From: Ruud Klaver User-Agent: Thunderbird 2.0.0.6 (X11/20070903) MIME-Version: 1.0 To: Adam Roach References: <46DFBF8E.9000609@ag-projects.com> <46E9B48C.3030109@nostrum.com> <46EE42E0.3040701@ag-projects.com> <46EE9FF0.9060904@nostrum.com> In-Reply-To: <46EE9FF0.9060904@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 85.113.252.3 X-SA-Exim-Mail-From: ruud@ag-projects.com X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on node05.dns-hosting.info X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 Subject: Re: [Simple] MSRP relay implementation issue; domains & scalability X-SA-Exim-Version: 4.2.1 (built Thu, 26 Apr 2007 18:30:04 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Adam Roach wrote: > On 9/17/07 4:03 AM, Ruud Klaver wrote: >> Thank you for the suggestions, and yes the TLS certificate is domain >> specific as well and needs to be dealt with. However, this makes your >> second suggestion unusable, as the TLS certificate needs to be presented >> to the client before it authenticates. >> > > I guess I wasn't particularly clear about that use case: if, for some > reason, the internal architecture of your software makes it difficult to > get information about which domain the request is associate with up to > the level that performs authentication, it is trivial to encode the > domain as part of the username field. This is never _necessary_, but it > may simplify your design. > >> To be honest I had already considered your first suggestion myself, but >> it does not seem the most elegant of solutions, especially when >> servicing a lot of domains. >> >> It was suggested to me that TLS includes an extension that allows the >> connecting client to indicate the name of the server it is contacting >> (section 3.1 of RFC 3546). This would allow the MSRP relay to present >> the client with the correct certificate for a domain and further >> authenticate it within that domain. However, this would rely on some >> support of the connecting client. Wouldn't this solution be preferable >> to having a relay listen on lots of different ports? >> >> > > It would -- but I suspect most clients won't implement this specific SSL > feature. If you think this is particularly important, I would propose > that you put together a "best current practices" internet-draft that > describes client and server behavior to support MSRP relay multi-homing > on a single IP address and port. > > Although it's basically the same demultiplexing as I was describing with > port numbers, I want to make sure you don't overlook this: if you use > the "server_name" extension during TLS establishment, then the indicated > domain can be used to scope the username presented by the client. > > More generally: *whatever* mechanism you use to determine what server > cert to present (IP address, port number, server_name, etc) can be used > to scope the client username. > > /a I suppose I wasn't too clear on this, but I was indeed looking for some solution that would resolve both issues, as they basically boil down to the same problem in my view. Again, thanks for the suggestions. -- Ruud Klaver http://www.ag-projects.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 18 10:13: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 1IXdmO-0006cy-Ce; Tue, 18 Sep 2007 10:10:20 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IXdmM-0006cm-D6 for simple-confirm+ok@megatron.ietf.org; Tue, 18 Sep 2007 10:10:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXdmM-0006ce-2A; Tue, 18 Sep 2007 10:10:18 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXdmG-0007l5-LV; Tue, 18 Sep 2007 10:10:18 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 331EA1C0138; Tue, 18 Sep 2007 16:10:10 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 2E1DD1C0126; Tue, 18 Sep 2007 16:10:10 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 2AF2958EB6A; Tue, 18 Sep 2007 16:10:10 +0200 (CEST) Date: Tue, 18 Sep 2007 16:10:10 +0200 From: Stephane Bortzmeyer To: "Tom.Petch" Message-ID: <20070918141010.GA9733@nic.fr> References: <030601c7f9ee$41d29180$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <030601c7f9ee$41d29180$0601a8c0@pc6> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ietf , simple@ietf.org Subject: [Simple] Re: Last Call: draft-ietf-simple-xml-patch-ops (An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors) 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: , Errors-To: simple-bounces@ietf.org On Tue, Sep 18, 2007 at 02:19:51PM +0200, Tom.Petch wrote a message of 135 lines which said: > I question the use of XPath 1.0, when XPath 2.0 was approved at the > start of this year. It seems short-sighted, a bit like choosing IPv4 > over IPv6 I strongly disagree. Xpath 2.0 is *much* more complicated than Xpath 1.0. Among free software, there is little implementation (or even plans) of 2.0. Xpath 2.0 is quite controversial. The comparison with IPv4/v6 is wrong. If you start from scratch, IPv6 is no more complicated than IPv4 (and it is probably the opposite). Xpath 2.0 is always much more difficult to implement (for instance, it requires schemas). > This business of updating parts of an XML document seems to be > cropping up in a number of places in the IETF with very different > solutions. AFAIK, this is the first one to be specified at IETF. Other contenders are: * REX (W3C), which uses DOM events http://www.w3.org/TR/rex/ * Xquery update (W3C) http://www.w3.org/TR/xqupdate/ * XUpdate, which seems completely dead http://xmldb-org.sourceforge.net/xupdate/ * DUL, there was an I-D, "A delta format for XML documents", draft-mouat-xml-patch-00.txt, now expired http://sourceforge.net/projects/diffxml _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From kominikllg@lasonrisa.ca Tue Sep 18 23:05:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXpst-0002fS-12 for simple-archive@lists.ietf.org; Tue, 18 Sep 2007 23:05:51 -0400 Received: from [201.37.113.95] (helo=C925715F.poa.virtua.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXpsY-0000sl-Sn for simple-archive@lists.ietf.org; Tue, 18 Sep 2007 23:05:31 -0400 Received: from souza-kiw4aahxf ([134.144.74.98] helo=souza-kiw4aahxf) by C925715F.poa.virtua.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1wtPrB-000QMB-xt for simple-archive@lists.ietf.org; Mon, 17 Sep 2007 00:04:24 -0300 Message-ID: <000e01c7f8d7$6cf0dc90$5f7125c9@souzakiw4aahxf> From: "Margi kominik" To: Subject: litifolk Date: Mon, 17 Sep 2007 00:04:13 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7F8BE.47A3A490" 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: 3.3 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0004_01C7F8BE.47A3A490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://csayto.com/ Hello simple-archive I went from being mr little too mr big boy within 6 months. Margi kominik ------=_NextPart_000_0004_01C7F8BE.47A3A490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://csayto.com/
Hello simple-archive
I went from being mr little too mr big boy = within 6 months.
Margi kominik
------=_NextPart_000_0004_01C7F8BE.47A3A490-- From simple-bounces@ietf.org Wed Sep 19 00:47: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 1IXrOL-0007gU-VV; Wed, 19 Sep 2007 00:42:25 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IXrOL-0007g4-5x for simple-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 00:42:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXrOK-0007fv-SN for simple@ietf.org; Wed, 19 Sep 2007 00:42:24 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXrOJ-0005nY-M2 for simple@ietf.org; Wed, 19 Sep 2007 00:42:24 -0400 X-IronPort-AV: E=Sophos;i="4.20,271,1186383600"; d="scan'208";a="220735208" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 18 Sep 2007 21:42:21 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8J4gLKI016289; Tue, 18 Sep 2007 21:42:21 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id l8J4gKDs006920; Wed, 19 Sep 2007 04:42:20 GMT In-Reply-To: <46BB50DE002DA78F@pne-smtpout1-sn1.fre.skanova.net> (added by postmaster@pne.skanova.net) References: <46BB50DE002DA78F@pne-smtpout1-sn1.fre.skanova.net> (added by postmaster@pne.skanova.net) Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <2586CB36-13D6-4F78-AF20-2CE4F3B3562A@cisco.com> Content-Transfer-Encoding: quoted-printable From: Cullen Jennings Subject: Re: [XCON] RE: [Simple] Chatroom Gap Analysis - Media and mode aspects Date: Tue, 18 Sep 2007 21:42:12 -0700 To: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=405; t=1190176941; x=1191040941; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[XCON]=20RE=3A=20[Simple]=20Chatroom=20Gap=20Analysis =20-=20Media=20and=20mode=20aspects |Sender:=20; bh=9cas/wCwq0wcHleAtigCaEFEFbSNh1P+PM1zTNaaNKY=; b=BsRSY44KP2ZjWMQ7wuHa1m9C+FGukljHn2PVq4Jnx2b2PxXiQqSw5cYNh4JJvlTcHd5zsGMf ybw/Aair432w7qt9aEsKR3FdZPABE64ve/1HYcL6gqdkgPMRc/EEliox; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 On Aug 20, 2007, at 10:01 PM, Gunnar Hellstr=F6m wrote: > > I have started on a document in that direction. > See: > http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-01.txt Gunnar, if you have not already done so, you should talk to Paul =20 Jones about some things he was looking at to do real time text with =20 MSRP - it fits in well with your textpreview draft. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 19 03:53:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXuKM-0006Rl-IJ; Wed, 19 Sep 2007 03:50:30 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IXuKK-0006N0-RZ for simple-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 03:50:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXuKK-0006JO-DJ for simple@ietf.org; Wed, 19 Sep 2007 03:50:28 -0400 Received: from smtp.dgcsystems.net ([83.241.254.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXuK9-0001na-5t for simple@ietf.org; Wed, 19 Sep 2007 03:50:23 -0400 Received: from GunnarH ([217.13.240.136]) by smtp.dgcsystems.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 09:50:18 +0200 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Cullen Jennings'" Subject: RE: [XCON] RE: [Simple] Chatroom Gap Analysis - Media and mode aspects Date: Wed, 19 Sep 2007 09:50:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acf6d3e4kCyrdq8lShe1KFerxvCcuQAEF+rw In-Reply-To: <2586CB36-13D6-4F78-AF20-2CE4F3B3562A@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Message-ID: X-OriginalArrivalTime: 19 Sep 2007 07:50:18.0208 (UTC) FILETIME=[B8DD9600:01C7FA91] X-Spam-Score: -1.0 (-) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Cullen, Thanks,=20 yes, I have talked with Paul Jones and others about the benefits of = making real-timish text with MSRP. MSRP does not specify what event should cause transmission. So, it could = be a timer driven transmission just as well as a send button driven transmission. The receiving and presenting end would just need to know = to=20 There are also some good features in MSRP that could be of good use to = make sure the users have a synchronized view of the conversation. People would love to do away with the tensions and risks for confusion appearing when you try to use message-wise IM for intensive = conversations, by having text appearing gradually and smoothly as it is typed. With a suitably selected transmission interval it probably does not need to = take more resources than maintaining the status indicator "The other = participant is typing a message" that many IM systems supply today. Is there an interest to discuss this topic in an own thread SIMPLE? Gunnar=20 ------------------------------------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se Tel: +46708204288 www.omnitor.se -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Wednesday, September 19, 2007 6:42 AM To: Gunnar Hellstr=F6m Cc: simple@ietf.org Subject: Re: [XCON] RE: [Simple] Chatroom Gap Analysis - Media and mode aspects On Aug 20, 2007, at 10:01 PM, Gunnar Hellstr=F6m wrote: > > I have started on a document in that direction. > See: > http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-01.txt Gunnar, if you have not already done so, you should talk to Paul Jones = about some things he was looking at to do real time text with MSRP - it fits = in well with your textpreview draft. Cullen __________ NOD32 2534 (20070917) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 19 05:17: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 1IXvdl-0005CX-TK; Wed, 19 Sep 2007 05:14:37 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IXvdj-0005B5-RQ for simple-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 05:14:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXvdj-00057f-Dp for simple@ietf.org; Wed, 19 Sep 2007 05:14:35 -0400 Received: from smtp.dgcsystems.net ([83.241.254.90]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXvda-000205-N9 for simple@ietf.org; Wed, 19 Sep 2007 05:14:27 -0400 Received: from GunnarH ([217.13.240.136]) by smtp.dgcsystems.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 11:14:47 +0200 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Cullen Jennings'" Subject: RE: [XCON] RE: [Simple] Chatroom Gap Analysis - Media and mode aspects Date: Wed, 19 Sep 2007 11:14:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acf6d3e4kCyrdq8lShe1KFerxvCcuQAEF+rw In-Reply-To: <2586CB36-13D6-4F78-AF20-2CE4F3B3562A@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Message-ID: X-OriginalArrivalTime: 19 Sep 2007 09:14:47.0518 (UTC) FILETIME=[8668E7E0:01C7FA9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 Cullen, sorry for repetition, I had an unfinished sentence in the = response sent recently. Thanks,=20 yes, I have talked with Paul Jones and others about the benefits of = making real-timish text with MSRP. MSRP does not specify what event should cause transmission. So, it could = be a timer driven transmission just as well as a send button driven transmission. The receiving and presenting end would just need to know = to present chunks consecutively until a new line or other end of entry indicator is received. There are also some good features in MSRP that could be of good use to = make sure the users have a synchronized view of the conversation. People would love to do away with the tensions and risks for confusion appearing when you try to use message-wise IM for intensive = conversations, by having text appearing gradually and smoothly as it is typed. With a suitably selected transmission interval it probably does not need to = take more resources than maintaining the status indicator "The other = participant is typing a message" that many IM systems supply today. Is there an interest to discuss this topic in an own thread SIMPLE? Gunnar=20 ------------------------------------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se Tel: +46708204288 www.omnitor.se -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Wednesday, September 19, 2007 6:42 AM To: Gunnar Hellstr=F6m Cc: simple@ietf.org Subject: Re: [XCON] RE: [Simple] Chatroom Gap Analysis - Media and mode aspects On Aug 20, 2007, at 10:01 PM, Gunnar Hellstr=F6m wrote: > > I have started on a document in that direction. > See: > http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-01.txt Gunnar, if you have not already done so, you should talk to Paul Jones = about some things he was looking at to do real time text with MSRP - it fits = in well with your textpreview draft. Cullen __________ NOD32 2534 (20070917) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Normann.Heiges@brasilien.de Wed Sep 19 11:21:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY1MN-0008Qq-Oj for simple-archive@lists.ietf.org; Wed, 19 Sep 2007 11:21:03 -0400 Received: from host194-50-dynamic.17-87-r.retail.telecomitalia.it ([87.17.50.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY1MN-00039u-4C for simple-archive@lists.ietf.org; Wed, 19 Sep 2007 11:21:03 -0400 Received: from pc02 ([108.170.170.14]:6801 "EHLO pc02" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host194-50-dynamic.17-87-r.retail.telecomitalia.it with ESMTP id S22UIRUIMOEFVSSO (ORCPT ); Wed, 19 Sep 2007 17:21:32 +0200 Message-ID: <000301c7fad0$b8d38540$c2321157@pc02> From: "Normann Heiges" To: Subject: stablein Date: Wed, 19 Sep 2007 17:21:16 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7FAE1.7C5C5540" 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: 2.1 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0008_01C7FAE1.7C5C5540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.matiman.com/ Wassup simple-archive check out my big schlong, haha.. i'll get all the ladies with this = beast. Normann Heiges ------=_NextPart_000_0008_01C7FAE1.7C5C5540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.matiman.com/
Wassup simple-archive
check out my big schlong, haha.. i'll get all = the ladies=20 with this beast.
Normann Heiges
------=_NextPart_000_0008_01C7FAE1.7C5C5540-- From simple-bounces@ietf.org Thu Sep 20 11:00:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYNTP-0004cS-Jm; Thu, 20 Sep 2007 10:57:47 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IYNTP-0004cG-07 for simple-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 10:57:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYNTO-0004c8-EQ for simple@ietf.org; Thu, 20 Sep 2007 10:57:46 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYNTN-0000di-IO for simple@ietf.org; Thu, 20 Sep 2007 10:57:46 -0400 Received: from [192.168.2.235] (pool-71-164-172-176.dllstx.fios.verizon.net [71.164.172.176]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l8KEvdTd005961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Sep 2007 09:57:44 -0500 (CDT) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) To: SIMPLE mailing list Message-Id: References: From: Robert Sparks Date: Thu, 20 Sep 2007 09:57:38 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Subject: [Simple] Fwd: Deployment of the Internet-Draft Submission Tool 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="===============1730224443==" Errors-To: simple-bounces@ietf.org --===============1730224443== Content-Type: multipart/alternative; boundary=Apple-Mail-3--607822164 --Apple-Mail-3--607822164 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed fyi Begin forwarded message: > From: IETF Secretariat > Date: September 19, 2007 2:32:20 PM CDT > To: IETF Announcement list > Cc: wgchairs@ietf.org > Subject: Deployment of the Internet-Draft Submission Tool > Reply-To: idst-developers@ietf.org > > The IETF Secretariat is pleased to announce the deployment of the > Internet-Draft Submission Tool (IDST)-Phase I. The IDST is a Web- > based > application that will allow an IETF participant to submit an > Internet-Draft online, obtain approval to post the draft (if > necessary), > and make the draft immediately available to the community on the IETF > Web site without the assistance of the Secretariat (in most cases). > > The URL for the IDST is: > https://datatracker.ietf.org/idst/upload.cgi > > The URL for instructions for using the IDST is: > http://www.ietf.org/idsubmit_instructions.html > > Although it will still be possible to submit your drafts by e-mail > (i.e., by sending them to internet-drafts@ietf.org), the tool is > available for use effective immediately, and we encourage you to > submit > your drafts via the tool starting today. > > If you have any questions about using the tool or wish to report a > bug, > then please send a message to idst-developers@ietf.org. > > Enjoy!! > > The IETF Secretariat > --Apple-Mail-3--607822164 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 fyi

Begin = forwarded message:

From: = IETF Secretariat <ietf-secretariat@ietf.org>= ;
Date: September 19, 2007 2:32:20 PM = CDT
To: IETF Announcement list <ietf-announce@ietf.org>
Subject: = Deployment of the Internet-Draft Submission Tool=A0

The IETF Secretariat is pleased to announce the = deployment of the
Internet-Draft Submission Tool = (IDST)-Phase I.=A0 The IDST = is a Web-based
application that will allow an = IETF participant to submit an
and make the draft immediately = available to the community on the IETF
Web site = without the assistance of the Secretariat (in most cases).

The URL = for the IDST is:

The URL for instructions for = using the IDST is:

Although it will still be = possible to submit your drafts by e-mail
(i.e., = by sending them to internet-drafts@ietf.org), = the tool is
available for use effective = immediately, and we encourage you to submit
your = drafts via the tool starting today.

If you have any questions about = using the tool or wish to report a bug,
then = please send a message to idst-developers@ietf.org.


The IETF Secretariat


= --Apple-Mail-3--607822164-- --===============1730224443== 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 --===============1730224443==-- From Mildred_Koykka@consulting-gmbh.com Thu Sep 20 13:49:14 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYQ9K-0006n2-7T for simple-archive@lists.ietf.org; Thu, 20 Sep 2007 13:49:14 -0400 Received: from host209-111-dynamic.17-87-r.retail.telecomitalia.it ([87.17.111.209]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYQ9G-0006th-Qi for simple-archive@lists.ietf.org; Thu, 20 Sep 2007 13:49:11 -0400 Received: from user-c3fed1e593 ([184.132.129.92]:21971 "EHLO user-c3fed1e593" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host209-111-dynamic.17-87-r.retail.telecomitalia.it with ESMTP id S22GVTCPBQQUZQYQ (ORCPT ); Thu, 20 Sep 2007 19:49:37 +0200 Message-ID: <000d01c7fbae$90886e50$d16f1157@userc3fed1e593> From: "Mildred Koykka" To: Subject: akiynagn Date: Thu, 20 Sep 2007 19:49:17 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7FBBF.54113E50" 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-Antivirus: avast! (VPS 000775-4, 20/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.1 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0009_01C7FBBF.54113E50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://meilidg.com/ hello simple-archive Our biochemists have created the best triple strength formula to give = you faster and safer results Mildred Koykka ------=_NextPart_000_0009_01C7FBBF.54113E50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://meilidg.com/
hello simple-archive
Our biochemists have created the best triple = strength=20 formula to give you faster and safer results
Mildred Koykka
------=_NextPart_000_0009_01C7FBBF.54113E50-- From Krollmxs@aerofin.com Fri Sep 21 07:51:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYh34-0005dz-H6 for simple-archive@lists.ietf.org; Fri, 21 Sep 2007 07:51:54 -0400 Received: from host228-156-dynamic.1-87-r.retail.telecomitalia.it ([87.1.156.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYh2z-00009d-Bx for simple-archive@lists.ietf.org; Fri, 21 Sep 2007 07:51:50 -0400 Received: by 10.207.21.200 with SMTP id XAhaFsUEJKxaI; Fri, 21 Sep 2007 13:51:53 +0200 (GMT) Received: by 192.168.96.139 with SMTP id KevIDDKluciXPM.0101774008218; Fri, 21 Sep 2007 13:51:51 +0200 (GMT) Message-ID: <35A85F07.9EEC8EB4@aerofin.com> Date: Fri, 21 Sep 2007 13:51:48 +0200 From: "Greer Kroll" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: tsimytyt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Rumor News: Oncology Med. Inc. (OTC: ONCO) a Cancer Treatment Solutions Group is said to have experienced over a 1000% increase in revenues for the fiscal 3rd quarter ending July, 2007 compared with the prior year while fiscal fourth quarter results for 2007 are on track to exceed this year’s third quarter results. ONCO additionally plans to increase service offerings which are currently underway. Don’t wait for the news to come out and lose the opportunity to get in front of the general investing public. Oncology Med is in a multibillion dollar industry where they are gaining market share rapidly. Call your broker now for ONCO. From jbGancman@IFA.STATE.IA.US Sat Sep 22 16:05:44 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZBEW-0005h3-3r for simple-archive@lists.ietf.org; Sat, 22 Sep 2007 16:05:44 -0400 Received: from [82.152.194.132] (helo=[81.5.170.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZBEN-0004Zd-6e for simple-archive@lists.ietf.org; Sat, 22 Sep 2007 16:05:35 -0400 Received: from user-bd7153544c ([155.164.45.199] helo=user-bd7153544c) by [81.5.170.81] ( sendmail 8.13.3/8.13.1) with esmtpa id 1ZQneF-000VXX-un for simple-archive@lists.ietf.org; Sat, 22 Sep 2007 21:05:43 +0100 Message-ID: <000301c7fd53$ecc0f510$51aa0551@userbd7153544c> From: "jb Gancman" To: Subject: iehtonom Date: Sat, 22 Sep 2007 21:05:29 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7FD5C.4E855D10" 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: 3.5 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0003_01C7FD5C.4E855D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.moomauto.com/ Wassup simple-archive sex life boring??, im sure it would spice up again if you had that extra = 3 inches jb Gancman ------=_NextPart_000_0003_01C7FD5C.4E855D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.moomauto.com/
Wassup simple-archive
sex life boring??, im sure it would spice up = again if=20 you had that extra 3 inches
jb Gancman
------=_NextPart_000_0003_01C7FD5C.4E855D10-- From Mazhar335@oxygen2.net Sun Sep 23 15:19:22 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZWzC-0004Bn-FK for simple-archive@lists.ietf.org; Sun, 23 Sep 2007 15:19:22 -0400 Received: from [201.82.188.23] (helo=c952bc17.virtua.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZWz9-0008Bq-L3 for simple-archive@lists.ietf.org; Sun, 23 Sep 2007 15:19:20 -0400 Received: from xp2000 ([122.134.51.173] helo=xp2000) by c952bc17.virtua.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1JWenV-000HLQ-dO for simple-archive@lists.ietf.org; Sun, 23 Sep 2007 16:19:34 -0300 Message-ID: <000301c7fe16$a2f1ce00$17bc52c9@xp2000> From: "Mazhar Loteyro" To: Subject: gnigdulk Date: Sun, 23 Sep 2007 16:19:17 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7FDFD.7DA49600" 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: 3.3 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C7FDFD.7DA49600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://gspmmatv.com/ Hi there simple-archive tired of being just mr average to the ladies? Mazhar Loteyro ------=_NextPart_000_0008_01C7FDFD.7DA49600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://gspmmatv.com/
Hi there simple-archive
tired of being just mr average to the = ladies?
Mazhar Loteyro
------=_NextPart_000_0008_01C7FDFD.7DA49600-- From Yoann-poker@michaelparisi.net Sun Sep 23 17:14:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZYn1-0007qv-76 for simple-archive@lists.ietf.org; Sun, 23 Sep 2007 17:14:55 -0400 Received: from host81-146-67-228.btremoteinternet-dsl.bt.net ([81.146.67.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZYmv-0001uo-CM for simple-archive@lists.ietf.org; Sun, 23 Sep 2007 17:14:49 -0400 Received: from LeeRoom ([176.169.61.173] helo=LeeRoom) by host81-146-67-228.btremoteinternet-dsl.bt.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1OEnfY-000PHM-OL for simple-archive@lists.ietf.org; Sun, 23 Sep 2007 22:15:30 +0100 Message-ID: <000501c7fe26$cbe71580$e4439251@LeeRoom> From: "Yoann poker" To: Subject: ye-klahc Date: Sun, 23 Sep 2007 22:14:58 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7FE2F.2DAB7D80" 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: 3.5 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0004_01C7FE2F.2DAB7D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://scrir.com/ Good night simple-archive get a BIG schlong, check this website out. Yoann poker ------=_NextPart_000_0004_01C7FE2F.2DAB7D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://scrir.com/
Good night simple-archive
get a BIG schlong, check this website = out.
Yoann poker
------=_NextPart_000_0004_01C7FE2F.2DAB7D80-- From Garlocklfxe@dynamicdesigndevelopment.com Tue Sep 25 13:02:37 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaDnx-0003sS-PO for simple-archive@lists.ietf.org; Tue, 25 Sep 2007 13:02:37 -0400 Received: from fhd186.internetdsl.tpnet.pl ([83.13.185.186]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaDnt-0005lV-JS for simple-archive@lists.ietf.org; Tue, 25 Sep 2007 13:02:35 -0400 Received: from ka-mo6lwd5u32ln ([133.144.5.100] helo=ka-mo6lwd5u32ln) by fhd186.internetdsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1knMPC-000IIH-oU for simple-archive@lists.ietf.org; Tue, 25 Sep 2007 19:03:17 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 25 Sep 2007 19:02:55 +0200 To: simple-archive@lists.ietf.org From: "Isabel Garlock" Subject: uortep Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Wazzup simple-archive My cock is soooo big now, thanks to these doctors Isabel Garlock http://laluse.com/ From montana96fu-zong9@brianrogers.net Tue Sep 25 15:09:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFn9-00017u-8o for simple-archive@lists.ietf.org; Tue, 25 Sep 2007 15:09:55 -0400 Received: from [189.30.99.108] (helo=189.30.99.108) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaFn7-0006tv-Bo for simple-archive@lists.ietf.org; Tue, 25 Sep 2007 15:09:55 -0400 Received: from [189.30.99.108] by trtfpgdk.brianrogers.net; Tue, 25 Sep 2007 19:09:45 +0000 Message-ID: <000601c7ffa7$042e1e66$f23d6c9f@etrtfpgd> From: "Cruz Pollard" To: "Hung Marion" Subject: Fwd: Thanks, we are ready to lend money regardless of Credit Date: Tue, 25 Sep 2007 17:22:23 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7FFA7.042DFF98" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 2.7 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C7FFA7.042DFF98 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you have your own business and require IMMEDIATE cash to spend ANY = way you like or wish Extra money to give your company a boost or want A = low interest loan - NO STRINGS ATTACHED, here is the deal we can offer = you TODAY (hurry, this deal will expire THIS NIGHT):   $29,000+ loan   Hurry, when our best deal is gone, it is gone. Simply Call Us Free on=20 877-292-6892 ------=_NextPart_000_0003_01C7FFA7.042DFF98 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you have your own business and = require IMMEDIATE cash to spend ANY way you like or wish Extra money to = give your company a boost or want A low interest loan - NO STRINGS = ATTACHED, here is the deal we can offer you TODAY (hurry, this deal will = expire THIS NIGHT):
=20
 
$29,000+ loan
 
Hurry, when our best deal is gone, it = is gone. Simply Call Us Free on 877-292-6892
------=_NextPart_000_0003_01C7FFA7.042DFF98-- From simple-bounces@ietf.org Tue Sep 25 18:39: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 1IaJ17-0000ad-V1; Tue, 25 Sep 2007 18:36:34 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IaJ16-0000RI-Ak for simple-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 18:36:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaJ15-0000Lh-RX; Tue, 25 Sep 2007 18:36:31 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaJ0z-0004YC-Lr; Tue, 25 Sep 2007 18:36:31 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 6E19CE4E77; Tue, 25 Sep 2007 15:32:32 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20070925223232.6E19CE4E77@bosco.isi.edu> Date: Tue, 25 Sep 2007 15:32:32 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 4976 on Relay Extensions for the Message Sessions Relay Protocol (MSRP) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4976 Title: Relay Extensions for the Message Sessions Relay Protocol (MSRP) Author: C. Jennings, R. Mahy, A. B. Roach Status: Standards Track Date: September 2007 Mailbox: fluffy@cisco.com, rohan@ekabal.com, adam@estacado.net Pages: 36 Characters: 84244 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-msrp-relays-10.txt URL: http://www.rfc-editor.org/rfc/rfc4976.txt Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example:From simple-bounces@ietf.org Tue Sep 25 18:39: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 1IaJ17-0000ad-V1; Tue, 25 Sep 2007 18:36:34 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IaJ16-0000RI-Ak for simple-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 18:36:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaJ15-0000Lh-RX; Tue, 25 Sep 2007 18:36:31 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaJ0z-0004YC-Lr; Tue, 25 Sep 2007 18:36:31 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 6E19CE4E77; Tue, 25 Sep 2007 15:32:32 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20070925223232.6E19CE4E77@bosco.isi.edu> Date: Tue, 25 Sep 2007 15:32:32 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 4976 on Relay Extensions for the Message Sessions Relay Protocol (MSRP) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4976 Title: Relay Extensions for the Message Sessions Relay Protocol (MSRP) Author: C. Jennings, R. Mahy, A. B. Roach Status: Standards Track Date: September 2007 Mailbox: fluffy@cisco.com, rohan@ekabal.com, adam@estacado.net Pages: 36 Characters: 84244 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-msrp-relays-10.txt URL: http://www.rfc-editor.org/rfc/rfc4976.txt Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 25 18:39: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 1IaJ0h-0006CK-RV; Tue, 25 Sep 2007 18:36:07 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IaJ0g-0006CB-FU for simple-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 18:36:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaJ0g-0006C3-40; Tue, 25 Sep 2007 18:36:06 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaJ0f-0008JY-LQ; Tue, 25 Sep 2007 18:36:06 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 43F52E4E75; Tue, 25 Sep 2007 15:32:22 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20070925223222.43F52E4E75@bosco.isi.edu> Date: Tue, 25 Sep 2007 15:32:22 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 4975 on The Message Session Relay Protocol (MSRP) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4975 Title: The Message Session Relay Protocol (MSRP) Author: B. Campbell, Ed., R. Mahy, Ed., C. Jennings, Ed. Status: Standards Track Date: September 2007 Mailbox: ben@estacado.net, rohan@ekabal.com, fluffy@cisco.com Pages: 63 Characters: 144254 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-message-sessions-19.txt URL: http://www.rfc-editor.org/rfc/rfc4975.txt This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DI To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 25 18:39: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 1IaJ0h-0006CK-RV; Tue, 25 Sep 2007 18:36:07 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IaJ0g-0006CB-FU for simple-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 18:36:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaJ0g-0006C3-40; Tue, 25 Sep 2007 18:36:06 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaJ0f-0008JY-LQ; Tue, 25 Sep 2007 18:36:06 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 43F52E4E75; Tue, 25 Sep 2007 15:32:22 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20070925223222.43F52E4E75@bosco.isi.edu> Date: Tue, 25 Sep 2007 15:32:22 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 4975 on The Message Session Relay Protocol (MSRP) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4975 Title: The Message Session Relay Protocol (MSRP) Author: B. Campbell, Ed., R. Mahy, Ed., C. Jennings, Ed. Status: Standards Track Date: September 2007 Mailbox: ben@estacado.net, rohan@ekabal.com, fluffy@cisco.com Pages: 63 Characters: 144254 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-message-sessions-19.txt URL: http://www.rfc-editor.org/rfc/rfc4975.txt This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From HonoreNormN@nobleminds.net Wed Sep 26 06:21:56 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaU1k-0004eM-Sq for simple-archive@lists.ietf.org; Wed, 26 Sep 2007 06:21:56 -0400 Received: from areims-157-1-50-189.w83-204.abo.wanadoo.fr ([83.204.17.189] helo=AReims-157-1-130-158.w90-18.abo.wanadoo.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaU1V-0002B2-Sz for simple-archive@lists.ietf.org; Wed, 26 Sep 2007 06:21:42 -0400 Received: from xpsp2-afdis37da ([118.171.150.187]:2599 "EHLO xpsp2-afdis37da" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by AReims-157-1-130-158.w90-18.abo.wanadoo.fr with ESMTP id S22BQSEFZWGHXAYK (ORCPT ); Wed, 26 Sep 2007 12:27:54 +0200 Message-ID: <000701c80027$d16f0e60$9eb9125a@xpsp2afdis37da> From: "Honore NormN" To: Subject: lkaarten Date: Wed, 26 Sep 2007 12:27:19 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C80038.94F7DE60" 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-Antivirus: avast! (VPS 000777-0, 26/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0004_01C80038.94F7DE60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://cinelon.com/ regards simple-archive i am the most confident person in the world now.. Honore NormN ------=_NextPart_000_0004_01C80038.94F7DE60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://cinelon.com/
regards simple-archive
i am the most confident person in the world = now..
Honore NormN
------=_NextPart_000_0004_01C80038.94F7DE60-- From Oula-Halmetoja@goldpass.ca Thu Sep 27 08:45:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iasjn-00068N-01 for simple-archive@lists.ietf.org; Thu, 27 Sep 2007 08:45:03 -0400 Received: from adsl-d245.84-47-61.t-com.sk ([84.47.61.245]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iasjg-0007BN-CG for simple-archive@lists.ietf.org; Thu, 27 Sep 2007 08:44:56 -0400 Received: from your-db31031de6 ([153.183.105.27] helo=your-db31031de6) by adsl-d245.84-47-61.t-com.sk ( sendmail 8.13.3/8.13.1) with esmtpa id 1VToSu-000EUA-nv for simple-archive@lists.ietf.org; Thu, 27 Sep 2007 14:45:22 +0200 Message-ID: <000b01c80104$34829850$f53d2f54@yourdb31031de6> From: "Oula Halmetoja" To: simple-archive@lists.ietf.org Subject: myyttine Date: Thu, 27 Sep 2007 14:44:55 +0200 Message-ID: <000b01c80104$34829850$f53d2f54@yourdb31031de6> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Good night simple-archive ladies like em big, so i enlarged my cock just to please them.. Oula Halmetoja http://www.cherrfan.com/ From Tapio.boble@profsoft.com Fri Sep 28 00:13:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib7Ek-0002VL-2r for simple-archive@lists.ietf.org; Fri, 28 Sep 2007 00:13:58 -0400 Received: from [195.46.100.198] (helo=[195.46.100.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib7Ee-0003Fs-IH for simple-archive@lists.ietf.org; Fri, 28 Sep 2007 00:13:54 -0400 Received: from Kirova16 by profsoft.com with ASMTP id 4A450CE0 for ; Fri, 28 Sep 2007 13:15:47 +0900 Received: from Kirova16 ([188.124.59.66]) by profsoft.com with ESMTP id 2A33FE0033AB for ; Fri, 28 Sep 2007 13:15:47 +0900 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 28 Sep 2007 13:15:30 +0900 To: simple-archive@lists.ietf.org From: "Tapio boble" Subject: 0nials Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Mining Sector --- Delta Mining UPDATE HOT SECTOR: Additional information on (O_T_C: D M X C) D M X C is expected to arrive soon. For those of you who currently own this company this will be great news. For those that don't currently own this company, you need to get in on this now. The company recently traded as high as .13 and with any significant news should be able to see (if not exceed) those prices again. Contact your broker now, don't miss this opportunity in D M X C! From simple-bounces@ietf.org Fri Sep 28 03:06:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib9t4-0007BN-DE; Fri, 28 Sep 2007 03:03:46 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1Ib9t2-0007B5-3Q for simple-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 03:03:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib9sx-00077F-UF; Fri, 28 Sep 2007 03:03:39 -0400 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 1Ib9sr-0006yE-Il; Fri, 28 Sep 2007 03:03:39 -0400 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 l8S730ox012915; Fri, 28 Sep 2007 10:03:27 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 10:02:48 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 10:02:47 +0300 Received: from esdhcp04073.research.nokia.com ([172.21.40.73]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 10:02:46 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: simple@ietf.org, christer.holmberg@ericsson.com Date: Fri, 28 Sep 2007 10:02:52 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline X-UID: 382 Content-Type: Multipart/Mixed; boundary="Boundary-00=_ccK/GOzk5GGCUZH" Message-Id: <200709281002.52399.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 28 Sep 2007 07:02:46.0573 (UTC) FILETIME=[92E05DD0:01C8019D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: mmusic@ietf.org, aki.niemi@nokia.com Subject: [Simple] MSRP and traversal (was Re: ICE and MSRP) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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 --Boundary-00=_ccK/GOzk5GGCUZH Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Christer, Le Thursday 27 September 2007 11:14:27 ext Christer Holmberg, vous avez=20 =C3=A9crit=C2=A0: > Has there been any discussions/studies on how ICE works with MSRP, where > routing is not done based on SDP m/c/candidate information, but on > information in the MSRP messages themselves? At some point in the recent past, there was draft-niemi-simple-msrp-ice:=20 http://www3.ietf.org/proceedings/07mar/slides/simple-7.pdf The draft proposed using ICE-TCP instead of MSRP path routing, but is=20 currently expired. I think the main issue is, contrary to UDP, TCP works pretty terribly if th= ere=20 is a NAT or stateful firewall on both sides. At least from Aki's and my=20 admittedly limited experiments, whenever "normal" TCP fails due to NAT or=20 firewall, TCP "simultaneous open" almost always fails as well :-( Because of this, I submitted a simpler solution draft, using only COMEDIA=20 instead of full ICE-TCP: https://datatracker.ietf.org/drafts/draft-denis-simple-msrp-comedia/ That would at least make MSRP work when one side has a public IP, which is= =20 hardly worse but much simpler than what draft-niemi-simple-msrp-ice did.=20 Bashing^WComments welcome. =2D-=20 R=C3=A9mi Denis-Courmont --Boundary-00=_ccK/GOzk5GGCUZH Content-Type: application/mbox; name="msrp-comedia-00.eml" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="msrp-comedia-00.eml" =46rom developers@ietf.org Tue Sep 25 16:29:41 2007 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebe108.NOE.Nok= ia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 16:29:45 +0300 Received: from esebh107.NOE.Nokia.com ([172.21.143.143]) by esebh104.NOE.No= kia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 16:29:45 +0300 Received: from mgw-mx04.nokia.com ([192.100.122.231]) by esebh107.NOE.Nokia= =2Ecom with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 16:29:44 +0300 Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by mgw-mx04.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id l8PDTfaa01= 3736 (version=3DTLSv1/SSLv3 cipher=3DDHE-RSA-AES256-SHA bits=3D256 verify=3DFAI= L) for ; Tue, 25 Sep 2007 16:29:43 +0300 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 35F46328CF for ; Tue, 25 Sep 2007 13:29:41 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IaATt-0003pX-4K for remi.denis-courmont@nokia.com; Tue, 25 Sep 2007 09:29:41 -0400 Content-Type: text/plain; charset=3D"utf-8" Mime-Version: 1.0 To: remi.denis-courmont@nokia.com Cc:=20 =46rom: "ext IETF I-D Submission Tool" Subject: New Version Notification for draft-denis-simple-msrp-comedia-00=20 Message-Id: Date: Tue, 25 Sep 2007 09:29:41 -0400 X-Nokia-AV: Clean X-pstn-spam: W X-Spam-Score: 0.00% Return-Path: mirror@ietf.org X-OriginalArrivalTime: 25 Sep 2007 13:29:44.0839 (UTC) FILETIME=3D[22CD5970= :01C7FF78] X-UID: 11689 X-Length: 2431 Status: R X-Status: NC X-KMail-EncryptionState: =20 X-KMail-SignatureState: =20 X-KMail-MDN-Sent: =20 A new version of I-D, draft-denis-simple-msrp-comedia-00.txt has been succe= ssfuly submitted by Remi Denis-Courmont and posted to the IETF repository. =46ilename: draft-denis-simple-msrp-comedia Revision: 00 Title: Connection setup negociation for the Message Session Relay Protocol Creation_date: 2007-09-25 WG ID: Independent Submission Number_of_pages: 10 Abstract: This document extends the MSRP connection model to negotiate the direction of the TCP connection setup. This provides a partial yet simple solution for scenarios whereby either, but not both, party to an MSRP session is located behind a NAT or firewall, and cannot serve as the passive endpoint for TCP connection setup. = =20 The IETF Secretariat. --Boundary-00=_ccK/GOzk5GGCUZH 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 --Boundary-00=_ccK/GOzk5GGCUZH-- From simple-bounces@ietf.org Fri Sep 28 06:13: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 1IbCnG-00042C-EL; Fri, 28 Sep 2007 06:09:58 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IbCnE-000424-Ds for simple-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 06:09:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbCnE-0003um-3O for simple@ietf.org; Fri, 28 Sep 2007 06:09:56 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbCmx-0001BI-9P for simple@ietf.org; Fri, 28 Sep 2007 06:09:39 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id l8SA9X1d038938 for ; Fri, 28 Sep 2007 10:09:33 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.5) with ESMTP id l8SA9XoR2191454 for ; Fri, 28 Sep 2007 12:09:33 +0200 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 l8SA9XaE014020 for ; Fri, 28 Sep 2007 12:09:33 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l8SA9XqL014017 for ; Fri, 28 Sep 2007 12:09:33 +0200 From: Gil Perzy To: simple@ietf.org Message-ID: Date: Fri, 28 Sep 2007 12:09:31 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 28/09/2007 12:09:32 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Simple] Gil Perzy is out of the office. 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 will be out of the office starting 26/09/2007 and will not return until 30/09/2007. I will respond to your message when I return. For urgent issues please contact Lior Sion _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 28 11:43:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbHxk-0007wD-Gu; Fri, 28 Sep 2007 11:41:08 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IbHxj-0007vz-HI for simple-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 11:41:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbHxj-0007vr-7D; Fri, 28 Sep 2007 11:41:07 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbHxi-0002Lk-W5; Fri, 28 Sep 2007 11:41:07 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A9D17175D0; Fri, 28 Sep 2007 15:41:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IbHxd-0002ku-7K; Fri, 28 Sep 2007 11:41:01 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 28 Sep 2007 11:41:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: simple@ietf.org Subject: [Simple] Last Call: draft-garcia-simple-presence-dictionary (The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)) 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 an individual submitter to consider the following document: - 'The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp) ' 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-10-26. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-garcia-simple-presence-dictionary-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14817&rfc_flag=0 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From polidario@allcountyinsurance.net Sat Sep 29 03:09:50 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbWSU-0003V4-K5 for simple-archive@lists.ietf.org; Sat, 29 Sep 2007 03:09:50 -0400 Received: from pool-71-245-45-191.sctnpa.east.verizon.net ([71.245.45.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbWSL-0002bs-6V for simple-archive@lists.ietf.org; Sat, 29 Sep 2007 03:09:41 -0400 Received: from Sue ([181.177.175.102] helo=Sue) by pool-71-245-45-191.sctnpa.east.verizon.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1emiJo-000JXH-cq for simple-archive@lists.ietf.org; Sat, 29 Sep 2007 03:10:11 -0400 Message-ID: <000801c80267$b27c5980$bf2df547@Sue> From: "BoWon polidario" To: Subject: isenable Date: Sat, 29 Sep 2007 03:09:37 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C80246.2B6AB980" 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: 4.6 (++++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a ------=_NextPart_000_0007_01C80246.2B6AB980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi To simple-archive Emergency report. Check DMXC! Price up 21% in 30 minutes! 5 day price: ~$0.50 ------=_NextPart_000_0007_01C80246.2B6AB980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi To simple-archive
Emergency report. Check DMXC!
Price up 21% in 30 minutes!
5 day price: ~$0.50
------=_NextPart_000_0007_01C80246.2B6AB980-- From huntleyfdo@pmddirect.com Sun Sep 30 04:10:22 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibtsc-0006fp-Tz for simple-archive@lists.ietf.org; Sun, 30 Sep 2007 04:10:22 -0400 Received: from adsl-ull-14-49.51-151.net24.it ([151.51.49.14] helo=[151.51.20.210]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbtsN-0004oe-3n for simple-archive@lists.ietf.org; Sun, 30 Sep 2007 04:10:07 -0400 Received: by 10.20.145.28 with SMTP id cdKMugSijxCje; Sun, 30 Sep 2007 10:10:10 +0200 (GMT) Received: by 192.168.206.64 with SMTP id rJpGIKlBbuhdqa.3663332426918; Sun, 30 Sep 2007 10:10:08 +0200 (GMT) Message-ID: <000b01c80339$4f46ac30$b72a3397@windowsxvmapdi> From: "Greb huntley" To: Subject: nrotegpo Date: Sun, 30 Sep 2007 10:10:05 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C8034A.12CF7C30" 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.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 ------=_NextPart_000_0006_01C8034A.12CF7C30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello simple-archive Urgent alert. Look at DM XC! 5-day price: ~$0.50 Get it at monday n{ringsr nrotnodo nsenetje notrespa ------=_NextPart_000_0006_01C8034A.12CF7C30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello simple-archive
Urgent alert.
Look at DM XC!
5-day price: ~$0.50
Get it at monday
n{ringsr
nrotnodo
nsenetje
notrespa
------=_NextPart_000_0006_01C8034A.12CF7C30-- From nieves@dethermostaat.nl Sun Sep 30 07:59:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbxRx-0005k7-1w for simple-archive@lists.ietf.org; Sun, 30 Sep 2007 07:59:05 -0400 Received: from bwv154.internetdsl.tpnet.pl ([83.18.229.154]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbxRw-0001bT-EA for simple-archive@lists.ietf.org; Sun, 30 Sep 2007 07:59:04 -0400 Received: from piast ([100.152.193.147] helo=piast) by bwv154.internetdsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1efmtL-000ZUR-OA for simple-archive@lists.ietf.org; Sun, 30 Sep 2007 13:59:52 +0200 Message-ID: <000701c80359$5a6a7cc0$9ae51253@piast> From: "Silvina nieves" To: Subject: aehhtuoy Date: Sun, 30 Sep 2007 13:59:28 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C8036A.1DF34CC0" 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: a7d6aff76b15f3f56fcb94490e1052e4 ------=_NextPart_000_0007_01C8036A.1DF34CC0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Good day simple-archive Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 aecidiof aginella agaiku aedioyht ------=_NextPart_000_0007_01C8036A.1DF34CC0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Good day simple-archive
Alert to all investors!
Look at D-M-X-C!
5-day price: ~$0.50
Check it at 31.09.2007
aecidiof
aginella
agaiku
aedioyht
------=_NextPart_000_0007_01C8036A.1DF34CC0-- From Rockle@amershamauto.com Sun Sep 30 22:22:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcAv3-0002mb-Q3 for simple-archive@lists.ietf.org; Sun, 30 Sep 2007 22:22:01 -0400 Received: from [190.42.201.166] (helo=[190.42.201.166]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcAv3-0002Vp-AL for simple-archive@lists.ietf.org; Sun, 30 Sep 2007 22:22:01 -0400 Received: from to-e8666e93d2aa ([120.188.13.16]:8357 "EHLO to-e8666e93d2aa" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [190.42.201.166] with ESMTP id S22HJXZSSGIREPQU (ORCPT ); Sun, 30 Sep 2007 21:22:21 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 30 Sep 2007 21:22:01 -0500 To: simple-archive@lists.ietf.org From: "Easa Rockle" Subject: cigliavi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Good day simple-archive Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 cinomedu ciperons clattery cidohtak