From wpc@stievater.com Mon May 07 05:36:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkzdW-00021m-Mb for simple-archive@lists.ietf.org; Mon, 07 May 2007 05:36:06 -0400 Received: from [200.168.220.6] (helo=wt-man.allcenter.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HkzdU-000293-UD for simple-archive@lists.ietf.org; Mon, 07 May 2007 05:36:06 -0400 Received: from [41.99.218.33] (helo=cdhh) by wt-man.allcenter.net with smtp (Exim 4.62 (FreeBSD)) id 1INZh-0006mX-UI; Mon, 7 May 2007 06:38:21 -0300 Message-ID: <001301c7908b$239723b0$21da6329@cdhh> From: "Benny Lott" To: Subject: We're confident that our customers will be very interested in the names Internet Finance is offering for sale," said Monte Cahn, co founder and CEO of Moniker. Date: Mon, 7 May 2007 06:36:07 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac The cream of the crop for 2007 - GET IN EARLY! DSDI IS SET TO ROCK YOUR PORTFOLIO! DSI Direct Sales, Inc. Symbol: DSDI Price: $0.05 There is a MASSIVE PROMOTION underway this weekend! This is hot, read the news and get on DSDI first thing Monday! The blog covers organizational and employee development topics, learning news and MindLeaders events. com), is an Internet marketing, interactive voice response (IVR), and dynamic web based applications firm. Founding partner, World Nomads, incorporated the system into its travel insurance business. ZenGuard offers assistance and expertise on strategic SAS system activities including: maintenance, troubleshooting, data integration, reporting as well as strategic advice. org) Random Quote When one area of taxation is reduced, other areas of taxation are increased to make up for it, most always having progressive taxes replaced with regressive ones. Ad Networks that refuse to adapt will quickly become obsolete. "We believe that our new ZenGuard service can extend ROI on SAS(R)9 BI systems and deliver cost savings across multiple systems. " BuzzLogic offers the features and scalability large companies require, yet is affordable for mid and even small-sized companies. "The new ZenGuard service will help qualified customers get the most from their SAS(R)9 investment. "For the DBAs the product identifies the exact modules and screens that affect database performance. Zunch Worldwide, Inc. To learn more about MagicYellow, or to register your busin 21st Street, New York, NY 10010 U. com offers useful advice for capitalizing on online consumers as a unique new marketing channel. "With the Olympics coming to China in 2008, many Chinese businesses want to establish a presence on the Web that will allow them to market their services to English-speaking visitors and countries. Zunch China also specializes in click fraud detection, localization and globalization services, blog marketing and interactive public relations. org) Random Quote They say one day He'll liquidate His holdings up on high, I say it's all speculation. The success of Podcamp Atlanta and Podcamp NYC proves that Podcasting is an incredibly effective tool for entrepreneurs and people passionate about what they promote. Brand holders can also outsource the entire process to CitizenHawk as part of the company's premium service. A higher score represents a more significant buzz factor. Recent Posts Apocryphal elementsGene GenieThe interwubs are so judgmentalRotten old willowHow many fossil hominins? People fly from all over the world to visit the Portable Media and Podcast Expo every fall to see the newest in technology and meet with other podcasters in person. org) Random Quote For centuries the leaders of Christian thought spoke of women as a necessary evil, and the greatest saints of the Church are those who despise women the most. "The power of open source is that it allows companies to pair best-of-breed components with best-of-breed ideas to drive innovation," said John Newton, CTO, Alfresco. Now, working with MuseGlobal allows us to deliver precisely-tailored blog content from millions of additional blogs, but in a way that truly adds value without overwhelming users. " Along with the Webbed-O-Meter, Webbed Marketing also plans on developing additional viral marketing tracking and management tools that will remain free to the public. " Features in the newest re This allows Newstex t This is not common with many ECM vendors. Founding partner, World Nomads, incorporated the system into its travel insurance business. It is also an excellent online guide for marketing students who want to stay updated on the latest marketing strategies and technological trends for competing in today's business world. " About Zunch China, Inc. "With the Olympics coming to China in 2008, many Chinese businesses want to establish a presence on the Web that will allow them to market their services to English-speaking visitors and countries. B2B Website Marketing Blog - Sayers Media Group Launches New Website Username: Password: Forgot your password? By providing the additional function that allows for ratings, reviews and opinions of services rendered, the added comments from users provides a far greater depth of value for the consumer. Michael Ruse in "Resolved: That evolutionists should acknowledge creation" Firing Line, 4 December 1997, p. org) Random Quote Hello Susie, this is Calvin. From simple-bounces@ietf.org Mon May 07 10:33:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl4HN-0006Pr-Oz; Mon, 07 May 2007 10:33:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl4HL-0006Pi-Mq for simple@ietf.org; Mon, 07 May 2007 10:33:32 -0400 Received: from an-out-0708.google.com ([209.85.132.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl4HL-0000dv-DO for simple@ietf.org; Mon, 07 May 2007 10:33:31 -0400 Received: by an-out-0708.google.com with SMTP id c34so158848anc for ; Mon, 07 May 2007 07:33:30 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=g7fw9qFjounNz/B2o4tuUMQipElcfmGd3L4Kd+W5j0jlAFDLu3OOqwa8x2MCI3OnNM48FVPRefhSGwsVYxHbCEali/cpEVtR3l2irq8YDdSbKnSbWBzrkTvNp4L55RzQS9Cn2nnpqIPUFSuv6BuAkCgh1LVdv6qmS3V5ehFjIIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=TVrOLci74AHYSV9iS9FjmYn2crMQDOrl5MkB76csviCMikhfHZGe7LgmwSYhVLGqeSOJWzrkJIMF/ky94r3zPBuqR7koJqeXtduVtnyZDeRW05hLCF31AZmbxNUXeXglO+/MVHsybELTjEqXStRsDXsC35m/TArGhYNs30GmVUQ= Received: by 10.100.106.5 with SMTP id e5mr4801798anc.1178548410574; Mon, 07 May 2007 07:33:30 -0700 (PDT) Received: by 10.100.125.18 with HTTP; Mon, 7 May 2007 07:33:30 -0700 (PDT) Message-ID: <44781c350705070733v3f30a24fp2781bf7166dc2d69@mail.gmail.com> Date: Mon, 7 May 2007 17:33:30 +0300 From: "Noga Tor" To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [Simple] Some Questions Regarding Presence attributes... 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="===============0811224871==" Errors-To: simple-bounces@ietf.org --===============0811224871== Content-Type: multipart/alternative; boundary="----=_Part_103012_4098282.1178548410452" ------=_Part_103012_4098282.1178548410452 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Everyone I have some questions I wanted to ask, regarding the Published Presence Attributes. I would appreciate any information you might have on any of the issued mentioned. 1. Authorization ============ if a presentity has defined an authorization rule granting persmission for certain presence attribute for the watcher. - does this mean that this watcher will never again enter the pending state? - If so, does this mean that reactive authorization (via winfo) can be done only once, and after that authorizations are done proactively only (via XCAP)? - Is all the above true, for the case of creating a rule that applies to the watcher, but not directly to him (i.e. domain identity)? meaning after a rule has been created for a domain, all watchers of this domain, will never enter the pending state? 2. Default values ============ Is there any way/need of defining default values for presence attributes? if a user published no/some attributes, do we need to fill up unpublished attributes with defaults? 3. Persistency =========== Are there any presence attributes that need to be persistent? For example, for attributes whose value is large - persistency can be used to avoid republishes of the large value. 4. IMPS - SIP translation ================== Is there any document or link to which you can refer me to that deals with mapping IMPS presence attributes to SIP presence attributes? Is this sort of effort being done somewhere? Thanks in advance, Noga Tor ------=_Part_103012_4098282.1178548410452 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Everyone
 
I have some questions I wanted to ask, regarding the Published Presence Attributes.
I would appreciate any information you might have on any of the issued mentioned.
 
1. Authorization
============
 
if a presentity has defined an authorization rule granting persmission for certain presence attribute for the watcher.
 
- does this mean that this watcher will never again enter the pending state?
- If so, does this mean that reactive authorization (via winfo) can be done only once, and after that authorizations are done proactively only (via XCAP)?
- Is all the above true, for the case of creating a rule that applies to the watcher, but not directly to him (i.e. domain identity)?
meaning after a rule has been created for a domain, all watchers of this domain, will never enter the pending state?
 
 
2. Default values
============
 
Is there any way/need of defining default values for presence attributes?
if a user published no/some attributes, do we need to fill up unpublished attributes with defaults?
 
 
3. Persistency
===========
 
Are there any presence attributes that need to be persistent?
For example, for attributes whose value is large - persistency can be used to avoid republishes of the large value.
 
 
4. IMPS - SIP translation
==================
 
Is there any document or link to which you can refer me to that deals with mapping IMPS presence attributes to SIP presence attributes?
Is this sort of effort being done somewhere?
 
 
Thanks in advance,
Noga Tor
------=_Part_103012_4098282.1178548410452-- --===============0811224871== 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 --===============0811224871==-- From simple-bounces@ietf.org Tue May 08 01:37:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlIOW-0005mf-7v; Tue, 08 May 2007 01:37:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlIOU-0005mM-Ss for simple@ietf.org; Tue, 08 May 2007 01:37:50 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlIOT-0005Us-2u for simple@ietf.org; Tue, 08 May 2007 01:37:50 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JHP00G8HJLHC8@szxga02-in.huawei.com> for simple@ietf.org; Tue, 08 May 2007 13:36:54 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JHP00LCMJLGRT@szxga02-in.huawei.com> for simple@ietf.org; Tue, 08 May 2007 13:36:53 +0800 (CST) Received: from HTIPL20760 ([10.18.4.165]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JHP000SZJLGVR@szxml03-in.huawei.com> for simple@ietf.org; Tue, 08 May 2007 13:36:52 +0800 (CST) Date: Tue, 08 May 2007 11:06:51 +0530 From: sreekanth To: simple@ietf.org Message-id: <001301c79132$e177b6e0$a504120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.3 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [Simple] Why LDAP... X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sreekanth 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="===============0201381379==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0201381379== Content-type: multipart/alternative; boundary="Boundary_(ID_4qjYxowSQxXx/wd01Aw2Ig)" This is a multi-part message in MIME format. --Boundary_(ID_4qjYxowSQxXx/wd01Aw2Ig) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, Why LDAP or ACAP cannot be used instead of XCAP?? -The following is from the XCAP presentation prepared by Rosenberg.. LDAP, ACAP, SNMP, relational DB cover related spaces, none successfully deployed to broad end client bases Can anyone clarify on this??? Rgds, Sreekanth This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_4qjYxowSQxXx/wd01Aw2Ig) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Hi,
 
Why LDAP or ACAP cannot be used instead = of=20 XCAP??
 
=96The following is from the XCAP presentation = prepared by=20 Rosenberg..
LDAP,=20 ACAP, SNMP, relational DB cover related spaces, none successfully = deployed to=20 broad end client bases
 
Can = anyone clarify on=20 this???
 
 
Rgds,
Sreekanth
This e-mail and attachments contain = confidential=20 information from HUAWEI, which is intended only for the person or entity = whose=20 address is listed above. Any use of the information contained herein in = any way=20 (including, but not limited to, total or partial disclosure, = reproduction, or=20 dissemination) by persons other than the intended recipient's) is = prohibited. If=20 you receive this e-mail in error, please notify the sender by phone or = email=20 immediately and delete it!
 
 
--Boundary_(ID_4qjYxowSQxXx/wd01Aw2Ig)-- --===============0201381379== 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 --===============0201381379==-- From simple-bounces@ietf.org Tue May 08 06:54: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 1HlNKm-0001l2-1W; Tue, 08 May 2007 06:54:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlNKl-0001kv-Ch for simple@ietf.org; Tue, 08 May 2007 06:54:19 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlNKj-0000Y2-U6 for simple@ietf.org; Tue, 08 May 2007 06:54:19 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l48AsAdw018841 for ; Tue, 8 May 2007 13:54:16 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 13:54:03 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 13:54:03 +0300 Received: from [172.21.59.24] ([172.21.59.24]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 13:54:03 +0300 Message-ID: <464056CA.1080209@nsn.com> Date: Tue, 08 May 2007 13:54:02 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: SIMPLE mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 May 2007 10:54:03.0229 (UTC) FILETIME=[30EFC8D0:01C7915F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Niemi Aki Petteri Subject: [Simple] MSRP chat: SIP-based nickname negotiation 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: We are trying to seek consensus and a bit more of discussion about the MSRP chat, to be precise, about the nickname capability, which is the most contentious issue so far. We don't discuss in this e-mail other issues, just nicknames. According to the minutes of the meeting in Prague, we understood that we should be seeking a nickname negotiation mechanism outside MSRP. For example, SIP. For what I recall from conversations years ago, the mechanism should be also applicable to regular sessions, not only those that contain MSRP or not only conferences. So, based on that, we would like to get comments on the following proposal: - Model the nickname capability in SIP as a option tag in Supported/Require headers * Whether to have Require in outgoing INVITEs is open - New header field "Set-Nickname" or something is added to the INVITE request. - Value of the Set-Nickname header field: Option 1) Either the header takes a single token value * URN scheme that embeds this token, and later goes into CPIM TO/From * Other option (maybe better) is to still use a naming convention and SIP URIs. Option 2) Another option is to have UA insert a Display-Name and SIP URI * The SIP URI represents the nickname and it is scoped to the chatroom or domain * The Display-Name is used for rendering purposes. * This is what the current draft says - We create a new error response code 4xx: Nickname Not Accepted * Optional Proposed-Nicknames header field proposing alternatives And before Keith jumps above me indicating that this work should be done in the SIP working group, yes, we are aware of RFC 3427, and this work, if agreed in SIMPLE, should move to SIP as some point in time. But let's see if SIMPLE agrees first. BR, Miguel -- Please note my new e-mail address: miguel.garcia at nsn.com Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 08 09:24: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 1HlPfu-0006Nc-RR; Tue, 08 May 2007 09:24:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlPft-0006NW-SF for simple@ietf.org; Tue, 08 May 2007 09:24:17 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlPfr-0000ZF-IP for simple@ietf.org; Tue, 08 May 2007 09:24:17 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 08 May 2007 09:24:15 -0400 X-IronPort-AV: i="4.14,505,1170651600"; d="scan'208"; a="120553026:sNHT50391644" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l48DOFq9015119; Tue, 8 May 2007 09:24:15 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l48DNmli025228; Tue, 8 May 2007 13:24:15 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 09:24:13 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 09:24:12 -0400 Message-ID: <464079FC.50704@cisco.com> Date: Tue, 08 May 2007 09:24:12 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> In-Reply-To: <464056CA.1080209@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 May 2007 13:24:12.0911 (UTC) FILETIME=[2B2027F0:01C79174] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2702; t=1178630655; x=1179494655; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20MSRP=20chat=3A=20SIP-based=20nickname=20ne gotiation |Sender:=20 |To:=20Miguel=20Garcia=20; bh=wwa9yEf2cnDsxKdKNQCt6U1scoCFRJJ6T+1a1cY5PKo=; b=hK3prSIui9bDVrICvYKZOF0x2CY/MQo+m1pepRaQ8VxdbjOvGEkkzU/FEbBhEms7HiBDafBi BL92nbAYoRRubaA/Pb03VmAGT/6CEm7tfumQQqSSPd+fr91Je332WvRC; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: SIMPLE mailing list , Niemi Aki Petteri X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Miguel, IMO the most straightforward way to handle nicknames is to treat them as a form of anonymization, provided by an anonymizer. Namely, you establish a nickname server, which is a form of B2BUA. You establish an account with it that defines a mapping between your actual AOR and the nickname you want to be known by, drawn from the address space of the server. Then you relay your request for the chat room (or whatever) through this server. This can be a server entirely independent of the chat room. But it would also be fine for the provider of a chat room server to couple a nickname service with it, perhaps coupling the mapping of real name to nickname to the lifetime of a particular chat room. Paul Miguel Garcia wrote: > Hi: > > We are trying to seek consensus and a bit more of discussion about the > MSRP chat, to be precise, about the nickname capability, which is the > most contentious issue so far. We don't discuss in this e-mail other > issues, just nicknames. > > According to the minutes of the meeting in Prague, we understood that we > should be seeking a nickname negotiation mechanism outside MSRP. For > example, SIP. For what I recall from conversations years ago, the > mechanism should be also applicable to regular sessions, not only those > that contain MSRP or not only conferences. > > So, based on that, we would like to get comments on the following proposal: > > - Model the nickname capability in SIP as a option tag in > Supported/Require headers > * Whether to have Require in outgoing INVITEs is open > > - New header field "Set-Nickname" or something is added to the INVITE > request. > > - Value of the Set-Nickname header field: > Option 1) Either the header takes a single token value > * URN scheme that embeds this token, and later goes into CPIM TO/From > * Other option (maybe better) is to still use a naming > convention and SIP URIs. > > Option 2) Another option is to have UA insert a Display-Name and SIP URI > * The SIP URI represents the nickname and it is scoped to the > chatroom or domain > * The Display-Name is used for rendering purposes. > * This is what the current draft says > > - We create a new error response code 4xx: Nickname Not Accepted > * Optional Proposed-Nicknames header field proposing alternatives > > > > And before Keith jumps above me indicating that this work should be done > in the SIP working group, yes, we are aware of RFC 3427, and this work, > if agreed in SIMPLE, should move to SIP as some point in time. But let's > see if SIMPLE agrees first. > > BR, > > Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 08 09:35: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 1HlPqh-0005DX-5L; Tue, 08 May 2007 09:35:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlPqf-0005DM-OP for simple@ietf.org; Tue, 08 May 2007 09:35:25 -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 1HlPqf-00021F-8k for simple@ietf.org; Tue, 08 May 2007 09:35:25 -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 l48DYvQI004763; Tue, 8 May 2007 16:35:20 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 16:35:07 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 16:35:07 +0300 Received: from [172.21.59.24] ([172.21.59.24]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 16:35:06 +0300 Message-ID: <46407C8A.6030000@nsn.com> Date: Tue, 08 May 2007 16:35:06 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> In-Reply-To: <464079FC.50704@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 May 2007 13:35:06.0734 (UTC) FILETIME=[B0D5A0E0:01C79175] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: SIMPLE mailing list , Niemi Aki Petteri 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 Aren't you assuming that if a user is willing to use nicknames at the same time wants to remain anonymous from his SIP URI? I thought these are two independent issues. I may want to reveal or hide my SIP URI, and I may want to reveal or hide my nickname. /Miguel Paul Kyzivat wrote: > Miguel, > > IMO the most straightforward way to handle nicknames is to treat them as > a form of anonymization, provided by an anonymizer. Namely, you > establish a nickname server, which is a form of B2BUA. You establish an > account with it that defines a mapping between your actual AOR and the > nickname you want to be known by, drawn from the address space of the > server. Then you relay your request for the chat room (or whatever) > through this server. > > This can be a server entirely independent of the chat room. But it would > also be fine for the provider of a chat room server to couple a nickname > service with it, perhaps coupling the mapping of real name to nickname > to the lifetime of a particular chat room. > > Paul > > Miguel Garcia wrote: >> Hi: >> >> We are trying to seek consensus and a bit more of discussion about the >> MSRP chat, to be precise, about the nickname capability, which is the >> most contentious issue so far. We don't discuss in this e-mail other >> issues, just nicknames. >> >> According to the minutes of the meeting in Prague, we understood that >> we should be seeking a nickname negotiation mechanism outside MSRP. >> For example, SIP. For what I recall from conversations years ago, the >> mechanism should be also applicable to regular sessions, not only >> those that contain MSRP or not only conferences. >> >> So, based on that, we would like to get comments on the following >> proposal: >> >> - Model the nickname capability in SIP as a option tag in >> Supported/Require headers >> * Whether to have Require in outgoing INVITEs is open >> >> - New header field "Set-Nickname" or something is added to the INVITE >> request. >> >> - Value of the Set-Nickname header field: >> Option 1) Either the header takes a single token value >> * URN scheme that embeds this token, and later goes into CPIM TO/From >> * Other option (maybe better) is to still use a naming >> convention and SIP URIs. >> >> Option 2) Another option is to have UA insert a Display-Name and SIP URI >> * The SIP URI represents the nickname and it is scoped to the >> chatroom or domain >> * The Display-Name is used for rendering purposes. >> * This is what the current draft says >> >> - We create a new error response code 4xx: Nickname Not Accepted >> * Optional Proposed-Nicknames header field proposing alternatives >> >> >> >> And before Keith jumps above me indicating that this work should be >> done in the SIP working group, yes, we are aware of RFC 3427, and this >> work, if agreed in SIMPLE, should move to SIP as some point in time. >> But let's see if SIMPLE agrees first. >> >> BR, >> >> Miguel -- Please note my new e-mail address: miguel.garcia at nsn.com Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 08 09:54: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 1HlQ9I-0000n1-4I; Tue, 08 May 2007 09:54:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlQ9H-0000mv-B3 for simple@ietf.org; Tue, 08 May 2007 09:54:39 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlQ9F-0007eE-Rp for simple@ietf.org; Tue, 08 May 2007 09:54:39 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l48DsRCO015044; Tue, 8 May 2007 16:54:33 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 16:54:17 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 16:54:17 +0300 Received: from [172.21.41.241] (esdhcp041241.research.nokia.com [172.21.41.241]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l48DsF6n021970; Tue, 8 May 2007 16:54:16 +0300 Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation From: Aki Niemi To: ext Paul Kyzivat In-Reply-To: <464079FC.50704@cisco.com> References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> Content-Type: text/plain Organization: Nokia Date: Tue, 08 May 2007 16:54:15 +0300 Message-Id: <1178632455.26822.10.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 May 2007 13:54:17.0662 (UTC) FILETIME=[5ED74DE0:01C79178] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Miguel Garcia , SIMPLE mailing list 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, 2007-05-08 at 09:24 -0400, ext Paul Kyzivat wrote: > Miguel, > > IMO the most straightforward way to handle nicknames is to treat them as > a form of anonymization, provided by an anonymizer. Namely, you > establish a nickname server, which is a form of B2BUA. You establish an > account with it that defines a mapping between your actual AOR and the > nickname you want to be known by, drawn from the address space of the > server. Then you relay your request for the chat room (or whatever) > through this server. > > This can be a server entirely independent of the chat room. But it would > also be fine for the provider of a chat room server to couple a nickname > service with it, perhaps coupling the mapping of real name to nickname > to the lifetime of a particular chat room. This sort of thing is a very valid model, but I don't think we want to require this to be the *only* way to acquire or use nicknames. In fact, many IRC services out there offer a way for a user to grab hold of a nickname permanently or semi-permanently. For example, one popular service I know of has a policy where the nicks can be registered (via web/email) and either get released by admin intervention or by being inactive for a certain amount of days/months. The service still allows people to connect and create nicks on the fly as well. And the way you would prove you "own" a nick is by providing a password along with the NICK command. This is definitely along the lines we were thinking simple-chats would work as well, namely that the MSRP NICKNAME method (or the equivalent SIP mechanism) would get challenged for Digest authentication. I think it is very important for us to define something that is easy to implement and deploy without restricting more elaborate models being deployed. Cheers, Aki -- Aki Niemi _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 08 11:34: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 1HlRhi-0004vK-T0; Tue, 08 May 2007 11:34:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlRhh-0004vF-NF for simple@ietf.org; Tue, 08 May 2007 11:34:17 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlRhh-0001XT-D2 for simple@ietf.org; Tue, 08 May 2007 11:34:17 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 08 May 2007 11:34:17 -0400 X-IronPort-AV: i="4.14,506,1170651600"; d="scan'208"; a="59691988:sNHT47964474" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l48FYHKP024441; Tue, 8 May 2007 11:34:17 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l48FXglm008849; Tue, 8 May 2007 15:34:17 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 11:34:16 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 11:34:15 -0400 Message-ID: <46409876.4030307@cisco.com> Date: Tue, 08 May 2007 11:34:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> In-Reply-To: <46407C8A.6030000@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 May 2007 15:34:15.0723 (UTC) FILETIME=[55F6C7B0:01C79186] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4136; t=1178638457; x=1179502457; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20MSRP=20chat=3A=20SIP-based=20nickname=20ne gotiation |Sender:=20 |To:=20Miguel=20Garcia=20; bh=Hqkw4jKZnexpjUhXn0K12n3KGvrxFoExwKt2oy+ObFw=; b=RAjD4ihOVXhPQYeDoDwBSJDOVyFDoUzUAzQ+y+xKGQC5qZD6EJ7hNisQme3ZSOcvH3AxYI7s ltMeE/ayJNxdvlIUYmmhQoGRNXyDmCQHps+r+i3L18GunDvDxsGjLZEA; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: SIMPLE mailing list , Niemi Aki Petteri X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Miguel Garcia wrote: > Aren't you assuming that if a user is willing to use nicknames at the > same time wants to remain anonymous from his SIP URI? > > I thought these are two independent issues. I may want to reveal or hide > my SIP URI, and I may want to reveal or hide my nickname. I guess the question is how many distinct models and mechanisms it makes sense to standardize. We already have Display Name as an uncontrolled way to provide an alias for yourself in addition to your actual URI. If you are willing to expose your actual URI, and there is no requirement for uniqueness of nickname, then this is enough. If you really want your identity hidden and only your nickname to be exposed, then the nickname must be unique and routable. What I have suggested satisfies that, and works for any conference server, in fact for any call. Is some mechanism between those two extremes worth the trouble, especially if it is limited to chat conferences based on MSRP? I may well participate in regular voice conferences using a conference server that provides access to a roster. I think I would want nicknames for that too. Do we provide another unique mechanism for that environment? Paul > /Miguel > > Paul Kyzivat wrote: >> Miguel, >> >> IMO the most straightforward way to handle nicknames is to treat them >> as a form of anonymization, provided by an anonymizer. Namely, you >> establish a nickname server, which is a form of B2BUA. You establish >> an account with it that defines a mapping between your actual AOR and >> the nickname you want to be known by, drawn from the address space of >> the server. Then you relay your request for the chat room (or >> whatever) through this server. >> >> This can be a server entirely independent of the chat room. But it >> would also be fine for the provider of a chat room server to couple a >> nickname service with it, perhaps coupling the mapping of real name to >> nickname to the lifetime of a particular chat room. >> >> Paul >> >> Miguel Garcia wrote: >>> Hi: >>> >>> We are trying to seek consensus and a bit more of discussion about >>> the MSRP chat, to be precise, about the nickname capability, which is >>> the most contentious issue so far. We don't discuss in this e-mail >>> other issues, just nicknames. >>> >>> According to the minutes of the meeting in Prague, we understood that >>> we should be seeking a nickname negotiation mechanism outside MSRP. >>> For example, SIP. For what I recall from conversations years ago, the >>> mechanism should be also applicable to regular sessions, not only >>> those that contain MSRP or not only conferences. >>> >>> So, based on that, we would like to get comments on the following >>> proposal: >>> >>> - Model the nickname capability in SIP as a option tag in >>> Supported/Require headers >>> * Whether to have Require in outgoing INVITEs is open >>> >>> - New header field "Set-Nickname" or something is added to the INVITE >>> request. >>> >>> - Value of the Set-Nickname header field: >>> Option 1) Either the header takes a single token value >>> * URN scheme that embeds this token, and later goes into CPIM >>> TO/From >>> * Other option (maybe better) is to still use a naming >>> convention and SIP URIs. >>> >>> Option 2) Another option is to have UA insert a Display-Name and SIP URI >>> * The SIP URI represents the nickname and it is scoped to the >>> chatroom or domain >>> * The Display-Name is used for rendering purposes. >>> * This is what the current draft says >>> >>> - We create a new error response code 4xx: Nickname Not Accepted >>> * Optional Proposed-Nicknames header field proposing alternatives >>> >>> >>> >>> And before Keith jumps above me indicating that this work should be >>> done in the SIP working group, yes, we are aware of RFC 3427, and >>> this work, if agreed in SIMPLE, should move to SIP as some point in >>> time. But let's see if SIMPLE agrees first. >>> >>> BR, >>> >>> Miguel > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 08 12:01:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlS7f-0004U9-F4; Tue, 08 May 2007 12:01:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlS7d-0004TD-HU for simple@ietf.org; Tue, 08 May 2007 12:01:05 -0400 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlS7b-0007IJ-Vq for simple@ietf.org; Tue, 08 May 2007 12:01:05 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 0E777498005; Tue, 8 May 2007 17:01:03 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26078-07; Tue, 8 May 2007 17:00:56 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id A22E9498002; Tue, 8 May 2007 17:00:56 +0100 (BST) Subject: Re: [Simple] Why LDAP... References: <001301c79132$e177b6e0$a504120a@china.huawei.com> In-Reply-To: <001301c79132$e177b6e0$a504120a@china.huawei.com> MIME-Version: 1.0 Message-Id: <18552.1178640056.644506@peirce.dave.cridland.net> Date: Tue, 08 May 2007 17:00:56 +0100 From: Dave Cridland To: sreekanth Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: SIP for Instant Messaging and Presence Leveraging Extensions 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 May 8 06:36:51 2007, sreekanth wrote: > Why LDAP or ACAP cannot be used instead of XCAP?? > > LDAP lacks some details of a configuration protocol that are thought to be, or were thought to be, useful. In particular: 1) It is geared toward data strongly bound to a schema, thought to be bad because clients generally have unique features, which in turn require schema support and maintenance. 2) It lacks "push" of change data, thought to be important to reduce the change lag of long-running clients (such as messaging clients and VOIP applications). 3) It lacks the more useful horizontal attribute inheritance, providing only vertical attribute inheritance (which in itself is little used, partly because it's not used as a configuration service). This is thought to be useful for site-wide configuration defaults. ACAP does provide these (and misses out several key features of a directory, too - it's not that ACAP is better than LDAP, it's just better suited for this purpose). XCAP doesn't provide any of them directly either, but instead supplies (2) by integrating the service with SIP, thus really providing a configuration bootstrap, rather than a full service. Apparently, though, XCAP is still thought to be suitable for use as a configuration service. > -The following is from the XCAP presentation prepared by Rosenberg.. > LDAP, ACAP, SNMP, relational DB cover related spaces, none > successfully deployed to broad end client bases > ACAP has seen comparitively low deployment, although multiple clients and servers do actually exist, and are used in production deployments. LDAP, SNMP, and relational databases have all seen very high deployment, but are not as well suited to configuration and roaming data storage. Some deployment exists of LDAP as an internet-accessible roaming data/configuration protocol, whereas RDBMs are often used for site-wide configuration and data roaming. While deployment levels of any of these are undoubtedly low compared to the levels of deployment of the protocols they support, it's certainly not true that they're zero, nor that the existing deployments are unsuccessful. > Can anyone clarify on this??? I can't speak for Rosenberg, and of course any debate is pointless now, but I hope I've shed some light on this. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 09 02:37:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlfnp-00048P-3e; Wed, 09 May 2007 02:37:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlfnn-00048H-S2 for simple@ietf.org; Wed, 09 May 2007 02:37:31 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlfnl-0004Va-55 for simple@ietf.org; Wed, 09 May 2007 02:37:31 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l496bFJb017646; Wed, 9 May 2007 09:37:25 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 09:36:48 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 09:36:47 +0300 Received: from [172.21.59.37] ([172.21.59.37]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 09:36:47 +0300 Message-ID: <46416BFF.5090105@nsn.com> Date: Wed, 09 May 2007 09:36:47 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> In-Reply-To: <46409876.4030307@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2007 06:36:47.0835 (UTC) FILETIME=[6B2352B0:01C79204] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: SIMPLE mailing list , Niemi Aki Petteri 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 Inline discussion Paul Kyzivat wrote: > > > Miguel Garcia wrote: >> Aren't you assuming that if a user is willing to use nicknames at the >> same time wants to remain anonymous from his SIP URI? >> >> I thought these are two independent issues. I may want to reveal or >> hide my SIP URI, and I may want to reveal or hide my nickname. > > I guess the question is how many distinct models and mechanisms it makes > sense to standardize. > > We already have Display Name as an uncontrolled way to provide an alias > for yourself in addition to your actual URI. If you are willing to > expose your actual URI, and there is no requirement for uniqueness of > nickname, then this is enough. Well, this is the heart of the problem. The nickname has to be unique at least within a conference, otherwise I would find the same nickname repeated a number of times. I wouldn't be able to identify which one is the "beer lover" I was chatting a few minutes ago. On the other hand, this is how most (if not all) the chat servers work today. The nickname is unique within the chat room. This requires a centralized repository for the nickname and a reservation mechanism, that is what we are trying to achieve. Since we want to use nicknames for routing private messages via the chat server, then we concluded that the nickname has a display-name (what the user sees in his display) and a URI (what the protocol uses for routing). Whether one is derived from the other via some rules, or there is a composition, then it is up to discussion. We are not there yet. > > If you really want your identity hidden and only your nickname to be > exposed, then the nickname must be unique and routable. What I have > suggested satisfies that, and works for any conference server, in fact > for any call. Yes. But I also want this other scenario where the user discloses his real identity in addition to his nickname. I don't think what you proposed satisfies that requirement. > > Is some mechanism between those two extremes worth the trouble, > especially if it is limited to chat conferences based on MSRP? I think I heard people saying that what we do with nicknames should be generally applicable to non-MSRP conferences as well, although certainly the use case is MSRP. > I may > well participate in regular voice conferences using a conference server > that provides access to a roster. I think I would want nicknames for > that too. Do we provide another unique mechanism for that environment? No, no. The mechanism that we have been suggesting, at the SIP level, will take care of reserving and negotiating a nickname for your non-MSRP conference as well. With respect the roaster. The current version of the draft suggests to extend the conference event package with a new element. It didn't do a formal description, it is more like a place holder for future work. /Miguel > > Paul > >> /Miguel >> >> Paul Kyzivat wrote: >>> Miguel, >>> >>> IMO the most straightforward way to handle nicknames is to treat them >>> as a form of anonymization, provided by an anonymizer. Namely, you >>> establish a nickname server, which is a form of B2BUA. You establish >>> an account with it that defines a mapping between your actual AOR and >>> the nickname you want to be known by, drawn from the address space of >>> the server. Then you relay your request for the chat room (or >>> whatever) through this server. >>> >>> This can be a server entirely independent of the chat room. But it >>> would also be fine for the provider of a chat room server to couple a >>> nickname service with it, perhaps coupling the mapping of real name >>> to nickname to the lifetime of a particular chat room. >>> >>> Paul >>> >>> Miguel Garcia wrote: >>>> Hi: >>>> >>>> We are trying to seek consensus and a bit more of discussion about >>>> the MSRP chat, to be precise, about the nickname capability, which >>>> is the most contentious issue so far. We don't discuss in this >>>> e-mail other issues, just nicknames. >>>> >>>> According to the minutes of the meeting in Prague, we understood >>>> that we should be seeking a nickname negotiation mechanism outside >>>> MSRP. For example, SIP. For what I recall from conversations years >>>> ago, the mechanism should be also applicable to regular sessions, >>>> not only those that contain MSRP or not only conferences. >>>> >>>> So, based on that, we would like to get comments on the following >>>> proposal: >>>> >>>> - Model the nickname capability in SIP as a option tag in >>>> Supported/Require headers >>>> * Whether to have Require in outgoing INVITEs is open >>>> >>>> - New header field "Set-Nickname" or something is added to the >>>> INVITE request. >>>> >>>> - Value of the Set-Nickname header field: >>>> Option 1) Either the header takes a single token value >>>> * URN scheme that embeds this token, and later goes into CPIM >>>> TO/From >>>> * Other option (maybe better) is to still use a naming >>>> convention and SIP URIs. >>>> >>>> Option 2) Another option is to have UA insert a Display-Name and SIP >>>> URI >>>> * The SIP URI represents the nickname and it is scoped to >>>> the chatroom or domain >>>> * The Display-Name is used for rendering purposes. >>>> * This is what the current draft says >>>> >>>> - We create a new error response code 4xx: Nickname Not Accepted >>>> * Optional Proposed-Nicknames header field proposing alternatives >>>> >>>> >>>> >>>> And before Keith jumps above me indicating that this work should be >>>> done in the SIP working group, yes, we are aware of RFC 3427, and >>>> this work, if agreed in SIMPLE, should move to SIP as some point in >>>> time. But let's see if SIMPLE agrees first. >>>> >>>> BR, >>>> >>>> Miguel >> -- Please note my new e-mail address: miguel.garcia at nsn.com Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 09 03:32:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlgf6-00068l-Lq; Wed, 09 May 2007 03:32:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlgf5-00068d-I6 for simple@ietf.org; Wed, 09 May 2007 03:32:35 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlgf4-00088A-Vl for simple@ietf.org; Wed, 09 May 2007 03:32:35 -0400 Received: by py-out-1112.google.com with SMTP id f31so78563pyh for ; Wed, 09 May 2007 00:32: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:content-transfer-encoding:content-disposition:references; b=tmz9Bi7vBh9t6hktmR3MQRQ6XfMATkv5z4veCAuU8RkZIEIcFNa3mxg+d/vPGngP+yVHz8bDDaolwS/b6TXlyCirT1Ob6gRLuLgNNM4xdgZoW6N9E5VZJg3GDkNma0Q6UcU61+Sh88YI1USMbreXr9p+XnoBtwXHpFjrKTzu1xA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Q++EXLcQ5iatDdhTGw0iJFmv3r3T3EjJpIUjXZj/6IOxLdaf6ac2OehZWQrXdPr6nQPhQD3oXKUvc0yUNtmZHW2s0DesRxdc++hbhmF117xTOZPLfz98IDkLr2Z7z64fwMF3oxQHbTtcPdD67qtprHCPPtfTZO7B4hxRpLVHnS8= Received: by 10.64.153.4 with SMTP id a4mr490990qbe.1178695954578; Wed, 09 May 2007 00:32:34 -0700 (PDT) Received: by 10.65.189.5 with HTTP; Wed, 9 May 2007 00:32:34 -0700 (PDT) Message-ID: <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> Date: Wed, 9 May 2007 17:32:34 +1000 From: "Hisham Khartabil" To: "Miguel Garcia" Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation In-Reply-To: <46416BFF.5090105@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: Paul Kyzivat , SIMPLE mailing list , Niemi Aki Petteri 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 09/05/07, Miguel Garcia wrote: > Inline discussion > > Paul Kyzivat wrote: > > > > > > Miguel Garcia wrote: > >> Aren't you assuming that if a user is willing to use nicknames at the > >> same time wants to remain anonymous from his SIP URI? > >> > >> I thought these are two independent issues. I may want to reveal or > >> hide my SIP URI, and I may want to reveal or hide my nickname. > > > > I guess the question is how many distinct models and mechanisms it makes > > sense to standardize. > > > > We already have Display Name as an uncontrolled way to provide an alias > > for yourself in addition to your actual URI. If you are willing to > > expose your actual URI, and there is no requirement for uniqueness of > > nickname, then this is enough. > > > Well, this is the heart of the problem. The nickname has to be unique at > least within a conference, otherwise I would find the same nickname > repeated a number of times. I wouldn't be able to identify which one is > the "beer lover" I was chatting a few minutes ago. > > On the other hand, this is how most (if not all) the chat servers work > today. The nickname is unique within the chat room. This requires a > centralized repository for the nickname and a reservation mechanism, > that is what we are trying to achieve. > > Since we want to use nicknames for routing private messages via the chat > server, then we concluded that the nickname has a display-name (what the > user sees in his display) and a URI (what the protocol uses for > routing). Whether one is derived from the other via some rules, or there > is a composition, then it is up to discussion. We are not there yet. > > > > > > If you really want your identity hidden and only your nickname to be > > exposed, then the nickname must be unique and routable. What I have > > suggested satisfies that, and works for any conference server, in fact > > for any call. > > Yes. But I also want this other scenario where the user discloses his > real identity in addition to his nickname. I don't think what you > proposed satisfies that requirement. what's wrong with a From-header plus P-Preferred-Identity (some similar) header? Hisham > > > > > Is some mechanism between those two extremes worth the trouble, > > especially if it is limited to chat conferences based on MSRP? > > I think I heard people saying that what we do with nicknames should be > generally applicable to non-MSRP conferences as well, although certainly > the use case is MSRP. > > > I may > > well participate in regular voice conferences using a conference server > > that provides access to a roster. I think I would want nicknames for > > that too. Do we provide another unique mechanism for that environment? > > No, no. The mechanism that we have been suggesting, at the SIP level, > will take care of reserving and negotiating a nickname for your non-MSRP > conference as well. > > With respect the roaster. The current version of the draft suggests to > extend the conference event package with a new element. It > didn't do a formal description, it is more like a place holder for > future work. > > /Miguel > > > > > > > > Paul > > > >> /Miguel > >> > >> Paul Kyzivat wrote: > >>> Miguel, > >>> > >>> IMO the most straightforward way to handle nicknames is to treat them > >>> as a form of anonymization, provided by an anonymizer. Namely, you > >>> establish a nickname server, which is a form of B2BUA. You establish > >>> an account with it that defines a mapping between your actual AOR and > >>> the nickname you want to be known by, drawn from the address space of > >>> the server. Then you relay your request for the chat room (or > >>> whatever) through this server. > >>> > >>> This can be a server entirely independent of the chat room. But it > >>> would also be fine for the provider of a chat room server to couple a > >>> nickname service with it, perhaps coupling the mapping of real name > >>> to nickname to the lifetime of a particular chat room. > >>> > >>> Paul > >>> > >>> Miguel Garcia wrote: > >>>> Hi: > >>>> > >>>> We are trying to seek consensus and a bit more of discussion about > >>>> the MSRP chat, to be precise, about the nickname capability, which > >>>> is the most contentious issue so far. We don't discuss in this > >>>> e-mail other issues, just nicknames. > >>>> > >>>> According to the minutes of the meeting in Prague, we understood > >>>> that we should be seeking a nickname negotiation mechanism outside > >>>> MSRP. For example, SIP. For what I recall from conversations years > >>>> ago, the mechanism should be also applicable to regular sessions, > >>>> not only those that contain MSRP or not only conferences. > >>>> > >>>> So, based on that, we would like to get comments on the following > >>>> proposal: > >>>> > >>>> - Model the nickname capability in SIP as a option tag in > >>>> Supported/Require headers > >>>> * Whether to have Require in outgoing INVITEs is open > >>>> > >>>> - New header field "Set-Nickname" or something is added to the > >>>> INVITE request. > >>>> > >>>> - Value of the Set-Nickname header field: > >>>> Option 1) Either the header takes a single token value > >>>> * URN scheme that embeds this token, and later goes into CPIM > >>>> TO/From > >>>> * Other option (maybe better) is to still use a naming > >>>> convention and SIP URIs. > >>>> > >>>> Option 2) Another option is to have UA insert a Display-Name and SIP > >>>> URI > >>>> * The SIP URI represents the nickname and it is scoped to > >>>> the chatroom or domain > >>>> * The Display-Name is used for rendering purposes. > >>>> * This is what the current draft says > >>>> > >>>> - We create a new error response code 4xx: Nickname Not Accepted > >>>> * Optional Proposed-Nicknames header field proposing alternatives > >>>> > >>>> > >>>> > >>>> And before Keith jumps above me indicating that this work should be > >>>> done in the SIP working group, yes, we are aware of RFC 3427, and > >>>> this work, if agreed in SIMPLE, should move to SIP as some point in > >>>> time. But let's see if SIMPLE agrees first. > >>>> > >>>> BR, > >>>> > >>>> Miguel > >> > > -- > Please note my new e-mail address: miguel.garcia at nsn.com > Miguel A. Garcia tel:+358-50-4804586 > Nokia Siemens Networks Helsinki, Finland > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 09 03:39: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 1Hlgla-0002Ik-QO; Wed, 09 May 2007 03:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlglZ-0002Ib-5F for simple@ietf.org; Wed, 09 May 2007 03:39:17 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlglX-0000QX-MF for simple@ietf.org; Wed, 09 May 2007 03:39:17 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l497d4SZ027269; Wed, 9 May 2007 10:39:10 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 10:39:07 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 10:39:06 +0300 Received: from [172.21.59.37] ([172.21.59.37]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 10:39:06 +0300 Message-ID: <46417A9A.9030703@nsn.com> Date: Wed, 09 May 2007 10:39:06 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> In-Reply-To: <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2007 07:39:06.0678 (UTC) FILETIME=[1FA97D60:01C7920D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Paul Kyzivat , SIMPLE mailing list , Niemi Aki Petteri 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 Hisham Khartabil wrote: > > what's wrong with a From-header plus P-Preferred-Identity (some similar) > header? > The P-Preferred-Identity/P-Asserted-Identity combination do not work in the Internet at large due to lack of trust. So, in general, it is not available. On the other hand, I wouldn't like to hijack an existing header with existing semantics for adding a nickname. I think the results are mostly unpredictable in existing software. /Miguel -- Please note my new e-mail address: miguel.garcia at nsn.com Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 09 03:48: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 1HlguN-0008FX-IP; Wed, 09 May 2007 03:48:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlguM-0008By-7W for simple@ietf.org; Wed, 09 May 2007 03:48:22 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlguL-000250-0k for simple@ietf.org; Wed, 09 May 2007 03:48:22 -0400 Received: by py-out-1112.google.com with SMTP id f31so81161pyh for ; Wed, 09 May 2007 00:48:20 -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:content-transfer-encoding:content-disposition:references; b=pJFGIubkhSXHfwiE6AbOZECDRJLgtjGU5QC1z6kdTn+iZY5bG+ihAEDzbTtyK8/MS1uecfSoQ6A0uBEk2/YmTywHA/iFM/e21V3Um6JHTFThKk9nTGuSgKpdvz67yfojXM0cBqUGLPZ4n1zb9sbWBEkKBcV6nwsjDbgjYAZhYqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=a89x0WUuEI34KwQx/rH/7/HZPTihVZkFxfT7Y7yQoYaDVD3hCXglfyKwGKwSU4IDtcAdv2NwnDfezkUcFmARAuyzvvuMB0vMpQo1bGrxS3OAIAfqY7EP2JRon2EoLLcKages+w9nfpokn0q2fPiV8Kwrc1W5v/Y7gOYcSh0Npww= Received: by 10.64.242.5 with SMTP id p5mr499305qbh.1178696900322; Wed, 09 May 2007 00:48:20 -0700 (PDT) Received: by 10.65.189.5 with HTTP; Wed, 9 May 2007 00:48:20 -0700 (PDT) Message-ID: <66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com> Date: Wed, 9 May 2007 17:48:20 +1000 From: "Hisham Khartabil" To: "Miguel Garcia" Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation In-Reply-To: <46417A9A.9030703@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Paul Kyzivat , SIMPLE mailing list , Niemi Aki Petteri 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 was suggesting something similar to the p-preferred-identity header. i.e. a header that carries a name that the user prefers. Hisham On 09/05/07, Miguel Garcia wrote: > Hisham Khartabil wrote: > > > > what's wrong with a From-header plus P-Preferred-Identity (some similar) > > header? > > > > > > The P-Preferred-Identity/P-Asserted-Identity combination do not work > in the Internet at large due to lack of trust. So, in general, it is > not available. > > On the other hand, I wouldn't like to hijack an existing header with > existing semantics for adding a nickname. I think the results are mostly > unpredictable in existing software. > > /Miguel > > -- > Please note my new e-mail address: miguel.garcia at nsn.com > Miguel A. Garcia tel:+358-50-4804586 > Nokia Siemens Networks Helsinki, Finland > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 09 03:53:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlgzC-0001jH-KH; Wed, 09 May 2007 03:53:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlgzB-0001in-C8 for simple@ietf.org; Wed, 09 May 2007 03:53:21 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlgz9-00038p-Fz for simple@ietf.org; Wed, 09 May 2007 03:53:21 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l497qwxS007510; Wed, 9 May 2007 10:53:15 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 10:52:59 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 10:52:59 +0300 Received: from [172.21.59.37] ([172.21.59.37]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 10:52:59 +0300 Message-ID: <46417DDA.9090000@nsn.com> Date: Wed, 09 May 2007 10:52:58 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com> <66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com> In-Reply-To: <66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2007 07:52:59.0261 (UTC) FILETIME=[0FEB92D0:01C7920F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Paul Kyzivat , SIMPLE mailing list , Niemi Aki Petteri 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 So you mean something like the header where the user will indicate his preferred nickname? Well, yes, this is what the proposal says: - New header field "Set-Nickname" or something is added to the INVITE request. /Miguel Hisham Khartabil wrote: > I was suggesting something similar to the p-preferred-identity header. > i.e. a header that carries a name that the user prefers. > > Hisham > > On 09/05/07, Miguel Garcia wrote: >> Hisham Khartabil wrote: >> > >> > what's wrong with a From-header plus P-Preferred-Identity (some >> similar) >> > header? >> > >> >> >> >> The P-Preferred-Identity/P-Asserted-Identity combination do not work >> in the Internet at large due to lack of trust. So, in general, it is >> not available. >> >> On the other hand, I wouldn't like to hijack an existing header with >> existing semantics for adding a nickname. I think the results are mostly >> unpredictable in existing software. >> >> /Miguel >> >> -- >> Please note my new e-mail address: miguel.garcia at nsn.com >> Miguel A. Garcia tel:+358-50-4804586 >> Nokia Siemens Networks Helsinki, Finland >> >> -- Please note my new e-mail address: miguel.garcia at nsn.com Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 09 07:54:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlkk9-000797-8p; Wed, 09 May 2007 07:54:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlkk7-000792-VZ for simple@ietf.org; Wed, 09 May 2007 07:54:03 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlkk6-0004Um-NB for simple@ietf.org; Wed, 09 May 2007 07:54:03 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 May 2007 07:54:03 -0400 X-IronPort-AV: i="4.14,509,1170651600"; d="scan'208"; a="120645876:sNHT44999566" 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 l49Bs2h1031967; Wed, 9 May 2007 07:54:02 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l49Bs10Z008481; Wed, 9 May 2007 11:54:01 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 07:54:01 -0400 Received: from [10.86.240.70] ([10.86.240.70]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 07:54:01 -0400 Message-ID: <4641B657.2010405@cisco.com> Date: Wed, 09 May 2007 07:53:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com> <66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com> <46417DDA.9090000@nsn.com> In-Reply-To: <46417DDA.9090000@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2007 11:54:01.0179 (UTC) FILETIME=[BBE522B0:01C79230] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1746; t=1178711642; x=1179575642; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20MSRP=20chat=3A=20SIP-based=20nickname=20ne gotiation |Sender:=20 |To:=20Miguel=20Garcia=20; bh=uNUsDP7uAaD16N87gmwHKMrJqK6jtdhIPAiWkVVNZlg=; b=S9BJQEXASkHI2rc2Y6uDnMCveTYq5TT8aJayQgcsFFg0JxX9Dm5lEA9NqF24SR5XoX4RJfGf uLNdOzKQy4PSOb4x3YNJg8wA2yLPqi3c0IfnSykh0NltsfySpECy6USh; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Niemi Aki Petteri , SIMPLE mailing list 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 was thinking of something similar to what Hisham is suggesting, but it is different from what you are suggesting Miguel. In particular: If I want to be known by a nickname within the conference, then I use an anonymizer to source my session with the identity of a nickname - as I first suggested. If I also want to disclose my *actual* URI to participants of the conference, then I just include that in my request in some subordinate role/header. E.g. Reply-To. Paul Miguel Garcia wrote: > So you mean something like the header where the user will indicate his > preferred nickname? Well, yes, this is what the proposal says: > > - New header field "Set-Nickname" or something is added to the INVITE > request. > > /Miguel > > Hisham Khartabil wrote: >> I was suggesting something similar to the p-preferred-identity header. >> i.e. a header that carries a name that the user prefers. >> >> Hisham >> >> On 09/05/07, Miguel Garcia wrote: >>> Hisham Khartabil wrote: >>> > >>> > what's wrong with a From-header plus P-Preferred-Identity (some >>> similar) >>> > header? >>> > >>> >>> >>> >>> The P-Preferred-Identity/P-Asserted-Identity combination do not work >>> in the Internet at large due to lack of trust. So, in general, it is >>> not available. >>> >>> On the other hand, I wouldn't like to hijack an existing header with >>> existing semantics for adding a nickname. I think the results are mostly >>> unpredictable in existing software. >>> >>> /Miguel >>> >>> -- >>> Please note my new e-mail address: miguel.garcia at nsn.com >>> Miguel A. Garcia tel:+358-50-4804586 >>> Nokia Siemens Networks Helsinki, Finland >>> >>> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 09 19:02:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlvAZ-0001zb-Jn; Wed, 09 May 2007 19:02:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlvAX-0001tp-HJ for simple@ietf.org; Wed, 09 May 2007 19:02:01 -0400 Received: from mail2.telefonica.es ([194.224.58.62] helo=28nbhc10.tesa) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlvAW-0005IE-5b for simple@ietf.org; Wed, 09 May 2007 19:02:01 -0400 From: ignacio.delacruzgallego@telefonica.es To: simple@ietf.org Message-ID: Date: Thu, 10 May 2007 01:01:56 +0200 X-MIMETrack: Serialize by Router on 28NBHC10/SRV/PASARELA_EMAIL(Release 6.5.4FP3|January 09, 2006) at 10/05/2007 01:01:59 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [Simple] =?iso-8859-1?q?Direcci=F3n_de_correo_no_disponible=2E_E?= =?iso-8859-1?q?mail_address_no_loger_available?= 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 Estar=E9 ausente de la oficina desde el 30/03/2007 y no volver=E9 hast= a el 30/03/2009. Hola, Esta direcci=F3n de correo no estar=E1 disponible a partir del d=EDa 30= de Marzo de 2007. Por favor, si se trata de un tema realcionado con Telef=F3nica M=F3vile= s, p=F3ngase en contacto con joseluis.vacascid@telefonica.es. Un saludo, Nacho. ------------------------ Dear Email Sender, This email address will be no longer available from March 30th 2007. Fo= r any Telefo=F3nica M=F3viles related subjects, please contact joseluis.vacascid@telefonica.es. Regards, Nacho _______________________________________________________________________= ____ Este mensaje se dirige exclusivamente a su destinatario y puede contene= r informaci=F3n privilegiada o confidencial. Si no es vd. el destinatario= indicado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3= n y/o copia sin autorizaci=F3n est=E1 prohibida en virtud de la legislaci=F3n= vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. El correo electr=F3nico v=EDa Internet no permite asegurar la confidenc= ialidad de los mensajes que se transmiten ni su integridad o correcta recepci=F3= n. Telef=F3nica no asume ninguna responsabilidad por estas circunstancias.= This message is intended exclusively for its addressee and may contain information that is CONFIDENTIAL and protected by a professional privil= ege or whose disclosure is prohibited by law.If you are not the intended recipient you are hereby notified that any read, dissemination, copy or= disclosure of this communication is strictly prohibited by law. If this= message has been received in error, please immediately notify us via e-= mail and delete it. Internet e-mail neither guarantees the confidentiality nor the integrit= y or proper receipt of the messages sent. Telef=F3nica does not assume any liability for those circumstances. _______________________________________________________________________= ____= _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu May 10 03:12: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 1Hm2nx-0000q9-VR; Thu, 10 May 2007 03:11:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm2nx-0000q4-1d for simple@ietf.org; Thu, 10 May 2007 03:11:13 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm2nw-0000iL-IB for simple@ietf.org; Thu, 10 May 2007 03:11:13 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4A7Am93015139; Thu, 10 May 2007 10:11:07 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 10:11:04 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 10:11:03 +0300 Received: from [172.21.59.30] ([172.21.59.30]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 10:11:04 +0300 Message-ID: <4642C587.9040107@nsn.com> Date: Thu, 10 May 2007 10:11:03 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com> <66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com> <46417DDA.9090000@nsn.com> <4641B657.2010405@cisco.com> In-Reply-To: <4641B657.2010405@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2007 07:11:04.0160 (UTC) FILETIME=[5F375E00:01C792D2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Niemi Aki Petteri , SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi: It has never been the purpose of this work to create a general mechanism for providing anonymity through nicknames. Rather than that, the goal is provide a mechanism that is compatible with existing chat rooms that implement other protocols, namely jabber/XMPP, perhaps IRC. The more we diverge from the current model, the more difficulties we will find. This is imposing us some constraints that we can't forget. One of them is that the nickname provider is an inherent part of the chat room. You can model it as a co-located anonymizer with the chat room. So we are not going to model a separate entity, that will bring other questions. Another constraint is that the nickname is a separate additional identity that resolves to the chat server. A UA that does not understand nicknames, should be able to operate without that notion. In particular, if we stick a nickname in a From header, we are overloading the meaning of it. There might be User Agents that allow, for example, to save in a Contacts application the URI listed in a From header. If that content is a temporarily scoped URI, then we will be braking the compatibility with existing UAs. Now, I have been listening to many opinions on how to do things in different ways, generalize, and so on. But we need to keep focused on solving our particular problem, if we ever want to see MSRP chat deployed. And to do it, we have to provide protocol compatibility with existing deployments. So, I would appreciate if we can focus on the problems of the proposal that we sent earlier for our specific application, rather than providing alternatives. /Miguel Paul Kyzivat wrote: > I was thinking of something similar to what Hisham is suggesting, but it > is different from what you are suggesting Miguel. In particular: > > If I want to be known by a nickname within the conference, then I use an > anonymizer to source my session with the identity of a nickname - as I > first suggested. > > If I also want to disclose my *actual* URI to participants of the > conference, then I just include that in my request in some subordinate > role/header. E.g. Reply-To. > > Paul > > Miguel Garcia wrote: >> So you mean something like the header where the user will indicate his >> preferred nickname? Well, yes, this is what the proposal says: >> >> - New header field "Set-Nickname" or something is added to the INVITE >> request. >> >> /Miguel >> >> Hisham Khartabil wrote: >>> I was suggesting something similar to the p-preferred-identity header. >>> i.e. a header that carries a name that the user prefers. >>> >>> Hisham >>> >>> On 09/05/07, Miguel Garcia wrote: >>>> Hisham Khartabil wrote: >>>> > >>>> > what's wrong with a From-header plus P-Preferred-Identity (some >>>> similar) >>>> > header? >>>> > >>>> >>>> >>>> >>>> The P-Preferred-Identity/P-Asserted-Identity combination do not work >>>> in the Internet at large due to lack of trust. So, in general, it is >>>> not available. >>>> >>>> On the other hand, I wouldn't like to hijack an existing header with >>>> existing semantics for adding a nickname. I think the results are >>>> mostly >>>> unpredictable in existing software. >>>> >>>> /Miguel >>>> >>>> -- >>>> Please note my new e-mail address: miguel.garcia at nsn.com >>>> Miguel A. Garcia tel:+358-50-4804586 >>>> Nokia Siemens Networks Helsinki, Finland >>>> >>>> >> -- Please note my new e-mail address: miguel.garcia at nsn.com Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From iercqzxdisk@iol.cz Sat May 12 18:02:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmzfx-00042V-Kj for simple-archive@lists.ietf.org; Sat, 12 May 2007 18:02:53 -0400 Received: from 86.33.broadband2.iol.cz ([83.208.33.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmzfw-0006kQ-8S for simple-archive@lists.ietf.org; Sat, 12 May 2007 18:02:53 -0400 From: "GB physical" To: simple-archive@lists.ietf.org Subject: Fwd: Thanks for your refinance debt request, we are ready to give a loan Date: Sun, 13 May 2007 00:02:52 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C794F2.0D541840" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceU8g1U+C8ZmH97Q8mKMrkR1wl7sg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <84B40F8610E554C.7E23D7A93E@iol.cz> X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 ------=_NextPart_000_0005_01C794F2.0D541840 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Your credit doesn't matter to us!

If you OWN real estate and want IMMEDIATE pocket money to spend ANY way you like, or simply need to LOWER your payments by a third or more, here is our deal we can offer you THIS NIGHT (hurry, this offer will expire TONIGHT):

$241,000+ loan

AND EVEN MORE: After further review, our lenders have established the lowest monthly payments!

Hurry, when the deal is gone, it is gone. Simply fill out this one-minute form...

Don't worry about approval, your credit history will not disqualify you!

------=_NextPart_000_0005_01C794F2.0D541840-- From simple-bounces@ietf.org Mon May 14 02:42:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnUGN-0005d1-Jw; Mon, 14 May 2007 02:42:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnUGM-0005X7-FT for simple@ietf.org; Mon, 14 May 2007 02:42:30 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnUGM-00074D-1X for simple@ietf.org; Mon, 14 May 2007 02:42:30 -0400 Received: from 80.178.94.165.static.012.net.il ([80.178.94.165] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HnUFC-00082z-Mr; Mon, 14 May 2007 01:41:19 -0500 From: "Brian Rosen" To: "'Miguel Garcia'" , "'Paul Kyzivat'" References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com><66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com><46417DDA.9090000@nsn.com> <4641B657.2010405@cisco.com> <4642C587.9040107@nsn.com> Subject: RE: [Simple] MSRP chat: SIP-based nickname negotiation Date: Mon, 14 May 2007 02:42:21 -0400 Message-ID: <080501c795f3$09614670$e4003c0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4642C587.9040107@nsn.com> Thread-Index: AceS0jQ0uN9m7NeOQxqYQjKetZ4X/QDHuzQA 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: 2ed806e2f53ff1a061ad4f97e00345ac Cc: 'Niemi Aki Petteri' , 'SIMPLE mailing list' 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 think that at root, the problem is that we don't agree on requirements. Perhaps we should start there, rather than discussing a particular proposed solution. I don't think it will take long to agree on requirements. So far, I have heard: It must be possible for a user to request a particular nickname It must be possible for a service (conference server or domain) to require uniqueness of nicknames within the conferenece/domain) It should be possible for a nickname to be retained by a user for a long time It must be possible for a user to reveal their nickname, but not require revealing an AoR Is it a requirement that the nickname "service" do this, or is it Acceptable to get an anonymous AoR and associate a nickname with that, making these two services independent of one another? I think it is. Nicknames are not display names, are not user parts of AoR, and are not other identities (i.e. P-Preferred-Identity); they are something new. Of course, nicks may be the same character sequence as one of the above if the domain, or the user, wants them to be. PERHAPS I have heard: A nickname is an ADDITIONAL identity; not equivalent to an AoR. A nickname is bound to an AoR and used for display purposes, not addressing purposes A nickname service may be separate or may be bound to a conference server/domaim --by domain, I mean the domain of an AoR: AOL maintains a domain of screen names that are persistent and used in all chat rooms and IM conversations. We need to maintain this style of nicknames as well as the temporary, join the chat, pick a nick style. > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > Sent: Thursday, May 10, 2007 3:11 AM > To: Paul Kyzivat > Cc: Niemi Aki Petteri; SIMPLE mailing list > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > > Hi: > > It has never been the purpose of this work to create a general mechanism > for providing anonymity through nicknames. Rather than that, the goal is > provide a mechanism that is compatible with existing chat rooms that > implement other protocols, namely jabber/XMPP, perhaps IRC. The more we > diverge from the current model, the more difficulties we will find. > > This is imposing us some constraints that we can't forget. One of them > is that the nickname provider is an inherent part of the chat room. You > can model it as a co-located anonymizer with the chat room. So we are > not going to model a separate entity, that will bring other questions. > > Another constraint is that the nickname is a separate additional > identity that resolves to the chat server. A UA that does not understand > nicknames, should be able to operate without that notion. In particular, > if we stick a nickname in a From header, we are overloading the meaning > of it. There might be User Agents that allow, for example, to save in a > Contacts application the URI listed in a From header. If that content is > a temporarily scoped URI, then we will be braking the compatibility with > existing UAs. > > Now, I have been listening to many opinions on how to do things in > different ways, generalize, and so on. But we need to keep focused on > solving our particular problem, if we ever want to see MSRP chat > deployed. And to do it, we have to provide protocol compatibility with > existing deployments. So, I would appreciate if we can focus on the > problems of the proposal that we sent earlier for our specific > application, rather than providing alternatives. > > /Miguel > > > Paul Kyzivat wrote: > > I was thinking of something similar to what Hisham is suggesting, but it > > is different from what you are suggesting Miguel. In particular: > > > > If I want to be known by a nickname within the conference, then I use an > > anonymizer to source my session with the identity of a nickname - as I > > first suggested. > > > > If I also want to disclose my *actual* URI to participants of the > > conference, then I just include that in my request in some subordinate > > role/header. E.g. Reply-To. > > > > Paul > > > > Miguel Garcia wrote: > >> So you mean something like the header where the user will indicate his > >> preferred nickname? Well, yes, this is what the proposal says: > >> > >> - New header field "Set-Nickname" or something is added to the INVITE > >> request. > >> > >> /Miguel > >> > >> Hisham Khartabil wrote: > >>> I was suggesting something similar to the p-preferred-identity header. > >>> i.e. a header that carries a name that the user prefers. > >>> > >>> Hisham > >>> > >>> On 09/05/07, Miguel Garcia wrote: > >>>> Hisham Khartabil wrote: > >>>> > > >>>> > what's wrong with a From-header plus P-Preferred-Identity (some > >>>> similar) > >>>> > header? > >>>> > > >>>> > >>>> > >>>> > >>>> The P-Preferred-Identity/P-Asserted-Identity combination do not work > >>>> in the Internet at large due to lack of trust. So, in general, it is > >>>> not available. > >>>> > >>>> On the other hand, I wouldn't like to hijack an existing header with > >>>> existing semantics for adding a nickname. I think the results are > >>>> mostly > >>>> unpredictable in existing software. > >>>> > >>>> /Miguel > >>>> > >>>> -- > >>>> Please note my new e-mail address: miguel.garcia at nsn.com > >>>> Miguel A. Garcia tel:+358-50-4804586 > >>>> Nokia Siemens Networks Helsinki, Finland > >>>> > >>>> > >> > > -- > Please note my new e-mail address: miguel.garcia at nsn.com > Miguel A. Garcia tel:+358-50-4804586 > Nokia Siemens Networks Helsinki, Finland > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon May 14 04:02:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnVVz-00031a-PU; Mon, 14 May 2007 04:02:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnVVx-00031D-RI for simple@ietf.org; Mon, 14 May 2007 04:02:41 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnVVw-0000TR-Fr for simple@ietf.org; Mon, 14 May 2007 04:02:41 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4E82SNf028672; Mon, 14 May 2007 11:02:30 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 11:02:05 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 11:02:05 +0300 Received: from [172.21.59.60] ([172.21.59.60]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 11:02:05 +0300 Message-ID: <4648177C.9020106@nsn.com> Date: Mon, 14 May 2007 11:02:04 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com><66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com><46417DDA.9090000@nsn.com> <4641B657.2010405@cisco.com> <4642C587.9040107@nsn.com> <080501c795f3$09614670$e4003c0a@cis.neustar.com> In-Reply-To: <080501c795f3$09614670$e4003c0a@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 May 2007 08:02:05.0086 (UTC) FILETIME=[29529BE0:01C795FE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: 'Paul Kyzivat' , 'Niemi Aki Petteri' , 'SIMPLE mailing list' 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 Brian: Perhaps you went to the heart of the problem... Anyway, I want to remind you that we wrote a requirements draft about two years ago... At that time, submitted to the XCON WG. This is the draft I am referring to: http://tools.ietf.org/id/draft-garcia-xcon-private-messaging-reqs-01.txt I guess this draft captures most of the requirements, if not all. Perhaps we have more information today, and we can clarify some of the requirements. Now, some inline comments on your proposed requirements. Brian Rosen wrote: > I think that at root, the problem is that we don't agree on requirements. > Perhaps we should start there, rather than discussing a particular proposed > solution. I don't think it will take long to agree on requirements. > > So far, I have heard: > It must be possible for a user to request a particular nickname I agree. > It must be possible for a service (conference server or domain) to require > uniqueness of nicknames within the conferenece/domain) I agree. > It should be possible for a nickname to be retained by a user for a long > time I agree, although the actual mechanism is not within the scope of the draft. > It must be possible for a user to reveal their nickname, but not require > revealing an AoR I want to clarify the requirement. There are two parties that can get the AoR: the conference server and participants. The requirement is to make possible for a user to reveal their nickname to participants but not reveal their AoR to participants. I don't think we have a requirement towards the conference server. > Is it a requirement that the nickname "service" do this, or is it > Acceptable to get an anonymous AoR and associate a nickname with > that, > making these two services independent of one another? I think it > is. > Nicknames are not display names, are not user parts of AoR, and are not > other identities (i.e. P-Preferred-Identity); they are something new. Of > course, nicks may be the same character sequence as one of the above if the > domain, or the user, wants them to be. Correct, perhaps clarifying that "Nicknames are not included in existing display names", because a nickname obviously is (or contains) a display name, which is not to override existing display names. > > PERHAPS I have heard: > A nickname is an ADDITIONAL identity; not equivalent to an AoR. A nickname > is bound to an AoR and used for display purposes, not addressing purposes More or less... I agree with everything, but not with the "not addressing purposes". Nicknames are used for addressing purposes when users send private messages. So, perhaps two clarifications - Nicknames do now a allow end-to-end addressing between users. - Nicknames allow a user to address another one via the conference server > > A nickname service may be separate or may be bound to a conference > server/domaim I think the "seperate" creates a bunch of problems. I think anyone is willing to deploy a generic nickname service. Here, we should focus on solving a real problem, and our real problem is that there are conference servers that provide nickname services. So, we should consider that, for the time being, we assume the nickname service to be a part of a conference service. > > --by domain, I mean the domain of an AoR: AOL maintains a domain of screen > names that are persistent and used in all chat rooms and IM conversations. > We need to maintain this style of nicknames as well as the temporary, join > the chat, pick a nick style. /Miguel > > > > >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >> Sent: Thursday, May 10, 2007 3:11 AM >> To: Paul Kyzivat >> Cc: Niemi Aki Petteri; SIMPLE mailing list >> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation >> >> Hi: >> >> It has never been the purpose of this work to create a general mechanism >> for providing anonymity through nicknames. Rather than that, the goal is >> provide a mechanism that is compatible with existing chat rooms that >> implement other protocols, namely jabber/XMPP, perhaps IRC. The more we >> diverge from the current model, the more difficulties we will find. >> >> This is imposing us some constraints that we can't forget. One of them >> is that the nickname provider is an inherent part of the chat room. You >> can model it as a co-located anonymizer with the chat room. So we are >> not going to model a separate entity, that will bring other questions. >> >> Another constraint is that the nickname is a separate additional >> identity that resolves to the chat server. A UA that does not understand >> nicknames, should be able to operate without that notion. In particular, >> if we stick a nickname in a From header, we are overloading the meaning >> of it. There might be User Agents that allow, for example, to save in a >> Contacts application the URI listed in a From header. If that content is >> a temporarily scoped URI, then we will be braking the compatibility with >> existing UAs. >> >> Now, I have been listening to many opinions on how to do things in >> different ways, generalize, and so on. But we need to keep focused on >> solving our particular problem, if we ever want to see MSRP chat >> deployed. And to do it, we have to provide protocol compatibility with >> existing deployments. So, I would appreciate if we can focus on the >> problems of the proposal that we sent earlier for our specific >> application, rather than providing alternatives. >> >> /Miguel >> >> >> Paul Kyzivat wrote: >>> I was thinking of something similar to what Hisham is suggesting, but it >>> is different from what you are suggesting Miguel. In particular: >>> >>> If I want to be known by a nickname within the conference, then I use an >>> anonymizer to source my session with the identity of a nickname - as I >>> first suggested. >>> >>> If I also want to disclose my *actual* URI to participants of the >>> conference, then I just include that in my request in some subordinate >>> role/header. E.g. Reply-To. >>> >>> Paul >>> >>> Miguel Garcia wrote: >>>> So you mean something like the header where the user will indicate his >>>> preferred nickname? Well, yes, this is what the proposal says: >>>> >>>> - New header field "Set-Nickname" or something is added to the INVITE >>>> request. >>>> >>>> /Miguel >>>> >>>> Hisham Khartabil wrote: >>>>> I was suggesting something similar to the p-preferred-identity header. >>>>> i.e. a header that carries a name that the user prefers. >>>>> >>>>> Hisham >>>>> >>>>> On 09/05/07, Miguel Garcia wrote: >>>>>> Hisham Khartabil wrote: >>>>>>> what's wrong with a From-header plus P-Preferred-Identity (some >>>>>> similar) >>>>>>> header? >>>>>>> >>>>>> >>>>>> >>>>>> The P-Preferred-Identity/P-Asserted-Identity combination do not work >>>>>> in the Internet at large due to lack of trust. So, in general, it is >>>>>> not available. >>>>>> >>>>>> On the other hand, I wouldn't like to hijack an existing header with >>>>>> existing semantics for adding a nickname. I think the results are >>>>>> mostly >>>>>> unpredictable in existing software. >>>>>> >>>>>> /Miguel >>>>>> >>>>>> -- >>>>>> Please note my new e-mail address: miguel.garcia at nsn.com >>>>>> Miguel A. Garcia tel:+358-50-4804586 >>>>>> Nokia Siemens Networks Helsinki, Finland >>>>>> >>>>>> >> -- >> Please note my new e-mail address: miguel.garcia at nsn.com >> Miguel A. Garcia tel:+358-50-4804586 >> Nokia Siemens Networks Helsinki, Finland >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > -- Please note my new e-mail address: miguel.garcia at nsn.com Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon May 14 08:04:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZHt-0003Sc-Lj; Mon, 14 May 2007 08:04:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZHt-0003SX-1k for simple@ietf.org; Mon, 14 May 2007 08:04:25 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnZHs-00009W-Ji for simple@ietf.org; Mon, 14 May 2007 08:04:25 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 May 2007 08:04:25 -0400 X-IronPort-AV: i="4.14,531,1170651600"; d="scan'208"; a="121028829:sNHT55621280" 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 l4EC4Ovn021527; Mon, 14 May 2007 08:04:24 -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 l4EC4JBe005496; Mon, 14 May 2007 12:04:19 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 08:04:15 -0400 Received: from [10.86.242.112] ([10.86.242.112]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 08:04:14 -0400 Message-ID: <4648503E.8040100@cisco.com> Date: Mon, 14 May 2007 08:04:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com><66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com><46417DDA.9090000@nsn.com> <4641B657.2010405@cisco.com> <4642C587.9040107@nsn.com> <080501c795f3$09614670$e4003c0a@cis.neustar.com> In-Reply-To: <080501c795f3$09614670$e4003c0a@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 May 2007 12:04:14.0884 (UTC) FILETIME=[FDC1D640:01C7961F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6992; t=1179144264; x=1180008264; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20MSRP=20chat=3A=20SIP-based=20nickname=20ne gotiation |Sender:=20 |To:=20Brian=20Rosen=20; bh=eelxxh3fyvjuZ9JNohRtSOyy1aSFq1jMJWkTn71S9P0=; b=qTz9SdyN3Pu5xq7UUaHzj0tzslpMTjGddYt8dGFXO6HWPA3SlVqKsHlt4MieyYkkSd2mGvRm u7LftOyMoWHVCmnGTEJqUbh3cUXRyCzyr7YFOjzzLFDwG+lIy3/joGJL; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: 'Miguel Garcia' , 'Niemi Aki Petteri' , 'SIMPLE mailing list' 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, Thanks. You make a good observation. And I agree with most of your points. Minor comments below. Paul Brian Rosen wrote: > I think that at root, the problem is that we don't agree on requirements. > Perhaps we should start there, rather than discussing a particular proposed > solution. I don't think it will take long to agree on requirements. > > So far, I have heard: > It must be possible for a user to request a particular nickname > It must be possible for a service (conference server or domain) to require > uniqueness of nicknames within the conferenece/domain) > It should be possible for a nickname to be retained by a user for a long > time > It must be possible for a user to reveal their nickname, but not require > revealing an AoR > Is it a requirement that the nickname "service" do this, or is it > Acceptable to get an anonymous AoR and associate a nickname with > that, > making these two services independent of one another? I think it > is. IMO it probably *should* be acceptable for these to be independent services. What I think is not clear is if/why it should be a requirement for these services to be combined. I think I hear an assertion that it must be possible for them to be combined because some existing chat conference facilities do it that way. I don't know why that is pertinent unless it is for the building of gateways. But even then I think the requirement is for the building of gateways, because perhaps that would be possible without the full requirement. > Nicknames are not display names, are not user parts of AoR, and are not > other identities (i.e. P-Preferred-Identity); they are something new. Of > course, nicks may be the same character sequence as one of the above if the > domain, or the user, wants them to be. > > PERHAPS I have heard: > A nickname is an ADDITIONAL identity; not equivalent to an AoR. A nickname > is bound to an AoR and used for display purposes, not addressing purposes > > A nickname service may be separate or may be bound to a conference > server/domaim > > --by domain, I mean the domain of an AoR: AOL maintains a domain of screen > names that are persistent and used in all chat rooms and IM conversations. > We need to maintain this style of nicknames as well as the temporary, join > the chat, pick a nick style. This seems to be a real requirement. I question if the converse is really a requirement - that nicknames per-conference when there are multiple conferences in the domain - is actually a requirement. I don't recall seeing any practical cases where that is true. Even if it is, it seems ill advised as it can be very deceptive. Paul >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >> Sent: Thursday, May 10, 2007 3:11 AM >> To: Paul Kyzivat >> Cc: Niemi Aki Petteri; SIMPLE mailing list >> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation >> >> Hi: >> >> It has never been the purpose of this work to create a general mechanism >> for providing anonymity through nicknames. Rather than that, the goal is >> provide a mechanism that is compatible with existing chat rooms that >> implement other protocols, namely jabber/XMPP, perhaps IRC. The more we >> diverge from the current model, the more difficulties we will find. >> >> This is imposing us some constraints that we can't forget. One of them >> is that the nickname provider is an inherent part of the chat room. You >> can model it as a co-located anonymizer with the chat room. So we are >> not going to model a separate entity, that will bring other questions. >> >> Another constraint is that the nickname is a separate additional >> identity that resolves to the chat server. A UA that does not understand >> nicknames, should be able to operate without that notion. In particular, >> if we stick a nickname in a From header, we are overloading the meaning >> of it. There might be User Agents that allow, for example, to save in a >> Contacts application the URI listed in a From header. If that content is >> a temporarily scoped URI, then we will be braking the compatibility with >> existing UAs. >> >> Now, I have been listening to many opinions on how to do things in >> different ways, generalize, and so on. But we need to keep focused on >> solving our particular problem, if we ever want to see MSRP chat >> deployed. And to do it, we have to provide protocol compatibility with >> existing deployments. So, I would appreciate if we can focus on the >> problems of the proposal that we sent earlier for our specific >> application, rather than providing alternatives. >> >> /Miguel >> >> >> Paul Kyzivat wrote: >>> I was thinking of something similar to what Hisham is suggesting, but it >>> is different from what you are suggesting Miguel. In particular: >>> >>> If I want to be known by a nickname within the conference, then I use an >>> anonymizer to source my session with the identity of a nickname - as I >>> first suggested. >>> >>> If I also want to disclose my *actual* URI to participants of the >>> conference, then I just include that in my request in some subordinate >>> role/header. E.g. Reply-To. >>> >>> Paul >>> >>> Miguel Garcia wrote: >>>> So you mean something like the header where the user will indicate his >>>> preferred nickname? Well, yes, this is what the proposal says: >>>> >>>> - New header field "Set-Nickname" or something is added to the INVITE >>>> request. >>>> >>>> /Miguel >>>> >>>> Hisham Khartabil wrote: >>>>> I was suggesting something similar to the p-preferred-identity header. >>>>> i.e. a header that carries a name that the user prefers. >>>>> >>>>> Hisham >>>>> >>>>> On 09/05/07, Miguel Garcia wrote: >>>>>> Hisham Khartabil wrote: >>>>>>> what's wrong with a From-header plus P-Preferred-Identity (some >>>>>> similar) >>>>>>> header? >>>>>>> >>>>>> >>>>>> >>>>>> The P-Preferred-Identity/P-Asserted-Identity combination do not work >>>>>> in the Internet at large due to lack of trust. So, in general, it is >>>>>> not available. >>>>>> >>>>>> On the other hand, I wouldn't like to hijack an existing header with >>>>>> existing semantics for adding a nickname. I think the results are >>>>>> mostly >>>>>> unpredictable in existing software. >>>>>> >>>>>> /Miguel >>>>>> >>>>>> -- >>>>>> Please note my new e-mail address: miguel.garcia at nsn.com >>>>>> Miguel A. Garcia tel:+358-50-4804586 >>>>>> Nokia Siemens Networks Helsinki, Finland >>>>>> >>>>>> >> -- >> Please note my new e-mail address: miguel.garcia at nsn.com >> Miguel A. Garcia tel:+358-50-4804586 >> Nokia Siemens Networks Helsinki, Finland >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon May 14 08:15: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 1HnZSR-0001eD-DG; Mon, 14 May 2007 08:15:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZSP-0001ct-T6 for simple@ietf.org; Mon, 14 May 2007 08:15:17 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnZSP-0002h4-D6 for simple@ietf.org; Mon, 14 May 2007 08:15:17 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 May 2007 08:15:17 -0400 X-IronPort-AV: i="4.14,531,1170651600"; d="scan'208"; a="60156718:sNHT61305840" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4ECFHVn021046; Mon, 14 May 2007 08:15:17 -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 l4ECFBBe007384; Mon, 14 May 2007 12:15:11 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 08:15:00 -0400 Received: from [10.86.242.112] ([10.86.242.112]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 08:14:59 -0400 Message-ID: <464852C3.1030200@cisco.com> Date: Mon, 14 May 2007 08:14:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com><66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com><46417DDA.9090000@nsn.com> <4641B657.2010405@cisco.com> <4642C587.9040107@nsn.com> <080501c795f3$09614670$e4003c0a@cis.neustar.com> <4648177C.9020106@nsn.com> In-Reply-To: <4648177C.9020106@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 May 2007 12:14:59.0661 (UTC) FILETIME=[7E12FFD0:01C79621] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9414; t=1179144917; x=1180008917; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20MSRP=20chat=3A=20SIP-based=20nickname=20ne gotiation |Sender:=20 |To:=20Miguel=20Garcia=20; bh=13dQdPvqXZcJqvspW7ZNEs48J+v0+KaA+TskDCmttBQ=; b=bjibIJsYsQVNfgQ3SjzDzCWro9waG4d5bB/k9qidxYVkTCo29m6Cy/t0l43lKOZguYCIcatu 11t0jXG8uWDgUQjnhlqVP+SjofTW5VKYDjq8oLul6gb/Y57zT8ltgjzh; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: 'SIMPLE mailing list' , 'Niemi Aki Petteri' 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 mostly replied earlier. Minor comments below. Paul Miguel Garcia wrote: > Hi Brian: > > Perhaps you went to the heart of the problem... Anyway, I want to remind > you that we wrote a requirements draft about two years ago... At that > time, submitted to the XCON WG. This is the draft I am referring to: > > http://tools.ietf.org/id/draft-garcia-xcon-private-messaging-reqs-01.txt > > I guess this draft captures most of the requirements, if not all. > Perhaps we have more information today, and we can clarify some of the > requirements. > > Now, some inline comments on your proposed requirements. > > Brian Rosen wrote: >> I think that at root, the problem is that we don't agree on requirements. >> Perhaps we should start there, rather than discussing a particular >> proposed >> solution. I don't think it will take long to agree on requirements. >> >> So far, I have heard: >> It must be possible for a user to request a particular nickname > > I agree. > >> It must be possible for a service (conference server or domain) to >> require >> uniqueness of nicknames within the conferenece/domain) > > I agree. > >> It should be possible for a nickname to be retained by a user for a long >> time > > I agree, although the actual mechanism is not within the scope of the > draft. > >> It must be possible for a user to reveal their nickname, but not require >> revealing an AoR > > I want to clarify the requirement. There are two parties that can get > the AoR: the conference server and participants. > > The requirement is to make possible for a user to reveal their nickname > to participants but not reveal their AoR to participants. > > I don't think we have a requirement towards the conference server. > >> Is it a requirement that the nickname "service" do this, or is it >> Acceptable to get an anonymous AoR and associate a nickname with >> that, >> making these two services independent of one another? I think it >> is. > > > >> Nicknames are not display names, are not user parts of AoR, and are not >> other identities (i.e. P-Preferred-Identity); they are something new. Of >> course, nicks may be the same character sequence as one of the above >> if the >> domain, or the user, wants them to be. > > Correct, perhaps clarifying that "Nicknames are not included in existing > display names", because a nickname obviously is (or contains) a display > name, which is not to override existing display names. Is there really a requirement that a participant in a conference be able to have *two* nicknames - one for the AOR and one for the nickname? I question this. >> PERHAPS I have heard: >> A nickname is an ADDITIONAL identity; not equivalent to an AoR. A >> nickname >> is bound to an AoR and used for display purposes, not addressing purposes > > More or less... I agree with everything, but not with the "not > addressing purposes". Nicknames are used for addressing purposes when > users send private messages. > > So, perhaps two clarifications > - Nicknames do now a allow end-to-end addressing between users. > - Nicknames allow a user to address another one via the conference server I think these requirements could stand to have some further clarification about what the intent is. Is the goal to restrict when private messages may be sent? Or to guarantee that the conference server *mediates* all messages sent between participants? Or both? I would distinguish between how this is implemented by existing servers, which may simply be just the best they could manage, and what the actual intent is. >> A nickname service may be separate or may be bound to a conference >> server/domaim > > I think the "seperate" creates a bunch of problems. I think anyone is > willing to deploy a generic nickname service. I presume you mean "anyone is *free* to deploy a generic nickname service." While that is true, it won't matter if a conference server doesn't permit users who are using such a service. In particular, it won't matter if the conference service only permits users whose AOR is hosted by a particular domain. AFAIK that is currently the situation for major providers such as AOL. So then the question is whether we are trying to address those kinds of service providers. > Here, we should focus on > solving a real problem, and our real problem is that there are > conference servers that provide nickname services. So, we should > consider that, for the time being, we assume the nickname service to be > a part of a conference service. > >> >> --by domain, I mean the domain of an AoR: AOL maintains a domain of >> screen >> names that are persistent and used in all chat rooms and IM >> conversations. >> We need to maintain this style of nicknames as well as the temporary, >> join >> the chat, pick a nick style. > > > /Miguel > > >> >> >> >> >>> -----Original Message----- >>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >>> Sent: Thursday, May 10, 2007 3:11 AM >>> To: Paul Kyzivat >>> Cc: Niemi Aki Petteri; SIMPLE mailing list >>> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation >>> >>> Hi: >>> >>> It has never been the purpose of this work to create a general mechanism >>> for providing anonymity through nicknames. Rather than that, the goal is >>> provide a mechanism that is compatible with existing chat rooms that >>> implement other protocols, namely jabber/XMPP, perhaps IRC. The more we >>> diverge from the current model, the more difficulties we will find. >>> >>> This is imposing us some constraints that we can't forget. One of them >>> is that the nickname provider is an inherent part of the chat room. You >>> can model it as a co-located anonymizer with the chat room. So we are >>> not going to model a separate entity, that will bring other questions. >>> >>> Another constraint is that the nickname is a separate additional >>> identity that resolves to the chat server. A UA that does not understand >>> nicknames, should be able to operate without that notion. In particular, >>> if we stick a nickname in a From header, we are overloading the meaning >>> of it. There might be User Agents that allow, for example, to save in a >>> Contacts application the URI listed in a From header. If that content is >>> a temporarily scoped URI, then we will be braking the compatibility with >>> existing UAs. >>> >>> Now, I have been listening to many opinions on how to do things in >>> different ways, generalize, and so on. But we need to keep focused on >>> solving our particular problem, if we ever want to see MSRP chat >>> deployed. And to do it, we have to provide protocol compatibility with >>> existing deployments. So, I would appreciate if we can focus on the >>> problems of the proposal that we sent earlier for our specific >>> application, rather than providing alternatives. >>> >>> /Miguel >>> >>> >>> Paul Kyzivat wrote: >>>> I was thinking of something similar to what Hisham is suggesting, >>>> but it >>>> is different from what you are suggesting Miguel. In particular: >>>> >>>> If I want to be known by a nickname within the conference, then I >>>> use an >>>> anonymizer to source my session with the identity of a nickname - as I >>>> first suggested. >>>> >>>> If I also want to disclose my *actual* URI to participants of the >>>> conference, then I just include that in my request in some subordinate >>>> role/header. E.g. Reply-To. >>>> >>>> Paul >>>> >>>> Miguel Garcia wrote: >>>>> So you mean something like the header where the user will indicate his >>>>> preferred nickname? Well, yes, this is what the proposal says: >>>>> >>>>> - New header field "Set-Nickname" or something is added to the INVITE >>>>> request. >>>>> >>>>> /Miguel >>>>> >>>>> Hisham Khartabil wrote: >>>>>> I was suggesting something similar to the p-preferred-identity >>>>>> header. >>>>>> i.e. a header that carries a name that the user prefers. >>>>>> >>>>>> Hisham >>>>>> >>>>>> On 09/05/07, Miguel Garcia wrote: >>>>>>> Hisham Khartabil wrote: >>>>>>>> what's wrong with a From-header plus P-Preferred-Identity (some >>>>>>> similar) >>>>>>>> header? >>>>>>>> >>>>>>> >>>>>>> >>>>>>> The P-Preferred-Identity/P-Asserted-Identity combination do not work >>>>>>> in the Internet at large due to lack of trust. So, in general, it is >>>>>>> not available. >>>>>>> >>>>>>> On the other hand, I wouldn't like to hijack an existing header with >>>>>>> existing semantics for adding a nickname. I think the results are >>>>>>> mostly >>>>>>> unpredictable in existing software. >>>>>>> >>>>>>> /Miguel >>>>>>> >>>>>>> -- >>>>>>> Please note my new e-mail address: miguel.garcia at nsn.com >>>>>>> Miguel A. Garcia tel:+358-50-4804586 >>>>>>> Nokia Siemens Networks Helsinki, Finland >>>>>>> >>>>>>> >>> -- >>> Please note my new e-mail address: miguel.garcia at nsn.com >>> Miguel A. Garcia tel:+358-50-4804586 >>> Nokia Siemens Networks Helsinki, Finland >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 15 08:07:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnvog-0001Rx-07; Tue, 15 May 2007 08:07:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnvoe-0001Rr-Lv for simple@ietf.org; Tue, 15 May 2007 08:07:44 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnvoe-0004JG-7Y for simple@ietf.org; Tue, 15 May 2007 08:07:44 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4FC7Rdw027882; Tue, 15 May 2007 15:07:31 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 15:07:30 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 15:07:29 +0300 Received: from [172.21.224.135] ([172.21.224.135]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 15:07:29 +0300 Message-ID: <4649A281.2000901@nsn.com> Date: Tue, 15 May 2007 15:07:29 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com><66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com><46417DDA.9090000@nsn.com> <4641B657.2010405@cisco.com> <4642C587.9040107@nsn.com> <080501c795f3$09614670$e4003c0a@cis.neustar.com> <4648177C.9020106@nsn.com> <464852C3.1030200@cisco.com> In-Reply-To: <464852C3.1030200@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 May 2007 12:07:29.0538 (UTC) FILETIME=[9C316E20:01C796E9] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: 'SIMPLE mailing list' , 'Niemi Aki Petteri' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Paul: Some inline comments. Paul Kyzivat wrote: > > Is there really a requirement that a participant in a conference be able > to have *two* nicknames - one for the AOR and one for the nickname? I > question this. I didn't understand your question, you spoke about two nicknames: one for the AoR and one for the nickname... Doesn't it go in circles? As far as I know, the requirement is to have a nickname. One nickname. > > I think these requirements could stand to have some further > clarification about what the intent is. > > Is the goal to restrict when private messages may be sent? Or to > guarantee that the conference server *mediates* all messages sent > between participants? Or both? There is no requirement to restrict when private messages are sent. There is a requirement that the conference server acts as an anonymizer to avoid end-to-end knowledge of identities. The solution is to place the conference server as a router of messages based on nicknames, so the second option you mentioned. > > I would distinguish between how this is implemented by existing servers, > which may simply be just the best they could manage, and what the actual > intent is. > >> >> I think the "seperate" creates a bunch of problems. I think anyone is >> willing to deploy a generic nickname service. > > I presume you mean "anyone is *free* to deploy a generic nickname service." > > While that is true, it won't matter if a conference server doesn't > permit users who are using such a service. In particular, it won't > matter if the conference service only permits users whose AOR is hosted > by a particular domain. AFAIK that is currently the situation for major > providers such as AOL. So then the question is whether we are trying to > address those kinds of service providers. I think you are speaking about identities (AoR), in particular to asserted identities derived through direct authentication. It is true that some conference services have a policy that requires participants to have an identity provided by the conference server network, due to technical or policy reasons. I would say that we don't care about that, because this is related to AoRs, and the draft does not discuss that issue. When we move the discussion to nicknames, we have the unique nickname requirement (at least within a conference), and the mechanism to represent nicknames for private messaging routing. Whether the nickname is "provided" by the conference server or not, is not really a requirement, but the uniqueness requirement may reveal that the solution is to let the conference server administer the nicknames. Again, these are not the AoRs, which will be used as an asserted identity. /Miguel -- Please note my new e-mail address: miguel.garcia at nsn.com Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 15 09:44: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 1HnxKT-0001E3-VS; Tue, 15 May 2007 09:44:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnxKT-0001Dy-1U for simple@ietf.org; Tue, 15 May 2007 09:44:41 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnxKS-0005Zt-Lu for simple@ietf.org; Tue, 15 May 2007 09:44:41 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 May 2007 09:44:37 -0400 X-IronPort-AV: i="4.14,537,1170651600"; d="scan'208"; a="60258483:sNHT9781165130" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4FDiaMj010897; Tue, 15 May 2007 09:44:36 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4FDiJ5r013127; Tue, 15 May 2007 13:44:27 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 09:44:18 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 09:44:18 -0400 Message-ID: <4649B933.3030007@cisco.com> Date: Tue, 15 May 2007 09:44:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com><66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com><46417DDA.9090000@nsn.com> <4641B657.2010405@cisco.com> <4642C587.9040107@nsn.com> <080501c795f3$09614670$e4003c0a@cis.neustar.com> <4648177C.9020106@nsn.com> <464852C3.1030200@cisco.com> <4649A281.2000901@nsn.com> In-Reply-To: <4649A281.2000901@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 May 2007 13:44:18.0554 (UTC) FILETIME=[22A2EDA0:01C796F7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6046; t=1179236676; x=1180100676; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20MSRP=20chat=3A=20SIP-based=20nickname=20ne gotiation |Sender:=20 |To:=20Miguel=20Garcia=20; bh=uFalwQQf6z58cYgqNwy7OSY/iCwXCwqcrrmq2CdmKT0=; b=V1uAvp/kb6xx1RUxVG1UKjr49RkB0EroqJD7kVkGCKZHy/dJib7W3mZ/QjTGBc95adzfw0Hb BigCXuS5KMCivDpAoQywB9J7BXAICORLxiFaSM2piqrk6R0ttO+HntBM; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: 'SIMPLE mailing list' , 'Niemi Aki Petteri' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Miguel Garcia wrote: > Hi Paul: > > > Some inline comments. > > Paul Kyzivat wrote: > >> >> Is there really a requirement that a participant in a conference be >> able to have *two* nicknames - one for the AOR and one for the >> nickname? I question this. > > > I didn't understand your question, you spoke about two nicknames: one > for the AoR and one for the nickname... Doesn't it go in circles? Sorry! I didn't write what I meant. I meant: Is there really a requirement that a participant in a conference be able to have *two* *display names* - one for the AOR and one for the nickname? I question this. > As far as I know, the requirement is to have a nickname. One nickname. > >> >> I think these requirements could stand to have some further >> clarification about what the intent is. >> >> Is the goal to restrict when private messages may be sent? Or to >> guarantee that the conference server *mediates* all messages sent >> between participants? Or both? > > There is no requirement to restrict when private messages are sent. > There is a requirement that the conference server acts as an anonymizer > to avoid end-to-end knowledge of identities. The solution is to place > the conference server as a router of messages based on nicknames, so the > second option you mentioned. I'm trying to get a better handle on the requirement here. I guess you are saying that you see a requirement for the conference server to mediate all requests addressed to a nickname. And that is in contrast to having some anonymizer that might *not* be part of the conference server doing the mediation. And my question is *why* that is a requirement. As to the first part of my question above: what behavior do you think is required if a request is received for a nickname when the nickname may be used in more than one conference, and might be assigned to a particular user at times when the user is not in any conference. I know the past proposals have always been that the nickname is not a first class addressable entity - that requests destined for a particular nickname have been addressed to a conference focus and sub-addressed to particular nicknames for the focus to act on. But that only works for MSRP. I can't imagine that working with RTP for voice conferences. So I'm looking for the fundamental requirement rather than the mechanism used to achieve it. IMO the nickname could easily be a globally routable URI, mediated by an anonymizer, which may or may not be associated with a conference server. When requests are addressed to it, it will need to apply some sort of analysis to decide if the request should be routed on. Lots of rules are possible, from simple to complex: - any time there is a known mapping between the nickname and the actual URI for the user then a request will be forwarded. (Where this is a static, configured mapping.) - any time the user owning the nickname has registered to receive requests then the request will be forwarded. (The usual sip registration model, though perhaps the contact being registered might be an AOR in another domain.) - the request will only be forwarded if the user owning the nickname is currently participating in some conference known to the anonymizer. - The participation in a conference via a nickname anonymizer will result in the participant having an AOR (the nickname) and a contact address supplied by the anonymizer being visible to the conference focus and potentially the other participants. If other participants chose to send requests out of dialog to that contact address (a form of gruu), they could be forwarded, out of dialog, to the contact address the user is using for participation, via the anonymizer, to that conference. This would work when the user is in a conference, and would localize the request to the particular conference without there needing to be any connection between the anonymizer and the conf server. >> I would distinguish between how this is implemented by existing >> servers, which may simply be just the best they could manage, and what >> the actual intent is. >> > > >>> >>> I think the "seperate" creates a bunch of problems. I think anyone is >>> willing to deploy a generic nickname service. >> >> I presume you mean "anyone is *free* to deploy a generic nickname >> service." >> >> While that is true, it won't matter if a conference server doesn't >> permit users who are using such a service. In particular, it won't >> matter if the conference service only permits users whose AOR is >> hosted by a particular domain. AFAIK that is currently the situation >> for major providers such as AOL. So then the question is whether we >> are trying to address those kinds of service providers. > > I think you are speaking about identities (AoR), in particular to > asserted identities derived through direct authentication. It is true > that some conference services have a policy that requires participants > to have an identity provided by the conference server network, due to > technical or policy reasons. I would say that we don't care about that, > because this is related to AoRs, and the draft does not discuss that issue. > > When we move the discussion to nicknames, we have the unique nickname > requirement (at least within a conference), and the mechanism to > represent nicknames for private messaging routing. Whether the nickname > is "provided" by the conference server or not, is not really a > requirement, but the uniqueness requirement may reveal that the solution > is to let the conference server administer the nicknames. Again, these > are not the AoRs, which will be used as an asserted identity. I don't know where to go with the above. IMO if the conf service allowed arbitrary AORs then an external nickname service would be sufficient. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 15 18:50: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 1Ho5qc-0006f2-JV; Tue, 15 May 2007 18:50:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho5qE-0005gK-HE; Tue, 15 May 2007 18:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho5qE-0001ni-3w; Tue, 15 May 2007 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 166B53296B; Tue, 15 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ho5qD-00042q-VH; Tue, 15 May 2007 18:50:01 -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, 15 May 2007 18:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-imdn-04.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 : Instant Message Disposition Notification Author(s) : E. Burger, H. Khartabil Filename : draft-ietf-simple-imdn-04.txt Pages : 37 Date : 2007-5-15 Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing and read notifications, for page-mode instant messages. The Common Profile for Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs. This document also describes how SIP entities behave using this extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-04.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-imdn-04.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-imdn-04.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-5-15155810.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-imdn-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-imdn-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-15155810.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 Wed May 16 06:27: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 1HoGj9-0006yb-Mb; Wed, 16 May 2007 06:27:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoGj8-0006yS-7J for simple@ietf.org; Wed, 16 May 2007 06:27:26 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoGj6-0004cO-Pp for simple@ietf.org; Wed, 16 May 2007 06:27:26 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4GAQtcr013183; Wed, 16 May 2007 13:27:16 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 13:27:14 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 13:27:14 +0300 Received: from [172.21.58.33] ([172.21.58.33]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 13:27:13 +0300 Message-ID: <464ADC81.7000501@nsn.com> Date: Wed, 16 May 2007 13:27:13 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com><66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com><46417DDA.9090000@nsn.com> <4641B657.2010405@cisco.com> <4642C587.9040107@nsn.com> <080501c795f3$09614670$e4003c0a@cis.neustar.com> <4648177C.9020106@nsn.com> <464852C3.1030200@cisco.com> <4649A281.2000901@nsn.com> <4649B933.3030007@cisco.com> In-Reply-To: <4649B933.3030007@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2007 10:27:13.0472 (UTC) FILETIME=[C4C05C00:01C797A4] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'SIMPLE mailing list' , 'Niemi Aki Petteri' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Paul Kyzivat wrote: > > Is there really a requirement that a participant in a conference be able > to have *two* *display names* - one for the AOR and one for the > nickname? I question this. > I think such requirement exists. Let's assume the following use case: I am logged into a chat room, where I can see the list of participants, learned through a subscription to the (potentially extended with nicknames) conference event package. I can do a right click on a participant and I get a context sensitive menu. If the participant is anonymous, I can send a private message to him/her. If the participant has disclosed his URI, then in addition to sending a private message, I can also save his SIP URI and other information in my phonebook or contacts application. I can also check his profile, I can check the capabilities of his SIP UA (by sending an OPTIONS). The OPTIONS could be done automatically, so the UI could change the color if, for example, the response from the OPTIONS indicates that the participant supports audio and video. If we decide to hijack an existing header for describing nicknames, then we will break all this use cases. For example, I could be storing a non-existent name or URI in my phonebook (if the user was anonymous). Or if we decide to not disclose SIP URIs at all, then I wouldn't be able to view profiles or query for capabilities. My conclusion is that the nickname is an additional feature that shouldn't override the existing headers and features. /Miguel -- Please note my new e-mail address: miguel.garcia at nsn.com Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 16 10:09: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 1HoKBe-00034o-Tc; Wed, 16 May 2007 10:09:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoKBd-00034i-78 for simple@ietf.org; Wed, 16 May 2007 10:09:05 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoKBc-0005gp-5p for simple@ietf.org; Wed, 16 May 2007 10:09:05 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 515DF20802; Wed, 16 May 2007 16:09:03 +0200 (CEST) X-AuditID: c1b4fb3c-a8cebbb0000073d5-88-464b107fd8b4 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2901F205FA; Wed, 16 May 2007 16:09:03 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 16:09:03 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 16:09:02 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7DDF527E6; Wed, 16 May 2007 17:09:02 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 101A74DC05; Wed, 16 May 2007 17:09:02 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9CFC74DC04; Wed, 16 May 2007 17:09:01 +0300 (EEST) Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation From: Salvatore Loreto To: Paul Kyzivat In-Reply-To: <4649B933.3030007@cisco.com> References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com> <66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com> <46417DDA.9090000@nsn.com> <4641B657.2010405@cisco.com> <4642C587.9040107@nsn.com> <080501c795f3$09614670$e4003c0a@cis.neustar.com> <4648177C.9020106@nsn.com> <464852C3.1030200@cisco.com> <4649A281.2000901@nsn.com> <4649B933.3030007@cisco.com> Content-Type: text/plain Date: Wed, 16 May 2007 17:09:01 +0300 Message-Id: <1179324541.4055.43.camel@n84.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 16 May 2007 14:09:02.0831 (UTC) FILETIME=[C1BF5FF0:01C797C3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: Miguel Garcia , 'SIMPLE mailing list' , 'Niemi Aki Petteri' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Paul, what it is not clear, maybe because I have lost some steps, in your proposal is where is located the anonymizer that should provide the anonymity or the nickname, should be in the user domain or in the conference service domain? /sal On Tue, 2007-05-15 at 09:44 -0400, Paul Kyzivat wrote: > > Miguel Garcia wrote: > > Hi Paul: > > > > > > Some inline comments. > > > > Paul Kyzivat wrote: > > > >> > >> Is there really a requirement that a participant in a conference be > >> able to have *two* nicknames - one for the AOR and one for the > >> nickname? I question this. > > > > > > I didn't understand your question, you spoke about two nicknames: one > > for the AoR and one for the nickname... Doesn't it go in circles? > > Sorry! I didn't write what I meant. I meant: > > Is there really a requirement that a participant in a conference be able > to have *two* *display names* - one for the AOR and one for the > nickname? I question this. > > > As far as I know, the requirement is to have a nickname. One nickname. > > > >> > >> I think these requirements could stand to have some further > >> clarification about what the intent is. > >> > >> Is the goal to restrict when private messages may be sent? Or to > >> guarantee that the conference server *mediates* all messages sent > >> between participants? Or both? > > > > There is no requirement to restrict when private messages are sent. > > There is a requirement that the conference server acts as an anonymizer > > to avoid end-to-end knowledge of identities. The solution is to place > > the conference server as a router of messages based on nicknames, so the > > second option you mentioned. > > I'm trying to get a better handle on the requirement here. > > I guess you are saying that you see a requirement for the conference > server to mediate all requests addressed to a nickname. And that is in > contrast to having some anonymizer that might *not* be part of the > conference server doing the mediation. And my question is *why* that is > a requirement. > > As to the first part of my question above: what behavior do you think is > required if a request is received for a nickname when the nickname may > be used in more than one conference, and might be assigned to a > particular user at times when the user is not in any conference. > > I know the past proposals have always been that the nickname is not a > first class addressable entity - that requests destined for a particular > nickname have been addressed to a conference focus and sub-addressed to > particular nicknames for the focus to act on. But that only works for > MSRP. I can't imagine that working with RTP for voice conferences. > > So I'm looking for the fundamental requirement rather than the mechanism > used to achieve it. IMO the nickname could easily be a globally routable > URI, mediated by an anonymizer, which may or may not be associated with > a conference server. When requests are addressed to it, it will need to > apply some sort of analysis to decide if the request should be routed > on. Lots of rules are possible, from simple to complex: > > - any time there is a known mapping between the nickname and > the actual URI for the user then a request will be forwarded. > (Where this is a static, configured mapping.) > > - any time the user owning the nickname has registered to receive > requests then the request will be forwarded. (The usual sip > registration model, though perhaps the contact being registered > might be an AOR in another domain.) > > - the request will only be forwarded if the user owning the > nickname is currently participating in some conference known > to the anonymizer. > > - The participation in a conference via a nickname anonymizer > will result in the participant having an AOR (the nickname) > and a contact address supplied by the anonymizer being visible > to the conference focus and potentially the other participants. > If other participants chose to send requests out of dialog to > that contact address (a form of gruu), they could be forwarded, > out of dialog, to the contact address the user is using for > participation, via the anonymizer, to that conference. This > would work when the user is in a conference, and would localize > the request to the particular conference without there needing > to be any connection between the anonymizer and the conf server. > > >> I would distinguish between how this is implemented by existing > >> servers, which may simply be just the best they could manage, and what > >> the actual intent is. > >> > > > > > >>> > >>> I think the "seperate" creates a bunch of problems. I think anyone is > >>> willing to deploy a generic nickname service. > >> > >> I presume you mean "anyone is *free* to deploy a generic nickname > >> service." > >> > >> While that is true, it won't matter if a conference server doesn't > >> permit users who are using such a service. In particular, it won't > >> matter if the conference service only permits users whose AOR is > >> hosted by a particular domain. AFAIK that is currently the situation > >> for major providers such as AOL. So then the question is whether we > >> are trying to address those kinds of service providers. > > > > I think you are speaking about identities (AoR), in particular to > > asserted identities derived through direct authentication. It is true > > that some conference services have a policy that requires participants > > to have an identity provided by the conference server network, due to > > technical or policy reasons. I would say that we don't care about that, > > because this is related to AoRs, and the draft does not discuss that issue. > > > > When we move the discussion to nicknames, we have the unique nickname > > requirement (at least within a conference), and the mechanism to > > represent nicknames for private messaging routing. Whether the nickname > > is "provided" by the conference server or not, is not really a > > requirement, but the uniqueness requirement may reveal that the solution > > is to let the conference server administer the nicknames. Again, these > > are not the AoRs, which will be used as an asserted identity. > > I don't know where to go with the above. IMO if the conf service allowed > arbitrary AORs then an external nickname service would be sufficient. > > Paul > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 16 10:25: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 1HoKRL-0007Qe-IA; Wed, 16 May 2007 10:25:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoKRK-0007QY-C1 for simple@ietf.org; Wed, 16 May 2007 10:25:18 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoKRK-0000gI-2Y for simple@ietf.org; Wed, 16 May 2007 10:25:18 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HoKPc-0003bm-GB; Wed, 16 May 2007 09:23:32 -0500 From: "Brian Rosen" To: "'Miguel Garcia'" , "'Paul Kyzivat'" References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com><66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com><46417DDA.9090000@nsn.com> <4641B657.2010405@cisco.com> <4642C587.9040107@nsn.com> <080501c795f3$09614670$e4003c0a@cis.neustar.com> <4648177C.9020106@nsn.com> <464852C3.1030200@cisco.com> <4649A281.2000901@nsn.com> <4649B933.3030007@cisco.com> <464ADC81.7000501@nsn.com> Subject: RE: [Simple] MSRP chat: SIP-based nickname negotiation Date: Wed, 16 May 2007 10:25:10 -0400 Message-ID: <077901c797c6$042fd1b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceXpI9s3+hMe34QS+K5cH2gV1+dNwAIMWHg In-Reply-To: <464ADC81.7000501@nsn.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 - [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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: 'Niemi Aki Petteri' , 'SIMPLE mailing list' 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 think that a nickname is an unadorned "display name" thing. There isn't the displayname+user@domain combination as in an AoR. So I think a display name and a nickname are not the same thing, but there isn't both a visual and an addressing component of a nickname; there is just a nickname. My display name is usually "Brian Rosen". My nickname is "br" or "brtech. Those are very clearly different, and I agree with Miguel that we don't want to re-use the display name in an AoR. Brian > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > Sent: Wednesday, May 16, 2007 6:27 AM > To: Paul Kyzivat > Cc: Brian Rosen; 'Niemi Aki Petteri'; 'SIMPLE mailing list' > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > > Paul Kyzivat wrote: > > > > Is there really a requirement that a participant in a conference be able > > to have *two* *display names* - one for the AOR and one for the > > nickname? I question this. > > > > I think such requirement exists. Let's assume the following use case: I > am logged into a chat room, where I can see the list of participants, > learned through a subscription to the (potentially extended with > nicknames) conference event package. I can do a right click on a > participant and I get a context sensitive menu. If the participant is > anonymous, I can send a private message to him/her. If the participant > has disclosed his URI, then in addition to sending a private message, I > can also save his SIP URI and other information in my phonebook or > contacts application. I can also check his profile, I can check the > capabilities of his SIP UA (by sending an OPTIONS). The OPTIONS could be > done automatically, so the UI could change the color if, for example, > the response from the OPTIONS indicates that the participant supports > audio and video. > > If we decide to hijack an existing header for describing nicknames, then > we will break all this use cases. For example, I could be storing a > non-existent name or URI in my phonebook (if the user was anonymous). Or > if we decide to not disclose SIP URIs at all, then I wouldn't be able to > view profiles or query for capabilities. > > My conclusion is that the nickname is an additional feature that > shouldn't override the existing headers and features. > > /Miguel > > > > > > > -- > Please note my new e-mail address: miguel.garcia at nsn.com > Miguel A. Garcia tel:+358-50-4804586 > Nokia Siemens Networks Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 16 11:12: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 1HoLB9-0004T0-3I; Wed, 16 May 2007 11:12:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoLB7-0004Sc-WB for simple@ietf.org; Wed, 16 May 2007 11:12:38 -0400 Received: from mail5.opus-i.net ([209.10.181.173] helo=FPNYEXCBE02.opus-i.corp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoLB6-0004It-M6 for simple@ietf.org; Wed, 16 May 2007 11:12:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP chat: SIP-based nickname negotiation Date: Wed, 16 May 2007 11:12:28 -0400 Message-ID: <3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp> In-Reply-To: <077901c797c6$042fd1b0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP chat: SIP-based nickname negotiation Thread-Index: AceXpI9s3+hMe34QS+K5cH2gV1+dNwAIMWHgAAE55IA= References: <464056CA.1080209@nsn.com><464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com><46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com><66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com><46417DDA.9090000@nsn.com><4641B657.2010405@cisco.com> <4642C587.9040107@nsn.com><080501c795f3$09614670$e4003c0a@cis.neustar.com><4648177C.9020106@nsn.com> <464852C3.1030200@cisco.com><4649A281.2000901@nsn.com> <4649B933.3030007@cisco.com><464ADC81.7000501@nsn.com> <077901c797c6$042fd1b0$640fa8c0@cis.neustar.com> From: "Bob Serr" To: "Brian Rosen" , "Miguel Garcia" , "Paul Kyzivat" X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Niemi Aki Petteri , SIMPLE mailing list 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 agree that the nickname should be an additional feature, beyond AOR and display name, and that the feature should be optional. It is a requirement that a user be able to select users in a participant list and click into other modalities. Regarding whether the nickname service is separate or part of the conferencing server, it would be a simpler and easier to manage architecture if it was part of the conferencing server. This will work better in federated chat environments as it will be one less service that you need to connect to in the federated environment. Additionally, it will likely be the conferencing server, or even the conference/room/channel that applies the policy about whether nicknames are supported on the channel. For example, one room may allow anonymous access while another may require that all user identities are known. Bob -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, May 16, 2007 9:25 AM To: 'Miguel Garcia'; 'Paul Kyzivat' Cc: 'Niemi Aki Petteri'; 'SIMPLE mailing list' Subject: RE: [Simple] MSRP chat: SIP-based nickname negotiation I think that a nickname is an unadorned "display name" thing. There isn't the displayname+user@domain combination as in an AoR. So I think a display name and a nickname are not the same thing, but there isn't both a visual and an addressing component of a nickname; there is just a nickname. My display name is usually "Brian Rosen". My nickname is "br" or "brtech. Those are very clearly different, and I agree with Miguel that we don't want to re-use the display name in an AoR. Brian > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > Sent: Wednesday, May 16, 2007 6:27 AM=20 > To: Paul Kyzivat > Cc: Brian Rosen; 'Niemi Aki Petteri'; 'SIMPLE mailing list' > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation >=20 > Paul Kyzivat wrote: > > > > Is there really a requirement that a participant in a conference be able > > to have *two* *display names* - one for the AOR and one for the > > nickname? I question this. > > >=20 > I think such requirement exists. Let's assume the following use case: I > am logged into a chat room, where I can see the list of participants, > learned through a subscription to the (potentially extended with > nicknames) conference event package. I can do a right click on a > participant and I get a context sensitive menu. If the participant is > anonymous, I can send a private message to him/her. If the participant > has disclosed his URI, then in addition to sending a private message, I > can also save his SIP URI and other information in my phonebook or > contacts application. I can also check his profile, I can check the > capabilities of his SIP UA (by sending an OPTIONS). The OPTIONS could be > done automatically, so the UI could change the color if, for example, > the response from the OPTIONS indicates that the participant supports > audio and video. >=20 > If we decide to hijack an existing header for describing nicknames, then > we will break all this use cases. For example, I could be storing a > non-existent name or URI in my phonebook (if the user was anonymous). Or > if we decide to not disclose SIP URIs at all, then I wouldn't be able to > view profiles or query for capabilities. >=20 > My conclusion is that the nickname is an additional feature that > shouldn't override the existing headers and features. >=20 > /Miguel >=20 >=20 >=20 >=20 >=20 >=20 > -- > Please note my new e-mail address: miguel.garcia at nsn.com > Miguel A. Garcia tel:+358-50-4804586 > Nokia Siemens Networks Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 16 12:21: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 1HoMFx-0001nd-2S; Wed, 16 May 2007 12:21:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoMFv-0001nY-DD for simple@ietf.org; Wed, 16 May 2007 12:21:39 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoMFt-00076Y-TW for simple@ietf.org; Wed, 16 May 2007 12:21:39 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 16 May 2007 12:21:37 -0400 X-IronPort-AV: i="4.14,544,1170651600"; d="scan'208"; a="121259021:sNHT56371808" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4GGLbps008107; Wed, 16 May 2007 12:21:37 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4GGLS5r011710; Wed, 16 May 2007 16:21: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); Wed, 16 May 2007 12:21:28 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 12:21:28 -0400 Message-ID: <464B2F86.3010409@cisco.com> Date: Wed, 16 May 2007 12:21:26 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Salvatore Loreto Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com> <66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com> <46417DDA.9090000@nsn.com> <4641B657.2010405@cisco.com> <4642C587.9040107@nsn.com> <080501c795f3$09614670$e4003c0a@cis.neustar.com> <4648177C.9020106@nsn.com> <464852C3.1030200@cisco.com> <4649A281.2000901@nsn.com> <4649B933.3030007@cisco.com> <1179324541.4055.43.camel@n84.nomadiclab.com> In-Reply-To: <1179324541.4055.43.camel@n84.nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2007 16:21:28.0244 (UTC) FILETIME=[41952F40:01C797D6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8164; t=1179332497; x=1180196497; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20MSRP=20chat=3A=20SIP-based=20nickname=20ne gotiation |Sender:=20 |To:=20Salvatore=20Loreto=20; bh=VCxdpm952Myj5rxOLTQ1hfwEZKf5sqtyfMbc9bik2OE=; b=satRN/r8oDELCFM0jcNdMHXwiRZXshaT4uaGzfTfmbTGwuIjSicHgezrMEhZwj3cGhiy5Hs+ WKM/3obOgSTNHpUqJn76jr00KgZoKeR1JTLvikNa15KJ9HB4Hni1ZMTF; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: Miguel Garcia , 'SIMPLE mailing list' , 'Niemi Aki Petteri' 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 Salvatore Loreto wrote: > Hi Paul, > > what it is not clear, maybe because I have lost some steps, > in your proposal is where is located the anonymizer that should provide > the anonymity or the nickname, > should be in the user domain or in the conference service domain? I'm suggesting that it could be anywhere. There could be an independent anonymizer service. (It could perhaps provide a variety of services. If you wish to make a single anonymous call and not be reachable then it could fill in an Anonymous identity. If you want to use a long lived nickname as a pseudonym then it could provide that.) If you use that sort of anonymizer to access a conference, then as far as the conference server is concerned the nickname is your actual AOR, and any authorization it does of you would be based on that. The operator of conference servers could provide an anonymizer that provides nicknames for the convenience of users that have no better source. It could operate this in parallel but independently of its conference servers, or it could choose to couple them in some way. For instance it might only support using its anonymizer for originating requests to its own conference servers. It also might impose a filter so that out of dialog requests addressed to a nickname are only delivered if there is an active session for that nickname between the anonymizer and one of its conference servers. Authentication and authorization could also be coupled between the two servers. I would hope that a provider of conference servers would not require use of its own anonymizer. Paul > /sal > > > > On Tue, 2007-05-15 at 09:44 -0400, Paul Kyzivat wrote: >> Miguel Garcia wrote: >>> Hi Paul: >>> >>> >>> Some inline comments. >>> >>> Paul Kyzivat wrote: >>> >>>> Is there really a requirement that a participant in a conference be >>>> able to have *two* nicknames - one for the AOR and one for the >>>> nickname? I question this. >>> >>> I didn't understand your question, you spoke about two nicknames: one >>> for the AoR and one for the nickname... Doesn't it go in circles? >> Sorry! I didn't write what I meant. I meant: >> >> Is there really a requirement that a participant in a conference be able >> to have *two* *display names* - one for the AOR and one for the >> nickname? I question this. >> >>> As far as I know, the requirement is to have a nickname. One nickname. >>> >>>> I think these requirements could stand to have some further >>>> clarification about what the intent is. >>>> >>>> Is the goal to restrict when private messages may be sent? Or to >>>> guarantee that the conference server *mediates* all messages sent >>>> between participants? Or both? >>> There is no requirement to restrict when private messages are sent. >>> There is a requirement that the conference server acts as an anonymizer >>> to avoid end-to-end knowledge of identities. The solution is to place >>> the conference server as a router of messages based on nicknames, so the >>> second option you mentioned. >> I'm trying to get a better handle on the requirement here. >> >> I guess you are saying that you see a requirement for the conference >> server to mediate all requests addressed to a nickname. And that is in >> contrast to having some anonymizer that might *not* be part of the >> conference server doing the mediation. And my question is *why* that is >> a requirement. >> >> As to the first part of my question above: what behavior do you think is >> required if a request is received for a nickname when the nickname may >> be used in more than one conference, and might be assigned to a >> particular user at times when the user is not in any conference. >> >> I know the past proposals have always been that the nickname is not a >> first class addressable entity - that requests destined for a particular >> nickname have been addressed to a conference focus and sub-addressed to >> particular nicknames for the focus to act on. But that only works for >> MSRP. I can't imagine that working with RTP for voice conferences. >> >> So I'm looking for the fundamental requirement rather than the mechanism >> used to achieve it. IMO the nickname could easily be a globally routable >> URI, mediated by an anonymizer, which may or may not be associated with >> a conference server. When requests are addressed to it, it will need to >> apply some sort of analysis to decide if the request should be routed >> on. Lots of rules are possible, from simple to complex: >> >> - any time there is a known mapping between the nickname and >> the actual URI for the user then a request will be forwarded. >> (Where this is a static, configured mapping.) >> >> - any time the user owning the nickname has registered to receive >> requests then the request will be forwarded. (The usual sip >> registration model, though perhaps the contact being registered >> might be an AOR in another domain.) >> >> - the request will only be forwarded if the user owning the >> nickname is currently participating in some conference known >> to the anonymizer. >> >> - The participation in a conference via a nickname anonymizer >> will result in the participant having an AOR (the nickname) >> and a contact address supplied by the anonymizer being visible >> to the conference focus and potentially the other participants. >> If other participants chose to send requests out of dialog to >> that contact address (a form of gruu), they could be forwarded, >> out of dialog, to the contact address the user is using for >> participation, via the anonymizer, to that conference. This >> would work when the user is in a conference, and would localize >> the request to the particular conference without there needing >> to be any connection between the anonymizer and the conf server. >> >>>> I would distinguish between how this is implemented by existing >>>> servers, which may simply be just the best they could manage, and what >>>> the actual intent is. >>>> >>> >>>>> I think the "seperate" creates a bunch of problems. I think anyone is >>>>> willing to deploy a generic nickname service. >>>> I presume you mean "anyone is *free* to deploy a generic nickname >>>> service." >>>> >>>> While that is true, it won't matter if a conference server doesn't >>>> permit users who are using such a service. In particular, it won't >>>> matter if the conference service only permits users whose AOR is >>>> hosted by a particular domain. AFAIK that is currently the situation >>>> for major providers such as AOL. So then the question is whether we >>>> are trying to address those kinds of service providers. >>> I think you are speaking about identities (AoR), in particular to >>> asserted identities derived through direct authentication. It is true >>> that some conference services have a policy that requires participants >>> to have an identity provided by the conference server network, due to >>> technical or policy reasons. I would say that we don't care about that, >>> because this is related to AoRs, and the draft does not discuss that issue. >>> >>> When we move the discussion to nicknames, we have the unique nickname >>> requirement (at least within a conference), and the mechanism to >>> represent nicknames for private messaging routing. Whether the nickname >>> is "provided" by the conference server or not, is not really a >>> requirement, but the uniqueness requirement may reveal that the solution >>> is to let the conference server administer the nicknames. Again, these >>> are not the AoRs, which will be used as an asserted identity. >> I don't know where to go with the above. IMO if the conf service allowed >> arbitrary AORs then an external nickname service would be sufficient. >> >> Paul >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 16 12:35:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoMT6-0002II-AA; Wed, 16 May 2007 12:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoMSv-000265-1y for simple@ietf.org; Wed, 16 May 2007 12:35:05 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoMSu-00035K-JI for simple@ietf.org; Wed, 16 May 2007 12:35:05 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 May 2007 12:35:04 -0400 X-IronPort-AV: i="4.14,544,1170651600"; d="scan'208"; a="121260402:sNHT54930338" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4GGZ4kZ009662; Wed, 16 May 2007 12:35:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4GGYU6J015507; Wed, 16 May 2007 16:34:51 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 12:34:47 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 12:34:47 -0400 Message-ID: <464B32A4.3000708@cisco.com> Date: Wed, 16 May 2007 12:34:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Bob Serr Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com><464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com><46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com><66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com><46417DDA.9090000@nsn.com><4641B657.2010405@cisco.com> <4642C587.9040107@nsn.com><080501c795f3$09614670$e4003c0a@cis.neustar.com><4648177C.9020106@nsn.com> <464852C3.1030200@cisco.com><4649A281.2000901@nsn.com> <4649B933.3030007@cisco.com><464ADC81.7000501@nsn.com> <077901c797c6$042fd1b0$640fa8c0@cis.neustar.com> <3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp> In-Reply-To: <3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2007 16:34:47.0609 (UTC) FILETIME=[1E0A9A90:01C797D8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5083; t=1179333304; x=1180197304; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20MSRP=20chat=3A=20SIP-based=20nickname=20ne gotiation |Sender:=20 |To:=20Bob=20Serr=20; bh=TLPAZC4ZclShsPNPmZrXsr7/if2FDdHxCOnLT6j2cmY=; b=oMAOldc3JUlwEYtiCUN7f79GzdJZA8etynSyMVQIE0OGWzBSYhG3+Sw7kdIxuzW5Lgh6tShn tCRhBZkvx5jvV6urrDPVBzQ4gihVVuZuWskNe2VWz5MvjvY0169YRZne; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: SIMPLE mailing list , Miguel Garcia , Niemi Aki Petteri X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The disadvantage of having the nickname as part of the conferencing server is that the scope of the nickname is tied to the scope of the conferencing server. For instance, suppose ietf maintained a conferencing server for use by the workgroups. I could have "paulk" as a nickname in that scope, for multiple conferences related to ietf things - sip, sipping, simple, etc. Then perhaps SIPforum might have a conference server for use by the things it handles, such as SIPit. If it managed its own nicknames, then I might or might not be able to get the nickname "paulk". Its possible that somebody else might get that nickname there. If the nickname anonymizer/provider could be independent of the conference server, then I could get paulk and use it as my identity in all of those conferences. Then people would know it was always the same person. With the nicknames coupled to the conf servers, even if I got "paulk" both places, people wouldn't necessarily know it was the same person. Paul Bob Serr wrote: > I agree that the nickname should be an additional feature, beyond AOR > and display name, and that the feature should be optional. It is a > requirement that a user be able to select users in a participant list > and click into other modalities. > > Regarding whether the nickname service is separate or part of the > conferencing server, it would be a simpler and easier to manage > architecture if it was part of the conferencing server. This will work > better in federated chat environments as it will be one less service > that you need to connect to in the federated environment. Additionally, > it will likely be the conferencing server, or even the > conference/room/channel that applies the policy about whether nicknames > are supported on the channel. For example, one room may allow anonymous > access while another may require that all user identities are known. > > Bob > > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, May 16, 2007 9:25 AM > To: 'Miguel Garcia'; 'Paul Kyzivat' > Cc: 'Niemi Aki Petteri'; 'SIMPLE mailing list' > Subject: RE: [Simple] MSRP chat: SIP-based nickname negotiation > > I think that a nickname is an unadorned "display name" thing. There > isn't > the displayname+user@domain combination as in an AoR. So I think a > display > name and a nickname are not the same thing, but there isn't both a > visual > and an addressing component of a nickname; there is just a nickname. > > My display name is usually "Brian Rosen". My nickname is "br" or > "brtech. > Those are very clearly different, and I agree with Miguel that we don't > want > to re-use the display name in an AoR. > > Brian > >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >> Sent: Wednesday, May 16, 2007 6:27 AM >> To: Paul Kyzivat >> Cc: Brian Rosen; 'Niemi Aki Petteri'; 'SIMPLE mailing list' >> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation >> >> Paul Kyzivat wrote: >>> Is there really a requirement that a participant in a conference be > able >>> to have *two* *display names* - one for the AOR and one for the >>> nickname? I question this. >> > >> >> I think such requirement exists. Let's assume the following use case: > I >> am logged into a chat room, where I can see the list of participants, >> learned through a subscription to the (potentially extended with >> nicknames) conference event package. I can do a right click on a >> participant and I get a context sensitive menu. If the participant is >> anonymous, I can send a private message to him/her. If the participant >> has disclosed his URI, then in addition to sending a private message, > I >> can also save his SIP URI and other information in my phonebook or >> contacts application. I can also check his profile, I can check the >> capabilities of his SIP UA (by sending an OPTIONS). The OPTIONS could > be >> done automatically, so the UI could change the color if, for example, >> the response from the OPTIONS indicates that the participant supports >> audio and video. >> >> If we decide to hijack an existing header for describing nicknames, > then >> we will break all this use cases. For example, I could be storing a >> non-existent name or URI in my phonebook (if the user was anonymous). > Or >> if we decide to not disclose SIP URIs at all, then I wouldn't be able > to >> view profiles or query for capabilities. >> >> My conclusion is that the nickname is an additional feature that >> shouldn't override the existing headers and features. >> >> /Miguel >> >> >> >> >> >> >> -- >> Please note my new e-mail address: miguel.garcia at nsn.com >> Miguel A. Garcia tel:+358-50-4804586 >> Nokia Siemens Networks Helsinki, Finland > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 16 14:46:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoOVr-00081x-4E; Wed, 16 May 2007 14:46:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoOVq-00081o-3w for simple@ietf.org; Wed, 16 May 2007 14:46:14 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoOVo-0000RM-I3 for simple@ietf.org; Wed, 16 May 2007 14:46:14 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HoOU1-00041E-5l; Wed, 16 May 2007 13:44:21 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" , "'Salvatore Loreto'" References: <464056CA.1080209@nsn.com> <464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com> <46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com> <66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com> <46417DDA.9090000@nsn.com> <4641B657.2010405@cisco.com> <4642C587.9040107@nsn.com><080501c795f3$09614670$e4003c0a@cis.neustar.com> <4648177C.9020106@nsn.com> <464852C3.1030200@cisco.com> <4649A281.2000901@nsn.com> <4649B933.3030007@cisco.com><1179324541.4055.43.camel@n84.nomadiclab.com> <464B2F86.3010409@cisco.com> Subject: RE: [Simple] MSRP chat: SIP-based nickname negotiation Date: Wed, 16 May 2007 14:46:01 -0400 Message-ID: <07d801c797ea$75174830$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceX1hEouC+X8prFSkO/x0J8oYbzwAAFD+ZQ In-Reply-To: <464B2F86.3010409@cisco.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 - [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: 8b6657e60309a1317174c9db2ae5f227 Cc: 'Miguel Garcia' , 'SIMPLE mailing list' , 'Niemi Aki Petteri' 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 Yep, that's the way I see it. Anonymization of URI's is an independent thing. It may be common for a conference service to include an anonymizing service. No problem, but it's independent. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, May 16, 2007 12:21 PM > To: Salvatore Loreto > Cc: Miguel Garcia; 'SIMPLE mailing list'; 'Niemi Aki Petteri' > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > > > > Salvatore Loreto wrote: > > Hi Paul, > > > > what it is not clear, maybe because I have lost some steps, > > in your proposal is where is located the anonymizer that should provide > > the anonymity or the nickname, > > should be in the user domain or in the conference service domain? > > I'm suggesting that it could be anywhere. > > There could be an independent anonymizer service. (It could perhaps > provide a variety of services. If you wish to make a single anonymous > call and not be reachable then it could fill in an Anonymous identity. > If you want to use a long lived nickname as a pseudonym then it could > provide that.) If you use that sort of anonymizer to access a > conference, then as far as the conference server is concerned the > nickname is your actual AOR, and any authorization it does of you would > be based on that. > > The operator of conference servers could provide an anonymizer that > provides nicknames for the convenience of users that have no better > source. It could operate this in parallel but independently of its > conference servers, or it could choose to couple them in some way. For > instance it might only support using its anonymizer for originating > requests to its own conference servers. It also might impose a filter so > that out of dialog requests addressed to a nickname are only delivered > if there is an active session for that nickname between the anonymizer > and one of its conference servers. Authentication and authorization > could also be coupled between the two servers. > > I would hope that a provider of conference servers would not require use > of its own anonymizer. > > Paul > > > /sal > > > > > > > > On Tue, 2007-05-15 at 09:44 -0400, Paul Kyzivat wrote: > >> Miguel Garcia wrote: > >>> Hi Paul: > >>> > >>> > >>> Some inline comments. > >>> > >>> Paul Kyzivat wrote: > >>> > >>>> Is there really a requirement that a participant in a conference be > >>>> able to have *two* nicknames - one for the AOR and one for the > >>>> nickname? I question this. > >>> > >>> I didn't understand your question, you spoke about two nicknames: one > >>> for the AoR and one for the nickname... Doesn't it go in circles? > >> Sorry! I didn't write what I meant. I meant: > >> > >> Is there really a requirement that a participant in a conference be > able > >> to have *two* *display names* - one for the AOR and one for the > >> nickname? I question this. > >> > >>> As far as I know, the requirement is to have a nickname. One nickname. > >>> > >>>> I think these requirements could stand to have some further > >>>> clarification about what the intent is. > >>>> > >>>> Is the goal to restrict when private messages may be sent? Or to > >>>> guarantee that the conference server *mediates* all messages sent > >>>> between participants? Or both? > >>> There is no requirement to restrict when private messages are sent. > >>> There is a requirement that the conference server acts as an > anonymizer > >>> to avoid end-to-end knowledge of identities. The solution is to place > >>> the conference server as a router of messages based on nicknames, so > the > >>> second option you mentioned. > >> I'm trying to get a better handle on the requirement here. > >> > >> I guess you are saying that you see a requirement for the conference > >> server to mediate all requests addressed to a nickname. And that is in > >> contrast to having some anonymizer that might *not* be part of the > >> conference server doing the mediation. And my question is *why* that is > >> a requirement. > >> > >> As to the first part of my question above: what behavior do you think > is > >> required if a request is received for a nickname when the nickname may > >> be used in more than one conference, and might be assigned to a > >> particular user at times when the user is not in any conference. > >> > >> I know the past proposals have always been that the nickname is not a > >> first class addressable entity - that requests destined for a > particular > >> nickname have been addressed to a conference focus and sub-addressed to > >> particular nicknames for the focus to act on. But that only works for > >> MSRP. I can't imagine that working with RTP for voice conferences. > >> > >> So I'm looking for the fundamental requirement rather than the > mechanism > >> used to achieve it. IMO the nickname could easily be a globally > routable > >> URI, mediated by an anonymizer, which may or may not be associated with > >> a conference server. When requests are addressed to it, it will need to > >> apply some sort of analysis to decide if the request should be routed > >> on. Lots of rules are possible, from simple to complex: > >> > >> - any time there is a known mapping between the nickname and > >> the actual URI for the user then a request will be forwarded. > >> (Where this is a static, configured mapping.) > >> > >> - any time the user owning the nickname has registered to receive > >> requests then the request will be forwarded. (The usual sip > >> registration model, though perhaps the contact being registered > >> might be an AOR in another domain.) > >> > >> - the request will only be forwarded if the user owning the > >> nickname is currently participating in some conference known > >> to the anonymizer. > >> > >> - The participation in a conference via a nickname anonymizer > >> will result in the participant having an AOR (the nickname) > >> and a contact address supplied by the anonymizer being visible > >> to the conference focus and potentially the other participants. > >> If other participants chose to send requests out of dialog to > >> that contact address (a form of gruu), they could be forwarded, > >> out of dialog, to the contact address the user is using for > >> participation, via the anonymizer, to that conference. This > >> would work when the user is in a conference, and would localize > >> the request to the particular conference without there needing > >> to be any connection between the anonymizer and the conf server. > >> > >>>> I would distinguish between how this is implemented by existing > >>>> servers, which may simply be just the best they could manage, and > what > >>>> the actual intent is. > >>>> > >>> > >>>>> I think the "seperate" creates a bunch of problems. I think anyone > is > >>>>> willing to deploy a generic nickname service. > >>>> I presume you mean "anyone is *free* to deploy a generic nickname > >>>> service." > >>>> > >>>> While that is true, it won't matter if a conference server doesn't > >>>> permit users who are using such a service. In particular, it won't > >>>> matter if the conference service only permits users whose AOR is > >>>> hosted by a particular domain. AFAIK that is currently the situation > >>>> for major providers such as AOL. So then the question is whether we > >>>> are trying to address those kinds of service providers. > >>> I think you are speaking about identities (AoR), in particular to > >>> asserted identities derived through direct authentication. It is true > >>> that some conference services have a policy that requires participants > >>> to have an identity provided by the conference server network, due to > >>> technical or policy reasons. I would say that we don't care about > that, > >>> because this is related to AoRs, and the draft does not discuss that > issue. > >>> > >>> When we move the discussion to nicknames, we have the unique nickname > >>> requirement (at least within a conference), and the mechanism to > >>> represent nicknames for private messaging routing. Whether the > nickname > >>> is "provided" by the conference server or not, is not really a > >>> requirement, but the uniqueness requirement may reveal that the > solution > >>> is to let the conference server administer the nicknames. Again, these > >>> are not the AoRs, which will be used as an asserted identity. > >> I don't know where to go with the above. IMO if the conf service > allowed > >> arbitrary AORs then an external nickname service would be sufficient. > >> > >> Paul > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 16 14:54: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 1HoOdi-0003Fv-7J; Wed, 16 May 2007 14:54:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoOdg-0003Fp-51 for simple@ietf.org; Wed, 16 May 2007 14:54:20 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoOde-000359-Lv for simple@ietf.org; Wed, 16 May 2007 14:54:20 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HoObl-0005hS-Jz; Wed, 16 May 2007 13:52:22 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" , "'Bob Serr'" References: <464056CA.1080209@nsn.com><464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com><46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com><66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com><46417DDA.9090000@nsn.com><4641B657.2010405@cisco.com> <4642C587.9040107@nsn.com><080501c795f3$09614670$e4003c0a@cis.neustar.com><4648177C.9020106@nsn.com> <464852C3.1030200@cisco.com><4649A281.2000901@nsn.com> <4649B933.3030007@cisco.com><464ADC81.7000501@nsn.com> <077901c797c6$042fd1b0$640fa8c0@cis.neustar.com> <3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp> <464B32A4.3000708@cisco.com> Subject: RE: [Simple] MSRP chat: SIP-based nickname negotiation Date: Wed, 16 May 2007 14:54:02 -0400 Message-ID: <07df01c797eb$93a7e0b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceX1/GSD2iMNQTkSNeR6u8iD8J1PgAEq4lA In-Reply-To: <464B32A4.3000708@cisco.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 - [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: 2e8fc473f5174be667965460bd5288ba Cc: 'Miguel Garcia' , 'Niemi Aki Petteri' , 'SIMPLE mailing list' 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 think the problem here is scope. Within a domain, you could have a nick service. AOL is a great example. AOL could run a conference service, and use the same nicks. However, www.freeconferencing.com can also run a conference service, and it may not have anything interesting in its domain other than a conference service. Nicks are tricky, because of the uniqueness property. They are typically short, which means collisions on self selected nicks. The bigger the domain, the harder it is to maintain uniqueness. I've used brtech as a nick for a couple decades, and in most domains, I don't have a problem getting it. In AOL, I wasn't early enough; it was gone before AIM was available outside the AOL paid service. Of course brtech(3) is unique from brtech(1) and a temporary hack like that for uniqueness within a conference service works fine. I think we couple a nick service to a domain, and not necessarily a conference server. The conference server almost always has a subdomain in which it runs the nick service, of course. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, May 16, 2007 12:35 PM > To: Bob Serr > Cc: Brian Rosen; Miguel Garcia; Niemi Aki Petteri; SIMPLE mailing list > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > > The disadvantage of having the nickname as part of the conferencing > server is that the scope of the nickname is tied to the scope of the > conferencing server. > > For instance, suppose ietf maintained a conferencing server for use by > the workgroups. I could have "paulk" as a nickname in that scope, for > multiple conferences related to ietf things - sip, sipping, simple, etc. > > Then perhaps SIPforum might have a conference server for use by the > things it handles, such as SIPit. If it managed its own nicknames, then > I might or might not be able to get the nickname "paulk". Its possible > that somebody else might get that nickname there. > > If the nickname anonymizer/provider could be independent of the > conference server, then I could get > paulk > and use it as my identity in all of those conferences. Then people would > know it was always the same person. With the nicknames coupled to the > conf servers, even if I got "paulk" both places, people wouldn't > necessarily know it was the same person. > > Paul > > Bob Serr wrote: > > I agree that the nickname should be an additional feature, beyond AOR > > and display name, and that the feature should be optional. It is a > > requirement that a user be able to select users in a participant list > > and click into other modalities. > > > > Regarding whether the nickname service is separate or part of the > > conferencing server, it would be a simpler and easier to manage > > architecture if it was part of the conferencing server. This will work > > better in federated chat environments as it will be one less service > > that you need to connect to in the federated environment. Additionally, > > it will likely be the conferencing server, or even the > > conference/room/channel that applies the policy about whether nicknames > > are supported on the channel. For example, one room may allow anonymous > > access while another may require that all user identities are known. > > > > Bob > > > > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, May 16, 2007 9:25 AM > > To: 'Miguel Garcia'; 'Paul Kyzivat' > > Cc: 'Niemi Aki Petteri'; 'SIMPLE mailing list' > > Subject: RE: [Simple] MSRP chat: SIP-based nickname negotiation > > > > I think that a nickname is an unadorned "display name" thing. There > > isn't > > the displayname+user@domain combination as in an AoR. So I think a > > display > > name and a nickname are not the same thing, but there isn't both a > > visual > > and an addressing component of a nickname; there is just a nickname. > > > > My display name is usually "Brian Rosen". My nickname is "br" or > > "brtech. > > Those are very clearly different, and I agree with Miguel that we don't > > want > > to re-use the display name in an AoR. > > > > Brian > > > >> -----Original Message----- > >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > >> Sent: Wednesday, May 16, 2007 6:27 AM > >> To: Paul Kyzivat > >> Cc: Brian Rosen; 'Niemi Aki Petteri'; 'SIMPLE mailing list' > >> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > >> > >> Paul Kyzivat wrote: > >>> Is there really a requirement that a participant in a conference be > > able > >>> to have *two* *display names* - one for the AOR and one for the > >>> nickname? I question this. > >> > > >> > >> I think such requirement exists. Let's assume the following use case: > > I > >> am logged into a chat room, where I can see the list of participants, > >> learned through a subscription to the (potentially extended with > >> nicknames) conference event package. I can do a right click on a > >> participant and I get a context sensitive menu. If the participant is > >> anonymous, I can send a private message to him/her. If the participant > >> has disclosed his URI, then in addition to sending a private message, > > I > >> can also save his SIP URI and other information in my phonebook or > >> contacts application. I can also check his profile, I can check the > >> capabilities of his SIP UA (by sending an OPTIONS). The OPTIONS could > > be > >> done automatically, so the UI could change the color if, for example, > >> the response from the OPTIONS indicates that the participant supports > >> audio and video. > >> > >> If we decide to hijack an existing header for describing nicknames, > > then > >> we will break all this use cases. For example, I could be storing a > >> non-existent name or URI in my phonebook (if the user was anonymous). > > Or > >> if we decide to not disclose SIP URIs at all, then I wouldn't be able > > to > >> view profiles or query for capabilities. > >> > >> My conclusion is that the nickname is an additional feature that > >> shouldn't override the existing headers and features. > >> > >> /Miguel > >> > >> > >> > >> > >> > >> > >> -- > >> Please note my new e-mail address: miguel.garcia at nsn.com > >> Miguel A. Garcia tel:+358-50-4804586 > >> Nokia Siemens Networks Helsinki, Finland > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 16 15:56: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 1HoPc7-0001GU-31; Wed, 16 May 2007 15:56:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoPc6-0001GP-0u for simple@ietf.org; Wed, 16 May 2007 15:56:46 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoPc4-0006If-Dt for simple@ietf.org; Wed, 16 May 2007 15:56:46 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 May 2007 15:56:44 -0400 X-IronPort-AV: i="4.14,544,1170651600"; d="scan'208"; a="60408437:sNHT332290252" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4GJuhlJ006852; Wed, 16 May 2007 15:56:43 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4GJucBu014881; Wed, 16 May 2007 19:56:43 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 15:56:29 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 15:56:36 -0400 Message-ID: <464B61F2.7060600@cisco.com> Date: Wed, 16 May 2007 15:56:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com><464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com><46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com><66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com><46417DDA.9090000@nsn.com><4641B657.2010405@cisco.com> <4642C587.9040107@nsn.com><080501c795f3$09614670$e4003c0a@cis.neustar.com><4648177C.9020106@nsn.com> <464852C3.1030200@cisco.com><4649A281.2000901@nsn.com> <4649B933.3030007@cisco.com><464ADC81.7000501@nsn.com> <077901c797c6$042fd1b0$640fa8c0@cis.neustar.com> <3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp> <464B32A4.3000708@cisco.com> <07df01c797eb$93a7e0b0$640fa8c0@cis.neustar.com> In-Reply-To: <07df01c797eb$93a7e0b0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2007 19:56:36.0335 (UTC) FILETIME=[4F678FF0:01C797F4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7895; t=1179345403; x=1180209403; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20MSRP=20chat=3A=20SIP-based=20nickname=20ne gotiation |Sender:=20 |To:=20Brian=20Rosen=20; bh=tsLeejC2mun8FeKASipkhHFZZVykvqO8Kp5rysqB2L4=; b=j6zGnx2ZOhw/T1oW0vqacA0JSJB2sVqhgmz+vzKHbuxdMv52oz/m0QyogCuskeyYrtUAY958 63Eoq+8f67CNHHu8r1vidnwk4Epr126wzdBpNX9nD/8IMdYCgQeNb+eT; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: 'SIMPLE mailing list' , 'Miguel Garcia' , 'Niemi Aki Petteri' 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: > I think the problem here is scope. > > Within a domain, you could have a nick service. AOL is a great example. > AOL could run a conference service, and use the same nicks. > > However, www.freeconferencing.com can also run a conference service, and it > may not have anything interesting in its domain other than a conference > service. > > Nicks are tricky, because of the uniqueness property. They are typically > short, which means collisions on self selected nicks. The bigger the > domain, the harder it is to maintain uniqueness. I've used brtech as a nick > for a couple decades, and in most domains, I don't have a problem getting > it. In AOL, I wasn't early enough; it was gone before AIM was available > outside the AOL paid service. Of course brtech(3) is unique from brtech(1) > and a temporary hack like that for uniqueness within a conference service > works fine. > > I think we couple a nick service to a domain, and not necessarily a > conference server. The conference server almost always has a subdomain in > which it runs the nick service, of course. I'm not sure I understand what you are saying. It seems clear that nicknames are only unique within the domain that assigns them. If they are of the @ format then the is only unique within the but the combination is globally unique within the scope that agrees on this definition. If it is a URI or URN then we understand its uniqueness. The issue is whether a conference server requires the nicknames to be from a particular domain. Maybe we can't legislate this completely, but I think we at least out to recommend that nicknames from arbitrary domains be supported. From a UI perspective there is a downside to allowing nicknames from arbitrary domains - the names are in general longer because they must carry the name of the domain. This is very much like what happened when mail services were first federated. It can be dealt with using a defaulting rule. The UI for access to the conference server can have a default domain. Nicknames in the default domain can have the domain name stripped off for presentation in the UI, and conversely on input. Paul > Brian > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, May 16, 2007 12:35 PM >> To: Bob Serr >> Cc: Brian Rosen; Miguel Garcia; Niemi Aki Petteri; SIMPLE mailing list >> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation >> >> The disadvantage of having the nickname as part of the conferencing >> server is that the scope of the nickname is tied to the scope of the >> conferencing server. >> >> For instance, suppose ietf maintained a conferencing server for use by >> the workgroups. I could have "paulk" as a nickname in that scope, for >> multiple conferences related to ietf things - sip, sipping, simple, etc. >> >> Then perhaps SIPforum might have a conference server for use by the >> things it handles, such as SIPit. If it managed its own nicknames, then >> I might or might not be able to get the nickname "paulk". Its possible >> that somebody else might get that nickname there. >> >> If the nickname anonymizer/provider could be independent of the >> conference server, then I could get >> paulk >> and use it as my identity in all of those conferences. Then people would >> know it was always the same person. With the nicknames coupled to the >> conf servers, even if I got "paulk" both places, people wouldn't >> necessarily know it was the same person. >> >> Paul >> >> Bob Serr wrote: >>> I agree that the nickname should be an additional feature, beyond AOR >>> and display name, and that the feature should be optional. It is a >>> requirement that a user be able to select users in a participant list >>> and click into other modalities. >>> >>> Regarding whether the nickname service is separate or part of the >>> conferencing server, it would be a simpler and easier to manage >>> architecture if it was part of the conferencing server. This will work >>> better in federated chat environments as it will be one less service >>> that you need to connect to in the federated environment. Additionally, >>> it will likely be the conferencing server, or even the >>> conference/room/channel that applies the policy about whether nicknames >>> are supported on the channel. For example, one room may allow anonymous >>> access while another may require that all user identities are known. >>> >>> Bob >>> >>> >>> >>> -----Original Message----- >>> From: Brian Rosen [mailto:br@brianrosen.net] >>> Sent: Wednesday, May 16, 2007 9:25 AM >>> To: 'Miguel Garcia'; 'Paul Kyzivat' >>> Cc: 'Niemi Aki Petteri'; 'SIMPLE mailing list' >>> Subject: RE: [Simple] MSRP chat: SIP-based nickname negotiation >>> >>> I think that a nickname is an unadorned "display name" thing. There >>> isn't >>> the displayname+user@domain combination as in an AoR. So I think a >>> display >>> name and a nickname are not the same thing, but there isn't both a >>> visual >>> and an addressing component of a nickname; there is just a nickname. >>> >>> My display name is usually "Brian Rosen". My nickname is "br" or >>> "brtech. >>> Those are very clearly different, and I agree with Miguel that we don't >>> want >>> to re-use the display name in an AoR. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >>>> Sent: Wednesday, May 16, 2007 6:27 AM >>>> To: Paul Kyzivat >>>> Cc: Brian Rosen; 'Niemi Aki Petteri'; 'SIMPLE mailing list' >>>> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation >>>> >>>> Paul Kyzivat wrote: >>>>> Is there really a requirement that a participant in a conference be >>> able >>>>> to have *two* *display names* - one for the AOR and one for the >>>>> nickname? I question this. >>>> > >>>> >>>> I think such requirement exists. Let's assume the following use case: >>> I >>>> am logged into a chat room, where I can see the list of participants, >>>> learned through a subscription to the (potentially extended with >>>> nicknames) conference event package. I can do a right click on a >>>> participant and I get a context sensitive menu. If the participant is >>>> anonymous, I can send a private message to him/her. If the participant >>>> has disclosed his URI, then in addition to sending a private message, >>> I >>>> can also save his SIP URI and other information in my phonebook or >>>> contacts application. I can also check his profile, I can check the >>>> capabilities of his SIP UA (by sending an OPTIONS). The OPTIONS could >>> be >>>> done automatically, so the UI could change the color if, for example, >>>> the response from the OPTIONS indicates that the participant supports >>>> audio and video. >>>> >>>> If we decide to hijack an existing header for describing nicknames, >>> then >>>> we will break all this use cases. For example, I could be storing a >>>> non-existent name or URI in my phonebook (if the user was anonymous). >>> Or >>>> if we decide to not disclose SIP URIs at all, then I wouldn't be able >>> to >>>> view profiles or query for capabilities. >>>> >>>> My conclusion is that the nickname is an additional feature that >>>> shouldn't override the existing headers and features. >>>> >>>> /Miguel >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Please note my new e-mail address: miguel.garcia at nsn.com >>>> Miguel A. Garcia tel:+358-50-4804586 >>>> Nokia Siemens Networks Helsinki, Finland >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 16 16:30:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoQ8o-0006dk-W4; Wed, 16 May 2007 16:30:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoQ8n-0006de-7Y for simple@ietf.org; Wed, 16 May 2007 16:30:33 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoQ8l-0001kN-KP for simple@ietf.org; Wed, 16 May 2007 16:30:33 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HoQ6w-0000Jr-Vq; Wed, 16 May 2007 15:28:39 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" References: <464056CA.1080209@nsn.com><464079FC.50704@cisco.com> <46407C8A.6030000@nsn.com><46409876.4030307@cisco.com> <46416BFF.5090105@nsn.com> <66cd252f0705090032q2b045180ya7a24cc1fd7a3fda@mail.gmail.com> <46417A9A.9030703@nsn.com><66cd252f0705090048g1071bdf8u4b78e12060051ea2@mail.gmail.com><46417DDA.9090000@nsn.com><4641B657.2010405@cisco.com> <4642C587.9040107@nsn.com><080501c795f3$09614670$e4003c0a@cis.neustar.com><4648177C.9020106@nsn.com> <464852C3.1030200@cisco.com><4649A281.2000901@nsn.com> <4649B933.3030007@cisco.com><464ADC81.7000501@nsn.com> <077901c797c6$042fd1b0$640fa8c0@cis.neustar.com> <3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp> <464B32A4.3000708@cisco.com> <07df01c797eb$93a7e0b0$640fa8c0@cis.neustar.com> <464B61F2.7060600@cisco.com> Subject: RE: [Simple] MSRP chat: SIP-based nickname negotiation Date: Wed, 16 May 2007 16:30:19 -0400 Message-ID: <087701c797f9$07ace250$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceX9Bhe9wrx1C9pTy+5hJ0Uv+EVZAAAurDw In-Reply-To: <464B61F2.7060600@cisco.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 - [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: 17bdfcaea25d1444baef0e24abc38874 Cc: 'SIMPLE mailing list' , 'Miguel Garcia' , 'Niemi Aki Petteri' 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 don't think we can do that. Nicks have to be short to be useful. Accepting any nick from any domain won't work (albeit a conference server can use the suffix idea to force them to be unique). I think, in the end, the nick has to be unique within the domain the conference server operates within, or at least declares (i.e. www.freeconferencing.com could demand an AOL screenname even if it's not an AOL domain). I don't think a nick is nick@domain, or at least we never see it that way. It is, of course, because if a nick is unique in a domain, then you need to know the domain as well as the nick, but the domain is implied, not explicit. The proposal circulating just has a way for a UA to declare its nick, with an error from the server that complains about non-uniqueness. I think that needs to be fleshed out some, because I do think having some kind of longer lived nick is useful. The mechanism to register a long lived nick need not directly tie to the conference nick declaration, and the conference server can always reject a nick not associated with an AoR that it knows (that is, if there is a registration of long lived nicks, it would be something a nick registrar does, and the conference server could ask the registrar if the asserted nick is the same as that associated with the AoR). So I think we can have two mechanisms. A way to register a long lived nick, and a way to assert a nick in a conference. Please remember that a nick is as useful in a two way IM exchange as it is in a chat room. I don't want to tie nicks to conference servers, just make them work as well there as in a simple IM pager mode or session. The assertion mechanism should work the same there as it does in a conference. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, May 16, 2007 3:57 PM > To: Brian Rosen > Cc: 'Bob Serr'; 'Miguel Garcia'; 'Niemi Aki Petteri'; 'SIMPLE mailing > list' > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > > > > Brian Rosen wrote: > > I think the problem here is scope. > > > > Within a domain, you could have a nick service. AOL is a great example. > > AOL could run a conference service, and use the same nicks. > > > > However, www.freeconferencing.com can also run a conference service, and > it > > may not have anything interesting in its domain other than a conference > > service. > > > > Nicks are tricky, because of the uniqueness property. They are > typically > > short, which means collisions on self selected nicks. The bigger the > > domain, the harder it is to maintain uniqueness. I've used brtech as a > nick > > for a couple decades, and in most domains, I don't have a problem > getting > > it. In AOL, I wasn't early enough; it was gone before AIM was available > > outside the AOL paid service. Of course brtech(3) is unique from > brtech(1) > > and a temporary hack like that for uniqueness within a conference > service > > works fine. > > > > I think we couple a nick service to a domain, and not necessarily a > > conference server. The conference server almost always has a subdomain > in > > which it runs the nick service, of course. > > I'm not sure I understand what you are saying. > > It seems clear that nicknames are only unique within the domain that > assigns them. If they are of the @ format then the is > only unique within the but the combination is globally unique > within the scope that agrees on this definition. If it is a URI or URN > then we understand its uniqueness. > > The issue is whether a conference server requires the nicknames to be > from a particular domain. Maybe we can't legislate this completely, but > I think we at least out to recommend that nicknames from arbitrary > domains be supported. > > From a UI perspective there is a downside to allowing nicknames from > arbitrary domains - the names are in general longer because they must > carry the name of the domain. This is very much like what happened when > mail services were first federated. It can be dealt with using a > defaulting rule. The UI for access to the conference server can have a > default domain. Nicknames in the default domain can have the domain name > stripped off for presentation in the UI, and conversely on input. > > Paul > > > Brian > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Wednesday, May 16, 2007 12:35 PM > >> To: Bob Serr > >> Cc: Brian Rosen; Miguel Garcia; Niemi Aki Petteri; SIMPLE mailing list > >> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > >> > >> The disadvantage of having the nickname as part of the conferencing > >> server is that the scope of the nickname is tied to the scope of the > >> conferencing server. > >> > >> For instance, suppose ietf maintained a conferencing server for use by > >> the workgroups. I could have "paulk" as a nickname in that scope, for > >> multiple conferences related to ietf things - sip, sipping, simple, > etc. > >> > >> Then perhaps SIPforum might have a conference server for use by the > >> things it handles, such as SIPit. If it managed its own nicknames, then > >> I might or might not be able to get the nickname "paulk". Its possible > >> that somebody else might get that nickname there. > >> > >> If the nickname anonymizer/provider could be independent of the > >> conference server, then I could get > >> paulk > >> and use it as my identity in all of those conferences. Then people > would > >> know it was always the same person. With the nicknames coupled to the > >> conf servers, even if I got "paulk" both places, people wouldn't > >> necessarily know it was the same person. > >> > >> Paul > >> > >> Bob Serr wrote: > >>> I agree that the nickname should be an additional feature, beyond AOR > >>> and display name, and that the feature should be optional. It is a > >>> requirement that a user be able to select users in a participant list > >>> and click into other modalities. > >>> > >>> Regarding whether the nickname service is separate or part of the > >>> conferencing server, it would be a simpler and easier to manage > >>> architecture if it was part of the conferencing server. This will work > >>> better in federated chat environments as it will be one less service > >>> that you need to connect to in the federated environment. > Additionally, > >>> it will likely be the conferencing server, or even the > >>> conference/room/channel that applies the policy about whether > nicknames > >>> are supported on the channel. For example, one room may allow > anonymous > >>> access while another may require that all user identities are known. > >>> > >>> Bob > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Brian Rosen [mailto:br@brianrosen.net] > >>> Sent: Wednesday, May 16, 2007 9:25 AM > >>> To: 'Miguel Garcia'; 'Paul Kyzivat' > >>> Cc: 'Niemi Aki Petteri'; 'SIMPLE mailing list' > >>> Subject: RE: [Simple] MSRP chat: SIP-based nickname negotiation > >>> > >>> I think that a nickname is an unadorned "display name" thing. There > >>> isn't > >>> the displayname+user@domain combination as in an AoR. So I think a > >>> display > >>> name and a nickname are not the same thing, but there isn't both a > >>> visual > >>> and an addressing component of a nickname; there is just a nickname. > >>> > >>> My display name is usually "Brian Rosen". My nickname is "br" or > >>> "brtech. > >>> Those are very clearly different, and I agree with Miguel that we > don't > >>> want > >>> to re-use the display name in an AoR. > >>> > >>> Brian > >>> > >>>> -----Original Message----- > >>>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > >>>> Sent: Wednesday, May 16, 2007 6:27 AM > >>>> To: Paul Kyzivat > >>>> Cc: Brian Rosen; 'Niemi Aki Petteri'; 'SIMPLE mailing list' > >>>> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > >>>> > >>>> Paul Kyzivat wrote: > >>>>> Is there really a requirement that a participant in a conference be > >>> able > >>>>> to have *two* *display names* - one for the AOR and one for the > >>>>> nickname? I question this. > >>>> > > >>>> > >>>> I think such requirement exists. Let's assume the following use case: > >>> I > >>>> am logged into a chat room, where I can see the list of participants, > >>>> learned through a subscription to the (potentially extended with > >>>> nicknames) conference event package. I can do a right click on a > >>>> participant and I get a context sensitive menu. If the participant is > >>>> anonymous, I can send a private message to him/her. If the > participant > >>>> has disclosed his URI, then in addition to sending a private message, > >>> I > >>>> can also save his SIP URI and other information in my phonebook or > >>>> contacts application. I can also check his profile, I can check the > >>>> capabilities of his SIP UA (by sending an OPTIONS). The OPTIONS could > >>> be > >>>> done automatically, so the UI could change the color if, for example, > >>>> the response from the OPTIONS indicates that the participant supports > >>>> audio and video. > >>>> > >>>> If we decide to hijack an existing header for describing nicknames, > >>> then > >>>> we will break all this use cases. For example, I could be storing a > >>>> non-existent name or URI in my phonebook (if the user was anonymous). > >>> Or > >>>> if we decide to not disclose SIP URIs at all, then I wouldn't be able > >>> to > >>>> view profiles or query for capabilities. > >>>> > >>>> My conclusion is that the nickname is an additional feature that > >>>> shouldn't override the existing headers and features. > >>>> > >>>> /Miguel > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Please note my new e-mail address: miguel.garcia at nsn.com > >>>> Miguel A. Garcia tel:+358-50-4804586 > >>>> Nokia Siemens Networks Helsinki, Finland > >>> > >>> _______________________________________________ > >>> Simple mailing list > >>> Simple@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/simple > >>> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 16 21:03: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 1HoUP8-0004GE-7w; Wed, 16 May 2007 21:03:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoUP6-0004G9-Ay for simple@ietf.org; Wed, 16 May 2007 21:03:40 -0400 Received: from wx-out-0506.google.com ([66.249.82.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoUP5-0000Gg-4l for simple@ietf.org; Wed, 16 May 2007 21:03:40 -0400 Received: by wx-out-0506.google.com with SMTP id h31so400677wxd for ; Wed, 16 May 2007 18:03:38 -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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Cht+fCK1WsmvFbZSbWRQYphYHg9FyZ/YIQYESpBWgaMQi1S3PuasMPeE4Y1iSepbDoRmfj1BMJvlv6GTxB9qOEaBWF/gFJpTaES4SZP+SPL+MzNGasy3OE6HH9VBGhXHg7BE3jc7byJknH9yIkwO7wTzYp4EzRybhfURMwLvEzo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=c/OfVKSZAquvK/oHx7fe0zf+iGhARj6us1brb331agNiMp+q21bBKoMuNECSVHxZ+IzIw5lhk+jBdsr40TjIhfsXq4kmiAWH386geoE/TGbobGqf6RZh2gcRzBni3/ykBaBHykO++oDpU6nL5q1OtcG890E89yjuhn68G5xnRZk= Received: by 10.90.97.11 with SMTP id u11mr9298256agb.1179363818923; Wed, 16 May 2007 18:03:38 -0700 (PDT) Received: by 10.65.113.16 with HTTP; Wed, 16 May 2007 18:03:38 -0700 (PDT) Message-ID: <66cd252f0705161803u5250073sfa468507f1fdd224@mail.gmail.com> Date: Thu, 17 May 2007 11:03:38 +1000 From: "Hisham Khartabil" To: "SIMPLE mailing list" Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation In-Reply-To: <087701c797f9$07ace250$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <464056CA.1080209@nsn.com> <4649A281.2000901@nsn.com> <4649B933.3030007@cisco.com> <464ADC81.7000501@nsn.com> <077901c797c6$042fd1b0$640fa8c0@cis.neustar.com> <3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp> <464B32A4.3000708@cisco.com> <07df01c797eb$93a7e0b0$640fa8c0@cis.neustar.com> <464B61F2.7060600@cisco.com> <087701c797f9$07ace250$640fa8c0@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 This discussion is great and helpful to the XCON folks. What we are doing in SIMPLE is a nickname service for an adhoc conference. In my opinion, the solution that Miguel and Aki are proposing in their draft is sufficient enough to satisfy the requirements of enabling a chatroom participant to suggest a nickname for himself/herself and get accepted into the chatroom or get rejected with a reason of conflict in nicknames. This is on a first come first server basis. If a domain wants to have the service where a user can have a unique nickname across chatrooms, then it is an implementation issue behind the scenes and does not require standardisation. If there are any other requirements, including nickname uniqueness across domains or the reservation of a nickname forever, I think they should go to XCON. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 16 21:58:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoVFj-00069a-Vj; Wed, 16 May 2007 21:58:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoVFi-00068V-MD for simple@ietf.org; Wed, 16 May 2007 21:58:02 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoVFh-0000R5-CP for simple@ietf.org; Wed, 16 May 2007 21:58:02 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HoVDw-0002aF-Tt; Wed, 16 May 2007 20:56:13 -0500 From: "Brian Rosen" To: "'Hisham Khartabil'" , "'SIMPLE mailing list'" References: <464056CA.1080209@nsn.com> <4649A281.2000901@nsn.com><4649B933.3030007@cisco.com> <464ADC81.7000501@nsn.com><077901c797c6$042fd1b0$640fa8c0@cis.neustar.com><3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp><464B32A4.3000708@cisco.com><07df01c797eb$93a7e0b0$640fa8c0@cis.neustar.com><464B61F2.7060600@cisco.com><087701c797f9$07ace250$640fa8c0@cis.neustar.com> <66cd252f0705161803u5250073sfa468507f1fdd224@mail.gmail.com> Subject: RE: [Simple] MSRP chat: SIP-based nickname negotiation Date: Wed, 16 May 2007 21:57:57 -0400 Message-ID: <008801c79826$cc735c40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceYHvpajwU9L/ERQbuL/BUzIfO21wABwNNQ In-reply-to: <66cd252f0705161803u5250073sfa468507f1fdd224@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 - [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: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I can see the registration of a persistent nick as outside the scope here. We could do some standardization, but we don't have to. However, we do need to standardize how a nick user "validates" the nick against the AoR, if that is what the domain wants to do. Nicks are not tied to conferences. They can be used in other circumstances. The validation operation can't be tied to a conference server. I don't really care which IETF work group does the work. In my experience, conferences are the least common use of nicks. Persistent nicks are much more common than temporary nicks. If we're going to bias solutions, we ought to bias them towards persistent, non conference nicks. It's not clear to me that we need such a bias. Brian > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > Sent: Wednesday, May 16, 2007 9:04 PM > To: SIMPLE mailing list > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > > This discussion is great and helpful to the XCON folks. What we are > doing in SIMPLE is a nickname service for an adhoc conference. In my > opinion, the solution that Miguel and Aki are proposing in their draft > is sufficient enough to satisfy the requirements of enabling a > chatroom participant to suggest a nickname for himself/herself and get > accepted into the chatroom or get rejected with a reason of conflict > in nicknames. This is on a first come first server basis. > > If a domain wants to have the service where a user can have a unique > nickname across chatrooms, then it is an implementation issue behind > the scenes and does not require standardisation. > > If there are any other requirements, including nickname uniqueness > across domains or the reservation of a nickname forever, I think they > should go to XCON. > > Regards, > Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu May 17 02:21:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoZLy-0004CV-5p; Thu, 17 May 2007 02:20:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoZLx-0004CP-85 for simple@ietf.org; Thu, 17 May 2007 02:20:45 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoZLu-0006fK-6m for simple@ietf.org; Thu, 17 May 2007 02:20:45 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4614220974; Thu, 17 May 2007 08:20:41 +0200 (CEST) X-AuditID: c1b4fb3c-aacefbb0000073d5-f5-464bf4390196 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2ADB8204D8; Thu, 17 May 2007 08:20:41 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 08:20:40 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 08:20:40 +0200 Received: from [131.160.126.214] (rvi2-126-214.lmf.ericsson.se [131.160.126.214]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 66ACB246F; Thu, 17 May 2007 09:20:40 +0300 (EEST) Message-ID: <464BF437.3020000@ericsson.com> Date: Thu, 17 May 2007 09:20:39 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <4649A281.2000901@nsn.com> <4649B933.3030007@cisco.com> <464ADC81.7000501@nsn.com> <077901c797c6$042fd1b0$640fa8c0@cis.neustar.com> <3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp> <464B32A4.3000708@cisco.com> <07df01c797eb$93a7e0b0$640fa8c0@cis.neustar.com> <464B61F2.7060600@cisco.com> <087701c797f9$07ace250$640fa8c0@cis.neustar.com> <66cd252f0705161803u5250073sfa468507f1fdd224@mail.gmail.com> In-Reply-To: <66cd252f0705161803u5250073sfa468507f1fdd224@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2007 06:20:40.0849 (UTC) FILETIME=[7E12F810:01C7984B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: SIMPLE mailing list 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 Hisham, I'll send a note to XCON in case they missed this thread (some of them may not be subscribed to SIMPLE). I agree it is relevant to what XCON is doing. Cheers, Gonzalo Hisham Khartabil wrote: > This discussion is great and helpful to the XCON folks. What we are > doing in SIMPLE is a nickname service for an adhoc conference. In my > opinion, the solution that Miguel and Aki are proposing in their draft > is sufficient enough to satisfy the requirements of enabling a > chatroom participant to suggest a nickname for himself/herself and get > accepted into the chatroom or get rejected with a reason of conflict > in nicknames. This is on a first come first server basis. > > If a domain wants to have the service where a user can have a unique > nickname across chatrooms, then it is an implementation issue behind > the scenes and does not require standardisation. > > If there are any other requirements, including nickname uniqueness > across domains or the reservation of a nickname forever, I think they > should go to XCON. > > Regards, > Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu May 17 02:25:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoZQr-0007cv-Si; Thu, 17 May 2007 02:25:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoZQq-0007cq-Gx for simple@ietf.org; Thu, 17 May 2007 02:25:48 -0400 Received: from nz-out-0506.google.com ([64.233.162.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoZQq-0007i8-8W for simple@ietf.org; Thu, 17 May 2007 02:25:48 -0400 Received: by nz-out-0506.google.com with SMTP id z6so894489nzd for ; Wed, 16 May 2007 23:25:48 -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:content-transfer-encoding:content-disposition:references; b=tlli6XvL4/r4v1LOqLF6QdCt1iSGgiqvK0KK9tKE9aBCTBwvf3K0rnf8STLKKexK28sC9f6z6OIkGdTJQk7mV86aOF7mkPw1+KA9W1tYrhNEVMq8Knrj2NBQMlUTItcQin218/0e8D6TzWeDDJtB6qKpf+Nf8sOkOB1olRSRwvE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eGTckQWsLdsDG9/6i1KHZXPraELrsoIKBOLJrvs4iOXtup2iR8tm9Lr9JHZuNdPrbGezty1/seH+TJJRfjYrpM9NVffNCpEtiZ6oPDquy0GAul8tRVYUZE4+VTmB5cZfuXEZpJoyS7Bi64PspB5+ZzJVj8IIsa9z9mJsgyQpisU= Received: by 10.65.139.9 with SMTP id r9mr1353442qbn.1179383147907; Wed, 16 May 2007 23:25:47 -0700 (PDT) Received: by 10.65.113.16 with HTTP; Wed, 16 May 2007 23:25:47 -0700 (PDT) Message-ID: <66cd252f0705162325s21d5cdfarc6632803539abfc6@mail.gmail.com> Date: Thu, 17 May 2007 16:25:47 +1000 From: "Hisham Khartabil" To: "Brian Rosen" Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation In-Reply-To: <008801c79826$cc735c40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <464056CA.1080209@nsn.com> <464ADC81.7000501@nsn.com> <077901c797c6$042fd1b0$640fa8c0@cis.neustar.com> <3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp> <464B32A4.3000708@cisco.com> <07df01c797eb$93a7e0b0$640fa8c0@cis.neustar.com> <464B61F2.7060600@cisco.com> <087701c797f9$07ace250$640fa8c0@cis.neustar.com> <66cd252f0705161803u5250073sfa468507f1fdd224@mail.gmail.com> <008801c79826$cc735c40$640fa8c0@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: SIMPLE mailing list 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, What we are doing in SIMPLE is specific to IM chat service (hence the name of the draft). My opinion is that whatever is in the draft is sufficient. Hisham On 17/05/07, Brian Rosen wrote: > I can see the registration of a persistent nick as outside the scope here. > We could do some standardization, but we don't have to. > > However, we do need to standardize how a nick user "validates" the nick > against the AoR, if that is what the domain wants to do. > > Nicks are not tied to conferences. They can be used in other circumstances. > The validation operation can't be tied to a conference server. I don't > really care which IETF work group does the work. > > In my experience, conferences are the least common use of nicks. Persistent > nicks are much more common than temporary nicks. If we're going to bias > solutions, we ought to bias them towards persistent, non conference nicks. > It's not clear to me that we need such a bias. > > Brian > > > -----Original Message----- > > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > > Sent: Wednesday, May 16, 2007 9:04 PM > > To: SIMPLE mailing list > > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > > > > This discussion is great and helpful to the XCON folks. What we are > > doing in SIMPLE is a nickname service for an adhoc conference. In my > > opinion, the solution that Miguel and Aki are proposing in their draft > > is sufficient enough to satisfy the requirements of enabling a > > chatroom participant to suggest a nickname for himself/herself and get > > accepted into the chatroom or get rejected with a reason of conflict > > in nicknames. This is on a first come first server basis. > > > > If a domain wants to have the service where a user can have a unique > > nickname across chatrooms, then it is an implementation issue behind > > the scenes and does not require standardisation. > > > > If there are any other requirements, including nickname uniqueness > > across domains or the reservation of a nickname forever, I think they > > should go to XCON. > > > > Regards, > > Hisham > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu May 17 08:35: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 1HofCI-0004Yt-0L; Thu, 17 May 2007 08:35:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HofCG-0004Yl-Bs for simple@ietf.org; Thu, 17 May 2007 08:35:08 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HofCF-00053d-0K for simple@ietf.org; Thu, 17 May 2007 08:35:08 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HofAN-0005BQ-IU; Thu, 17 May 2007 07:33:11 -0500 From: "Brian Rosen" To: "'Hisham Khartabil'" References: <464056CA.1080209@nsn.com> <464ADC81.7000501@nsn.com> <077901c797c6$042fd1b0$640fa8c0@cis.neustar.com> <3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp> <464B32A4.3000708@cisco.com> <07df01c797eb$93a7e0b0$640fa8c0@cis.neustar.com> <464B61F2.7060600@cisco.com> <087701c797f9$07ace250$640fa8c0@cis.neustar.com> <66cd252f0705161803u5250073sfa468507f1fdd224@mail.gmail.com> <008801c79826$cc735c40$640fa8c0@cis.neustar.com> <66cd252f0705162325s21d5cdfarc6632803539abfc6@mail.gmail.com> Subject: RE: [Simple] MSRP chat: SIP-based nickname negotiation Date: Thu, 17 May 2007 08:35:03 -0400 Message-ID: <018001c7987f$ccb745a0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceYS/THBIAyv14QR+SD4swYaYTfXQAM07QA In-reply-to: <66cd252f0705162325s21d5cdfarc6632803539abfc6@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 - [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: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: 'SIMPLE mailing list' 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 Hisham Do you think it would be wise for, let's say, a presence system which uses nicknames have a different mechanism for informing its service of its nickname than it would use for an IM chat? Should the XCON mechanism be different? I don't want to make this into a big deal, but nicknames are not peculiar to IM chat. I don't want an IM chat specific solution, especially when I don't think we need a whole lot more than is proposed. I think we need SOME more to make a generalized nickname feasible. Persistent nicks within a domain is one of the big differences. Brian > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > Sent: Thursday, May 17, 2007 2:26 AM > To: Brian Rosen > Cc: SIMPLE mailing list > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > > Brian, > > What we are doing in SIMPLE is specific to IM chat service (hence the > name of the draft). My opinion is that whatever is in the draft is > sufficient. > > Hisham > > On 17/05/07, Brian Rosen wrote: > > I can see the registration of a persistent nick as outside the scope > here. > > We could do some standardization, but we don't have to. > > > > However, we do need to standardize how a nick user "validates" the nick > > against the AoR, if that is what the domain wants to do. > > > > Nicks are not tied to conferences. They can be used in other > circumstances. > > The validation operation can't be tied to a conference server. I don't > > really care which IETF work group does the work. > > > > In my experience, conferences are the least common use of nicks. > Persistent > > nicks are much more common than temporary nicks. If we're going to bias > > solutions, we ought to bias them towards persistent, non conference > nicks. > > It's not clear to me that we need such a bias. > > > > Brian > > > > > -----Original Message----- > > > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > > > Sent: Wednesday, May 16, 2007 9:04 PM > > > To: SIMPLE mailing list > > > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > > > > > > This discussion is great and helpful to the XCON folks. What we are > > > doing in SIMPLE is a nickname service for an adhoc conference. In my > > > opinion, the solution that Miguel and Aki are proposing in their draft > > > is sufficient enough to satisfy the requirements of enabling a > > > chatroom participant to suggest a nickname for himself/herself and get > > > accepted into the chatroom or get rejected with a reason of conflict > > > in nicknames. This is on a first come first server basis. > > > > > > If a domain wants to have the service where a user can have a unique > > > nickname across chatrooms, then it is an implementation issue behind > > > the scenes and does not require standardisation. > > > > > > If there are any other requirements, including nickname uniqueness > > > across domains or the reservation of a nickname forever, I think they > > > should go to XCON. > > > > > > Regards, > > > Hisham > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu May 17 09:28:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hog1y-0008F4-TD; Thu, 17 May 2007 09:28:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hog1x-0008Ew-UU for simple@ietf.org; Thu, 17 May 2007 09:28:33 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hog1w-0003ea-Ey for simple@ietf.org; Thu, 17 May 2007 09:28:33 -0400 Received: by py-out-1112.google.com with SMTP id f31so820996pyh for ; Thu, 17 May 2007 06:28:31 -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:content-transfer-encoding:content-disposition:references; b=qtXDwkc5sHh8tRAnQuHqxxIA7a9PL3nQE+pBNxIZeyPhPior36Zom/oKNpTzo8Pf110fg9/OLJTzFjZOhI99yBcuHKVp1O0dIKjTO47pDVfj6vazYl5WDG3G37kRGCzZuP39l4+6GfxT2OPVCCIFFd02NudhdEx4YGRdChHHDyk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=asliAzDA2SQUzLqXMV9/o6MrA14gmUW9f3GKuxg9NEb21FgMgbL0WJpabqourwd8r0gp2Ej5oLjhzQJqsy4L7ulEk49dkXOVK72fSxUvjoZVSn8N+0BVAzWdqqhpjoHqUBiBsCDEvrKk5X64LWg2Q1dBFQKyPUWobWo+Ila+ga4= Received: by 10.65.59.11 with SMTP id m11mr4132890qbk.1179408510927; Thu, 17 May 2007 06:28:30 -0700 (PDT) Received: by 10.65.113.16 with HTTP; Thu, 17 May 2007 06:28:30 -0700 (PDT) Message-ID: <66cd252f0705170628w4c6bef8an898b049de75e238e@mail.gmail.com> Date: Thu, 17 May 2007 23:28:30 +1000 From: "Hisham Khartabil" To: "Brian Rosen" Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation In-Reply-To: <018001c7987f$ccb745a0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <464056CA.1080209@nsn.com> <3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp> <464B32A4.3000708@cisco.com> <07df01c797eb$93a7e0b0$640fa8c0@cis.neustar.com> <464B61F2.7060600@cisco.com> <087701c797f9$07ace250$640fa8c0@cis.neustar.com> <66cd252f0705161803u5250073sfa468507f1fdd224@mail.gmail.com> <008801c79826$cc735c40$640fa8c0@cis.neustar.com> <66cd252f0705162325s21d5cdfarc6632803539abfc6@mail.gmail.com> <018001c7987f$ccb745a0$640fa8c0@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: SIMPLE mailing list 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 Brain, Thats fair enough. Why don't you get with Miguel and Aki and add some text to the draft that makes it a generalised mechanism. I believe Miguel are Aki are more than happy to make you a co-author of this draft. Hisham On 17/05/07, Brian Rosen wrote: > Hisham > > Do you think it would be wise for, let's say, a presence system which uses > nicknames have a different mechanism for informing its service of its > nickname than it would use for an IM chat? > > Should the XCON mechanism be different? > > I don't want to make this into a big deal, but nicknames are not peculiar to > IM chat. I don't want an IM chat specific solution, especially when I don't > think we need a whole lot more than is proposed. I think we need SOME more > to make a generalized nickname feasible. Persistent nicks within a domain > is one of the big differences. > > Brian > > > -----Original Message----- > > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > > Sent: Thursday, May 17, 2007 2:26 AM > > To: Brian Rosen > > Cc: SIMPLE mailing list > > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > > > > Brian, > > > > What we are doing in SIMPLE is specific to IM chat service (hence the > > name of the draft). My opinion is that whatever is in the draft is > > sufficient. > > > > Hisham > > > > On 17/05/07, Brian Rosen wrote: > > > I can see the registration of a persistent nick as outside the scope > > here. > > > We could do some standardization, but we don't have to. > > > > > > However, we do need to standardize how a nick user "validates" the nick > > > against the AoR, if that is what the domain wants to do. > > > > > > Nicks are not tied to conferences. They can be used in other > > circumstances. > > > The validation operation can't be tied to a conference server. I don't > > > really care which IETF work group does the work. > > > > > > In my experience, conferences are the least common use of nicks. > > Persistent > > > nicks are much more common than temporary nicks. If we're going to bias > > > solutions, we ought to bias them towards persistent, non conference > > nicks. > > > It's not clear to me that we need such a bias. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > > > > Sent: Wednesday, May 16, 2007 9:04 PM > > > > To: SIMPLE mailing list > > > > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > > > > > > > > This discussion is great and helpful to the XCON folks. What we are > > > > doing in SIMPLE is a nickname service for an adhoc conference. In my > > > > opinion, the solution that Miguel and Aki are proposing in their draft > > > > is sufficient enough to satisfy the requirements of enabling a > > > > chatroom participant to suggest a nickname for himself/herself and get > > > > accepted into the chatroom or get rejected with a reason of conflict > > > > in nicknames. This is on a first come first server basis. > > > > > > > > If a domain wants to have the service where a user can have a unique > > > > nickname across chatrooms, then it is an implementation issue behind > > > > the scenes and does not require standardisation. > > > > > > > > If there are any other requirements, including nickname uniqueness > > > > across domains or the reservation of a nickname forever, I think they > > > > should go to XCON. > > > > > > > > Regards, > > > > Hisham > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri May 18 05:57:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HozCl-00076Z-6j; Fri, 18 May 2007 05:56:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HozCk-00076U-4k for simple@ietf.org; Fri, 18 May 2007 05:56:58 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HozCi-0002IW-09 for simple@ietf.org; Fri, 18 May 2007 05:56:58 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4C33F2114A; Fri, 18 May 2007 11:56:55 +0200 (CEST) X-AuditID: c1b4fb3e-b01efbb0000061ca-b1-464d786771ed Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2C58221061; Fri, 18 May 2007 11:56:55 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 11:56:54 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 11:56:54 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2073C25F9; Fri, 18 May 2007 12:56:54 +0300 (EEST) Message-ID: <464D7864.3090608@ericsson.com> Date: Fri, 18 May 2007 12:56:52 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp> <464B32A4.3000708@cisco.com> <07df01c797eb$93a7e0b0$640fa8c0@cis.neustar.com> <464B61F2.7060600@cisco.com> <087701c797f9$07ace250$640fa8c0@cis.neustar.com> <66cd252f0705161803u5250073sfa468507f1fdd224@mail.gmail.com> <008801c79826$cc735c40$640fa8c0@cis.neustar.com> <66cd252f0705162325s21d5cdfarc6632803539abfc6@mail.gmail.com> <018001c7987f$ccb745a0$640fa8c0@cis.neustar.com> <66cd252f0705170628w4c6bef8an898b049de75e238e@mail.gmail.com> In-Reply-To: <66cd252f0705170628w4c6bef8an898b049de75e238e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2007 09:56:54.0367 (UTC) FILETIME=[DD4E76F0:01C79932] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: SIMPLE mailing list 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, regarding the scope of this work, my understanding was that SIMPLE was going to come up with an MRSP-specific solution for nicknames. A general solution for nicknames would be developed by XCON (SIP might be to be involved as well if SIP extensions were needed) at a later stage. Therefore, the only requirement on the MSRP-specific solution would be that it is future-proof so that it does not keep us from developing a more general (while being backwards compatible) one in the future. If my understanding of the process is correct, let's get the MSRP-specific solution finished and let's discuss the more general one somewhere else (e.g., XCON). If, on the other hand, this is not the process we want to follow, I would appreciate if somebody could clarify what our plan is. Thanks, Gonzalo Hisham Khartabil wrote: > Brain, > > Thats fair enough. Why don't you get with Miguel and Aki and add some > text to the draft that makes it a generalised mechanism. I believe > Miguel are Aki are more than happy to make you a co-author of this > draft. > > Hisham > > On 17/05/07, Brian Rosen wrote: >> Hisham >> >> Do you think it would be wise for, let's say, a presence system which >> uses >> nicknames have a different mechanism for informing its service of its >> nickname than it would use for an IM chat? >> >> Should the XCON mechanism be different? >> >> I don't want to make this into a big deal, but nicknames are not >> peculiar to >> IM chat. I don't want an IM chat specific solution, especially when I >> don't >> think we need a whole lot more than is proposed. I think we need SOME >> more >> to make a generalized nickname feasible. Persistent nicks within a >> domain >> is one of the big differences. >> >> Brian >> >> > -----Original Message----- >> > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] >> > Sent: Thursday, May 17, 2007 2:26 AM >> > To: Brian Rosen >> > Cc: SIMPLE mailing list >> > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation >> > >> > Brian, >> > >> > What we are doing in SIMPLE is specific to IM chat service (hence the >> > name of the draft). My opinion is that whatever is in the draft is >> > sufficient. >> > >> > Hisham >> > >> > On 17/05/07, Brian Rosen wrote: >> > > I can see the registration of a persistent nick as outside the scope >> > here. >> > > We could do some standardization, but we don't have to. >> > > >> > > However, we do need to standardize how a nick user "validates" the >> nick >> > > against the AoR, if that is what the domain wants to do. >> > > >> > > Nicks are not tied to conferences. They can be used in other >> > circumstances. >> > > The validation operation can't be tied to a conference server. I >> don't >> > > really care which IETF work group does the work. >> > > >> > > In my experience, conferences are the least common use of nicks. >> > Persistent >> > > nicks are much more common than temporary nicks. If we're going >> to bias >> > > solutions, we ought to bias them towards persistent, non conference >> > nicks. >> > > It's not clear to me that we need such a bias. >> > > >> > > Brian >> > > >> > > > -----Original Message----- >> > > > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] >> > > > Sent: Wednesday, May 16, 2007 9:04 PM >> > > > To: SIMPLE mailing list >> > > > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation >> > > > >> > > > This discussion is great and helpful to the XCON folks. What we are >> > > > doing in SIMPLE is a nickname service for an adhoc conference. >> In my >> > > > opinion, the solution that Miguel and Aki are proposing in their >> draft >> > > > is sufficient enough to satisfy the requirements of enabling a >> > > > chatroom participant to suggest a nickname for himself/herself >> and get >> > > > accepted into the chatroom or get rejected with a reason of >> conflict >> > > > in nicknames. This is on a first come first server basis. >> > > > >> > > > If a domain wants to have the service where a user can have a >> unique >> > > > nickname across chatrooms, then it is an implementation issue >> behind >> > > > the scenes and does not require standardisation. >> > > > >> > > > If there are any other requirements, including nickname uniqueness >> > > > across domains or the reservation of a nickname forever, I think >> they >> > > > should go to XCON. >> > > > >> > > > Regards, >> > > > Hisham >> > > > >> > > > _______________________________________________ >> > > > Simple mailing list >> > > > Simple@ietf.org >> > > > https://www1.ietf.org/mailman/listinfo/simple >> > > >> > > >> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri May 18 07:36:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp0kf-0006RJ-3k; Fri, 18 May 2007 07:36:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp0kd-0006R0-Aj for simple@ietf.org; Fri, 18 May 2007 07:36:03 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp0kc-0001RR-Se for simple@ietf.org; Fri, 18 May 2007 07:36:03 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hp0iV-0008Um-Oq; Fri, 18 May 2007 06:33:51 -0500 From: "Brian Rosen" To: "'Gonzalo Camarillo'" , "'Hisham Khartabil'" References: <464056CA.1080209@nsn.com> <3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp> <464B32A4.3000708@cisco.com> <07df01c797eb$93a7e0b0$640fa8c0@cis.neustar.com> <464B61F2.7060600@cisco.com> <087701c797f9$07ace250$640fa8c0@cis.neustar.com> <66cd252f0705161803u5250073sfa468507f1fdd224@mail.gmail.com> <008801c79826$cc735c40$640fa8c0@cis.neustar.com> <66cd252f0705162325s21d5cdfarc6632803539abfc6@mail.gmail.com> <018001c7987f$ccb745a0$640fa8c0@cis.neustar.com> <66cd252f0705170628w4c6bef8an898b049de75e238e@mail.gmail.com> <464D7864.3090608@ericsson.com> Subject: RE: [Simple] MSRP chat: SIP-based nickname negotiation Date: Fri, 18 May 2007 07:35:57 -0400 Message-ID: <054901c79940$b5c43580$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceZMpRe9Pfo5XzLT422mWhiwlKz9wADQmtw In-reply-to: <464D7864.3090608@ericsson.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 - [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: 0cff8c3ec906d056784362c06f5f88c1 Cc: 'SIMPLE mailing list' 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 Gonzalo I don't want an MSRP specific solution. I don't want an XCON solution. I want a SIP/IM/Presence/XCON... solution. Nicknames are a common thing. The most common nicknames are things like AOL screen names. They are persistent, unique within a domain, and used with all forms of communication. Per chat temporary nicks happen to us techies that use things like IRC, not to the real world. I think this is a simple problem, with simple solutions. I think it's reasonably a SIMPLE problem, with possibly some SIP work for a header. I think we can first apply it to MSRP chat and expand it to XCON. The proposal on the table needs only a little work, I think, to make it generally useful. I do think we need to agree on requirements first, but we seem to be coalescing fairly rapidly on that. Brian > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Friday, May 18, 2007 5:57 AM > To: Hisham Khartabil > Cc: Brian Rosen; SIMPLE mailing list > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > > Hi, > > regarding the scope of this work, my understanding was that SIMPLE was > going to come up with an MRSP-specific solution for nicknames. A general > solution for nicknames would be developed by XCON (SIP might be to be > involved as well if SIP extensions were needed) at a later stage. > > Therefore, the only requirement on the MSRP-specific solution would be > that it is future-proof so that it does not keep us from developing a > more general (while being backwards compatible) one in the future. > > If my understanding of the process is correct, let's get the > MSRP-specific solution finished and let's discuss the more general one > somewhere else (e.g., XCON). If, on the other hand, this is not the > process we want to follow, I would appreciate if somebody could clarify > what our plan is. > > Thanks, > > Gonzalo > > > > > Hisham Khartabil wrote: > > Brain, > > > > Thats fair enough. Why don't you get with Miguel and Aki and add some > > text to the draft that makes it a generalised mechanism. I believe > > Miguel are Aki are more than happy to make you a co-author of this > > draft. > > > > Hisham > > > > On 17/05/07, Brian Rosen wrote: > >> Hisham > >> > >> Do you think it would be wise for, let's say, a presence system which > >> uses > >> nicknames have a different mechanism for informing its service of its > >> nickname than it would use for an IM chat? > >> > >> Should the XCON mechanism be different? > >> > >> I don't want to make this into a big deal, but nicknames are not > >> peculiar to > >> IM chat. I don't want an IM chat specific solution, especially when I > >> don't > >> think we need a whole lot more than is proposed. I think we need SOME > >> more > >> to make a generalized nickname feasible. Persistent nicks within a > >> domain > >> is one of the big differences. > >> > >> Brian > >> > >> > -----Original Message----- > >> > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > >> > Sent: Thursday, May 17, 2007 2:26 AM > >> > To: Brian Rosen > >> > Cc: SIMPLE mailing list > >> > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > >> > > >> > Brian, > >> > > >> > What we are doing in SIMPLE is specific to IM chat service (hence the > >> > name of the draft). My opinion is that whatever is in the draft is > >> > sufficient. > >> > > >> > Hisham > >> > > >> > On 17/05/07, Brian Rosen wrote: > >> > > I can see the registration of a persistent nick as outside the > scope > >> > here. > >> > > We could do some standardization, but we don't have to. > >> > > > >> > > However, we do need to standardize how a nick user "validates" the > >> nick > >> > > against the AoR, if that is what the domain wants to do. > >> > > > >> > > Nicks are not tied to conferences. They can be used in other > >> > circumstances. > >> > > The validation operation can't be tied to a conference server. I > >> don't > >> > > really care which IETF work group does the work. > >> > > > >> > > In my experience, conferences are the least common use of nicks. > >> > Persistent > >> > > nicks are much more common than temporary nicks. If we're going > >> to bias > >> > > solutions, we ought to bias them towards persistent, non conference > >> > nicks. > >> > > It's not clear to me that we need such a bias. > >> > > > >> > > Brian > >> > > > >> > > > -----Original Message----- > >> > > > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > >> > > > Sent: Wednesday, May 16, 2007 9:04 PM > >> > > > To: SIMPLE mailing list > >> > > > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > >> > > > > >> > > > This discussion is great and helpful to the XCON folks. What we > are > >> > > > doing in SIMPLE is a nickname service for an adhoc conference. > >> In my > >> > > > opinion, the solution that Miguel and Aki are proposing in their > >> draft > >> > > > is sufficient enough to satisfy the requirements of enabling a > >> > > > chatroom participant to suggest a nickname for himself/herself > >> and get > >> > > > accepted into the chatroom or get rejected with a reason of > >> conflict > >> > > > in nicknames. This is on a first come first server basis. > >> > > > > >> > > > If a domain wants to have the service where a user can have a > >> unique > >> > > > nickname across chatrooms, then it is an implementation issue > >> behind > >> > > > the scenes and does not require standardisation. > >> > > > > >> > > > If there are any other requirements, including nickname > uniqueness > >> > > > across domains or the reservation of a nickname forever, I think > >> they > >> > > > should go to XCON. > >> > > > > >> > > > Regards, > >> > > > Hisham > >> > > > > >> > > > _______________________________________________ > >> > > > Simple mailing list > >> > > > Simple@ietf.org > >> > > > https://www1.ietf.org/mailman/listinfo/simple > >> > > > >> > > > >> > >> > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri May 18 10:17:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp3GQ-0005Bh-E5; Fri, 18 May 2007 10:17:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp3GO-0005BW-3l for simple@ietf.org; Fri, 18 May 2007 10:17:01 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp3GN-0003cH-JS for simple@ietf.org; Fri, 18 May 2007 10:17:00 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 May 2007 10:16:59 -0400 X-IronPort-AV: i="4.14,552,1170651600"; d="scan'208"; a="121474540:sNHT154498914" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4IEGxRZ032763; Fri, 18 May 2007 10:16:59 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4IEGq63020209; Fri, 18 May 2007 14:16:59 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 10:16:43 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 10:16:42 -0400 Message-ID: <464DB54A.9000403@cisco.com> Date: Fri, 18 May 2007 10:16:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp> <464B32A4.3000708@cisco.com> <07df01c797eb$93a7e0b0$640fa8c0@cis.neustar.com> <464B61F2.7060600@cisco.com> <087701c797f9$07ace250$640fa8c0@cis.neustar.com> <66cd252f0705161803u5250073sfa468507f1fdd224@mail.gmail.com> <008801c79826$cc735c40$640fa8c0@cis.neustar.com> <66cd252f0705162325s21d5cdfarc6632803539abfc6@mail.gmail.com> <018001c7987f$ccb745a0$640fa8c0@cis.neustar.com> <66cd252f0705170628w4c6bef8an898b049de75e238e@mail.gmail.com> <464D7864.3090608@ericsson.com> <054901c79940$b5c43580$640fa8c0@cis.neustar.com> In-Reply-To: <054901c79940$b5c43580$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2007 14:16:42.0929 (UTC) FILETIME=[28D04210:01C79957] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7630; t=1179497819; x=1180361819; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20MSRP=20chat=3A=20SIP-based=20nickname=20ne gotiation |Sender:=20 |To:=20Brian=20Rosen=20; bh=jAJOub/p2msOYUMfdR8A6QwbK59beDBVx04dxhBNDr0=; b=fxerDu9TS6wAxBUzieRpknSdGW+zNN1m2wzYVsKfJQRJ/3fp271hFIRK5ktfOboDqagk2eiQ AtsIcW/EWlo1/FM3HPmi+2H48tfiVDS6h9NB/LTrfWE0DGvZYTr1vuGN; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: 'SIMPLE mailing list' , 'Gonzalo Camarillo' 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: > Gonzalo > > I don't want an MSRP specific solution. I don't want an XCON solution. I > want a SIP/IM/Presence/XCON... solution. Nicknames are a common thing. Right. > The most common nicknames are things like AOL screen names. They are > persistent, unique within a domain, and used with all forms of > communication. I agree with what you say here about the prior art. But I have difficulty relating the "unique within a domain" part to what we are doing. That works for AOL because all communications, even the point to point kind, are mediated by a server in the AOL domain. Both ends share that domain and so the nickname namespace. That fits with what the current proposal is, because it applies only to conferences, where again there is a common server mediating all communications. But it doesn't generalize to the broader scope that you and I aspire to. In particular it doesn't generalize to point to point communications. The real world is also more complex than this when you get to multiple providers. For instance I use a Gaim IM client, with connections to AOL and to a corporate Sametime server. The namespace for nicknames/screen-names is separate for the two domains but must be resolved in the client UI. IMO the general solution must tag nicknames with their domain. That isn't so friendly if the domain shows up in the UI, but neither is it awful. It can be made better by a UI that does defaulting of the domain part of the nickname in a reasonable way. Paul > Per chat temporary nicks happen to us techies that use > things like IRC, not to the real world. > > I think this is a simple problem, with simple solutions. I think it's > reasonably a SIMPLE problem, with possibly some SIP work for a header. I > think we can first apply it to MSRP chat and expand it to XCON. > > The proposal on the table needs only a little work, I think, to make it > generally useful. I do think we need to agree on requirements first, but we > seem to be coalescing fairly rapidly on that. > > Brian > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Friday, May 18, 2007 5:57 AM >> To: Hisham Khartabil >> Cc: Brian Rosen; SIMPLE mailing list >> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation >> >> Hi, >> >> regarding the scope of this work, my understanding was that SIMPLE was >> going to come up with an MRSP-specific solution for nicknames. A general >> solution for nicknames would be developed by XCON (SIP might be to be >> involved as well if SIP extensions were needed) at a later stage. >> >> Therefore, the only requirement on the MSRP-specific solution would be >> that it is future-proof so that it does not keep us from developing a >> more general (while being backwards compatible) one in the future. >> >> If my understanding of the process is correct, let's get the >> MSRP-specific solution finished and let's discuss the more general one >> somewhere else (e.g., XCON). If, on the other hand, this is not the >> process we want to follow, I would appreciate if somebody could clarify >> what our plan is. >> >> Thanks, >> >> Gonzalo >> >> >> >> >> Hisham Khartabil wrote: >>> Brain, >>> >>> Thats fair enough. Why don't you get with Miguel and Aki and add some >>> text to the draft that makes it a generalised mechanism. I believe >>> Miguel are Aki are more than happy to make you a co-author of this >>> draft. >>> >>> Hisham >>> >>> On 17/05/07, Brian Rosen wrote: >>>> Hisham >>>> >>>> Do you think it would be wise for, let's say, a presence system which >>>> uses >>>> nicknames have a different mechanism for informing its service of its >>>> nickname than it would use for an IM chat? >>>> >>>> Should the XCON mechanism be different? >>>> >>>> I don't want to make this into a big deal, but nicknames are not >>>> peculiar to >>>> IM chat. I don't want an IM chat specific solution, especially when I >>>> don't >>>> think we need a whole lot more than is proposed. I think we need SOME >>>> more >>>> to make a generalized nickname feasible. Persistent nicks within a >>>> domain >>>> is one of the big differences. >>>> >>>> Brian >>>> >>>>> -----Original Message----- >>>>> From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] >>>>> Sent: Thursday, May 17, 2007 2:26 AM >>>>> To: Brian Rosen >>>>> Cc: SIMPLE mailing list >>>>> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation >>>>> >>>>> Brian, >>>>> >>>>> What we are doing in SIMPLE is specific to IM chat service (hence the >>>>> name of the draft). My opinion is that whatever is in the draft is >>>>> sufficient. >>>>> >>>>> Hisham >>>>> >>>>> On 17/05/07, Brian Rosen wrote: >>>>>> I can see the registration of a persistent nick as outside the >> scope >>>>> here. >>>>>> We could do some standardization, but we don't have to. >>>>>> >>>>>> However, we do need to standardize how a nick user "validates" the >>>> nick >>>>>> against the AoR, if that is what the domain wants to do. >>>>>> >>>>>> Nicks are not tied to conferences. They can be used in other >>>>> circumstances. >>>>>> The validation operation can't be tied to a conference server. I >>>> don't >>>>>> really care which IETF work group does the work. >>>>>> >>>>>> In my experience, conferences are the least common use of nicks. >>>>> Persistent >>>>>> nicks are much more common than temporary nicks. If we're going >>>> to bias >>>>>> solutions, we ought to bias them towards persistent, non conference >>>>> nicks. >>>>>> It's not clear to me that we need such a bias. >>>>>> >>>>>> Brian >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] >>>>>>> Sent: Wednesday, May 16, 2007 9:04 PM >>>>>>> To: SIMPLE mailing list >>>>>>> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation >>>>>>> >>>>>>> This discussion is great and helpful to the XCON folks. What we >> are >>>>>>> doing in SIMPLE is a nickname service for an adhoc conference. >>>> In my >>>>>>> opinion, the solution that Miguel and Aki are proposing in their >>>> draft >>>>>>> is sufficient enough to satisfy the requirements of enabling a >>>>>>> chatroom participant to suggest a nickname for himself/herself >>>> and get >>>>>>> accepted into the chatroom or get rejected with a reason of >>>> conflict >>>>>>> in nicknames. This is on a first come first server basis. >>>>>>> >>>>>>> If a domain wants to have the service where a user can have a >>>> unique >>>>>>> nickname across chatrooms, then it is an implementation issue >>>> behind >>>>>>> the scenes and does not require standardisation. >>>>>>> >>>>>>> If there are any other requirements, including nickname >> uniqueness >>>>>>> across domains or the reservation of a nickname forever, I think >>>> they >>>>>>> should go to XCON. >>>>>>> >>>>>>> Regards, >>>>>>> Hisham >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Simple mailing list >>>>>>> Simple@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri May 18 13:57:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp6hV-0003mt-Pb; Fri, 18 May 2007 13:57:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp6hU-0003kA-Tc for simple@ietf.org; Fri, 18 May 2007 13:57:12 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp6hT-0007aS-CD for simple@ietf.org; Fri, 18 May 2007 13:57:12 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hp6fG-0001QB-NN; Fri, 18 May 2007 12:54:55 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" References: <464056CA.1080209@nsn.com> <3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp> <464B32A4.3000708@cisco.com> <07df01c797eb$93a7e0b0$640fa8c0@cis.neustar.com> <464B61F2.7060600@cisco.com> <087701c797f9$07ace250$640fa8c0@cis.neustar.com> <66cd252f0705161803u5250073sfa468507f1fdd224@mail.gmail.com> <008801c79826$cc735c40$640fa8c0@cis.neustar.com> <66cd252f0705162325s21d5cdfarc6632803539abfc6@mail.gmail.com> <018001c7987f$ccb745a0$640fa8c0@cis.neustar.com> <66cd252f0705170628w4c6bef8an898b049de75e238e@mail.gmail.com> <464D7864.3090608@ericsson.com> <054901c79940$b5c43580$640fa8c0@cis.neustar.com> <464DB54A.9000403@cisco.com> Subject: RE: [Simple] MSRP chat: SIP-based nickname negotiation Date: Fri, 18 May 2007 13:57:04 -0400 Message-ID: <062601c79975$f34b7320$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceZVuh7XRF0z0+RSRaFSErtgcgx5wAFmtCA In-reply-to: <464DB54A.9000403@cisco.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 - [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: 7698d1420ecbbce1995432e99bb6d1a1 Cc: 'SIMPLE mailing list' , 'Gonzalo Camarillo' 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 Works for me. So you really want nick@domain. I try to separate what is displayed from what the protocol conveys. nick@domain is unique, can be persistent, and I don't see any problem there. Certainly, it's no stretch to have chatroom6.example.com as the domain. bob@example.com and bob@atlanta.com can be displayed as Bob(1) and Bob(2), or any other way the UI wants to. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, May 18, 2007 10:17 AM > To: Brian Rosen > Cc: 'Gonzalo Camarillo'; 'Hisham Khartabil'; 'SIMPLE mailing list' > Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > > > > Brian Rosen wrote: > > Gonzalo > > > > I don't want an MSRP specific solution. I don't want an XCON solution. > I > > want a SIP/IM/Presence/XCON... solution. Nicknames are a common thing. > > Right. > > > The most common nicknames are things like AOL screen names. They are > > persistent, unique within a domain, and used with all forms of > > communication. > > I agree with what you say here about the prior art. But I have > difficulty relating the "unique within a domain" part to what we are > doing. > > That works for AOL because all communications, even the point to point > kind, are mediated by a server in the AOL domain. Both ends share that > domain and so the nickname namespace. > > That fits with what the current proposal is, because it applies only to > conferences, where again there is a common server mediating all > communications. > > But it doesn't generalize to the broader scope that you and I aspire to. > In particular it doesn't generalize to point to point communications. > > The real world is also more complex than this when you get to multiple > providers. For instance I use a Gaim IM client, with connections to AOL > and to a corporate Sametime server. The namespace for > nicknames/screen-names is separate for the two domains but must be > resolved in the client UI. > > IMO the general solution must tag nicknames with their domain. That > isn't so friendly if the domain shows up in the UI, but neither is it > awful. It can be made better by a UI that does defaulting of the domain > part of the nickname in a reasonable way. > > Paul > > > Per chat temporary nicks happen to us techies that use > > things like IRC, not to the real world. > > > > I think this is a simple problem, with simple solutions. I think it's > > reasonably a SIMPLE problem, with possibly some SIP work for a header. > I > > think we can first apply it to MSRP chat and expand it to XCON. > > > > The proposal on the table needs only a little work, I think, to make it > > generally useful. I do think we need to agree on requirements first, > but we > > seem to be coalescing fairly rapidly on that. > > > > Brian > > > >> -----Original Message----- > >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > >> Sent: Friday, May 18, 2007 5:57 AM > >> To: Hisham Khartabil > >> Cc: Brian Rosen; SIMPLE mailing list > >> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > >> > >> Hi, > >> > >> regarding the scope of this work, my understanding was that SIMPLE was > >> going to come up with an MRSP-specific solution for nicknames. A > general > >> solution for nicknames would be developed by XCON (SIP might be to be > >> involved as well if SIP extensions were needed) at a later stage. > >> > >> Therefore, the only requirement on the MSRP-specific solution would be > >> that it is future-proof so that it does not keep us from developing a > >> more general (while being backwards compatible) one in the future. > >> > >> If my understanding of the process is correct, let's get the > >> MSRP-specific solution finished and let's discuss the more general one > >> somewhere else (e.g., XCON). If, on the other hand, this is not the > >> process we want to follow, I would appreciate if somebody could clarify > >> what our plan is. > >> > >> Thanks, > >> > >> Gonzalo > >> > >> > >> > >> > >> Hisham Khartabil wrote: > >>> Brain, > >>> > >>> Thats fair enough. Why don't you get with Miguel and Aki and add some > >>> text to the draft that makes it a generalised mechanism. I believe > >>> Miguel are Aki are more than happy to make you a co-author of this > >>> draft. > >>> > >>> Hisham > >>> > >>> On 17/05/07, Brian Rosen wrote: > >>>> Hisham > >>>> > >>>> Do you think it would be wise for, let's say, a presence system which > >>>> uses > >>>> nicknames have a different mechanism for informing its service of its > >>>> nickname than it would use for an IM chat? > >>>> > >>>> Should the XCON mechanism be different? > >>>> > >>>> I don't want to make this into a big deal, but nicknames are not > >>>> peculiar to > >>>> IM chat. I don't want an IM chat specific solution, especially when > I > >>>> don't > >>>> think we need a whole lot more than is proposed. I think we need > SOME > >>>> more > >>>> to make a generalized nickname feasible. Persistent nicks within a > >>>> domain > >>>> is one of the big differences. > >>>> > >>>> Brian > >>>> > >>>>> -----Original Message----- > >>>>> From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > >>>>> Sent: Thursday, May 17, 2007 2:26 AM > >>>>> To: Brian Rosen > >>>>> Cc: SIMPLE mailing list > >>>>> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > >>>>> > >>>>> Brian, > >>>>> > >>>>> What we are doing in SIMPLE is specific to IM chat service (hence > the > >>>>> name of the draft). My opinion is that whatever is in the draft is > >>>>> sufficient. > >>>>> > >>>>> Hisham > >>>>> > >>>>> On 17/05/07, Brian Rosen wrote: > >>>>>> I can see the registration of a persistent nick as outside the > >> scope > >>>>> here. > >>>>>> We could do some standardization, but we don't have to. > >>>>>> > >>>>>> However, we do need to standardize how a nick user "validates" the > >>>> nick > >>>>>> against the AoR, if that is what the domain wants to do. > >>>>>> > >>>>>> Nicks are not tied to conferences. They can be used in other > >>>>> circumstances. > >>>>>> The validation operation can't be tied to a conference server. I > >>>> don't > >>>>>> really care which IETF work group does the work. > >>>>>> > >>>>>> In my experience, conferences are the least common use of nicks. > >>>>> Persistent > >>>>>> nicks are much more common than temporary nicks. If we're going > >>>> to bias > >>>>>> solutions, we ought to bias them towards persistent, non conference > >>>>> nicks. > >>>>>> It's not clear to me that we need such a bias. > >>>>>> > >>>>>> Brian > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > >>>>>>> Sent: Wednesday, May 16, 2007 9:04 PM > >>>>>>> To: SIMPLE mailing list > >>>>>>> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation > >>>>>>> > >>>>>>> This discussion is great and helpful to the XCON folks. What we > >> are > >>>>>>> doing in SIMPLE is a nickname service for an adhoc conference. > >>>> In my > >>>>>>> opinion, the solution that Miguel and Aki are proposing in their > >>>> draft > >>>>>>> is sufficient enough to satisfy the requirements of enabling a > >>>>>>> chatroom participant to suggest a nickname for himself/herself > >>>> and get > >>>>>>> accepted into the chatroom or get rejected with a reason of > >>>> conflict > >>>>>>> in nicknames. This is on a first come first server basis. > >>>>>>> > >>>>>>> If a domain wants to have the service where a user can have a > >>>> unique > >>>>>>> nickname across chatrooms, then it is an implementation issue > >>>> behind > >>>>>>> the scenes and does not require standardisation. > >>>>>>> > >>>>>>> If there are any other requirements, including nickname > >> uniqueness > >>>>>>> across domains or the reservation of a nickname forever, I think > >>>> they > >>>>>>> should go to XCON. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Hisham > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Simple mailing list > >>>>>>> Simple@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/simple > >>>>>> > >>>> > >>> _______________________________________________ > >>> Simple mailing list > >>> Simple@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/simple > >>> > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri May 18 14:33:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp7G9-0005Ag-UU; Fri, 18 May 2007 14:33:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp7G7-0005AI-Bx for simple@ietf.org; Fri, 18 May 2007 14:33:00 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp7G6-0006Ri-9F for simple@ietf.org; Fri, 18 May 2007 14:32:58 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 18 May 2007 11:32:57 -0700 X-IronPort-AV: i="4.14,553,1170662400"; d="scan'208"; a="151132159:sNHT56058174" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l4IIWve8025461; Fri, 18 May 2007 11:32:57 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4IIWp0A019694; Fri, 18 May 2007 18:32:57 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 14:32:53 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 14:32:52 -0400 Message-ID: <464DF151.3070500@cisco.com> Date: Fri, 18 May 2007 14:32:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation References: <464056CA.1080209@nsn.com> <3D42858C58CCCF468D184BF60B104ADA06BB93E1@FPNYEXCBE02.opus-i.corp> <464B32A4.3000708@cisco.com> <07df01c797eb$93a7e0b0$640fa8c0@cis.neustar.com> <464B61F2.7060600@cisco.com> <087701c797f9$07ace250$640fa8c0@cis.neustar.com> <66cd252f0705161803u5250073sfa468507f1fdd224@mail.gmail.com> <008801c79826$cc735c40$640fa8c0@cis.neustar.com> <66cd252f0705162325s21d5cdfarc6632803539abfc6@mail.gmail.com> <018001c7987f$ccb745a0$640fa8c0@cis.neustar.com> <66cd252f0705170628w4c6bef8an898b049de75e238e@mail.gmail.com> <464D7864.3090608@ericsson.com> <054901c79940$b5c43580$640fa8c0@cis.neustar.com> <464DB54A.9000403@cisco.com> <062601c79975$f34b7320$640fa8c0@cis.neustar.com> In-Reply-To: <062601c79975$f34b7320$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2007 18:32:52.0632 (UTC) FILETIME=[F1DED180:01C7997A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8817; t=1179513177; x=1180377177; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20MSRP=20chat=3A=20SIP-based=20nickname=20ne gotiation |Sender:=20; bh=SyL62VTsueB+OpHNmcz4gllRTwlWGRpS8ULJP29Yt8Q=; b=CGN9x4jxJCxfOfALUxfnCxw203TsHPxn1DO9CtKFgwFRQyDzf/vp/1T6twjAKB+51fdvIJBK gBiy5VbSVrxa06FxUVGPugD8P25ZyPb7QMssLaxMroMwkKGfddQ4NtIC; Authentication-Results: sj-dkim-8; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: 'SIMPLE mailing list' , 'Gonzalo Camarillo' 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: > Works for me. So you really want nick@domain. > I try to separate what is displayed from what the protocol conveys. > nick@domain is unique, can be persistent, and I don't see any problem there. > Certainly, it's no stretch to have chatroom6.example.com as the domain. > > bob@example.com and bob@atlanta.com can be displayed as Bob(1) and Bob(2), > or any other way the UI wants to. Yeah, that's what I was thinking. Paul > Brian > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, May 18, 2007 10:17 AM >> To: Brian Rosen >> Cc: 'Gonzalo Camarillo'; 'Hisham Khartabil'; 'SIMPLE mailing list' >> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation >> >> >> >> Brian Rosen wrote: >>> Gonzalo >>> >>> I don't want an MSRP specific solution. I don't want an XCON solution. >> I >>> want a SIP/IM/Presence/XCON... solution. Nicknames are a common thing. >> Right. >> >>> The most common nicknames are things like AOL screen names. They are >>> persistent, unique within a domain, and used with all forms of >>> communication. >> I agree with what you say here about the prior art. But I have >> difficulty relating the "unique within a domain" part to what we are >> doing. >> >> That works for AOL because all communications, even the point to point >> kind, are mediated by a server in the AOL domain. Both ends share that >> domain and so the nickname namespace. >> >> That fits with what the current proposal is, because it applies only to >> conferences, where again there is a common server mediating all >> communications. >> >> But it doesn't generalize to the broader scope that you and I aspire to. >> In particular it doesn't generalize to point to point communications. >> >> The real world is also more complex than this when you get to multiple >> providers. For instance I use a Gaim IM client, with connections to AOL >> and to a corporate Sametime server. The namespace for >> nicknames/screen-names is separate for the two domains but must be >> resolved in the client UI. >> >> IMO the general solution must tag nicknames with their domain. That >> isn't so friendly if the domain shows up in the UI, but neither is it >> awful. It can be made better by a UI that does defaulting of the domain >> part of the nickname in a reasonable way. >> >> Paul >> >>> Per chat temporary nicks happen to us techies that use >>> things like IRC, not to the real world. >>> >>> I think this is a simple problem, with simple solutions. I think it's >>> reasonably a SIMPLE problem, with possibly some SIP work for a header. >> I >>> think we can first apply it to MSRP chat and expand it to XCON. >>> >>> The proposal on the table needs only a little work, I think, to make it >>> generally useful. I do think we need to agree on requirements first, >> but we >>> seem to be coalescing fairly rapidly on that. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>> Sent: Friday, May 18, 2007 5:57 AM >>>> To: Hisham Khartabil >>>> Cc: Brian Rosen; SIMPLE mailing list >>>> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation >>>> >>>> Hi, >>>> >>>> regarding the scope of this work, my understanding was that SIMPLE was >>>> going to come up with an MRSP-specific solution for nicknames. A >> general >>>> solution for nicknames would be developed by XCON (SIP might be to be >>>> involved as well if SIP extensions were needed) at a later stage. >>>> >>>> Therefore, the only requirement on the MSRP-specific solution would be >>>> that it is future-proof so that it does not keep us from developing a >>>> more general (while being backwards compatible) one in the future. >>>> >>>> If my understanding of the process is correct, let's get the >>>> MSRP-specific solution finished and let's discuss the more general one >>>> somewhere else (e.g., XCON). If, on the other hand, this is not the >>>> process we want to follow, I would appreciate if somebody could clarify >>>> what our plan is. >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> >>>> >>>> >>>> Hisham Khartabil wrote: >>>>> Brain, >>>>> >>>>> Thats fair enough. Why don't you get with Miguel and Aki and add some >>>>> text to the draft that makes it a generalised mechanism. I believe >>>>> Miguel are Aki are more than happy to make you a co-author of this >>>>> draft. >>>>> >>>>> Hisham >>>>> >>>>> On 17/05/07, Brian Rosen wrote: >>>>>> Hisham >>>>>> >>>>>> Do you think it would be wise for, let's say, a presence system which >>>>>> uses >>>>>> nicknames have a different mechanism for informing its service of its >>>>>> nickname than it would use for an IM chat? >>>>>> >>>>>> Should the XCON mechanism be different? >>>>>> >>>>>> I don't want to make this into a big deal, but nicknames are not >>>>>> peculiar to >>>>>> IM chat. I don't want an IM chat specific solution, especially when >> I >>>>>> don't >>>>>> think we need a whole lot more than is proposed. I think we need >> SOME >>>>>> more >>>>>> to make a generalized nickname feasible. Persistent nicks within a >>>>>> domain >>>>>> is one of the big differences. >>>>>> >>>>>> Brian >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] >>>>>>> Sent: Thursday, May 17, 2007 2:26 AM >>>>>>> To: Brian Rosen >>>>>>> Cc: SIMPLE mailing list >>>>>>> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation >>>>>>> >>>>>>> Brian, >>>>>>> >>>>>>> What we are doing in SIMPLE is specific to IM chat service (hence >> the >>>>>>> name of the draft). My opinion is that whatever is in the draft is >>>>>>> sufficient. >>>>>>> >>>>>>> Hisham >>>>>>> >>>>>>> On 17/05/07, Brian Rosen wrote: >>>>>>>> I can see the registration of a persistent nick as outside the >>>> scope >>>>>>> here. >>>>>>>> We could do some standardization, but we don't have to. >>>>>>>> >>>>>>>> However, we do need to standardize how a nick user "validates" the >>>>>> nick >>>>>>>> against the AoR, if that is what the domain wants to do. >>>>>>>> >>>>>>>> Nicks are not tied to conferences. They can be used in other >>>>>>> circumstances. >>>>>>>> The validation operation can't be tied to a conference server. I >>>>>> don't >>>>>>>> really care which IETF work group does the work. >>>>>>>> >>>>>>>> In my experience, conferences are the least common use of nicks. >>>>>>> Persistent >>>>>>>> nicks are much more common than temporary nicks. If we're going >>>>>> to bias >>>>>>>> solutions, we ought to bias them towards persistent, non conference >>>>>>> nicks. >>>>>>>> It's not clear to me that we need such a bias. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] >>>>>>>>> Sent: Wednesday, May 16, 2007 9:04 PM >>>>>>>>> To: SIMPLE mailing list >>>>>>>>> Subject: Re: [Simple] MSRP chat: SIP-based nickname negotiation >>>>>>>>> >>>>>>>>> This discussion is great and helpful to the XCON folks. What we >>>> are >>>>>>>>> doing in SIMPLE is a nickname service for an adhoc conference. >>>>>> In my >>>>>>>>> opinion, the solution that Miguel and Aki are proposing in their >>>>>> draft >>>>>>>>> is sufficient enough to satisfy the requirements of enabling a >>>>>>>>> chatroom participant to suggest a nickname for himself/herself >>>>>> and get >>>>>>>>> accepted into the chatroom or get rejected with a reason of >>>>>> conflict >>>>>>>>> in nicknames. This is on a first come first server basis. >>>>>>>>> >>>>>>>>> If a domain wants to have the service where a user can have a >>>>>> unique >>>>>>>>> nickname across chatrooms, then it is an implementation issue >>>>>> behind >>>>>>>>> the scenes and does not require standardisation. >>>>>>>>> >>>>>>>>> If there are any other requirements, including nickname >>>> uniqueness >>>>>>>>> across domains or the reservation of a nickname forever, I think >>>>>> they >>>>>>>>> should go to XCON. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Hisham >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Simple mailing list >>>>>>>>> Simple@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From rwq@netvision.net.il Sat May 19 22:44:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpbPX-00057L-7i for simple-archive@lists.ietf.org; Sat, 19 May 2007 22:44:43 -0400 Received: from [122.252.77.200] (helo=thvcowe) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HpbPU-0008Dp-FC for simple-archive@lists.ietf.org; Sat, 19 May 2007 22:44:43 -0400 Received: (qmail 17324 invoked from network); Sun, 20 May 2007 11:44:38 +0900 Received: from unknown (HELO grvgo) (88.209.102.28) by thvcowe with SMTP; Sun, 20 May 2007 11:44:38 +0900 Message-ID: <001501c79a88$cf7639d0$1c66d158@grvgo> From: "Angelica Ballard" To: Subject: I was still marveling at this when another brookie followed, and another. Date: Sun, 20 May 2007 11:44:38 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 GPSI Announces Market Attack Into $1 Trillion Market! Global Payment Solutions Symbol: GPSI Price: $0.03 GPSI announced its plans to address the huge influx of immigrant workers into the US that need banking solutions that they otherwise would not qualify for. This market is expected to represent over $1 Trillion dollars to be managed by 2008. GPSI provides viable solutions to this market. This is hot, read the news and watch for more Monday! Get on GPSI first thing Monday! It's an extremely worrisome situation. Someone call IX - I - I. Something is going on. Hours go by, still sitting. The Maggie is part of a spiffing Ealing Studios boxset; it also includes The Titfield Thunderbolt, Passport to Pimlico, Whisky Galore! The dumplings were just a bit dry on the first attempt - I may add more milk, or butter, or both, and cook 'em a tad less. In the evening I betook myself to the shower rather pleased with myself but anticipating, correctly, that I would wake up sore as hell. And if you like that sort of thing, this is the sort of thing you'll like. Combine dry ingredients and mix well. One can also share a radio-like stream with friends or post it on one's web site. and A Run for Your Money - all worth seeing. The answer was, that it was like looking for a needle in a haystack and that we should continue to take all precautions. From idqct@rediffmail.com Sun May 20 10:20:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpmGi-0005b6-9G for simple-archive@lists.ietf.org; Sun, 20 May 2007 10:20:20 -0400 Received: from [88.245.170.56] (helo=ukucvrr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HpmGh-0000gi-BU for simple-archive@lists.ietf.org; Sun, 20 May 2007 10:20:20 -0400 Received: from fxwi ([127.84.37.177]) by ukucvrr (8.13.3/8.13.3) with SMTP id l4KELcV4037104; Sun, 20 May 2007 17:21:38 +0300 Message-ID: <4650591C.3030503@rediffmail.com> Date: Sun, 20 May 2007 17:20:12 +0300 From: Kent User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: I'm not a 'Mister' anything. Content-Type: multipart/related; boundary="------------040807020108040200070206" X-Spam-Score: 3.1 (+++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 --------------040807020108040200070206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hated
One of the most common mistakes made by Website owners is paying too much attention to first-time visitors rather than on repeat visitors. The Lesson: You can charge more for your stuff as long as you're showing you client that even though she's paying a premium price, she's getting a good value.
or even setting up special landing pages for them gives you site traffic the opportunity to stand out in the search engines with little competition. Keep track of how many inquiries each ad pulls.
Highlight that theme in subsequent ads.
If your interruptions are due to people consistently coming in and just sitting and talking, remove the empty chairs.
Become a broken record if need be.
The hard part is keepin' them coming back as repeat visitors.
Type a keyword or phrase below and tap into Google's listings of Websites offering glossaries related to your search. And you can too when you install FREE RSS software on your computer and link to the Internet.
and what could he say then?
They start talking and don't stop. simply copy and paste the HTML code below: Shipping insurance news, views, and reviews .
But for internet marketing junkies, a glossary is their best-kept secret to find a treasure trove of keyword gold.
often finding that I'm the only advertiser bidding on these "stealthy" keyword phrases. leaving their private Web site available for anyone with even the slowest modem connection the ability to hack away.
The last subhead of your ad could read, "Get the facts-Free. I'm not a 'Mister' anything. Navigation Home Member login Email this Webpage Send feedback www. Add a white board for notes. encoded within each of my Web pages does all of the asking for me.
If they don't return, you haven't lost anything.
Read content anywhere in the world The following Web sites give you RSS software over the net.
An area you can call your own. " Now let's add a situation statement: "I'm working on a report that I promised to finish within the next hour. so when you factor in the cost of a corrugated shipping box, it's actually cheaper to go with Priority Mail. Add a white board for notes. just search for the name and ZIP Code.
A news letter could contain many things.
But reading the internet is at best. " Eventually when they finally realize you're not paying their game, they will stop, and even pretend to be offended.
--------------040807020108040200070206-- From avq@djis.net Sun May 20 19:47:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hpv7o-0004rT-7G for simple-archive@lists.ietf.org; Sun, 20 May 2007 19:47:44 -0400 Received: from [80.80.175.148] (helo=lqnk) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hpv7m-0000Eg-HZ for simple-archive@lists.ietf.org; Sun, 20 May 2007 19:47:44 -0400 Received: from lhgl ([143.43.139.55]) by lqnk (8.13.2/8.13.2) with SMTP id l4KNxDod045663; Mon, 21 May 2007 01:59:13 +0200 Message-ID: <002801c79b3a$8c1b5b40$378b2b8f@lhgl> From: "Blake S. Victor" To: Subject: The whole time I was watching this piece I kept wondering to myself how in the world the camera-person had been able to get as close and as involved in the action as the Date: Mon, 21 May 2007 01:56:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.3 (++++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 GPSI Announces Market Attack Into $1 Trillion Market! Global Payment Solutions Symbol: GPSI Price: $0.03 GPSI announced its plans to address the huge influx of immigrant workers into the US that need banking solutions that they otherwise would not qualify for. This market is expected to represent over $1 Trillion dollars to be managed by 2008. GPSI provides viable solutions to this market. This is hot, read the news and watch for more Monday! Get on GPSI first thing Monday! With the general population of L. to access thedarkknight. Boyes is a four-time Oscar winner for Pirates of the Caribbean: Dead Man's Chest, The Lord of the Rings: The Return of the King, A contemporary drama set in Washington, D. It tinkles down to baby milk formulas and soy sauce: "cuttlefish were soaked in calligraphy ink to improve their color and eels were fed contraceptive pills to make them grow long and slim. Harrelson plays a gay society walker who becomes involved in a Washington murder scandal. What makes kiteboarding different is the fact that it seems like the participants have a bit more control. Winners Receive:- Pan's Labyrinth DVD to enter our contest! Synopsis:Left-wing liberals beware! ThinkFilm will release the drama late this year to qualify for awards consideration. And they should be marked down by the time Dia de la Independencia rolls around in September. Synopsis:Taking place on an alternative earth, humans and vampires live together in peace. Das nennt man Mystifizierung. The tour is being supported by a fantastic lineup of promotional partners. And indeed, this turned out to be a murky area, even for professionals. The tour chefs will feature recipes from the General Mills' portfolio of brands and attendees will be able to sample Chocolate Chex cereal as available. My WebBackflipBlinkbitsBlinklistblogmarksBuddymarksCiteULikedel. The film finds Shrek, Donkey, and Puss N' Boots searching for the future King Arthur in a medieval high school. Meanwhile, back at the quarantine area the passengers are dropping like flies and the doctors are at a loss as to what to do to save them. From cnnvh@signaturecommunities.us Mon May 21 06:33: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 1Hq5DB-0006nz-Oz for simple-archive@lists.ietf.org; Mon, 21 May 2007 06:33:57 -0400 Received: from d13-169.rt-bras.wnvl.centurytel.net ([69.179.140.169]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hq5DA-0004Cx-SO for simple-archive@lists.ietf.org; Mon, 21 May 2007 06:33:57 -0400 Received: from tgjb ([121.140.59.207]) by d13-169.rt-bras.wnvl.centurytel.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 21 May 2007 05:33:42 -0500 Message-ID: <000701c79b93$80a0ad20$cf3b8c79@tgjb> From: "Noah O. Kelly" To: Subject: Never got beyond India really. Date: Mon, 21 May 2007 05:33:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.0 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe GPSI Announces Market Attack Into $1 Trillion Market! Global Payment Solutions Symbol: GPSI Price: $0.03 GPSI announced its plans to address the huge influx of immigrant workers into the US that need banking solutions that they otherwise would not qualify for. This market is expected to represent over $1 Trillion dollars to be managed by 2008. GPSI provides viable solutions to this market. This is hot, read the news and watch for more Monday! Get on GPSI first thing Monday! I'm not a huge fan of McDonald's and, unlike some people I know, don't subsist on a steady diet of the local incarnation of a BigMac and Fries when traveling. Hence a horse can live a long, pleasant, and natural life and still produce choice yield. I commend the writer for not being very judgmental. But no ducks, no bunnies, no lambs, no puppies. In Brooklyn, there are no giant carvings of man. They aren't great, still being McDs after all, but really aren't terrible. Usually the comments are quite informative. Incredible these fools come into power and do so much damage. Hey, are you gonna finish those fries? It stopped looking like a real word halfway through the comments. They are so damned tasty. Being brutally truthful and well written doesn't make the topic sweeter and nicer to digest. I hadn't previously considered corn a dessert item, but it wasn't bad. It has your general burger tomato sauce I think, it's been years since I ate any McDonalds food let alone that type of burger. There are many, many people who know lots of things about cooking and are -not- advocates of this, and they are the ones from whom I'll take my advice, thanks. There were commercials for it with guys in Lederhosen climbing up ladders to like, raid McDonald's or something for these pork burgers with mayonnaise. Seriously though, yes, I knew that McDonalds had different items on their menu for different countries. Incidentally, Hell's Kitchen in the UK is a much different show than the US one. Verbing weirds nouns. Is it just a regular McDonald's burger, straight up? Linda Hunt was frikkin brilliant. That movie was awful. Incidentally, Hell's Kitchen in the UK is a much different show than the US one. I felt like chicken tonight, like chicken tonight, but the rain has foiled my BBQ plans. Locally, some McDonalds in Maryland's eastern shore sell crab cake sandwiches, but I guess that is not as exotic as beets and fried eggs. Though, just once, I'd like to hear GWBush say it. Being brutally truthful and well written doesn't make the topic sweeter and nicer to digest. Perusing this international McMenu, it wouldn't surprise me if people elsewhere in the world made a similar joke. McDonald's food sucks. My family was stationed at West Point when My Lai cascaded through our culture. Knock on my laptop, I don't want to jinx anything. Just to kill that phrase dead. I like my eggs nice and smooth. "I'm not making this up, you know. I can't hep thinking that the voices the villagers hear are some expression of their memories, perhaps buried or walled off, from the days of the killing fields. The fried egg is just a no-brainer, though. I don't think there is any way to comprehend it on an emotional level. From qxbd@c2i.net Mon May 21 14:52:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqD02-00069V-22 for simple-archive@lists.ietf.org; Mon, 21 May 2007 14:52:54 -0400 Received: from [85.108.172.79] (helo=uxbaqye) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HqD00-0004M5-9Y for simple-archive@lists.ietf.org; Mon, 21 May 2007 14:52:54 -0400 Received: from rrtry ([230.80.175.137]) by uxbaqye (8.13.5/8.13.5) with SMTP id l4LIscDg030831; Mon, 21 May 2007 21:54:38 +0300 Message-ID: <001a01c79bd9$3b046220$89af50e6@rrtry> From: "Paige" To: Subject: But now that my wife saw Front Row in action I don't know if Vaio is going to hold for much longer. Date: Mon, 21 May 2007 21:52:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 GPSI Announces Market Attack Into $1 Trillion Market! Global Payment Solutions Symbol: GPSI Price: $0.03 GPSI announced its plans to address the huge influx of immigrant workers into the US that need banking solutions that they otherwise would not qualify for. This market is expected to represent over $1 Trillion dollars to be managed by 2008. GPSI provides viable solutions to this market. This is hot, read the news and watch for more Monday! Get on GPSI first thing Monday! For example, it replaced almost all its desktop computers and CRT monitors with laptops and LCD screens, which consume much less power. Could it hurt the future sales of those involved? Do users have the right to complain? George Sudarkoff: Pure means impractical? You attribute way to much power to those desperate blokes. This deal with IBM gives us the ability to scale as well as access world-leading technological innovation to meet the changing needs of our super fund clients and their members. And they chose to target cheapsters because it is easy - not the strategy I would choose for my marketing campaign, but is a valid strategy nonetheless. Much of this seems to be attributable to a dramatic decrease in patenting activity in the industry. Please see the below Disclaimer of Warranty for additional conditions. The company offers a host of cross-industry and industry-specific solutions designed to meet the needs of companies of all sizes. Dread that other people's gifts might be better than yours. All employees who are not offered employment with IBM, and whose employment with TRUenergy ceases, will receive their full leave and redundancy entitlements as well as outplacement services. IBM is leading the way towards a more flexible inclusive and diverse workplace", said Mr Andrews. "This Match Analysis DVD will help players at the Australian Open take their game to the next level. Based in Brisbane, Multibill has its own inbound call centre specifically designed to handle the wide range of tasks associated with utility billing. The other day, a friend of mine complained about Smalltalk being responsible for his increased rent. And no matter how much you plan you'll still have to do something for the first time. they put a man on the Moon. Under IBM's global delivery model, client service and delivery will be done from Australia and selected back-office functions will be managed from IBM Daksh in Bangalore. In the short term IBM will implement a range of services to streamline IT operations including remote server monitoring and administration and full-time help desk. Some doctors treat the ordinary cold, others specialize in brain surgery. IBM Vice President, Mid-Market Business, Australia and New Zealand, Charles Bligh, said, "Express Advantage is an exciting development for us in the medium-sized business space. This is an example of this strategy in action. Please see the below Disclaimer of Warranty for additional conditions. The move provided the agency with a chance to create a model office for energy efficient technology usage. For example, it replaced almost all its desktop computers and CRT monitors with laptops and LCD screens, which consume much less power. In one of my previous posts I argued that software systems are essentially incomplete. "What's more, employing people with diverse backgrounds, perspectives and skills gives IBM a competitive edge as innovation becomes more important to our clients", said Mr Boreham. com Definitely a useful site and a clever idea. IBM will also install back-office and call centre infrastructure at Multibill. Traditional business process outsourcing focuses on cost cutting. About IBM Privacy Contact Coupled with this, there has been an increased focus on the use of technology as an enabler of service delivery and efficiency gains. The virtualised hosting solution, built on IBM System P technology, is priced according to the number of end-customers billed, and can be scaled dynamically to meet changes in demand. IBM will also leverage its global application management services capabilities to manage and transform the underlying software applications over the course of the agreement. From xwx@mbglaw.com Mon May 21 23:51:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqLPi-0007cn-M5 for simple-archive@lists.ietf.org; Mon, 21 May 2007 23:51:58 -0400 Received: from adsl-224-105-73.asm.bellsouth.net ([74.224.105.73]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HqLPg-0007rQ-Jc for simple-archive@lists.ietf.org; Mon, 21 May 2007 23:51:58 -0400 Received: from [127.91.44.51] (helo=ncr) by adsl-224-105-73.asm.bellsouth.net with smtp (Exim 4.62 (FreeBSD)) id 1ITdQI-0004Qw-Ue; Mon, 21 May 2007 23:52:34 -0400 Message-ID: <002a01c79c24$9435d4a0$332c5b7f@ncr> From: "Gonzales Mortimer" To: Subject: That had to be tough after a full day; you had to be wiped out. Date: Mon, 21 May 2007 23:52:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 X-Spam-Score: 1.7 (+) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 News Releases Warming Investors Up On GPSI Global Pay Solutions Inc. Symbol: GPSI Close: $0.031 Recent news releases have excited investors. Heavy trading pushed share prices up to highs of $0.08 (UP 266%). Closing at $0.031 (UP 3%) we expect to see more traffic and prices shooting up all week. This one is getting started. Don't miss it. Get on GPSI first thing Tuesday! How did you work your way from being an assistant editor to writing a script for the unit? Other martial arts films always have a clearly defined villain - either a rival from another Wushu school or an unscrupulous foreigner - but there is no villain in the film. The first word is stop. The film redefines the genre, as opposed to Crouching Tiger, Hidden Dragon, which was a reinterpretation of the genre. - and went well, it's still family. They'd say, 'Come on in and watch this and see if you think it's funny. Both films inhabit innocent, dark, and dangerous worlds where there's vulnerability and moral complexity. Roy also wrote for television series, including Walt Disney's Wonderful World of Color and the popular Zorro, starring Guy Williams. That's the big motivation for making this film. There, in the middle of it, was this beautiful Emily Watson; it didn't make any difference how luscious and fragile she was, the notion of family through Danny Huston's eyes still remained true. How does it differ from working on Six Feet Under? In Twelve and Holding and LIE you deal with the deep issues children can face as they transition between kids and adults. I was just a consultant. Physically, Huo Yuanjia never lost. Twelve and Holding divides up key issues faced by adolescents into three connected but divergent storylines. Of course, the bigger the screen, really the better the effect. It's just humans fighting, to help the story. So I kind of loved it, we all loved it, I think; we loved getting dirty and loved getting that hot and sweaty. It's not about martial arts. Be patient in your casting process because you live and die by that. Can you discuss the restoration process a little bit? You think about a lot of foreigners today going to China, and what are they doing? "I would never want to take a break, because I don't feel like I'm working," says Lee, satisfied with his career. I just trust my instincts and the only thinking that's involved with decision-making is "Do I want to spend the next two years of my life with this story and characters". Both films inhabit innocent, dark, and dangerous worlds where there's vulnerability and moral complexity. I think he understood this character from the first read. As far as being type cast, pigeon holed. I feel like it's a film that over time, people will catch on. Instead, it is Yuanjia himself, through is arrogance and self importance, who emerges as the film's antagonist, doing more damage to himself than any enemy ever could. How does it differ from working on Six Feet Under? This story is perfect to see - through the life journey - what changes you. That's the big motivation for making this film. TV's a writer, exec producer medium, and Film is a director's medium. If that's my fate, so be it. I think I need a certain amount of authorship of my work to truly emerge myself in it. I was just a consultant. And I think this theme will prevail in any later projects that I work on. And after awhile, we began asking people to cover certain events or things. Which of the three main characters do you feel the closest identification with and why? I loved the episode, "You never know". These three things are true. During his tenure, Disney animation produced some of its greatest box office successes of all time, including The Little Mermaid, Beauty and the Beast and The Lion King. I'm number one in China. " That made all Chinese people very proud, and very happy. He needs to battle a plethora of demons to care about his job. That's why I say this is my last Wushu movie, because everything I want to say is already in this film. These guys were so smart, and so good at what they did. Knowing when to talk and to direct them, and when not to talk and not direct them. Honestly, I don't have much to ask you; so much of the information was already in the disc extras. I believe it is yourself. People have made a lot of films about him after he died, about his students coming back to figure out who killed their master, to get revenge. Li, director Ronny Yu and writer Chris Chow go one step further in removing Fearless for its genre brethren by removing the other staple of martial arts films, the villain. JET LI: This character, Huo Yuanjia, is well known in China. I love it," says Lee. Incredibly, he's more visible today than he's ever been, with his famous cameos in the movies based on his characters and TV shows like "Heroes," his fun "reality" show "Who Wants to be a Superhero? "I come up with the ideas. From iujz@houston.rr.com Mon May 21 23:54:50 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqLSU-0001RH-LP for simple-archive@lists.ietf.org; Mon, 21 May 2007 23:54:50 -0400 Received: from adsl-224-105-73.asm.bellsouth.net ([74.224.105.73]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HqLSS-000875-ID for simple-archive@lists.ietf.org; Mon, 21 May 2007 23:54:50 -0400 Received: from [116.105.178.63] (helo=ziart) by adsl-224-105-73.asm.bellsouth.net with smtp (Exim 4.66 (FreeBSD)) id 1IT%=d-0002l3-MP; Mon, 21 May 2007 23:57:39 -0400 Message-ID: <001101c79c24$fb1a9ed0$3fb26974@ziart> From: "Frederick D. Evelina" To: Subject: Do you know how much tax you will have to pay? Date: Mon, 21 May 2007 23:55:04 -0400 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C79C03.74010F90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.5 (++++) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e ------=_NextPart_000_000D_01C79C03.74010F90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C79C03.74030B60" ------=_NextPart_001_000E_01C79C03.74030B60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Do you have the right staff? Business and financial risk too high? The public sector has higher rates = than the private sector and manufacturing is lower than retail sectors. The difficulty, then, is that these data files were originally designed = to optimise transaction processing. Website design and development by PS = Europe Ltd. Employers can help their employess buy thier own computers at a big = discount by entering the HCI sch. Are your stakeholders happy? The = public sector has higher rates than the private sector and manufacturing = is lower than retail sectors. For example, transactions which have been deleted will need to be = retained on the database for the audit trail. Are you short of IT = skills? This equals seven days lost productivity for each person. Does your company have a plan? Because of different attitudes to attendance; public sector employment = does not make you sicker than private sector jobs! Business and financial risk too high? Are you short of IT skills? The source data for the report will be all the transactions which have = been analysed to the Marketing Expenses account. Can you use IQ Objects? The answer is that those who tackle absence effectively and fairly get = good results. Microsoft provides additional modules with SQL Server called Analysis = Services and Reporting Services, which make it easy to create reports = out of your data. You must retain a copy of all relevant parts of the = documents seen. The difficulty, then, is that these data files were = originally designed to optimise transaction processing. You can put all = your procedures on paper, but you have to make sure they are = implemented. Within SQL Server it is a simple matter to create Views of = your data. Usually the developer has to write a special program in Microsoft Access = simply to collect together the data. Data for accounting reports will derive from the system that processes = purchase invoices and payments - usually an accounts package such as = Oracle, Sun, Sage and so on. But the change management process must = still be carefully planned. Do you know how much tax you will have to pay? Do you need to reduce your costs? Others join some tables but not = others, so essential information cannot be accessed. all the = transactions effectively in the first place. With nominal reporting in = particular, data will derive from several transaction types such as = purchase invoices, sales invoices, cash payments, nominal journals. Do = you know how to sell your business? You can pull in data from multiple tables and amend it as necessary, and = the resultant file can serve as the basis for a report. With substantial = systems running the different operations, the IT department has to spend = a lot of time simply getting these systems to talk to each other. Have = you got a mission statement? Are you maximising the revenue from your assets? But the name of the = supplier will probably be held in another table - the one that stores = purchase ledger transactions. Or the package may hold both sales = invoices and credit notes as positive values because that is the way = they are keyed in by the operator. ------=_NextPart_001_000E_01C79C03.74030B60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"stunt
Do you have the right = staff?
Business and financial risk too high? = The public=20 sector has higher rates than the private sector and manufacturing is = lower than=20 retail sectors.
The difficulty, then, is that these = data files were=20 originally designed to optimise transaction processing. Website design = and=20 development by PS Europe Ltd.
Employers can help their employess buy = thier own=20 computers at a big discount by entering the HCI sch. Are your = stakeholders happy?=20 The public sector has higher rates than the private sector and = manufacturing is=20 lower than retail sectors.
For example, transactions which have = been deleted=20 will need to be retained on the database for the audit trail. Are you = short of IT=20 skills? This equals seven days lost productivity for each = person.
Does your company have a = plan?
Because of different attitudes to = attendance;=20 public sector employment does not make you sicker than private sector=20 jobs!
Business and financial risk too = high?
Are you short of IT = skills?
The source data for the report will be = all the=20 transactions which have been analysed to the Marketing Expenses=20 account.
Can you use IQ Objects?
The answer is that those who tackle = absence=20 effectively and fairly get good results.
Microsoft provides additional modules = with SQL=20 Server called Analysis Services and Reporting Services, which make it = easy to create=20 reports out of your data. You must retain a copy of all relevant parts = of the=20 documents seen. The difficulty, then, is that these data files were = originally=20 designed to optimise transaction processing. You can put all your = procedures on=20 paper, but you have to make sure they are implemented. Within SQL Server = it is a=20 simple matter to create Views of your data.
Usually the developer has to write a = special=20 program in Microsoft Access simply to collect together the = data.
Data for accounting reports will derive = from the=20 system that processes purchase invoices and payments - usually an = accounts package=20 such as Oracle, Sun, Sage and so on. But the change management process = must still be=20 carefully planned.
Do you know how much tax you will have = to=20 pay?
Do you need to reduce your costs? = Others join some=20 tables but not others, so essential information cannot be accessed. all = the=20 transactions effectively in the first place. With nominal reporting in = particular,=20 data will derive from several transaction types such as purchase = invoices, sales=20 invoices, cash payments, nominal journals. Do you know how to sell = your=20 business?
You can pull in data from multiple = tables and amend=20 it as necessary, and the resultant file can serve as the basis for a = report. With=20 substantial systems running the different operations, the IT department = has to spend=20 a lot of time simply getting these systems to talk to each other. Have = you got a=20 mission statement?
Are you maximising the revenue from = your assets?=20 But the name of the supplier will probably be held in another table - = the one that=20 stores purchase ledger transactions. Or the package may hold both sales = invoices and=20 credit notes as positive values because that is the way they are keyed = in by the=20 operator.
------=_NextPart_001_000E_01C79C03.74030B60-- ------=_NextPart_000_000D_01C79C03.74010F90-- From simple-bounces@ietf.org Tue May 22 03: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 1HqOxJ-0005mN-4C; Tue, 22 May 2007 03:38:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiO1E-0000mQ-6j for simple@ietf.org; Mon, 30 Apr 2007 01:01:48 -0400 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiO1C-0006uU-Rs for simple@ietf.org; Mon, 30 Apr 2007 01:01:48 -0400 Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3.1b2) for ; Mon, 30 Apr 2007 00:01:46 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.3a0] Date: Mon, 30 Apr 2007 00:01:52 -0500 To: SIMPLE:; From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Tue, 22 May 2007 03:38:48 -0400 Subject: [Simple] Fwd: draft-resnick-2822upd-01 posted 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 was asked to forward this to SIMPLE. Please follow the discussion on ietf-822@imc.org. --- begin forwarded text Date: Thu, 26 Apr 2007 16:55:06 -0500 To: ietf-822@imc.org From: Pete Resnick Subject: draft-resnick-2822upd-01 posted You may have noticed that 2822upd-01 was posted. Also: To make rfcdiff work, I've put a copy of RFC 2822 on my web site with some of the later sections rearranged so that they're in the same order as the current draft. You can see the diffs between the two here: Though overall very few, there are real changes from 2822 in this document that need review. See the changes section at the bottom. I did *not* go whole hog and switch to Bruce's syntax, simply because I wanted to limit the number of changes and see if we can't get this thing to Draft along with 2821bis. But I did incorporate (hopefully all of) the corrections that you all have pointed out over the last couple of years. Please review with a fine toothed comb. If there are more than just a few problems, perhaps I'll ask Tony Hansen or Philip Guenther (who have at assorted time offered assistance) to start an issues list. Thanks in advance for your assistance. pr --- end forwarded text -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 22 19:41: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 1HqdyX-0003Pu-BO; Tue, 22 May 2007 19:41:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqdyS-0003Op-JI; Tue, 22 May 2007 19:41:04 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqdyR-0001Sw-77; Tue, 22 May 2007 19:41:04 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l4MNf2M0026480; Tue, 22 May 2007 16:41:02 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l4MNf2sD026479; Tue, 22 May 2007 16:41:02 -0700 Date: Tue, 22 May 2007 16:41:02 -0700 Message-Id: <200705222341.l4MNf2sD026479@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 4825 on The Extensible Markup Language (XML) Configuration Access Protocol (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: , Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4825 Title: The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Author: J. Rosenberg Status: Standards Track Date: May 2007 Mailbox: jdrosen@cisco.com Pages: 71 Characters: 166627 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-xcap-12.txt URL: http://www.rfc-editor.org/rfc/rfc4825.txt This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write, and modify application configuration data stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. [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 May 22 19:41: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 1Hqdyl-00040x-Q2; Tue, 22 May 2007 19:41:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqdyd-0003Yt-3D; Tue, 22 May 2007 19:41:15 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqdyc-0001V8-Nc; Tue, 22 May 2007 19:41:15 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l4MNfE7x026485; Tue, 22 May 2007 16:41:14 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l4MNfES3026484; Tue, 22 May 2007 16:41:14 -0700 Date: Tue, 22 May 2007 16:41:14 -0700 Message-Id: <200705222341.l4MNfES3026484@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 4826 on Extensible Markup Language (XML) Formats for Representing Resource Lists 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 4826 Title: Extensible Markup Language (XML) Formats for Representing Resource Lists Author: J. Rosenberg Status: Standards Track Date: May 2007 Mailbox: jdrosen@cisco.com Pages: 31 Characters: 68850 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-xcap-list-usage-05.txt URL: http://www.rfc-editor.org/rfc/rfc4826.txt In multimedia communications, presence, and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services that are associated with a group of users. One example is a resource list service. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents. One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists that are referenced from the first. This list of users can be utilized by other applications and services. Both documents can be created and managed with the XML Configuration Access Protocol (XCAP). [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 May 22 19:41:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqdyx-0004UU-PO; Tue, 22 May 2007 19:41:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqdyo-0004H9-Qk; Tue, 22 May 2007 19:41:27 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqdyo-0001X0-F1; Tue, 22 May 2007 19:41:26 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l4MNfQMn026490; Tue, 22 May 2007 16:41:26 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l4MNfQqM026489; Tue, 22 May 2007 16:41:26 -0700 Date: Tue, 22 May 2007 16:41:26 -0700 Message-Id: <200705222341.l4MNfQqM026489@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 4827 on An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents 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 4827 Title: An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents Author: M. Isomaki, E. Leppanen Status: Standards Track Date: May 2007 Mailbox: markus.isomaki@nokia.com, eva-maria.leppanen@nokia.com Pages: 11 Characters: 22896 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-xcap-pidf-manipulation-usage-02.txt URL: http://www.rfc-editor.org/rfc/rfc4827.txt This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence documents. It is intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs on which it builds the overall presence state for the presentity. [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 Sun May 27 23:29:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsVvF-0007pE-PI; Sun, 27 May 2007 23:29:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsVvE-0007p3-Bq for simple@ietf.org; Sun, 27 May 2007 23:29:28 -0400 Received: from maillog.itri.org.tw ([61.61.254.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsVvD-0002Ju-1U for simple@ietf.org; Sun, 27 May 2007 23:29:28 -0400 Received: from mail.itri.org.tw (mail [140.96.157.2]) by maillog.itri.org.tw (8.12.10/8.12.10) with ESMTP id l4S3V8cO011891; Mon, 28 May 2007 11:31:09 +0800 (CST) Received: from mail.itri.org.tw (localhost [127.0.0.1]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id l4S3UWV3013191; Mon, 28 May 2007 11:30:32 +0800 (CST) Received: from ms1.itri.org.tw ([140.96.147.43]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id l4S3TT70012809; Mon, 28 May 2007 11:30:16 +0800 (CST) Received: from 52092035393 ([140.96.147.156]) by ms1.itri.org.tw (Lotus Domino Release 7.0.2FP1) with ESMTP id 2007052811272093-1161 ; Mon, 28 May 2007 11:27:20 +0800 From: "Jeffrey" To: "'Simple WG'" , Subject: [simple] [Sip-implementors] Should presence server allow a long expiration time of subscription? Date: Mon, 28 May 2007 11:30:19 +0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceg2IRLqQiP+EOWR9uBShsYpY9ynw== X-MIMETrack: Itemize by SMTP Server on MS1/ITRI(Release 7.0.2FP1|January 10, 2007) at 2007-05-28 11:27:21, Serialize by Router on MS1/ITRI(Release 7.0.2FP1|January 10, 2007) at 2007-05-28 11:28:41, Serialize complete at 2007-05-28 11:28:41 X-Spam-Score: 0.4 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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="===============0085520017==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0085520017== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01C7A11B.92B84FD0" This is a multi-part message in MIME format. ------=_NextPart_000_0081_01C7A11B.92B84FD0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" Hi all, I would like to know what consideration Presence Server acting as Notifier wants to shorten the expiration time of presence event package subscription requested from subscriber. Could you give me some reasons about this? If subscribers request a subscription to Presence Server with long expiration like 8 hours (28800 seconds) and Presence Server honors it, is there any disadvantage caused? What consideration should Presence Server take into? Thanks a lot. BR, Jeffrey %;+H%s%i/`%]'t$u,c0|>w1K8j0T!A+D+|)w$'&,%s*L!A=P$E(O%N)N4&ES%;+H%s$:.e!A(C=P>P74&9+H%s!C This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient. ------=_NextPart_000_0081_01C7A11B.92B84FD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="big5" [simple] [Sip-implementors] Should presence server allow a long= expiration time of subscription?

Hi all,

I would= like to know what consideration Presence Server acting as Notifier wants= to shorten the expiration time of presence event package subscription= requested from subscriber. Could you give me some reasons about this? If= subscribers request a subscription to Presence Server with long expiration= like 8 hours (28800 seconds) and Presence Server honors it, is there any= disadvantage caused? What consideration should Presence Server take= into?

Thanks a= lot.

BR,
Jeffrey=


=A5=BB=ABH=A5=F3=A5i= =AF=E0=A5]=A7t=A4u=AC=E3=B0|=BE=F7=B1K=B8=EA=B0T=A1A=ABD=AB=FC=A9w=A4=A7=A6= =AC=A5=F3=AA=CC=A1A=BD=D0=A4=C5=A8=CF=A5=CE=A9=CE=B4=A6=C5S=A5=BB=ABH=A5=F3= =A4=BA=AEe=A1A=A8=C3=BD=D0=BEP=B7=B4=A6=B9=ABH=A5=F3=A1C
This email may contain confidential information. Please do not use or= disclose it in any way and delete it if you are not the intended= recipient.
------=_NextPart_000_0081_01C7A11B.92B84FD0-- --===============0085520017== 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 --===============0085520017==-- From simple-bounces@ietf.org Wed May 30 06:56:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtLqU-0003qB-Vz; Wed, 30 May 2007 06:56:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtLqT-0003oy-Ak for simple@ietf.org; Wed, 30 May 2007 06:56:01 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtLqR-00024A-PZ for simple@ietf.org; Wed, 30 May 2007 06:56:01 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4UAtnNV006753 for ; Wed, 30 May 2007 13:55:58 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 13:55:49 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 13:55:49 +0300 Received: from [172.21.154.97] ([172.21.154.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 13:55:49 +0300 Message-ID: <465D5835.4060009@nsn.com> Date: Wed, 30 May 2007 13:55:49 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: SIMPLE mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 May 2007 10:55:49.0927 (UTC) FILETIME=[159F1B70:01C7A2A9] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Simple] Presence dictionary -05 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: Presence dictionary -05 has been made available. http://www.ietf.org/internet-drafts/draft-garcia-simple-presence-dictionary-05.txt There is an online diff version at: http://people.nokia.net/~miguel/drafts/draft-garcia-simple-presence-dictionary-05-from-4.html The changes with respect the previous version are: - Addition of a missing "country" string (from the Geopriv location object) - Typo: s/close/closed - Typo: s/deviceId/deviceID /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple