From simple-bounces@ietf.org Wed Aug 01 04:00: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 1IG97r-0006nJ-7a; Wed, 01 Aug 2007 04:00:11 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IG97q-0006mq-2l for simple-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 04:00:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG97l-0006ZP-Hx for simple@ietf.org; Wed, 01 Aug 2007 04:00:05 -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 1IG97k-00047T-1x for simple@ietf.org; Wed, 01 Aug 2007 04:00:05 -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 l717xcIe015458; Wed, 1 Aug 2007 11:00:01 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 10:59:45 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 10:59:45 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP NAT traversal Date: Wed, 1 Aug 2007 10:59:44 +0300 Message-ID: In-Reply-To: <66cd252f0707262129t15383003rd9f0c090acf07a13@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP NAT traversal Thread-Index: AcfQBs0MN8qRtRV9TUiXa0a9xgnxVgEB7ncA References: <1FCC1736-3504-408C-A9ED-55C33FDE6D39@nostrum.com> <66cd252f0707262129t15383003rd9f0c090acf07a13@mail.gmail.com> From: To: X-OriginalArrivalTime: 01 Aug 2007 07:59:45.0164 (UTC) FILETIME=[EC8E74C0:01C7D411] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hisham,=20 See inline with [Markus]: ________________________________ From: ext Hisham Khartabil [mailto:hisham.khartabil@gmail.com]=20 Sent: 27 July, 2007 07:30 To: Isomaki Markus (Nokia-SIR/Espoo) Cc: rjsparks@nostrum.com; simple@ietf.org Subject: Re: [Simple] MSRP NAT traversal =09 =09 I think we are always in the habbit on being 10 years ahead of implementation and always trying to design an alternative solution to a solution that has not been proven broken. [Markus] Of course we should give our specs a fair chance before creating alternatives but I think we must also pay attention to what people who deploy these things want rather than expecting them always do things in the way it was originally designed in the IETF. In the worst case they will do things differently anyway, without a proper open spec, and then the interop is even worse. The reason I sent my mail was to get a feeling what people think the situation is with MSRP, MSRP relays, TURN and SBCs. From my perspective I know for sure that there are efforts going on outside IETF (between vendors etc.) to see how MSRP could work through SBCs. On the other hand I've not heard of plans to use relays. But certainly this is just a single view and I'd like to understand how others implementing or deploying see it. It may be that even if we wanted something, it is too complicated to add it as an extension anymore. =20 We spent years on designing MSRP and MSRP relay. Now that they are finally becoming RFCs, we want an alternative solution. One that will cause interoperability problem in the sense that different implementors will choose different solutions. This will cause further work in order to negotiate the NAT traversal solution between endpoints. =20 - Why is not using comedia a mistake? [Markus] MSRP fixes the direction of who opens the TCP connection. In comedia the endpoints can negotiate this. So, with comedia you can get end-to-end TCP always if at least one of the endpoints can receive incoming TCP connections. For instance an MSRP chat server would typically be such an endpoint.=20 - Why is it valuable? - Why isnt MSRP Relay sufficient? [Markus] It is sufficient but it is yet another box to put in your network. Most networks already have SBCs and hopefully soon TURN relays as well and these can handle TCP. So, logically they would like to use them for MSRP and not require a specific solution just for that. In case they would like to do something more than just NAT traversal, they could probably use relay, but AFAIK that is a minority case.=20 =20 Config framework work is another example where people are proposing something else before the config framework has been proven broken. [Markus] That has nothing to do with this discussion related to MSRP, you should bring that up where it belongs. =20 I don't know why you would want to standardise something that is not any better than an existing solution. [Markus] I don't know either, but I tried to explain the benefits I can see. If there are not enough people who agree with them, this is obviously going nowhere (in the IETF). But there are some who do already. =20 Hisham Regards, Markus =20 On 25/07/07, Markus.Isomaki@nokia.com wrote:=20 Hi, =09 Now that MSRP has been finally approved as an RFC, it would be nice to get some actual implementations and even deployments for it. Based on=20 what I've heard there are several client implementations under development (for instance to support file/image transfer service). The problem is that I've got a sense that the interest to support MSRP relay=20 extension seems to be quite low. I'm not sure if there are MSRP relay implementations under development. Instead it seems that many people would rather have MSRP NAT traversal using SBCs (based on comedia) or=20 ICE/TURN. =09 Personally I think that the decision in MSRP not to use comedia has been a mistake. It's not possible to change that anymore in the MSRP base spec, but I think it would be valuable to define how to negotiate MSRP=20 with comedia in an extension spec. This would allow MSRP to work in situations where one of the endpoints can receive incoming TCP connections, as well as with SBCs supporting comedia. =09 Also the work started in=20 =09 http://www.ietf.org/internet-drafts/draft-niemi-simple-msrp-ice-00.txt should be brought to completion. =09 I would be interested in hearing comments whether people think that MSRP=20 relays are going to be sufficient for MSRP NAT traversal (and especially if there are implementation plans) or if there is interest in defining how MSRP works with comedia as an alternative mechanism. My goal would=20 be to do whatever is best to have MSRP deployable. =09 Regards, Markus =09 =09 _______________________________________________ Simple mailing list Simple@ietf.org=20 https://www1.ietf.org/mailman/listinfo/simple =09 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 01 08:01: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 1IGCsy-0005UB-70; Wed, 01 Aug 2007 08:01:04 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IGCsw-0005Td-BS for simple-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 08:01:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGCsw-0005TV-1m for simple@ietf.org; Wed, 01 Aug 2007 08:01:02 -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 1IGCsu-0003NW-Gl for simple@ietf.org; Wed, 01 Aug 2007 08:01:02 -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 l71C0YX9006861; Wed, 1 Aug 2007 15:00:55 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 15:00:47 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 15:00:45 +0300 Received: from [10.144.74.70] ([10.144.74.70]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 15:00:45 +0300 Message-ID: <46B075ED.80809@nsn.com> Date: Wed, 01 Aug 2007 15:00:45 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com> In-Reply-To: <46ADF390.4010204@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2007 12:00:45.0283 (UTC) FILETIME=[97758330:01C7D433] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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: Some inline discussion Paul Kyzivat wrote: > inline > > Miguel Garcia wrote: >> Jonathan Rosenberg wrote: >> >> An example of a nickname is: >> >> >> >> sip:Alice%20in%20wonderland@example.com >> > >> > If a nickname is scoped to a conference, the URI has to include a >> > conference identifier so that such URIs are unique and properly >> scoped. >> > I'd suggest something like: >> > >> > sip:"msrp-nicknames" "/" "/" @ domain >> >> This comes as a side effect of the confusion with domain nicknames in >> previous issues. >> >> So, I agree that the nickname URI has to include the conference >> URI. > > Why? > > By my understanding we are not excluding domain nicknames - we are just > not requiring them or specifying how they might work. Any syntactically > correct nickname should be ok if the server finds it acceptable > according to its own policies. I try to understand that Jonathan is heading towards having a well-specified nickname that is restricted to the conference URI, the rest, can be done ONLY with a generalize mechanism, but not with MSRP. So, we are not excluding domain nicknames, we are just not standardizing them. > > Perhaps there is need for some mandatory-to-implement naming convention > for nicknames that are intended to be per-conference. Yes, this is what I believe Jonathan is suggesting. > >> Earlier versions of the drat spoke about sip:nick@conf@domain, >> and percentage encoding of the first '@' sgn. Please verify if the >> text we used to have is still applicable >> >> Let us take a look at an example. Assume the chat room URI allocated >> to a given chat room is 'sip:room34@example.com'. A user whose >> nickname identifier is set to 'nordicguy' is represented with the >> nickname URI: 'sip:nordicguy%40room34@example.com'. > > Some other possibilities: > > sip:nordicguy@example.com;conf=room34 I think this format does not match a conference URI, so I wouldn't even try to pursue it. > or sip:room34@example.com;name="nordicguy" better, but I what is a 'name'. A parameter named 'nickname' would even be better. Still, I think we can reuse the already defined 'user' parameter of a URI to write a nickname in the userpart. > >> In another example the chat room URI does not include a username >> part. For example, the chat room URI is 'sip:chat34.example.com'. >> In this context a user whose nickname is 'nordicguy' gets represented >> with a nickname URI of 'sip:nordicguy@chat34.example.com'. >> >> Let me know if the percentage encoding of the '@' is ok or you really >> want to go with the "/" sign. >> >> The second aspect you are you suggesting: we should create a >> convention to represent nicknames so that they are distinguishable >> from "regular" URIs. This corresponds to the "msrp-nicknames" in your >> suggestion. I also think we need to do it, mostly for tracing and >> debugging purposes, but I thought of using the user= parameter of a >> SIP URI. >> >> So, what about this syntax? >> >> sip:nickname%40conf-uri-userpart@example.com;user=nikcname > > The user=nickname is an interesting idea. Would this mean that it would > be possible to have both: > > sip:alice@atlanta.com > sip:alice@atlanta.com;user=nickname > > and the two would be distinct, potentially owned by different people? Yes, this is what it means. While it would be confusing if you are just taking a look at the SIP packets, it wouldn't be confusing for the logic in the software. In any case, it will be hard to avoid that someone takes as a nickname other person's username (like you suggested). I consider this issue orthogonal from the syntax of the nickname URI. > That sounds like a pretty confusing situation. Isn't it sufficient for a > particular domain name to be dedicated to either "regular AORs" or > "nicknames", if that makes sense? And why would it be bad to use a real > AOR (that you own) as a nickname if you want and the focus allows it? I think a nickname is a string of characters. If you want your string of characters to include an '@' sign and be charact-by-character equal to your (or someone else's) SIP AoR, I think it should be possible, although the server may impose policy restrictions. The '@' sign may need to be percent-encoded, though, but this is not a problem. This would fit with almost any of the proposed nickname URI syntax that we have been discussing. > > Paul -- 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 From simple-bounces@ietf.org Wed Aug 01 08:15: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 1IGD6R-0006R6-4P; Wed, 01 Aug 2007 08:14:59 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IGD6Q-0006R1-Jp for simple-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 08:14:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGD6Q-0006Qr-1t for simple@ietf.org; Wed, 01 Aug 2007 08:14:58 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGD6P-0004bt-Cp for simple@ietf.org; Wed, 01 Aug 2007 08:14:57 -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 l71CElpo008332; Wed, 1 Aug 2007 15:14:50 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 15:14:48 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 15:14:47 +0300 Received: from [10.144.74.70] ([10.144.74.70]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 15:14:47 +0300 Message-ID: <46B07936.70000@nsn.com> Date: Wed, 01 Aug 2007 15:14:46 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com> <66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com> In-Reply-To: <66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2007 12:14:47.0357 (UTC) FILETIME=[8D5FCED0:01C7D435] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Paul Kyzivat , 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, I agree with your text below. However, I want to highlight a problem: The Conference framework (RFC 4353) provide high-level guidelines for the creation of conference URIs. It says that the conference URI has to resolve to the focus, but does not say that the domain part has to resolve to the conference. Remember that a focus will typically host several conferences. So, sip:chat34@focus.example.com is a valid conference URI, so is valid also sip:chat34.focus.example.com, providing that chat34 is a (perhaps virtual) focus that handles a number of conferences. Ideally I would like to have a conference URI where the conference is part of the hostname (e.g., sip:chat34.focus.example.com), but I suspect this has some impact of the DNS configuration. I believe most network operators will configure the focus on DNS, but not each of the chat rooms (e.g., sip:chat34@focus.example.com). So, we need to leave with it and have a mechanism to embed the nickname in the URI, perhaps using separators "/" like Jonathan proposed, or percent-encoding the '@' sign. /Miguel Hisham Khartabil wrote: > I think the nickname needs to include the conference identifier for the > reasons as follows: > > I am in a chatroom where Alice is. I want to send a private message to > Alice, so my client just happens to pick Alice's nickname and send the > message to her in a normal SIP MESSAGE. > > The way I think the MESSAGE should reach its destination of Alice's > client is via the chatroom server. So, in order for that to happen, the > domain part of the nickname should be routable to the chatroom. > > So Miguel, looking at your examples 'sip:chat34@example.com > ' and 'sip:chat34.example.com > ' being both valid chatroom URIs. In both > cases, I think the nickname URI should look like @ > chat34.example.com . The latter chatroom URI > is ok since it can be routable to the chatroom , but the former is > troublesom. Guidence is need to say that when a nickname is created and > the chatroom URI is in the form room@domain.com > , the 'room' should be put as a subdomain in the > form nickname@room.domain.com . > Regards, > Hisham > -- 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 From simple-bounces@ietf.org Wed Aug 01 08:23: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 1IGDEs-00051u-Fp; Wed, 01 Aug 2007 08:23:42 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IGDEq-00051i-K9 for simple-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 08:23:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGDEq-00051a-Ab for simple@ietf.org; Wed, 01 Aug 2007 08:23:40 -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 1IGDEo-0003uj-GI for simple@ietf.org; Wed, 01 Aug 2007 08:23:40 -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 l71CN6Tx013126; Wed, 1 Aug 2007 15:23:34 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 15:22:38 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 15:22:37 +0300 Received: from [10.144.74.70] ([10.144.74.70]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 15:22:37 +0300 Message-ID: <46B07B0D.5070206@nsn.com> Date: Wed, 01 Aug 2007 15:22:37 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] [MSRP chat] Issue 14: Normative text References: <46ADF57F.1070508@nsn.com> <46ADF89D.5050908@cisco.com> In-Reply-To: <46ADF89D.5050908@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2007 12:22:37.0415 (UTC) FILETIME=[A58CF770:01C7D436] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Paul Kyzivat wrote: > > > Miguel Garcia wrote: >> Jonathan Rosenberg wrote: >> >> Then the MSRP switch should inspect the To header field of the >> >> Message/CPIM wrapper. If the To header field of the Message/CPIM >> >> wrapper contains the chat room URI, the MSRP switch can generate a >> >> copy of the SEND request to each of the participants in the >> >> conference except the sender. >> > >> > MUST generate a copy > > Is this really mandatory? What about a participant that is in "sendonly" > or "inactive" mode? > > It seems that the To header value is input to the "mixer", but that the > mixing policy has some say in what to do as a result. Point taken. I will revise the text to still have the normative text, perhaps as a SHOULD with collection of exceptions (sendonly/inactive, policy, etc.). /Miguel > > Paul -- 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 From simple-bounces@ietf.org Wed Aug 01 08:27: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 1IGDIZ-0002PM-7A; Wed, 01 Aug 2007 08:27:31 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IGDIX-0002OD-36 for simple-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 08:27:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGDIW-0002O5-Pu for simple@ietf.org; Wed, 01 Aug 2007 08:27:28 -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 1IGDIV-0003y3-BE for simple@ietf.org; Wed, 01 Aug 2007 08:27:28 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l71CQfoo024627; Wed, 1 Aug 2007 15:27:18 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 15:27:17 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 15:27:16 +0300 Received: from [10.144.74.70] ([10.144.74.70]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 15:27:16 +0300 Message-ID: <46B07C24.8050701@nsn.com> Date: Wed, 01 Aug 2007 15:27:16 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] [MSRP chat] Issue 11: Anonymity bug References: <46ADF0CD.4080006@nsn.com> <66cd252f0707301622g663d8d05yd93dfa60e283a12@mail.gmail.com> In-Reply-To: <66cd252f0707301622g663d8d05yd93dfa60e283a12@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2007 12:27:16.0319 (UTC) FILETIME=[4BCA56F0:01C7D437] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 The problem here is: - A user wants to send an anonymous private message (not the conference, but privately to another user). - He has to populate the From header in CPIM somehow. The From header of CPIM is transmitted end-to-end. I think we need to provide guidelines of which URI to use in this case. If using the anonymous URI indicated in RFC 3261 is a bug, please indicate which URI to use. /Miguel Hisham Khartabil wrote: > I think Jonathan is asking you not to use whatever is in RFC3261 since > he believes is it a bug. So he is not ok with the text. > > What other mechanisms do we have in place to allow anonymity? > > Hisham > > > On 31/07/07, *Miguel Garcia* > wrote: > > Jonathan Rosenberg wrote: > >> If the sender of the message wants to remain anonymous to the > rest of > >> the participants, and providing that the policy of the conference > >> allows anonymous participation, the creator SHOULD populate > the From > >> header of the Message/CPIM body with an anonymous identity, e.g., > >> using the "anonymous" SIP URI as described in RFC 3261 [RFC3261] > > > > Ugh, this is a bug I'd rather not propagate.... > > So you are OK with the text, I hope. I was trying to give similar > guidelines as RFC 3261 gives with respect the population of the From > header field. > > /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 > > > -- 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 From simple-bounces@ietf.org Thu Aug 02 00:55:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGSj4-0004uO-0S; Thu, 02 Aug 2007 00:55:54 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IGSj2-0004uJ-Od for simple-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 00:55:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGSj2-0004uB-Ez for simple@ietf.org; Thu, 02 Aug 2007 00:55:52 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGSj1-000338-5g for simple@ietf.org; Thu, 02 Aug 2007 00:55:52 -0400 Received: by py-out-1112.google.com with SMTP id f31so1334922pyh for ; Wed, 01 Aug 2007 21:55:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ACL47TKYc3NvJc9hm50hIX0bqZYa8+n+zrV28WVK++9CH0Luo02p3UxrQQTA3D7sAZwhbykPQp+FHQUhrT14urmYCUjFpDI1jeaGbKHCZvOfA5cBPHeraQd/x3GEZBXewbtKbmBfGbQ9EYqIVrusZY8MqT+zvGXdy83I+9yexLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=AO5srittRppRfq9JRzgOzzvVvymxHjQSsARcBgi/j8ivYyJK6O7SisSZyw+4NOo5jYA3y6gSqNVR1Smccj9eZUWCf8XzylmeqFygsi/VWA8IVjXptWijqgrjQOppunto+G+sxscQ8H4Vhnm6bZWcpYtivJoC+yptNoHCiGkmu0Q= Received: by 10.65.126.16 with SMTP id d16mr2415779qbn.1186030550510; Wed, 01 Aug 2007 21:55:50 -0700 (PDT) Received: by 10.65.213.1 with HTTP; Wed, 1 Aug 2007 21:55:50 -0700 (PDT) Message-ID: <66cd252f0708012155k4860d927wfb9d842f12659e65@mail.gmail.com> Date: Thu, 2 Aug 2007 14:55:50 +1000 From: "Hisham Khartabil" To: "Markus.Isomaki@nokia.com" Subject: Re: [Simple] MSRP NAT traversal In-Reply-To: MIME-Version: 1.0 References: <1FCC1736-3504-408C-A9ED-55C33FDE6D39@nostrum.com> <66cd252f0707262129t15383003rd9f0c090acf07a13@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2035431864==" Errors-To: simple-bounces@ietf.org --===============2035431864== Content-Type: multipart/alternative; boundary="----=_Part_12755_32103882.1186030550465" ------=_Part_12755_32103882.1186030550465 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 01/08/07, Markus.Isomaki@nokia.com wrote: > > Hisham, > > See inline with [Markus]: > > ________________________________ > > From: ext Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > Sent: 27 July, 2007 07:30 > To: Isomaki Markus (Nokia-SIR/Espoo) > Cc: rjsparks@nostrum.com; simple@ietf.org > Subject: Re: [Simple] MSRP NAT traversal > > > I think we are always in the habbit on being 10 years ahead of > implementation and always trying to design an alternative solution to a > solution that has not been proven broken. > > [Markus] Of course we should give our specs a fair chance before > creating alternatives but I think we must also pay attention to what > people who deploy these things want rather than expecting them always do > things in the way it was originally designed in the IETF. In the worst > case they will do things differently anyway, without a proper open spec, > and then the interop is even worse. The IETF has participants from service providers (people who deploy these things) as well as vendors (people who build these things). You cannot claim that IETF participants are different from those people. The reason I sent my mail was to get > a feeling what people think the situation is with MSRP, MSRP relays, > TURN and SBCs. From my perspective I know for sure that there are > efforts going on outside IETF (between vendors etc.) to see how MSRP > could work through SBCs. On the other hand I've not heard of plans to > use relays. But certainly this is just a single view and I'd like to > understand how others implementing or deploying see it. It may be that > even if we wanted something, it is too complicated to add it as an > extension anymore. > > We spent years on designing MSRP and MSRP relay. Now that they > are finally becoming RFCs, we want an alternative solution. One that > will cause interoperability problem in the sense that different > implementors will choose different solutions. This will cause further > work in order to negotiate the NAT traversal solution between endpoints. > > > - Why is not using comedia a mistake? > > [Markus] MSRP fixes the direction of who opens the TCP connection. In > comedia the endpoints can negotiate this. So, with comedia you can get > end-to-end TCP always if at least one of the endpoints can receive > incoming TCP connections. For instance an MSRP chat server would > typically be such an endpoint. That's a bogus limitation. What endpoints do you know that can receive TCP connections but can't open them? - Why is it valuable? > - Why isnt MSRP Relay sufficient? > > [Markus] It is sufficient but it is yet another box to put in your > network. Most networks already have SBCs and hopefully soon TURN relays > as well and these can handle TCP. So, logically they would like to use > them for MSRP and not require a specific solution just for that. In case > they would like to do something more than just NAT traversal, they could > probably use relay, but AFAIK that is a minority case. MSRP Relay can be implemented in SBCs. Its a logical entity, not a physical box. Hisham Config framework work is another example where people are > proposing something else before the config framework has been proven > broken. > > [Markus] That has nothing to do with this discussion related to MSRP, > you should bring that up where it belongs. > > I don't know why you would want to standardise something that is > not any better than an existing solution. > > [Markus] I don't know either, but I tried to explain the benefits I can > see. If there are not enough people who agree with them, this is > obviously going nowhere (in the IETF). But there are some who do > already. > > Hisham > > Regards, > Markus > > > On 25/07/07, Markus.Isomaki@nokia.com > wrote: > > Hi, > > Now that MSRP has been finally approved as an RFC, it > would be nice to > get some actual implementations and even deployments for > it. Based on > what I've heard there are several client implementations > under > development (for instance to support file/image transfer > service). The > problem is that I've got a sense that the interest to > support MSRP relay > extension seems to be quite low. I'm not sure if there > are MSRP relay > implementations under development. Instead it seems that > many people > would rather have MSRP NAT traversal using SBCs (based > on comedia) or > ICE/TURN. > > Personally I think that the decision in MSRP not to use > comedia has been > a mistake. It's not possible to change that anymore in > the MSRP base > spec, but I think it would be valuable to define how to > negotiate MSRP > with comedia in an extension spec. This would allow MSRP > to work in > situations where one of the endpoints can receive > incoming TCP > connections, as well as with SBCs supporting comedia. > > Also the work started in > > http://www.ietf.org/internet-drafts/draft-niemi-simple-msrp-ice-00.txt > should be brought to completion. > > I would be interested in hearing comments whether people > think that MSRP > relays are going to be sufficient for MSRP NAT traversal > (and especially > if there are implementation plans) or if there is > interest in defining > how MSRP works with comedia as an alternative mechanism. > My goal would > be to do whatever is best to have MSRP deployable. > > Regards, > Markus > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > > ------=_Part_12755_32103882.1186030550465 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 01/08/07, Markus.Isomaki@nokia.com <Markus.Isomaki@nokia.com > wrote:
Hisham,

See inline with [Markus]:

________________________________

       From: ext Hisham Khartabil [mailto: hisham.khartabil@gmail.com]
       Sent: 27 July, 2007 07:30
       To: Isomaki Markus (Nokia-SIR/Espoo)
       Cc: rjsparks@nostrum.com ; simple@ietf.org
       Subject: Re: [Simple] MSRP NAT traversal


       I think we are always in the habbit on being 10 years ahead of
implementation and always trying to design an alternative solution to a
solution that has not been proven broken.

[Markus] Of course we should give our specs a fair chance before
creating alternatives but I think we must also pay attention to what
people who deploy these things want rather than expecting them always do
things in the way it was originally designed in the IETF. In the worst
case they will do things differently anyway, without a proper open spec,
and then the interop is even worse.
 
The IETF has participants from service providers (people who deploy these things) as well as vendors (people who build these things). You cannot claim that IETF participants are different from those people.
 

The reason I sent my mail was to get
a feeling what people think the situation is with MSRP, MSRP relays,
TURN and SBCs. From my perspective I know for sure that there are
efforts going on outside IETF (between vendors etc.) to see how MSRP
could work through SBCs. On the other hand I've not heard of plans to
use relays. But certainly this is just a single view and I'd like to
understand how others implementing or deploying see it. It may be that
even if we wanted something, it is too complicated to add it as an
extension anymore.

       We spent years on designing MSRP and MSRP relay. Now that they
are finally becoming RFCs, we want an alternative solution. One that
will cause interoperability problem in the sense that different
implementors will choose different solutions. This will cause further
work in order to negotiate the NAT traversal solution between endpoints.


       - Why is not using comedia a mistake?

[Markus] MSRP fixes the direction of who opens the TCP connection. In
comedia the endpoints can negotiate this. So, with comedia you can get
end-to-end TCP always if at least one of the endpoints can receive
incoming TCP connections. For instance an MSRP chat server would
typically be such an endpoint.
 
That's a bogus limitation. What endpoints do you know that can receive TCP connections but can't open them?
 

       - Why is it valuable?
       - Why isnt MSRP Relay sufficient?

[Markus] It is sufficient but it is yet another box to put in your
network. Most networks already have SBCs and hopefully soon TURN relays
as well and these can handle TCP. So, logically they would like to use
them for MSRP and not require a specific solution just for that. In case
they would like to do something more than just NAT traversal, they could
probably use relay, but AFAIK that is a minority case.
 
MSRP Relay can be implemented in SBCs. Its a logical entity, not a physical box.
 
Hisham

       Config framework work is another example where people are
proposing something else before the config framework has been proven
broken.

[Markus] That has nothing to do with this discussion related to MSRP,
you should bring that up where it belongs.

       I don't know why you would want to standardise something that is
not any better than an existing solution.

[Markus] I don't know either, but I tried to explain the benefits I can
see. If there are not enough people who agree with them, this is
obviously going nowhere (in the IETF). But there are some who do
already.

       Hisham

Regards,
       Markus


       On 25/07/07, Markus.Isomaki@nokia.com <Markus.Isomaki@nokia.com
> wrote:

               Hi,

               Now that MSRP has been finally approved as an RFC, it
would be nice to
               get some actual implementations and even deployments for
it. Based on
               what I've heard there are several client implementations
under
               development (for instance to support file/image transfer
service). The
               problem is that I've got a sense that the interest to
support MSRP relay
               extension seems to be quite low. I'm not sure if there
are MSRP relay
               implementations under development. Instead it seems that
many people
               would rather have MSRP NAT traversal using SBCs (based
on comedia) or
               ICE/TURN.

               Personally I think that the decision in MSRP not to use
comedia has been
               a mistake. It's not possible to change that anymore in
the MSRP base
               spec, but I think it would be valuable to define how to
negotiate MSRP
               with comedia in an extension spec. This would allow MSRP
to work in
               situations where one of the endpoints can receive
incoming TCP
               connections, as well as with SBCs supporting comedia.

               Also the work started in

http://www.ietf.org/internet-drafts/draft-niemi-simple-msrp-ice-00.txt
               should be brought to completion.

               I would be interested in hearing comments whether people
think that MSRP
               relays are going to be sufficient for MSRP NAT traversal
(and especially
               if there are implementation plans) or if there is
interest in defining
               how MSRP works with comedia as an alternative mechanism.
My goal would
               be to do whatever is best to have MSRP deployable.

               Regards,
                      Markus


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




------=_Part_12755_32103882.1186030550465-- --===============2035431864== 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 --===============2035431864==-- From simple-bounces@ietf.org Thu Aug 02 04:13: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 1IGVoT-0007gJ-VH; Thu, 02 Aug 2007 04:13:41 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IGVoS-0007gD-ED for simple-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 04:13:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGVoS-0007ff-2K for simple@ietf.org; Thu, 02 Aug 2007 04:13:40 -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 1IGVoQ-0007sZ-Iy for simple@ietf.org; Thu, 02 Aug 2007 04:13:40 -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 l728DMKP029443; Thu, 2 Aug 2007 11:13:35 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 11:13:28 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 11:13:27 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP NAT traversal Date: Thu, 2 Aug 2007 11:13:26 +0300 Message-ID: In-Reply-To: <66cd252f0708012155k4860d927wfb9d842f12659e65@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP NAT traversal Thread-Index: AcfUwWnF2eEzu5OaS8KM5VUUgBmrFAAFkCLg References: <1FCC1736-3504-408C-A9ED-55C33FDE6D39@nostrum.com> <66cd252f0707262129t15383003rd9f0c090acf07a13@mail.gmail.com> <66cd252f0708012155k4860d927wfb9d842f12659e65@mail.gmail.com> From: To: X-OriginalArrivalTime: 02 Aug 2007 08:13:27.0650 (UTC) FILETIME=[01359C20:01C7D4DD] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hisham,=20 =20 The IETF has participants from service providers (people who deploy these things) as well as vendors (people who build these things). You cannot claim that IETF participants are different from those people. [Markus] True, but this does not mean that the initial specs always solve all deployment related problems in an optimal or even sufficient way. I've heard about protocols being extended and even obsolited for these reasons. =20 =09 - Why is not using comedia a mistake? =09 [Markus] MSRP fixes the direction of who opens the TCP connection. In comedia the endpoints can negotiate this. So, with comedia you can get=20 end-to-end TCP always if at least one of the endpoints can receive incoming TCP connections. For instance an MSRP chat server would typically be such an endpoint. =20 That's a bogus limitation. What endpoints do you know that can receive TCP connections but can't open them? [Markus] It's not bogus at all. The limitation is valid when the *other* endpoint is behind a NAT (or firewall) and that's why you can't open the connection. If you are not NATed yourself, opening the connection from that other endpoint will work, however. In practice the difference is that current MSRP will not work in the case where the SDP answerer is NAT'ed while the offerer is not, but MSRP+comedia would work in that case too (without relays).=20 =20 - Why is it valuable? - Why isnt MSRP Relay sufficient? =09 [Markus] It is sufficient but it is yet another box to put in your=20 network. Most networks already have SBCs and hopefully soon TURN relays as well and these can handle TCP. So, logically they would like to use them for MSRP and not require a specific solution just for that. In case=20 they would like to do something more than just NAT traversal, they could probably use relay, but AFAIK that is a minority case. =20 MSRP Relay can be implemented in SBCs. Its a logical entity, not a physical box. =20 [Markus] Great. Logical entities are so much easier to deploy than boxes ;) Hisham Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 02 04:44:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGWIe-0007sP-K1; Thu, 02 Aug 2007 04:44:52 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IGWIc-0007ry-FJ for simple-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 04:44:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGWIc-0007rp-3F for simple@ietf.org; Thu, 02 Aug 2007 04:44:50 -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 1IGWIa-0000Es-JA for simple@ietf.org; Thu, 02 Aug 2007 04:44:50 -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 l728ijlq021628 for ; Thu, 2 Aug 2007 11:44:46 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 11:44:24 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 11:44:23 +0300 Received: from [172.21.11.11] ([172.21.11.11]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 11:44:23 +0300 Message-ID: <46B19967.7010807@nsn.com> Date: Thu, 02 Aug 2007 11:44:23 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: SIMPLE mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Aug 2007 08:44:23.0321 (UTC) FILETIME=[53468890:01C7D4E1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Simple] Presence dictionary -06 sumitted X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org As I indicated verbally during the SIMPLE meeting in Chicago, I found an error in the presence dictionary. I have now fixed it and I have just submitted version -06. While this becomes generally available, you can fetch a copy from: http://people.nokia.net/~miguel/drafts/draft-garcia-simple-presence-dictionary-06.txt http://people.nokia.net/~miguel/drafts/draft-garcia-simple-presence-dictionary-06.html Changes in this version are: - There was something weird with the string "country", which apparently was part of the actual dictionary but didn't get an address in the Appendix A. - In the Appendix A there were 4 or 5 duplicated strings. Although this is not an error into the actual dictionary, I fixed the duplicated entries. Due to this, the dictionary itself changed: state_identifier, length, addresses of strings, etc. If you want to check track changes list, the draft is available at: http://people.nokia.net/~miguel/drafts/draft-garcia-simple-presence-dictionary-06-from-5.html /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 From simple-bounces@ietf.org Thu Aug 02 12:52: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 1IGduj-0000aR-Qv; Thu, 02 Aug 2007 12:52:41 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IGduh-0000aM-UK for simple-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 12:52:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGduh-0000aD-JW for simple@ietf.org; Thu, 02 Aug 2007 12:52:39 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGduh-0006S6-3p for simple@ietf.org; Thu, 02 Aug 2007 12:52:39 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l72GqbVa027663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Aug 2007 09:52:37 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l72GqaGY009265; Thu, 2 Aug 2007 09:52:37 -0700 Received: from NAEX15.na.qualcomm.com ([10.47.5.244]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 09:52:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Presence dictionary -06 sumitted Date: Thu, 2 Aug 2007 09:52:33 -0700 Message-ID: In-Reply-To: <46B19967.7010807@nsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Presence dictionary -06 sumitted Thread-Index: AcfU4ZnF17mJA9qZTFaDM0Dzci53BwAQ1ZWg References: <46B19967.7010807@nsn.com> From: "Jin, Haipeng" To: "Miguel Garcia" , "SIMPLE mailing list" X-OriginalArrivalTime: 02 Aug 2007 16:52:36.0536 (UTC) FILETIME=[87646B80:01C7D525] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, Miguel, I am looking at the binary representation of the dictionary. Near address location 0950 (toward the end of the string subset), terms such as "sick", "hospital" are included. But my understanding is that these are low priority strings and should appear toward the beginning of the string subset. Is this an oversight, or is it intentional? Thanks, Haipeng -----Original Message----- From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com]=20 Sent: Thursday, August 02, 2007 1:44 AM To: SIMPLE mailing list Subject: [Simple] Presence dictionary -06 sumitted As I indicated verbally during the SIMPLE meeting in Chicago, I found an error in the presence dictionary. I have now fixed it and I have just=20 submitted version -06. While this becomes generally available, you can fetch a copy from: http://people.nokia.net/~miguel/drafts/draft-garcia-simple-presence-dict ionary-06.txt http://people.nokia.net/~miguel/drafts/draft-garcia-simple-presence-dict ionary-06.html Changes in this version are: - There was something weird with the string "country", which apparently=20 was part of the actual dictionary but didn't get an address in the=20 Appendix A. - In the Appendix A there were 4 or 5 duplicated strings. Although this=20 is not an error into the actual dictionary, I fixed the duplicated entries. Due to this, the dictionary itself changed: state_identifier, length,=20 addresses of strings, etc. If you want to check track changes list, the=20 draft is available at: http://people.nokia.net/~miguel/drafts/draft-garcia-simple-presence-dict ionary-06-from-5.html /Miguel --=20 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 02 15:36: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 1IGgTD-0005ZG-FQ; Thu, 02 Aug 2007 15:36:27 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IGgTC-0005ZA-Py for simple-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 15:36:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGgTC-0005Z2-1q for simple@ietf.org; Thu, 02 Aug 2007 15:36:26 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGgTB-0001K4-Bi for simple@ietf.org; Thu, 02 Aug 2007 15:36:25 -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 l72JaH1Z011933; Thu, 2 Aug 2007 22:36:22 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 22:36:17 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 22:36:16 +0300 Received: from [10.162.86.141] ([10.162.86.141]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 22:36:16 +0300 Message-ID: <46B23230.3080609@nsn.com> Date: Thu, 02 Aug 2007 22:36:16 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Jin, Haipeng" Subject: Re: [Simple] Presence dictionary -06 sumitted References: <46B19967.7010807@nsn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Aug 2007 19:36:16.0753 (UTC) FILETIME=[64B29E10:01C7D53C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 Haipeng, Yes, these strings have an allocated priority of 5 and ideally should be located towards the top of the dictionary. But they are embedded with the priority 1 strings. This might be cause due to either : a) The algorithm is optimizing the strings and perhaps they are merged with other strings, which happen to have priority 1; For example, "hospital" is merged with "lang" to form "hospitalang". Notice that "lang" is allocated priority 1, so the result is promoted to priority 1. But I don't have an excuse for "sick" b) An error in the script that generates the dictionary. I need to investigate this a bit more... /Miguel Jin, Haipeng wrote: > Hi, Miguel, > > I am looking at the binary representation of the dictionary. Near > address location 0950 (toward the end of the string subset), terms such > as "sick", "hospital" are included. But my understanding is that these > are low priority strings and should appear toward the beginning of the > string subset. Is this an oversight, or is it intentional? > > Thanks, > Haipeng > > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > Sent: Thursday, August 02, 2007 1:44 AM > To: SIMPLE mailing list > Subject: [Simple] Presence dictionary -06 sumitted > > As I indicated verbally during the SIMPLE meeting in Chicago, I found an > > error in the presence dictionary. I have now fixed it and I have just > submitted version -06. > > While this becomes generally available, you can fetch a copy from: > > http://people.nokia.net/~miguel/drafts/draft-garcia-simple-presence-dict > ionary-06.txt > http://people.nokia.net/~miguel/drafts/draft-garcia-simple-presence-dict > ionary-06.html > > Changes in this version are: > - There was something weird with the string "country", which apparently > was part of the actual dictionary but didn't get an address in the > Appendix A. > - In the Appendix A there were 4 or 5 duplicated strings. Although this > is not an error into the actual dictionary, I fixed the duplicated > entries. > > Due to this, the dictionary itself changed: state_identifier, length, > addresses of strings, etc. If you want to check track changes list, the > draft is available at: > > http://people.nokia.net/~miguel/drafts/draft-garcia-simple-presence-dict > ionary-06-from-5.html > > /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 From simple-bounces@ietf.org Fri Aug 03 01:01:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGpHM-0006Nv-Vs; Fri, 03 Aug 2007 01:00:48 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IGpHL-0006Np-Ol for simple-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 01:00:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGpHL-0006Nh-BQ for simple@ietf.org; Fri, 03 Aug 2007 01:00:47 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGpHK-00050g-Fr for simple@ietf.org; Fri, 03 Aug 2007 01:00:47 -0400 Received: by py-out-1112.google.com with SMTP id f31so2276502pyh for ; Thu, 02 Aug 2007 22:00:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=sWtmFo/veB85FLLj7x3soLFErRnz4OvTFRNGdBu9J1riPc37E/r+sCc/ta9NRo5YlFgYn9hCk0FIFfMN7H/2tnK9j4hQ+ye66MxWTGE/PTCGJymZRaL2PRtMiAXX/KZ7Bq2nYVvaicDpakKyTYqEwIhcYvex5ZE7KfzjtHuPhgg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=DFV4FqOdj7+miVqpeO0/3LXJbhNYUMeY4v0L0v376fg1Glb90Jkz8bCpfNXj6OVu3nKJJlZnDFQo+Av4IEvV8Knw2bqdBXkHwihIF4VRM9xH49oafLbwdlt666ezXPd8iGU27LybpIAt3z+tqupB0QHCwsUwo4IegOyB+3nXqxE= Received: by 10.65.158.9 with SMTP id k9mr4401017qbo.1186117245718; Thu, 02 Aug 2007 22:00:45 -0700 (PDT) Received: by 10.65.213.1 with HTTP; Thu, 2 Aug 2007 22:00:45 -0700 (PDT) Message-ID: <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> Date: Fri, 3 Aug 2007 15:00:45 +1000 From: "Hisham Khartabil" To: "Miguel Garcia" Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI In-Reply-To: <46B07936.70000@nsn.com> MIME-Version: 1.0 References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com> <66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com> <46B07936.70000@nsn.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Paul Kyzivat , 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: , Content-Type: multipart/mixed; boundary="===============0529785892==" Errors-To: simple-bounces@ietf.org --===============0529785892== Content-Type: multipart/alternative; boundary="----=_Part_24139_14574660.1186117245397" ------=_Part_24139_14574660.1186117245397 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 01/08/07, Miguel Garcia wrote: > > Hisham, > > I agree with your text below. However, I want to highlight a problem: > > The Conference framework (RFC 4353) provide high-level guidelines for > the creation of conference URIs. It says that the conference URI has to > resolve to the focus, but does not say that the domain part has to > resolve to the conference. Remember that a focus will typically host > several conferences. > > So, sip:chat34@focus.example.com is a valid conference URI, so is valid > also sip:chat34.focus.example.com, providing that chat34 is a (perhaps > virtual) focus that handles a number of conferences. Something is messed up here in your defintion of a focus. In my definition, the focus IS the chatroom. A focus is one instance of a conference, not an instance of a conference server. Ideally I would like to have a conference URI where the conference is > part of the hostname (e.g., sip:chat34.focus.example.com), but I suspect > this has some impact of the DNS configuration. I believe most network > operators will configure the focus on DNS, but not each of the chat > rooms (e.g., sip:chat34@focus.example.com). So, we need to leave with it > and have a mechanism to embed the nickname in the URI, perhaps using > separators "/" like Jonathan proposed, or percent-encoding the '@' sign. you might have a point with the DNS issue. I don't really care which way we represent it (although I do prefer a parameter rather than a username with seperators), but I do care that a message sent to a nickname outside the session IS routed via the chatroom to the correct recipient. This requires 2 pieces of information: nickname, conference ID. Hisham /Miguel > > Hisham Khartabil wrote: > > I think the nickname needs to include the conference identifier for the > > reasons as follows: > > > > I am in a chatroom where Alice is. I want to send a private message to > > Alice, so my client just happens to pick Alice's nickname and send the > > message to her in a normal SIP MESSAGE. > > > > The way I think the MESSAGE should reach its destination of Alice's > > client is via the chatroom server. So, in order for that to happen, the > > domain part of the nickname should be routable to the chatroom. > > > > So Miguel, looking at your examples 'sip:chat34@example.com > > ' and 'sip:chat34.example.com > > ' being both valid chatroom URIs. In both > > cases, I think the nickname URI should look like @ > > chat34.example.com . The latter chatroom URI > > is ok since it can be routable to the chatroom , but the former is > > troublesom. Guidence is need to say that when a nickname is created and > > the chatroom URI is in the form room@domain.com > > , the 'room' should be put as a subdomain in the > > form nickname@room.domain.com . > > Regards, > > Hisham > > > > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Siemens Networks Espoo, Finland > > ------=_Part_24139_14574660.1186117245397 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 01/08/07, Miguel Garcia <Miguel.Garcia@nsn.com> wrote:
Hisham,

I agree with your text below. However, I want to highlight a problem:

The Conference framework (RFC 4353) provide high-level guidelines for
the creation of conference URIs. It says that the conference URI has to
resolve to the focus, but does not say that the domain part has to
resolve to the conference. Remember that a focus will typically host
several conferences.

So, sip:chat34@focus.example.com is a valid conference URI, so is valid
also sip:chat34.focus.example.com , providing that chat34 is a (perhaps
virtual) focus that handles a number of conferences.
 
 
Something is messed up here in your defintion of a focus. In my definition, the focus IS the chatroom. A focus is one instance of a conference, not an instance of a conference server.
 

Ideally I would like to have a conference URI where the conference is
part of the hostname (e.g., sip: chat34.focus.example.com), but I suspect
this has some impact of the DNS configuration. I believe most network
operators will configure the focus on DNS, but not each of the chat
rooms (e.g., sip:chat34@focus.example.com). So, we need to leave with it
and have a mechanism to embed the nickname in the URI, perhaps using
separators "/" like Jonathan proposed, or percent-encoding the '@' sign.
 
 
you might have a point with the DNS issue. I don't really care which way we represent it (although I do prefer a parameter rather than a username with seperators), but I do care that a message sent to a nickname outside the session IS routed via the chatroom to the correct recipient. This requires 2 pieces of information: nickname, conference ID.
 
Hisham

/Miguel

Hisham Khartabil wrote:
> I think the nickname needs to include the conference identifier for the
> reasons as follows:
>
> I am in a chatroom where Alice is. I want to send a private message to
> Alice, so my client just happens to pick Alice's nickname and send the
> message to her in a normal SIP MESSAGE.
>
> The way I think the MESSAGE should reach its destination of Alice's
> client is via the chatroom server. So, in order for that to happen, the
> domain part of the nickname should be routable to the chatroom.
>
> So Miguel, looking at your examples 'sip:chat34@example.com
> <mailto:chat34@example.com>' and 'sip: chat34.example.com
> <http://chat34.example.com/>' being both valid chatroom URIs. In both
> cases, I think the nickname URI should look like <nickname>@
> chat34.example.com <http://chat34.example.com>. The latter chatroom URI
> is ok since it can be routable to the chatroom , but the former is
> troublesom. Guidence is need to say that when a nickname is created and
> the chatroom URI is in the form room@domain.com
> <mailto: room@domain.com>, the 'room' should be put as a subdomain in the
> form nickname@room.domain.com <mailto:nickname@room.domain.com >.
> Regards,
> Hisham
>


--
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland


------=_Part_24139_14574660.1186117245397-- --===============0529785892== 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 --===============0529785892==-- From simple-bounces@ietf.org Fri Aug 03 02:17: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 1IGqTY-0004PE-OG; Fri, 03 Aug 2007 02:17:28 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IGqTX-0004KY-G8 for simple-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 02:17:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGqTX-0004KP-4n for simple@ietf.org; Fri, 03 Aug 2007 02:17:27 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGqTV-0006mP-Qe for simple@ietf.org; Fri, 03 Aug 2007 02:17:27 -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 l736HJog005795; Fri, 3 Aug 2007 09:17:19 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 09:17:18 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 09:17:18 +0300 Received: from [10.144.23.96] ([10.144.23.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 09:17:18 +0300 Message-ID: <46B2C86E.6060200@nsn.com> Date: Fri, 03 Aug 2007 09:17:18 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com> <66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com> <46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> In-Reply-To: <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2007 06:17:18.0456 (UTC) FILETIME=[F1A8BF80:01C7D595] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Paul Kyzivat , 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 Inline... Hisham Khartabil wrote: > > > On 01/08/07, *Miguel Garcia* > wrote: > > Hisham, > > I agree with your text below. However, I want to highlight a problem: > > The Conference framework (RFC 4353) provide high-level guidelines for > the creation of conference URIs. It says that the conference URI has to > resolve to the focus, but does not say that the domain part has to > resolve to the conference. Remember that a focus will typically host > several conferences. > > So, sip:chat34@focus.example.com > is a valid conference URI, so > is valid > also sip:chat34.focus.example.com , > providing that chat34 is a (perhaps > virtual) focus that handles a number of conferences. > > > > Something is messed up here in your defintion of a focus. In my > definition, the focus IS the chatroom. A focus is one instance of a > conference, not an instance of a conference server. Yeap, you are right: the focus is the SIP UA that instantiates the conference. Still we have one problem: the SIP conference framework does not provide any requirements for the creation of the SIP URI of the focus. Assume a conference server whose URI is sip:conf.example.com, you can still have two types of URIs for a given focus, for example: sip:chat32@conf.example.com sip:chat32.conf.example.com So, most likely implementations use the former but not the latter. > > > Ideally I would like to have a conference URI where the conference is > part of the hostname (e.g., sip: chat34.focus.example.com > ), but I suspect > this has some impact of the DNS configuration. I believe most network > operators will configure the focus on DNS, but not each of the chat > rooms (e.g., sip:chat34@focus.example.com > ). So, we need to leave with it > and have a mechanism to embed the nickname in the URI, perhaps using > separators "/" like Jonathan proposed, or percent-encoding the '@' > sign. > > > > you might have a point with the DNS issue. I don't really care which way > we represent it (although I do prefer a parameter rather than a username > with seperators), but I do care that a message sent to a nickname > outside the session IS routed via the chatroom to the correct recipient. > This requires 2 pieces of information: nickname, conference ID. Right. Earlier versions of the draft had that property, but then we introduced this ability to use a general nickname, although not fully supported, which won't have the property you requested. I think I have an idea how to get your comments into the draft. Thanks. /Miguel > > Hisham > > /Miguel > > Hisham Khartabil wrote: > > I think the nickname needs to include the conference identifier > for the > > reasons as follows: > > > > I am in a chatroom where Alice is. I want to send a private > message to > > Alice, so my client just happens to pick Alice's nickname and > send the > > message to her in a normal SIP MESSAGE. > > > > The way I think the MESSAGE should reach its destination of Alice's > > client is via the chatroom server. So, in order for that to > happen, the > > domain part of the nickname should be routable to the chatroom. > > > > So Miguel, looking at your examples 'sip:chat34@example.com > > > >' and > 'sip: chat34.example.com > > ' being both valid chatroom URIs. In both > > cases, I think the nickname URI should look like @ > > chat34.example.com > . The latter chatroom URI > > is ok since it can be routable to the chatroom , but the former is > > troublesom. Guidence is need to say that when a nickname is > created and > > the chatroom URI is in the form room@domain.com > > > >, the 'room' > should be put as a subdomain in the > > form nickname@room.domain.com > >. > > Regards, > > Hisham > > > > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Siemens Networks Espoo, Finland > > -- 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 From simple-bounces@ietf.org Fri Aug 03 09:32: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 1IGxGY-0001gK-8E; Fri, 03 Aug 2007 09:32:30 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IGxGW-0001gC-G7 for simple-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 09:32:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGxGW-0001g3-5O for simple@ietf.org; Fri, 03 Aug 2007 09:32:28 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGxGV-0002ew-IY for simple@ietf.org; Fri, 03 Aug 2007 09:32:28 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IGxGH-0005Ef-7Y; Fri, 03 Aug 2007 08:32:13 -0500 From: "Brian Rosen" To: "'Hisham Khartabil'" , "'Miguel Garcia'" References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Fri, 3 Aug 2007 09:32:15 -0400 Message-ID: <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> Thread-Index: AcfVi2hGO8MOzYl4TcSap6BsGhYPLwARtrcA 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: 6d95a152022472c7d6cdf886a0424dc6 Cc: 'Paul Kyzivat' , '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=92m working on the more generalized nickname mechanism and I did run = across a related issue: Do we permit nicknames with syntax that doesn=92t conform to the syntax = of the user part of a URI? The ability to form a URI with the nickname and the domain of the = conference can be useful but the primary purpose of nicknames is in user = interfaces. Do we want to restrict what the user interface can do in order to allow = a URI to be created from the nickname? Brian ________________________________________ From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com]=20 Sent: Friday, August 03, 2007 1:01 AM To: Miguel Garcia Cc: Paul Kyzivat; SIMPLE mailing list Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI On 01/08/07, Miguel Garcia wrote:=20 Hisham, I agree with your text below. However, I want to highlight a problem: The Conference framework (RFC 4353) provide high-level guidelines for=20 the creation of conference URIs. It says that the conference URI has to resolve to the focus, but does not say that the domain part has to resolve to the conference. Remember that a focus will typically host several conferences. So, sip:chat34@focus.example.com is a valid conference URI, so is valid also sip:chat34.focus.example.com , providing that chat34 is a (perhaps virtual) focus that handles a number of conferences. =A0 =A0 Something is messed up here in your defintion of a focus. In my = definition, the focus IS the chatroom. A focus is one instance of a conference, not = an instance of a conference server. =A0 Ideally I would like to have a conference URI where the conference is part of the hostname (e.g., sip: chat34.focus.example.com), but I = suspect this has some impact of the DNS configuration. I believe most network operators will configure the focus on DNS, but not each of the chat rooms (e.g., sip:chat34@focus.example.com). So, we need to leave with it and have a mechanism to embed the nickname in the URI, perhaps using separators "/" like Jonathan proposed, or percent-encoding the '@' sign. = =A0 =A0 you might have a point with the DNS issue. I don't really care which way = we represent it (although I do prefer a parameter rather than a username = with seperators), but I do care that a message sent to a nickname outside the session IS routed via the chatroom to the correct recipient. This = requires=A02 pieces of information: nickname, conference ID.=20 =A0 Hisham /Miguel Hisham Khartabil wrote: > I think the nickname needs to include the conference identifier for = the=20 > reasons as follows: > > I am in a chatroom where Alice is. I want to send a private message to > Alice, so my client just happens to pick Alice's nickname and send the > message to her in a normal SIP MESSAGE.=20 > > The way I think the MESSAGE should reach its destination of Alice's > client is via the chatroom server. So, in order for that to happen, = the > domain part of the nickname should be routable to the chatroom.=20 > > So Miguel, looking at your examples 'sip:chat34@example.com > ' and 'sip: chat34.example.com > ' being both valid chatroom URIs. In both > cases, I think the nickname URI should look like @=20 > chat34.example.com . The latter chatroom = URI > is ok since it can be routable to the chatroom , but the former is=20 > troublesom. Guidence is need to say that when a nickname is created = and > the chatroom URI is in the form room@domain.com > , the 'room' should be put as a subdomain in = the > form nickname@room.domain.com . > Regards, > Hisham > -- Miguel A. Garcia=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 tel:+358-50-4804586 Nokia Siemens Networks=A0=A0=A0=A0 Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 03 12:44:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH0Ge-0003Hn-4C; Fri, 03 Aug 2007 12:44:48 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IH0Gc-0003Hh-8H for simple-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 12:44:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH0Gb-0003HZ-TA for simple@ietf.org; Fri, 03 Aug 2007 12:44:45 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IH0Ga-0008OO-Ik for simple@ietf.org; Fri, 03 Aug 2007 12:44:45 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 03 Aug 2007 12:41:19 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswMAGz4skZAZnmf/2dsb2JhbACICJtY X-IronPort-AV: i="4.19,217,1183348800"; d="scan'208"; a="67017960:sNHT2660447868" 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 l73GfJjv002071; Fri, 3 Aug 2007 12:41:19 -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 l73GfAtn008984; Fri, 3 Aug 2007 16:41:10 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); Fri, 3 Aug 2007 12:41:10 -0400 Received: from [10.86.243.18] ([10.86.243.18]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 12:41:09 -0400 Message-ID: <46B35AA4.7090106@cisco.com> Date: Fri, 03 Aug 2007 12:41:08 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> In-Reply-To: <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 03 Aug 2007 16:41:09.0812 (UTC) FILETIME=[187C6740:01C7D5ED] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4257; t=1186159279; x=1187023279; 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]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20 |To:=20Brian=20Rosen=20; bh=11nBaPGF17RFm70VQcxWBLY9fnaEwYWVjbT2IXeb630=; b=c2e2pkmo/1+ToIsuP2aJP2SLtgSrh4GccKriv4I5lhgOPBwhqhOa8LnfEYLFXY/fAU3F0vEw f3TF1EJ/eSIihPqVr2d3l5LeFe5NXql8RDTU03DbbfoiqlHkH2GmjL/+; 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: e1b0e72ff1bbd457ceef31828f216a86 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 I'm neutral about whether more is allowed than what is permitted in the user part of a URI. (But that covers pretty much everything once you take into account escaping.) But it should *at least* allow everything permitted in a URI. Paul Brian Rosen wrote: > I’m working on the more generalized nickname mechanism and I did run across > a related issue: > Do we permit nicknames with syntax that doesn’t conform to the syntax of the > user part of a URI? > > The ability to form a URI with the nickname and the domain of the conference > can be useful but the primary purpose of nicknames is in user interfaces. > Do we want to restrict what the user interface can do in order to allow a > URI to be created from the nickname? > > Brian > > ________________________________________ > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > Sent: Friday, August 03, 2007 1:01 AM > To: Miguel Garcia > Cc: Paul Kyzivat; SIMPLE mailing list > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > > On 01/08/07, Miguel Garcia wrote: > Hisham, > > I agree with your text below. However, I want to highlight a problem: > > The Conference framework (RFC 4353) provide high-level guidelines for > the creation of conference URIs. It says that the conference URI has to > resolve to the focus, but does not say that the domain part has to > resolve to the conference. Remember that a focus will typically host > several conferences. > > So, sip:chat34@focus.example.com is a valid conference URI, so is valid > also sip:chat34.focus.example.com , providing that chat34 is a (perhaps > virtual) focus that handles a number of conferences. > > > Something is messed up here in your defintion of a focus. In my definition, > the focus IS the chatroom. A focus is one instance of a conference, not an > instance of a conference server. > > > Ideally I would like to have a conference URI where the conference is > part of the hostname (e.g., sip: chat34.focus.example.com), but I suspect > this has some impact of the DNS configuration. I believe most network > operators will configure the focus on DNS, but not each of the chat > rooms (e.g., sip:chat34@focus.example.com). So, we need to leave with it > and have a mechanism to embed the nickname in the URI, perhaps using > separators "/" like Jonathan proposed, or percent-encoding the '@' sign. > > > you might have a point with the DNS issue. I don't really care which way we > represent it (although I do prefer a parameter rather than a username with > seperators), but I do care that a message sent to a nickname outside the > session IS routed via the chatroom to the correct recipient. This requires 2 > pieces of information: nickname, conference ID. > > Hisham > > /Miguel > > Hisham Khartabil wrote: >> I think the nickname needs to include the conference identifier for the >> reasons as follows: >> >> I am in a chatroom where Alice is. I want to send a private message to >> Alice, so my client just happens to pick Alice's nickname and send the >> message to her in a normal SIP MESSAGE. >> >> The way I think the MESSAGE should reach its destination of Alice's >> client is via the chatroom server. So, in order for that to happen, the >> domain part of the nickname should be routable to the chatroom. >> >> So Miguel, looking at your examples 'sip:chat34@example.com >> ' and 'sip: chat34.example.com >> ' being both valid chatroom URIs. In both >> cases, I think the nickname URI should look like @ >> chat34.example.com . The latter chatroom URI >> is ok since it can be routable to the chatroom , but the former is >> troublesom. Guidence is need to say that when a nickname is created and >> the chatroom URI is in the form room@domain.com >> , the 'room' should be put as a subdomain in the >> form nickname@room.domain.com . >> Regards, >> Hisham >> > > > -- > 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 From RhondairvinMayes@adobe.com Fri Aug 03 12:48:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH0KT-0004vN-Fy for simple-archive@lists.ietf.org; Fri, 03 Aug 2007 12:48:45 -0400 Received: from cpe-74-71-196-247.twcny.res.rr.com ([74.71.196.247] helo=microspa-567066) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IH0KT-0008VK-3w for simple-archive@lists.ietf.org; Fri, 03 Aug 2007 12:48:45 -0400 Message-ID: <01e201c7d5ee$28c48910$0a00a8c0@microspa567066> From: "Carrie Pike" To: Subject: Fw: Thank you, we are ready to lend some cash Date: Fri, 3 Aug 2007 12:48:38 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DE_01C7D5EE.28C48910" 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.9 (+++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 This is a multi-part message in MIME format. ------=_NextPart_000_01DE_01C7D5EE.28C48910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit history does not matter to us! If you have your own business and wish IMMEDIATE ready money to spend = ANY way you like or require Extra money to give your business a boost or = wish A low interest loan - NO STRINGS ATTACHED, here is our best deal we = can offer you THIS NIGHT (hurry, this lot will expire NOW): $49,000+ loan Hurry, when the deal is gone, it is gone. Simply Call Us... Don't worry about approval, your credit history will not disqualify you! Call Us Free on 877-699-7808 ------=_NextPart_000_01DE_01C7D5EE.28C48910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your credit history does not = matter to us!
=20
 
If you have your own business and = wish IMMEDIATE=20 ready money to spend ANY way you like or require Extra money to give = your=20 business a boost or wish A low interest loan - NO STRINGS ATTACHED, = here is=20 our best deal we can offer you THIS NIGHT (hurry, this lot will expire=20 NOW):
=20
 
$49,000+ loan
 
Hurry, when the deal is gone, it = is gone.=20 Simply Call Us...
=20
 
Don't worry about approval, your = credit history=20 will not disqualify you!
=20
 
Call Us Free on = 877-699-7808
------=_NextPart_000_01DE_01C7D5EE.28C48910-- From simple-bounces@ietf.org Mon Aug 06 01:26: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 1IHv6P-0004BW-8q; Mon, 06 Aug 2007 01:26:01 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IHv6M-0004BQ-Tm for simple-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 01:25:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHv6L-0004BH-LV for simple@ietf.org; Mon, 06 Aug 2007 01:25:57 -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 1IHv6K-0003wL-5g for simple@ietf.org; Mon, 06 Aug 2007 01:25:57 -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 l765PXMY001140; Mon, 6 Aug 2007 08:25:35 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 08:25:31 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 08:25:30 +0300 Received: from [10.144.23.96] ([10.144.23.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 08:25:30 +0300 Message-ID: <46B6B0CA.6040508@nsn.com> Date: Mon, 06 Aug 2007 08:25:30 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> In-Reply-To: <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 06 Aug 2007 05:25:30.0627 (UTC) FILETIME=[347CED30:01C7D7EA] X-Nokia-AV: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext14.nokia.com id l765PXMY001140 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'Paul Kyzivat' , '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 Rosen wrote: > I=92m working on the more generalized nickname mechanism and I did run = across > a related issue: > Do we permit nicknames with syntax that doesn=92t conform to the syntax= of the > user part of a URI? Can't they be percent-encoded to be represented in a username? If yes, I=20 don't see a problem. /Miguel >=20 > The ability to form a URI with the nickname and the domain of the confe= rence > can be useful but the primary purpose of nicknames is in user interface= s. > Do we want to restrict what the user interface can do in order to allow= a > URI to be created from the nickname? >=20 > Brian >=20 > --=20 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 From simple-bounces@ietf.org Mon Aug 06 01:32:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHvCy-00076N-JQ; Mon, 06 Aug 2007 01:32:48 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IHvCw-00076H-Cx for simple-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 01:32:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHvCt-000764-Ck for simple@ietf.org; Mon, 06 Aug 2007 01:32:43 -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 1IHvCr-000444-T5 for simple@ietf.org; Mon, 06 Aug 2007 01:32:43 -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 l765W5Su006333; Mon, 6 Aug 2007 08:32:35 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 08:32:28 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 08:32:28 +0300 Received: from [10.144.23.96] ([10.144.23.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 08:32:28 +0300 Message-ID: <46B6B26C.3080002@nsn.com> Date: Mon, 06 Aug 2007 08:32:28 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Kyzivat , Brian Rosen , "'Hisham Khartabil'" , Niemi Aki , Jonathan Rosenberg Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> In-Reply-To: <46B35AA4.7090106@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Aug 2007 05:32:28.0468 (UTC) FILETIME=[2D8A6740:01C7D7EB] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Let me try to seek consensus on the issue of the Nickname URI. We have been hearing that we need to allow URIs to be issued by any entity as well as the chat server. We agreed that the MSRP chat draft will tackle only the latter. We haven't really agreed whether we envision MSRP chat operations (namely the NICKNAME method) with domain URIs in the future. The current version of the draft leaves open space for it, but this has created some misunderstanding. Since there is current work on generalized nicknames I would suggest that we take the assumption that the MSRP NICKNAME method only deals with chat room server scoped nicknames. Domain nicknames are not considered with the NICKNAME method. We are having discussions on the representation of a nickname URI. Some of these problems come from the fact that we don't really know how to represent domain nicknames and we don't know the relation of them to the chat room server. I've been thinking that we should decouple the nickname itself from its representation in a URI. So, my suggestion is that the MSRP chat draft goes ahead with its representation of nicknames in a URI, for the purpose of reservation/validation (NICKNAME method), having into account that those nicknames are scoped to the focus of the conference. Other representation of nicknames (domain-scoped nicknames) may appear in From and To headers in CPIM, but not in NICKNAME method. Representation of chat room scoped nicknames. We need a mechanism to identify that a nickname URI is effectively a nickname URI, and be able to extract the nickname (for rendering in the UI) from the rest of teh URI. Jonathan proposed: sip:"msrp-nicknames" "/" "/" @ domain which is correct in my opinion. While there have been other suggestions, I haven't heard anyone indicating that Jonathan's proposal wouldn't work. So, I suggest we go for it. /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 From simple-bounces@ietf.org Mon Aug 06 03:59: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 1IHxUb-0001f9-Ue; Mon, 06 Aug 2007 03:59:09 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IHxUZ-0001df-S8 for simple-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 03:59:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHxUW-0001dV-EQ for simple@ietf.org; Mon, 06 Aug 2007 03:59:04 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHxUV-0000gp-TH for simple@ietf.org; Mon, 06 Aug 2007 03:59:04 -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 l767wnNo007384; Mon, 6 Aug 2007 10:58:56 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 10:58:49 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 10:58:48 +0300 Received: from [10.144.23.96] ([10.144.23.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 10:58:47 +0300 Message-ID: <46B6D4B7.3090503@nsn.com> Date: Mon, 06 Aug 2007 10:58:47 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Aug 2007 07:58:47.0866 (UTC) FILETIME=[9E7839A0:01C7D7FF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: SIMPLE mailing list Subject: [Simple] SIMPLE made simple misses presence dictionary X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jonathan: I am missing a reference to the Sigcomp presence dictionary draft, http://tools.ietf.org/wg/simple/draft-garcia-simple-presence-dictionary-05.txt (soon to be -06) in Section 2.5 of the 'SIMPLE made simple' draft. Thanks, 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 From dpchug@lucky-cab.com Mon Aug 06 10:55:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II3zp-0000FM-F9 for simple-archive@lists.ietf.org; Mon, 06 Aug 2007 10:55:49 -0400 Received: from pool-71-176-64-167.syrcny.fios.verizon.net ([71.176.64.167] helo=lucky-cab.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1II3zp-0002F8-2c for simple-archive@lists.ietf.org; Mon, 06 Aug 2007 10:55:49 -0400 Message-ID: <001201c7d80f$f72d5200$0642221c@Dell> From: "Fannie Goddard" To: "simple-archive" Subject: Awesome news Date: Mon, 6 Aug 2007 09:55:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.4682 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2720.2869 X-Spam-Score: 1.2 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Hi James, hope I hit your correct email adress. I was going to mention about these incredible opportunities for future prosperity.There is a company outhere known as Exchange Mobile Tele Co (EXMT). This one as you can see is climbing, but by just looking at it I can tell it's gonna explode.So you do have a window to digg in while it's still in it's low.I got a few shares of mine and made 5K. So what a hey, go ahead and do the same make some money while it's there. I hope it was a helper.I'll email you later this week. Maryanne. From simple-bounces@ietf.org Mon Aug 06 16:58: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 1II9eW-0003sk-2D; Mon, 06 Aug 2007 16:58:12 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1II9eV-0003se-LW for simple-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 16:58:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II9eV-0003sW-9u for simple@ietf.org; Mon, 06 Aug 2007 16:58:11 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1II9eU-0004w3-L0 for simple@ietf.org; Mon, 06 Aug 2007 16:58:11 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1II9eB-0007Cb-OL; Mon, 06 Aug 2007 15:57:52 -0500 From: "Brian Rosen" To: "'Miguel Garcia'" , "'Paul Kyzivat'" , "'Hisham Khartabil'" , "'Niemi Aki'" , "'Jonathan Rosenberg'" References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Mon, 6 Aug 2007 16:57:53 -0400 Message-ID: <03f601c7d86c$7846c540$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: AcfX6zIHKF+RoTnnSXGSsHN9xF24bwAee+3g In-reply-to: <46B6B26C.3080002@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: b5d20af10c334b36874c0264b10f59f1 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 Having agreed to proceed with the nickname stuff in MSRP chat, BUT having the benefit of the discussion on generalizing nicknames in the Chicago meeting, I'd suggest we simplify as much as possible the MSRP mechanism. Specifically, I suggest the following: 1. We don't need a display name on a nick name. Just delete it. 2. We agree that there is a nickname, scoped within a domain, and you need to be able to form a URI from it. The domain in MSRP chat is always the chat itself. There is the complication that the domain of the chat may have content prior to the "@". This problem exists in XCON also. This means there needs to be a construction rule to form URI from the nick and the domain, handling this problem. OTOH, there really isn't a reason why the domain needs to be mentioned in the Set-Nickname. You can't use a NICKNAME method outside the domain of a chat, so we know a-priori what the chat domain is. 4. Jonathan proposed a construction rule. I don't understand why we need a prefix. We could easily put a rule that said, for example, in an MSRP From: or To:, a slash must be escaped unless it separates nick from chat domain user-part. You already imply a rule that says you can't have "msrp-nickname" with slashes as a URI in From:/To:. So: I propose that Set-Nickname simply have the nickname as the parameter: Set-Nickname: joebob I propose a construction rule from nickname+chat-domain to a URI useable in MSRP From:/To: be to separate the nick from the domain with a slash IFF the domain has a userpart. So, for example: sip:joebob/chat34@msrp.example.com Include the rule that a normal URI in From:/To: that has a slash needs the slash to be escaped. One other thought: the URI construction rule bothers me. I don't like forcing new syntax on the user-part, and restricting what the URI can look like. Consider making the nick a parameter to the domain URI in From:/To: like: sip:chat34@msrp.example.com;nickname=joebob You could allow this syntax always (at least as an alternative) sip:chat34.example.com;nickname=joebob Brian > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > Sent: Monday, August 06, 2007 1:32 AM > To: Paul Kyzivat; Brian Rosen; 'Hisham Khartabil'; Niemi Aki; Jonathan > Rosenberg > Cc: 'SIMPLE mailing list' > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > Let me try to seek consensus on the issue of the Nickname URI. > > We have been hearing that we need to allow URIs to be issued by any > entity as well as the chat server. We agreed that the MSRP chat draft > will tackle only the latter. > > We haven't really agreed whether we envision MSRP chat operations > (namely the NICKNAME method) with domain URIs in the future. The current > version of the draft leaves open space for it, but this has created some > misunderstanding. Since there is current work on generalized nicknames I > would suggest that we take the assumption that the MSRP NICKNAME method > only deals with chat room server scoped nicknames. Domain nicknames are > not considered with the NICKNAME method. > > We are having discussions on the representation of a nickname URI. Some > of these problems come from the fact that we don't really know how to > represent domain nicknames and we don't know the relation of them to the > chat room server. I've been thinking that we should decouple the > nickname itself from its representation in a URI. So, my suggestion is > that the MSRP chat draft goes ahead with its representation of nicknames > in a URI, for the purpose of reservation/validation (NICKNAME method), > having into account that those nicknames are scoped to the focus of the > conference. Other representation of nicknames (domain-scoped nicknames) > may appear in From and To headers in CPIM, but not in NICKNAME method. > > Representation of chat room scoped nicknames. We need a mechanism to > identify that a nickname URI is effectively a nickname URI, and be able > to extract the nickname (for rendering in the UI) from the rest of teh > URI. Jonathan proposed: > > sip:"msrp-nicknames" "/" "/" @ domain > > which is correct in my opinion. While there have been other suggestions, > I haven't heard anyone indicating that Jonathan's proposal wouldn't > work. So, I suggest we go for it. > > /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 From simple-bounces@ietf.org Tue Aug 07 02:58:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIJ0z-0001Am-Vy; Tue, 07 Aug 2007 02:58:01 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIJ0y-0001Ah-04 for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 02:58:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIJ0u-000142-9p for simple@ietf.org; Tue, 07 Aug 2007 02:57:56 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIJ0s-00061V-EI for simple@ietf.org; Tue, 07 Aug 2007 02:57:56 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l776uu5d020186; Tue, 7 Aug 2007 09:57:20 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 09:57:18 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 09:57:18 +0300 Received: from [10.144.23.115] ([10.144.23.115]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 09:57:17 +0300 Message-ID: <46B817CD.8090205@nsn.com> Date: Tue, 07 Aug 2007 09:57:17 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> In-Reply-To: <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Aug 2007 06:57:17.0767 (UTC) FILETIME=[31698D70:01C7D8C0] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: 'Paul Kyzivat' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Some inline comments Brian Rosen wrote: > Having agreed to proceed with the nickname stuff in MSRP chat, BUT having > the benefit of the discussion on generalizing nicknames in the Chicago > meeting, I'd suggest we simplify as much as possible the MSRP mechanism. > Specifically, I suggest the following: > > 1. We don't need a display name on a nick name. Just delete it. Agreed. No changes with respect the current version of the draft, which already includes the following text: The 'name-addr' ABNF in RFC 3261 allows an optional 'display-name' to prepend the actual URI. For the purpose of conveying nicknames, display-names MUST NOT be used, because the username part of a nickname URI provides its rendering property. If the display-name is included in an Use-Nickname header field, it SHOULD be ignored. Implementations are RECOMMENDED to use only the user part of the nickname URI for rendering purposes. > 2. We agree that there is a nickname, scoped within a domain, and you need > to be able to form a URI from it. The domain in MSRP chat is always the > chat itself. There is the complication that the domain of the chat may have > content prior to the "@". This problem exists in XCON also. This means > there needs to be a construction rule to form URI from the nick and the > domain, handling this problem. OTOH, there really isn't a reason why the > domain needs to be mentioned in the Set-Nickname. You can't use a NICKNAME > method outside the domain of a chat, so we know a-priori what the chat > domain is. I am trying to understand the benefit of it. On one hand, the MSRP endpoint needs to understand the construction for nickname URIs defined by the document. This is because it is going to receive participant's nicknames via the conference event package, and it needs to be able to extract the nickname out of the URI for rendering purposes. On the other hand, in the future, there might be participants who have non-chat-server-scoped nicknames. So, the endpoint needs to know the structure of the URI. If the endpoint needs to know the structure of the URI I would prefer to be explicit and send in the Set-Nickname the full nickname URI that the user wishes to set. Somehow, I feel more comfortable being explicit. > > 4. Jonathan proposed a construction rule. I don't understand why we need a > prefix. I think the prefix serves for two purposes. On one side, it is trying to avoid clashes between regular SIP URIs and nickname URIs in the chat room server/mixer. But more important, I think the prefix also indicates the structure or scheme used in the nickname URI. Assume in the future we come up with another way to represent nicknames in a URI (perhaps the general nicknames), then we should have a mechanism to clearly identify which structure is used. I think the "msrp-nickname" prefix gives us such property. > We could easily put a rule that said, for example, in an MSRP From: > or To:, a slash must be escaped unless it separates nick from chat > domain user-part. In CPIM From and To. But yes, I agree, slashes must be escaped unless used for the purpose of separating nicknames from the chat room name. > You already imply a rule that says you can't have > "msrp-nickname" with slashes as a URI in From:/To:. You could. Nothing prevents to you to add the string "msrp-nickname" as part of your nickname. That would lead to: sip:msrp-nickname/msrp-nickname/chat33@conf.example.com The prefix tells you how to decode the username part; the second "msrp-nickname" is your actual nickname. If you want to add slashes, you escape them. > > So: I propose that Set-Nickname simply have the nickname as the parameter: > Set-Nickname: joebob As I said, I prefer to be explicit. I don't think we gain anything, and we loose a lot. > > I propose a construction rule from nickname+chat-domain to a URI useable in > MSRP From:/To: be to separate the nick from the domain with a slash IFF the > domain has a userpart. So, for example: > sip:joebob/chat34@msrp.example.com > > Include the rule that a normal URI in From:/To: that has a slash needs the > slash to be escaped. > > One other thought: the URI construction rule bothers me. I don't like > forcing new syntax on the user-part, and restricting what the URI can look > like. Consider making the nick a parameter to the domain URI in From:/To: > like: > sip:chat34@msrp.example.com;nickname=joebob > You could allow this syntax always (at least as an alternative) > sip:chat34.example.com;nickname=joebob I also proposed the nickname parameter earlier, but there is something I don't like from it: parameters should be modifiers of the resource that add new characteristics to the resource. Here the resource is the chatroom URI (as opposed to the user URI), so if we take it literally, the nickname parameter represents the chat room nickname, not the user's nickname. The idea of the nickname URI would be OK in the generic nicknames that you are working on, so I could write my SIP URI including a nickname, for example: sip:miguel@example.com;nickname=wine-expert /Miguel > > Brian > >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >> Sent: Monday, August 06, 2007 1:32 AM >> To: Paul Kyzivat; Brian Rosen; 'Hisham Khartabil'; Niemi Aki; Jonathan >> Rosenberg >> Cc: 'SIMPLE mailing list' >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >> >> Let me try to seek consensus on the issue of the Nickname URI. >> >> We have been hearing that we need to allow URIs to be issued by any >> entity as well as the chat server. We agreed that the MSRP chat draft >> will tackle only the latter. >> >> We haven't really agreed whether we envision MSRP chat operations >> (namely the NICKNAME method) with domain URIs in the future. The current >> version of the draft leaves open space for it, but this has created some >> misunderstanding. Since there is current work on generalized nicknames I >> would suggest that we take the assumption that the MSRP NICKNAME method >> only deals with chat room server scoped nicknames. Domain nicknames are >> not considered with the NICKNAME method. >> >> We are having discussions on the representation of a nickname URI. Some >> of these problems come from the fact that we don't really know how to >> represent domain nicknames and we don't know the relation of them to the >> chat room server. I've been thinking that we should decouple the >> nickname itself from its representation in a URI. So, my suggestion is >> that the MSRP chat draft goes ahead with its representation of nicknames >> in a URI, for the purpose of reservation/validation (NICKNAME method), >> having into account that those nicknames are scoped to the focus of the >> conference. Other representation of nicknames (domain-scoped nicknames) >> may appear in From and To headers in CPIM, but not in NICKNAME method. >> >> Representation of chat room scoped nicknames. We need a mechanism to >> identify that a nickname URI is effectively a nickname URI, and be able >> to extract the nickname (for rendering in the UI) from the rest of teh >> URI. Jonathan proposed: >> >> sip:"msrp-nicknames" "/" "/" @ domain >> >> which is correct in my opinion. While there have been other suggestions, >> I haven't heard anyone indicating that Jonathan's proposal wouldn't >> work. So, I suggest we go for it. >> >> /Miguel >> -- >> Miguel A. Garcia tel:+358-50-4804586 >> Nokia Siemens Networks Espoo, Finland > -- 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 From simple-bounces@ietf.org Tue Aug 07 09:05: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 1IIOk3-0006L4-6A; Tue, 07 Aug 2007 09:04:55 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIOk1-0006Ki-8r for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 09:04:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIOk0-0006KV-Ta for simple@ietf.org; Tue, 07 Aug 2007 09:04:52 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIOk0-00054z-1G for simple@ietf.org; Tue, 07 Aug 2007 09:04:52 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 07 Aug 2007 06:04:51 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACYKuEarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.19,229,1183359600"; d="scan'208"; a="511014286:sNHT32945194" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l77D4pMw016711; Tue, 7 Aug 2007 06:04:51 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l77D4fF8013711; Tue, 7 Aug 2007 13:04:46 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, 7 Aug 2007 09:04:43 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 09:04:42 -0400 Message-ID: <46B86DEB.90405@cisco.com> Date: Tue, 07 Aug 2007 09:04:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> In-Reply-To: <46B817CD.8090205@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Aug 2007 13:04:42.0830 (UTC) FILETIME=[854B36E0:01C7D8F3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4521; t=1186491891; x=1187355891; c=relaxed/simple; s=sjdkim1004; 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]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20; bh=8WiiAW67z47rBNKzYxT+BWr2626l268dAh1ZUc+U2DU=; b=lhUNo1oA2JhjPbDxR5clVeyc6d8RHNMWrT6Lw5cs0dLi/GX0lqUPylAYfeESQ7WNhFgIU/xc WrY1k0OETHj2Nzx1podsj5c8iAuCnqfEFBLupUwGhBsVn+bi4dcZrfT2DhLgLCK0XIqYgUoGg+ d9495UJAJWFb+iuE3E2XsrN04=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Miguel Garcia wrote: >> One other thought: the URI construction rule bothers me. I don't like >> forcing new syntax on the user-part, and restricting what the URI can >> look >> like. Consider making the nick a parameter to the domain URI in >> From:/To: >> like: >> sip:chat34@msrp.example.com;nickname=joebob >> You could allow this syntax always (at least as an alternative) >> sip:chat34.example.com;nickname=joebob > > I also proposed the nickname parameter earlier, but there is something I > don't like from it: parameters should be modifiers of the resource that > add new characteristics to the resource. Here the resource is the > chatroom URI (as opposed to the user URI), so if we take it literally, > the nickname parameter represents the chat room nickname, not the user's > nickname. I don't see the problem here. The parameter does indeed modify the resource (chatroom), identifying a "sub-resource" - one of the nicknames owned and assigned by the chatroom. I don't see why it is necessarily an identifier of the chatroom itself. > The idea of the nickname URI would be OK in the generic nicknames that > you are working on, so I could write my SIP URI including a nickname, > for example: sip:miguel@example.com;nickname=wine-expert That would also be consistent - "wine-expert" is a nickname owned and assigned by miguel@example.com. I also see this as pretty consistent with what Brian suggested. When using MSRP to request the nickname, simply send in the requested nickname part, and hopefully get back a URI containing that nickname. That way the focus can decide what scope it wants to use when assigning the nickname. It can use itself, or it can use something else. And that leaves open the door for getting nickname URIs some other way, while the consistent use of the parameter provides a common way to know what part should normally be displayed. Paul > /Miguel > >> >> Brian >> >>> -----Original Message----- >>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >>> Sent: Monday, August 06, 2007 1:32 AM >>> To: Paul Kyzivat; Brian Rosen; 'Hisham Khartabil'; Niemi Aki; Jonathan >>> Rosenberg >>> Cc: 'SIMPLE mailing list' >>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>> >>> Let me try to seek consensus on the issue of the Nickname URI. >>> >>> We have been hearing that we need to allow URIs to be issued by any >>> entity as well as the chat server. We agreed that the MSRP chat draft >>> will tackle only the latter. >>> >>> We haven't really agreed whether we envision MSRP chat operations >>> (namely the NICKNAME method) with domain URIs in the future. The current >>> version of the draft leaves open space for it, but this has created some >>> misunderstanding. Since there is current work on generalized nicknames I >>> would suggest that we take the assumption that the MSRP NICKNAME method >>> only deals with chat room server scoped nicknames. Domain nicknames are >>> not considered with the NICKNAME method. >>> >>> We are having discussions on the representation of a nickname URI. Some >>> of these problems come from the fact that we don't really know how to >>> represent domain nicknames and we don't know the relation of them to the >>> chat room server. I've been thinking that we should decouple the >>> nickname itself from its representation in a URI. So, my suggestion is >>> that the MSRP chat draft goes ahead with its representation of nicknames >>> in a URI, for the purpose of reservation/validation (NICKNAME method), >>> having into account that those nicknames are scoped to the focus of the >>> conference. Other representation of nicknames (domain-scoped nicknames) >>> may appear in From and To headers in CPIM, but not in NICKNAME method. >>> >>> Representation of chat room scoped nicknames. We need a mechanism to >>> identify that a nickname URI is effectively a nickname URI, and be able >>> to extract the nickname (for rendering in the UI) from the rest of teh >>> URI. Jonathan proposed: >>> >>> sip:"msrp-nicknames" "/" "/" @ domain >>> >>> which is correct in my opinion. While there have been other suggestions, >>> I haven't heard anyone indicating that Jonathan's proposal wouldn't >>> work. So, I suggest we go for it. >>> >>> /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 From simple-bounces@ietf.org Tue Aug 07 09:40:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPIm-0004u6-LD; Tue, 07 Aug 2007 09:40:48 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIPIm-0004qy-5h for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 09:40:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPIl-0004m8-Ne for simple@ietf.org; Tue, 07 Aug 2007 09:40:47 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIPIk-0001nX-9W for simple@ietf.org; Tue, 07 Aug 2007 09:40:47 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IIPIX-0002lO-Eh; Tue, 07 Aug 2007 08:40:33 -0500 From: "Brian Rosen" To: "'Miguel Garcia'" References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Tue, 7 Aug 2007 09:40:38 -0400 Message-ID: <071601c7d8f8$8c267c90$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: AcfYwELWw8tVPvAJSQaKk3vvVjobLAAMwv5Q In-reply-to: <46B817CD.8090205@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: 2a9ffb6f997442a3b543bcdaf483b990 Cc: 'Paul Kyzivat' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I think you are too hung up on the fact you can create a URI out of a nickname. There is no more comfort in explicitly providing the URI and forcing the UA (and the server) to decode it to extract the nickname, then in sending the nickname and forcing construction of the URI. I think: Set-Nickname joebob is much preferable to Set-Nickname sip:msrp-nickname/joebob/chat34@msrp.example.com I didn't remember the detail about how you extend the conference package. It's much simpler to just have the nickname be the string, and not the URI. It's an extension; there is no reason to require the URI, and we can make it anything appropriate. Keep it simple. I'm trying to keep this mechanism as close to the generalized mechanism as possible. I want to go the other way from you: if you declare a nickname with the generalized mechanism, I want the conference package extension to not change, I want you to be able to (generally) mix and match use of the generalized Set with the MSRP Set and I want the form of the construction to be the same. If we get away with that, we won't usually need to distinguish how we set the nickname in the URI. Even if we keep the text pretty much as is, I'd prefer to change the prefix to just "nickname". To be honest, we actually DO need to have an explicit domain in the generalized SET, because it may not be the domain of the chat/conference/whatever. I want that in the generalized mechanism and not in the msrp mechanism. I don't want a client with the generalized mechanism to be able to send a non local domain in the msrp Set. I'm worried that the client may not know that the chat server does not support the generalized mechanism before he tries that, or using the Supported header for the generalized mechanism to imply what can or cannot be sent in the msrp Set. I'd make the domain in the generalized Set a separate parameter in the (sip) header, not the constructed URI: Set-Nickname joebob nickserver.example.com I think you are mistaken about what the constructor rule does to user part syntax. If I choose a username of msrp-nickname/joebob, you can make a valid nickname uri from it, but if I send a regular message, it looks like it's from a nickname. You would have to get a full set of nicknames from the server and figure this out to know what my actual URI was and distinguish it from my nickname. I worry that there will be implementations that will able to be failed by fooling them in this way. I think the text should say that usernames can't start with the prefix we choose, and the server should enforce the rule. When you use a nickname the message is always sent to the switch. You cannot address any form of message directly to the constructed URI. This is why the parameter works. You ARE sending it to the switch, it is translating the URI you send into an actually addressable entity. Brian > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > Sent: Tuesday, August 07, 2007 2:57 AM > To: Brian Rosen > Cc: 'Paul Kyzivat'; 'Hisham Khartabil'; 'Niemi Aki'; 'Jonathan Rosenberg'; > 'SIMPLE mailing list' > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > Some inline comments > > Brian Rosen wrote: > > Having agreed to proceed with the nickname stuff in MSRP chat, BUT > having > > the benefit of the discussion on generalizing nicknames in the Chicago > > meeting, I'd suggest we simplify as much as possible the MSRP mechanism. > > Specifically, I suggest the following: > > > > 1. We don't need a display name on a nick name. Just delete it. > > Agreed. No changes with respect the current version of the draft, which > already includes the following text: > > The 'name-addr' ABNF in RFC 3261 allows an optional 'display-name' to > prepend the actual URI. For the purpose of conveying nicknames, > display-names MUST NOT be used, because the username part of a > nickname URI provides its rendering property. If the display-name is > included in an Use-Nickname header field, it SHOULD be ignored. > Implementations are RECOMMENDED to use only the user part of the > nickname URI for rendering purposes. > > > > 2. We agree that there is a nickname, scoped within a domain, and you > need > > to be able to form a URI from it. The domain in MSRP chat is always the > > chat itself. There is the complication that the domain of the chat may > have > > content prior to the "@". This problem exists in XCON also. This means > > there needs to be a construction rule to form URI from the nick and the > > domain, handling this problem. OTOH, there really isn't a reason why > the > > domain needs to be mentioned in the Set-Nickname. You can't use a > NICKNAME > > method outside the domain of a chat, so we know a-priori what the chat > > domain is. > > I am trying to understand the benefit of it. > > On one hand, the MSRP endpoint needs to understand the construction for > nickname URIs defined by the document. This is because it is going to > receive participant's nicknames via the conference event package, and it > needs to be able to extract the nickname out of the URI for rendering > purposes. > > On the other hand, in the future, there might be participants who have > non-chat-server-scoped nicknames. So, the endpoint needs to know the > structure of the URI. > > If the endpoint needs to know the structure of the URI I would prefer to > be explicit and send in the Set-Nickname the full nickname URI that the > user wishes to set. Somehow, I feel more comfortable being explicit. > > > > > 4. Jonathan proposed a construction rule. I don't understand why we > need a > > prefix. > > I think the prefix serves for two purposes. On one side, it is trying to > avoid clashes between regular SIP URIs and nickname URIs in the chat > room server/mixer. > > But more important, I think the prefix also indicates the structure or > scheme used in the nickname URI. Assume in the future we come up with > another way to represent nicknames in a URI (perhaps the general > nicknames), then we should have a mechanism to clearly identify which > structure is used. I think the "msrp-nickname" prefix gives us such > property. > > > We could easily put a rule that said, for example, in an MSRP From: > > or To:, a slash must be escaped unless it separates nick from chat > > domain user-part. > > In CPIM From and To. But yes, I agree, slashes must be escaped unless > used for the purpose of separating nicknames from the chat room name. > > > You already imply a rule that says you can't have > > "msrp-nickname" with slashes as a URI in From:/To:. > > You could. Nothing prevents to you to add the string "msrp-nickname" as > part of your nickname. That would lead to: > > sip:msrp-nickname/msrp-nickname/chat33@conf.example.com > > The prefix tells you how to decode the username part; the second > "msrp-nickname" is your actual nickname. If you want to add slashes, you > escape them. > > > > > > So: I propose that Set-Nickname simply have the nickname as the > parameter: > > Set-Nickname: joebob > > As I said, I prefer to be explicit. I don't think we gain anything, and > we loose a lot. > > > > > I propose a construction rule from nickname+chat-domain to a URI useable > in > > MSRP From:/To: be to separate the nick from the domain with a slash IFF > the > > domain has a userpart. So, for example: > > sip:joebob/chat34@msrp.example.com > > > > Include the rule that a normal URI in From:/To: that has a slash needs > the > > slash to be escaped. > > > > One other thought: the URI construction rule bothers me. I don't like > > forcing new syntax on the user-part, and restricting what the URI can > look > > like. Consider making the nick a parameter to the domain URI in > From:/To: > > like: > > sip:chat34@msrp.example.com;nickname=joebob > > You could allow this syntax always (at least as an alternative) > > sip:chat34.example.com;nickname=joebob > > I also proposed the nickname parameter earlier, but there is something I > don't like from it: parameters should be modifiers of the resource that > add new characteristics to the resource. Here the resource is the > chatroom URI (as opposed to the user URI), so if we take it literally, > the nickname parameter represents the chat room nickname, not the user's > nickname. > > The idea of the nickname URI would be OK in the generic nicknames that > you are working on, so I could write my SIP URI including a nickname, > for example: sip:miguel@example.com;nickname=wine-expert > > /Miguel > > > > > Brian > > > >> -----Original Message----- > >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > >> Sent: Monday, August 06, 2007 1:32 AM > >> To: Paul Kyzivat; Brian Rosen; 'Hisham Khartabil'; Niemi Aki; Jonathan > >> Rosenberg > >> Cc: 'SIMPLE mailing list' > >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > >> > >> Let me try to seek consensus on the issue of the Nickname URI. > >> > >> We have been hearing that we need to allow URIs to be issued by any > >> entity as well as the chat server. We agreed that the MSRP chat draft > >> will tackle only the latter. > >> > >> We haven't really agreed whether we envision MSRP chat operations > >> (namely the NICKNAME method) with domain URIs in the future. The > current > >> version of the draft leaves open space for it, but this has created > some > >> misunderstanding. Since there is current work on generalized nicknames > I > >> would suggest that we take the assumption that the MSRP NICKNAME method > >> only deals with chat room server scoped nicknames. Domain nicknames are > >> not considered with the NICKNAME method. > >> > >> We are having discussions on the representation of a nickname URI. Some > >> of these problems come from the fact that we don't really know how to > >> represent domain nicknames and we don't know the relation of them to > the > >> chat room server. I've been thinking that we should decouple the > >> nickname itself from its representation in a URI. So, my suggestion is > >> that the MSRP chat draft goes ahead with its representation of > nicknames > >> in a URI, for the purpose of reservation/validation (NICKNAME method), > >> having into account that those nicknames are scoped to the focus of the > >> conference. Other representation of nicknames (domain-scoped nicknames) > >> may appear in From and To headers in CPIM, but not in NICKNAME method. > >> > >> Representation of chat room scoped nicknames. We need a mechanism to > >> identify that a nickname URI is effectively a nickname URI, and be able > >> to extract the nickname (for rendering in the UI) from the rest of teh > >> URI. Jonathan proposed: > >> > >> sip:"msrp-nicknames" "/" "/" @ domain > >> > >> which is correct in my opinion. While there have been other > suggestions, > >> I haven't heard anyone indicating that Jonathan's proposal wouldn't > >> work. So, I suggest we go for it. > >> > >> /Miguel > >> -- > >> Miguel A. Garcia tel:+358-50-4804586 > >> Nokia Siemens Networks Espoo, Finland > > > > -- > 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 From simple-bounces@ietf.org Tue Aug 07 10:24:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPzP-0003ZV-EQ; Tue, 07 Aug 2007 10:24:51 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIPzO-0003ZP-Jb for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 10:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPzN-0003ZA-Qj for simple@ietf.org; Tue, 07 Aug 2007 10:24:49 -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 1IIPzM-0004WK-5A for simple@ietf.org; Tue, 07 Aug 2007 10:24:49 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l77EOV3N006036; Tue, 7 Aug 2007 17:24:40 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 17:24:39 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 17:24:38 +0300 Received: from [10.144.23.115] ([10.144.23.115]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 17:24:37 +0300 Message-ID: <46B880A5.1080402@nsn.com> Date: Tue, 07 Aug 2007 17:24:37 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <46B86DEB.90405@cisco.com> In-Reply-To: <46B86DEB.90405@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Aug 2007 14:24:37.0971 (UTC) FILETIME=[AF6BAA30:01C7D8FE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Inline. Paul Kyzivat wrote: > > > Miguel Garcia wrote: > >>> One other thought: the URI construction rule bothers me. I don't like >>> forcing new syntax on the user-part, and restricting what the URI can >>> look >>> like. Consider making the nick a parameter to the domain URI in >>> From:/To: >>> like: >>> sip:chat34@msrp.example.com;nickname=joebob >>> You could allow this syntax always (at least as an alternative) >>> sip:chat34.example.com;nickname=joebob >> >> I also proposed the nickname parameter earlier, but there is something >> I don't like from it: parameters should be modifiers of the resource >> that add new characteristics to the resource. Here the resource is the >> chatroom URI (as opposed to the user URI), so if we take it literally, >> the nickname parameter represents the chat room nickname, not the >> user's nickname. > > I don't see the problem here. The parameter does indeed modify the > resource (chatroom), identifying a "sub-resource" - one of the nicknames > owned and assigned by the chatroom. I don't see why it is necessarily an > identifier of the chatroom itself. Yes, it is a sub-resouce. I thought we wanted to have parameters that modify the resource, not use it to identify a sub-resource. > >> The idea of the nickname URI would be OK in the generic nicknames that >> you are working on, so I could write my SIP URI including a nickname, >> for example: sip:miguel@example.com;nickname=wine-expert > > That would also be consistent - "wine-expert" is a nickname owned and > assigned by miguel@example.com. Yes, I see this other format more consistent. We are not using the nickname for sub-resourcing, but as a property of the resource. It is different from the example in the chat room. > > I also see this as pretty consistent with what Brian suggested. When > using MSRP to request the nickname, simply send in the requested > nickname part, and hopefully get back a URI containing that nickname. OK, if the endpoint gets back the full URI, I don't have a major problem. The endpoint needs to determine its own full URI and get the other participant's full nickname URIs. This is because the CPIM From/To headers require absolute URIs. > That way the focus can decide what scope it wants to use when assigning > the nickname. It can use itself, or it can use something else. And that > leaves open the door for getting nickname URIs some other way, while the > consistent use of the parameter provides a common way to know what part > should normally be displayed. > This is not going to work. What do you mean by "something else"? I think we ought to write very clear semantics that the Set-Nickname header in the NICKNAME method are intended to set a chat-room scoped nickname. How can it be that it could be in its own domain or something else?. I think the endpoint will go nuts if it doesn't know how the nickname is reserved and what is the structure of such nickname. /Miguel > Paul > >> /Miguel >> >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >>>> Sent: Monday, August 06, 2007 1:32 AM >>>> To: Paul Kyzivat; Brian Rosen; 'Hisham Khartabil'; Niemi Aki; Jonathan >>>> Rosenberg >>>> Cc: 'SIMPLE mailing list' >>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>> >>>> Let me try to seek consensus on the issue of the Nickname URI. >>>> >>>> We have been hearing that we need to allow URIs to be issued by any >>>> entity as well as the chat server. We agreed that the MSRP chat draft >>>> will tackle only the latter. >>>> >>>> We haven't really agreed whether we envision MSRP chat operations >>>> (namely the NICKNAME method) with domain URIs in the future. The >>>> current >>>> version of the draft leaves open space for it, but this has created >>>> some >>>> misunderstanding. Since there is current work on generalized >>>> nicknames I >>>> would suggest that we take the assumption that the MSRP NICKNAME method >>>> only deals with chat room server scoped nicknames. Domain nicknames are >>>> not considered with the NICKNAME method. >>>> >>>> We are having discussions on the representation of a nickname URI. Some >>>> of these problems come from the fact that we don't really know how to >>>> represent domain nicknames and we don't know the relation of them to >>>> the >>>> chat room server. I've been thinking that we should decouple the >>>> nickname itself from its representation in a URI. So, my suggestion is >>>> that the MSRP chat draft goes ahead with its representation of >>>> nicknames >>>> in a URI, for the purpose of reservation/validation (NICKNAME method), >>>> having into account that those nicknames are scoped to the focus of the >>>> conference. Other representation of nicknames (domain-scoped nicknames) >>>> may appear in From and To headers in CPIM, but not in NICKNAME method. >>>> >>>> Representation of chat room scoped nicknames. We need a mechanism to >>>> identify that a nickname URI is effectively a nickname URI, and be able >>>> to extract the nickname (for rendering in the UI) from the rest of teh >>>> URI. Jonathan proposed: >>>> >>>> sip:"msrp-nicknames" "/" "/" @ domain >>>> >>>> which is correct in my opinion. While there have been other >>>> suggestions, >>>> I haven't heard anyone indicating that Jonathan's proposal wouldn't >>>> work. So, I suggest we go for it. >>>> >>>> /Miguel >>>> -- >>>> Miguel A. Garcia tel:+358-50-4804586 >>>> Nokia Siemens Networks Espoo, Finland >>> >> -- 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 From simple-bounces@ietf.org Tue Aug 07 11:15:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQmh-00052Z-Cf; Tue, 07 Aug 2007 11:15:47 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIQmg-00052Q-K5 for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 11:15:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQmg-00052I-AN for simple@ietf.org; Tue, 07 Aug 2007 11:15:46 -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 1IIQme-00077I-DX for simple@ietf.org; Tue, 07 Aug 2007 11:15:46 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l77FF7H6010066; Tue, 7 Aug 2007 18:15:37 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 18:15:34 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 18:15:33 +0300 Received: from [10.144.23.115] ([10.144.23.115]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 18:15:33 +0300 Message-ID: <46B88C95.60606@nsn.com> Date: Tue, 07 Aug 2007 18:15:33 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> In-Reply-To: <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Aug 2007 15:15:33.0467 (UTC) FILETIME=[CCA35AB0:01C7D905] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Cc: 'Paul Kyzivat' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Inline Brian Rosen wrote: > I think you are too hung up on the fact you can create a URI out of a > nickname. There is no more comfort in explicitly providing the URI and > forcing the UA (and the server) to decode it to extract the nickname, then > in sending the nickname and forcing construction of the URI. I think: > Set-Nickname joebob > is much preferable to > Set-Nickname sip:msrp-nickname/joebob/chat34@msrp.example.com I would agree on the implicit version providing that the response contains the full URI. Still I don't really understand what are we achieving.... > I didn't remember the detail about how you extend the conference package. > It's much simpler to just have the nickname be the string, and not the URI. > It's an extension; there is no reason to require the URI, and we can make it > anything appropriate. Keep it simple. The conference event package is extended with a new element surprisingly called . It currently contains the URI. I think the conference event package needs to send the full URI. Otherwise, there might be conflicts if one person with say a local nickname shares the nickname with a general domain nickname. When a user sends a private message to one of these nicknames, if the nickname is not a URI the server is not going to know how to route the message. > > I'm trying to keep this mechanism as close to the generalized mechanism as > possible. I want to go the other way from you: if you declare a nickname > with the generalized mechanism, I want the conference package extension to > not change, Agreed. The current extension holds a URI, so if you can represent a general nickname as a URI, then it is not a probelm. > I want you to be able to (generally) mix and match use of the > generalized Set with the MSRP Set and I want the form of the construction to > be the same. Generally agreed. I was assuming that the general Set nickname will require a domain, so it does the chat-room scoped nickname. But you seem to be suggesting the opposite, so I am confused. The other thing: I believe we came to an agreement that on the procedures, we will use Set-Nickname in NICKNAME to set the chat-room scoped URI only. Setting a general nickname will be done by some other general procedure. Just wanted to confirm that we are on the same page. > If we get away with that, we won't usually need to distinguish > how we set the nickname in the URI. Even if we keep the text pretty much as > is, I'd prefer to change the prefix to just "nickname". Ok, we can change the prefix name to "nickname". > > To be honest, we actually DO need to have an explicit domain in the > generalized SET, because it may not be the domain of the > chat/conference/whatever. Exactly > I want that in the generalized mechanism and not > in the msrp mechanism. I don't want a client with the generalized mechanism > to be able to send a non local domain in the msrp Set. Ok, I can agree with it. As long as the response contains the full URI, as I said before. > I'm worried that the > client may not know that the chat server does not support the generalized > mechanism before he tries that, or using the Supported header for the > generalized mechanism to imply what can or cannot be sent in the msrp Set. > > I'd make the domain in the generalized Set a separate parameter in the (sip) > header, not the constructed URI: > Set-Nickname joebob nickserver.example.com ok, not a big difference with a uri: sip:joebob@nickserver.example.com > > I think you are mistaken about what the constructor rule does to user part > syntax. If I choose a username of msrp-nickname/joebob, you can make a > valid nickname uri from it, but if I send a regular message, it looks like > it's from a nickname. You would have to get a full set of nicknames from > the server and figure this out to know what my actual URI was and > distinguish it from my nickname. I worry that there will be implementations > that will able to be failed by fooling them in this way. I think the text > should say that usernames can't start with the prefix we choose, and the > server should enforce the rule. The problem of knowing what is my real nickanme URI is solved if the nickname URI returned in the response to the NICKNAME method. I don't have a problem to say that nicknames can't start by the prefix. Paul wanted that feature, but I don't have a problem in either way. Miguel > > When you use a nickname the message is always sent to the switch. You > cannot address any form of message directly to the constructed URI. This is > why the parameter works. You ARE sending it to the switch, it is > translating the URI you send into an actually addressable entity. > > Brian >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >> Sent: Tuesday, August 07, 2007 2:57 AM >> To: Brian Rosen >> Cc: 'Paul Kyzivat'; 'Hisham Khartabil'; 'Niemi Aki'; 'Jonathan Rosenberg'; >> 'SIMPLE mailing list' >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >> >> Some inline comments >> >> Brian Rosen wrote: >>> Having agreed to proceed with the nickname stuff in MSRP chat, BUT >> having >>> the benefit of the discussion on generalizing nicknames in the Chicago >>> meeting, I'd suggest we simplify as much as possible the MSRP mechanism. >>> Specifically, I suggest the following: >>> >>> 1. We don't need a display name on a nick name. Just delete it. >> Agreed. No changes with respect the current version of the draft, which >> already includes the following text: >> >> The 'name-addr' ABNF in RFC 3261 allows an optional 'display-name' to >> prepend the actual URI. For the purpose of conveying nicknames, >> display-names MUST NOT be used, because the username part of a >> nickname URI provides its rendering property. If the display-name is >> included in an Use-Nickname header field, it SHOULD be ignored. >> Implementations are RECOMMENDED to use only the user part of the >> nickname URI for rendering purposes. >> >> >>> 2. We agree that there is a nickname, scoped within a domain, and you >> need >>> to be able to form a URI from it. The domain in MSRP chat is always the >>> chat itself. There is the complication that the domain of the chat may >> have >>> content prior to the "@". This problem exists in XCON also. This means >>> there needs to be a construction rule to form URI from the nick and the >>> domain, handling this problem. OTOH, there really isn't a reason why >> the >>> domain needs to be mentioned in the Set-Nickname. You can't use a >> NICKNAME >>> method outside the domain of a chat, so we know a-priori what the chat >>> domain is. >> I am trying to understand the benefit of it. >> >> On one hand, the MSRP endpoint needs to understand the construction for >> nickname URIs defined by the document. This is because it is going to >> receive participant's nicknames via the conference event package, and it >> needs to be able to extract the nickname out of the URI for rendering >> purposes. >> >> On the other hand, in the future, there might be participants who have >> non-chat-server-scoped nicknames. So, the endpoint needs to know the >> structure of the URI. >> >> If the endpoint needs to know the structure of the URI I would prefer to >> be explicit and send in the Set-Nickname the full nickname URI that the >> user wishes to set. Somehow, I feel more comfortable being explicit. >> >>> 4. Jonathan proposed a construction rule. I don't understand why we >> need a >>> prefix. >> I think the prefix serves for two purposes. On one side, it is trying to >> avoid clashes between regular SIP URIs and nickname URIs in the chat >> room server/mixer. >> >> But more important, I think the prefix also indicates the structure or >> scheme used in the nickname URI. Assume in the future we come up with >> another way to represent nicknames in a URI (perhaps the general >> nicknames), then we should have a mechanism to clearly identify which >> structure is used. I think the "msrp-nickname" prefix gives us such >> property. >> >> > We could easily put a rule that said, for example, in an MSRP From: >> > or To:, a slash must be escaped unless it separates nick from chat >> > domain user-part. >> >> In CPIM From and To. But yes, I agree, slashes must be escaped unless >> used for the purpose of separating nicknames from the chat room name. >> >> > You already imply a rule that says you can't have >> > "msrp-nickname" with slashes as a URI in From:/To:. >> >> You could. Nothing prevents to you to add the string "msrp-nickname" as >> part of your nickname. That would lead to: >> >> sip:msrp-nickname/msrp-nickname/chat33@conf.example.com >> >> The prefix tells you how to decode the username part; the second >> "msrp-nickname" is your actual nickname. If you want to add slashes, you >> escape them. >> >> >>> So: I propose that Set-Nickname simply have the nickname as the >> parameter: >>> Set-Nickname: joebob >> As I said, I prefer to be explicit. I don't think we gain anything, and >> we loose a lot. >> >>> I propose a construction rule from nickname+chat-domain to a URI useable >> in >>> MSRP From:/To: be to separate the nick from the domain with a slash IFF >> the >>> domain has a userpart. So, for example: >>> sip:joebob/chat34@msrp.example.com >>> >>> Include the rule that a normal URI in From:/To: that has a slash needs >> the >>> slash to be escaped. >>> >>> One other thought: the URI construction rule bothers me. I don't like >>> forcing new syntax on the user-part, and restricting what the URI can >> look >>> like. Consider making the nick a parameter to the domain URI in >> From:/To: >>> like: >>> sip:chat34@msrp.example.com;nickname=joebob >>> You could allow this syntax always (at least as an alternative) >>> sip:chat34.example.com;nickname=joebob >> I also proposed the nickname parameter earlier, but there is something I >> don't like from it: parameters should be modifiers of the resource that >> add new characteristics to the resource. Here the resource is the >> chatroom URI (as opposed to the user URI), so if we take it literally, >> the nickname parameter represents the chat room nickname, not the user's >> nickname. >> >> The idea of the nickname URI would be OK in the generic nicknames that >> you are working on, so I could write my SIP URI including a nickname, >> for example: sip:miguel@example.com;nickname=wine-expert >> >> /Miguel >> >>> Brian >>> >>>> -----Original Message----- >>>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >>>> Sent: Monday, August 06, 2007 1:32 AM >>>> To: Paul Kyzivat; Brian Rosen; 'Hisham Khartabil'; Niemi Aki; Jonathan >>>> Rosenberg >>>> Cc: 'SIMPLE mailing list' >>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>> >>>> Let me try to seek consensus on the issue of the Nickname URI. >>>> >>>> We have been hearing that we need to allow URIs to be issued by any >>>> entity as well as the chat server. We agreed that the MSRP chat draft >>>> will tackle only the latter. >>>> >>>> We haven't really agreed whether we envision MSRP chat operations >>>> (namely the NICKNAME method) with domain URIs in the future. The >> current >>>> version of the draft leaves open space for it, but this has created >> some >>>> misunderstanding. Since there is current work on generalized nicknames >> I >>>> would suggest that we take the assumption that the MSRP NICKNAME method >>>> only deals with chat room server scoped nicknames. Domain nicknames are >>>> not considered with the NICKNAME method. >>>> >>>> We are having discussions on the representation of a nickname URI. Some >>>> of these problems come from the fact that we don't really know how to >>>> represent domain nicknames and we don't know the relation of them to >> the >>>> chat room server. I've been thinking that we should decouple the >>>> nickname itself from its representation in a URI. So, my suggestion is >>>> that the MSRP chat draft goes ahead with its representation of >> nicknames >>>> in a URI, for the purpose of reservation/validation (NICKNAME method), >>>> having into account that those nicknames are scoped to the focus of the >>>> conference. Other representation of nicknames (domain-scoped nicknames) >>>> may appear in From and To headers in CPIM, but not in NICKNAME method. >>>> >>>> Representation of chat room scoped nicknames. We need a mechanism to >>>> identify that a nickname URI is effectively a nickname URI, and be able >>>> to extract the nickname (for rendering in the UI) from the rest of teh >>>> URI. Jonathan proposed: >>>> >>>> sip:"msrp-nicknames" "/" "/" @ domain >>>> >>>> which is correct in my opinion. While there have been other >> suggestions, >>>> I haven't heard anyone indicating that Jonathan's proposal wouldn't >>>> work. So, I suggest we go for it. >>>> >>>> /Miguel >>>> -- >>>> Miguel A. Garcia tel:+358-50-4804586 >>>> Nokia Siemens Networks Espoo, Finland >> -- >> 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 -- 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 From simple-bounces@ietf.org Tue Aug 07 11:47: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 1IIRH3-0005ct-La; Tue, 07 Aug 2007 11:47:09 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIRH1-0005cf-VN for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 11:47:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIRH1-0005cX-LU for simple@ietf.org; Tue, 07 Aug 2007 11:47:07 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIRH0-0008Eu-AE for simple@ietf.org; Tue, 07 Aug 2007 11:47:07 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IIRGl-0007Sy-Rl; Tue, 07 Aug 2007 10:46:52 -0500 From: "Brian Rosen" To: "'Miguel Garcia'" References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Tue, 7 Aug 2007 11:46:56 -0400 Message-ID: <082b01c7d90a$31041540$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: AcfZBcvDuEjkYL9yQauCpJH7FivciAAAPrTQ In-reply-to: <46B88C95.60606@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: 9178bae9f85419fdc08e9f2c86e345d0 Cc: 'Paul Kyzivat' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org We're getting closer! You want the URI in the response. Your reasoning is: > Otherwise, there might be conflicts if one person with say a local > nickname shares the nickname with a general domain nickname. When a user > sends a private message to one of these nicknames, if the nickname is > not a URI the server is not going to know how to route the message. Let me make sure I get your problem: I have a nickname in nickserver.example.com, say joebob. Now, you use the msrp NICKNAME method to create a local nickname, also joebob NICKNAME Set-Nickname joebob So, now I have two definitions of joebob, one declared in the chat, one a more permanent one at nickserver.example.com. The nickname is the same, the domains are different. As we discussed, the generalized mechanism need local policy to decide if the server allows such a conflict (same nick). I think the notion that because they have different domains they are different is wrong. You can keep them separate for addressing purposes, but you force the UI to deal with them as the same. I think if nickname part is the same there is a collision, and either it's allowed or not, and the domain is not part of that. If it's allowed, the client and the server have to deal with the issue. This is not an issue for msrp chat: the text does not allow two users to have the same nickname. When we get to the generalized mechanism, we have to make it work for same name, different domain and same name, same domain. Brian > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > Sent: Tuesday, August 07, 2007 11:16 AM > To: Brian Rosen > Cc: 'Paul Kyzivat'; 'SIMPLE mailing list'; 'Niemi Aki' > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > Inline > > Brian Rosen wrote: > > I think you are too hung up on the fact you can create a URI out of a > > nickname. There is no more comfort in explicitly providing the URI and > > forcing the UA (and the server) to decode it to extract the nickname, > then > > in sending the nickname and forcing construction of the URI. I think: > > Set-Nickname joebob > > is much preferable to > > Set-Nickname sip:msrp-nickname/joebob/chat34@msrp.example.com > > > I would agree on the implicit version providing that the response > contains the full URI. > > Still I don't really understand what are we achieving.... > > > I didn't remember the detail about how you extend the conference > package. > > It's much simpler to just have the nickname be the string, and not the > URI. > > It's an extension; there is no reason to require the URI, and we can > make it > > anything appropriate. Keep it simple. > > The conference event package is extended with a new element surprisingly > called . It currently contains the URI. > > I think the conference event package needs to send the full URI. > Otherwise, there might be conflicts if one person with say a local > nickname shares the nickname with a general domain nickname. When a user > sends a private message to one of these nicknames, if the nickname is > not a URI the server is not going to know how to route the message. > > > > > I'm trying to keep this mechanism as close to the generalized mechanism > as > > possible. I want to go the other way from you: if you declare a > nickname > > with the generalized mechanism, I want the conference package extension > to > > not change, > > Agreed. The current extension holds a URI, so if you can represent a > general nickname as a URI, then it is not a probelm. > > > I want you to be able to (generally) mix and match use of the > > generalized Set with the MSRP Set and I want the form of the > construction to > > be the same. > > Generally agreed. I was assuming that the general Set nickname will > require a domain, so it does the chat-room scoped nickname. But you seem > to be suggesting the opposite, so I am confused. > > The other thing: I believe we came to an agreement that on the > procedures, we will use Set-Nickname in NICKNAME to set the chat-room > scoped URI only. Setting a general nickname will be done by some other > general procedure. Just wanted to confirm that we are on the same page. > > > If we get away with that, we won't usually need to distinguish > > how we set the nickname in the URI. Even if we keep the text pretty > much as > > is, I'd prefer to change the prefix to just "nickname". > > Ok, we can change the prefix name to "nickname". > > > > > To be honest, we actually DO need to have an explicit domain in the > > generalized SET, because it may not be the domain of the > > chat/conference/whatever. > > Exactly > > > I want that in the generalized mechanism and not > > in the msrp mechanism. I don't want a client with the generalized > mechanism > > to be able to send a non local domain in the msrp Set. > > Ok, I can agree with it. As long as the response contains the full URI, > as I said before. > > > I'm worried that the > > client may not know that the chat server does not support the > generalized > > mechanism before he tries that, or using the Supported header for the > > generalized mechanism to imply what can or cannot be sent in the msrp > Set. > > > > I'd make the domain in the generalized Set a separate parameter in the > (sip) > > header, not the constructed URI: > > Set-Nickname joebob nickserver.example.com > > ok, not a big difference with a uri: sip:joebob@nickserver.example.com > > > > > I think you are mistaken about what the constructor rule does to user > part > > syntax. If I choose a username of msrp-nickname/joebob, you can make a > > valid nickname uri from it, but if I send a regular message, it looks > like > > it's from a nickname. You would have to get a full set of nicknames > from > > the server and figure this out to know what my actual URI was and > > distinguish it from my nickname. I worry that there will be > implementations > > that will able to be failed by fooling them in this way. I think the > text > > should say that usernames can't start with the prefix we choose, and the > > server should enforce the rule. > > The problem of knowing what is my real nickanme URI is solved if the > nickname URI returned in the response to the NICKNAME method. > > I don't have a problem to say that nicknames can't start by the prefix. > Paul wanted that feature, but I don't have a problem in either way. > > Miguel > > > > > When you use a nickname the message is always sent to the switch. You > > cannot address any form of message directly to the constructed URI. > This is > > why the parameter works. You ARE sending it to the switch, it is > > translating the URI you send into an actually addressable entity. > > > > Brian > >> -----Original Message----- > >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > >> Sent: Tuesday, August 07, 2007 2:57 AM > >> To: Brian Rosen > >> Cc: 'Paul Kyzivat'; 'Hisham Khartabil'; 'Niemi Aki'; 'Jonathan > Rosenberg'; > >> 'SIMPLE mailing list' > >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > >> > >> Some inline comments > >> > >> Brian Rosen wrote: > >>> Having agreed to proceed with the nickname stuff in MSRP chat, BUT > >> having > >>> the benefit of the discussion on generalizing nicknames in the Chicago > >>> meeting, I'd suggest we simplify as much as possible the MSRP > mechanism. > >>> Specifically, I suggest the following: > >>> > >>> 1. We don't need a display name on a nick name. Just delete it. > >> Agreed. No changes with respect the current version of the draft, which > >> already includes the following text: > >> > >> The 'name-addr' ABNF in RFC 3261 allows an optional 'display-name' > to > >> prepend the actual URI. For the purpose of conveying nicknames, > >> display-names MUST NOT be used, because the username part of a > >> nickname URI provides its rendering property. If the display-name > is > >> included in an Use-Nickname header field, it SHOULD be ignored. > >> Implementations are RECOMMENDED to use only the user part of the > >> nickname URI for rendering purposes. > >> > >> > >>> 2. We agree that there is a nickname, scoped within a domain, and you > >> need > >>> to be able to form a URI from it. The domain in MSRP chat is always > the > >>> chat itself. There is the complication that the domain of the chat > may > >> have > >>> content prior to the "@". This problem exists in XCON also. This > means > >>> there needs to be a construction rule to form URI from the nick and > the > >>> domain, handling this problem. OTOH, there really isn't a reason why > >> the > >>> domain needs to be mentioned in the Set-Nickname. You can't use a > >> NICKNAME > >>> method outside the domain of a chat, so we know a-priori what the chat > >>> domain is. > >> I am trying to understand the benefit of it. > >> > >> On one hand, the MSRP endpoint needs to understand the construction for > >> nickname URIs defined by the document. This is because it is going to > >> receive participant's nicknames via the conference event package, and > it > >> needs to be able to extract the nickname out of the URI for rendering > >> purposes. > >> > >> On the other hand, in the future, there might be participants who have > >> non-chat-server-scoped nicknames. So, the endpoint needs to know the > >> structure of the URI. > >> > >> If the endpoint needs to know the structure of the URI I would prefer > to > >> be explicit and send in the Set-Nickname the full nickname URI that the > >> user wishes to set. Somehow, I feel more comfortable being explicit. > >> > >>> 4. Jonathan proposed a construction rule. I don't understand why we > >> need a > >>> prefix. > >> I think the prefix serves for two purposes. On one side, it is trying > to > >> avoid clashes between regular SIP URIs and nickname URIs in the chat > >> room server/mixer. > >> > >> But more important, I think the prefix also indicates the structure or > >> scheme used in the nickname URI. Assume in the future we come up with > >> another way to represent nicknames in a URI (perhaps the general > >> nicknames), then we should have a mechanism to clearly identify which > >> structure is used. I think the "msrp-nickname" prefix gives us such > >> property. > >> > >> > We could easily put a rule that said, for example, in an MSRP From: > >> > or To:, a slash must be escaped unless it separates nick from chat > >> > domain user-part. > >> > >> In CPIM From and To. But yes, I agree, slashes must be escaped unless > >> used for the purpose of separating nicknames from the chat room name. > >> > >> > You already imply a rule that says you can't have > >> > "msrp-nickname" with slashes as a URI in From:/To:. > >> > >> You could. Nothing prevents to you to add the string "msrp-nickname" as > >> part of your nickname. That would lead to: > >> > >> sip:msrp-nickname/msrp-nickname/chat33@conf.example.com > >> > >> The prefix tells you how to decode the username part; the second > >> "msrp-nickname" is your actual nickname. If you want to add slashes, > you > >> escape them. > >> > >> > >>> So: I propose that Set-Nickname simply have the nickname as the > >> parameter: > >>> Set-Nickname: joebob > >> As I said, I prefer to be explicit. I don't think we gain anything, and > >> we loose a lot. > >> > >>> I propose a construction rule from nickname+chat-domain to a URI > useable > >> in > >>> MSRP From:/To: be to separate the nick from the domain with a slash > IFF > >> the > >>> domain has a userpart. So, for example: > >>> sip:joebob/chat34@msrp.example.com > >>> > >>> Include the rule that a normal URI in From:/To: that has a slash needs > >> the > >>> slash to be escaped. > >>> > >>> One other thought: the URI construction rule bothers me. I don't like > >>> forcing new syntax on the user-part, and restricting what the URI can > >> look > >>> like. Consider making the nick a parameter to the domain URI in > >> From:/To: > >>> like: > >>> sip:chat34@msrp.example.com;nickname=joebob > >>> You could allow this syntax always (at least as an alternative) > >>> sip:chat34.example.com;nickname=joebob > >> I also proposed the nickname parameter earlier, but there is something > I > >> don't like from it: parameters should be modifiers of the resource that > >> add new characteristics to the resource. Here the resource is the > >> chatroom URI (as opposed to the user URI), so if we take it literally, > >> the nickname parameter represents the chat room nickname, not the > user's > >> nickname. > >> > >> The idea of the nickname URI would be OK in the generic nicknames that > >> you are working on, so I could write my SIP URI including a nickname, > >> for example: sip:miguel@example.com;nickname=wine-expert > >> > >> /Miguel > >> > >>> Brian > >>> > >>>> -----Original Message----- > >>>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > >>>> Sent: Monday, August 06, 2007 1:32 AM > >>>> To: Paul Kyzivat; Brian Rosen; 'Hisham Khartabil'; Niemi Aki; > Jonathan > >>>> Rosenberg > >>>> Cc: 'SIMPLE mailing list' > >>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > >>>> > >>>> Let me try to seek consensus on the issue of the Nickname URI. > >>>> > >>>> We have been hearing that we need to allow URIs to be issued by any > >>>> entity as well as the chat server. We agreed that the MSRP chat draft > >>>> will tackle only the latter. > >>>> > >>>> We haven't really agreed whether we envision MSRP chat operations > >>>> (namely the NICKNAME method) with domain URIs in the future. The > >> current > >>>> version of the draft leaves open space for it, but this has created > >> some > >>>> misunderstanding. Since there is current work on generalized > nicknames > >> I > >>>> would suggest that we take the assumption that the MSRP NICKNAME > method > >>>> only deals with chat room server scoped nicknames. Domain nicknames > are > >>>> not considered with the NICKNAME method. > >>>> > >>>> We are having discussions on the representation of a nickname URI. > Some > >>>> of these problems come from the fact that we don't really know how to > >>>> represent domain nicknames and we don't know the relation of them to > >> the > >>>> chat room server. I've been thinking that we should decouple the > >>>> nickname itself from its representation in a URI. So, my suggestion > is > >>>> that the MSRP chat draft goes ahead with its representation of > >> nicknames > >>>> in a URI, for the purpose of reservation/validation (NICKNAME > method), > >>>> having into account that those nicknames are scoped to the focus of > the > >>>> conference. Other representation of nicknames (domain-scoped > nicknames) > >>>> may appear in From and To headers in CPIM, but not in NICKNAME > method. > >>>> > >>>> Representation of chat room scoped nicknames. We need a mechanism to > >>>> identify that a nickname URI is effectively a nickname URI, and be > able > >>>> to extract the nickname (for rendering in the UI) from the rest of > teh > >>>> URI. Jonathan proposed: > >>>> > >>>> sip:"msrp-nicknames" "/" "/" @ domain > >>>> > >>>> which is correct in my opinion. While there have been other > >> suggestions, > >>>> I haven't heard anyone indicating that Jonathan's proposal wouldn't > >>>> work. So, I suggest we go for it. > >>>> > >>>> /Miguel > >>>> -- > >>>> Miguel A. Garcia tel:+358-50-4804586 > >>>> Nokia Siemens Networks Espoo, Finland > >> -- > >> 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 > > -- > 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 From simple-bounces@ietf.org Tue Aug 07 14:41:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IITzy-0006pq-7B; Tue, 07 Aug 2007 14:41:42 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IITzx-0006pl-99 for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 14:41:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IITzw-0006pc-SV for simple@ietf.org; Tue, 07 Aug 2007 14:41:40 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IITzv-0003co-AH for simple@ietf.org; Tue, 07 Aug 2007 14:41:40 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Aug 2007 14:41:38 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgnXACNZuEZAZnme/2dsb2JhbACICgOjYwE X-IronPort-AV: i="4.19,230,1183348800"; d="scan'208"; a="67319746:sNHT116267970" 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 l77Ifco1009689; Tue, 7 Aug 2007 14:41:38 -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 l77IfDjg018075; Tue, 7 Aug 2007 18:41:30 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 14:41:26 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 14:41:26 -0400 Message-ID: <46B8BCD4.4030800@cisco.com> Date: Tue, 07 Aug 2007 14:41:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> In-Reply-To: <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Aug 2007 18:41:26.0546 (UTC) FILETIME=[8FA59F20:01C7D922] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16887; t=1186512098; x=1187376098; 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]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20 |To:=20Brian=20Rosen=20; bh=W/eDaWfEYMbW0VNx3LIXwKvmHadk4IlKtxYNLX76v4Y=; b=quqAE38jli1hvaqnOF3H+GgTI+8y4ZRFy3kKO6byWflEJZHTBpPYU+0MGgAaryYJ3yUNiIh4 FH3N0rdwZLs66GxQ7Mc7p1j8PFN3vO0JKA8maixl9yK5BcfANsVdWAD7; 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: 9178bae9f85419fdc08e9f2c86e345d0 Cc: 'Miguel Garcia' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Joebob - comments inline. Paul Brian Rosen wrote: > As we discussed, the generalized mechanism need local policy to decide if > the server allows such a conflict (same nick). I think the notion that > because they have different domains they are different is wrong. You can > keep them separate for addressing purposes, but you force the UI to deal > with them as the same. I think if nickname part is the same there is a > collision, and either it's allowed or not, and the domain is not part of > that. If it's allowed, the client and the server have to deal with the > issue. I don't like this approach. IMO at the *protocol* level nicknames must be unique - except possibly that if one user has two sessions he may use the same nickname for both. (That needs further consideration.) The point of having domains is to deal with that, and allow two joebobs only when they are in different domains. It is then an issue for the UI to deal with the collisions as it sees fit. Some things it might do: - distinguish by colors - e.g. (red)joebob, (blue)joebob - distinguish with suffixes - e.g. joebob, joebob(2), ... - display first without domain, others with domain: joebob, joebob@biloxi.com - display all with domains: joebob@atlanta.com, joebob@biloxi.com It needn't be our problem to figure out this part. But when I reply to a particular joebob thru my UI, the protocol must identify the particular joebob I meant. > This is not an issue for msrp chat: the text does not allow two users to > have the same nickname. When we get to the generalized mechanism, we have > to make it work for same name, different domain and same name, same domain. I think we could eventually get into a situation where we have a server that supports the msrp nicknames and the more general ones as well. Some clients may use msrp to get their nicknames, and others the other method. They need to interoperate. I see the nickname method in msrp to be just a limited way to *assign* a nickname, but it doesn't limit to *use* of nicknames assigned that way. Paul > Brian > >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >> Sent: Tuesday, August 07, 2007 11:16 AM >> To: Brian Rosen >> Cc: 'Paul Kyzivat'; 'SIMPLE mailing list'; 'Niemi Aki' >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >> >> Inline >> >> Brian Rosen wrote: >>> I think you are too hung up on the fact you can create a URI out of a >>> nickname. There is no more comfort in explicitly providing the URI and >>> forcing the UA (and the server) to decode it to extract the nickname, >> then >>> in sending the nickname and forcing construction of the URI. I think: >>> Set-Nickname joebob >>> is much preferable to >>> Set-Nickname sip:msrp-nickname/joebob/chat34@msrp.example.com >> >> I would agree on the implicit version providing that the response >> contains the full URI. >> >> Still I don't really understand what are we achieving.... >> >>> I didn't remember the detail about how you extend the conference >> package. >>> It's much simpler to just have the nickname be the string, and not the >> URI. >>> It's an extension; there is no reason to require the URI, and we can >> make it >>> anything appropriate. Keep it simple. >> The conference event package is extended with a new element surprisingly >> called . It currently contains the URI. >> >> I think the conference event package needs to send the full URI. >> Otherwise, there might be conflicts if one person with say a local >> nickname shares the nickname with a general domain nickname. When a user >> sends a private message to one of these nicknames, if the nickname is >> not a URI the server is not going to know how to route the message. >> >>> I'm trying to keep this mechanism as close to the generalized mechanism >> as >>> possible. I want to go the other way from you: if you declare a >> nickname >>> with the generalized mechanism, I want the conference package extension >> to >>> not change, >> Agreed. The current extension holds a URI, so if you can represent a >> general nickname as a URI, then it is not a probelm. >> >>> I want you to be able to (generally) mix and match use of the >>> generalized Set with the MSRP Set and I want the form of the >> construction to >>> be the same. >> Generally agreed. I was assuming that the general Set nickname will >> require a domain, so it does the chat-room scoped nickname. But you seem >> to be suggesting the opposite, so I am confused. >> >> The other thing: I believe we came to an agreement that on the >> procedures, we will use Set-Nickname in NICKNAME to set the chat-room >> scoped URI only. Setting a general nickname will be done by some other >> general procedure. Just wanted to confirm that we are on the same page. >> >>> If we get away with that, we won't usually need to distinguish >>> how we set the nickname in the URI. Even if we keep the text pretty >> much as >>> is, I'd prefer to change the prefix to just "nickname". >> Ok, we can change the prefix name to "nickname". >> >>> To be honest, we actually DO need to have an explicit domain in the >>> generalized SET, because it may not be the domain of the >>> chat/conference/whatever. >> Exactly >> >>> I want that in the generalized mechanism and not >>> in the msrp mechanism. I don't want a client with the generalized >> mechanism >>> to be able to send a non local domain in the msrp Set. >> Ok, I can agree with it. As long as the response contains the full URI, >> as I said before. >> >>> I'm worried that the >>> client may not know that the chat server does not support the >> generalized >>> mechanism before he tries that, or using the Supported header for the >>> generalized mechanism to imply what can or cannot be sent in the msrp >> Set. >>> I'd make the domain in the generalized Set a separate parameter in the >> (sip) >>> header, not the constructed URI: >>> Set-Nickname joebob nickserver.example.com >> ok, not a big difference with a uri: sip:joebob@nickserver.example.com >> >>> I think you are mistaken about what the constructor rule does to user >> part >>> syntax. If I choose a username of msrp-nickname/joebob, you can make a >>> valid nickname uri from it, but if I send a regular message, it looks >> like >>> it's from a nickname. You would have to get a full set of nicknames >> from >>> the server and figure this out to know what my actual URI was and >>> distinguish it from my nickname. I worry that there will be >> implementations >>> that will able to be failed by fooling them in this way. I think the >> text >>> should say that usernames can't start with the prefix we choose, and the >>> server should enforce the rule. >> The problem of knowing what is my real nickanme URI is solved if the >> nickname URI returned in the response to the NICKNAME method. >> >> I don't have a problem to say that nicknames can't start by the prefix. >> Paul wanted that feature, but I don't have a problem in either way. >> >> Miguel >> >>> When you use a nickname the message is always sent to the switch. You >>> cannot address any form of message directly to the constructed URI. >> This is >>> why the parameter works. You ARE sending it to the switch, it is >>> translating the URI you send into an actually addressable entity. >>> >>> Brian >>>> -----Original Message----- >>>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >>>> Sent: Tuesday, August 07, 2007 2:57 AM >>>> To: Brian Rosen >>>> Cc: 'Paul Kyzivat'; 'Hisham Khartabil'; 'Niemi Aki'; 'Jonathan >> Rosenberg'; >>>> 'SIMPLE mailing list' >>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>> >>>> Some inline comments >>>> >>>> Brian Rosen wrote: >>>>> Having agreed to proceed with the nickname stuff in MSRP chat, BUT >>>> having >>>>> the benefit of the discussion on generalizing nicknames in the Chicago >>>>> meeting, I'd suggest we simplify as much as possible the MSRP >> mechanism. >>>>> Specifically, I suggest the following: >>>>> >>>>> 1. We don't need a display name on a nick name. Just delete it. >>>> Agreed. No changes with respect the current version of the draft, which >>>> already includes the following text: >>>> >>>> The 'name-addr' ABNF in RFC 3261 allows an optional 'display-name' >> to >>>> prepend the actual URI. For the purpose of conveying nicknames, >>>> display-names MUST NOT be used, because the username part of a >>>> nickname URI provides its rendering property. If the display-name >> is >>>> included in an Use-Nickname header field, it SHOULD be ignored. >>>> Implementations are RECOMMENDED to use only the user part of the >>>> nickname URI for rendering purposes. >>>> >>>> >>>>> 2. We agree that there is a nickname, scoped within a domain, and you >>>> need >>>>> to be able to form a URI from it. The domain in MSRP chat is always >> the >>>>> chat itself. There is the complication that the domain of the chat >> may >>>> have >>>>> content prior to the "@". This problem exists in XCON also. This >> means >>>>> there needs to be a construction rule to form URI from the nick and >> the >>>>> domain, handling this problem. OTOH, there really isn't a reason why >>>> the >>>>> domain needs to be mentioned in the Set-Nickname. You can't use a >>>> NICKNAME >>>>> method outside the domain of a chat, so we know a-priori what the chat >>>>> domain is. >>>> I am trying to understand the benefit of it. >>>> >>>> On one hand, the MSRP endpoint needs to understand the construction for >>>> nickname URIs defined by the document. This is because it is going to >>>> receive participant's nicknames via the conference event package, and >> it >>>> needs to be able to extract the nickname out of the URI for rendering >>>> purposes. >>>> >>>> On the other hand, in the future, there might be participants who have >>>> non-chat-server-scoped nicknames. So, the endpoint needs to know the >>>> structure of the URI. >>>> >>>> If the endpoint needs to know the structure of the URI I would prefer >> to >>>> be explicit and send in the Set-Nickname the full nickname URI that the >>>> user wishes to set. Somehow, I feel more comfortable being explicit. >>>> >>>>> 4. Jonathan proposed a construction rule. I don't understand why we >>>> need a >>>>> prefix. >>>> I think the prefix serves for two purposes. On one side, it is trying >> to >>>> avoid clashes between regular SIP URIs and nickname URIs in the chat >>>> room server/mixer. >>>> >>>> But more important, I think the prefix also indicates the structure or >>>> scheme used in the nickname URI. Assume in the future we come up with >>>> another way to represent nicknames in a URI (perhaps the general >>>> nicknames), then we should have a mechanism to clearly identify which >>>> structure is used. I think the "msrp-nickname" prefix gives us such >>>> property. >>>> >>>> > We could easily put a rule that said, for example, in an MSRP From: >>>> > or To:, a slash must be escaped unless it separates nick from chat >>>> > domain user-part. >>>> >>>> In CPIM From and To. But yes, I agree, slashes must be escaped unless >>>> used for the purpose of separating nicknames from the chat room name. >>>> >>>> > You already imply a rule that says you can't have >>>> > "msrp-nickname" with slashes as a URI in From:/To:. >>>> >>>> You could. Nothing prevents to you to add the string "msrp-nickname" as >>>> part of your nickname. That would lead to: >>>> >>>> sip:msrp-nickname/msrp-nickname/chat33@conf.example.com >>>> >>>> The prefix tells you how to decode the username part; the second >>>> "msrp-nickname" is your actual nickname. If you want to add slashes, >> you >>>> escape them. >>>> >>>> >>>>> So: I propose that Set-Nickname simply have the nickname as the >>>> parameter: >>>>> Set-Nickname: joebob >>>> As I said, I prefer to be explicit. I don't think we gain anything, and >>>> we loose a lot. >>>> >>>>> I propose a construction rule from nickname+chat-domain to a URI >> useable >>>> in >>>>> MSRP From:/To: be to separate the nick from the domain with a slash >> IFF >>>> the >>>>> domain has a userpart. So, for example: >>>>> sip:joebob/chat34@msrp.example.com >>>>> >>>>> Include the rule that a normal URI in From:/To: that has a slash needs >>>> the >>>>> slash to be escaped. >>>>> >>>>> One other thought: the URI construction rule bothers me. I don't like >>>>> forcing new syntax on the user-part, and restricting what the URI can >>>> look >>>>> like. Consider making the nick a parameter to the domain URI in >>>> From:/To: >>>>> like: >>>>> sip:chat34@msrp.example.com;nickname=joebob >>>>> You could allow this syntax always (at least as an alternative) >>>>> sip:chat34.example.com;nickname=joebob >>>> I also proposed the nickname parameter earlier, but there is something >> I >>>> don't like from it: parameters should be modifiers of the resource that >>>> add new characteristics to the resource. Here the resource is the >>>> chatroom URI (as opposed to the user URI), so if we take it literally, >>>> the nickname parameter represents the chat room nickname, not the >> user's >>>> nickname. >>>> >>>> The idea of the nickname URI would be OK in the generic nicknames that >>>> you are working on, so I could write my SIP URI including a nickname, >>>> for example: sip:miguel@example.com;nickname=wine-expert >>>> >>>> /Miguel >>>> >>>>> Brian >>>>> >>>>>> -----Original Message----- >>>>>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >>>>>> Sent: Monday, August 06, 2007 1:32 AM >>>>>> To: Paul Kyzivat; Brian Rosen; 'Hisham Khartabil'; Niemi Aki; >> Jonathan >>>>>> Rosenberg >>>>>> Cc: 'SIMPLE mailing list' >>>>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>>>> >>>>>> Let me try to seek consensus on the issue of the Nickname URI. >>>>>> >>>>>> We have been hearing that we need to allow URIs to be issued by any >>>>>> entity as well as the chat server. We agreed that the MSRP chat draft >>>>>> will tackle only the latter. >>>>>> >>>>>> We haven't really agreed whether we envision MSRP chat operations >>>>>> (namely the NICKNAME method) with domain URIs in the future. The >>>> current >>>>>> version of the draft leaves open space for it, but this has created >>>> some >>>>>> misunderstanding. Since there is current work on generalized >> nicknames >>>> I >>>>>> would suggest that we take the assumption that the MSRP NICKNAME >> method >>>>>> only deals with chat room server scoped nicknames. Domain nicknames >> are >>>>>> not considered with the NICKNAME method. >>>>>> >>>>>> We are having discussions on the representation of a nickname URI. >> Some >>>>>> of these problems come from the fact that we don't really know how to >>>>>> represent domain nicknames and we don't know the relation of them to >>>> the >>>>>> chat room server. I've been thinking that we should decouple the >>>>>> nickname itself from its representation in a URI. So, my suggestion >> is >>>>>> that the MSRP chat draft goes ahead with its representation of >>>> nicknames >>>>>> in a URI, for the purpose of reservation/validation (NICKNAME >> method), >>>>>> having into account that those nicknames are scoped to the focus of >> the >>>>>> conference. Other representation of nicknames (domain-scoped >> nicknames) >>>>>> may appear in From and To headers in CPIM, but not in NICKNAME >> method. >>>>>> Representation of chat room scoped nicknames. We need a mechanism to >>>>>> identify that a nickname URI is effectively a nickname URI, and be >> able >>>>>> to extract the nickname (for rendering in the UI) from the rest of >> teh >>>>>> URI. Jonathan proposed: >>>>>> >>>>>> sip:"msrp-nicknames" "/" "/" @ domain >>>>>> >>>>>> which is correct in my opinion. While there have been other >>>> suggestions, >>>>>> I haven't heard anyone indicating that Jonathan's proposal wouldn't >>>>>> work. So, I suggest we go for it. >>>>>> >>>>>> /Miguel >>>>>> -- >>>>>> Miguel A. Garcia tel:+358-50-4804586 >>>>>> Nokia Siemens Networks Espoo, Finland >>>> -- >>>> 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 >> -- >> 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 From simple-bounces@ietf.org Tue Aug 07 14:43: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 1IIU1x-0007q7-B0; Tue, 07 Aug 2007 14:43:45 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIU1v-0007pu-RC for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 14:43:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIU1v-0007ot-H9 for simple@ietf.org; Tue, 07 Aug 2007 14:43:43 -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 1IIU1t-0006lP-6B for simple@ietf.org; Tue, 07 Aug 2007 14:43:43 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l77IhLnj020131; Tue, 7 Aug 2007 21:43:33 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 21:43:31 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 21:43:31 +0300 Received: from [10.162.65.40] ([10.162.65.40]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 21:43:31 +0300 Message-ID: <46B8BD52.3090807@nsn.com> Date: Tue, 07 Aug 2007 21:43:30 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> In-Reply-To: <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Aug 2007 18:43:31.0419 (UTC) FILETIME=[DA13BAB0:01C7D922] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4c463dcf97e2b913ab242796279c24d2 Cc: 'Paul Kyzivat' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I understand the potential conflict between a generalized nickname URI and chat-room scoped nickname. Yes, we spoke that the policy in the chat room will determine whether it is allowed or not. I am afraid that, in case the conflict is allowed, it is the UI's responsibility to avoid the clash towards the user, rendering them differently. This bring another issue. If a chat room does not allow clashes in the nicknames, then he should prevent them also between different domains (joebob@example.com and joebob@example.net). And it would be very easy to prevent that a user with a legitimate nickname, issued by his nickname server, would never be able to use it in a chat room. We just need a rouge guy who sets the chat-room scoped nickname joebob, preventing the other two to use their regular permanent URIs. /Miguel Brian Rosen wrote: > We're getting closer! > > You want the URI in the response. Your reasoning is: >> Otherwise, there might be conflicts if one person with say a local >> nickname shares the nickname with a general domain nickname. When a user >> sends a private message to one of these nicknames, if the nickname is >> not a URI the server is not going to know how to route the message. > Let me make sure I get your problem: > I have a nickname in nickserver.example.com, say joebob. > > Now, you use the msrp NICKNAME method to create a local nickname, also > joebob > NICKNAME > Set-Nickname joebob > > So, now I have two definitions of joebob, one declared in the chat, one a > more permanent one at nickserver.example.com. The nickname is the same, the > domains are different. > > As we discussed, the generalized mechanism need local policy to decide if > the server allows such a conflict (same nick). I think the notion that > because they have different domains they are different is wrong. You can > keep them separate for addressing purposes, but you force the UI to deal > with them as the same. I think if nickname part is the same there is a > collision, and either it's allowed or not, and the domain is not part of > that. If it's allowed, the client and the server have to deal with the > issue. > > This is not an issue for msrp chat: the text does not allow two users to > have the same nickname. When we get to the generalized mechanism, we have > to make it work for same name, different domain and same name, same domain. > > Brian > >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >> Sent: Tuesday, August 07, 2007 11:16 AM >> To: Brian Rosen >> Cc: 'Paul Kyzivat'; 'SIMPLE mailing list'; 'Niemi Aki' >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >> >> Inline >> >> Brian Rosen wrote: >>> I think you are too hung up on the fact you can create a URI out of a >>> nickname. There is no more comfort in explicitly providing the URI and >>> forcing the UA (and the server) to decode it to extract the nickname, >> then >>> in sending the nickname and forcing construction of the URI. I think: >>> Set-Nickname joebob >>> is much preferable to >>> Set-Nickname sip:msrp-nickname/joebob/chat34@msrp.example.com >> >> I would agree on the implicit version providing that the response >> contains the full URI. >> >> Still I don't really understand what are we achieving.... >> >>> I didn't remember the detail about how you extend the conference >> package. >>> It's much simpler to just have the nickname be the string, and not the >> URI. >>> It's an extension; there is no reason to require the URI, and we can >> make it >>> anything appropriate. Keep it simple. >> The conference event package is extended with a new element surprisingly >> called . It currently contains the URI. >> >> I think the conference event package needs to send the full URI. >> Otherwise, there might be conflicts if one person with say a local >> nickname shares the nickname with a general domain nickname. When a user >> sends a private message to one of these nicknames, if the nickname is >> not a URI the server is not going to know how to route the message. >> >>> I'm trying to keep this mechanism as close to the generalized mechanism >> as >>> possible. I want to go the other way from you: if you declare a >> nickname >>> with the generalized mechanism, I want the conference package extension >> to >>> not change, >> Agreed. The current extension holds a URI, so if you can represent a >> general nickname as a URI, then it is not a probelm. >> >>> I want you to be able to (generally) mix and match use of the >>> generalized Set with the MSRP Set and I want the form of the >> construction to >>> be the same. >> Generally agreed. I was assuming that the general Set nickname will >> require a domain, so it does the chat-room scoped nickname. But you seem >> to be suggesting the opposite, so I am confused. >> >> The other thing: I believe we came to an agreement that on the >> procedures, we will use Set-Nickname in NICKNAME to set the chat-room >> scoped URI only. Setting a general nickname will be done by some other >> general procedure. Just wanted to confirm that we are on the same page. >> >>> If we get away with that, we won't usually need to distinguish >>> how we set the nickname in the URI. Even if we keep the text pretty >> much as >>> is, I'd prefer to change the prefix to just "nickname". >> Ok, we can change the prefix name to "nickname". >> >>> To be honest, we actually DO need to have an explicit domain in the >>> generalized SET, because it may not be the domain of the >>> chat/conference/whatever. >> Exactly >> >>> I want that in the generalized mechanism and not >>> in the msrp mechanism. I don't want a client with the generalized >> mechanism >>> to be able to send a non local domain in the msrp Set. >> Ok, I can agree with it. As long as the response contains the full URI, >> as I said before. >> >>> I'm worried that the >>> client may not know that the chat server does not support the >> generalized >>> mechanism before he tries that, or using the Supported header for the >>> generalized mechanism to imply what can or cannot be sent in the msrp >> Set. >>> I'd make the domain in the generalized Set a separate parameter in the >> (sip) >>> header, not the constructed URI: >>> Set-Nickname joebob nickserver.example.com >> ok, not a big difference with a uri: sip:joebob@nickserver.example.com >> >>> I think you are mistaken about what the constructor rule does to user >> part >>> syntax. If I choose a username of msrp-nickname/joebob, you can make a >>> valid nickname uri from it, but if I send a regular message, it looks >> like >>> it's from a nickname. You would have to get a full set of nicknames >> from >>> the server and figure this out to know what my actual URI was and >>> distinguish it from my nickname. I worry that there will be >> implementations >>> that will able to be failed by fooling them in this way. I think the >> text >>> should say that usernames can't start with the prefix we choose, and the >>> server should enforce the rule. >> The problem of knowing what is my real nickanme URI is solved if the >> nickname URI returned in the response to the NICKNAME method. >> >> I don't have a problem to say that nicknames can't start by the prefix. >> Paul wanted that feature, but I don't have a problem in either way. >> >> Miguel >> >>> When you use a nickname the message is always sent to the switch. You >>> cannot address any form of message directly to the constructed URI. >> This is >>> why the parameter works. You ARE sending it to the switch, it is >>> translating the URI you send into an actually addressable entity. >>> >>> Brian >>>> -----Original Message----- >>>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >>>> Sent: Tuesday, August 07, 2007 2:57 AM >>>> To: Brian Rosen >>>> Cc: 'Paul Kyzivat'; 'Hisham Khartabil'; 'Niemi Aki'; 'Jonathan >> Rosenberg'; >>>> 'SIMPLE mailing list' >>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>> >>>> Some inline comments >>>> >>>> Brian Rosen wrote: >>>>> Having agreed to proceed with the nickname stuff in MSRP chat, BUT >>>> having >>>>> the benefit of the discussion on generalizing nicknames in the Chicago >>>>> meeting, I'd suggest we simplify as much as possible the MSRP >> mechanism. >>>>> Specifically, I suggest the following: >>>>> >>>>> 1. We don't need a display name on a nick name. Just delete it. >>>> Agreed. No changes with respect the current version of the draft, which >>>> already includes the following text: >>>> >>>> The 'name-addr' ABNF in RFC 3261 allows an optional 'display-name' >> to >>>> prepend the actual URI. For the purpose of conveying nicknames, >>>> display-names MUST NOT be used, because the username part of a >>>> nickname URI provides its rendering property. If the display-name >> is >>>> included in an Use-Nickname header field, it SHOULD be ignored. >>>> Implementations are RECOMMENDED to use only the user part of the >>>> nickname URI for rendering purposes. >>>> >>>> >>>>> 2. We agree that there is a nickname, scoped within a domain, and you >>>> need >>>>> to be able to form a URI from it. The domain in MSRP chat is always >> the >>>>> chat itself. There is the complication that the domain of the chat >> may >>>> have >>>>> content prior to the "@". This problem exists in XCON also. This >> means >>>>> there needs to be a construction rule to form URI from the nick and >> the >>>>> domain, handling this problem. OTOH, there really isn't a reason why >>>> the >>>>> domain needs to be mentioned in the Set-Nickname. You can't use a >>>> NICKNAME >>>>> method outside the domain of a chat, so we know a-priori what the chat >>>>> domain is. >>>> I am trying to understand the benefit of it. >>>> >>>> On one hand, the MSRP endpoint needs to understand the construction for >>>> nickname URIs defined by the document. This is because it is going to >>>> receive participant's nicknames via the conference event package, and >> it >>>> needs to be able to extract the nickname out of the URI for rendering >>>> purposes. >>>> >>>> On the other hand, in the future, there might be participants who have >>>> non-chat-server-scoped nicknames. So, the endpoint needs to know the >>>> structure of the URI. >>>> >>>> If the endpoint needs to know the structure of the URI I would prefer >> to >>>> be explicit and send in the Set-Nickname the full nickname URI that the >>>> user wishes to set. Somehow, I feel more comfortable being explicit. >>>> >>>>> 4. Jonathan proposed a construction rule. I don't understand why we >>>> need a >>>>> prefix. >>>> I think the prefix serves for two purposes. On one side, it is trying >> to >>>> avoid clashes between regular SIP URIs and nickname URIs in the chat >>>> room server/mixer. >>>> >>>> But more important, I think the prefix also indicates the structure or >>>> scheme used in the nickname URI. Assume in the future we come up with >>>> another way to represent nicknames in a URI (perhaps the general >>>> nicknames), then we should have a mechanism to clearly identify which >>>> structure is used. I think the "msrp-nickname" prefix gives us such >>>> property. >>>> >>>> > We could easily put a rule that said, for example, in an MSRP From: >>>> > or To:, a slash must be escaped unless it separates nick from chat >>>> > domain user-part. >>>> >>>> In CPIM From and To. But yes, I agree, slashes must be escaped unless >>>> used for the purpose of separating nicknames from the chat room name. >>>> >>>> > You already imply a rule that says you can't have >>>> > "msrp-nickname" with slashes as a URI in From:/To:. >>>> >>>> You could. Nothing prevents to you to add the string "msrp-nickname" as >>>> part of your nickname. That would lead to: >>>> >>>> sip:msrp-nickname/msrp-nickname/chat33@conf.example.com >>>> >>>> The prefix tells you how to decode the username part; the second >>>> "msrp-nickname" is your actual nickname. If you want to add slashes, >> you >>>> escape them. >>>> >>>> >>>>> So: I propose that Set-Nickname simply have the nickname as the >>>> parameter: >>>>> Set-Nickname: joebob >>>> As I said, I prefer to be explicit. I don't think we gain anything, and >>>> we loose a lot. >>>> >>>>> I propose a construction rule from nickname+chat-domain to a URI >> useable >>>> in >>>>> MSRP From:/To: be to separate the nick from the domain with a slash >> IFF >>>> the >>>>> domain has a userpart. So, for example: >>>>> sip:joebob/chat34@msrp.example.com >>>>> >>>>> Include the rule that a normal URI in From:/To: that has a slash needs >>>> the >>>>> slash to be escaped. >>>>> >>>>> One other thought: the URI construction rule bothers me. I don't like >>>>> forcing new syntax on the user-part, and restricting what the URI can >>>> look >>>>> like. Consider making the nick a parameter to the domain URI in >>>> From:/To: >>>>> like: >>>>> sip:chat34@msrp.example.com;nickname=joebob >>>>> You could allow this syntax always (at least as an alternative) >>>>> sip:chat34.example.com;nickname=joebob >>>> I also proposed the nickname parameter earlier, but there is something >> I >>>> don't like from it: parameters should be modifiers of the resource that >>>> add new characteristics to the resource. Here the resource is the >>>> chatroom URI (as opposed to the user URI), so if we take it literally, >>>> the nickname parameter represents the chat room nickname, not the >> user's >>>> nickname. >>>> >>>> The idea of the nickname URI would be OK in the generic nicknames that >>>> you are working on, so I could write my SIP URI including a nickname, >>>> for example: sip:miguel@example.com;nickname=wine-expert >>>> >>>> /Miguel >>>> >>>>> Brian >>>>> >>>>>> -----Original Message----- >>>>>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >>>>>> Sent: Monday, August 06, 2007 1:32 AM >>>>>> To: Paul Kyzivat; Brian Rosen; 'Hisham Khartabil'; Niemi Aki; >> Jonathan >>>>>> Rosenberg >>>>>> Cc: 'SIMPLE mailing list' >>>>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>>>> >>>>>> Let me try to seek consensus on the issue of the Nickname URI. >>>>>> >>>>>> We have been hearing that we need to allow URIs to be issued by any >>>>>> entity as well as the chat server. We agreed that the MSRP chat draft >>>>>> will tackle only the latter. >>>>>> >>>>>> We haven't really agreed whether we envision MSRP chat operations >>>>>> (namely the NICKNAME method) with domain URIs in the future. The >>>> current >>>>>> version of the draft leaves open space for it, but this has created >>>> some >>>>>> misunderstanding. Since there is current work on generalized >> nicknames >>>> I >>>>>> would suggest that we take the assumption that the MSRP NICKNAME >> method >>>>>> only deals with chat room server scoped nicknames. Domain nicknames >> are >>>>>> not considered with the NICKNAME method. >>>>>> >>>>>> We are having discussions on the representation of a nickname URI. >> Some >>>>>> of these problems come from the fact that we don't really know how to >>>>>> represent domain nicknames and we don't know the relation of them to >>>> the >>>>>> chat room server. I've been thinking that we should decouple the >>>>>> nickname itself from its representation in a URI. So, my suggestion >> is >>>>>> that the MSRP chat draft goes ahead with its representation of >>>> nicknames >>>>>> in a URI, for the purpose of reservation/validation (NICKNAME >> method), >>>>>> having into account that those nicknames are scoped to the focus of >> the >>>>>> conference. Other representation of nicknames (domain-scoped >> nicknames) >>>>>> may appear in From and To headers in CPIM, but not in NICKNAME >> method. >>>>>> Representation of chat room scoped nicknames. We need a mechanism to >>>>>> identify that a nickname URI is effectively a nickname URI, and be >> able >>>>>> to extract the nickname (for rendering in the UI) from the rest of >> teh >>>>>> URI. Jonathan proposed: >>>>>> >>>>>> sip:"msrp-nicknames" "/" "/" @ domain >>>>>> >>>>>> which is correct in my opinion. While there have been other >>>> suggestions, >>>>>> I haven't heard anyone indicating that Jonathan's proposal wouldn't >>>>>> work. So, I suggest we go for it. >>>>>> >>>>>> /Miguel >>>>>> -- >>>>>> Miguel A. Garcia tel:+358-50-4804586 >>>>>> Nokia Siemens Networks Espoo, Finland >>>> -- >>>> 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 >> -- >> 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 -- 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 From simple-bounces@ietf.org Tue Aug 07 14:45:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIU3i-0008Vs-Vv; Tue, 07 Aug 2007 14:45:34 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIU3h-0008Vm-2O for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 14:45:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIU3g-0008Vd-Ov for simple@ietf.org; Tue, 07 Aug 2007 14:45:32 -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 1IIU3e-0006oH-Lc for simple@ietf.org; Tue, 07 Aug 2007 14:45:32 -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 l77Iiw1m007157; Tue, 7 Aug 2007 21:45:23 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 21:45:10 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 21:45:09 +0300 Received: from [10.162.65.40] ([10.162.65.40]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 21:45:09 +0300 Message-ID: <46B8BDB4.8080602@nsn.com> Date: Tue, 07 Aug 2007 21:45:08 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> In-Reply-To: <46B8BCD4.4030800@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Aug 2007 18:45:09.0324 (UTC) FILETIME=[146ED8C0:01C7D923] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1 Cc: 'Niemi Aki' , '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 with Paul. /Miguel Paul Kyzivat wrote: > Joebob - comments inline. > > Paul > > Brian Rosen wrote: > >> As we discussed, the generalized mechanism need local policy to decide if >> the server allows such a conflict (same nick). I think the notion that >> because they have different domains they are different is wrong. You can >> keep them separate for addressing purposes, but you force the UI to deal >> with them as the same. I think if nickname part is the same there is a >> collision, and either it's allowed or not, and the domain is not part of >> that. If it's allowed, the client and the server have to deal with the >> issue. > > I don't like this approach. IMO at the *protocol* level nicknames must > be unique - except possibly that if one user has two sessions he may use > the same nickname for both. (That needs further consideration.) > > The point of having domains is to deal with that, and allow two joebobs > only when they are in different domains. > > It is then an issue for the UI to deal with the collisions as it sees > fit. Some things it might do: > - distinguish by colors - e.g. (red)joebob, (blue)joebob > - distinguish with suffixes - e.g. joebob, joebob(2), ... > - display first without domain, others with domain: > joebob, joebob@biloxi.com > - display all with domains: joebob@atlanta.com, joebob@biloxi.com > > It needn't be our problem to figure out this part. > > But when I reply to a particular joebob thru my UI, the protocol must > identify the particular joebob I meant. > >> This is not an issue for msrp chat: the text does not allow two users to >> have the same nickname. When we get to the generalized mechanism, we >> have >> to make it work for same name, different domain and same name, same >> domain. > > I think we could eventually get into a situation where we have a server > that supports the msrp nicknames and the more general ones as well. Some > clients may use msrp to get their nicknames, and others the other > method. They need to interoperate. > > I see the nickname method in msrp to be just a limited way to *assign* a > nickname, but it doesn't limit to *use* of nicknames assigned that way. > > Paul > >> Brian >> >>> -----Original Message----- >>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >>> Sent: Tuesday, August 07, 2007 11:16 AM >>> To: Brian Rosen >>> Cc: 'Paul Kyzivat'; 'SIMPLE mailing list'; 'Niemi Aki' >>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>> >>> Inline >>> >>> Brian Rosen wrote: >>>> I think you are too hung up on the fact you can create a URI out of a >>>> nickname. There is no more comfort in explicitly providing the URI and >>>> forcing the UA (and the server) to decode it to extract the nickname, >>> then >>>> in sending the nickname and forcing construction of the URI. I think: >>>> Set-Nickname joebob >>>> is much preferable to >>>> Set-Nickname sip:msrp-nickname/joebob/chat34@msrp.example.com >>> >>> I would agree on the implicit version providing that the response >>> contains the full URI. >>> >>> Still I don't really understand what are we achieving.... >>> >>>> I didn't remember the detail about how you extend the conference >>> package. >>>> It's much simpler to just have the nickname be the string, and not the >>> URI. >>>> It's an extension; there is no reason to require the URI, and we can >>> make it >>>> anything appropriate. Keep it simple. >>> The conference event package is extended with a new element surprisingly >>> called . It currently contains the URI. >>> >>> I think the conference event package needs to send the full URI. >>> Otherwise, there might be conflicts if one person with say a local >>> nickname shares the nickname with a general domain nickname. When a user >>> sends a private message to one of these nicknames, if the nickname is >>> not a URI the server is not going to know how to route the message. >>> >>>> I'm trying to keep this mechanism as close to the generalized mechanism >>> as >>>> possible. I want to go the other way from you: if you declare a >>> nickname >>>> with the generalized mechanism, I want the conference package extension >>> to >>>> not change, >>> Agreed. The current extension holds a URI, so if you can represent a >>> general nickname as a URI, then it is not a probelm. >>> >>>> I want you to be able to (generally) mix and match use of the >>>> generalized Set with the MSRP Set and I want the form of the >>> construction to >>>> be the same. >>> Generally agreed. I was assuming that the general Set nickname will >>> require a domain, so it does the chat-room scoped nickname. But you seem >>> to be suggesting the opposite, so I am confused. >>> >>> The other thing: I believe we came to an agreement that on the >>> procedures, we will use Set-Nickname in NICKNAME to set the chat-room >>> scoped URI only. Setting a general nickname will be done by some other >>> general procedure. Just wanted to confirm that we are on the same page. >>> >>>> If we get away with that, we won't usually need to distinguish >>>> how we set the nickname in the URI. Even if we keep the text pretty >>> much as >>>> is, I'd prefer to change the prefix to just "nickname". >>> Ok, we can change the prefix name to "nickname". >>> >>>> To be honest, we actually DO need to have an explicit domain in the >>>> generalized SET, because it may not be the domain of the >>>> chat/conference/whatever. >>> Exactly >>> >>>> I want that in the generalized mechanism and not >>>> in the msrp mechanism. I don't want a client with the generalized >>> mechanism >>>> to be able to send a non local domain in the msrp Set. >>> Ok, I can agree with it. As long as the response contains the full URI, >>> as I said before. >>> >>>> I'm worried that the >>>> client may not know that the chat server does not support the >>> generalized >>>> mechanism before he tries that, or using the Supported header for the >>>> generalized mechanism to imply what can or cannot be sent in the msrp >>> Set. >>>> I'd make the domain in the generalized Set a separate parameter in the >>> (sip) >>>> header, not the constructed URI: >>>> Set-Nickname joebob nickserver.example.com >>> ok, not a big difference with a uri: sip:joebob@nickserver.example.com >>> >>>> I think you are mistaken about what the constructor rule does to user >>> part >>>> syntax. If I choose a username of msrp-nickname/joebob, you can make a >>>> valid nickname uri from it, but if I send a regular message, it looks >>> like >>>> it's from a nickname. You would have to get a full set of nicknames >>> from >>>> the server and figure this out to know what my actual URI was and >>>> distinguish it from my nickname. I worry that there will be >>> implementations >>>> that will able to be failed by fooling them in this way. I think the >>> text >>>> should say that usernames can't start with the prefix we choose, and >>>> the >>>> server should enforce the rule. >>> The problem of knowing what is my real nickanme URI is solved if the >>> nickname URI returned in the response to the NICKNAME method. >>> >>> I don't have a problem to say that nicknames can't start by the prefix. >>> Paul wanted that feature, but I don't have a problem in either way. >>> >>> Miguel >>> >>>> When you use a nickname the message is always sent to the switch. You >>>> cannot address any form of message directly to the constructed URI. >>> This is >>>> why the parameter works. You ARE sending it to the switch, it is >>>> translating the URI you send into an actually addressable entity. >>>> >>>> Brian >>>>> -----Original Message----- >>>>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >>>>> Sent: Tuesday, August 07, 2007 2:57 AM >>>>> To: Brian Rosen >>>>> Cc: 'Paul Kyzivat'; 'Hisham Khartabil'; 'Niemi Aki'; 'Jonathan >>> Rosenberg'; >>>>> 'SIMPLE mailing list' >>>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>>> >>>>> Some inline comments >>>>> >>>>> Brian Rosen wrote: >>>>>> Having agreed to proceed with the nickname stuff in MSRP chat, BUT >>>>> having >>>>>> the benefit of the discussion on generalizing nicknames in the >>>>>> Chicago >>>>>> meeting, I'd suggest we simplify as much as possible the MSRP >>> mechanism. >>>>>> Specifically, I suggest the following: >>>>>> >>>>>> 1. We don't need a display name on a nick name. Just delete it. >>>>> Agreed. No changes with respect the current version of the draft, >>>>> which >>>>> already includes the following text: >>>>> >>>>> The 'name-addr' ABNF in RFC 3261 allows an optional 'display-name' >>> to >>>>> prepend the actual URI. For the purpose of conveying nicknames, >>>>> display-names MUST NOT be used, because the username part of a >>>>> nickname URI provides its rendering property. If the display-name >>> is >>>>> included in an Use-Nickname header field, it SHOULD be ignored. >>>>> Implementations are RECOMMENDED to use only the user part of the >>>>> nickname URI for rendering purposes. >>>>> >>>>> >>>>>> 2. We agree that there is a nickname, scoped within a domain, and you >>>>> need >>>>>> to be able to form a URI from it. The domain in MSRP chat is always >>> the >>>>>> chat itself. There is the complication that the domain of the chat >>> may >>>>> have >>>>>> content prior to the "@". This problem exists in XCON also. This >>> means >>>>>> there needs to be a construction rule to form URI from the nick and >>> the >>>>>> domain, handling this problem. OTOH, there really isn't a reason why >>>>> the >>>>>> domain needs to be mentioned in the Set-Nickname. You can't use a >>>>> NICKNAME >>>>>> method outside the domain of a chat, so we know a-priori what the >>>>>> chat >>>>>> domain is. >>>>> I am trying to understand the benefit of it. >>>>> >>>>> On one hand, the MSRP endpoint needs to understand the construction >>>>> for >>>>> nickname URIs defined by the document. This is because it is going to >>>>> receive participant's nicknames via the conference event package, and >>> it >>>>> needs to be able to extract the nickname out of the URI for rendering >>>>> purposes. >>>>> >>>>> On the other hand, in the future, there might be participants who have >>>>> non-chat-server-scoped nicknames. So, the endpoint needs to know the >>>>> structure of the URI. >>>>> >>>>> If the endpoint needs to know the structure of the URI I would prefer >>> to >>>>> be explicit and send in the Set-Nickname the full nickname URI that >>>>> the >>>>> user wishes to set. Somehow, I feel more comfortable being explicit. >>>>> >>>>>> 4. Jonathan proposed a construction rule. I don't understand why we >>>>> need a >>>>>> prefix. >>>>> I think the prefix serves for two purposes. On one side, it is trying >>> to >>>>> avoid clashes between regular SIP URIs and nickname URIs in the chat >>>>> room server/mixer. >>>>> >>>>> But more important, I think the prefix also indicates the structure or >>>>> scheme used in the nickname URI. Assume in the future we come up with >>>>> another way to represent nicknames in a URI (perhaps the general >>>>> nicknames), then we should have a mechanism to clearly identify which >>>>> structure is used. I think the "msrp-nickname" prefix gives us such >>>>> property. >>>>> >>>>> > We could easily put a rule that said, for example, in an MSRP From: >>>>> > or To:, a slash must be escaped unless it separates nick from chat >>>>> > domain user-part. >>>>> >>>>> In CPIM From and To. But yes, I agree, slashes must be escaped unless >>>>> used for the purpose of separating nicknames from the chat room name. >>>>> >>>>> > You already imply a rule that says you can't have >>>>> > "msrp-nickname" with slashes as a URI in From:/To:. >>>>> >>>>> You could. Nothing prevents to you to add the string >>>>> "msrp-nickname" as >>>>> part of your nickname. That would lead to: >>>>> >>>>> sip:msrp-nickname/msrp-nickname/chat33@conf.example.com >>>>> >>>>> The prefix tells you how to decode the username part; the second >>>>> "msrp-nickname" is your actual nickname. If you want to add slashes, >>> you >>>>> escape them. >>>>> >>>>> >>>>>> So: I propose that Set-Nickname simply have the nickname as the >>>>> parameter: >>>>>> Set-Nickname: joebob >>>>> As I said, I prefer to be explicit. I don't think we gain anything, >>>>> and >>>>> we loose a lot. >>>>> >>>>>> I propose a construction rule from nickname+chat-domain to a URI >>> useable >>>>> in >>>>>> MSRP From:/To: be to separate the nick from the domain with a slash >>> IFF >>>>> the >>>>>> domain has a userpart. So, for example: >>>>>> sip:joebob/chat34@msrp.example.com >>>>>> >>>>>> Include the rule that a normal URI in From:/To: that has a slash >>>>>> needs >>>>> the >>>>>> slash to be escaped. >>>>>> >>>>>> One other thought: the URI construction rule bothers me. I don't >>>>>> like >>>>>> forcing new syntax on the user-part, and restricting what the URI can >>>>> look >>>>>> like. Consider making the nick a parameter to the domain URI in >>>>> From:/To: >>>>>> like: >>>>>> sip:chat34@msrp.example.com;nickname=joebob >>>>>> You could allow this syntax always (at least as an alternative) >>>>>> sip:chat34.example.com;nickname=joebob >>>>> I also proposed the nickname parameter earlier, but there is something >>> I >>>>> don't like from it: parameters should be modifiers of the resource >>>>> that >>>>> add new characteristics to the resource. Here the resource is the >>>>> chatroom URI (as opposed to the user URI), so if we take it literally, >>>>> the nickname parameter represents the chat room nickname, not the >>> user's >>>>> nickname. >>>>> >>>>> The idea of the nickname URI would be OK in the generic nicknames that >>>>> you are working on, so I could write my SIP URI including a nickname, >>>>> for example: sip:miguel@example.com;nickname=wine-expert >>>>> >>>>> /Miguel >>>>> >>>>>> Brian >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >>>>>>> Sent: Monday, August 06, 2007 1:32 AM >>>>>>> To: Paul Kyzivat; Brian Rosen; 'Hisham Khartabil'; Niemi Aki; >>> Jonathan >>>>>>> Rosenberg >>>>>>> Cc: 'SIMPLE mailing list' >>>>>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>>>>> >>>>>>> Let me try to seek consensus on the issue of the Nickname URI. >>>>>>> >>>>>>> We have been hearing that we need to allow URIs to be issued by any >>>>>>> entity as well as the chat server. We agreed that the MSRP chat >>>>>>> draft >>>>>>> will tackle only the latter. >>>>>>> >>>>>>> We haven't really agreed whether we envision MSRP chat operations >>>>>>> (namely the NICKNAME method) with domain URIs in the future. The >>>>> current >>>>>>> version of the draft leaves open space for it, but this has created >>>>> some >>>>>>> misunderstanding. Since there is current work on generalized >>> nicknames >>>>> I >>>>>>> would suggest that we take the assumption that the MSRP NICKNAME >>> method >>>>>>> only deals with chat room server scoped nicknames. Domain nicknames >>> are >>>>>>> not considered with the NICKNAME method. >>>>>>> >>>>>>> We are having discussions on the representation of a nickname URI. >>> Some >>>>>>> of these problems come from the fact that we don't really know >>>>>>> how to >>>>>>> represent domain nicknames and we don't know the relation of them to >>>>> the >>>>>>> chat room server. I've been thinking that we should decouple the >>>>>>> nickname itself from its representation in a URI. So, my suggestion >>> is >>>>>>> that the MSRP chat draft goes ahead with its representation of >>>>> nicknames >>>>>>> in a URI, for the purpose of reservation/validation (NICKNAME >>> method), >>>>>>> having into account that those nicknames are scoped to the focus of >>> the >>>>>>> conference. Other representation of nicknames (domain-scoped >>> nicknames) >>>>>>> may appear in From and To headers in CPIM, but not in NICKNAME >>> method. >>>>>>> Representation of chat room scoped nicknames. We need a mechanism to >>>>>>> identify that a nickname URI is effectively a nickname URI, and be >>> able >>>>>>> to extract the nickname (for rendering in the UI) from the rest of >>> teh >>>>>>> URI. Jonathan proposed: >>>>>>> >>>>>>> sip:"msrp-nicknames" "/" "/" @ domain >>>>>>> >>>>>>> which is correct in my opinion. While there have been other >>>>> suggestions, >>>>>>> I haven't heard anyone indicating that Jonathan's proposal >>>>>>> wouldn't >>>>>>> work. So, I suggest we go for it. >>>>>>> >>>>>>> /Miguel >>>>>>> -- >>>>>>> Miguel A. Garcia tel:+358-50-4804586 >>>>>>> Nokia Siemens Networks Espoo, Finland >>>>> -- >>>>> 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 >>> -- >>> Miguel A. Garcia tel:+358-50-4804586 >>> Nokia Siemens Networks Espoo, Finland >> -- 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 From simple-bounces@ietf.org Tue Aug 07 16:29:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIVfo-0004OU-GA; Tue, 07 Aug 2007 16:29:00 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIVfn-0004OO-MZ for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 16:28:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIVfn-0004OF-Cr for simple@ietf.org; Tue, 07 Aug 2007 16:28:59 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIVfl-0002EB-Un for simple@ietf.org; Tue, 07 Aug 2007 16:28:59 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IIVfT-0001aI-Rv; Tue, 07 Aug 2007 15:28:40 -0500 From: "Brian Rosen" To: "'Miguel Garcia'" , "'Paul Kyzivat'" References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Tue, 7 Aug 2007 16:28:48 -0400 Message-ID: <087901c7d931$917494f0$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: AcfZIxhpqWx7OQZiSWCtQkM97/sHUAADOpVw In-reply-to: <46B8BDB4.8080602@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: 57b3d456dc4730784e7070d5c6b7d14f Cc: 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I think this leads to users not understanding why their nicknames work sometimes and not others: Example 1: My nickname is joebob. Your nickname is joebob. Neither of us is registered. We both ask the chat server to give us joebob. I get there first, and you get an error. Example 2: My nickname is joebob. Your nickname is joebob. I am registered at some other domain. We both ask the chat server to give us joebob. I get there first, but this time it works for you. You would have to know that I registered my nick somewhere else, so my URI is unique, to know why you got an error in the first example, but didn't in the second. Normally, the URI isn't visible to the users, only the names are. If you allow a nickname collision, you incur costs at both the server and the clients. You can't avoid them. Collision really is the name; the domain MAY help you, but since it can't fix the whole problem, it isn't useful. Note that we are discussing the generalized nickname mechanisms, not the msrp-chat. We're projecting a problem onto that mechanism and trying to solve it here. In msrp-chat, you can't have a collision. Brian > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > Sent: Tuesday, August 07, 2007 2:45 PM > To: Paul Kyzivat > Cc: Brian Rosen; 'SIMPLE mailing list'; 'Niemi Aki' > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > I agree with Paul. > > /Miguel > > Paul Kyzivat wrote: > > Joebob - comments inline. > > > > Paul > > > > Brian Rosen wrote: > > > >> As we discussed, the generalized mechanism need local policy to decide > if > >> the server allows such a conflict (same nick). I think the notion that > >> because they have different domains they are different is wrong. You > can > >> keep them separate for addressing purposes, but you force the UI to > deal > >> with them as the same. I think if nickname part is the same there is a > >> collision, and either it's allowed or not, and the domain is not part > of > >> that. If it's allowed, the client and the server have to deal with the > >> issue. > > > > I don't like this approach. IMO at the *protocol* level nicknames must > > be unique - except possibly that if one user has two sessions he may use > > the same nickname for both. (That needs further consideration.) > > > > The point of having domains is to deal with that, and allow two joebobs > > only when they are in different domains. > > > > It is then an issue for the UI to deal with the collisions as it sees > > fit. Some things it might do: > > - distinguish by colors - e.g. (red)joebob, (blue)joebob > > - distinguish with suffixes - e.g. joebob, joebob(2), ... > > - display first without domain, others with domain: > > joebob, joebob@biloxi.com > > - display all with domains: joebob@atlanta.com, joebob@biloxi.com > > > > It needn't be our problem to figure out this part. > > > > But when I reply to a particular joebob thru my UI, the protocol must > > identify the particular joebob I meant. > > > >> This is not an issue for msrp chat: the text does not allow two users > to > >> have the same nickname. When we get to the generalized mechanism, we > >> have > >> to make it work for same name, different domain and same name, same > >> domain. > > > > I think we could eventually get into a situation where we have a server > > that supports the msrp nicknames and the more general ones as well. Some > > clients may use msrp to get their nicknames, and others the other > > method. They need to interoperate. > > > > I see the nickname method in msrp to be just a limited way to *assign* a > > nickname, but it doesn't limit to *use* of nicknames assigned that way. > > > > Paul > > > >> Brian > >> > >>> -----Original Message----- > >>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > >>> Sent: Tuesday, August 07, 2007 11:16 AM > >>> To: Brian Rosen > >>> Cc: 'Paul Kyzivat'; 'SIMPLE mailing list'; 'Niemi Aki' > >>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > >>> > >>> Inline > >>> > >>> Brian Rosen wrote: > >>>> I think you are too hung up on the fact you can create a URI out of a > >>>> nickname. There is no more comfort in explicitly providing the URI > and > >>>> forcing the UA (and the server) to decode it to extract the nickname, > >>> then > >>>> in sending the nickname and forcing construction of the URI. I > think: > >>>> Set-Nickname joebob > >>>> is much preferable to > >>>> Set-Nickname sip:msrp-nickname/joebob/chat34@msrp.example.com > >>> > >>> I would agree on the implicit version providing that the response > >>> contains the full URI. > >>> > >>> Still I don't really understand what are we achieving.... > >>> > >>>> I didn't remember the detail about how you extend the conference > >>> package. > >>>> It's much simpler to just have the nickname be the string, and not > the > >>> URI. > >>>> It's an extension; there is no reason to require the URI, and we can > >>> make it > >>>> anything appropriate. Keep it simple. > >>> The conference event package is extended with a new element > surprisingly > >>> called . It currently contains the URI. > >>> > >>> I think the conference event package needs to send the full URI. > >>> Otherwise, there might be conflicts if one person with say a local > >>> nickname shares the nickname with a general domain nickname. When a > user > >>> sends a private message to one of these nicknames, if the nickname is > >>> not a URI the server is not going to know how to route the message. > >>> > >>>> I'm trying to keep this mechanism as close to the generalized > mechanism > >>> as > >>>> possible. I want to go the other way from you: if you declare a > >>> nickname > >>>> with the generalized mechanism, I want the conference package > extension > >>> to > >>>> not change, > >>> Agreed. The current extension holds a URI, so if you can represent a > >>> general nickname as a URI, then it is not a probelm. > >>> > >>>> I want you to be able to (generally) mix and match use of the > >>>> generalized Set with the MSRP Set and I want the form of the > >>> construction to > >>>> be the same. > >>> Generally agreed. I was assuming that the general Set nickname will > >>> require a domain, so it does the chat-room scoped nickname. But you > seem > >>> to be suggesting the opposite, so I am confused. > >>> > >>> The other thing: I believe we came to an agreement that on the > >>> procedures, we will use Set-Nickname in NICKNAME to set the chat-room > >>> scoped URI only. Setting a general nickname will be done by some other > >>> general procedure. Just wanted to confirm that we are on the same > page. > >>> > >>>> If we get away with that, we won't usually need to distinguish > >>>> how we set the nickname in the URI. Even if we keep the text pretty > >>> much as > >>>> is, I'd prefer to change the prefix to just "nickname". > >>> Ok, we can change the prefix name to "nickname". > >>> > >>>> To be honest, we actually DO need to have an explicit domain in the > >>>> generalized SET, because it may not be the domain of the > >>>> chat/conference/whatever. > >>> Exactly > >>> > >>>> I want that in the generalized mechanism and not > >>>> in the msrp mechanism. I don't want a client with the generalized > >>> mechanism > >>>> to be able to send a non local domain in the msrp Set. > >>> Ok, I can agree with it. As long as the response contains the full > URI, > >>> as I said before. > >>> > >>>> I'm worried that the > >>>> client may not know that the chat server does not support the > >>> generalized > >>>> mechanism before he tries that, or using the Supported header for the > >>>> generalized mechanism to imply what can or cannot be sent in the msrp > >>> Set. > >>>> I'd make the domain in the generalized Set a separate parameter in > the > >>> (sip) > >>>> header, not the constructed URI: > >>>> Set-Nickname joebob nickserver.example.com > >>> ok, not a big difference with a uri: sip:joebob@nickserver.example.com > >>> > >>>> I think you are mistaken about what the constructor rule does to user > >>> part > >>>> syntax. If I choose a username of msrp-nickname/joebob, you can make > a > >>>> valid nickname uri from it, but if I send a regular message, it looks > >>> like > >>>> it's from a nickname. You would have to get a full set of nicknames > >>> from > >>>> the server and figure this out to know what my actual URI was and > >>>> distinguish it from my nickname. I worry that there will be > >>> implementations > >>>> that will able to be failed by fooling them in this way. I think the > >>> text > >>>> should say that usernames can't start with the prefix we choose, and > >>>> the > >>>> server should enforce the rule. > >>> The problem of knowing what is my real nickanme URI is solved if the > >>> nickname URI returned in the response to the NICKNAME method. > >>> > >>> I don't have a problem to say that nicknames can't start by the > prefix. > >>> Paul wanted that feature, but I don't have a problem in either way. > >>> > >>> Miguel > >>> > >>>> When you use a nickname the message is always sent to the switch. > You > >>>> cannot address any form of message directly to the constructed URI. > >>> This is > >>>> why the parameter works. You ARE sending it to the switch, it is > >>>> translating the URI you send into an actually addressable entity. > >>>> > >>>> Brian > >>>>> -----Original Message----- > >>>>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > >>>>> Sent: Tuesday, August 07, 2007 2:57 AM > >>>>> To: Brian Rosen > >>>>> Cc: 'Paul Kyzivat'; 'Hisham Khartabil'; 'Niemi Aki'; 'Jonathan > >>> Rosenberg'; > >>>>> 'SIMPLE mailing list' > >>>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > >>>>> > >>>>> Some inline comments > >>>>> > >>>>> Brian Rosen wrote: > >>>>>> Having agreed to proceed with the nickname stuff in MSRP chat, BUT > >>>>> having > >>>>>> the benefit of the discussion on generalizing nicknames in the > >>>>>> Chicago > >>>>>> meeting, I'd suggest we simplify as much as possible the MSRP > >>> mechanism. > >>>>>> Specifically, I suggest the following: > >>>>>> > >>>>>> 1. We don't need a display name on a nick name. Just delete it. > >>>>> Agreed. No changes with respect the current version of the draft, > >>>>> which > >>>>> already includes the following text: > >>>>> > >>>>> The 'name-addr' ABNF in RFC 3261 allows an optional 'display- > name' > >>> to > >>>>> prepend the actual URI. For the purpose of conveying nicknames, > >>>>> display-names MUST NOT be used, because the username part of a > >>>>> nickname URI provides its rendering property. If the display- > name > >>> is > >>>>> included in an Use-Nickname header field, it SHOULD be ignored. > >>>>> Implementations are RECOMMENDED to use only the user part of the > >>>>> nickname URI for rendering purposes. > >>>>> > >>>>> > >>>>>> 2. We agree that there is a nickname, scoped within a domain, and > you > >>>>> need > >>>>>> to be able to form a URI from it. The domain in MSRP chat is > always > >>> the > >>>>>> chat itself. There is the complication that the domain of the chat > >>> may > >>>>> have > >>>>>> content prior to the "@". This problem exists in XCON also. This > >>> means > >>>>>> there needs to be a construction rule to form URI from the nick and > >>> the > >>>>>> domain, handling this problem. OTOH, there really isn't a reason > why > >>>>> the > >>>>>> domain needs to be mentioned in the Set-Nickname. You can't use a > >>>>> NICKNAME > >>>>>> method outside the domain of a chat, so we know a-priori what the > >>>>>> chat > >>>>>> domain is. > >>>>> I am trying to understand the benefit of it. > >>>>> > >>>>> On one hand, the MSRP endpoint needs to understand the construction > >>>>> for > >>>>> nickname URIs defined by the document. This is because it is going > to > >>>>> receive participant's nicknames via the conference event package, > and > >>> it > >>>>> needs to be able to extract the nickname out of the URI for > rendering > >>>>> purposes. > >>>>> > >>>>> On the other hand, in the future, there might be participants who > have > >>>>> non-chat-server-scoped nicknames. So, the endpoint needs to know the > >>>>> structure of the URI. > >>>>> > >>>>> If the endpoint needs to know the structure of the URI I would > prefer > >>> to > >>>>> be explicit and send in the Set-Nickname the full nickname URI that > >>>>> the > >>>>> user wishes to set. Somehow, I feel more comfortable being explicit. > >>>>> > >>>>>> 4. Jonathan proposed a construction rule. I don't understand why > we > >>>>> need a > >>>>>> prefix. > >>>>> I think the prefix serves for two purposes. On one side, it is > trying > >>> to > >>>>> avoid clashes between regular SIP URIs and nickname URIs in the chat > >>>>> room server/mixer. > >>>>> > >>>>> But more important, I think the prefix also indicates the structure > or > >>>>> scheme used in the nickname URI. Assume in the future we come up > with > >>>>> another way to represent nicknames in a URI (perhaps the general > >>>>> nicknames), then we should have a mechanism to clearly identify > which > >>>>> structure is used. I think the "msrp-nickname" prefix gives us such > >>>>> property. > >>>>> > >>>>> > We could easily put a rule that said, for example, in an MSRP > From: > >>>>> > or To:, a slash must be escaped unless it separates nick from > chat > >>>>> > domain user-part. > >>>>> > >>>>> In CPIM From and To. But yes, I agree, slashes must be escaped > unless > >>>>> used for the purpose of separating nicknames from the chat room > name. > >>>>> > >>>>> > You already imply a rule that says you can't have > >>>>> > "msrp-nickname" with slashes as a URI in From:/To:. > >>>>> > >>>>> You could. Nothing prevents to you to add the string > >>>>> "msrp-nickname" as > >>>>> part of your nickname. That would lead to: > >>>>> > >>>>> sip:msrp-nickname/msrp-nickname/chat33@conf.example.com > >>>>> > >>>>> The prefix tells you how to decode the username part; the second > >>>>> "msrp-nickname" is your actual nickname. If you want to add slashes, > >>> you > >>>>> escape them. > >>>>> > >>>>> > >>>>>> So: I propose that Set-Nickname simply have the nickname as the > >>>>> parameter: > >>>>>> Set-Nickname: joebob > >>>>> As I said, I prefer to be explicit. I don't think we gain anything, > >>>>> and > >>>>> we loose a lot. > >>>>> > >>>>>> I propose a construction rule from nickname+chat-domain to a URI > >>> useable > >>>>> in > >>>>>> MSRP From:/To: be to separate the nick from the domain with a slash > >>> IFF > >>>>> the > >>>>>> domain has a userpart. So, for example: > >>>>>> sip:joebob/chat34@msrp.example.com > >>>>>> > >>>>>> Include the rule that a normal URI in From:/To: that has a slash > >>>>>> needs > >>>>> the > >>>>>> slash to be escaped. > >>>>>> > >>>>>> One other thought: the URI construction rule bothers me. I don't > >>>>>> like > >>>>>> forcing new syntax on the user-part, and restricting what the URI > can > >>>>> look > >>>>>> like. Consider making the nick a parameter to the domain URI in > >>>>> From:/To: > >>>>>> like: > >>>>>> sip:chat34@msrp.example.com;nickname=joebob > >>>>>> You could allow this syntax always (at least as an alternative) > >>>>>> sip:chat34.example.com;nickname=joebob > >>>>> I also proposed the nickname parameter earlier, but there is > something > >>> I > >>>>> don't like from it: parameters should be modifiers of the resource > >>>>> that > >>>>> add new characteristics to the resource. Here the resource is the > >>>>> chatroom URI (as opposed to the user URI), so if we take it > literally, > >>>>> the nickname parameter represents the chat room nickname, not the > >>> user's > >>>>> nickname. > >>>>> > >>>>> The idea of the nickname URI would be OK in the generic nicknames > that > >>>>> you are working on, so I could write my SIP URI including a > nickname, > >>>>> for example: sip:miguel@example.com;nickname=wine-expert > >>>>> > >>>>> /Miguel > >>>>> > >>>>>> Brian > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > >>>>>>> Sent: Monday, August 06, 2007 1:32 AM > >>>>>>> To: Paul Kyzivat; Brian Rosen; 'Hisham Khartabil'; Niemi Aki; > >>> Jonathan > >>>>>>> Rosenberg > >>>>>>> Cc: 'SIMPLE mailing list' > >>>>>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > >>>>>>> > >>>>>>> Let me try to seek consensus on the issue of the Nickname URI. > >>>>>>> > >>>>>>> We have been hearing that we need to allow URIs to be issued by > any > >>>>>>> entity as well as the chat server. We agreed that the MSRP chat > >>>>>>> draft > >>>>>>> will tackle only the latter. > >>>>>>> > >>>>>>> We haven't really agreed whether we envision MSRP chat operations > >>>>>>> (namely the NICKNAME method) with domain URIs in the future. The > >>>>> current > >>>>>>> version of the draft leaves open space for it, but this has > created > >>>>> some > >>>>>>> misunderstanding. Since there is current work on generalized > >>> nicknames > >>>>> I > >>>>>>> would suggest that we take the assumption that the MSRP NICKNAME > >>> method > >>>>>>> only deals with chat room server scoped nicknames. Domain > nicknames > >>> are > >>>>>>> not considered with the NICKNAME method. > >>>>>>> > >>>>>>> We are having discussions on the representation of a nickname URI. > >>> Some > >>>>>>> of these problems come from the fact that we don't really know > >>>>>>> how to > >>>>>>> represent domain nicknames and we don't know the relation of them > to > >>>>> the > >>>>>>> chat room server. I've been thinking that we should decouple the > >>>>>>> nickname itself from its representation in a URI. So, my > suggestion > >>> is > >>>>>>> that the MSRP chat draft goes ahead with its representation of > >>>>> nicknames > >>>>>>> in a URI, for the purpose of reservation/validation (NICKNAME > >>> method), > >>>>>>> having into account that those nicknames are scoped to the focus > of > >>> the > >>>>>>> conference. Other representation of nicknames (domain-scoped > >>> nicknames) > >>>>>>> may appear in From and To headers in CPIM, but not in NICKNAME > >>> method. > >>>>>>> Representation of chat room scoped nicknames. We need a mechanism > to > >>>>>>> identify that a nickname URI is effectively a nickname URI, and be > >>> able > >>>>>>> to extract the nickname (for rendering in the UI) from the rest of > >>> teh > >>>>>>> URI. Jonathan proposed: > >>>>>>> > >>>>>>> sip:"msrp-nicknames" "/" "/" @ > domain > >>>>>>> > >>>>>>> which is correct in my opinion. While there have been other > >>>>> suggestions, > >>>>>>> I haven't heard anyone indicating that Jonathan's proposal > >>>>>>> wouldn't > >>>>>>> work. So, I suggest we go for it. > >>>>>>> > >>>>>>> /Miguel > >>>>>>> -- > >>>>>>> Miguel A. Garcia tel:+358-50-4804586 > >>>>>>> Nokia Siemens Networks Espoo, Finland > >>>>> -- > >>>>> 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 > >>> -- > >>> Miguel A. Garcia tel:+358-50-4804586 > >>> Nokia Siemens Networks Espoo, Finland > >> > > -- > 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 From simple-bounces@ietf.org Tue Aug 07 16:33: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 1IIVju-0008IO-3A; Tue, 07 Aug 2007 16:33:14 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIVjs-0008IG-2C for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 16:33:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIVjr-0008I7-NZ for simple@ietf.org; Tue, 07 Aug 2007 16:33:11 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIVjr-0007vl-Di for simple@ietf.org; Tue, 07 Aug 2007 16:33:11 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IIVjZ-0006f9-UY; Tue, 07 Aug 2007 15:32:55 -0500 From: "Brian Rosen" To: "'Miguel Garcia'" References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BD52.3090807@nsn.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Tue, 7 Aug 2007 16:33:02 -0400 Message-ID: <087d01c7d932$28e384e0$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: AcfZItdxoEmFTiPURdOirxCTrE+cEgADtI2g In-reply-to: <46B8BD52.3090807@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: de4f315c9369b71d7dd5909b42224370 Cc: 'Paul Kyzivat' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org > This bring another issue. If a chat room does not allow clashes in the > nicknames, then he should prevent them also between different domains > (joebob@example.com and joebob@example.net). And it would be very easy > to prevent that a user with a legitimate nickname, issued by his > nickname server, would never be able to use it in a chat room. We just > need a rouge guy who sets the chat-room scoped nickname joebob, > preventing the other two to use their regular permanent URIs. This problem occurs in msrp-chat nicknames. The rogue fellow asks for jeobob, and you can't get it. You can't avoid it. The generalized mechanism, with clients and servers that can deal with collisions might be able to handle it, but the msrp-chat nickname mechanism can't. The domain is always the chat domain, and thus you can only have one user with a given nickname. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 07 17:23:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIWWp-0001GB-2D; Tue, 07 Aug 2007 17:23:47 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIWWn-0001G4-NY for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 17:23:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIWWn-0001Fw-8b for simple@ietf.org; Tue, 07 Aug 2007 17:23:45 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIWWl-0000rm-6J for simple@ietf.org; Tue, 07 Aug 2007 17:23:45 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 07 Aug 2007 17:20:23 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACp+uEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.19,231,1183348800"; d="scan'208"; a="128212778:sNHT2840007532" 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 l77LKLGe023440; Tue, 7 Aug 2007 17:20:21 -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 l77LKDjK020326; Tue, 7 Aug 2007 21:20:21 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 17:20:16 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 17:20:16 -0400 Message-ID: <46B8E20F.60804@cisco.com> Date: Tue, 07 Aug 2007 17:20:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> In-Reply-To: <087901c7d931$917494f0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Aug 2007 21:20:16.0071 (UTC) FILETIME=[BFAFBD70:01C7D938] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=21507; t=1186521621; x=1187385621; 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]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20 |To:=20Brian=20Rosen=20; bh=2gdH7MOGkMhH+8w68jdkKpkdreQYAGPF5jby32YM0o8=; b=Xp1tteqf9bA6el1NeW3GMNDv38YtWxK/BGbW0WV+OF/pjBNVUGTo1InUpT4tpmbrmlEs3IAW AsunXObG+x/8iyQiZ7YR/rBfDMjEjSQpJWOQGCfMIP5/Q8V8ac9reVvA; 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: 4863a9796402a44fdb52482f353618fe Cc: 'Miguel Garcia' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Brian Rosen wrote: > I think this leads to users not understanding why their nicknames work > sometimes and not others: > > Example 1: > My nickname is joebob. Your nickname is joebob. Neither of us is > registered. Neither of us "has" the nickname joebob. We both *want* the nickname joebob in the scope of this conference. > We both ask the chat server to give us joebob. I get there > first, and you get an error. We both wanted it, and one of us won. What do you *want* to happen? The conf server could hand out two nicknames that are both joebob in different domains that the server controls, if it wants to do that. It depends on what its policy is for duplicates. > Example 2: > My nickname is joebob. Your nickname is joebob. I am registered at some > other domain. We both ask the chat server to give us joebob. I get there > first, but this time it works for you. In that case you *do* *have* the nickname joebob in some domain. Its more than a wish. So this isn't surprising. Are you assuming that anyone can ask for any nickname from any server, and always get it, even if someone else also has the same nickname from the same server? If so, the protocol and the UI can't distinguish them and I can't selectively send to one or the other. I find that entirely unacceptable. > You would have to know that I registered my nick somewhere else, so my URI > is unique, to know why you got an error in the first example, but didn't in > the second. Normally, the URI isn't visible to the users, only the names > are. This would be no different than me being the 2nd user rather than the first to show up. You think this is unacceptable, but I find it way more acceptable than not being able to discriminate between two distinct joebobs. As I said above, if you want more-or-less this behavior then we must allow the MSRP server to accept multiple requests for nickname joebob and give them *different* URIs in return. > If you allow a nickname collision, you incur costs at both the server and > the clients. You can't avoid them. Collision really is the name; the > domain MAY help you, but since it can't fix the whole problem, it isn't > useful. > > Note that we are discussing the generalized nickname mechanisms, not the > msrp-chat. We're projecting a problem onto that mechanism and trying to > solve it here. In msrp-chat, you can't have a collision. No. I think this is lapping over to the msrp-chat nickname issue to because of needing to sort out what happens when two people request the same nickname. Paul > Brian > >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >> Sent: Tuesday, August 07, 2007 2:45 PM >> To: Paul Kyzivat >> Cc: Brian Rosen; 'SIMPLE mailing list'; 'Niemi Aki' >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >> >> I agree with Paul. >> >> /Miguel >> >> Paul Kyzivat wrote: >>> Joebob - comments inline. >>> >>> Paul >>> >>> Brian Rosen wrote: >>> >>>> As we discussed, the generalized mechanism need local policy to decide >> if >>>> the server allows such a conflict (same nick). I think the notion that >>>> because they have different domains they are different is wrong. You >> can >>>> keep them separate for addressing purposes, but you force the UI to >> deal >>>> with them as the same. I think if nickname part is the same there is a >>>> collision, and either it's allowed or not, and the domain is not part >> of >>>> that. If it's allowed, the client and the server have to deal with the >>>> issue. >>> I don't like this approach. IMO at the *protocol* level nicknames must >>> be unique - except possibly that if one user has two sessions he may use >>> the same nickname for both. (That needs further consideration.) >>> >>> The point of having domains is to deal with that, and allow two joebobs >>> only when they are in different domains. >>> >>> It is then an issue for the UI to deal with the collisions as it sees >>> fit. Some things it might do: >>> - distinguish by colors - e.g. (red)joebob, (blue)joebob >>> - distinguish with suffixes - e.g. joebob, joebob(2), ... >>> - display first without domain, others with domain: >>> joebob, joebob@biloxi.com >>> - display all with domains: joebob@atlanta.com, joebob@biloxi.com >>> >>> It needn't be our problem to figure out this part. >>> >>> But when I reply to a particular joebob thru my UI, the protocol must >>> identify the particular joebob I meant. >>> >>>> This is not an issue for msrp chat: the text does not allow two users >> to >>>> have the same nickname. When we get to the generalized mechanism, we >>>> have >>>> to make it work for same name, different domain and same name, same >>>> domain. >>> I think we could eventually get into a situation where we have a server >>> that supports the msrp nicknames and the more general ones as well. Some >>> clients may use msrp to get their nicknames, and others the other >>> method. They need to interoperate. >>> >>> I see the nickname method in msrp to be just a limited way to *assign* a >>> nickname, but it doesn't limit to *use* of nicknames assigned that way. >>> >>> Paul >>> >>>> Brian >>>> >>>>> -----Original Message----- >>>>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >>>>> Sent: Tuesday, August 07, 2007 11:16 AM >>>>> To: Brian Rosen >>>>> Cc: 'Paul Kyzivat'; 'SIMPLE mailing list'; 'Niemi Aki' >>>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>>> >>>>> Inline >>>>> >>>>> Brian Rosen wrote: >>>>>> I think you are too hung up on the fact you can create a URI out of a >>>>>> nickname. There is no more comfort in explicitly providing the URI >> and >>>>>> forcing the UA (and the server) to decode it to extract the nickname, >>>>> then >>>>>> in sending the nickname and forcing construction of the URI. I >> think: >>>>>> Set-Nickname joebob >>>>>> is much preferable to >>>>>> Set-Nickname sip:msrp-nickname/joebob/chat34@msrp.example.com >>>>> I would agree on the implicit version providing that the response >>>>> contains the full URI. >>>>> >>>>> Still I don't really understand what are we achieving.... >>>>> >>>>>> I didn't remember the detail about how you extend the conference >>>>> package. >>>>>> It's much simpler to just have the nickname be the string, and not >> the >>>>> URI. >>>>>> It's an extension; there is no reason to require the URI, and we can >>>>> make it >>>>>> anything appropriate. Keep it simple. >>>>> The conference event package is extended with a new element >> surprisingly >>>>> called . It currently contains the URI. >>>>> >>>>> I think the conference event package needs to send the full URI. >>>>> Otherwise, there might be conflicts if one person with say a local >>>>> nickname shares the nickname with a general domain nickname. When a >> user >>>>> sends a private message to one of these nicknames, if the nickname is >>>>> not a URI the server is not going to know how to route the message. >>>>> >>>>>> I'm trying to keep this mechanism as close to the generalized >> mechanism >>>>> as >>>>>> possible. I want to go the other way from you: if you declare a >>>>> nickname >>>>>> with the generalized mechanism, I want the conference package >> extension >>>>> to >>>>>> not change, >>>>> Agreed. The current extension holds a URI, so if you can represent a >>>>> general nickname as a URI, then it is not a probelm. >>>>> >>>>>> I want you to be able to (generally) mix and match use of the >>>>>> generalized Set with the MSRP Set and I want the form of the >>>>> construction to >>>>>> be the same. >>>>> Generally agreed. I was assuming that the general Set nickname will >>>>> require a domain, so it does the chat-room scoped nickname. But you >> seem >>>>> to be suggesting the opposite, so I am confused. >>>>> >>>>> The other thing: I believe we came to an agreement that on the >>>>> procedures, we will use Set-Nickname in NICKNAME to set the chat-room >>>>> scoped URI only. Setting a general nickname will be done by some other >>>>> general procedure. Just wanted to confirm that we are on the same >> page. >>>>>> If we get away with that, we won't usually need to distinguish >>>>>> how we set the nickname in the URI. Even if we keep the text pretty >>>>> much as >>>>>> is, I'd prefer to change the prefix to just "nickname". >>>>> Ok, we can change the prefix name to "nickname". >>>>> >>>>>> To be honest, we actually DO need to have an explicit domain in the >>>>>> generalized SET, because it may not be the domain of the >>>>>> chat/conference/whatever. >>>>> Exactly >>>>> >>>>>> I want that in the generalized mechanism and not >>>>>> in the msrp mechanism. I don't want a client with the generalized >>>>> mechanism >>>>>> to be able to send a non local domain in the msrp Set. >>>>> Ok, I can agree with it. As long as the response contains the full >> URI, >>>>> as I said before. >>>>> >>>>>> I'm worried that the >>>>>> client may not know that the chat server does not support the >>>>> generalized >>>>>> mechanism before he tries that, or using the Supported header for the >>>>>> generalized mechanism to imply what can or cannot be sent in the msrp >>>>> Set. >>>>>> I'd make the domain in the generalized Set a separate parameter in >> the >>>>> (sip) >>>>>> header, not the constructed URI: >>>>>> Set-Nickname joebob nickserver.example.com >>>>> ok, not a big difference with a uri: sip:joebob@nickserver.example.com >>>>> >>>>>> I think you are mistaken about what the constructor rule does to user >>>>> part >>>>>> syntax. If I choose a username of msrp-nickname/joebob, you can make >> a >>>>>> valid nickname uri from it, but if I send a regular message, it looks >>>>> like >>>>>> it's from a nickname. You would have to get a full set of nicknames >>>>> from >>>>>> the server and figure this out to know what my actual URI was and >>>>>> distinguish it from my nickname. I worry that there will be >>>>> implementations >>>>>> that will able to be failed by fooling them in this way. I think the >>>>> text >>>>>> should say that usernames can't start with the prefix we choose, and >>>>>> the >>>>>> server should enforce the rule. >>>>> The problem of knowing what is my real nickanme URI is solved if the >>>>> nickname URI returned in the response to the NICKNAME method. >>>>> >>>>> I don't have a problem to say that nicknames can't start by the >> prefix. >>>>> Paul wanted that feature, but I don't have a problem in either way. >>>>> >>>>> Miguel >>>>> >>>>>> When you use a nickname the message is always sent to the switch. >> You >>>>>> cannot address any form of message directly to the constructed URI. >>>>> This is >>>>>> why the parameter works. You ARE sending it to the switch, it is >>>>>> translating the URI you send into an actually addressable entity. >>>>>> >>>>>> Brian >>>>>>> -----Original Message----- >>>>>>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >>>>>>> Sent: Tuesday, August 07, 2007 2:57 AM >>>>>>> To: Brian Rosen >>>>>>> Cc: 'Paul Kyzivat'; 'Hisham Khartabil'; 'Niemi Aki'; 'Jonathan >>>>> Rosenberg'; >>>>>>> 'SIMPLE mailing list' >>>>>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>>>>> >>>>>>> Some inline comments >>>>>>> >>>>>>> Brian Rosen wrote: >>>>>>>> Having agreed to proceed with the nickname stuff in MSRP chat, BUT >>>>>>> having >>>>>>>> the benefit of the discussion on generalizing nicknames in the >>>>>>>> Chicago >>>>>>>> meeting, I'd suggest we simplify as much as possible the MSRP >>>>> mechanism. >>>>>>>> Specifically, I suggest the following: >>>>>>>> >>>>>>>> 1. We don't need a display name on a nick name. Just delete it. >>>>>>> Agreed. No changes with respect the current version of the draft, >>>>>>> which >>>>>>> already includes the following text: >>>>>>> >>>>>>> The 'name-addr' ABNF in RFC 3261 allows an optional 'display- >> name' >>>>> to >>>>>>> prepend the actual URI. For the purpose of conveying nicknames, >>>>>>> display-names MUST NOT be used, because the username part of a >>>>>>> nickname URI provides its rendering property. If the display- >> name >>>>> is >>>>>>> included in an Use-Nickname header field, it SHOULD be ignored. >>>>>>> Implementations are RECOMMENDED to use only the user part of the >>>>>>> nickname URI for rendering purposes. >>>>>>> >>>>>>> >>>>>>>> 2. We agree that there is a nickname, scoped within a domain, and >> you >>>>>>> need >>>>>>>> to be able to form a URI from it. The domain in MSRP chat is >> always >>>>> the >>>>>>>> chat itself. There is the complication that the domain of the chat >>>>> may >>>>>>> have >>>>>>>> content prior to the "@". This problem exists in XCON also. This >>>>> means >>>>>>>> there needs to be a construction rule to form URI from the nick and >>>>> the >>>>>>>> domain, handling this problem. OTOH, there really isn't a reason >> why >>>>>>> the >>>>>>>> domain needs to be mentioned in the Set-Nickname. You can't use a >>>>>>> NICKNAME >>>>>>>> method outside the domain of a chat, so we know a-priori what the >>>>>>>> chat >>>>>>>> domain is. >>>>>>> I am trying to understand the benefit of it. >>>>>>> >>>>>>> On one hand, the MSRP endpoint needs to understand the construction >>>>>>> for >>>>>>> nickname URIs defined by the document. This is because it is going >> to >>>>>>> receive participant's nicknames via the conference event package, >> and >>>>> it >>>>>>> needs to be able to extract the nickname out of the URI for >> rendering >>>>>>> purposes. >>>>>>> >>>>>>> On the other hand, in the future, there might be participants who >> have >>>>>>> non-chat-server-scoped nicknames. So, the endpoint needs to know the >>>>>>> structure of the URI. >>>>>>> >>>>>>> If the endpoint needs to know the structure of the URI I would >> prefer >>>>> to >>>>>>> be explicit and send in the Set-Nickname the full nickname URI that >>>>>>> the >>>>>>> user wishes to set. Somehow, I feel more comfortable being explicit. >>>>>>> >>>>>>>> 4. Jonathan proposed a construction rule. I don't understand why >> we >>>>>>> need a >>>>>>>> prefix. >>>>>>> I think the prefix serves for two purposes. On one side, it is >> trying >>>>> to >>>>>>> avoid clashes between regular SIP URIs and nickname URIs in the chat >>>>>>> room server/mixer. >>>>>>> >>>>>>> But more important, I think the prefix also indicates the structure >> or >>>>>>> scheme used in the nickname URI. Assume in the future we come up >> with >>>>>>> another way to represent nicknames in a URI (perhaps the general >>>>>>> nicknames), then we should have a mechanism to clearly identify >> which >>>>>>> structure is used. I think the "msrp-nickname" prefix gives us such >>>>>>> property. >>>>>>> >>>>>>> > We could easily put a rule that said, for example, in an MSRP >> From: >>>>>>> > or To:, a slash must be escaped unless it separates nick from >> chat >>>>>>> > domain user-part. >>>>>>> >>>>>>> In CPIM From and To. But yes, I agree, slashes must be escaped >> unless >>>>>>> used for the purpose of separating nicknames from the chat room >> name. >>>>>>> > You already imply a rule that says you can't have >>>>>>> > "msrp-nickname" with slashes as a URI in From:/To:. >>>>>>> >>>>>>> You could. Nothing prevents to you to add the string >>>>>>> "msrp-nickname" as >>>>>>> part of your nickname. That would lead to: >>>>>>> >>>>>>> sip:msrp-nickname/msrp-nickname/chat33@conf.example.com >>>>>>> >>>>>>> The prefix tells you how to decode the username part; the second >>>>>>> "msrp-nickname" is your actual nickname. If you want to add slashes, >>>>> you >>>>>>> escape them. >>>>>>> >>>>>>> >>>>>>>> So: I propose that Set-Nickname simply have the nickname as the >>>>>>> parameter: >>>>>>>> Set-Nickname: joebob >>>>>>> As I said, I prefer to be explicit. I don't think we gain anything, >>>>>>> and >>>>>>> we loose a lot. >>>>>>> >>>>>>>> I propose a construction rule from nickname+chat-domain to a URI >>>>> useable >>>>>>> in >>>>>>>> MSRP From:/To: be to separate the nick from the domain with a slash >>>>> IFF >>>>>>> the >>>>>>>> domain has a userpart. So, for example: >>>>>>>> sip:joebob/chat34@msrp.example.com >>>>>>>> >>>>>>>> Include the rule that a normal URI in From:/To: that has a slash >>>>>>>> needs >>>>>>> the >>>>>>>> slash to be escaped. >>>>>>>> >>>>>>>> One other thought: the URI construction rule bothers me. I don't >>>>>>>> like >>>>>>>> forcing new syntax on the user-part, and restricting what the URI >> can >>>>>>> look >>>>>>>> like. Consider making the nick a parameter to the domain URI in >>>>>>> From:/To: >>>>>>>> like: >>>>>>>> sip:chat34@msrp.example.com;nickname=joebob >>>>>>>> You could allow this syntax always (at least as an alternative) >>>>>>>> sip:chat34.example.com;nickname=joebob >>>>>>> I also proposed the nickname parameter earlier, but there is >> something >>>>> I >>>>>>> don't like from it: parameters should be modifiers of the resource >>>>>>> that >>>>>>> add new characteristics to the resource. Here the resource is the >>>>>>> chatroom URI (as opposed to the user URI), so if we take it >> literally, >>>>>>> the nickname parameter represents the chat room nickname, not the >>>>> user's >>>>>>> nickname. >>>>>>> >>>>>>> The idea of the nickname URI would be OK in the generic nicknames >> that >>>>>>> you are working on, so I could write my SIP URI including a >> nickname, >>>>>>> for example: sip:miguel@example.com;nickname=wine-expert >>>>>>> >>>>>>> /Miguel >>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >>>>>>>>> Sent: Monday, August 06, 2007 1:32 AM >>>>>>>>> To: Paul Kyzivat; Brian Rosen; 'Hisham Khartabil'; Niemi Aki; >>>>> Jonathan >>>>>>>>> Rosenberg >>>>>>>>> Cc: 'SIMPLE mailing list' >>>>>>>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>>>>>>> >>>>>>>>> Let me try to seek consensus on the issue of the Nickname URI. >>>>>>>>> >>>>>>>>> We have been hearing that we need to allow URIs to be issued by >> any >>>>>>>>> entity as well as the chat server. We agreed that the MSRP chat >>>>>>>>> draft >>>>>>>>> will tackle only the latter. >>>>>>>>> >>>>>>>>> We haven't really agreed whether we envision MSRP chat operations >>>>>>>>> (namely the NICKNAME method) with domain URIs in the future. The >>>>>>> current >>>>>>>>> version of the draft leaves open space for it, but this has >> created >>>>>>> some >>>>>>>>> misunderstanding. Since there is current work on generalized >>>>> nicknames >>>>>>> I >>>>>>>>> would suggest that we take the assumption that the MSRP NICKNAME >>>>> method >>>>>>>>> only deals with chat room server scoped nicknames. Domain >> nicknames >>>>> are >>>>>>>>> not considered with the NICKNAME method. >>>>>>>>> >>>>>>>>> We are having discussions on the representation of a nickname URI. >>>>> Some >>>>>>>>> of these problems come from the fact that we don't really know >>>>>>>>> how to >>>>>>>>> represent domain nicknames and we don't know the relation of them >> to >>>>>>> the >>>>>>>>> chat room server. I've been thinking that we should decouple the >>>>>>>>> nickname itself from its representation in a URI. So, my >> suggestion >>>>> is >>>>>>>>> that the MSRP chat draft goes ahead with its representation of >>>>>>> nicknames >>>>>>>>> in a URI, for the purpose of reservation/validation (NICKNAME >>>>> method), >>>>>>>>> having into account that those nicknames are scoped to the focus >> of >>>>> the >>>>>>>>> conference. Other representation of nicknames (domain-scoped >>>>> nicknames) >>>>>>>>> may appear in From and To headers in CPIM, but not in NICKNAME >>>>> method. >>>>>>>>> Representation of chat room scoped nicknames. We need a mechanism >> to >>>>>>>>> identify that a nickname URI is effectively a nickname URI, and be >>>>> able >>>>>>>>> to extract the nickname (for rendering in the UI) from the rest of >>>>> teh >>>>>>>>> URI. Jonathan proposed: >>>>>>>>> >>>>>>>>> sip:"msrp-nicknames" "/" "/" @ >> domain >>>>>>>>> which is correct in my opinion. While there have been other >>>>>>> suggestions, >>>>>>>>> I haven't heard anyone indicating that Jonathan's proposal >>>>>>>>> wouldn't >>>>>>>>> work. So, I suggest we go for it. >>>>>>>>> >>>>>>>>> /Miguel >>>>>>>>> -- >>>>>>>>> Miguel A. Garcia tel:+358-50-4804586 >>>>>>>>> Nokia Siemens Networks Espoo, Finland >>>>>>> -- >>>>>>> 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 >>>>> -- >>>>> Miguel A. Garcia tel:+358-50-4804586 >>>>> Nokia Siemens Networks Espoo, Finland >> -- >> 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 From simple-bounces@ietf.org Tue Aug 07 18:11: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 1IIXHF-0000Xw-Ok; Tue, 07 Aug 2007 18:11:45 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIXHE-0000Wt-1O for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 18:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIXHD-0000US-N3 for simple@ietf.org; Tue, 07 Aug 2007 18:11:43 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIXHD-0004ff-2K for simple@ietf.org; Tue, 07 Aug 2007 18:11:43 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IIXGt-0003H5-HB; Tue, 07 Aug 2007 17:11:24 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Tue, 7 Aug 2007 18:11:32 -0400 Message-ID: <089e01c7d93f$ec515a30$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: AcfZOTUQlqUmhrlGSMSlZsLwbYR+HAABKy3g In-reply-to: <46B8E20F.60804@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: 37af5f8fbf6f013c5b771388e24b09e7 Cc: 'Miguel Garcia' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Inline > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, August 07, 2007 5:20 PM > To: Brian Rosen > Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > > > Brian Rosen wrote: > > I think this leads to users not understanding why their nicknames work > > sometimes and not others: > > > > Example 1: > > My nickname is joebob. Your nickname is joebob. Neither of us is > > registered. > > Neither of us "has" the nickname joebob. We both *want* the nickname > joebob in the scope of this conference. > > > We both ask the chat server to give us joebob. I get there > > first, and you get an error. > > We both wanted it, and one of us won. What do you *want* to happen? I want an error, especially in msrp-chat declared nicknames > > The conf server could hand out two nicknames that are both joebob in > different domains that the server controls, if it wants to do that. It > depends on what its policy is for duplicates. Not in msrp-chat nicknames. Yes, if that is its policy in the generalized mechanism. The generalized mechanism needs a way to have unambiguous URIs if it has a policy of allowing collisions on nicknames. > > > Example 2: > > My nickname is joebob. Your nickname is joebob. I am registered at > some > > other domain. We both ask the chat server to give us joebob. I get > there > > first, but this time it works for you. > > In that case you *do* *have* the nickname joebob in some domain. Its > more than a wish. So this isn't surprising. It is surprising to the user, who doesn't understand the difference > > Are you assuming that anyone can ask for any nickname from any server, > and always get it, even if someone else also has the same nickname from > the same server? If so, the protocol and the UI can't distinguish them > and I can't selectively send to one or the other. I find that entirely > unacceptable. I am not assuming that. I am assuming that if the policy for nicknames is that collisions are allowed, that a collision exists whether the domain of the nickname is the same or different as long as the nickname itself is the same. If the policy is that collisions are not allowed then two users requesting the same nickname that happen to have different domains would be rejected with an error. Of course, it would also reject, with the same error, if the domains were the same, specifically if they were requested from the using domain (the chat server). This would always be the case in an msrp-chat nickname declaration because I want this mechanism to always disallow collisions. > > > You would have to know that I registered my nick somewhere else, so my > URI > > is unique, to know why you got an error in the first example, but didn't > in > > the second. Normally, the URI isn't visible to the users, only the > names > > are. > > This would be no different than me being the 2nd user rather than the > first to show up. > > You think this is unacceptable, but I find it way more acceptable than > not being able to discriminate between two distinct joebobs. I think if collisions are allowed, collisions exist if the nicknames are the same, and the mechanism must provide a way to construct a unique URI. If the domains are different, then it's easy. If the domains are the same, more work is needed. > > As I said above, if you want more-or-less this behavior then we must > allow the MSRP server to accept multiple requests for nickname joebob > and give them *different* URIs in return. Yes, I agree with this, but only in the case of the generalized mechanism, where the policy of the chat server (which is could mint nicknames using the generalized mechanism) was to allow collisions. > > > If you allow a nickname collision, you incur costs at both the server > and > > the clients. You can't avoid them. Collision really is the name; the > > domain MAY help you, but since it can't fix the whole problem, it isn't > > useful. > > > > Note that we are discussing the generalized nickname mechanisms, not the > > msrp-chat. We're projecting a problem onto that mechanism and trying to > > solve it here. In msrp-chat, you can't have a collision. > > No. I think this is lapping over to the msrp-chat nickname issue to > because of needing to sort out what happens when two people request the > same nickname. In msrp-chat, I want it to not be allowed. If two users request the same nickname, I want an error on the second (and succeeding) requests. The problem we are discussing: same nickname, different domains, cannot exist. The only acceptable domain is the domain of the chat. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 07 20:03:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIYze-0008TY-Aq; Tue, 07 Aug 2007 20:01:42 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIYzd-0008TS-0s for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 20:01:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIYzc-0008TK-NZ for simple@ietf.org; Tue, 07 Aug 2007 20:01:40 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIYzb-0006pI-9I for simple@ietf.org; Tue, 07 Aug 2007 20:01:40 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 07 Aug 2007 17:01:39 -0700 X-IronPort-AV: i="4.19,232,1183359600"; d="scan'208"; a="511237006:sNHT64424642" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7801cdE014298; Tue, 7 Aug 2007 17:01:38 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l7801XiF013160; Wed, 8 Aug 2007 00:01:33 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 20:01:33 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 20:01:32 -0400 Message-ID: <46B907DB.8080301@cisco.com> Date: Tue, 07 Aug 2007 20:01:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> In-Reply-To: <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2007 00:01:32.0961 (UTC) FILETIME=[478FF910:01C7D94F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8112; t=1186531298; x=1187395298; c=relaxed/simple; s=sjdkim2002; 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]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20; bh=0gUlgzyQL0RNSiI2619ehSHHKRmciPGQW7XpECsSu+Y=; b=vfm4FN6sOaq6e3FEoCcXgJINX3NBcUj7RaVobG8WeuCJndOpbEKxQPox4GqW0VY3trJLhVnC S2vFAf/ijHXphsqeG7hOuPG1vdMCPQ/eGDCe3vrpcFHPin6W+52FKb8e; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: 'Miguel Garcia' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Brian Rosen wrote: > Inline > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, August 07, 2007 5:20 PM >> To: Brian Rosen >> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >> >> >> >> Brian Rosen wrote: >>> I think this leads to users not understanding why their nicknames work >>> sometimes and not others: >>> >>> Example 1: >>> My nickname is joebob. Your nickname is joebob. Neither of us is >>> registered. >> Neither of us "has" the nickname joebob. We both *want* the nickname >> joebob in the scope of this conference. >> >>> We both ask the chat server to give us joebob. I get there >>> first, and you get an error. >> We both wanted it, and one of us won. What do you *want* to happen? > I want an error, especially in msrp-chat declared nicknames OK. That helps. But then I think your desires are inconsistent, or else I don't understand what you are saying. I'm saying that the *clients* of this server must be prepared for the case where the server supports the more general mechanism, where some participants may have nicknames in some other domain, and ones with identical names but different domains. This is so even though it might not be possible for that to arise using only the MSRP mechanism. >> The conf server could hand out two nicknames that are both joebob in >> different domains that the server controls, if it wants to do that. It >> depends on what its policy is for duplicates. > Not in msrp-chat nicknames. Yes, if that is its policy in the generalized > mechanism. The generalized mechanism needs a way to have unambiguous URIs > if it has a policy of allowing collisions on nicknames. OK, if you want to make that rule for the msrp mechanism, then that is ok, so long as you then only allow one request for a given nickname to succeed at any given time. (Which I now see you do want.) >>> Example 2: >>> My nickname is joebob. Your nickname is joebob. I am registered at >> some >>> other domain. We both ask the chat server to give us joebob. I get >> there >>> first, but this time it works for you. >> In that case you *do* *have* the nickname joebob in some domain. Its >> more than a wish. So this isn't surprising. > It is surprising to the user, who doesn't understand the difference Users already must understand the difference between permanently signing up for a nickname vs not doing that and just trying to get one when they enter a chat. This is not unfamiliar. And if you want, you can make a rule that an msrp nickname request will always fail if there is already someone in the chat using an external nickname that "clashes". BUT, that isn't a complete solution unless you also prevent anyone using an external nickname from later joining the chat if their nickname clashes. While you *could* do that I think it would be a bad way forward. As long as the UIs are prepared for this from day 1 I think the users will cope. >> Are you assuming that anyone can ask for any nickname from any server, >> and always get it, even if someone else also has the same nickname from >> the same server? If so, the protocol and the UI can't distinguish them >> and I can't selectively send to one or the other. I find that entirely >> unacceptable. > I am not assuming that. I am assuming that if the policy for nicknames is > that collisions are allowed, that a collision exists whether the domain of > the nickname is the same or different as long as the nickname itself is the > same. > If the policy is that collisions are not allowed then two users requesting > the same nickname that happen to have different domains would be rejected > with an error. I think there is some confusion here. There is requesting to have a nickname *assigned* to you within some scope/domain, when it otherwise wasn't, and there is requesting to *use* a nickname in a particular session. The msrp method does both, binding the scope/domain of the assignment to the session you are establishing. There can be collision on assignment, and there can be collision on use. And there can be collision on the name+domain or on just the name. I believe the policy you are suggesting applies to collision on just names, for *use*, not assignment. I agree you can go either way on that, though it will ultimately be an annoying system if it forbids it. For assignment we always allow collision on names if the domains are different - that is the point, and there is no way to forbid it if the assignment is administered independently per domain. For assignment collision on name+domain is probably a bad idea, unless the entities doing the requesting are really the same in some sense. If they are then there probably aren't multiple assignments. So I think this is a non-issue. Collision on use at the name+domain level must be carefully controlled or users of the system will not be able to make any sense of it. I think the same name+domain can be used for multiple sessions with the focus *if* all the sessions belong to the same user, whatever that means. Its probably easy if they authenticate with the same credentials. Otherwise not. > Of course, it would also reject, with the same error, if the domains were > the same, I think you are saying what I said in last paragraph above. > specifically if they were requested from the using domain (the > chat server). This would always be the case in an msrp-chat nickname > declaration because I want this mechanism to always disallow collisions. I'm not sure if we are agreeing or not. >>> You would have to know that I registered my nick somewhere else, so my >> URI >>> is unique, to know why you got an error in the first example, but didn't >> in >>> the second. Normally, the URI isn't visible to the users, only the >> names >>> are. >> This would be no different than me being the 2nd user rather than the >> first to show up. >> >> You think this is unacceptable, but I find it way more acceptable than >> not being able to discriminate between two distinct joebobs. > I think if collisions are allowed, collisions exist if the nicknames are the > same, and the mechanism must provide a way to construct a unique URI. If > the domains are different, then it's easy. If the domains are the same, > more work is needed. If you want to use something other than domain for further discrimination (e.g. an URI parameter), for the msrp case, then I can probably live with that, pending the details. >> As I said above, if you want more-or-less this behavior then we must >> allow the MSRP server to accept multiple requests for nickname joebob >> and give them *different* URIs in return. > Yes, I agree with this, but only in the case of the generalized mechanism, > where the policy of the chat server (which is could mint nicknames using the > generalized mechanism) was to allow collisions. Again I don't know if we are agreeing or disagreeing. >>> If you allow a nickname collision, you incur costs at both the server >> and >>> the clients. You can't avoid them. Collision really is the name; the >>> domain MAY help you, but since it can't fix the whole problem, it isn't >>> useful. >>> >>> Note that we are discussing the generalized nickname mechanisms, not the >>> msrp-chat. We're projecting a problem onto that mechanism and trying to >>> solve it here. In msrp-chat, you can't have a collision. >> No. I think this is lapping over to the msrp-chat nickname issue to >> because of needing to sort out what happens when two people request the >> same nickname. > In msrp-chat, I want it to not be allowed. If two users request the same > nickname, I want an error on the second (and succeeding) requests. The > problem we are discussing: same nickname, different domains, cannot exist. > The only acceptable domain is the domain of the chat. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 07 20:30:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIZPe-0001py-IL; Tue, 07 Aug 2007 20:28:34 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIZPc-0001g8-Nm for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 20:28:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIZPc-0001g0-E5 for simple@ietf.org; Tue, 07 Aug 2007 20:28:32 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIZPb-0007Hi-1N for simple@ietf.org; Tue, 07 Aug 2007 20:28:32 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IIZPG-0008Q1-Fl; Tue, 07 Aug 2007 19:28:11 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Tue, 7 Aug 2007 20:28:21 -0400 Message-ID: <08c901c7d953$0880f310$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: AcfZT0QCsHqWpzZWQTuRCD2uY7NqDwAAefyw In-reply-to: <46B907DB.8080301@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: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: 'Miguel Garcia' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Let's break this down piece by piece, because we each don't yet understand what the other is saying. I propose that msrp-chat not allow nickname collisions. If two users do Set-Nickname with the same nickname, the second gets an error. Do you agree to that? Miguel? I think we all agree that the generalized mechanism will allow collisions. Let's see if we can agree on when these happen: 1. Two users with externally defined nicknames, where the domains are different 2. Two users request the same nickname from the local server In the hope that we all do agree, I'll press on one more (big) step. 3. I propose that the generalized mechanism allow an external domain to permit the same nickname for multiple users, and a chat server or other user of nicknames could allow that in a single chat/conference/whatever. I'm not sure that a domain who registers nicknames will have a policy that does permit it, but I don't see a fundamental reason why we would accept two users with the same nicknames in the local domain, but not two users with the same nicknames from an external domain. To make either work, somehow, a URI has to be minted that is unique. We don't have to specify how to do that yet, but a parameter on the URI is one way that would work. I'm going to pause to see if we agree or don't. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, August 07, 2007 8:02 PM > To: Brian Rosen > Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > > > Brian Rosen wrote: > > Inline > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Tuesday, August 07, 2007 5:20 PM > >> To: Brian Rosen > >> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > >> > >> > >> > >> Brian Rosen wrote: > >>> I think this leads to users not understanding why their nicknames work > >>> sometimes and not others: > >>> > >>> Example 1: > >>> My nickname is joebob. Your nickname is joebob. Neither of us is > >>> registered. > >> Neither of us "has" the nickname joebob. We both *want* the nickname > >> joebob in the scope of this conference. > >> > >>> We both ask the chat server to give us joebob. I get there > >>> first, and you get an error. > >> We both wanted it, and one of us won. What do you *want* to happen? > > I want an error, especially in msrp-chat declared nicknames > > OK. That helps. But then I think your desires are inconsistent, or else > I don't understand what you are saying. > > I'm saying that the *clients* of this server must be prepared for the > case where the server supports the more general mechanism, where some > participants may have nicknames in some other domain, and ones with > identical names but different domains. This is so even though it might > not be possible for that to arise using only the MSRP mechanism. > > >> The conf server could hand out two nicknames that are both joebob in > >> different domains that the server controls, if it wants to do that. It > >> depends on what its policy is for duplicates. > > Not in msrp-chat nicknames. Yes, if that is its policy in the > generalized > > mechanism. The generalized mechanism needs a way to have unambiguous > URIs > > if it has a policy of allowing collisions on nicknames. > > OK, if you want to make that rule for the msrp mechanism, then that is > ok, so long as you then only allow one request for a given nickname to > succeed at any given time. (Which I now see you do want.) > > >>> Example 2: > >>> My nickname is joebob. Your nickname is joebob. I am registered at > >> some > >>> other domain. We both ask the chat server to give us joebob. I get > >> there > >>> first, but this time it works for you. > >> In that case you *do* *have* the nickname joebob in some domain. Its > >> more than a wish. So this isn't surprising. > > It is surprising to the user, who doesn't understand the difference > > Users already must understand the difference between permanently signing > up for a nickname vs not doing that and just trying to get one when they > enter a chat. This is not unfamiliar. > > And if you want, you can make a rule that an msrp nickname request will > always fail if there is already someone in the chat using an external > nickname that "clashes". BUT, that isn't a complete solution unless you > also prevent anyone using an external nickname from later joining the > chat if their nickname clashes. While you *could* do that I think it > would be a bad way forward. > > As long as the UIs are prepared for this from day 1 I think the users > will cope. > > >> Are you assuming that anyone can ask for any nickname from any server, > >> and always get it, even if someone else also has the same nickname from > >> the same server? If so, the protocol and the UI can't distinguish them > >> and I can't selectively send to one or the other. I find that entirely > >> unacceptable. > > I am not assuming that. I am assuming that if the policy for nicknames > is > > that collisions are allowed, that a collision exists whether the domain > of > > the nickname is the same or different as long as the nickname itself is > the > > same. > > > If the policy is that collisions are not allowed then two users > requesting > > the same nickname that happen to have different domains would be > rejected > > with an error. > > I think there is some confusion here. There is requesting to have a > nickname *assigned* to you within some scope/domain, when it otherwise > wasn't, and there is requesting to *use* a nickname in a particular > session. The msrp method does both, binding the scope/domain of the > assignment to the session you are establishing. > > There can be collision on assignment, and there can be collision on use. > And there can be collision on the name+domain or on just the name. > > I believe the policy you are suggesting applies to collision on just > names, for *use*, not assignment. I agree you can go either way on that, > though it will ultimately be an annoying system if it forbids it. > > For assignment we always allow collision on names if the domains are > different - that is the point, and there is no way to forbid it if the > assignment is administered independently per domain. > > For assignment collision on name+domain is probably a bad idea, unless > the entities doing the requesting are really the same in some sense. If > they are then there probably aren't multiple assignments. So I think > this is a non-issue. > > Collision on use at the name+domain level must be carefully controlled > or users of the system will not be able to make any sense of it. I think > the same name+domain can be used for multiple sessions with the focus > *if* all the sessions belong to the same user, whatever that means. Its > probably easy if they authenticate with the same credentials. Otherwise > not. > > > Of course, it would also reject, with the same error, if the domains > were > > the same, > > I think you are saying what I said in last paragraph above. > > > specifically if they were requested from the using domain (the > > chat server). This would always be the case in an msrp-chat nickname > > declaration because I want this mechanism to always disallow collisions. > > I'm not sure if we are agreeing or not. > > >>> You would have to know that I registered my nick somewhere else, so my > >> URI > >>> is unique, to know why you got an error in the first example, but > didn't > >> in > >>> the second. Normally, the URI isn't visible to the users, only the > >> names > >>> are. > >> This would be no different than me being the 2nd user rather than the > >> first to show up. > >> > >> You think this is unacceptable, but I find it way more acceptable than > >> not being able to discriminate between two distinct joebobs. > > I think if collisions are allowed, collisions exist if the nicknames are > the > > same, and the mechanism must provide a way to construct a unique URI. > If > > the domains are different, then it's easy. If the domains are the same, > > more work is needed. > > If you want to use something other than domain for further > discrimination (e.g. an URI parameter), for the msrp case, then I can > probably live with that, pending the details. > > >> As I said above, if you want more-or-less this behavior then we must > >> allow the MSRP server to accept multiple requests for nickname joebob > >> and give them *different* URIs in return. > > Yes, I agree with this, but only in the case of the generalized > mechanism, > > where the policy of the chat server (which is could mint nicknames using > the > > generalized mechanism) was to allow collisions. > > Again I don't know if we are agreeing or disagreeing. > > >>> If you allow a nickname collision, you incur costs at both the server > >> and > >>> the clients. You can't avoid them. Collision really is the name; the > >>> domain MAY help you, but since it can't fix the whole problem, it > isn't > >>> useful. > >>> > >>> Note that we are discussing the generalized nickname mechanisms, not > the > >>> msrp-chat. We're projecting a problem onto that mechanism and trying > to > >>> solve it here. In msrp-chat, you can't have a collision. > >> No. I think this is lapping over to the msrp-chat nickname issue to > >> because of needing to sort out what happens when two people request the > >> same nickname. > > In msrp-chat, I want it to not be allowed. If two users request the > same > > nickname, I want an error on the second (and succeeding) requests. The > > problem we are discussing: same nickname, different domains, cannot > exist. > > The only acceptable domain is the domain of the chat. > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 07 20:42: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 1IIZbk-0008OC-80; Tue, 07 Aug 2007 20:41:04 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIZbi-0008IP-6F for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 20:41:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIZbg-0008Cp-Jw for simple@ietf.org; Tue, 07 Aug 2007 20:41:00 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIZbf-0006Ae-La for simple@ietf.org; Tue, 07 Aug 2007 20:41:00 -0400 Received: by py-out-1112.google.com with SMTP id f31so19660pyh for ; Tue, 07 Aug 2007 17:40:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=uSzLSFfQ7/91fE61L25+ZsnstNIsbfAdrm10U53Y4pdIo4S1TuOtgG/8dtExNSgKhh/qzbP557PDe6WXru1o8zo+as8cnE55jKvT8Ob3nYnzEPOc/SDjtFsdSPSr+Gzygd5CTRbRY0mE5JwTA9q+VdQvdpN6aAcY9ksKv7WvN1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=krCHGDZRkEN4UFxHVKG6CT21TZZcqLZ7Xyy5ed03e7WOUzLGYsW1NfSCyJf4vgMHWyzdJB/wl7t+XOuPrlz9w4tbZtBtoMoOQxVNc2RPeyNxlaS/RChux16VLetxUWjK/E3imwTehePjS2GgU60u7NkhF5FXQX9tdim6TBZ3b6o= Received: by 10.65.159.3 with SMTP id l3mr38054qbo.1186533658084; Tue, 07 Aug 2007 17:40:58 -0700 (PDT) Received: by 10.65.213.1 with HTTP; Tue, 7 Aug 2007 17:40:57 -0700 (PDT) Message-ID: <66cd252f0708071740r20e31c76u3f38e04023fd2a4f@mail.gmail.com> Date: Wed, 8 Aug 2007 10:40:57 +1000 From: "Hisham Khartabil" To: "Miguel Garcia" Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI In-Reply-To: <46B6B26C.3080002@nsn.com> MIME-Version: 1.0 References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com> <66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com> <46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Paul Kyzivat , SIMPLE mailing list , Niemi Aki X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1223315382==" Errors-To: simple-bounces@ietf.org --===============1223315382== Content-Type: multipart/alternative; boundary="----=_Part_1255_21541223.1186533657996" ------=_Part_1255_21541223.1186533657996 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 06/08/2007, Miguel Garcia wrote: > > Let me try to seek consensus on the issue of the Nickname URI. > > We have been hearing that we need to allow URIs to be issued by any > entity as well as the chat server. We agreed that the MSRP chat draft > will tackle only the latter. > > We haven't really agreed whether we envision MSRP chat operations > (namely the NICKNAME method) with domain URIs in the future. The current > version of the draft leaves open space for it, but this has created some > misunderstanding. Since there is current work on generalized nicknames I > would suggest that we take the assumption that the MSRP NICKNAME method > only deals with chat room server scoped nicknames. Domain nicknames are > not considered with the NICKNAME method. Agreed. We are having discussions on the representation of a nickname URI. Some > of these problems come from the fact that we don't really know how to > represent domain nicknames and we don't know the relation of them to the > chat room server. I've been thinking that we should decouple the > nickname itself from its representation in a URI. So, my suggestion is > that the MSRP chat draft goes ahead with its representation of nicknames > in a URI, for the purpose of reservation/validation (NICKNAME method), > having into account that those nicknames are scoped to the focus of the > conference. Other representation of nicknames (domain-scoped nicknames) > may appear in From and To headers in CPIM, but not in NICKNAME method. > > Representation of chat room scoped nicknames. We need a mechanism to > identify that a nickname URI is effectively a nickname URI, and be able > to extract the nickname (for rendering in the UI) from the rest of teh > URI. Jonathan proposed: > > sip:"msrp-nicknames" "/" "/" @ domain > > which is correct in my opinion. While there have been other suggestions, > I haven't heard anyone indicating that Jonathan's proposal wouldn't > work. So, I suggest we go for it. I agree with the above. Do we also have concensus that a nickname URI is routable to the focus (chatroom) outside the session? Hisham /Miguel > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Siemens Networks Espoo, Finland > > ------=_Part_1255_21541223.1186533657996 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 06/08/2007, Miguel Garcia <Miguel.Garcia@nsn.com> wrote:
Let me try to seek consensus on the issue of the Nickname URI.

We have been hearing that we need to allow URIs to be issued by any
entity as well as the chat server. We agreed that the MSRP chat draft
will tackle only the latter.

We haven't really agreed whether we envision MSRP chat operations
(namely the NICKNAME method) with domain URIs in the future. The current
version of the draft leaves open space for it, but this has created some
misunderstanding. Since there is current work on generalized nicknames I
would suggest that we take the assumption that the MSRP NICKNAME method
only deals with chat room server scoped nicknames. Domain nicknames are
not considered with the NICKNAME method.
 
 
Agreed.

We are having discussions on the representation of a nickname URI. Some
of these problems come from the fact that we don't really know how to
represent domain nicknames and we don't know the relation of them to the
chat room server. I've been thinking that we should decouple the
nickname itself from its representation in a URI. So, my suggestion is
that the MSRP chat draft goes ahead with its representation of nicknames
in a URI, for the purpose of reservation/validation (NICKNAME method),
having into account that those nicknames are scoped to the focus of the
conference. Other representation of nicknames (domain-scoped nicknames)
may appear in From and To headers in CPIM, but not in NICKNAME method.

Representation of chat room scoped nicknames. We need a mechanism to
identify that a nickname URI is effectively a nickname URI, and be able
to extract the nickname (for rendering in the UI) from the rest of teh
URI. Jonathan proposed:

sip:"msrp-nicknames" "/" <nickname> "/" <conf-uri-userpart> @ domain

which is correct in my opinion. While there have been other suggestions,
I haven't heard anyone indicating that Jonathan's proposal wouldn't
work. So, I suggest we go for it.
 
I agree with the above.
 
Do we also have concensus that a nickname URI is routable to the focus (chatroom) outside the session?
 
Hisham
 

/Miguel
--
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland


------=_Part_1255_21541223.1186533657996-- --===============1223315382== 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 --===============1223315382==-- From simple-bounces@ietf.org Tue Aug 07 21:02:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIZvA-0005rS-Jp; Tue, 07 Aug 2007 21:01:08 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIZv8-0005rN-OG for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 21:01:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIZv8-0005rF-DU for simple@ietf.org; Tue, 07 Aug 2007 21:01:06 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIZv6-0006rA-7V for simple@ietf.org; Tue, 07 Aug 2007 21:01:04 -0400 Received: by py-out-1112.google.com with SMTP id f31so33836pyh for ; Tue, 07 Aug 2007 18:01:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=cLfBfqszi0/9f1vuq9udJ4vbc6KV3ECiyPNmpdEcPwkk0QQkreOJ+uao+V1pGKDrwZykCD4baQNe0VSTyJCF07NC+44hT5IU4UAT/XDhnhoaEhXqLDwrM9hgCKUpvzjKfkzwI95CYAMB3uoVWXK59IGTBqgNZKFnIAPB1L6QlKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=aP/jwfNLXxxM8Qlq/k+ARy0dF2zBvtH3WNXhuWKfFDJv6a4NpKlKp99njI5NLRdfNqk+sfhiDdpn1lwZJJSFs9A2HeikUxjgQjsjT9HniUQPCMwcRgt3ODFQmqaVWvvibjuWj+v+z8TjyIKwnhQwOaloRzk+/jlYMmMY+ff8w+w= Received: by 10.65.83.18 with SMTP id k18mr11884838qbl.1186534863112; Tue, 07 Aug 2007 18:01:03 -0700 (PDT) Received: by 10.65.213.1 with HTTP; Tue, 7 Aug 2007 18:01:03 -0700 (PDT) Message-ID: <66cd252f0708071801v6aa09016qb16c2dfb4de06f64@mail.gmail.com> Date: Wed, 8 Aug 2007 11:01:03 +1000 From: "Hisham Khartabil" To: "Brian Rosen" Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI In-Reply-To: <08cf01c7d956$7e059b60$640fa8c0@cis.neustar.com> MIME-Version: 1.0 References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com> <66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com> <46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <66cd252f0708071740r20e31c76u3f38e04023fd2a4f@mail.gmail.com> <08cf01c7d956$7e059b60$640fa8c0@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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: , Content-Type: multipart/mixed; boundary="===============0774476704==" Errors-To: simple-bounces@ietf.org --===============0774476704== Content-Type: multipart/alternative; boundary="----=_Part_1415_5086680.1186534863029" ------=_Part_1415_5086680.1186534863029 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline (adding SIMPLE again) I don't have the participant's URI to message him outside the session. The only way to reach him is through his nickname in the chatroom. It is a sort of private message where the user is not reachable after the chat session is terminated. Hisham On 08/08/2007, Brian Rosen wrote: > > > >Do we also have concensus that a nickname URI is routable to the focus > (chatroom) outside the session? > > No > > For one thing, we don't know what that means. For another thing, we know > we > will be permitting the domain of the URI to be outside the focus domain in > the generalized case, and it won't work at all. > > The only thing we define the URI to be able to be used for is in an msrp > from: and to:. In xcon, there may be more operations defined, but none of > them are outside the session. > > Why do you want to do this? > > Brian > > ------=_Part_1415_5086680.1186534863029 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
(adding SIMPLE again)
 
I don't have the participant's URI to message him outside the session. The only way to reach him is through his nickname in the chatroom. It is a sort of private message where the user is not reachable after the chat session is terminated.
 
Hisham

 
On 08/08/2007, Brian Rosen <br@brianrosen.net> wrote:

>Do we also have concensus that a nickname URI is routable to the focus
(chatroom) outside the session?

No

For one thing, we don't know what that means.  For another thing, we know we
will be permitting the domain of the URI to be outside the focus domain in
the generalized case, and it won't work at all.

The only thing we define the URI to be able to be used for is in an msrp
from: and to:.  In xcon, there may be more operations defined, but none of
them are outside the session.

Why do you want to do this?

Brian


------=_Part_1415_5086680.1186534863029-- --===============0774476704== 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 --===============0774476704==-- From simple-bounces@ietf.org Tue Aug 07 23:18: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 1IIc1x-0005Gz-Vw; Tue, 07 Aug 2007 23:16:17 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIc1w-0005Gt-7p for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 23:16:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIc1v-0005Gl-Ry for simple@ietf.org; Tue, 07 Aug 2007 23:16:15 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIc1u-0001EA-LE for simple@ietf.org; Tue, 07 Aug 2007 23:16:15 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 07 Aug 2007 23:16:14 -0400 X-IronPort-AV: i="4.19,233,1183348800"; d="scan'208"; a="128234794:sNHT77789888" 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 l783GElT005951; Tue, 7 Aug 2007 23:16:14 -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 l783G9mf003217; Wed, 8 Aug 2007 03:16:14 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, 7 Aug 2007 23:16:09 -0400 Received: from [10.86.242.134] ([10.86.242.134]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 23:16:09 -0400 Message-ID: <46B93575.7080808@cisco.com> Date: Tue, 07 Aug 2007 23:16:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> In-Reply-To: <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2007 03:16:09.0530 (UTC) FILETIME=[775701A0:01C7D96A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11381; t=1186542974; x=1187406974; 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]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20 |To:=20Brian=20Rosen=20; bh=XNDKiw7WSh+FkK10qKUu87OpdWujV+ENKPThyy/MiIU=; b=L+UIX/iN6K51QSgSh77UiU9UvcErUZPGJC5dLWMrgFQ4jHwOp+cNC5Lgnc+7UgUacU+MHZZk i6lBZmB86FmUgV/OuAM2lGuRNG1RhXCZR4RHjfz7kwFKh8DHjdDK4MG8; 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: c2e58d9873012c90703822e287241385 Cc: 'Miguel Garcia' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Brian Rosen wrote: > Let's break this down piece by piece, because we each don't yet understand > what the other is saying. > > I propose that msrp-chat not allow nickname collisions. If two users do > Set-Nickname with the same nickname, the second gets an error. > > Do you agree to that? Miguel? I'm ok with that, though I don't think we *must* do that. But I don't feel strongly about it. > I think we all agree that the generalized mechanism will allow collisions. > Let's see if we can agree on when these happen: > 1. Two users with externally defined nicknames, where the domains are > different Yes. > 2. Two users request the same nickname from the local server As I noted before, I distinguish between requesting the ownership of a nickname and trying to use it in a conference. I believe the requesting/assignment of ownership for a nickname is probably out of scope for us - it could simply be something you do at a web site. I don't think it makes any sense for one to be assigned to more than one "entity", but one might be usable with a bunch of different sets of credentials / used in conjunction with multiple user ids. I do think "collision" in the use of a single nickname should probably be ok as long as each session that asserts it is *authorized* to use it, however that is determined, which is still TBD. But if somebody wants to enforce a policy that forbids it then I guess that is their business. I also think that collision in *use* of a nickname should be ok (if policy permits) even if the nickname is *assigned* via msrp. But exactly how that would work needs some consideration. > In the hope that we all do agree, I'll press on one more (big) step. > > 3. I propose that the generalized mechanism allow an external domain to > permit the same nickname for multiple users, and a chat server or other user > of nicknames could allow that in a single chat/conference/whatever. I'm not > sure that a domain who registers nicknames will have a policy that does > permit it, but I don't see a fundamental reason why we would accept two > users with the same nicknames in the local domain, but not two users with > the same nicknames from an external domain. To make either work, somehow, a > URI has to be minted that is unique. We don't have to specify how to do > that yet, but a parameter on the URI is one way that would work. I think I agree with this. Lets see how my comments above go. Paul > I'm going to pause to see if we agree or don't. > > Brian > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, August 07, 2007 8:02 PM >> To: Brian Rosen >> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >> >> >> >> Brian Rosen wrote: >>> Inline >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Tuesday, August 07, 2007 5:20 PM >>>> To: Brian Rosen >>>> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' >>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>> >>>> >>>> >>>> Brian Rosen wrote: >>>>> I think this leads to users not understanding why their nicknames work >>>>> sometimes and not others: >>>>> >>>>> Example 1: >>>>> My nickname is joebob. Your nickname is joebob. Neither of us is >>>>> registered. >>>> Neither of us "has" the nickname joebob. We both *want* the nickname >>>> joebob in the scope of this conference. >>>> >>>>> We both ask the chat server to give us joebob. I get there >>>>> first, and you get an error. >>>> We both wanted it, and one of us won. What do you *want* to happen? >>> I want an error, especially in msrp-chat declared nicknames >> OK. That helps. But then I think your desires are inconsistent, or else >> I don't understand what you are saying. >> >> I'm saying that the *clients* of this server must be prepared for the >> case where the server supports the more general mechanism, where some >> participants may have nicknames in some other domain, and ones with >> identical names but different domains. This is so even though it might >> not be possible for that to arise using only the MSRP mechanism. >> >>>> The conf server could hand out two nicknames that are both joebob in >>>> different domains that the server controls, if it wants to do that. It >>>> depends on what its policy is for duplicates. >>> Not in msrp-chat nicknames. Yes, if that is its policy in the >> generalized >>> mechanism. The generalized mechanism needs a way to have unambiguous >> URIs >>> if it has a policy of allowing collisions on nicknames. >> OK, if you want to make that rule for the msrp mechanism, then that is >> ok, so long as you then only allow one request for a given nickname to >> succeed at any given time. (Which I now see you do want.) >> >>>>> Example 2: >>>>> My nickname is joebob. Your nickname is joebob. I am registered at >>>> some >>>>> other domain. We both ask the chat server to give us joebob. I get >>>> there >>>>> first, but this time it works for you. >>>> In that case you *do* *have* the nickname joebob in some domain. Its >>>> more than a wish. So this isn't surprising. >>> It is surprising to the user, who doesn't understand the difference >> Users already must understand the difference between permanently signing >> up for a nickname vs not doing that and just trying to get one when they >> enter a chat. This is not unfamiliar. >> >> And if you want, you can make a rule that an msrp nickname request will >> always fail if there is already someone in the chat using an external >> nickname that "clashes". BUT, that isn't a complete solution unless you >> also prevent anyone using an external nickname from later joining the >> chat if their nickname clashes. While you *could* do that I think it >> would be a bad way forward. >> >> As long as the UIs are prepared for this from day 1 I think the users >> will cope. >> >>>> Are you assuming that anyone can ask for any nickname from any server, >>>> and always get it, even if someone else also has the same nickname from >>>> the same server? If so, the protocol and the UI can't distinguish them >>>> and I can't selectively send to one or the other. I find that entirely >>>> unacceptable. >>> I am not assuming that. I am assuming that if the policy for nicknames >> is >>> that collisions are allowed, that a collision exists whether the domain >> of >>> the nickname is the same or different as long as the nickname itself is >> the >>> same. >>> If the policy is that collisions are not allowed then two users >> requesting >>> the same nickname that happen to have different domains would be >> rejected >>> with an error. >> I think there is some confusion here. There is requesting to have a >> nickname *assigned* to you within some scope/domain, when it otherwise >> wasn't, and there is requesting to *use* a nickname in a particular >> session. The msrp method does both, binding the scope/domain of the >> assignment to the session you are establishing. >> >> There can be collision on assignment, and there can be collision on use. >> And there can be collision on the name+domain or on just the name. >> >> I believe the policy you are suggesting applies to collision on just >> names, for *use*, not assignment. I agree you can go either way on that, >> though it will ultimately be an annoying system if it forbids it. >> >> For assignment we always allow collision on names if the domains are >> different - that is the point, and there is no way to forbid it if the >> assignment is administered independently per domain. >> >> For assignment collision on name+domain is probably a bad idea, unless >> the entities doing the requesting are really the same in some sense. If >> they are then there probably aren't multiple assignments. So I think >> this is a non-issue. >> >> Collision on use at the name+domain level must be carefully controlled >> or users of the system will not be able to make any sense of it. I think >> the same name+domain can be used for multiple sessions with the focus >> *if* all the sessions belong to the same user, whatever that means. Its >> probably easy if they authenticate with the same credentials. Otherwise >> not. >> >>> Of course, it would also reject, with the same error, if the domains >> were >>> the same, >> I think you are saying what I said in last paragraph above. >> >>> specifically if they were requested from the using domain (the >>> chat server). This would always be the case in an msrp-chat nickname >>> declaration because I want this mechanism to always disallow collisions. >> I'm not sure if we are agreeing or not. >> >>>>> You would have to know that I registered my nick somewhere else, so my >>>> URI >>>>> is unique, to know why you got an error in the first example, but >> didn't >>>> in >>>>> the second. Normally, the URI isn't visible to the users, only the >>>> names >>>>> are. >>>> This would be no different than me being the 2nd user rather than the >>>> first to show up. >>>> >>>> You think this is unacceptable, but I find it way more acceptable than >>>> not being able to discriminate between two distinct joebobs. >>> I think if collisions are allowed, collisions exist if the nicknames are >> the >>> same, and the mechanism must provide a way to construct a unique URI. >> If >>> the domains are different, then it's easy. If the domains are the same, >>> more work is needed. >> If you want to use something other than domain for further >> discrimination (e.g. an URI parameter), for the msrp case, then I can >> probably live with that, pending the details. >> >>>> As I said above, if you want more-or-less this behavior then we must >>>> allow the MSRP server to accept multiple requests for nickname joebob >>>> and give them *different* URIs in return. >>> Yes, I agree with this, but only in the case of the generalized >> mechanism, >>> where the policy of the chat server (which is could mint nicknames using >> the >>> generalized mechanism) was to allow collisions. >> Again I don't know if we are agreeing or disagreeing. >> >>>>> If you allow a nickname collision, you incur costs at both the server >>>> and >>>>> the clients. You can't avoid them. Collision really is the name; the >>>>> domain MAY help you, but since it can't fix the whole problem, it >> isn't >>>>> useful. >>>>> >>>>> Note that we are discussing the generalized nickname mechanisms, not >> the >>>>> msrp-chat. We're projecting a problem onto that mechanism and trying >> to >>>>> solve it here. In msrp-chat, you can't have a collision. >>>> No. I think this is lapping over to the msrp-chat nickname issue to >>>> because of needing to sort out what happens when two people request the >>>> same nickname. >>> In msrp-chat, I want it to not be allowed. If two users request the >> same >>> nickname, I want an error on the second (and succeeding) requests. The >>> problem we are discussing: same nickname, different domains, cannot >> exist. >>> The only acceptable domain is the domain of the chat. >>> >>> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 07 23:27:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIcBL-0003DG-MB; Tue, 07 Aug 2007 23:25:59 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIcBJ-0003D5-VY for simple-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 23:25:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIcBJ-0003Cw-Lx for simple@ietf.org; Tue, 07 Aug 2007 23:25:57 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIcBI-0003bH-Fg for simple@ietf.org; Tue, 07 Aug 2007 23:25:57 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Aug 2007 23:25:54 -0400 X-IronPort-AV: i="4.19,233,1183348800"; d="scan'208"; a="128235127:sNHT56773208" 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 l783PsKm025516; Tue, 7 Aug 2007 23:25:54 -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 l783PnjK011220; Wed, 8 Aug 2007 03:25:49 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 23:25:49 -0400 Received: from [10.86.242.134] ([10.86.242.134]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 23:25:49 -0400 Message-ID: <46B937B7.1050601@cisco.com> Date: Tue, 07 Aug 2007 23:25:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com> <66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com> <46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <66cd252f0708071740r20e31c76u3f38e04023fd2a4f@mail.gmail.com> In-Reply-To: <66cd252f0708071740r20e31c76u3f38e04023fd2a4f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2007 03:25:49.0224 (UTC) FILETIME=[D0DD4A80:01C7D96B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2088; t=1186543554; x=1187407554; 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]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20 |To:=20Hisham=20Khartabil=20; bh=J6fybSuxeCvmniFDaubVuzaaRluQb5GK7ULUvyiXZ6w=; b=q4zwl5l7FZE55SQvgP81YBYXwNJx2EFiCfvssRMwoZSlJkvOKGJXCealY4KkLB6IJq9/chBh +X6nsVyPRoI4J4ybyFKkcZppbxR7niGygMExrBGt8NqmVuOia7EVJhEX; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Miguel Garcia , SIMPLE mailing list , Niemi Aki X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hisham Khartabil wrote: > Representation of chat room scoped nicknames. We need a mechanism to > identify that a nickname URI is effectively a nickname URI, and be able > to extract the nickname (for rendering in the UI) from the rest of teh > URI. Jonathan proposed: > > sip:"msrp-nicknames" "/" "/" @ domain > > which is correct in my opinion. While there have been other suggestions, > I haven't heard anyone indicating that Jonathan's proposal wouldn't > work. So, I suggest we go for it. I think this will work with conference scoped nicknames. But it seems less than ideal for nicknames that are more broadly scoped. Frankly I would prefer something like sip:[/conf-uri-userpart]@domain;user=msrp-nickname. Here the user param indicates a particular syntax for the user part. Other URIs used as nicknames but without this user parameter would be treated differently. > I agree with the above. > > Do we also have concensus that a nickname URI is routable to the focus > (chatroom) outside the session? Whether it is routable should be a policy of the minter of the nickname. I believe it would be good for an msrp-assigned nickname to be routable while it is being used, but not otherwise. For externally assigned nicknames the policy might be more involved: - might be routable all the time, like an alias - might only be routable when the nickname is being used in one or more sessions. (But I don't know how the minting domain would know that.) I don't think we need to specify this except to say that it might be, might not be, might sometimes be. Paul > Hisham > > > /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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 08 02:02: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 1IIebH-0003xs-Es; Wed, 08 Aug 2007 02:00:55 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIebE-0003xT-MA for simple-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 02:00:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIebE-0003ug-3w for simple@ietf.org; Wed, 08 Aug 2007 02:00:52 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIebC-0004oP-EJ for simple@ietf.org; Wed, 08 Aug 2007 02:00:52 -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 l7860QcE002916; Wed, 8 Aug 2007 09:00:38 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 09:00:32 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 09:00:32 +0300 Received: from [10.144.23.115] ([10.144.23.115]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 09:00:32 +0300 Message-ID: <46B95BFF.8090304@nsn.com> Date: Wed, 08 Aug 2007 09:00:31 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> In-Reply-To: <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2007 06:00:32.0182 (UTC) FILETIME=[6DF04560:01C7D981] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: 'Paul Kyzivat' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org You guys had a long discussion while I was sleeping. I'll try to get my opinion to this e-mail. Inline. Brian Rosen wrote: > Let's break this down piece by piece, because we each don't yet understand > what the other is saying. > > I propose that msrp-chat not allow nickname collisions. If two users do > Set-Nickname with the same nickname, the second gets an error. > > Do you agree to that? Miguel? > Of course. Yes. This is the current behavior. The draft defines a 423 response: "Nickname usage failed; the nickname is not allocated to this user". > I think we all agree that the generalized mechanism will allow collisions. Yes, let me clarify that sentence. The generalize mechanism will allow collisions in the username part of the URI, i.e., with two different domains. This means: there are collisions for UI rendering, but there aren't collisions for routing private messages. > Let's see if we can agree on when these happen: > 1. Two users with externally defined nicknames, where the domains are > different Yes, no problem. In this case, we have the UI rendering collision, but no the routing of private messages problem. > 2. Two users request the same nickname from the local server This should not be allowed, because it will lead to two users with exactly the same byte-by-byte nickname URI, including the domain name. If these two users having the exactly same nickname URI are in the same conference, it wouldn't be possible to determine which of them is the legitimate recipient of a private message addressed to that nickname URI. I think this shouldn't be allowed. > > In the hope that we all do agree, I'll press on one more (big) step. > > 3. I propose that the generalized mechanism allow an external domain to > permit the same nickname for multiple users, and a chat server or other user > of nicknames could allow that in a single chat/conference/whatever. I'm not > sure that a domain who registers nicknames will have a policy that does > permit it, but I don't see a fundamental reason why we would accept two > users with the same nicknames in the local domain, but not two users with > the same nicknames from an external domain. To make either work, somehow, a > URI has to be minted that is unique. We don't have to specify how to do > that yet, but a parameter on the URI is one way that would work. I don't think we should go into that direction. Permanent nicknames should be exclusively allocated to a given user. Otherwise people are going to get very confuse when they see joebob@example.com in a conference, send him a private message, and then realize is a different person from the joebob@example.com they previously messaged. I think allowing non-exclusive access to nicknames would be like issuing shared e-mail addresses. Can you imagine if br@brianrosen.net is shared by you, Paul, Hisham, and me? It would be fun though.... /Miguel > > I'm going to pause to see if we agree or don't. > > Brian > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, August 07, 2007 8:02 PM >> To: Brian Rosen >> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >> >> >> >> Brian Rosen wrote: >>> Inline >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Tuesday, August 07, 2007 5:20 PM >>>> To: Brian Rosen >>>> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' >>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>> >>>> >>>> >>>> Brian Rosen wrote: >>>>> I think this leads to users not understanding why their nicknames work >>>>> sometimes and not others: >>>>> >>>>> Example 1: >>>>> My nickname is joebob. Your nickname is joebob. Neither of us is >>>>> registered. >>>> Neither of us "has" the nickname joebob. We both *want* the nickname >>>> joebob in the scope of this conference. >>>> >>>>> We both ask the chat server to give us joebob. I get there >>>>> first, and you get an error. >>>> We both wanted it, and one of us won. What do you *want* to happen? >>> I want an error, especially in msrp-chat declared nicknames >> OK. That helps. But then I think your desires are inconsistent, or else >> I don't understand what you are saying. >> >> I'm saying that the *clients* of this server must be prepared for the >> case where the server supports the more general mechanism, where some >> participants may have nicknames in some other domain, and ones with >> identical names but different domains. This is so even though it might >> not be possible for that to arise using only the MSRP mechanism. >> >>>> The conf server could hand out two nicknames that are both joebob in >>>> different domains that the server controls, if it wants to do that. It >>>> depends on what its policy is for duplicates. >>> Not in msrp-chat nicknames. Yes, if that is its policy in the >> generalized >>> mechanism. The generalized mechanism needs a way to have unambiguous >> URIs >>> if it has a policy of allowing collisions on nicknames. >> OK, if you want to make that rule for the msrp mechanism, then that is >> ok, so long as you then only allow one request for a given nickname to >> succeed at any given time. (Which I now see you do want.) >> >>>>> Example 2: >>>>> My nickname is joebob. Your nickname is joebob. I am registered at >>>> some >>>>> other domain. We both ask the chat server to give us joebob. I get >>>> there >>>>> first, but this time it works for you. >>>> In that case you *do* *have* the nickname joebob in some domain. Its >>>> more than a wish. So this isn't surprising. >>> It is surprising to the user, who doesn't understand the difference >> Users already must understand the difference between permanently signing >> up for a nickname vs not doing that and just trying to get one when they >> enter a chat. This is not unfamiliar. >> >> And if you want, you can make a rule that an msrp nickname request will >> always fail if there is already someone in the chat using an external >> nickname that "clashes". BUT, that isn't a complete solution unless you >> also prevent anyone using an external nickname from later joining the >> chat if their nickname clashes. While you *could* do that I think it >> would be a bad way forward. >> >> As long as the UIs are prepared for this from day 1 I think the users >> will cope. >> >>>> Are you assuming that anyone can ask for any nickname from any server, >>>> and always get it, even if someone else also has the same nickname from >>>> the same server? If so, the protocol and the UI can't distinguish them >>>> and I can't selectively send to one or the other. I find that entirely >>>> unacceptable. >>> I am not assuming that. I am assuming that if the policy for nicknames >> is >>> that collisions are allowed, that a collision exists whether the domain >> of >>> the nickname is the same or different as long as the nickname itself is >> the >>> same. >>> If the policy is that collisions are not allowed then two users >> requesting >>> the same nickname that happen to have different domains would be >> rejected >>> with an error. >> I think there is some confusion here. There is requesting to have a >> nickname *assigned* to you within some scope/domain, when it otherwise >> wasn't, and there is requesting to *use* a nickname in a particular >> session. The msrp method does both, binding the scope/domain of the >> assignment to the session you are establishing. >> >> There can be collision on assignment, and there can be collision on use. >> And there can be collision on the name+domain or on just the name. >> >> I believe the policy you are suggesting applies to collision on just >> names, for *use*, not assignment. I agree you can go either way on that, >> though it will ultimately be an annoying system if it forbids it. >> >> For assignment we always allow collision on names if the domains are >> different - that is the point, and there is no way to forbid it if the >> assignment is administered independently per domain. >> >> For assignment collision on name+domain is probably a bad idea, unless >> the entities doing the requesting are really the same in some sense. If >> they are then there probably aren't multiple assignments. So I think >> this is a non-issue. >> >> Collision on use at the name+domain level must be carefully controlled >> or users of the system will not be able to make any sense of it. I think >> the same name+domain can be used for multiple sessions with the focus >> *if* all the sessions belong to the same user, whatever that means. Its >> probably easy if they authenticate with the same credentials. Otherwise >> not. >> >>> Of course, it would also reject, with the same error, if the domains >> were >>> the same, >> I think you are saying what I said in last paragraph above. >> >>> specifically if they were requested from the using domain (the >>> chat server). This would always be the case in an msrp-chat nickname >>> declaration because I want this mechanism to always disallow collisions. >> I'm not sure if we are agreeing or not. >> >>>>> You would have to know that I registered my nick somewhere else, so my >>>> URI >>>>> is unique, to know why you got an error in the first example, but >> didn't >>>> in >>>>> the second. Normally, the URI isn't visible to the users, only the >>>> names >>>>> are. >>>> This would be no different than me being the 2nd user rather than the >>>> first to show up. >>>> >>>> You think this is unacceptable, but I find it way more acceptable than >>>> not being able to discriminate between two distinct joebobs. >>> I think if collisions are allowed, collisions exist if the nicknames are >> the >>> same, and the mechanism must provide a way to construct a unique URI. >> If >>> the domains are different, then it's easy. If the domains are the same, >>> more work is needed. >> If you want to use something other than domain for further >> discrimination (e.g. an URI parameter), for the msrp case, then I can >> probably live with that, pending the details. >> >>>> As I said above, if you want more-or-less this behavior then we must >>>> allow the MSRP server to accept multiple requests for nickname joebob >>>> and give them *different* URIs in return. >>> Yes, I agree with this, but only in the case of the generalized >> mechanism, >>> where the policy of the chat server (which is could mint nicknames using >> the >>> generalized mechanism) was to allow collisions. >> Again I don't know if we are agreeing or disagreeing. >> >>>>> If you allow a nickname collision, you incur costs at both the server >>>> and >>>>> the clients. You can't avoid them. Collision really is the name; the >>>>> domain MAY help you, but since it can't fix the whole problem, it >> isn't >>>>> useful. >>>>> >>>>> Note that we are discussing the generalized nickname mechanisms, not >> the >>>>> msrp-chat. We're projecting a problem onto that mechanism and trying >> to >>>>> solve it here. In msrp-chat, you can't have a collision. >>>> No. I think this is lapping over to the msrp-chat nickname issue to >>>> because of needing to sort out what happens when two people request the >>>> same nickname. >>> In msrp-chat, I want it to not be allowed. If two users request the >> same >>> nickname, I want an error on the second (and succeeding) requests. The >>> problem we are discussing: same nickname, different domains, cannot >> exist. >>> The only acceptable domain is the domain of the chat. >>> >>> > -- 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 From simple-bounces@ietf.org Wed Aug 08 09:29:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIlZV-0008IG-Bm; Wed, 08 Aug 2007 09:27:33 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IIlZT-0008I5-Lw for simple-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 09:27:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIlZT-0008Hv-Bu for simple@ietf.org; Wed, 08 Aug 2007 09:27:31 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIlZR-00008k-T9 for simple@ietf.org; Wed, 08 Aug 2007 09:27:31 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IIlZD-0001hJ-FH; Wed, 08 Aug 2007 08:27:16 -0500 From: "Brian Rosen" To: "'Miguel Garcia'" References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Wed, 8 Aug 2007 09:27:19 -0400 Message-ID: <094501c7d9bf$dac457b0$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: AcfZgXRiY6xr3InCQD+gVFsVAQ84egAObC+A In-reply-to: <46B95BFF.8090304@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: 9c7d7a899dc8f3389bf7ace6f0ad8e29 Cc: 'Paul Kyzivat' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Okay, progress. Slow, but progress. Miguel, you think that there can be UI collisions. You worry that if we allow domain collisions, we can't create distinct URIs. I'd like to point out, as I did with Paul, that users won't really be aware of the domains. It may well be that a user registers his nick with some service, but the domain won't show up anywhere they can see (normally). Most importantly, whether I register a nick at some external domain or not shouldn't affect what YOU see. I may be aware of my nick's domain, but you are not. This, to me, is the problem with your position on this issue. You want to not allow a local domain to have two users with the same nick, but you are okay with two users from external domains (or one internal and one external) having the same nick. You think the UI can deal with the nickname part, but you are concerned we won't have a way to create a unique URI. I think, to a user, the cases look the same, and especially to a user who did not register their nick with an external service, they may be able to get a nick with a collision sometimes (if the other guy used an external service) but not other times (if the other guy used the local service). Since the domain is normally not visible, that is poor design. I also think it's easily fixed. I've been thinking about this for a while now, and have come to the conclusion that we have made a leap of assumption we should not have made. The leap is that you construct the uri from the nickname. Let's think about not doing that for a moment. Suppose that nicknames were associated with a URI, but the association was not a construction rule using the nickname, but rather just a URI minted by the chat server, a full fledged anonymous URI. Suppose it ALWAYS did that, i.e. the response to a Set-Nickname, whether using the msrp-chat mechanism or the generalized mechanism was that it returned an anonymous URI. Now, everything works: you always have a unique URI to use. The name collision can be dealt with by the UI, and it works the same way no matter what the domains the nicknames are declared in are. And Hisham's notion that maybe you can make that URI work outside the session could be made to work by the chat-server, if it wanted to. And to Paul's notion that only collision on use is important, it addresses that issue as well. And it gets us out of funny escaping, new parameters, and other weirdities of a construction rule Brian > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > Sent: Wednesday, August 08, 2007 2:01 AM > To: Brian Rosen > Cc: 'Paul Kyzivat'; 'SIMPLE mailing list'; 'Niemi Aki' > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > You guys had a long discussion while I was sleeping. I'll try to get my > opinion to this e-mail. Inline. > > Brian Rosen wrote: > > Let's break this down piece by piece, because we each don't yet > understand > > what the other is saying. > > > > I propose that msrp-chat not allow nickname collisions. If two users do > > Set-Nickname with the same nickname, the second gets an error. > > > > Do you agree to that? Miguel? > > > > Of course. Yes. This is the current behavior. The draft defines a 423 > response: "Nickname usage failed; the nickname is not allocated to this > user". > > > > I think we all agree that the generalized mechanism will allow > collisions. > > Yes, let me clarify that sentence. The generalize mechanism will allow > collisions in the username part of the URI, i.e., with two different > domains. This means: there are collisions for UI rendering, but there > aren't collisions for routing private messages. > > > Let's see if we can agree on when these happen: > > 1. Two users with externally defined nicknames, where the domains are > > different > > Yes, no problem. In this case, we have the UI rendering collision, but > no the routing of private messages problem. > > > 2. Two users request the same nickname from the local server > > This should not be allowed, because it will lead to two users with > exactly the same byte-by-byte nickname URI, including the domain name. > If these two users having the exactly same nickname URI are in the same > conference, it wouldn't be possible to determine which of them is the > legitimate recipient of a private message addressed to that nickname > URI. I think this shouldn't be allowed. > > > > > In the hope that we all do agree, I'll press on one more (big) step. > > > > 3. I propose that the generalized mechanism allow an external domain to > > permit the same nickname for multiple users, and a chat server or other > user > > of nicknames could allow that in a single chat/conference/whatever. I'm > not > > sure that a domain who registers nicknames will have a policy that does > > permit it, but I don't see a fundamental reason why we would accept two > > users with the same nicknames in the local domain, but not two users > with > > the same nicknames from an external domain. To make either work, > somehow, a > > URI has to be minted that is unique. We don't have to specify how to do > > that yet, but a parameter on the URI is one way that would work. > > I don't think we should go into that direction. Permanent nicknames > should be exclusively allocated to a given user. Otherwise people are > going to get very confuse when they see joebob@example.com in a > conference, send him a private message, and then realize is a different > person from the joebob@example.com they previously messaged. > > I think allowing non-exclusive access to nicknames would be like issuing > shared e-mail addresses. Can you imagine if br@brianrosen.net is shared > by you, Paul, Hisham, and me? It would be fun though.... > > > /Miguel > > > > I'm going to pause to see if we agree or don't. > > > > Brian > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Tuesday, August 07, 2007 8:02 PM > >> To: Brian Rosen > >> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > >> > >> > >> > >> Brian Rosen wrote: > >>> Inline > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: Tuesday, August 07, 2007 5:20 PM > >>>> To: Brian Rosen > >>>> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > >>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > >>>> > >>>> > >>>> > >>>> Brian Rosen wrote: > >>>>> I think this leads to users not understanding why their nicknames > work > >>>>> sometimes and not others: > >>>>> > >>>>> Example 1: > >>>>> My nickname is joebob. Your nickname is joebob. Neither of us is > >>>>> registered. > >>>> Neither of us "has" the nickname joebob. We both *want* the nickname > >>>> joebob in the scope of this conference. > >>>> > >>>>> We both ask the chat server to give us joebob. I get there > >>>>> first, and you get an error. > >>>> We both wanted it, and one of us won. What do you *want* to happen? > >>> I want an error, especially in msrp-chat declared nicknames > >> OK. That helps. But then I think your desires are inconsistent, or else > >> I don't understand what you are saying. > >> > >> I'm saying that the *clients* of this server must be prepared for the > >> case where the server supports the more general mechanism, where some > >> participants may have nicknames in some other domain, and ones with > >> identical names but different domains. This is so even though it might > >> not be possible for that to arise using only the MSRP mechanism. > >> > >>>> The conf server could hand out two nicknames that are both joebob in > >>>> different domains that the server controls, if it wants to do that. > It > >>>> depends on what its policy is for duplicates. > >>> Not in msrp-chat nicknames. Yes, if that is its policy in the > >> generalized > >>> mechanism. The generalized mechanism needs a way to have unambiguous > >> URIs > >>> if it has a policy of allowing collisions on nicknames. > >> OK, if you want to make that rule for the msrp mechanism, then that is > >> ok, so long as you then only allow one request for a given nickname to > >> succeed at any given time. (Which I now see you do want.) > >> > >>>>> Example 2: > >>>>> My nickname is joebob. Your nickname is joebob. I am registered at > >>>> some > >>>>> other domain. We both ask the chat server to give us joebob. I get > >>>> there > >>>>> first, but this time it works for you. > >>>> In that case you *do* *have* the nickname joebob in some domain. Its > >>>> more than a wish. So this isn't surprising. > >>> It is surprising to the user, who doesn't understand the difference > >> Users already must understand the difference between permanently > signing > >> up for a nickname vs not doing that and just trying to get one when > they > >> enter a chat. This is not unfamiliar. > >> > >> And if you want, you can make a rule that an msrp nickname request will > >> always fail if there is already someone in the chat using an external > >> nickname that "clashes". BUT, that isn't a complete solution unless you > >> also prevent anyone using an external nickname from later joining the > >> chat if their nickname clashes. While you *could* do that I think it > >> would be a bad way forward. > >> > >> As long as the UIs are prepared for this from day 1 I think the users > >> will cope. > >> > >>>> Are you assuming that anyone can ask for any nickname from any > server, > >>>> and always get it, even if someone else also has the same nickname > from > >>>> the same server? If so, the protocol and the UI can't distinguish > them > >>>> and I can't selectively send to one or the other. I find that > entirely > >>>> unacceptable. > >>> I am not assuming that. I am assuming that if the policy for > nicknames > >> is > >>> that collisions are allowed, that a collision exists whether the > domain > >> of > >>> the nickname is the same or different as long as the nickname itself > is > >> the > >>> same. > >>> If the policy is that collisions are not allowed then two users > >> requesting > >>> the same nickname that happen to have different domains would be > >> rejected > >>> with an error. > >> I think there is some confusion here. There is requesting to have a > >> nickname *assigned* to you within some scope/domain, when it otherwise > >> wasn't, and there is requesting to *use* a nickname in a particular > >> session. The msrp method does both, binding the scope/domain of the > >> assignment to the session you are establishing. > >> > >> There can be collision on assignment, and there can be collision on > use. > >> And there can be collision on the name+domain or on just the name. > >> > >> I believe the policy you are suggesting applies to collision on just > >> names, for *use*, not assignment. I agree you can go either way on > that, > >> though it will ultimately be an annoying system if it forbids it. > >> > >> For assignment we always allow collision on names if the domains are > >> different - that is the point, and there is no way to forbid it if the > >> assignment is administered independently per domain. > >> > >> For assignment collision on name+domain is probably a bad idea, unless > >> the entities doing the requesting are really the same in some sense. If > >> they are then there probably aren't multiple assignments. So I think > >> this is a non-issue. > >> > >> Collision on use at the name+domain level must be carefully controlled > >> or users of the system will not be able to make any sense of it. I > think > >> the same name+domain can be used for multiple sessions with the focus > >> *if* all the sessions belong to the same user, whatever that means. Its > >> probably easy if they authenticate with the same credentials. Otherwise > >> not. > >> > >>> Of course, it would also reject, with the same error, if the domains > >> were > >>> the same, > >> I think you are saying what I said in last paragraph above. > >> > >>> specifically if they were requested from the using domain (the > >>> chat server). This would always be the case in an msrp-chat nickname > >>> declaration because I want this mechanism to always disallow > collisions. > >> I'm not sure if we are agreeing or not. > >> > >>>>> You would have to know that I registered my nick somewhere else, so > my > >>>> URI > >>>>> is unique, to know why you got an error in the first example, but > >> didn't > >>>> in > >>>>> the second. Normally, the URI isn't visible to the users, only the > >>>> names > >>>>> are. > >>>> This would be no different than me being the 2nd user rather than the > >>>> first to show up. > >>>> > >>>> You think this is unacceptable, but I find it way more acceptable > than > >>>> not being able to discriminate between two distinct joebobs. > >>> I think if collisions are allowed, collisions exist if the nicknames > are > >> the > >>> same, and the mechanism must provide a way to construct a unique URI. > >> If > >>> the domains are different, then it's easy. If the domains are the > same, > >>> more work is needed. > >> If you want to use something other than domain for further > >> discrimination (e.g. an URI parameter), for the msrp case, then I can > >> probably live with that, pending the details. > >> > >>>> As I said above, if you want more-or-less this behavior then we must > >>>> allow the MSRP server to accept multiple requests for nickname joebob > >>>> and give them *different* URIs in return. > >>> Yes, I agree with this, but only in the case of the generalized > >> mechanism, > >>> where the policy of the chat server (which is could mint nicknames > using > >> the > >>> generalized mechanism) was to allow collisions. > >> Again I don't know if we are agreeing or disagreeing. > >> > >>>>> If you allow a nickname collision, you incur costs at both the > server > >>>> and > >>>>> the clients. You can't avoid them. Collision really is the name; > the > >>>>> domain MAY help you, but since it can't fix the whole problem, it > >> isn't > >>>>> useful. > >>>>> > >>>>> Note that we are discussing the generalized nickname mechanisms, not > >> the > >>>>> msrp-chat. We're projecting a problem onto that mechanism and > trying > >> to > >>>>> solve it here. In msrp-chat, you can't have a collision. > >>>> No. I think this is lapping over to the msrp-chat nickname issue to > >>>> because of needing to sort out what happens when two people request > the > >>>> same nickname. > >>> In msrp-chat, I want it to not be allowed. If two users request the > >> same > >>> nickname, I want an error on the second (and succeeding) requests. > The > >>> problem we are discussing: same nickname, different domains, cannot > >> exist. > >>> The only acceptable domain is the domain of the chat. > >>> > >>> > > > > -- > 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 From simple-bounces@ietf.org Wed Aug 08 11:17: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 1IInGK-000164-Jl; Wed, 08 Aug 2007 11:15:52 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IInGJ-00015f-2l for simple-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 11:15:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IInGI-00015V-MH for simple@ietf.org; Wed, 08 Aug 2007 11:15:50 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IInGG-0001jz-Rb for simple@ietf.org; Wed, 08 Aug 2007 11:15:50 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Aug 2007 11:15:45 -0400 X-IronPort-AV: i="4.19,236,1183348800"; d="scan'208"; a="67406400:sNHT82354120" 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 l78FFkTY001468; Wed, 8 Aug 2007 11:15:46 -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 l78FFTmt013952; Wed, 8 Aug 2007 15:15:45 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, 8 Aug 2007 11:15:33 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 11:15:33 -0400 Message-ID: <46B9DE12.6090400@cisco.com> Date: Wed, 08 Aug 2007 11:15:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> In-Reply-To: <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2007 15:15:33.0233 (UTC) FILETIME=[F6E96610:01C7D9CE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=18588; t=1186586146; x=1187450146; 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]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20 |To:=20Brian=20Rosen=20; bh=fx1ln3+SBkeeo5k3PeMFumoZ4Oz9YaVkWBhdq6kV0SA=; b=nSQj2a17t3y6c537Zxg/OY+qdVVpNvxn/xTuPdH9CCS2BjTTWAW/N0pfrEGUvpxsMk+ME1W3 JgFNF5LL79Y84u3n+vdaxijYFtYllhGjIrJpSSBtHhbso2O+ZiqCHFqE; 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: efc5d1db3729b4b7031f1bb5f5a30ae3 Cc: 'Miguel Garcia' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Brian Rosen wrote: > Okay, progress. Slow, but progress. > > Miguel, you think that there can be UI collisions. You worry that if we > allow domain collisions, we can't create distinct URIs. > > I'd like to point out, as I did with Paul, that users won't really be aware > of the domains. It may well be that a user registers his nick with some > service, but the domain won't show up anywhere they can see (normally). > Most importantly, whether I register a nick at some external domain or not > shouldn't affect what YOU see. I may be aware of my nick's domain, but you > are not. I don't agree with your assumptions. This all depends on how the UI is managed for the client, and is somewhat speculative because its all about functionality that doesn't currently exist. To use this capability you will need to register for a nickname with some service, and tell your IM client to use that one. Surely this will be apparent to the user as something different than telling the IM client to try to use an unregistered nickname in conferences. I would also expect that a good IM client would have a way of discovering the details about a participant that it doesn't display be default. So I should be *able* to see your domain if I ever care. This is a lot like how addresses are managed in email clients. Lots of clients seem to hide the actual URL by default and only show the display name. But typically there is a way to cause the URL to be displayed, or to at least query for it if you care. Some people go through life thinking there is only one John Smith, because they only get email from one. But when they reply, it is to the right one. > This, to me, is the problem with your position on this issue. You want to > not allow a local domain to have two users with the same nick, but you are > okay with two users from external domains (or one internal and one external) > having the same nick. You think the UI can deal with the nickname part, but > you are concerned we won't have a way to create a unique URI. I think you are mixing up "domain" and "nickname assignment service". A single nickname assignment service, whether an independent entity or part of a conference focus, can potentially allow collisions on the name part of a nickname URI by assigning URIs that are distinct in some other part of the URI, whether that be by using two domain names, or by adding a parameter, or whatever. So if two users both want to be joebob in a conference with focus sip:chatter@atlanta.com, then one possibility might be: - sip:joebob/chatter@atlanta.com;user=msrp-nickname - sip:joebob/chatter@atlanta.com;user=msrp-nickname;instance=2 or - sip:joebob/1/chatter@atlanta.com;user=msrp-nickname - sip:joebob/2/chatter@atlanta.com;user=msrp-nickname Of course these would require us to agree on the conventions about what part is typically displayed. If those two users wanted to request joebob from an independent service that owns domain nick.name then it could do it as: - sip:joebob@nick.name - sip:joebob@2.nick.name or - sip:joebob@1.nick.name - sip:joebob@2.nick.name or - sip:joebob@ma.nick.name - sip:joebob@pa.nick.name or - sip:joebob@nick.name;instance=1 - sip:joebob@nick.name;instance=2 And there are lots more possibilities. With these the display convention could simply be to use the username part by default, and qualify it in some way when there is more than one in the same conference. > I think, to a user, the cases look the same, and especially to a user who > did not register their nick with an external service, they may be able to > get a nick with a collision sometimes (if the other guy used an external > service) but not other times (if the other guy used the local service). > Since the domain is normally not visible, that is poor design. > > I also think it's easily fixed. > > I've been thinking about this for a while now, and have come to the > conclusion that we have made a leap of assumption we should not have made. > The leap is that you construct the uri from the nickname. > > Let's think about not doing that for a moment. > > Suppose that nicknames were associated with a URI, but the association was > not a construction rule using the nickname, but rather just a URI minted by > the chat server, a full fledged anonymous URI. > > Suppose it ALWAYS did that, i.e. the response to a Set-Nickname, whether > using the msrp-chat mechanism or the generalized mechanism was that it > returned an anonymous URI. > > Now, everything works: you always have a unique URI to use. The name > collision can be dealt with by the UI, and it works the same way no matter > what the domains the nicknames are declared in are. > > And Hisham's notion that maybe you can make that URI work outside the > session could be made to work by the chat-server, if it wanted to. > > And to Paul's notion that only collision on use is important, it addresses > that issue as well. > > And it gets us out of funny escaping, new parameters, and other weirdities > of a construction rule How is what you are suggesting different from a display name on an anonymous URI? It is essential that a nickname only be used when authorized. Of course that is the unresolved issue with externally assigned nicknames as well. This of course wouldn't be a problem if the nickname service was a full fledged anonymizer. When messages when through the anonymizer, the source address would be replaced with the nickname, and the nickname would be what was authorized by the recipient/focus. Paul > Brian > >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >> Sent: Wednesday, August 08, 2007 2:01 AM >> To: Brian Rosen >> Cc: 'Paul Kyzivat'; 'SIMPLE mailing list'; 'Niemi Aki' >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >> >> You guys had a long discussion while I was sleeping. I'll try to get my >> opinion to this e-mail. Inline. >> >> Brian Rosen wrote: >>> Let's break this down piece by piece, because we each don't yet >> understand >>> what the other is saying. >>> >>> I propose that msrp-chat not allow nickname collisions. If two users do >>> Set-Nickname with the same nickname, the second gets an error. >> > >> > Do you agree to that? Miguel? >> > >> >> Of course. Yes. This is the current behavior. The draft defines a 423 >> response: "Nickname usage failed; the nickname is not allocated to this >> user". >> >> >>> I think we all agree that the generalized mechanism will allow >> collisions. >> >> Yes, let me clarify that sentence. The generalize mechanism will allow >> collisions in the username part of the URI, i.e., with two different >> domains. This means: there are collisions for UI rendering, but there >> aren't collisions for routing private messages. >> >>> Let's see if we can agree on when these happen: >>> 1. Two users with externally defined nicknames, where the domains are >>> different >> Yes, no problem. In this case, we have the UI rendering collision, but >> no the routing of private messages problem. >> >>> 2. Two users request the same nickname from the local server >> This should not be allowed, because it will lead to two users with >> exactly the same byte-by-byte nickname URI, including the domain name. >> If these two users having the exactly same nickname URI are in the same >> conference, it wouldn't be possible to determine which of them is the >> legitimate recipient of a private message addressed to that nickname >> URI. I think this shouldn't be allowed. >> >>> In the hope that we all do agree, I'll press on one more (big) step. >>> >>> 3. I propose that the generalized mechanism allow an external domain to >>> permit the same nickname for multiple users, and a chat server or other >> user >>> of nicknames could allow that in a single chat/conference/whatever. I'm >> not >>> sure that a domain who registers nicknames will have a policy that does >>> permit it, but I don't see a fundamental reason why we would accept two >>> users with the same nicknames in the local domain, but not two users >> with >>> the same nicknames from an external domain. To make either work, >> somehow, a >>> URI has to be minted that is unique. We don't have to specify how to do >>> that yet, but a parameter on the URI is one way that would work. >> I don't think we should go into that direction. Permanent nicknames >> should be exclusively allocated to a given user. Otherwise people are >> going to get very confuse when they see joebob@example.com in a >> conference, send him a private message, and then realize is a different >> person from the joebob@example.com they previously messaged. >> >> I think allowing non-exclusive access to nicknames would be like issuing >> shared e-mail addresses. Can you imagine if br@brianrosen.net is shared >> by you, Paul, Hisham, and me? It would be fun though.... >> >> >> /Miguel >>> I'm going to pause to see if we agree or don't. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Tuesday, August 07, 2007 8:02 PM >>>> To: Brian Rosen >>>> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' >>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>> >>>> >>>> >>>> Brian Rosen wrote: >>>>> Inline >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>> Sent: Tuesday, August 07, 2007 5:20 PM >>>>>> To: Brian Rosen >>>>>> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' >>>>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>>>> >>>>>> >>>>>> >>>>>> Brian Rosen wrote: >>>>>>> I think this leads to users not understanding why their nicknames >> work >>>>>>> sometimes and not others: >>>>>>> >>>>>>> Example 1: >>>>>>> My nickname is joebob. Your nickname is joebob. Neither of us is >>>>>>> registered. >>>>>> Neither of us "has" the nickname joebob. We both *want* the nickname >>>>>> joebob in the scope of this conference. >>>>>> >>>>>>> We both ask the chat server to give us joebob. I get there >>>>>>> first, and you get an error. >>>>>> We both wanted it, and one of us won. What do you *want* to happen? >>>>> I want an error, especially in msrp-chat declared nicknames >>>> OK. That helps. But then I think your desires are inconsistent, or else >>>> I don't understand what you are saying. >>>> >>>> I'm saying that the *clients* of this server must be prepared for the >>>> case where the server supports the more general mechanism, where some >>>> participants may have nicknames in some other domain, and ones with >>>> identical names but different domains. This is so even though it might >>>> not be possible for that to arise using only the MSRP mechanism. >>>> >>>>>> The conf server could hand out two nicknames that are both joebob in >>>>>> different domains that the server controls, if it wants to do that. >> It >>>>>> depends on what its policy is for duplicates. >>>>> Not in msrp-chat nicknames. Yes, if that is its policy in the >>>> generalized >>>>> mechanism. The generalized mechanism needs a way to have unambiguous >>>> URIs >>>>> if it has a policy of allowing collisions on nicknames. >>>> OK, if you want to make that rule for the msrp mechanism, then that is >>>> ok, so long as you then only allow one request for a given nickname to >>>> succeed at any given time. (Which I now see you do want.) >>>> >>>>>>> Example 2: >>>>>>> My nickname is joebob. Your nickname is joebob. I am registered at >>>>>> some >>>>>>> other domain. We both ask the chat server to give us joebob. I get >>>>>> there >>>>>>> first, but this time it works for you. >>>>>> In that case you *do* *have* the nickname joebob in some domain. Its >>>>>> more than a wish. So this isn't surprising. >>>>> It is surprising to the user, who doesn't understand the difference >>>> Users already must understand the difference between permanently >> signing >>>> up for a nickname vs not doing that and just trying to get one when >> they >>>> enter a chat. This is not unfamiliar. >>>> >>>> And if you want, you can make a rule that an msrp nickname request will >>>> always fail if there is already someone in the chat using an external >>>> nickname that "clashes". BUT, that isn't a complete solution unless you >>>> also prevent anyone using an external nickname from later joining the >>>> chat if their nickname clashes. While you *could* do that I think it >>>> would be a bad way forward. >>>> >>>> As long as the UIs are prepared for this from day 1 I think the users >>>> will cope. >>>> >>>>>> Are you assuming that anyone can ask for any nickname from any >> server, >>>>>> and always get it, even if someone else also has the same nickname >> from >>>>>> the same server? If so, the protocol and the UI can't distinguish >> them >>>>>> and I can't selectively send to one or the other. I find that >> entirely >>>>>> unacceptable. >>>>> I am not assuming that. I am assuming that if the policy for >> nicknames >>>> is >>>>> that collisions are allowed, that a collision exists whether the >> domain >>>> of >>>>> the nickname is the same or different as long as the nickname itself >> is >>>> the >>>>> same. >>>>> If the policy is that collisions are not allowed then two users >>>> requesting >>>>> the same nickname that happen to have different domains would be >>>> rejected >>>>> with an error. >>>> I think there is some confusion here. There is requesting to have a >>>> nickname *assigned* to you within some scope/domain, when it otherwise >>>> wasn't, and there is requesting to *use* a nickname in a particular >>>> session. The msrp method does both, binding the scope/domain of the >>>> assignment to the session you are establishing. >>>> >>>> There can be collision on assignment, and there can be collision on >> use. >>>> And there can be collision on the name+domain or on just the name. >>>> >>>> I believe the policy you are suggesting applies to collision on just >>>> names, for *use*, not assignment. I agree you can go either way on >> that, >>>> though it will ultimately be an annoying system if it forbids it. >>>> >>>> For assignment we always allow collision on names if the domains are >>>> different - that is the point, and there is no way to forbid it if the >>>> assignment is administered independently per domain. >>>> >>>> For assignment collision on name+domain is probably a bad idea, unless >>>> the entities doing the requesting are really the same in some sense. If >>>> they are then there probably aren't multiple assignments. So I think >>>> this is a non-issue. >>>> >>>> Collision on use at the name+domain level must be carefully controlled >>>> or users of the system will not be able to make any sense of it. I >> think >>>> the same name+domain can be used for multiple sessions with the focus >>>> *if* all the sessions belong to the same user, whatever that means. Its >>>> probably easy if they authenticate with the same credentials. Otherwise >>>> not. >>>> >>>>> Of course, it would also reject, with the same error, if the domains >>>> were >>>>> the same, >>>> I think you are saying what I said in last paragraph above. >>>> >>>>> specifically if they were requested from the using domain (the >>>>> chat server). This would always be the case in an msrp-chat nickname >>>>> declaration because I want this mechanism to always disallow >> collisions. >>>> I'm not sure if we are agreeing or not. >>>> >>>>>>> You would have to know that I registered my nick somewhere else, so >> my >>>>>> URI >>>>>>> is unique, to know why you got an error in the first example, but >>>> didn't >>>>>> in >>>>>>> the second. Normally, the URI isn't visible to the users, only the >>>>>> names >>>>>>> are. >>>>>> This would be no different than me being the 2nd user rather than the >>>>>> first to show up. >>>>>> >>>>>> You think this is unacceptable, but I find it way more acceptable >> than >>>>>> not being able to discriminate between two distinct joebobs. >>>>> I think if collisions are allowed, collisions exist if the nicknames >> are >>>> the >>>>> same, and the mechanism must provide a way to construct a unique URI. >>>> If >>>>> the domains are different, then it's easy. If the domains are the >> same, >>>>> more work is needed. >>>> If you want to use something other than domain for further >>>> discrimination (e.g. an URI parameter), for the msrp case, then I can >>>> probably live with that, pending the details. >>>> >>>>>> As I said above, if you want more-or-less this behavior then we must >>>>>> allow the MSRP server to accept multiple requests for nickname joebob >>>>>> and give them *different* URIs in return. >>>>> Yes, I agree with this, but only in the case of the generalized >>>> mechanism, >>>>> where the policy of the chat server (which is could mint nicknames >> using >>>> the >>>>> generalized mechanism) was to allow collisions. >>>> Again I don't know if we are agreeing or disagreeing. >>>> >>>>>>> If you allow a nickname collision, you incur costs at both the >> server >>>>>> and >>>>>>> the clients. You can't avoid them. Collision really is the name; >> the >>>>>>> domain MAY help you, but since it can't fix the whole problem, it >>>> isn't >>>>>>> useful. >>>>>>> >>>>>>> Note that we are discussing the generalized nickname mechanisms, not >>>> the >>>>>>> msrp-chat. We're projecting a problem onto that mechanism and >> trying >>>> to >>>>>>> solve it here. In msrp-chat, you can't have a collision. >>>>>> No. I think this is lapping over to the msrp-chat nickname issue to >>>>>> because of needing to sort out what happens when two people request >> the >>>>>> same nickname. >>>>> In msrp-chat, I want it to not be allowed. If two users request the >>>> same >>>>> nickname, I want an error on the second (and succeeding) requests. >> The >>>>> problem we are discussing: same nickname, different domains, cannot >>>> exist. >>>>> The only acceptable domain is the domain of the chat. >>>>> >>>>> >> -- >> 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 From simple-bounces@ietf.org Wed Aug 08 11:37: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 1IInZK-0003jb-GJ; Wed, 08 Aug 2007 11:35:30 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IInZI-0003jL-TV for simple-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 11:35:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IInZI-0003jD-GP for simple@ietf.org; Wed, 08 Aug 2007 11:35:28 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IInZG-0002Bc-Hi for simple@ietf.org; Wed, 08 Aug 2007 11:35:28 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IInYz-0003oY-4v; Wed, 08 Aug 2007 10:35:11 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46B9DE12.6090400@cisco.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Wed, 8 Aug 2007 11:35:12 -0400 Message-ID: <097c01c7d9d1$b9ccafa0$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: AcfZzv1UjgQ3eMaCTNGwzQ94GPEM9gAAURrQ In-reply-to: <46B9DE12.6090400@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: 439b8e44c906b144bce6744ebb966e60 Cc: 'Miguel Garcia' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Is there a reason to want a construction rule for the URI? The nick could be a display name on an anonymous URI. You would send a nickname to the nick service, it would return the anonymous URI with the display name. I think we have a problem in marking. How does anyone know that this is what the URI means? Can we do this without marking the URI itself, and know by where it goes in various messages? I don't think users managing nicknames by turning on and off display of URIs is going to work. I don't think we NEED to cause such confusion, and I'd prefer to not create the situation in the first place. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, August 08, 2007 11:16 AM > To: Brian Rosen > Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > > > Brian Rosen wrote: > > Okay, progress. Slow, but progress. > > > > Miguel, you think that there can be UI collisions. You worry that if we > > allow domain collisions, we can't create distinct URIs. > > > > I'd like to point out, as I did with Paul, that users won't really be > aware > > of the domains. It may well be that a user registers his nick with some > > service, but the domain won't show up anywhere they can see (normally). > > Most importantly, whether I register a nick at some external domain or > not > > shouldn't affect what YOU see. I may be aware of my nick's domain, but > you > > are not. > > I don't agree with your assumptions. This all depends on how the UI is > managed for the client, and is somewhat speculative because its all > about functionality that doesn't currently exist. > > To use this capability you will need to register for a nickname with > some service, and tell your IM client to use that one. Surely this will > be apparent to the user as something different than telling the IM > client to try to use an unregistered nickname in conferences. > > I would also expect that a good IM client would have a way of > discovering the details about a participant that it doesn't display be > default. So I should be *able* to see your domain if I ever care. > > This is a lot like how addresses are managed in email clients. Lots of > clients seem to hide the actual URL by default and only show the display > name. But typically there is a way to cause the URL to be displayed, or > to at least query for it if you care. Some people go through life > thinking there is only one John Smith, because they only get email from > one. But when they reply, it is to the right one. > > > This, to me, is the problem with your position on this issue. You want > to > > not allow a local domain to have two users with the same nick, but you > are > > okay with two users from external domains (or one internal and one > external) > > having the same nick. You think the UI can deal with the nickname part, > but > > you are concerned we won't have a way to create a unique URI. > > I think you are mixing up "domain" and "nickname assignment service". A > single nickname assignment service, whether an independent entity or > part of a conference focus, can potentially allow collisions on the name > part of a nickname URI by assigning URIs that are distinct in some other > part of the URI, whether that be by using two domain names, or by adding > a parameter, or whatever. > > So if two users both want to be joebob in a conference with focus > sip:chatter@atlanta.com, then one possibility might be: > - sip:joebob/chatter@atlanta.com;user=msrp-nickname > - sip:joebob/chatter@atlanta.com;user=msrp-nickname;instance=2 > or > - sip:joebob/1/chatter@atlanta.com;user=msrp-nickname > - sip:joebob/2/chatter@atlanta.com;user=msrp-nickname > > Of course these would require us to agree on the conventions about what > part is typically displayed. > > If those two users wanted to request joebob from an independent service > that owns domain nick.name then it could do it as: > - sip:joebob@nick.name > - sip:joebob@2.nick.name > or > - sip:joebob@1.nick.name > - sip:joebob@2.nick.name > or > - sip:joebob@ma.nick.name > - sip:joebob@pa.nick.name > or > - sip:joebob@nick.name;instance=1 > - sip:joebob@nick.name;instance=2 > > And there are lots more possibilities. With these the display convention > could simply be to use the username part by default, and qualify it in > some way when there is more than one in the same conference. > > > I think, to a user, the cases look the same, and especially to a user > who > > did not register their nick with an external service, they may be able > to > > get a nick with a collision sometimes (if the other guy used an external > > service) but not other times (if the other guy used the local service). > > Since the domain is normally not visible, that is poor design. > > > > I also think it's easily fixed. > > > > I've been thinking about this for a while now, and have come to the > > conclusion that we have made a leap of assumption we should not have > made. > > The leap is that you construct the uri from the nickname. > > > > Let's think about not doing that for a moment. > > > > Suppose that nicknames were associated with a URI, but the association > was > > not a construction rule using the nickname, but rather just a URI minted > by > > the chat server, a full fledged anonymous URI. > > > > Suppose it ALWAYS did that, i.e. the response to a Set-Nickname, whether > > using the msrp-chat mechanism or the generalized mechanism was that it > > returned an anonymous URI. > > > > Now, everything works: you always have a unique URI to use. The name > > collision can be dealt with by the UI, and it works the same way no > matter > > what the domains the nicknames are declared in are. > > > > And Hisham's notion that maybe you can make that URI work outside the > > session could be made to work by the chat-server, if it wanted to. > > > > And to Paul's notion that only collision on use is important, it > addresses > > that issue as well. > > > > And it gets us out of funny escaping, new parameters, and other > weirdities > > of a construction rule > > How is what you are suggesting different from a display name on an > anonymous URI? > > It is essential that a nickname only be used when authorized. Of course > that is the unresolved issue with externally assigned nicknames as well. > > This of course wouldn't be a problem if the nickname service was a full > fledged anonymizer. When messages when through the anonymizer, the > source address would be replaced with the nickname, and the nickname > would be what was authorized by the recipient/focus. > > Paul > > > Brian > > > >> -----Original Message----- > >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > >> Sent: Wednesday, August 08, 2007 2:01 AM > >> To: Brian Rosen > >> Cc: 'Paul Kyzivat'; 'SIMPLE mailing list'; 'Niemi Aki' > >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > >> > >> You guys had a long discussion while I was sleeping. I'll try to get my > >> opinion to this e-mail. Inline. > >> > >> Brian Rosen wrote: > >>> Let's break this down piece by piece, because we each don't yet > >> understand > >>> what the other is saying. > >>> > >>> I propose that msrp-chat not allow nickname collisions. If two users > do > >>> Set-Nickname with the same nickname, the second gets an error. > >> > > >> > Do you agree to that? Miguel? > >> > > >> > >> Of course. Yes. This is the current behavior. The draft defines a 423 > >> response: "Nickname usage failed; the nickname is not allocated to this > >> user". > >> > >> > >>> I think we all agree that the generalized mechanism will allow > >> collisions. > >> > >> Yes, let me clarify that sentence. The generalize mechanism will allow > >> collisions in the username part of the URI, i.e., with two different > >> domains. This means: there are collisions for UI rendering, but there > >> aren't collisions for routing private messages. > >> > >>> Let's see if we can agree on when these happen: > >>> 1. Two users with externally defined nicknames, where the domains are > >>> different > >> Yes, no problem. In this case, we have the UI rendering collision, but > >> no the routing of private messages problem. > >> > >>> 2. Two users request the same nickname from the local server > >> This should not be allowed, because it will lead to two users with > >> exactly the same byte-by-byte nickname URI, including the domain name. > >> If these two users having the exactly same nickname URI are in the same > >> conference, it wouldn't be possible to determine which of them is the > >> legitimate recipient of a private message addressed to that nickname > >> URI. I think this shouldn't be allowed. > >> > >>> In the hope that we all do agree, I'll press on one more (big) step. > >>> > >>> 3. I propose that the generalized mechanism allow an external domain > to > >>> permit the same nickname for multiple users, and a chat server or > other > >> user > >>> of nicknames could allow that in a single chat/conference/whatever. > I'm > >> not > >>> sure that a domain who registers nicknames will have a policy that > does > >>> permit it, but I don't see a fundamental reason why we would accept > two > >>> users with the same nicknames in the local domain, but not two users > >> with > >>> the same nicknames from an external domain. To make either work, > >> somehow, a > >>> URI has to be minted that is unique. We don't have to specify how to > do > >>> that yet, but a parameter on the URI is one way that would work. > >> I don't think we should go into that direction. Permanent nicknames > >> should be exclusively allocated to a given user. Otherwise people are > >> going to get very confuse when they see joebob@example.com in a > >> conference, send him a private message, and then realize is a different > >> person from the joebob@example.com they previously messaged. > >> > >> I think allowing non-exclusive access to nicknames would be like > issuing > >> shared e-mail addresses. Can you imagine if br@brianrosen.net is shared > >> by you, Paul, Hisham, and me? It would be fun though.... > >> > >> > >> /Miguel > >>> I'm going to pause to see if we agree or don't. > >>> > >>> Brian > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: Tuesday, August 07, 2007 8:02 PM > >>>> To: Brian Rosen > >>>> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > >>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > >>>> > >>>> > >>>> > >>>> Brian Rosen wrote: > >>>>> Inline > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>> Sent: Tuesday, August 07, 2007 5:20 PM > >>>>>> To: Brian Rosen > >>>>>> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > >>>>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > >>>>>> > >>>>>> > >>>>>> > >>>>>> Brian Rosen wrote: > >>>>>>> I think this leads to users not understanding why their nicknames > >> work > >>>>>>> sometimes and not others: > >>>>>>> > >>>>>>> Example 1: > >>>>>>> My nickname is joebob. Your nickname is joebob. Neither of us is > >>>>>>> registered. > >>>>>> Neither of us "has" the nickname joebob. We both *want* the > nickname > >>>>>> joebob in the scope of this conference. > >>>>>> > >>>>>>> We both ask the chat server to give us joebob. I get there > >>>>>>> first, and you get an error. > >>>>>> We both wanted it, and one of us won. What do you *want* to happen? > >>>>> I want an error, especially in msrp-chat declared nicknames > >>>> OK. That helps. But then I think your desires are inconsistent, or > else > >>>> I don't understand what you are saying. > >>>> > >>>> I'm saying that the *clients* of this server must be prepared for the > >>>> case where the server supports the more general mechanism, where some > >>>> participants may have nicknames in some other domain, and ones with > >>>> identical names but different domains. This is so even though it > might > >>>> not be possible for that to arise using only the MSRP mechanism. > >>>> > >>>>>> The conf server could hand out two nicknames that are both joebob > in > >>>>>> different domains that the server controls, if it wants to do that. > >> It > >>>>>> depends on what its policy is for duplicates. > >>>>> Not in msrp-chat nicknames. Yes, if that is its policy in the > >>>> generalized > >>>>> mechanism. The generalized mechanism needs a way to have > unambiguous > >>>> URIs > >>>>> if it has a policy of allowing collisions on nicknames. > >>>> OK, if you want to make that rule for the msrp mechanism, then that > is > >>>> ok, so long as you then only allow one request for a given nickname > to > >>>> succeed at any given time. (Which I now see you do want.) > >>>> > >>>>>>> Example 2: > >>>>>>> My nickname is joebob. Your nickname is joebob. I am registered > at > >>>>>> some > >>>>>>> other domain. We both ask the chat server to give us joebob. I > get > >>>>>> there > >>>>>>> first, but this time it works for you. > >>>>>> In that case you *do* *have* the nickname joebob in some domain. > Its > >>>>>> more than a wish. So this isn't surprising. > >>>>> It is surprising to the user, who doesn't understand the difference > >>>> Users already must understand the difference between permanently > >> signing > >>>> up for a nickname vs not doing that and just trying to get one when > >> they > >>>> enter a chat. This is not unfamiliar. > >>>> > >>>> And if you want, you can make a rule that an msrp nickname request > will > >>>> always fail if there is already someone in the chat using an external > >>>> nickname that "clashes". BUT, that isn't a complete solution unless > you > >>>> also prevent anyone using an external nickname from later joining the > >>>> chat if their nickname clashes. While you *could* do that I think it > >>>> would be a bad way forward. > >>>> > >>>> As long as the UIs are prepared for this from day 1 I think the users > >>>> will cope. > >>>> > >>>>>> Are you assuming that anyone can ask for any nickname from any > >> server, > >>>>>> and always get it, even if someone else also has the same nickname > >> from > >>>>>> the same server? If so, the protocol and the UI can't distinguish > >> them > >>>>>> and I can't selectively send to one or the other. I find that > >> entirely > >>>>>> unacceptable. > >>>>> I am not assuming that. I am assuming that if the policy for > >> nicknames > >>>> is > >>>>> that collisions are allowed, that a collision exists whether the > >> domain > >>>> of > >>>>> the nickname is the same or different as long as the nickname itself > >> is > >>>> the > >>>>> same. > >>>>> If the policy is that collisions are not allowed then two users > >>>> requesting > >>>>> the same nickname that happen to have different domains would be > >>>> rejected > >>>>> with an error. > >>>> I think there is some confusion here. There is requesting to have a > >>>> nickname *assigned* to you within some scope/domain, when it > otherwise > >>>> wasn't, and there is requesting to *use* a nickname in a particular > >>>> session. The msrp method does both, binding the scope/domain of the > >>>> assignment to the session you are establishing. > >>>> > >>>> There can be collision on assignment, and there can be collision on > >> use. > >>>> And there can be collision on the name+domain or on just the name. > >>>> > >>>> I believe the policy you are suggesting applies to collision on just > >>>> names, for *use*, not assignment. I agree you can go either way on > >> that, > >>>> though it will ultimately be an annoying system if it forbids it. > >>>> > >>>> For assignment we always allow collision on names if the domains are > >>>> different - that is the point, and there is no way to forbid it if > the > >>>> assignment is administered independently per domain. > >>>> > >>>> For assignment collision on name+domain is probably a bad idea, > unless > >>>> the entities doing the requesting are really the same in some sense. > If > >>>> they are then there probably aren't multiple assignments. So I think > >>>> this is a non-issue. > >>>> > >>>> Collision on use at the name+domain level must be carefully > controlled > >>>> or users of the system will not be able to make any sense of it. I > >> think > >>>> the same name+domain can be used for multiple sessions with the focus > >>>> *if* all the sessions belong to the same user, whatever that means. > Its > >>>> probably easy if they authenticate with the same credentials. > Otherwise > >>>> not. > >>>> > >>>>> Of course, it would also reject, with the same error, if the domains > >>>> were > >>>>> the same, > >>>> I think you are saying what I said in last paragraph above. > >>>> > >>>>> specifically if they were requested from the using domain (the > >>>>> chat server). This would always be the case in an msrp-chat > nickname > >>>>> declaration because I want this mechanism to always disallow > >> collisions. > >>>> I'm not sure if we are agreeing or not. > >>>> > >>>>>>> You would have to know that I registered my nick somewhere else, > so > >> my > >>>>>> URI > >>>>>>> is unique, to know why you got an error in the first example, but > >>>> didn't > >>>>>> in > >>>>>>> the second. Normally, the URI isn't visible to the users, only > the > >>>>>> names > >>>>>>> are. > >>>>>> This would be no different than me being the 2nd user rather than > the > >>>>>> first to show up. > >>>>>> > >>>>>> You think this is unacceptable, but I find it way more acceptable > >> than > >>>>>> not being able to discriminate between two distinct joebobs. > >>>>> I think if collisions are allowed, collisions exist if the nicknames > >> are > >>>> the > >>>>> same, and the mechanism must provide a way to construct a unique > URI. > >>>> If > >>>>> the domains are different, then it's easy. If the domains are the > >> same, > >>>>> more work is needed. > >>>> If you want to use something other than domain for further > >>>> discrimination (e.g. an URI parameter), for the msrp case, then I can > >>>> probably live with that, pending the details. > >>>> > >>>>>> As I said above, if you want more-or-less this behavior then we > must > >>>>>> allow the MSRP server to accept multiple requests for nickname > joebob > >>>>>> and give them *different* URIs in return. > >>>>> Yes, I agree with this, but only in the case of the generalized > >>>> mechanism, > >>>>> where the policy of the chat server (which is could mint nicknames > >> using > >>>> the > >>>>> generalized mechanism) was to allow collisions. > >>>> Again I don't know if we are agreeing or disagreeing. > >>>> > >>>>>>> If you allow a nickname collision, you incur costs at both the > >> server > >>>>>> and > >>>>>>> the clients. You can't avoid them. Collision really is the name; > >> the > >>>>>>> domain MAY help you, but since it can't fix the whole problem, it > >>>> isn't > >>>>>>> useful. > >>>>>>> > >>>>>>> Note that we are discussing the generalized nickname mechanisms, > not > >>>> the > >>>>>>> msrp-chat. We're projecting a problem onto that mechanism and > >> trying > >>>> to > >>>>>>> solve it here. In msrp-chat, you can't have a collision. > >>>>>> No. I think this is lapping over to the msrp-chat nickname issue to > >>>>>> because of needing to sort out what happens when two people request > >> the > >>>>>> same nickname. > >>>>> In msrp-chat, I want it to not be allowed. If two users request the > >>>> same > >>>>> nickname, I want an error on the second (and succeeding) requests. > >> The > >>>>> problem we are discussing: same nickname, different domains, cannot > >>>> exist. > >>>>> The only acceptable domain is the domain of the chat. > >>>>> > >>>>> > >> -- > >> 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 From simple-bounces@ietf.org Thu Aug 09 08:22:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ70P-0006e8-Ni; Thu, 09 Aug 2007 08:20:45 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJ70O-0006e3-Qo for simple-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 08:20:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ70O-0006dv-H5 for simple@ietf.org; Thu, 09 Aug 2007 08:20:44 -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 1IJ70M-0000Ur-JN for simple@ietf.org; Thu, 09 Aug 2007 08:20:44 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l79CK9BO014823; Thu, 9 Aug 2007 15:20:34 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 15:20:29 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 15:20:28 +0300 Received: from [10.144.23.148] ([10.144.23.148]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 15:20:28 +0300 Message-ID: <46BB068B.9080604@nsn.com> Date: Thu, 09 Aug 2007 15:20:27 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> In-Reply-To: <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2007 12:20:28.0107 (UTC) FILETIME=[ABC821B0:01C7DA7F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 Cc: 'Paul Kyzivat' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Inline Brian Rosen wrote: > Okay, progress. Slow, but progress. > > Miguel, you think that there can be UI collisions. You worry that if we > allow domain collisions, we can't create distinct URIs. > > I'd like to point out, as I did with Paul, that users won't really be aware > of the domains. It may well be that a user registers his nick with some > service, but the domain won't show up anywhere they can see (normally). > Most importantly, whether I register a nick at some external domain or not > shouldn't affect what YOU see. I may be aware of my nick's domain, but you > are not. I think this is not the case, at least in e-mail clients. You can usually see the display name (equivalent to nickname). If you hover over the nickname, you can see the full From header. I was expecting similar but not exactly the same behavior in chat rooms. The client will allocate separate identifiers to nickname collisions, such us joebob, joebob(2), joebob(3). If the user wants to send a private message to one of this, and it doesn't know which one is the target, he can hover over any of them. > > This, to me, is the problem with your position on this issue. You want to > not allow a local domain to have two users with the same nick, but you are > okay with two users from external domains (or one internal and one external) > having the same nick. You think the UI can deal with the nickname part, but > you are concerned we won't have a way to create a unique URI. I re-read this paragraph a few times, and I think I understand you and see where we have been disagreeing. So, let me try to clarify your words. Terminology: nickname-string: refers to the visible (UI) identifier. nickname-URI: refers to the associated URI. nickname: not used to avoid misleading. So, are you saying that two users of the same domain could have the same nickname-string but different nickname-URI? If this is possible, I don't have any problem. This would require to add something like a unique identifier to a each nickname-URI. For example: sip:nickname/joebob/sd098d@example.com sip:nickname/joebob/a9xc8s@example.com The UI will display joebob(1) and joebob(2) in the chat room, but the user can perhaps hover to get the full nickname-URI, or perhaps also the SIP AoR (if available). I don't have a problem with this. In the past, I have been always thinking that a nickname-string in a domain will create a unique nickname-URI. This is becoming GRUU, by the way. > > I think, to a user, the cases look the same, and especially to a user who > did not register their nick with an external service, they may be able to > get a nick with a collision sometimes (if the other guy used an external > service) but not other times (if the other guy used the local service). > Since the domain is normally not visible, that is poor design. > > I also think it's easily fixed. > > I've been thinking about this for a while now, and have come to the > conclusion that we have made a leap of assumption we should not have made. > The leap is that you construct the uri from the nickname. This is another possibility that we somehow explored in the past. If the nickname-string is not connected to (and can be derived from) the nickname-URI, it behaves essentially as a display name. The conference event package will have to send both (which is not a problem). So, the linkage between nickname-URIs and nickname-strings will exist in the chat room server only, although the endpoints will get it (mainly) via the conference event package. > > Let's think about not doing that for a moment. > > Suppose that nicknames were associated with a URI, but the association was > not a construction rule using the nickname, but rather just a URI minted by > the chat server, a full fledged anonymous URI. > > Suppose it ALWAYS did that, i.e. the response to a Set-Nickname, whether > using the msrp-chat mechanism or the generalized mechanism was that it > returned an anonymous URI. > > Now, everything works: you always have a unique URI to use. The name > collision can be dealt with by the UI, and it works the same way no matter > what the domains the nicknames are declared in are. > > And Hisham's notion that maybe you can make that URI work outside the > session could be made to work by the chat-server, if it wanted to. > > And to Paul's notion that only collision on use is important, it addresses > that issue as well. > > And it gets us out of funny escaping, new parameters, and other weirdities > of a construction rule Yeap, I think this works. I may also add one step more. We could make the focus to create a GRUU per participant that requests a nickname. The GRUU will resolve to the focus, but it will have a unique identifier that is available to the user that requested it. This allows private messaging, in and outside the conference (as per Hisham's request). The nickname-string is merely a display name. We have display names in the From/To headers in CPIM. So, a user would send the NICKNAME method with the Set-Nickname header set to the nickname-string: joebob. It will get back the nickname-string plus nickname-uri, for example: "joebob" This can be used in From/To headers, or announced via the conference event package. If there are several "joebob" in the same chat room, the UI will differentiate it. But since the nickname is unique, there is no problem to route private messages. Comments? /Miguel > > Brian > >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >> Sent: Wednesday, August 08, 2007 2:01 AM >> To: Brian Rosen >> Cc: 'Paul Kyzivat'; 'SIMPLE mailing list'; 'Niemi Aki' >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >> >> You guys had a long discussion while I was sleeping. I'll try to get my >> opinion to this e-mail. Inline. >> >> Brian Rosen wrote: >>> Let's break this down piece by piece, because we each don't yet >> understand >>> what the other is saying. >>> >>> I propose that msrp-chat not allow nickname collisions. If two users do >>> Set-Nickname with the same nickname, the second gets an error. >> > >> > Do you agree to that? Miguel? >> > >> >> Of course. Yes. This is the current behavior. The draft defines a 423 >> response: "Nickname usage failed; the nickname is not allocated to this >> user". >> >> >>> I think we all agree that the generalized mechanism will allow >> collisions. >> >> Yes, let me clarify that sentence. The generalize mechanism will allow >> collisions in the username part of the URI, i.e., with two different >> domains. This means: there are collisions for UI rendering, but there >> aren't collisions for routing private messages. >> >>> Let's see if we can agree on when these happen: >>> 1. Two users with externally defined nicknames, where the domains are >>> different >> Yes, no problem. In this case, we have the UI rendering collision, but >> no the routing of private messages problem. >> >>> 2. Two users request the same nickname from the local server >> This should not be allowed, because it will lead to two users with >> exactly the same byte-by-byte nickname URI, including the domain name. >> If these two users having the exactly same nickname URI are in the same >> conference, it wouldn't be possible to determine which of them is the >> legitimate recipient of a private message addressed to that nickname >> URI. I think this shouldn't be allowed. >> >>> In the hope that we all do agree, I'll press on one more (big) step. >>> >>> 3. I propose that the generalized mechanism allow an external domain to >>> permit the same nickname for multiple users, and a chat server or other >> user >>> of nicknames could allow that in a single chat/conference/whatever. I'm >> not >>> sure that a domain who registers nicknames will have a policy that does >>> permit it, but I don't see a fundamental reason why we would accept two >>> users with the same nicknames in the local domain, but not two users >> with >>> the same nicknames from an external domain. To make either work, >> somehow, a >>> URI has to be minted that is unique. We don't have to specify how to do >>> that yet, but a parameter on the URI is one way that would work. >> I don't think we should go into that direction. Permanent nicknames >> should be exclusively allocated to a given user. Otherwise people are >> going to get very confuse when they see joebob@example.com in a >> conference, send him a private message, and then realize is a different >> person from the joebob@example.com they previously messaged. >> >> I think allowing non-exclusive access to nicknames would be like issuing >> shared e-mail addresses. Can you imagine if br@brianrosen.net is shared >> by you, Paul, Hisham, and me? It would be fun though.... >> >> >> /Miguel >>> I'm going to pause to see if we agree or don't. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Tuesday, August 07, 2007 8:02 PM >>>> To: Brian Rosen >>>> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' >>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>> >>>> >>>> >>>> Brian Rosen wrote: >>>>> Inline >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>> Sent: Tuesday, August 07, 2007 5:20 PM >>>>>> To: Brian Rosen >>>>>> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' >>>>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >>>>>> >>>>>> >>>>>> >>>>>> Brian Rosen wrote: >>>>>>> I think this leads to users not understanding why their nicknames >> work >>>>>>> sometimes and not others: >>>>>>> >>>>>>> Example 1: >>>>>>> My nickname is joebob. Your nickname is joebob. Neither of us is >>>>>>> registered. >>>>>> Neither of us "has" the nickname joebob. We both *want* the nickname >>>>>> joebob in the scope of this conference. >>>>>> >>>>>>> We both ask the chat server to give us joebob. I get there >>>>>>> first, and you get an error. >>>>>> We both wanted it, and one of us won. What do you *want* to happen? >>>>> I want an error, especially in msrp-chat declared nicknames >>>> OK. That helps. But then I think your desires are inconsistent, or else >>>> I don't understand what you are saying. >>>> >>>> I'm saying that the *clients* of this server must be prepared for the >>>> case where the server supports the more general mechanism, where some >>>> participants may have nicknames in some other domain, and ones with >>>> identical names but different domains. This is so even though it might >>>> not be possible for that to arise using only the MSRP mechanism. >>>> >>>>>> The conf server could hand out two nicknames that are both joebob in >>>>>> different domains that the server controls, if it wants to do that. >> It >>>>>> depends on what its policy is for duplicates. >>>>> Not in msrp-chat nicknames. Yes, if that is its policy in the >>>> generalized >>>>> mechanism. The generalized mechanism needs a way to have unambiguous >>>> URIs >>>>> if it has a policy of allowing collisions on nicknames. >>>> OK, if you want to make that rule for the msrp mechanism, then that is >>>> ok, so long as you then only allow one request for a given nickname to >>>> succeed at any given time. (Which I now see you do want.) >>>> >>>>>>> Example 2: >>>>>>> My nickname is joebob. Your nickname is joebob. I am registered at >>>>>> some >>>>>>> other domain. We both ask the chat server to give us joebob. I get >>>>>> there >>>>>>> first, but this time it works for you. >>>>>> In that case you *do* *have* the nickname joebob in some domain. Its >>>>>> more than a wish. So this isn't surprising. >>>>> It is surprising to the user, who doesn't understand the difference >>>> Users already must understand the difference between permanently >> signing >>>> up for a nickname vs not doing that and just trying to get one when >> they >>>> enter a chat. This is not unfamiliar. >>>> >>>> And if you want, you can make a rule that an msrp nickname request will >>>> always fail if there is already someone in the chat using an external >>>> nickname that "clashes". BUT, that isn't a complete solution unless you >>>> also prevent anyone using an external nickname from later joining the >>>> chat if their nickname clashes. While you *could* do that I think it >>>> would be a bad way forward. >>>> >>>> As long as the UIs are prepared for this from day 1 I think the users >>>> will cope. >>>> >>>>>> Are you assuming that anyone can ask for any nickname from any >> server, >>>>>> and always get it, even if someone else also has the same nickname >> from >>>>>> the same server? If so, the protocol and the UI can't distinguish >> them >>>>>> and I can't selectively send to one or the other. I find that >> entirely >>>>>> unacceptable. >>>>> I am not assuming that. I am assuming that if the policy for >> nicknames >>>> is >>>>> that collisions are allowed, that a collision exists whether the >> domain >>>> of >>>>> the nickname is the same or different as long as the nickname itself >> is >>>> the >>>>> same. >>>>> If the policy is that collisions are not allowed then two users >>>> requesting >>>>> the same nickname that happen to have different domains would be >>>> rejected >>>>> with an error. >>>> I think there is some confusion here. There is requesting to have a >>>> nickname *assigned* to you within some scope/domain, when it otherwise >>>> wasn't, and there is requesting to *use* a nickname in a particular >>>> session. The msrp method does both, binding the scope/domain of the >>>> assignment to the session you are establishing. >>>> >>>> There can be collision on assignment, and there can be collision on >> use. >>>> And there can be collision on the name+domain or on just the name. >>>> >>>> I believe the policy you are suggesting applies to collision on just >>>> names, for *use*, not assignment. I agree you can go either way on >> that, >>>> though it will ultimately be an annoying system if it forbids it. >>>> >>>> For assignment we always allow collision on names if the domains are >>>> different - that is the point, and there is no way to forbid it if the >>>> assignment is administered independently per domain. >>>> >>>> For assignment collision on name+domain is probably a bad idea, unless >>>> the entities doing the requesting are really the same in some sense. If >>>> they are then there probably aren't multiple assignments. So I think >>>> this is a non-issue. >>>> >>>> Collision on use at the name+domain level must be carefully controlled >>>> or users of the system will not be able to make any sense of it. I >> think >>>> the same name+domain can be used for multiple sessions with the focus >>>> *if* all the sessions belong to the same user, whatever that means. Its >>>> probably easy if they authenticate with the same credentials. Otherwise >>>> not. >>>> >>>>> Of course, it would also reject, with the same error, if the domains >>>> were >>>>> the same, >>>> I think you are saying what I said in last paragraph above. >>>> >>>>> specifically if they were requested from the using domain (the >>>>> chat server). This would always be the case in an msrp-chat nickname >>>>> declaration because I want this mechanism to always disallow >> collisions. >>>> I'm not sure if we are agreeing or not. >>>> >>>>>>> You would have to know that I registered my nick somewhere else, so >> my >>>>>> URI >>>>>>> is unique, to know why you got an error in the first example, but >>>> didn't >>>>>> in >>>>>>> the second. Normally, the URI isn't visible to the users, only the >>>>>> names >>>>>>> are. >>>>>> This would be no different than me being the 2nd user rather than the >>>>>> first to show up. >>>>>> >>>>>> You think this is unacceptable, but I find it way more acceptable >> than >>>>>> not being able to discriminate between two distinct joebobs. >>>>> I think if collisions are allowed, collisions exist if the nicknames >> are >>>> the >>>>> same, and the mechanism must provide a way to construct a unique URI. >>>> If >>>>> the domains are different, then it's easy. If the domains are the >> same, >>>>> more work is needed. >>>> If you want to use something other than domain for further >>>> discrimination (e.g. an URI parameter), for the msrp case, then I can >>>> probably live with that, pending the details. >>>> >>>>>> As I said above, if you want more-or-less this behavior then we must >>>>>> allow the MSRP server to accept multiple requests for nickname joebob >>>>>> and give them *different* URIs in return. >>>>> Yes, I agree with this, but only in the case of the generalized >>>> mechanism, >>>>> where the policy of the chat server (which is could mint nicknames >> using >>>> the >>>>> generalized mechanism) was to allow collisions. >>>> Again I don't know if we are agreeing or disagreeing. >>>> >>>>>>> If you allow a nickname collision, you incur costs at both the >> server >>>>>> and >>>>>>> the clients. You can't avoid them. Collision really is the name; >> the >>>>>>> domain MAY help you, but since it can't fix the whole problem, it >>>> isn't >>>>>>> useful. >>>>>>> >>>>>>> Note that we are discussing the generalized nickname mechanisms, not >>>> the >>>>>>> msrp-chat. We're projecting a problem onto that mechanism and >> trying >>>> to >>>>>>> solve it here. In msrp-chat, you can't have a collision. >>>>>> No. I think this is lapping over to the msrp-chat nickname issue to >>>>>> because of needing to sort out what happens when two people request >> the >>>>>> same nickname. >>>>> In msrp-chat, I want it to not be allowed. If two users request the >>>> same >>>>> nickname, I want an error on the second (and succeeding) requests. >> The >>>>> problem we are discussing: same nickname, different domains, cannot >>>> exist. >>>>> The only acceptable domain is the domain of the chat. >>>>> >>>>> >> -- >> Miguel A. Garcia tel:+358-50-4804586 >> Nokia Siemens Networks Espoo, Finland > -- 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 From simple-bounces@ietf.org Thu Aug 09 10:06:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ8cW-00023X-U3; Thu, 09 Aug 2007 10:04:12 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJ8cV-00023P-ID for simple-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 10:04:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ8cV-00023G-6w for simple@ietf.org; Thu, 09 Aug 2007 10:04:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ8cU-0004Cn-Bl for simple@ietf.org; Thu, 09 Aug 2007 10:04:11 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Aug 2007 10:04:10 -0400 X-IronPort-AV: i="4.19,240,1183348800"; d="scan'208"; a="67523867:sNHT63462336" 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 l79E4A4g006620; Thu, 9 Aug 2007 10:04:10 -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 l79E41mj013575; Thu, 9 Aug 2007 14:04:05 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); Thu, 9 Aug 2007 10:04:00 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 10:03:57 -0400 Message-ID: <46BB1ECB.7010001@cisco.com> Date: Thu, 09 Aug 2007 10:03:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> In-Reply-To: <46BB068B.9080604@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2007 14:03:57.0324 (UTC) FILETIME=[20C374C0:01C7DA8E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7984; t=1186668250; x=1187532250; 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]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20 |To:=20Miguel=20Garcia=20; bh=w3ToOim3cyV+c7lM8bNGkvNmlc1I9sftO31NNuxOPLA=; b=JC2xJgKF2hbBxxFMeexzY3AIqeA/98XvPuiQU/UQavVErXiDSljKxadEcz6ettt4PAqcO9OZ VMnfjIW/OsbFthmW5hz+zn126MbtfvmAWRV9cgiKW3lxNSiaISDW/UOu; 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: 33cc095b503da4365ce57c727e553cf1 Cc: 'Niemi Aki' , '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 There are comments inline below. But I have one general observation to make: As we discuss this I am beginning to see this as almost the same, or a very similar, problem as SIP Identity and "callerid" functionality. Namely we need for some trusted party to vouch for the claimed identity. For SIP Identity it needs to be in the signaling path. In our case we sometimes are using the focus and mixer as the trusted party, but when the identity is assigned elsewhere then we may need that to be on the path. Unfortunately, if we intend to send these identities in the msrp media stream then the trusted party may need to be on that path. But maybe not if we also trust the mixer to verify the identity with the actual trusted party. (But of course that is the transitive trust that people aren't very happy with.) Casting this as an identity problem may make it much harder to solve, but if that is what it is then there is no getting around it, and we might as well apply all the expertise available on that subject. Miguel Garcia wrote: > Inline > > Brian Rosen wrote: >> Okay, progress. Slow, but progress. >> >> Miguel, you think that there can be UI collisions. You worry that if we >> allow domain collisions, we can't create distinct URIs. >> >> I'd like to point out, as I did with Paul, that users won't really be >> aware >> of the domains. It may well be that a user registers his nick with some >> service, but the domain won't show up anywhere they can see (normally). >> Most importantly, whether I register a nick at some external domain or >> not >> shouldn't affect what YOU see. I may be aware of my nick's domain, >> but you >> are not. > > I think this is not the case, at least in e-mail clients. You can > usually see the display name (equivalent to nickname). If you hover over > the nickname, you can see the full From header. > > I was expecting similar but not exactly the same behavior in chat rooms. > The client will allocate separate identifiers to nickname collisions, > such us joebob, joebob(2), joebob(3). If the user wants to send a > private message to one of this, and it doesn't know which one is the > target, he can hover over any of them. I agree. >> This, to me, is the problem with your position on this issue. You >> want to >> not allow a local domain to have two users with the same nick, but you >> are >> okay with two users from external domains (or one internal and one >> external) >> having the same nick. You think the UI can deal with the nickname >> part, but >> you are concerned we won't have a way to create a unique URI. > > I re-read this paragraph a few times, and I think I understand you and > see where we have been disagreeing. So, let me try to clarify your words. > > Terminology: > nickname-string: refers to the visible (UI) identifier. > nickname-URI: refers to the associated URI. > nickname: not used to avoid misleading. > > So, are you saying that two users of the same domain could have the same > nickname-string but different nickname-URI? If this is possible, I don't > have any problem. This would require to add something like a unique > identifier to a each nickname-URI. > > For example: > > sip:nickname/joebob/sd098d@example.com > sip:nickname/joebob/a9xc8s@example.com > > The UI will display joebob(1) and joebob(2) in the chat room, but the > user can perhaps hover to get the full nickname-URI, or perhaps also the > SIP AoR (if available). > > I don't have a problem with this. In the past, I have been always > thinking that a nickname-string in a domain will create a unique > nickname-URI. I don't have a problem with this either. > This is becoming GRUU, by the way. > >> I think, to a user, the cases look the same, and especially to a user who >> did not register their nick with an external service, they may be able to >> get a nick with a collision sometimes (if the other guy used an external >> service) but not other times (if the other guy used the local service). >> Since the domain is normally not visible, that is poor design. >> >> I also think it's easily fixed. >> I've been thinking about this for a while now, and have come to the >> conclusion that we have made a leap of assumption we should not have >> made. >> The leap is that you construct the uri from the nickname. > > This is another possibility that we somehow explored in the past. If the > nickname-string is not connected to (and can be derived from) the > nickname-URI, it behaves essentially as a display name. The conference > event package will have to send both (which is not a problem). > > So, the linkage between nickname-URIs and nickname-strings will exist in > the chat room server only, although the endpoints will get it (mainly) > via the conference event package. They could get it otherwise. The msrp "mixer" could add the nickname (as a display name) to the From header of msrp messages when the From header contains the corresponding id. If the mixer promised to police this so that those nicknames could be trusted, then it might work out. OTOH, would it also police display names when the From of the msrp message contained an actual participant AOR rather than a nickname? I don't think it could. And the recipient can't tell the two cases apart, can it? >> Let's think about not doing that for a moment. >> >> Suppose that nicknames were associated with a URI, but the association >> was >> not a construction rule using the nickname, but rather just a URI >> minted by >> the chat server, a full fledged anonymous URI. >> >> Suppose it ALWAYS did that, i.e. the response to a Set-Nickname, whether >> using the msrp-chat mechanism or the generalized mechanism was that it >> returned an anonymous URI. >> >> Now, everything works: you always have a unique URI to use. The name >> collision can be dealt with by the UI, and it works the same way no >> matter >> what the domains the nicknames are declared in are. >> >> And Hisham's notion that maybe you can make that URI work outside the >> session could be made to work by the chat-server, if it wanted to. >> >> And to Paul's notion that only collision on use is important, it >> addresses >> that issue as well. >> >> And it gets us out of funny escaping, new parameters, and other >> weirdities >> of a construction rule > > Yeap, I think this works. I may also add one step more. We could make > the focus to create a GRUU per participant that requests a nickname. The > GRUU will resolve to the focus, but it will have a unique identifier > that is available to the user that requested it. This allows private > messaging, in and outside the conference (as per Hisham's request). > > The nickname-string is merely a display name. We have display names in > the From/To headers in CPIM. > > So, a user would send the NICKNAME method with the Set-Nickname header > set to the nickname-string: joebob. It will get back the nickname-string > plus nickname-uri, for example: > > "joebob" > > This can be used in From/To headers, or announced via the conference > event package. > > If there are several "joebob" in the same chat room, the UI will > differentiate it. But since the nickname is unique, there is no problem > to route private messages. In this approach the nickname-string is carried in the display name. But apparently it isn't policed. Which means I could request a nickname, get the corresponding URI, and then proceed to send messages using whatever nickname string I want. And I don't see how the recipient knows when a message carries a nickname, in contrast to a From in the msrp that carries the senders AOR and an arbitrary display name that wasn't intended to be a nickname. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 09 13:52: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 1IJC9b-00083J-Im; Thu, 09 Aug 2007 13:50:35 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJC9Y-0007yM-PE for simple-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 13:50:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJC9Y-0007yE-DL for simple@ietf.org; Thu, 09 Aug 2007 13:50:32 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJC9W-0001tX-8T for simple@ietf.org; Thu, 09 Aug 2007 13:50:32 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IJC8x-0006Jm-5A; Thu, 09 Aug 2007 12:49:57 -0500 From: "Brian Rosen" To: "'Brian Rosen'" , "'Paul Kyzivat'" References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com><46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com><071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com><46B88C95.60606@nsn.com><082b01c7d90a$31041540$640fa8c0@cis.neustar.com><46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com><087901c7d931$917494f0$640fa8c0@cis.neustar.com><46B8E20F.60804@cisco.com><089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com><46B907DB.8080301@cisco.com><08c901c7d953$0880f310$640fa8c0@cis.neustar.com><46B95BFF.8090304@nsn.com><094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com><46B9DE12.6090400@cisco.com> <097c01c7d9d1$b9ccafa0$640fa8c0@cis.neustar.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Thu, 9 Aug 2007 13:49:57 -0400 Message-ID: <000001c7daad$b83cacd0$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 Thread-Index: AcfZzv1UjgQ3eMaCTNGwzQ94GPEM9gAAURrQADXmEeA= In-Reply-To: <097c01c7d9d1$b9ccafa0$640fa8c0@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 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.5 (/) X-Scan-Signature: 312bb437839230b5894c6b1686dbca1d Cc: 'Miguel Garcia' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Okay, no replies. Perhaps the day job beckons. Anyway, I propose that we change the msrp-chat text on nicknames to say: Set-Nickname takes a string; the proposed nickname The response is an anonymous URI with the nickname as the display name. The URI can be used, as described, in msrp From:/To: The conference package extension includes the anonymous URI with display name. I'd actually prefer to have the conf package have the string distinct from the URI, but I would accept just using display name of the URI. I think that the msrp-chat mechanism should say explicitly that it does not support name collisions (it implies it by the errors). I think it should say that as defined in this document, the URI is only valid in the context of the chat in which it was used. Then I think the generalized mechanism basically does the same thing using a SIP header. It WILL allow collisions. It WILL allow the URI to be used outside the session, at the option of the minter. The SIP mechanism will have an AoR and a domain, which is used for validation. The Set-nickname has the optional AoR. We'll define an operation (probably not a SIP mechanism) to ask the domain if the nick is valid for that AoR. Brian > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, August 08, 2007 11:35 AM > To: 'Paul Kyzivat' > Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > Is there a reason to want a construction rule for the URI? > > The nick could be a display name on an anonymous URI. You would send a > nickname to the nick service, it would return the anonymous URI with the > display name. > > I think we have a problem in marking. How does anyone know that this is > what the URI means? Can we do this without marking the URI itself, and > know > by where it goes in various messages? > > I don't think users managing nicknames by turning on and off display of > URIs > is going to work. I don't think we NEED to cause such confusion, and I'd > prefer to not create the situation in the first place. > > Brian > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Wednesday, August 08, 2007 11:16 AM > > To: Brian Rosen > > Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > > > > > > > Brian Rosen wrote: > > > Okay, progress. Slow, but progress. > > > > > > Miguel, you think that there can be UI collisions. You worry that if > we > > > allow domain collisions, we can't create distinct URIs. > > > > > > I'd like to point out, as I did with Paul, that users won't really be > > aware > > > of the domains. It may well be that a user registers his nick with > some > > > service, but the domain won't show up anywhere they can see > (normally). > > > Most importantly, whether I register a nick at some external domain or > > not > > > shouldn't affect what YOU see. I may be aware of my nick's domain, > but > > you > > > are not. > > > > I don't agree with your assumptions. This all depends on how the UI is > > managed for the client, and is somewhat speculative because its all > > about functionality that doesn't currently exist. > > > > To use this capability you will need to register for a nickname with > > some service, and tell your IM client to use that one. Surely this will > > be apparent to the user as something different than telling the IM > > client to try to use an unregistered nickname in conferences. > > > > I would also expect that a good IM client would have a way of > > discovering the details about a participant that it doesn't display be > > default. So I should be *able* to see your domain if I ever care. > > > > This is a lot like how addresses are managed in email clients. Lots of > > clients seem to hide the actual URL by default and only show the display > > name. But typically there is a way to cause the URL to be displayed, or > > to at least query for it if you care. Some people go through life > > thinking there is only one John Smith, because they only get email from > > one. But when they reply, it is to the right one. > > > > > This, to me, is the problem with your position on this issue. You > want > > to > > > not allow a local domain to have two users with the same nick, but you > > are > > > okay with two users from external domains (or one internal and one > > external) > > > having the same nick. You think the UI can deal with the nickname > part, > > but > > > you are concerned we won't have a way to create a unique URI. > > > > I think you are mixing up "domain" and "nickname assignment service". A > > single nickname assignment service, whether an independent entity or > > part of a conference focus, can potentially allow collisions on the name > > part of a nickname URI by assigning URIs that are distinct in some other > > part of the URI, whether that be by using two domain names, or by adding > > a parameter, or whatever. > > > > So if two users both want to be joebob in a conference with focus > > sip:chatter@atlanta.com, then one possibility might be: > > - sip:joebob/chatter@atlanta.com;user=msrp-nickname > > - sip:joebob/chatter@atlanta.com;user=msrp-nickname;instance=2 > > or > > - sip:joebob/1/chatter@atlanta.com;user=msrp-nickname > > - sip:joebob/2/chatter@atlanta.com;user=msrp-nickname > > > > Of course these would require us to agree on the conventions about what > > part is typically displayed. > > > > If those two users wanted to request joebob from an independent service > > that owns domain nick.name then it could do it as: > > - sip:joebob@nick.name > > - sip:joebob@2.nick.name > > or > > - sip:joebob@1.nick.name > > - sip:joebob@2.nick.name > > or > > - sip:joebob@ma.nick.name > > - sip:joebob@pa.nick.name > > or > > - sip:joebob@nick.name;instance=1 > > - sip:joebob@nick.name;instance=2 > > > > And there are lots more possibilities. With these the display convention > > could simply be to use the username part by default, and qualify it in > > some way when there is more than one in the same conference. > > > > > I think, to a user, the cases look the same, and especially to a user > > who > > > did not register their nick with an external service, they may be able > > to > > > get a nick with a collision sometimes (if the other guy used an > external > > > service) but not other times (if the other guy used the local > service). > > > Since the domain is normally not visible, that is poor design. > > > > > > I also think it's easily fixed. > > > > > > I've been thinking about this for a while now, and have come to the > > > conclusion that we have made a leap of assumption we should not have > > made. > > > The leap is that you construct the uri from the nickname. > > > > > > Let's think about not doing that for a moment. > > > > > > Suppose that nicknames were associated with a URI, but the association > > was > > > not a construction rule using the nickname, but rather just a URI > minted > > by > > > the chat server, a full fledged anonymous URI. > > > > > > Suppose it ALWAYS did that, i.e. the response to a Set-Nickname, > whether > > > using the msrp-chat mechanism or the generalized mechanism was that it > > > returned an anonymous URI. > > > > > > Now, everything works: you always have a unique URI to use. The name > > > collision can be dealt with by the UI, and it works the same way no > > matter > > > what the domains the nicknames are declared in are. > > > > > > And Hisham's notion that maybe you can make that URI work outside the > > > session could be made to work by the chat-server, if it wanted to. > > > > > > And to Paul's notion that only collision on use is important, it > > addresses > > > that issue as well. > > > > > > And it gets us out of funny escaping, new parameters, and other > > weirdities > > > of a construction rule > > > > How is what you are suggesting different from a display name on an > > anonymous URI? > > > > It is essential that a nickname only be used when authorized. Of course > > that is the unresolved issue with externally assigned nicknames as well. > > > > This of course wouldn't be a problem if the nickname service was a full > > fledged anonymizer. When messages when through the anonymizer, the > > source address would be replaced with the nickname, and the nickname > > would be what was authorized by the recipient/focus. > > > > Paul > > > > > Brian > > > > > >> -----Original Message----- > > >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > > >> Sent: Wednesday, August 08, 2007 2:01 AM > > >> To: Brian Rosen > > >> Cc: 'Paul Kyzivat'; 'SIMPLE mailing list'; 'Niemi Aki' > > >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > >> > > >> You guys had a long discussion while I was sleeping. I'll try to get > my > > >> opinion to this e-mail. Inline. > > >> > > >> Brian Rosen wrote: > > >>> Let's break this down piece by piece, because we each don't yet > > >> understand > > >>> what the other is saying. > > >>> > > >>> I propose that msrp-chat not allow nickname collisions. If two > users > > do > > >>> Set-Nickname with the same nickname, the second gets an error. > > >> > > > >> > Do you agree to that? Miguel? > > >> > > > >> > > >> Of course. Yes. This is the current behavior. The draft defines a 423 > > >> response: "Nickname usage failed; the nickname is not allocated to > this > > >> user". > > >> > > >> > > >>> I think we all agree that the generalized mechanism will allow > > >> collisions. > > >> > > >> Yes, let me clarify that sentence. The generalize mechanism will > allow > > >> collisions in the username part of the URI, i.e., with two different > > >> domains. This means: there are collisions for UI rendering, but there > > >> aren't collisions for routing private messages. > > >> > > >>> Let's see if we can agree on when these happen: > > >>> 1. Two users with externally defined nicknames, where the domains > are > > >>> different > > >> Yes, no problem. In this case, we have the UI rendering collision, > but > > >> no the routing of private messages problem. > > >> > > >>> 2. Two users request the same nickname from the local server > > >> This should not be allowed, because it will lead to two users with > > >> exactly the same byte-by-byte nickname URI, including the domain > name. > > >> If these two users having the exactly same nickname URI are in the > same > > >> conference, it wouldn't be possible to determine which of them is the > > >> legitimate recipient of a private message addressed to that nickname > > >> URI. I think this shouldn't be allowed. > > >> > > >>> In the hope that we all do agree, I'll press on one more (big) step. > > >>> > > >>> 3. I propose that the generalized mechanism allow an external domain > > to > > >>> permit the same nickname for multiple users, and a chat server or > > other > > >> user > > >>> of nicknames could allow that in a single chat/conference/whatever. > > I'm > > >> not > > >>> sure that a domain who registers nicknames will have a policy that > > does > > >>> permit it, but I don't see a fundamental reason why we would accept > > two > > >>> users with the same nicknames in the local domain, but not two users > > >> with > > >>> the same nicknames from an external domain. To make either work, > > >> somehow, a > > >>> URI has to be minted that is unique. We don't have to specify how > to > > do > > >>> that yet, but a parameter on the URI is one way that would work. > > >> I don't think we should go into that direction. Permanent nicknames > > >> should be exclusively allocated to a given user. Otherwise people are > > >> going to get very confuse when they see joebob@example.com in a > > >> conference, send him a private message, and then realize is a > different > > >> person from the joebob@example.com they previously messaged. > > >> > > >> I think allowing non-exclusive access to nicknames would be like > > issuing > > >> shared e-mail addresses. Can you imagine if br@brianrosen.net is > shared > > >> by you, Paul, Hisham, and me? It would be fun though.... > > >> > > >> > > >> /Miguel > > >>> I'm going to pause to see if we agree or don't. > > >>> > > >>> Brian > > >>> > > >>>> -----Original Message----- > > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >>>> Sent: Tuesday, August 07, 2007 8:02 PM > > >>>> To: Brian Rosen > > >>>> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > > >>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > >>>> > > >>>> > > >>>> > > >>>> Brian Rosen wrote: > > >>>>> Inline > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >>>>>> Sent: Tuesday, August 07, 2007 5:20 PM > > >>>>>> To: Brian Rosen > > >>>>>> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > > >>>>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Brian Rosen wrote: > > >>>>>>> I think this leads to users not understanding why their > nicknames > > >> work > > >>>>>>> sometimes and not others: > > >>>>>>> > > >>>>>>> Example 1: > > >>>>>>> My nickname is joebob. Your nickname is joebob. Neither of us > is > > >>>>>>> registered. > > >>>>>> Neither of us "has" the nickname joebob. We both *want* the > > nickname > > >>>>>> joebob in the scope of this conference. > > >>>>>> > > >>>>>>> We both ask the chat server to give us joebob. I get there > > >>>>>>> first, and you get an error. > > >>>>>> We both wanted it, and one of us won. What do you *want* to > happen? > > >>>>> I want an error, especially in msrp-chat declared nicknames > > >>>> OK. That helps. But then I think your desires are inconsistent, or > > else > > >>>> I don't understand what you are saying. > > >>>> > > >>>> I'm saying that the *clients* of this server must be prepared for > the > > >>>> case where the server supports the more general mechanism, where > some > > >>>> participants may have nicknames in some other domain, and ones with > > >>>> identical names but different domains. This is so even though it > > might > > >>>> not be possible for that to arise using only the MSRP mechanism. > > >>>> > > >>>>>> The conf server could hand out two nicknames that are both joebob > > in > > >>>>>> different domains that the server controls, if it wants to do > that. > > >> It > > >>>>>> depends on what its policy is for duplicates. > > >>>>> Not in msrp-chat nicknames. Yes, if that is its policy in the > > >>>> generalized > > >>>>> mechanism. The generalized mechanism needs a way to have > > unambiguous > > >>>> URIs > > >>>>> if it has a policy of allowing collisions on nicknames. > > >>>> OK, if you want to make that rule for the msrp mechanism, then that > > is > > >>>> ok, so long as you then only allow one request for a given nickname > > to > > >>>> succeed at any given time. (Which I now see you do want.) > > >>>> > > >>>>>>> Example 2: > > >>>>>>> My nickname is joebob. Your nickname is joebob. I am > registered > > at > > >>>>>> some > > >>>>>>> other domain. We both ask the chat server to give us joebob. I > > get > > >>>>>> there > > >>>>>>> first, but this time it works for you. > > >>>>>> In that case you *do* *have* the nickname joebob in some domain. > > Its > > >>>>>> more than a wish. So this isn't surprising. > > >>>>> It is surprising to the user, who doesn't understand the > difference > > >>>> Users already must understand the difference between permanently > > >> signing > > >>>> up for a nickname vs not doing that and just trying to get one when > > >> they > > >>>> enter a chat. This is not unfamiliar. > > >>>> > > >>>> And if you want, you can make a rule that an msrp nickname request > > will > > >>>> always fail if there is already someone in the chat using an > external > > >>>> nickname that "clashes". BUT, that isn't a complete solution unless > > you > > >>>> also prevent anyone using an external nickname from later joining > the > > >>>> chat if their nickname clashes. While you *could* do that I think > it > > >>>> would be a bad way forward. > > >>>> > > >>>> As long as the UIs are prepared for this from day 1 I think the > users > > >>>> will cope. > > >>>> > > >>>>>> Are you assuming that anyone can ask for any nickname from any > > >> server, > > >>>>>> and always get it, even if someone else also has the same > nickname > > >> from > > >>>>>> the same server? If so, the protocol and the UI can't distinguish > > >> them > > >>>>>> and I can't selectively send to one or the other. I find that > > >> entirely > > >>>>>> unacceptable. > > >>>>> I am not assuming that. I am assuming that if the policy for > > >> nicknames > > >>>> is > > >>>>> that collisions are allowed, that a collision exists whether the > > >> domain > > >>>> of > > >>>>> the nickname is the same or different as long as the nickname > itself > > >> is > > >>>> the > > >>>>> same. > > >>>>> If the policy is that collisions are not allowed then two users > > >>>> requesting > > >>>>> the same nickname that happen to have different domains would be > > >>>> rejected > > >>>>> with an error. > > >>>> I think there is some confusion here. There is requesting to have a > > >>>> nickname *assigned* to you within some scope/domain, when it > > otherwise > > >>>> wasn't, and there is requesting to *use* a nickname in a particular > > >>>> session. The msrp method does both, binding the scope/domain of the > > >>>> assignment to the session you are establishing. > > >>>> > > >>>> There can be collision on assignment, and there can be collision on > > >> use. > > >>>> And there can be collision on the name+domain or on just the name. > > >>>> > > >>>> I believe the policy you are suggesting applies to collision on > just > > >>>> names, for *use*, not assignment. I agree you can go either way on > > >> that, > > >>>> though it will ultimately be an annoying system if it forbids it. > > >>>> > > >>>> For assignment we always allow collision on names if the domains > are > > >>>> different - that is the point, and there is no way to forbid it if > > the > > >>>> assignment is administered independently per domain. > > >>>> > > >>>> For assignment collision on name+domain is probably a bad idea, > > unless > > >>>> the entities doing the requesting are really the same in some > sense. > > If > > >>>> they are then there probably aren't multiple assignments. So I > think > > >>>> this is a non-issue. > > >>>> > > >>>> Collision on use at the name+domain level must be carefully > > controlled > > >>>> or users of the system will not be able to make any sense of it. I > > >> think > > >>>> the same name+domain can be used for multiple sessions with the > focus > > >>>> *if* all the sessions belong to the same user, whatever that means. > > Its > > >>>> probably easy if they authenticate with the same credentials. > > Otherwise > > >>>> not. > > >>>> > > >>>>> Of course, it would also reject, with the same error, if the > domains > > >>>> were > > >>>>> the same, > > >>>> I think you are saying what I said in last paragraph above. > > >>>> > > >>>>> specifically if they were requested from the using domain (the > > >>>>> chat server). This would always be the case in an msrp-chat > > nickname > > >>>>> declaration because I want this mechanism to always disallow > > >> collisions. > > >>>> I'm not sure if we are agreeing or not. > > >>>> > > >>>>>>> You would have to know that I registered my nick somewhere else, > > so > > >> my > > >>>>>> URI > > >>>>>>> is unique, to know why you got an error in the first example, > but > > >>>> didn't > > >>>>>> in > > >>>>>>> the second. Normally, the URI isn't visible to the users, only > > the > > >>>>>> names > > >>>>>>> are. > > >>>>>> This would be no different than me being the 2nd user rather than > > the > > >>>>>> first to show up. > > >>>>>> > > >>>>>> You think this is unacceptable, but I find it way more acceptable > > >> than > > >>>>>> not being able to discriminate between two distinct joebobs. > > >>>>> I think if collisions are allowed, collisions exist if the > nicknames > > >> are > > >>>> the > > >>>>> same, and the mechanism must provide a way to construct a unique > > URI. > > >>>> If > > >>>>> the domains are different, then it's easy. If the domains are the > > >> same, > > >>>>> more work is needed. > > >>>> If you want to use something other than domain for further > > >>>> discrimination (e.g. an URI parameter), for the msrp case, then I > can > > >>>> probably live with that, pending the details. > > >>>> > > >>>>>> As I said above, if you want more-or-less this behavior then we > > must > > >>>>>> allow the MSRP server to accept multiple requests for nickname > > joebob > > >>>>>> and give them *different* URIs in return. > > >>>>> Yes, I agree with this, but only in the case of the generalized > > >>>> mechanism, > > >>>>> where the policy of the chat server (which is could mint nicknames > > >> using > > >>>> the > > >>>>> generalized mechanism) was to allow collisions. > > >>>> Again I don't know if we are agreeing or disagreeing. > > >>>> > > >>>>>>> If you allow a nickname collision, you incur costs at both the > > >> server > > >>>>>> and > > >>>>>>> the clients. You can't avoid them. Collision really is the > name; > > >> the > > >>>>>>> domain MAY help you, but since it can't fix the whole problem, > it > > >>>> isn't > > >>>>>>> useful. > > >>>>>>> > > >>>>>>> Note that we are discussing the generalized nickname mechanisms, > > not > > >>>> the > > >>>>>>> msrp-chat. We're projecting a problem onto that mechanism and > > >> trying > > >>>> to > > >>>>>>> solve it here. In msrp-chat, you can't have a collision. > > >>>>>> No. I think this is lapping over to the msrp-chat nickname issue > to > > >>>>>> because of needing to sort out what happens when two people > request > > >> the > > >>>>>> same nickname. > > >>>>> In msrp-chat, I want it to not be allowed. If two users request > the > > >>>> same > > >>>>> nickname, I want an error on the second (and succeeding) requests. > > >> The > > >>>>> problem we are discussing: same nickname, different domains, > cannot > > >>>> exist. > > >>>>> The only acceptable domain is the domain of the chat. > > >>>>> > > >>>>> > > >> -- > > >> 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 09 14:16:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCXL-0005Bt-5h; Thu, 09 Aug 2007 14:15:07 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJCXH-0004yt-Bb for simple-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 14:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCXG-0004yh-UR; Thu, 09 Aug 2007 14:15:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJCXG-0008VX-GN; Thu, 09 Aug 2007 14:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5BBB626ED5; Thu, 9 Aug 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IJCXG-00048U-8p; Thu, 09 Aug 2007 14:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 09 Aug 2007 14:15:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xml-patch-ops-03.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors Author(s) : J. Urpalainen, et al. Filename : draft-ietf-simple-xml-patch-ops-03.txt Pages : 33 Date : 2007-8-9 Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic , and directives a set of patches can then be applied to update an existing XML document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch-ops-03.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-xml-patch-ops-03.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-xml-patch-ops-03.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-8-9135204.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xml-patch-ops-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xml-patch-ops-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-9135204.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Thu Aug 09 15:34:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJDkc-0003Kc-Ga; Thu, 09 Aug 2007 15:32:54 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJDkZ-0003Jh-Ly for simple-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 15:32:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJDkY-0003J2-TI for simple@ietf.org; Thu, 09 Aug 2007 15:32:51 -0400 Received: from dencfw1.jabber.com ([207.182.164.5] helo=wrk225.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJDkW-0002x7-BQ for simple@ietf.org; Thu, 09 Aug 2007 15:32:50 -0400 Received: from wrk225.corp.jabber.com (localhost [127.0.0.1]) by wrk225.corp.jabber.com (Postfix) with ESMTP id 48DB6639F98 for ; Thu, 9 Aug 2007 13:34:59 -0600 (MDT) Message-ID: <46BB6C62.3020404@jabber.org> Date: Thu, 09 Aug 2007 13:34:58 -0600 From: Peter Saint-Andre Organization: XMPP Standards Foundation User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: simple@ietf.org X-Enigmail-Version: 0.95.2 OpenPGP: id=7BBD0573; url=http://www.saint-andre.com/me/stpeter.asc Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Subject: [Simple] [Fwd: I-D ACTION:draft-saintandre-xmpp-simple-10.txt] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1222956619==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1222956619== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050105060001080206040607" This is a cryptographically signed message in MIME format. --------------ms050105060001080206040607 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI. -------- Original Message -------- To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 09 Aug 2007 14:15:02 -0400 Subject: I-D ACTION:draft-saintandre-xmpp-simple-10.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Basic Messaging and Presence Interworking between the Extensible Messaging and Presence Protocol (XMPP) and Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Author(s) : P. Saint-Andre, et al. Filename : draft-saintandre-xmpp-simple-10.txt Pages : 35 Date : 2007-8-9 This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of presence information and single instant messages between systems that implement the Extensible Messaging and Presence Protocol (XMPP) and those that implement the basic extensions to the Session Initiation Protocol (SIP) for instant messaging and presence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-simple-10.txt --------------ms050105060001080206040607 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGowggdSoAMCAQICAwFotjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwNzA1MTYxODMyWhcNMDgwNzA0MTYxODMyWjCBwjELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxIjAgBgNVBAoTGVhN UFAgU3RhbmRhcmRzIEZvdW5kYXRpb24xLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2Vy dGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3 DQEJARYSc3RwZXRlckBqYWJiZXIub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAoRCp9cymHb9V1L04LWCmN2wQEbHFWrmgFnAPxRVQpMsB4ifl5iYSDICmBkLINum2inq9 /+0Fz6ScCEONYC/CDOkkmLPItEDNZ0gdUd+kl+5wMPI+567ttt85ResrUAN0B/gcp+prQKxS 7uM6JcSxC0PdwrWK9pWwxPR+LveLgX9/oE9jSSy5BIQnZVgH8nhjlNMcfkTw/hVuGD/8HJFX 1MVySNt7Qy38Kc3CALmuR3ulGUkYeepGUHXj3gdITJ1CKSKCTq6hqzjTZ4m2BDAdIV4LVVlZ pH8AFs7zcl6HuQ2jLAXqBH97iSHjm5bziC9PaNmAbQkLYIPqSK46YdnSmwIDAQABo4IEeDCC BHQwDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBS08ly4gUAQeznlzuQXQlnPQN0HMTCB3QYDVR0jBIHVMIHSgBQE rNskd1NGRpZfFwFcfUJHvUgZCKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklz cmFlbDEOMAwGA1UEBxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsT EUNBIEF1dGhvcml0eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0g BIIBNzCCATMwggEvBgsrBgEEAYG1NwEBAzCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20g THRkLjADAgEBGoGNTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2Fs IExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZh aWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRd MFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4 MHYwNwYIKwYBBQUHMAGGK2h0dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3Vz ZXIvY2EwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3Mz LnVzZXIuY2EuY3J0MBEGCWCGSAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRD b20gVHJ1c3RlZCBFbWFpbCBDZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFy dGNvbS5vcmcwDQYJKoZIhvcNAQEFBQADggEBAL7ynZiQ7FHEMcQsQetYQwDHKql1d2dBtPtW YjPvU62LyZHbqFKVc2oA6rKaGBqpUKVYUyoBkfJkyAz5/YgrFufw5mnrqysjctDMKTsjdtvu NnL0pIGnvZsQhlL/sTUV/hDOBv00ypsbHXpv5YrVKpCw4Vs9rwSo/5o8f2K8dMHbNB4dv3GX JfMGQUHR/UDTiMqMOxSRAXQ6xGBwNr3zmfDys7qtgoSqy9nBy3er12WRN10jUjdJsFv11Syh 1qyRr+RH0z3Yz6gfd0tq1S9sdzDZ+hFAai3eyjKU6kNLneumEu0w1jeL9EiDRioFsEqCYTuu +c4/cvqC+T/dP89QbGowgghqMIIHUqADAgECAgMBaLYwDQYJKoZIhvcNAQEFBQAwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAzIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnMB4XDTA3MDcwNTE2MTgzMloXDTA4MDcwNDE2MTgzMlowgcIxCzAJBgNVBAYT AlVTMREwDwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQ IFN0YW5kYXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRp ZmljYXRlIE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0B CQEWEnN0cGV0ZXJAamFiYmVyLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKEQqfXMph2/VdS9OC1gpjdsEBGxxVq5oBZwD8UVUKTLAeIn5eYmEgyApgZCyDbptop6vf/t Bc+knAhDjWAvwgzpJJizyLRAzWdIHVHfpJfucDDyPueu7bbfOUXrK1ADdAf4HKfqa0CsUu7j OiXEsQtD3cK1ivaVsMT0fi73i4F/f6BPY0ksuQSEJ2VYB/J4Y5TTHH5E8P4Vbhg//ByRV9TF ckjbe0Mt/CnNwgC5rkd7pRlJGHnqRlB1494HSEydQikigk6uoas402eJtgQwHSFeC1VZWaR/ ABbO83Jeh7kNoywF6gR/e4kh45uW84gvT2jZgG0JC2CD6kiuOmHZ0psCAwEAAaOCBHgwggR0 MAwGA1UdEwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDAdBgNVHQ4EFgQUtPJcuIFAEHs55c7kF0JZz0DdBzEwgd0GA1UdIwSB1TCB0oAUBKzb JHdTRkaWXxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3Jh ZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFD QSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASC ATcwggEzMIIBLwYLKwYBBAGBtTcBAQMwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0 ZC4wAwIBARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBb MCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4Yl aHR0cDovL2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2 MDcGCCsGAQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2Vy L2NhMDsGCCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51 c2VyLmNhLmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29t IFRydXN0ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC+8p2YkOxRxDHELEHrWEMAxyqpdXdnQbT7VmIz 71Oti8mR26hSlXNqAOqymhgaqVClWFMqAZHyZMgM+f2IKxbn8OZp66srI3LQzCk7I3bb7jZy 9KSBp72bEIZS/7E1Ff4Qzgb9NMqbGx16b+WK1SqQsOFbPa8EqP+aPH9ivHTB2zQeHb9xlyXz BkFB0f1A04jKjDsUkQF0OsRgcDa985nw8rO6rYKEqsvZwct3q9dlkTddI1I3SbBb9dUsodas ka/kR9M92M+oH3dLatUvbHcw2foRQGot3soylOpDS53rphLtMNY3i/RIg0YqBbBKgmE7rvnO P3L6gvk/3T/PUGxqMYIELDCCBCgCAQEwgbcwga8xCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJ c3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBDZXJ0aWZp Y2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgRW1haWwg RnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBaLYwCQYFKw4D AhoFAKCCAkkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcw ODA5MTkzNDU4WjAjBgkqhkiG9w0BCQQxFgQUfuzwumr41sjHqrCPHT3ptQPc21kwUgYJKoZI hvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgcgGCSsGAQQBgjcQBDGBujCBtzCBrzELMAkGA1UE BhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UE CxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNz IDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNv bS5vcmcCAwFotjCBygYLKoZIhvcNAQkQAgsxgbqggbcwga8xCzAJBgNVBAYTAklMMQ8wDQYD VQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBD ZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkg RW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBaLYw DQYJKoZIhvcNAQEBBQAEggEAP3R+b2e+JrEDC5WEbW21ifXJ49QCW2vy5nnc8bJdCj34Y4ay d0TderIcHCntuf4c+2DBzJowYD0qI+kjaWgw73S73YNxvA7BKtUp96LmpAK17yxtNyfcQzEq R91Lc9T4tyZ7CIjH2/VkLcdScDb1K0lh6fpYtCiXGtM0fkvI0leL/35tG3Jlo9uOZxL1RS15 i2MMUlkjLXsR8L6IOBa+V7/FYlP7P0bRQSS7Wl95s7kAzT2mI7Rj7q4G0A4tMCyxLFmatUBv n9AWG4udM79MdWkEdE/RGzqRvk4cclEzlmCap7Bsi9wA+AeoGk4VwbVVKJATsFEE/e21rul7 zt482gAAAAAAAA== --------------ms050105060001080206040607-- --===============1222956619== 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 --===============1222956619==-- From simple-bounces@ietf.org Thu Aug 09 16:51:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJEx8-00054u-P5; Thu, 09 Aug 2007 16:49:54 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJEx7-00054o-LZ for simple-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 16:49:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJEx7-00054f-9f for simple@ietf.org; Thu, 09 Aug 2007 16:49:53 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJEx5-00082e-0W for simple@ietf.org; Thu, 09 Aug 2007 16:49:53 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IJEwl-0007O4-TW; Thu, 09 Aug 2007 15:49:33 -0500 From: "Brian Rosen" To: "'Brian Rosen'" , "'Paul Kyzivat'" References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com><46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com><071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com><46B88C95.60606@nsn.com><082b01c7d90a$31041540$640fa8c0@cis.neustar.com><46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com><087901c7d931$917494f0$640fa8c0@cis.neustar.com><46B8E20F.60804@cisco.com><089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com><46B907DB.8080301@cisco.com><08c901c7d953$0880f310$640fa8c0@cis.neustar.com><46B95BFF.8090304@nsn.com><094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com><46B9DE12.6090400@cisco.com> <097c01c7d9d1$b9ccafa0$640fa8c0@cis.neustar.com> <000001c7daad$b83cacd0$640fa8c0@cis.neustar.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Thu, 9 Aug 2007 16:49:40 -0400 Message-ID: <021501c7dac6$d0e38560$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 In-Reply-To: <000001c7daad$b83cacd0$640fa8c0@cis.neustar.com> Thread-Index: AcfZzv1UjgQ3eMaCTNGwzQ94GPEM9gAAURrQADXmEeAAB7YjUA== 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: c2c13da073bbdd073b64ce7ea2347217 Cc: 'Miguel Garcia' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org My email server was borked and I didn't get the email from Miguel and Paul, so this email is more or less not relevant any more. Brian > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, August 09, 2007 1:50 PM > To: 'Brian Rosen'; 'Paul Kyzivat' > Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > Okay, no replies. Perhaps the day job beckons. Anyway, I propose that we > change the msrp-chat text on nicknames to say: > > Set-Nickname takes a string; the proposed nickname > The response is an anonymous URI with the nickname as the display name. > > The URI can be used, as described, in msrp From:/To: > > The conference package extension includes the anonymous URI with display > name. I'd actually prefer to have the conf package have the string > distinct > from the URI, but I would accept just using display name of the URI. > > I think that the msrp-chat mechanism should say explicitly that it does > not > support name collisions (it implies it by the errors). I think it should > say that as defined in this document, the URI is only valid in the context > of the chat in which it was used. > > Then I think the generalized mechanism basically does the same thing using > a > SIP header. It WILL allow collisions. It WILL allow the URI to be used > outside the session, at the option of the minter. The SIP mechanism will > have an AoR and a domain, which is used for validation. The Set-nickname > has the optional AoR. We'll define an operation (probably not a SIP > mechanism) to ask the domain if the nick is valid for that AoR. > > Brian > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, August 08, 2007 11:35 AM > > To: 'Paul Kyzivat' > > Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > > Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > > > Is there a reason to want a construction rule for the URI? > > > > The nick could be a display name on an anonymous URI. You would send a > > nickname to the nick service, it would return the anonymous URI with the > > display name. > > > > I think we have a problem in marking. How does anyone know that this is > > what the URI means? Can we do this without marking the URI itself, and > > know > > by where it goes in various messages? > > > > I don't think users managing nicknames by turning on and off display of > > URIs > > is going to work. I don't think we NEED to cause such confusion, and > I'd > > prefer to not create the situation in the first place. > > > > Brian > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Wednesday, August 08, 2007 11:16 AM > > > To: Brian Rosen > > > Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > > > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > > > > > > > > > > > Brian Rosen wrote: > > > > Okay, progress. Slow, but progress. > > > > > > > > Miguel, you think that there can be UI collisions. You worry that > if > > we > > > > allow domain collisions, we can't create distinct URIs. > > > > > > > > I'd like to point out, as I did with Paul, that users won't really > be > > > aware > > > > of the domains. It may well be that a user registers his nick with > > some > > > > service, but the domain won't show up anywhere they can see > > (normally). > > > > Most importantly, whether I register a nick at some external domain > or > > > not > > > > shouldn't affect what YOU see. I may be aware of my nick's domain, > > but > > > you > > > > are not. > > > > > > I don't agree with your assumptions. This all depends on how the UI is > > > managed for the client, and is somewhat speculative because its all > > > about functionality that doesn't currently exist. > > > > > > To use this capability you will need to register for a nickname with > > > some service, and tell your IM client to use that one. Surely this > will > > > be apparent to the user as something different than telling the IM > > > client to try to use an unregistered nickname in conferences. > > > > > > I would also expect that a good IM client would have a way of > > > discovering the details about a participant that it doesn't display be > > > default. So I should be *able* to see your domain if I ever care. > > > > > > This is a lot like how addresses are managed in email clients. Lots of > > > clients seem to hide the actual URL by default and only show the > display > > > name. But typically there is a way to cause the URL to be displayed, > or > > > to at least query for it if you care. Some people go through life > > > thinking there is only one John Smith, because they only get email > from > > > one. But when they reply, it is to the right one. > > > > > > > This, to me, is the problem with your position on this issue. You > > want > > > to > > > > not allow a local domain to have two users with the same nick, but > you > > > are > > > > okay with two users from external domains (or one internal and one > > > external) > > > > having the same nick. You think the UI can deal with the nickname > > part, > > > but > > > > you are concerned we won't have a way to create a unique URI. > > > > > > I think you are mixing up "domain" and "nickname assignment service". > A > > > single nickname assignment service, whether an independent entity or > > > part of a conference focus, can potentially allow collisions on the > name > > > part of a nickname URI by assigning URIs that are distinct in some > other > > > part of the URI, whether that be by using two domain names, or by > adding > > > a parameter, or whatever. > > > > > > So if two users both want to be joebob in a conference with focus > > > sip:chatter@atlanta.com, then one possibility might be: > > > - sip:joebob/chatter@atlanta.com;user=msrp-nickname > > > - sip:joebob/chatter@atlanta.com;user=msrp-nickname;instance=2 > > > or > > > - sip:joebob/1/chatter@atlanta.com;user=msrp-nickname > > > - sip:joebob/2/chatter@atlanta.com;user=msrp-nickname > > > > > > Of course these would require us to agree on the conventions about > what > > > part is typically displayed. > > > > > > If those two users wanted to request joebob from an independent > service > > > that owns domain nick.name then it could do it as: > > > - sip:joebob@nick.name > > > - sip:joebob@2.nick.name > > > or > > > - sip:joebob@1.nick.name > > > - sip:joebob@2.nick.name > > > or > > > - sip:joebob@ma.nick.name > > > - sip:joebob@pa.nick.name > > > or > > > - sip:joebob@nick.name;instance=1 > > > - sip:joebob@nick.name;instance=2 > > > > > > And there are lots more possibilities. With these the display > convention > > > could simply be to use the username part by default, and qualify it in > > > some way when there is more than one in the same conference. > > > > > > > I think, to a user, the cases look the same, and especially to a > user > > > who > > > > did not register their nick with an external service, they may be > able > > > to > > > > get a nick with a collision sometimes (if the other guy used an > > external > > > > service) but not other times (if the other guy used the local > > service). > > > > Since the domain is normally not visible, that is poor design. > > > > > > > > I also think it's easily fixed. > > > > > > > > I've been thinking about this for a while now, and have come to the > > > > conclusion that we have made a leap of assumption we should not have > > > made. > > > > The leap is that you construct the uri from the nickname. > > > > > > > > Let's think about not doing that for a moment. > > > > > > > > Suppose that nicknames were associated with a URI, but the > association > > > was > > > > not a construction rule using the nickname, but rather just a URI > > minted > > > by > > > > the chat server, a full fledged anonymous URI. > > > > > > > > Suppose it ALWAYS did that, i.e. the response to a Set-Nickname, > > whether > > > > using the msrp-chat mechanism or the generalized mechanism was that > it > > > > returned an anonymous URI. > > > > > > > > Now, everything works: you always have a unique URI to use. The > name > > > > collision can be dealt with by the UI, and it works the same way no > > > matter > > > > what the domains the nicknames are declared in are. > > > > > > > > And Hisham's notion that maybe you can make that URI work outside > the > > > > session could be made to work by the chat-server, if it wanted to. > > > > > > > > And to Paul's notion that only collision on use is important, it > > > addresses > > > > that issue as well. > > > > > > > > And it gets us out of funny escaping, new parameters, and other > > > weirdities > > > > of a construction rule > > > > > > How is what you are suggesting different from a display name on an > > > anonymous URI? > > > > > > It is essential that a nickname only be used when authorized. Of > course > > > that is the unresolved issue with externally assigned nicknames as > well. > > > > > > This of course wouldn't be a problem if the nickname service was a > full > > > fledged anonymizer. When messages when through the anonymizer, the > > > source address would be replaced with the nickname, and the nickname > > > would be what was authorized by the recipient/focus. > > > > > > Paul > > > > > > > Brian > > > > > > > >> -----Original Message----- > > > >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > > > >> Sent: Wednesday, August 08, 2007 2:01 AM > > > >> To: Brian Rosen > > > >> Cc: 'Paul Kyzivat'; 'SIMPLE mailing list'; 'Niemi Aki' > > > >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > > >> > > > >> You guys had a long discussion while I was sleeping. I'll try to > get > > my > > > >> opinion to this e-mail. Inline. > > > >> > > > >> Brian Rosen wrote: > > > >>> Let's break this down piece by piece, because we each don't yet > > > >> understand > > > >>> what the other is saying. > > > >>> > > > >>> I propose that msrp-chat not allow nickname collisions. If two > > users > > > do > > > >>> Set-Nickname with the same nickname, the second gets an error. > > > >> > > > > >> > Do you agree to that? Miguel? > > > >> > > > > >> > > > >> Of course. Yes. This is the current behavior. The draft defines a > 423 > > > >> response: "Nickname usage failed; the nickname is not allocated to > > this > > > >> user". > > > >> > > > >> > > > >>> I think we all agree that the generalized mechanism will allow > > > >> collisions. > > > >> > > > >> Yes, let me clarify that sentence. The generalize mechanism will > > allow > > > >> collisions in the username part of the URI, i.e., with two > different > > > >> domains. This means: there are collisions for UI rendering, but > there > > > >> aren't collisions for routing private messages. > > > >> > > > >>> Let's see if we can agree on when these happen: > > > >>> 1. Two users with externally defined nicknames, where the domains > > are > > > >>> different > > > >> Yes, no problem. In this case, we have the UI rendering collision, > > but > > > >> no the routing of private messages problem. > > > >> > > > >>> 2. Two users request the same nickname from the local server > > > >> This should not be allowed, because it will lead to two users with > > > >> exactly the same byte-by-byte nickname URI, including the domain > > name. > > > >> If these two users having the exactly same nickname URI are in the > > same > > > >> conference, it wouldn't be possible to determine which of them is > the > > > >> legitimate recipient of a private message addressed to that > nickname > > > >> URI. I think this shouldn't be allowed. > > > >> > > > >>> In the hope that we all do agree, I'll press on one more (big) > step. > > > >>> > > > >>> 3. I propose that the generalized mechanism allow an external > domain > > > to > > > >>> permit the same nickname for multiple users, and a chat server or > > > other > > > >> user > > > >>> of nicknames could allow that in a single > chat/conference/whatever. > > > I'm > > > >> not > > > >>> sure that a domain who registers nicknames will have a policy that > > > does > > > >>> permit it, but I don't see a fundamental reason why we would > accept > > > two > > > >>> users with the same nicknames in the local domain, but not two > users > > > >> with > > > >>> the same nicknames from an external domain. To make either work, > > > >> somehow, a > > > >>> URI has to be minted that is unique. We don't have to specify how > > to > > > do > > > >>> that yet, but a parameter on the URI is one way that would work. > > > >> I don't think we should go into that direction. Permanent > nicknames > > > >> should be exclusively allocated to a given user. Otherwise people > are > > > >> going to get very confuse when they see joebob@example.com in a > > > >> conference, send him a private message, and then realize is a > > different > > > >> person from the joebob@example.com they previously messaged. > > > >> > > > >> I think allowing non-exclusive access to nicknames would be like > > > issuing > > > >> shared e-mail addresses. Can you imagine if br@brianrosen.net is > > shared > > > >> by you, Paul, Hisham, and me? It would be fun though.... > > > >> > > > >> > > > >> /Miguel > > > >>> I'm going to pause to see if we agree or don't. > > > >>> > > > >>> Brian > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > >>>> Sent: Tuesday, August 07, 2007 8:02 PM > > > >>>> To: Brian Rosen > > > >>>> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > > > >>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > > >>>> > > > >>>> > > > >>>> > > > >>>> Brian Rosen wrote: > > > >>>>> Inline > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > >>>>>> Sent: Tuesday, August 07, 2007 5:20 PM > > > >>>>>> To: Brian Rosen > > > >>>>>> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > > > >>>>>> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname > URI > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> Brian Rosen wrote: > > > >>>>>>> I think this leads to users not understanding why their > > nicknames > > > >> work > > > >>>>>>> sometimes and not others: > > > >>>>>>> > > > >>>>>>> Example 1: > > > >>>>>>> My nickname is joebob. Your nickname is joebob. Neither of > us > > is > > > >>>>>>> registered. > > > >>>>>> Neither of us "has" the nickname joebob. We both *want* the > > > nickname > > > >>>>>> joebob in the scope of this conference. > > > >>>>>> > > > >>>>>>> We both ask the chat server to give us joebob. I get there > > > >>>>>>> first, and you get an error. > > > >>>>>> We both wanted it, and one of us won. What do you *want* to > > happen? > > > >>>>> I want an error, especially in msrp-chat declared nicknames > > > >>>> OK. That helps. But then I think your desires are inconsistent, > or > > > else > > > >>>> I don't understand what you are saying. > > > >>>> > > > >>>> I'm saying that the *clients* of this server must be prepared for > > the > > > >>>> case where the server supports the more general mechanism, where > > some > > > >>>> participants may have nicknames in some other domain, and ones > with > > > >>>> identical names but different domains. This is so even though it > > > might > > > >>>> not be possible for that to arise using only the MSRP mechanism. > > > >>>> > > > >>>>>> The conf server could hand out two nicknames that are both > joebob > > > in > > > >>>>>> different domains that the server controls, if it wants to do > > that. > > > >> It > > > >>>>>> depends on what its policy is for duplicates. > > > >>>>> Not in msrp-chat nicknames. Yes, if that is its policy in the > > > >>>> generalized > > > >>>>> mechanism. The generalized mechanism needs a way to have > > > unambiguous > > > >>>> URIs > > > >>>>> if it has a policy of allowing collisions on nicknames. > > > >>>> OK, if you want to make that rule for the msrp mechanism, then > that > > > is > > > >>>> ok, so long as you then only allow one request for a given > nickname > > > to > > > >>>> succeed at any given time. (Which I now see you do want.) > > > >>>> > > > >>>>>>> Example 2: > > > >>>>>>> My nickname is joebob. Your nickname is joebob. I am > > registered > > > at > > > >>>>>> some > > > >>>>>>> other domain. We both ask the chat server to give us joebob. > I > > > get > > > >>>>>> there > > > >>>>>>> first, but this time it works for you. > > > >>>>>> In that case you *do* *have* the nickname joebob in some > domain. > > > Its > > > >>>>>> more than a wish. So this isn't surprising. > > > >>>>> It is surprising to the user, who doesn't understand the > > difference > > > >>>> Users already must understand the difference between permanently > > > >> signing > > > >>>> up for a nickname vs not doing that and just trying to get one > when > > > >> they > > > >>>> enter a chat. This is not unfamiliar. > > > >>>> > > > >>>> And if you want, you can make a rule that an msrp nickname > request > > > will > > > >>>> always fail if there is already someone in the chat using an > > external > > > >>>> nickname that "clashes". BUT, that isn't a complete solution > unless > > > you > > > >>>> also prevent anyone using an external nickname from later joining > > the > > > >>>> chat if their nickname clashes. While you *could* do that I think > > it > > > >>>> would be a bad way forward. > > > >>>> > > > >>>> As long as the UIs are prepared for this from day 1 I think the > > users > > > >>>> will cope. > > > >>>> > > > >>>>>> Are you assuming that anyone can ask for any nickname from any > > > >> server, > > > >>>>>> and always get it, even if someone else also has the same > > nickname > > > >> from > > > >>>>>> the same server? If so, the protocol and the UI can't > distinguish > > > >> them > > > >>>>>> and I can't selectively send to one or the other. I find that > > > >> entirely > > > >>>>>> unacceptable. > > > >>>>> I am not assuming that. I am assuming that if the policy for > > > >> nicknames > > > >>>> is > > > >>>>> that collisions are allowed, that a collision exists whether the > > > >> domain > > > >>>> of > > > >>>>> the nickname is the same or different as long as the nickname > > itself > > > >> is > > > >>>> the > > > >>>>> same. > > > >>>>> If the policy is that collisions are not allowed then two users > > > >>>> requesting > > > >>>>> the same nickname that happen to have different domains would be > > > >>>> rejected > > > >>>>> with an error. > > > >>>> I think there is some confusion here. There is requesting to have > a > > > >>>> nickname *assigned* to you within some scope/domain, when it > > > otherwise > > > >>>> wasn't, and there is requesting to *use* a nickname in a > particular > > > >>>> session. The msrp method does both, binding the scope/domain of > the > > > >>>> assignment to the session you are establishing. > > > >>>> > > > >>>> There can be collision on assignment, and there can be collision > on > > > >> use. > > > >>>> And there can be collision on the name+domain or on just the > name. > > > >>>> > > > >>>> I believe the policy you are suggesting applies to collision on > > just > > > >>>> names, for *use*, not assignment. I agree you can go either way > on > > > >> that, > > > >>>> though it will ultimately be an annoying system if it forbids it. > > > >>>> > > > >>>> For assignment we always allow collision on names if the domains > > are > > > >>>> different - that is the point, and there is no way to forbid it > if > > > the > > > >>>> assignment is administered independently per domain. > > > >>>> > > > >>>> For assignment collision on name+domain is probably a bad idea, > > > unless > > > >>>> the entities doing the requesting are really the same in some > > sense. > > > If > > > >>>> they are then there probably aren't multiple assignments. So I > > think > > > >>>> this is a non-issue. > > > >>>> > > > >>>> Collision on use at the name+domain level must be carefully > > > controlled > > > >>>> or users of the system will not be able to make any sense of it. > I > > > >> think > > > >>>> the same name+domain can be used for multiple sessions with the > > focus > > > >>>> *if* all the sessions belong to the same user, whatever that > means. > > > Its > > > >>>> probably easy if they authenticate with the same credentials. > > > Otherwise > > > >>>> not. > > > >>>> > > > >>>>> Of course, it would also reject, with the same error, if the > > domains > > > >>>> were > > > >>>>> the same, > > > >>>> I think you are saying what I said in last paragraph above. > > > >>>> > > > >>>>> specifically if they were requested from the using domain (the > > > >>>>> chat server). This would always be the case in an msrp-chat > > > nickname > > > >>>>> declaration because I want this mechanism to always disallow > > > >> collisions. > > > >>>> I'm not sure if we are agreeing or not. > > > >>>> > > > >>>>>>> You would have to know that I registered my nick somewhere > else, > > > so > > > >> my > > > >>>>>> URI > > > >>>>>>> is unique, to know why you got an error in the first example, > > but > > > >>>> didn't > > > >>>>>> in > > > >>>>>>> the second. Normally, the URI isn't visible to the users, > only > > > the > > > >>>>>> names > > > >>>>>>> are. > > > >>>>>> This would be no different than me being the 2nd user rather > than > > > the > > > >>>>>> first to show up. > > > >>>>>> > > > >>>>>> You think this is unacceptable, but I find it way more > acceptable > > > >> than > > > >>>>>> not being able to discriminate between two distinct joebobs. > > > >>>>> I think if collisions are allowed, collisions exist if the > > nicknames > > > >> are > > > >>>> the > > > >>>>> same, and the mechanism must provide a way to construct a unique > > > URI. > > > >>>> If > > > >>>>> the domains are different, then it's easy. If the domains are > the > > > >> same, > > > >>>>> more work is needed. > > > >>>> If you want to use something other than domain for further > > > >>>> discrimination (e.g. an URI parameter), for the msrp case, then I > > can > > > >>>> probably live with that, pending the details. > > > >>>> > > > >>>>>> As I said above, if you want more-or-less this behavior then we > > > must > > > >>>>>> allow the MSRP server to accept multiple requests for nickname > > > joebob > > > >>>>>> and give them *different* URIs in return. > > > >>>>> Yes, I agree with this, but only in the case of the generalized > > > >>>> mechanism, > > > >>>>> where the policy of the chat server (which is could mint > nicknames > > > >> using > > > >>>> the > > > >>>>> generalized mechanism) was to allow collisions. > > > >>>> Again I don't know if we are agreeing or disagreeing. > > > >>>> > > > >>>>>>> If you allow a nickname collision, you incur costs at both the > > > >> server > > > >>>>>> and > > > >>>>>>> the clients. You can't avoid them. Collision really is the > > name; > > > >> the > > > >>>>>>> domain MAY help you, but since it can't fix the whole problem, > > it > > > >>>> isn't > > > >>>>>>> useful. > > > >>>>>>> > > > >>>>>>> Note that we are discussing the generalized nickname > mechanisms, > > > not > > > >>>> the > > > >>>>>>> msrp-chat. We're projecting a problem onto that mechanism and > > > >> trying > > > >>>> to > > > >>>>>>> solve it here. In msrp-chat, you can't have a collision. > > > >>>>>> No. I think this is lapping over to the msrp-chat nickname > issue > > to > > > >>>>>> because of needing to sort out what happens when two people > > request > > > >> the > > > >>>>>> same nickname. > > > >>>>> In msrp-chat, I want it to not be allowed. If two users request > > the > > > >>>> same > > > >>>>> nickname, I want an error on the second (and succeeding) > requests. > > > >> The > > > >>>>> problem we are discussing: same nickname, different domains, > > cannot > > > >>>> exist. > > > >>>>> The only acceptable domain is the domain of the chat. > > > >>>>> > > > >>>>> > > > >> -- > > > >> 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 09 17:10: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 1IJFFI-0004hO-6I; Thu, 09 Aug 2007 17:08:40 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJFFG-0004g1-KH for simple-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 17:08:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJFFG-0004fY-82 for simple@ietf.org; Thu, 09 Aug 2007 17:08:38 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJFFF-0008Va-4u for simple@ietf.org; Thu, 09 Aug 2007 17:08:38 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IJFEv-00019U-Fb; Thu, 09 Aug 2007 16:08:19 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" , "'Miguel Garcia'" References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Thu, 9 Aug 2007 17:08:26 -0400 Message-ID: <021601c7dac9$707165f0$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 In-Reply-To: <46BB1ECB.7010001@cisco.com> Thread-Index: AcfajiS+BIBDpyEDRHWd/uvZix+jNwAOKwoA 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: ed68cc91cc637fea89623888898579ba Cc: 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Only the generalized mechanism has a validity problem. We need an AoR or other URI specified in the generalized "Set-Nickname" along with the domain of the nickname service. The validation operation asks the domain to validate that it assigned the nickname to someone with that URI. I don't think we loop the SIP signaling through the nickname service. I think we use a non-sip mechanism for validation. I think that using display name causes the policing problem that Paul is worried about. We could try to fix it with some spec words that says that UAs have to get nicknames from the conference event package, and not pay attention to the From:/To:. I think that way will not really work well, and I think we would be better off not making the display name of the GRUU the nickname. Just make the Set-Nickname specify a string, and the only way a UA gets the string is from the conference roster in the event package. That means Set-Nickname joebob ... Proposed-Nickname joebob sip:chat34@focus.example.com;gr=3298sd0d98s And in the event package: The generalized one would be Set-Nickname joebob joseph.robert.smith@example.com nicks.example.com with the same return. I guess I can live with having the msrp mechanism handle collisions. I'd rather make this a feature of the generalized system and keep the msrp system simple, but I think there is a problem with backwards compatibility with that: the conference server would have to know that all participants in a conference were able to handle the generalized mechanism before it allowed a conflict. But of course it starts handing out nicknames before it knows that. If we require all UIs to handle collisions from day 1, we don't have that problem. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, August 09, 2007 10:04 AM > To: Miguel Garcia > Cc: Brian Rosen; 'SIMPLE mailing list'; 'Niemi Aki' > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > There are comments inline below. But I have one general observation to > make: > > As we discuss this I am beginning to see this as almost the same, or a > very similar, problem as SIP Identity and "callerid" functionality. > Namely we need for some trusted party to vouch for the claimed identity. > For SIP Identity it needs to be in the signaling path. In our case we > sometimes are using the focus and mixer as the trusted party, but when > the identity is assigned elsewhere then we may need that to be on the > path. Unfortunately, if we intend to send these identities in the msrp > media stream then the trusted party may need to be on that path. But > maybe not if we also trust the mixer to verify the identity with the > actual trusted party. (But of course that is the transitive trust that > people aren't very happy with.) > > Casting this as an identity problem may make it much harder to solve, > but if that is what it is then there is no getting around it, and we > might as well apply all the expertise available on that subject. > > Miguel Garcia wrote: > > Inline > > > > Brian Rosen wrote: > >> Okay, progress. Slow, but progress. > >> > >> Miguel, you think that there can be UI collisions. You worry that if > we > >> allow domain collisions, we can't create distinct URIs. > >> > >> I'd like to point out, as I did with Paul, that users won't really be > >> aware > >> of the domains. It may well be that a user registers his nick with > some > >> service, but the domain won't show up anywhere they can see (normally). > >> Most importantly, whether I register a nick at some external domain or > >> not > >> shouldn't affect what YOU see. I may be aware of my nick's domain, > >> but you > >> are not. > > > > I think this is not the case, at least in e-mail clients. You can > > usually see the display name (equivalent to nickname). If you hover over > > the nickname, you can see the full From header. > > > > I was expecting similar but not exactly the same behavior in chat rooms. > > The client will allocate separate identifiers to nickname collisions, > > such us joebob, joebob(2), joebob(3). If the user wants to send a > > private message to one of this, and it doesn't know which one is the > > target, he can hover over any of them. > > I agree. > > >> This, to me, is the problem with your position on this issue. You > >> want to > >> not allow a local domain to have two users with the same nick, but you > >> are > >> okay with two users from external domains (or one internal and one > >> external) > >> having the same nick. You think the UI can deal with the nickname > >> part, but > >> you are concerned we won't have a way to create a unique URI. > > > > I re-read this paragraph a few times, and I think I understand you and > > see where we have been disagreeing. So, let me try to clarify your > words. > > > > Terminology: > > nickname-string: refers to the visible (UI) identifier. > > nickname-URI: refers to the associated URI. > > nickname: not used to avoid misleading. > > > > So, are you saying that two users of the same domain could have the same > > nickname-string but different nickname-URI? If this is possible, I don't > > have any problem. This would require to add something like a unique > > identifier to a each nickname-URI. > > > > For example: > > > > sip:nickname/joebob/sd098d@example.com > > sip:nickname/joebob/a9xc8s@example.com > > > > The UI will display joebob(1) and joebob(2) in the chat room, but the > > user can perhaps hover to get the full nickname-URI, or perhaps also the > > SIP AoR (if available). > > > > I don't have a problem with this. In the past, I have been always > > thinking that a nickname-string in a domain will create a unique > > nickname-URI. > > I don't have a problem with this either. > > > This is becoming GRUU, by the way. > > > >> I think, to a user, the cases look the same, and especially to a user > who > >> did not register their nick with an external service, they may be able > to > >> get a nick with a collision sometimes (if the other guy used an > external > >> service) but not other times (if the other guy used the local service). > >> Since the domain is normally not visible, that is poor design. > >> > >> I also think it's easily fixed. > >> I've been thinking about this for a while now, and have come to the > >> conclusion that we have made a leap of assumption we should not have > >> made. > >> The leap is that you construct the uri from the nickname. > > > > This is another possibility that we somehow explored in the past. If the > > nickname-string is not connected to (and can be derived from) the > > nickname-URI, it behaves essentially as a display name. The conference > > event package will have to send both (which is not a problem). > > > > So, the linkage between nickname-URIs and nickname-strings will exist in > > the chat room server only, although the endpoints will get it (mainly) > > via the conference event package. > > They could get it otherwise. The msrp "mixer" could add the nickname (as > a display name) to the From header of msrp messages when the From header > contains the corresponding id. > > If the mixer promised to police this so that those nicknames could be > trusted, then it might work out. OTOH, would it also police display > names when the From of the msrp message contained an actual participant > AOR rather than a nickname? I don't think it could. And the recipient > can't tell the two cases apart, can it? > > >> Let's think about not doing that for a moment. > >> > >> Suppose that nicknames were associated with a URI, but the association > >> was > >> not a construction rule using the nickname, but rather just a URI > >> minted by > >> the chat server, a full fledged anonymous URI. > >> > >> Suppose it ALWAYS did that, i.e. the response to a Set-Nickname, > whether > >> using the msrp-chat mechanism or the generalized mechanism was that it > >> returned an anonymous URI. > >> > >> Now, everything works: you always have a unique URI to use. The name > >> collision can be dealt with by the UI, and it works the same way no > >> matter > >> what the domains the nicknames are declared in are. > >> > >> And Hisham's notion that maybe you can make that URI work outside the > >> session could be made to work by the chat-server, if it wanted to. > >> > >> And to Paul's notion that only collision on use is important, it > >> addresses > >> that issue as well. > >> > >> And it gets us out of funny escaping, new parameters, and other > >> weirdities > >> of a construction rule > > > > Yeap, I think this works. I may also add one step more. We could make > > the focus to create a GRUU per participant that requests a nickname. The > > GRUU will resolve to the focus, but it will have a unique identifier > > that is available to the user that requested it. This allows private > > messaging, in and outside the conference (as per Hisham's request). > > > > The nickname-string is merely a display name. We have display names in > > the From/To headers in CPIM. > > > > So, a user would send the NICKNAME method with the Set-Nickname header > > set to the nickname-string: joebob. It will get back the nickname-string > > plus nickname-uri, for example: > > > > "joebob" > > > > This can be used in From/To headers, or announced via the conference > > event package. > > > > If there are several "joebob" in the same chat room, the UI will > > differentiate it. But since the nickname is unique, there is no problem > > to route private messages. > > In this approach the nickname-string is carried in the display name. But > apparently it isn't policed. Which means I could request a nickname, get > the corresponding URI, and then proceed to send messages using whatever > nickname string I want. > > And I don't see how the recipient knows when a message carries a > nickname, in contrast to a From in the msrp that carries the senders AOR > and an arbitrary display name that wasn't intended to be a nickname. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 09 17:53: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 1IJFuq-00050p-C6; Thu, 09 Aug 2007 17:51:36 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJFuo-0004vw-2i for simple-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 17:51:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJFun-0004tq-Mf for simple@ietf.org; Thu, 09 Aug 2007 17:51:33 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJFum-0006k3-3O for simple@ietf.org; Thu, 09 Aug 2007 17:51:33 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 09 Aug 2007 14:51:31 -0700 X-IronPort-AV: i="4.19,243,1183359600"; d="scan'208"; a="197471510:sNHT74194983" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l79LpV0k005152; Thu, 9 Aug 2007 14:51:31 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l79LpQiH016830; Thu, 9 Aug 2007 21:51:31 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); Thu, 9 Aug 2007 17:51:30 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 17:51:29 -0400 Message-ID: <46BB8C63.1050100@cisco.com> Date: Thu, 09 Aug 2007 17:51:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> In-Reply-To: <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2007 21:51:29.0538 (UTC) FILETIME=[712F9E20:01C7DACF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13531; t=1186696291; x=1187560291; c=relaxed/simple; s=sjdkim3002; 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]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20; bh=xH4tC8r7E3WsjAnppADYHpCcGzbiO8z1Hk2jto+/rjk=; b=g8IEICdja3OQdZq91ZShbnvODl/igvA1p+ZoYLtwy+stYTQiZ2IyFfASsVYBJVCHq7QZWJyI Xm26Rx3ueWSjH72leYLfye2Crde6np1hQwQOUiHujJ4sVkyE6xoIUMuy; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: 'Miguel Garcia' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I think we might be getting close! Brian Rosen wrote: > Only the generalized mechanism has a validity problem. We need an AoR or > other URI specified in the generalized "Set-Nickname" along with the domain > of the nickname service. The validation operation asks the domain to > validate that it assigned the nickname to someone with that URI. > I don't think we loop the SIP signaling through the nickname service. I > think we use a non-sip mechanism for validation. That works as long as we accept that nicknames are only usable through a conference focus. While it might be nice to go beyond that it seems a reasonable restriction. It also means that you trust the conference focus to properly represent the identities. But if you are using a conference server with a star architecture then you already trust it, so there is no extra loss here. > I think that using display name causes the policing problem that Paul is > worried about. Yes. > We could try to fix it with some spec words that says that > UAs have to get nicknames from the conference event package, and not pay > attention to the From:/To:. I think that way will not really work well, and > I think we would be better off not making the display name of the GRUU the > nickname. Just make the Set-Nickname specify a string, and the only way a > UA gets the string is from the conference roster in the event package. That solves the problem. It does however impose the limitation that even with msrp-only conferences that are being addressed here it will still be necessary to use the conf event package. Is that ok? > That means > Set-Nickname joebob > > ... > Proposed-Nickname joebob sip:chat34@focus.example.com;gr=3298sd0d98s Note that this approach opens the possibility of separating nicknames and anonymity, which I think is an excellent thing. If you want anonymity, then request that the focus assign you an anonymous URI (which can be a gruu it constructs). You could then use that instead of your actual address. If you want to use a nickname, then simply ask to use your chosen nickname within the conference. If it is accepted then it will be made available in the conf event package. You could use an anonymous URI, a nickname, both, or neither. There will be many circumstances when using nicknames without anonymity is desirable. Separating them will require some added syntax. > And in the event package: > > > The generalized one would be > Set-Nickname joebob joseph.robert.smith@example.com nicks.example.com So "nicks.example.com" is the nickname service? and joseph.robert.smith@example.com is the AOR bound to the nickname? I don't see why you need to provide the AOR in this request. It will need to be provided by the focus when it requests verification from nicks.example.com. But the AOR it provides must be the identity it authenticated you with when you connect to the focus. So it is presumably your sip From address or perhaps the P-Asserted-Identity, depending on the authentication mechanism in use. IMO it might as well just be Set-Nickname joebob or Set-Nickname joebob@nicks.example.com The first form means you want to focus to use a service of its choice, and do an assignment as well as a verification, while the second form says you only want it to do a verification at the specified domain. And of course there is no reason why we couldn't allow both forms in MSRP as well. (The server can reject the request with a domain if it doesn't accept that form, or if it doesn't know how to verify with that domain.) With anonymity, as well, the syntax might be: Set-Nickname joebob;anonymous or Set-Nickname joebob@nicks.example.com;anonymous And I guess you would get the URI via the conf event package too. But I'm not remembering how anonymity works in the conf event package now. As I recall, there is some way to be anonymous, which I guess means no URI is visible for me in the conf event package. But in that case what shows up in the From in MSRP? Maybe one of you who knows more about the conf framework can better suggest how to separate these. > with the same return. > > I guess I can live with having the msrp mechanism handle collisions. I'd > rather make this a feature of the generalized system and keep the msrp > system simple, but I think there is a problem with backwards compatibility > with that: the conference server would have to know that all participants in > a conference were able to handle the generalized mechanism before it allowed > a conflict. But of course it starts handing out nicknames before it knows > that. If we require all UIs to handle collisions from day 1, we don't have > that problem. Right. The backward compatibility is the killer. We have the opportunity to avoid the problem now. Thanks, Paul > Brian > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, August 09, 2007 10:04 AM >> To: Miguel Garcia >> Cc: Brian Rosen; 'SIMPLE mailing list'; 'Niemi Aki' >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >> >> There are comments inline below. But I have one general observation to >> make: >> >> As we discuss this I am beginning to see this as almost the same, or a >> very similar, problem as SIP Identity and "callerid" functionality. >> Namely we need for some trusted party to vouch for the claimed identity. >> For SIP Identity it needs to be in the signaling path. In our case we >> sometimes are using the focus and mixer as the trusted party, but when >> the identity is assigned elsewhere then we may need that to be on the >> path. Unfortunately, if we intend to send these identities in the msrp >> media stream then the trusted party may need to be on that path. But >> maybe not if we also trust the mixer to verify the identity with the >> actual trusted party. (But of course that is the transitive trust that >> people aren't very happy with.) >> >> Casting this as an identity problem may make it much harder to solve, >> but if that is what it is then there is no getting around it, and we >> might as well apply all the expertise available on that subject. >> >> Miguel Garcia wrote: >>> Inline >>> >>> Brian Rosen wrote: >>>> Okay, progress. Slow, but progress. >>>> >>>> Miguel, you think that there can be UI collisions. You worry that if >> we >>>> allow domain collisions, we can't create distinct URIs. >>>> >>>> I'd like to point out, as I did with Paul, that users won't really be >>>> aware >>>> of the domains. It may well be that a user registers his nick with >> some >>>> service, but the domain won't show up anywhere they can see (normally). >>>> Most importantly, whether I register a nick at some external domain or >>>> not >>>> shouldn't affect what YOU see. I may be aware of my nick's domain, >>>> but you >>>> are not. >>> I think this is not the case, at least in e-mail clients. You can >>> usually see the display name (equivalent to nickname). If you hover over >>> the nickname, you can see the full From header. >>> >>> I was expecting similar but not exactly the same behavior in chat rooms. >>> The client will allocate separate identifiers to nickname collisions, >>> such us joebob, joebob(2), joebob(3). If the user wants to send a >>> private message to one of this, and it doesn't know which one is the >>> target, he can hover over any of them. >> I agree. >> >>>> This, to me, is the problem with your position on this issue. You >>>> want to >>>> not allow a local domain to have two users with the same nick, but you >>>> are >>>> okay with two users from external domains (or one internal and one >>>> external) >>>> having the same nick. You think the UI can deal with the nickname >>>> part, but >>>> you are concerned we won't have a way to create a unique URI. >>> I re-read this paragraph a few times, and I think I understand you and >>> see where we have been disagreeing. So, let me try to clarify your >> words. >>> Terminology: >>> nickname-string: refers to the visible (UI) identifier. >>> nickname-URI: refers to the associated URI. >>> nickname: not used to avoid misleading. >>> >>> So, are you saying that two users of the same domain could have the same >>> nickname-string but different nickname-URI? If this is possible, I don't >>> have any problem. This would require to add something like a unique >>> identifier to a each nickname-URI. >>> >>> For example: >>> >>> sip:nickname/joebob/sd098d@example.com >>> sip:nickname/joebob/a9xc8s@example.com >>> >>> The UI will display joebob(1) and joebob(2) in the chat room, but the >>> user can perhaps hover to get the full nickname-URI, or perhaps also the >>> SIP AoR (if available). >>> >>> I don't have a problem with this. In the past, I have been always >>> thinking that a nickname-string in a domain will create a unique >>> nickname-URI. >> I don't have a problem with this either. >> >>> This is becoming GRUU, by the way. >>> >>>> I think, to a user, the cases look the same, and especially to a user >> who >>>> did not register their nick with an external service, they may be able >> to >>>> get a nick with a collision sometimes (if the other guy used an >> external >>>> service) but not other times (if the other guy used the local service). >>>> Since the domain is normally not visible, that is poor design. >>>> >>>> I also think it's easily fixed. >>>> I've been thinking about this for a while now, and have come to the >>>> conclusion that we have made a leap of assumption we should not have >>>> made. >>>> The leap is that you construct the uri from the nickname. >>> This is another possibility that we somehow explored in the past. If the >>> nickname-string is not connected to (and can be derived from) the >>> nickname-URI, it behaves essentially as a display name. The conference >>> event package will have to send both (which is not a problem). >>> >>> So, the linkage between nickname-URIs and nickname-strings will exist in >>> the chat room server only, although the endpoints will get it (mainly) >>> via the conference event package. >> They could get it otherwise. The msrp "mixer" could add the nickname (as >> a display name) to the From header of msrp messages when the From header >> contains the corresponding id. >> >> If the mixer promised to police this so that those nicknames could be >> trusted, then it might work out. OTOH, would it also police display >> names when the From of the msrp message contained an actual participant >> AOR rather than a nickname? I don't think it could. And the recipient >> can't tell the two cases apart, can it? >> >>>> Let's think about not doing that for a moment. >>>> >>>> Suppose that nicknames were associated with a URI, but the association >>>> was >>>> not a construction rule using the nickname, but rather just a URI >>>> minted by >>>> the chat server, a full fledged anonymous URI. >>>> >>>> Suppose it ALWAYS did that, i.e. the response to a Set-Nickname, >> whether >>>> using the msrp-chat mechanism or the generalized mechanism was that it >>>> returned an anonymous URI. >>>> >>>> Now, everything works: you always have a unique URI to use. The name >>>> collision can be dealt with by the UI, and it works the same way no >>>> matter >>>> what the domains the nicknames are declared in are. >>>> >>>> And Hisham's notion that maybe you can make that URI work outside the >>>> session could be made to work by the chat-server, if it wanted to. >>>> >>>> And to Paul's notion that only collision on use is important, it >>>> addresses >>>> that issue as well. >>>> >>>> And it gets us out of funny escaping, new parameters, and other >>>> weirdities >>>> of a construction rule >>> Yeap, I think this works. I may also add one step more. We could make >>> the focus to create a GRUU per participant that requests a nickname. The >>> GRUU will resolve to the focus, but it will have a unique identifier >>> that is available to the user that requested it. This allows private >>> messaging, in and outside the conference (as per Hisham's request). >>> >>> The nickname-string is merely a display name. We have display names in >>> the From/To headers in CPIM. >>> >>> So, a user would send the NICKNAME method with the Set-Nickname header >>> set to the nickname-string: joebob. It will get back the nickname-string >>> plus nickname-uri, for example: >>> >>> "joebob" >>> >>> This can be used in From/To headers, or announced via the conference >>> event package. >>> >>> If there are several "joebob" in the same chat room, the UI will >>> differentiate it. But since the nickname is unique, there is no problem >>> to route private messages. >> In this approach the nickname-string is carried in the display name. But >> apparently it isn't policed. Which means I could request a nickname, get >> the corresponding URI, and then proceed to send messages using whatever >> nickname string I want. >> >> And I don't see how the recipient knows when a message carries a >> nickname, in contrast to a From in the msrp that carries the senders AOR >> and an arbitrary display name that wasn't intended to be a nickname. >> >> Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 09 20:21: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 1IJIER-0003yW-6w; Thu, 09 Aug 2007 20:19:59 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJIEP-0003x0-1I for simple-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 20:19:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJIEO-0003wr-Lh for simple@ietf.org; Thu, 09 Aug 2007 20:19:56 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJIEN-000254-Av for simple@ietf.org; Thu, 09 Aug 2007 20:19:56 -0400 Received: by py-out-1112.google.com with SMTP id f31so1974121pyh for ; Thu, 09 Aug 2007 17:19:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=YEhcRgtML2SpRISS6t69Hyn4xum2NzzgGNbClV2d0JfCFIEcn1Gs3VPo2CWbPaCEEFfZr5YopqlMe2EvK73RpQ0vQM/twfvIzQphKcOIvRt+bM/5pKWRk18niRZ5F6TkgeHJLm42urxWbqJ43mK0jdHrzpvyd98SvTV8fVKHXTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=eh4kufTYSddf1oGI/Eny9BABqw0FLVa7DLQhVascfaQDmh4B0KA9fTYcpTTHYKUH73JLQjw+nZOq/xxZqSBX94lzeNwLwROUNzkt+1AvVgiesn+x5w8ppvoLDIoNIkw0k+uQgZEVkye+FDPn+08r4VpUdfQzGZzUHGDYOCqkIzc= Received: by 10.65.155.19 with SMTP id h19mr4036043qbo.1186705194399; Thu, 09 Aug 2007 17:19:54 -0700 (PDT) Received: by 10.65.126.19 with HTTP; Thu, 9 Aug 2007 17:19:54 -0700 (PDT) Message-ID: <66cd252f0708091719i76286a54h7ec8c1a3517b9d82@mail.gmail.com> Date: Fri, 10 Aug 2007 10:19:54 +1000 From: "Hisham Khartabil" To: "Brian Rosen" Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI In-Reply-To: <66cd252f0708091701p398c08d6ved2205d0558e37ac@mail.gmail.com> MIME-Version: 1.0 References: <46ADDC1E.10301@nsn.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46B9DE12.6090400@cisco.com> <097c01c7d9d1$b9ccafa0$640fa8c0@cis.neustar.com> <66cd252f0708091701p398c08d6ved2205d0558e37ac@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Paul Kyzivat , Miguel Garcia , SIMPLE mailing list , Niemi Aki X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1334567162==" Errors-To: simple-bounces@ietf.org --===============1334567162== Content-Type: multipart/alternative; boundary="----=_Part_7859_8464134.1186705194284" ------=_Part_7859_8464134.1186705194284 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline (apologies if you get a duplicate of this email. The first one got held up for moderator approval due to size of email) I think I'm ok with this. I have one suggestion regarding scope. To keep things simple for MSRP, can we keep external nickname assignment out? For MSRP, I think having the chat server itself assign nicknames for now is good enough. If you want to join a chatroom, you have create a nickname within that chatroom domain. For the general mechanism that Brian is working on, we can tackle external nickname service issues. What do you guys think? Hisham - Hide quoted text - On 09/08/07, Brian Rosen wrote: > > Is there a reason to want a construction rule for the URI? > > The nick could be a display name on an anonymous URI. You would send a > nickname to the nick service, it would return the anonymous URI with the > display name. > > I think we have a problem in marking. How does anyone know that this is > what the URI means? Can we do this without marking the URI itself, and > know > by where it goes in various messages? > > I don't think users managing nicknames by turning on and off display of > URIs > is going to work. I don't think we NEED to cause such confusion, and I'd > prefer to not create the situation in the first place. > > Brian ------=_Part_7859_8464134.1186705194284 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
(apologies if you get a duplicate of this email. The first one got held up for moderator approval due to size of email)
 
I think I'm ok with this.
 
I have one suggestion regarding scope. To keep things simple for MSRP, can we keep external nickname assignment out? For MSRP, I think having the chat server itself assign nicknames for now is good enough. If you want to join a chatroom, you have create a nickname within that chatroom domain.
 
For the general mechanism that Brian is working on, we can tackle external nickname service issues.
 
What do you guys think?

Hisham
- Hide quoted text -
 
On 09/08/07, Brian Rosen <br@brianrosen.net> wrote:
Is there a reason to want a construction rule for the URI?

The nick could be a display name on an anonymous URI.  You would send a
nickname to the nick service, it would return the anonymous URI with the
display name.

I think we have a problem in marking.  How does anyone know that this is
what the URI means?  Can we do this without marking the URI itself, and know
by where it goes in various messages?

I don't think users managing nicknames by turning on and off display of URIs
is going to work.  I don't think we NEED to cause such confusion, and I'd
prefer to not create the situation in the first place.

Brian


------=_Part_7859_8464134.1186705194284-- --===============1334567162== 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 --===============1334567162==-- From simple-bounces@ietf.org Thu Aug 09 20:48: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 1IJIeP-0003ar-4U; Thu, 09 Aug 2007 20:46:49 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJIeO-0003am-2O for simple-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 20:46:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJIeN-0003ae-Mw for simple@ietf.org; Thu, 09 Aug 2007 20:46:47 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJIeM-0006RG-5j for simple@ietf.org; Thu, 09 Aug 2007 20:46:47 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IJIe1-0003yX-7b; Thu, 09 Aug 2007 19:46:26 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Thu, 9 Aug 2007 20:46:36 -0400 Message-ID: <023f01c7dae7$ea328b30$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 In-Reply-To: <46BB8C63.1050100@cisco.com> Thread-Index: Acfaz21J09YWmmwlRb+VTiuxjG+YOgAAkOhQ 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: 58b614506802734014829a093beb6879 Cc: 'Miguel Garcia' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org In line. Indeed we may be close. Need to hear from Miguel. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, August 09, 2007 5:52 PM > To: Brian Rosen > Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > I think we might be getting close! > > Brian Rosen wrote: > > Only the generalized mechanism has a validity problem. We need an AoR > or > > other URI specified in the generalized "Set-Nickname" along with the > domain > > of the nickname service. The validation operation asks the domain to > > validate that it assigned the nickname to someone with that URI. > > I don't think we loop the SIP signaling through the nickname service. I > > think we use a non-sip mechanism for validation. > > That works as long as we accept that nicknames are only usable through a > conference focus. While it might be nice to go beyond that it seems a > reasonable restriction. It also means that you trust the conference > focus to properly represent the identities. But if you are using a > conference server with a star architecture then you already trust it, so > there is no extra loss here. Well, it can also work in a simple two way call if that is interesting. It could also work with a PUBLISH for presence if that was interesting I think your point is that if someone needs to see the nickname, either the UA asserting the Set-Nickname has to be sending it to the entity that needs it, or something like the conference package has to be available to get it. I think that is okay. > > > I think that using display name causes the policing problem that Paul is > > worried about. > > Yes. > > > We could try to fix it with some spec words that says that > > UAs have to get nicknames from the conference event package, and not pay > > attention to the From:/To:. I think that way will not really work well, > and > > I think we would be better off not making the display name of the GRUU > the > > nickname. Just make the Set-Nickname specify a string, and the only way > a > > UA gets the string is from the conference roster in the event package. > > That solves the problem. It does however impose the limitation that even > with msrp-only conferences that are being addressed here it will still > be necessary to use the conf event package. Is that ok? See above. You can use it directly, or with conf event, or something similar, and I am okay with it. > > > That means > > Set-Nickname joebob > > > > ... > > Proposed-Nickname joebob sip:chat34@focus.example.com;gr=3298sd0d98s > > Note that this approach opens the possibility of separating nicknames > and anonymity, which I think is an excellent thing. > > If you want anonymity, then request that the focus assign you an > anonymous URI (which can be a gruu it constructs). You could then use > that instead of your actual address. > > If you want to use a nickname, then simply ask to use your chosen > nickname within the conference. If it is accepted then it will be made > available in the conf event package. Sure. > > You could use an anonymous URI, a nickname, both, or neither. There will > be many circumstances when using nicknames without anonymity is desirable. Agree > > Separating them will require some added syntax. Okay. > > > And in the event package: > > > > > > The generalized one would be > > Set-Nickname joebob joseph.robert.smith@example.com nicks.example.com > > So "nicks.example.com" is the nickname service? and > joseph.robert.smith@example.com is the AOR bound to the nickname? Yes > > I don't see why you need to provide the AOR in this request. It will > need to be provided by the focus when it requests verification from > nicks.example.com. But the AOR it provides must be the identity it > authenticated you with when you connect to the focus. So it is > presumably your sip From address or perhaps the P-Asserted-Identity, > depending on the authentication mechanism in use. I'm not sure that will always work. Suppose, for example, that the AoR you use in your From: is what you registered your nick with. Let's say the service you send your INVITE to the conference with adds a P-A-I and it's different in some way from the registered URI. The conference server would have to know to use From: and not P-A-I to validate. If you specify to the conference server what the URI is registered under, it can make a policy decision if it will accept that. Without being explicit, it would have to do something like try both of them and see if one worked. Yuck. > > IMO it might as well just be > > Set-Nickname joebob > or Set-Nickname joebob@nicks.example.com > > The first form means you want to focus to use a service of its choice, > and do an assignment as well as a verification, while the second form > says you only want it to do a verification at the specified domain. > > And of course there is no reason why we couldn't allow both forms in > MSRP as well. (The server can reject the request with a domain if it > doesn't accept that form, or if it doesn't know how to verify with that > domain.) I'd prefer to make that an extension to the MSRP mechanism rather than defined in msrp chat. I don't want to hold up msrp-chat while we figure out the validation mechanism. > > With anonymity, as well, the syntax might be: > > Set-Nickname joebob;anonymous > or Set-Nickname joebob@nicks.example.com;anonymous > > And I guess you would get the URI via the conf event package too. I'm okay with the anonymous, and I agree you get the URI with the conf event package > > But I'm not remembering how anonymity works in the conf event package > now. As I recall, there is some way to be anonymous, which I guess means > no URI is visible for me in the conf event package. But in that case > what shows up in the From in MSRP? RFC4575 says the URI is an actual anonymous URI (sip:anonymousX@anonymous.invalid). > > Maybe one of you who knows more about the conf framework can better > suggest how to separate these. xcon-framework doesn't add anything to this. > > > with the same return. > > > > I guess I can live with having the msrp mechanism handle collisions. > I'd > > rather make this a feature of the generalized system and keep the msrp > > system simple, but I think there is a problem with backwards > compatibility > > with that: the conference server would have to know that all > participants in > > a conference were able to handle the generalized mechanism before it > allowed > > a conflict. But of course it starts handing out nicknames before it > knows > > that. If we require all UIs to handle collisions from day 1, we don't > have > > that problem. > > Right. The backward compatibility is the killer. We have the opportunity > to avoid the problem now. > > Thanks, > Paul > > > Brian > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Thursday, August 09, 2007 10:04 AM > >> To: Miguel Garcia > >> Cc: Brian Rosen; 'SIMPLE mailing list'; 'Niemi Aki' > >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > >> > >> There are comments inline below. But I have one general observation to > >> make: > >> > >> As we discuss this I am beginning to see this as almost the same, or a > >> very similar, problem as SIP Identity and "callerid" functionality. > >> Namely we need for some trusted party to vouch for the claimed > identity. > >> For SIP Identity it needs to be in the signaling path. In our case we > >> sometimes are using the focus and mixer as the trusted party, but when > >> the identity is assigned elsewhere then we may need that to be on the > >> path. Unfortunately, if we intend to send these identities in the msrp > >> media stream then the trusted party may need to be on that path. But > >> maybe not if we also trust the mixer to verify the identity with the > >> actual trusted party. (But of course that is the transitive trust that > >> people aren't very happy with.) > >> > >> Casting this as an identity problem may make it much harder to solve, > >> but if that is what it is then there is no getting around it, and we > >> might as well apply all the expertise available on that subject. > >> > >> Miguel Garcia wrote: > >>> Inline > >>> > >>> Brian Rosen wrote: > >>>> Okay, progress. Slow, but progress. > >>>> > >>>> Miguel, you think that there can be UI collisions. You worry that if > >> we > >>>> allow domain collisions, we can't create distinct URIs. > >>>> > >>>> I'd like to point out, as I did with Paul, that users won't really be > >>>> aware > >>>> of the domains. It may well be that a user registers his nick with > >> some > >>>> service, but the domain won't show up anywhere they can see > (normally). > >>>> Most importantly, whether I register a nick at some external domain > or > >>>> not > >>>> shouldn't affect what YOU see. I may be aware of my nick's domain, > >>>> but you > >>>> are not. > >>> I think this is not the case, at least in e-mail clients. You can > >>> usually see the display name (equivalent to nickname). If you hover > over > >>> the nickname, you can see the full From header. > >>> > >>> I was expecting similar but not exactly the same behavior in chat > rooms. > >>> The client will allocate separate identifiers to nickname collisions, > >>> such us joebob, joebob(2), joebob(3). If the user wants to send a > >>> private message to one of this, and it doesn't know which one is the > >>> target, he can hover over any of them. > >> I agree. > >> > >>>> This, to me, is the problem with your position on this issue. You > >>>> want to > >>>> not allow a local domain to have two users with the same nick, but > you > >>>> are > >>>> okay with two users from external domains (or one internal and one > >>>> external) > >>>> having the same nick. You think the UI can deal with the nickname > >>>> part, but > >>>> you are concerned we won't have a way to create a unique URI. > >>> I re-read this paragraph a few times, and I think I understand you and > >>> see where we have been disagreeing. So, let me try to clarify your > >> words. > >>> Terminology: > >>> nickname-string: refers to the visible (UI) identifier. > >>> nickname-URI: refers to the associated URI. > >>> nickname: not used to avoid misleading. > >>> > >>> So, are you saying that two users of the same domain could have the > same > >>> nickname-string but different nickname-URI? If this is possible, I > don't > >>> have any problem. This would require to add something like a unique > >>> identifier to a each nickname-URI. > >>> > >>> For example: > >>> > >>> sip:nickname/joebob/sd098d@example.com > >>> sip:nickname/joebob/a9xc8s@example.com > >>> > >>> The UI will display joebob(1) and joebob(2) in the chat room, but the > >>> user can perhaps hover to get the full nickname-URI, or perhaps also > the > >>> SIP AoR (if available). > >>> > >>> I don't have a problem with this. In the past, I have been always > >>> thinking that a nickname-string in a domain will create a unique > >>> nickname-URI. > >> I don't have a problem with this either. > >> > >>> This is becoming GRUU, by the way. > >>> > >>>> I think, to a user, the cases look the same, and especially to a user > >> who > >>>> did not register their nick with an external service, they may be > able > >> to > >>>> get a nick with a collision sometimes (if the other guy used an > >> external > >>>> service) but not other times (if the other guy used the local > service). > >>>> Since the domain is normally not visible, that is poor design. > >>>> > >>>> I also think it's easily fixed. > >>>> I've been thinking about this for a while now, and have come to the > >>>> conclusion that we have made a leap of assumption we should not have > >>>> made. > >>>> The leap is that you construct the uri from the nickname. > >>> This is another possibility that we somehow explored in the past. If > the > >>> nickname-string is not connected to (and can be derived from) the > >>> nickname-URI, it behaves essentially as a display name. The conference > >>> event package will have to send both (which is not a problem). > >>> > >>> So, the linkage between nickname-URIs and nickname-strings will exist > in > >>> the chat room server only, although the endpoints will get it (mainly) > >>> via the conference event package. > >> They could get it otherwise. The msrp "mixer" could add the nickname > (as > >> a display name) to the From header of msrp messages when the From > header > >> contains the corresponding id. > >> > >> If the mixer promised to police this so that those nicknames could be > >> trusted, then it might work out. OTOH, would it also police display > >> names when the From of the msrp message contained an actual participant > >> AOR rather than a nickname? I don't think it could. And the recipient > >> can't tell the two cases apart, can it? > >> > >>>> Let's think about not doing that for a moment. > >>>> > >>>> Suppose that nicknames were associated with a URI, but the > association > >>>> was > >>>> not a construction rule using the nickname, but rather just a URI > >>>> minted by > >>>> the chat server, a full fledged anonymous URI. > >>>> > >>>> Suppose it ALWAYS did that, i.e. the response to a Set-Nickname, > >> whether > >>>> using the msrp-chat mechanism or the generalized mechanism was that > it > >>>> returned an anonymous URI. > >>>> > >>>> Now, everything works: you always have a unique URI to use. The name > >>>> collision can be dealt with by the UI, and it works the same way no > >>>> matter > >>>> what the domains the nicknames are declared in are. > >>>> > >>>> And Hisham's notion that maybe you can make that URI work outside the > >>>> session could be made to work by the chat-server, if it wanted to. > >>>> > >>>> And to Paul's notion that only collision on use is important, it > >>>> addresses > >>>> that issue as well. > >>>> > >>>> And it gets us out of funny escaping, new parameters, and other > >>>> weirdities > >>>> of a construction rule > >>> Yeap, I think this works. I may also add one step more. We could make > >>> the focus to create a GRUU per participant that requests a nickname. > The > >>> GRUU will resolve to the focus, but it will have a unique identifier > >>> that is available to the user that requested it. This allows private > >>> messaging, in and outside the conference (as per Hisham's request). > >>> > >>> The nickname-string is merely a display name. We have display names in > >>> the From/To headers in CPIM. > >>> > >>> So, a user would send the NICKNAME method with the Set-Nickname header > >>> set to the nickname-string: joebob. It will get back the nickname- > string > >>> plus nickname-uri, for example: > >>> > >>> "joebob" > >>> > >>> This can be used in From/To headers, or announced via the conference > >>> event package. > >>> > >>> If there are several "joebob" in the same chat room, the UI will > >>> differentiate it. But since the nickname is unique, there is no > problem > >>> to route private messages. > >> In this approach the nickname-string is carried in the display name. > But > >> apparently it isn't policed. Which means I could request a nickname, > get > >> the corresponding URI, and then proceed to send messages using whatever > >> nickname string I want. > >> > >> And I don't see how the recipient knows when a message carries a > >> nickname, in contrast to a From in the msrp that carries the senders > AOR > >> and an arbitrary display name that wasn't intended to be a nickname. > >> > >> Paul > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 10 01:49: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 1IJNLG-0004nD-T6; Fri, 10 Aug 2007 01:47:22 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJNLF-0004lE-3V for simple-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 01:47:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJNLE-0004l6-GG for simple@ietf.org; Fri, 10 Aug 2007 01:47:20 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJNLD-0005oQ-WA for simple@ietf.org; Fri, 10 Aug 2007 01:47:20 -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 l7A5kfsR019542; Fri, 10 Aug 2007 08:47:11 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 08:47:09 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 08:47:09 +0300 Received: from [10.144.23.148] ([10.144.23.148]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 08:47:08 +0300 Message-ID: <46BBFBDC.60509@nsn.com> Date: Fri, 10 Aug 2007 08:47:08 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> In-Reply-To: <46BB8C63.1050100@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2007 05:47:08.0851 (UTC) FILETIME=[E3F13030:01C7DB11] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 'Niemi Aki' , '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 Paul Kyzivat wrote: > But I'm not remembering how anonymity works in the conf event package > now. As I recall, there is some way to be anonymous, which I guess means > no URI is visible for me in the conf event package. But in that case > what shows up in the From in MSRP? > > Maybe one of you who knows more about the conf framework can better > suggest how to separate these. > The answer is in RFC 4579: A focus MUST support a participant's request for privacy, either through conference policy or as expressed through the signaling. For example, a participant joining a conference and including a Privacy header field [10] must not have identity information revealed to other participants by the focus. If other signaling protocols are used, privacy signaled through them also must be respected. So, if the UA sends an INVITE with Privacy: id, then the focus MUST not disclose the SIP AoR through the conference event package. /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 From simple-bounces@ietf.org Fri Aug 10 01:50: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 1IJNMg-0005lV-Ur; Fri, 10 Aug 2007 01:48:50 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJNMg-0005iy-2i for simple-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 01:48:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJNMf-0005il-Dr for simple@ietf.org; Fri, 10 Aug 2007 01:48:49 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJNMe-0005r6-Tr for simple@ietf.org; Fri, 10 Aug 2007 01:48:49 -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 l7A5mMqN020806; Fri, 10 Aug 2007 08:48:43 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 08:48:40 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 08:48:39 +0300 Received: from [10.144.23.148] ([10.144.23.148]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 08:48:39 +0300 Message-ID: <46BBFC37.2050005@nsn.com> Date: Fri, 10 Aug 2007 08:48:39 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com><66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com><46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> In-Reply-To: <46BB8C63.1050100@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2007 05:48:39.0585 (UTC) FILETIME=[1A061910:01C7DB12] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 'Niemi Aki' , '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 Paul Kyzivat wrote: > I think we might be getting close! > > Brian Rosen wrote: >> I guess I can live with having the msrp mechanism handle collisions. I'd >> rather make this a feature of the generalized system and keep the msrp >> system simple, but I think there is a problem with backwards >> compatibility >> with that: the conference server would have to know that all >> participants in >> a conference were able to handle the generalized mechanism before it >> allowed >> a conflict. But of course it starts handing out nicknames before it >> knows >> that. If we require all UIs to handle collisions from day 1, we don't >> have >> that problem. > > Right. The backward compatibility is the killer. We have the opportunity > to avoid the problem now. > We also agree that endpoints need to be able prepared for handling collisions. No doubt. This will happen from day 1. /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 From simple-bounces@ietf.org Fri Aug 10 01:51: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 1IJNNf-0006cy-FR; Fri, 10 Aug 2007 01:49:51 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJNNe-0006cb-En for simple-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 01:49:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJNNe-0006cJ-4s for simple@ietf.org; Fri, 10 Aug 2007 01:49:50 -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 1IJNNc-0001AV-KL for simple@ietf.org; Fri, 10 Aug 2007 01:49:50 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7A5ncIY024775; Fri, 10 Aug 2007 08:49:41 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 08:49:32 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 08:49:32 +0300 Received: from [10.144.23.148] ([10.144.23.148]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 08:49:31 +0300 Message-ID: <46BBFC6B.9050901@nsn.com> Date: Fri, 10 Aug 2007 08:49:31 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46B9DE12.6090400@cisco.com> <097c01c7d9d1$b9ccafa0$640fa8c0@cis.neustar.com> <66cd252f0708091701p398c08d6ved2205d0558e37ac@mail.gmail.com> In-Reply-To: <66cd252f0708091701p398c08d6ved2205d0558e37ac@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2007 05:49:31.0725 (UTC) FILETIME=[391A07D0:01C7DB12] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Paul Kyzivat , Niemi Aki , 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 Khartabil wrote: > I think I'm ok with this. > > I have one suggestion regarding scope. To keep things simple for MSRP, > can we keep external nickname assignment out? For MSRP, I think having > the chat server itself assign nicknames for now is good enough. If you > want to join a chatroom, you have create a nickname within that chatroom > domain. > > For the general mechanism that Brian is working on, we can tackle > external nickname service issues. > > What do you guys think? > Yes, agreed. This has always been the assumption. /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 From simple-bounces@ietf.org Fri Aug 10 02:26: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 1IJNv3-00047T-D0; Fri, 10 Aug 2007 02:24:21 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJNv1-00047H-DB for simple-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 02:24:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJNv1-000479-1t for simple@ietf.org; Fri, 10 Aug 2007 02:24:19 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJNuz-0006mq-NL for simple@ietf.org; Fri, 10 Aug 2007 02:24:18 -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 l7A6O1Sh018867; Fri, 10 Aug 2007 09:24:10 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 09:24:02 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 09:24:02 +0300 Received: from [10.144.23.148] ([10.144.23.148]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 09:24:02 +0300 Message-ID: <46BC0482.6080401@nsn.com> Date: Fri, 10 Aug 2007 09:24:02 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> In-Reply-To: <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2007 06:24:02.0399 (UTC) FILETIME=[0B51CEF0:01C7DB17] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: 'Paul Kyzivat' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I think I am ok with Brian's e-mail below. To summarize, for people who are bored of following the discussion, and to confirm myself, I believe we agreed: For the MSRP reduced scope (only nicknames resolved to the conference focus). Let's analyzed the simplest sunny case: a) Setting the nickname: - The NICKNAME method is the mechanism to bind a nickname-string with a temporary SIP GRUU allocated by the conference server. - The NICKNAME method contains a Set-Nickname header - The Set-Nickname header contains the requested nickname-string. Example: Set-Nickname: joebob - The focus/mixer assigns a GRUU which is valid for the duration of the conference. The GRUU resolves to the conference focus and obfuscates the SIP AoR of the user. - The 200 OK for the NICKNAME method contains a header, perhaps Nickname, that contains the assigned URI (GRUU). Perhaps something like this: Nickname: joebob b) Learning participant's nicknames - The focus disseminates the nickname (string and URI) in the conference event package. We spoke about separated elements. - Endpoints need to be ready to receive collisions in nickname-strings c) Using the nickname: - From and To headers in CPIM can contain nickname URIs. They never carry nickname-strings, which are only bound at the endpoints and the conference server. - Side effect: It is also possible to use the nickname URI outside the conference, for example, in a MESSAGE, while the user is participating on it. I thought a bit about the anonymity parameter in the Set-Nickname, but I think it is not required for MSRP chat, but just for the generalized mechanism. The reason: the returned nickname-URI (GRUU) is always anonymous, at least, you cannot derive the SIP AoR out of it. The user selects the nickname-string, so he can set any random string, if he wants to remain discontinued from being "joebob". Comments? /Miguel Brian Rosen wrote: > In line. Indeed we may be close. Need to hear from Miguel. > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, August 09, 2007 5:52 PM >> To: Brian Rosen >> Cc: 'Miguel Garcia'; 'SIMPLE mailing list'; 'Niemi Aki' >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >> >> I think we might be getting close! >> >> Brian Rosen wrote: >>> Only the generalized mechanism has a validity problem. We need an AoR >> or >>> other URI specified in the generalized "Set-Nickname" along with the >> domain >>> of the nickname service. The validation operation asks the domain to >>> validate that it assigned the nickname to someone with that URI. >>> I don't think we loop the SIP signaling through the nickname service. I >>> think we use a non-sip mechanism for validation. >> That works as long as we accept that nicknames are only usable through a >> conference focus. While it might be nice to go beyond that it seems a >> reasonable restriction. It also means that you trust the conference >> focus to properly represent the identities. But if you are using a >> conference server with a star architecture then you already trust it, so >> there is no extra loss here. > Well, it can also work in a simple two way call if that is interesting. > It could also work with a PUBLISH for presence if that was interesting > I think your point is that if someone needs to see the nickname, either the > UA asserting the Set-Nickname has to be sending it to the entity that needs > it, or something like the conference package has to be available to get it. > I think that is okay. > >>> I think that using display name causes the policing problem that Paul is >>> worried about. >> Yes. >> >>> We could try to fix it with some spec words that says that >>> UAs have to get nicknames from the conference event package, and not pay >>> attention to the From:/To:. I think that way will not really work well, >> and >>> I think we would be better off not making the display name of the GRUU >> the >>> nickname. Just make the Set-Nickname specify a string, and the only way >> a >>> UA gets the string is from the conference roster in the event package. >> That solves the problem. It does however impose the limitation that even >> with msrp-only conferences that are being addressed here it will still >> be necessary to use the conf event package. Is that ok? > See above. You can use it directly, or with conf event, or something > similar, and I am okay with it. >>> That means >>> Set-Nickname joebob >>> >>> ... >>> Proposed-Nickname joebob sip:chat34@focus.example.com;gr=3298sd0d98s >> Note that this approach opens the possibility of separating nicknames >> and anonymity, which I think is an excellent thing. >> >> If you want anonymity, then request that the focus assign you an >> anonymous URI (which can be a gruu it constructs). You could then use >> that instead of your actual address. >> >> If you want to use a nickname, then simply ask to use your chosen >> nickname within the conference. If it is accepted then it will be made >> available in the conf event package. > Sure. > >> You could use an anonymous URI, a nickname, both, or neither. There will >> be many circumstances when using nicknames without anonymity is desirable. > Agree >> Separating them will require some added syntax. > Okay. > >>> And in the event package: >>> >>> >>> The generalized one would be >>> Set-Nickname joebob joseph.robert.smith@example.com nicks.example.com >> So "nicks.example.com" is the nickname service? and >> joseph.robert.smith@example.com is the AOR bound to the nickname? > Yes > >> I don't see why you need to provide the AOR in this request. It will >> need to be provided by the focus when it requests verification from >> nicks.example.com. But the AOR it provides must be the identity it >> authenticated you with when you connect to the focus. So it is >> presumably your sip From address or perhaps the P-Asserted-Identity, >> depending on the authentication mechanism in use. > I'm not sure that will always work. Suppose, for example, that the AoR you > use in your From: is what you registered your nick with. Let's say the > service you send your INVITE to the conference with adds a P-A-I and it's > different in some way from the registered URI. The conference server would > have to know to use From: and not P-A-I to validate. If you specify to the > conference server what the URI is registered under, it can make a policy > decision if it will accept that. Without being explicit, it would have to > do something like try both of them and see if one worked. Yuck. > >> IMO it might as well just be >> >> Set-Nickname joebob >> or Set-Nickname joebob@nicks.example.com >> >> The first form means you want to focus to use a service of its choice, >> and do an assignment as well as a verification, while the second form >> says you only want it to do a verification at the specified domain. >> >> And of course there is no reason why we couldn't allow both forms in >> MSRP as well. (The server can reject the request with a domain if it >> doesn't accept that form, or if it doesn't know how to verify with that >> domain.) > I'd prefer to make that an extension to the MSRP mechanism rather than > defined in msrp chat. I don't want to hold up msrp-chat while we figure out > the validation mechanism. > >> With anonymity, as well, the syntax might be: >> >> Set-Nickname joebob;anonymous >> or Set-Nickname joebob@nicks.example.com;anonymous >> >> And I guess you would get the URI via the conf event package too. > I'm okay with the anonymous, and I agree you get the URI with the conf event > package > >> But I'm not remembering how anonymity works in the conf event package >> now. As I recall, there is some way to be anonymous, which I guess means >> no URI is visible for me in the conf event package. But in that case >> what shows up in the From in MSRP? > RFC4575 says the URI is an actual anonymous URI > (sip:anonymousX@anonymous.invalid). >> Maybe one of you who knows more about the conf framework can better >> suggest how to separate these. > xcon-framework doesn't add anything to this. > >>> with the same return. >>> >>> I guess I can live with having the msrp mechanism handle collisions. >> I'd >>> rather make this a feature of the generalized system and keep the msrp >>> system simple, but I think there is a problem with backwards >> compatibility >>> with that: the conference server would have to know that all >> participants in >>> a conference were able to handle the generalized mechanism before it >> allowed >>> a conflict. But of course it starts handing out nicknames before it >> knows >>> that. If we require all UIs to handle collisions from day 1, we don't >> have >>> that problem. >> Right. The backward compatibility is the killer. We have the opportunity >> to avoid the problem now. >> >> Thanks, >> Paul >> >>> Brian >>> >>> -- 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 From simple-bounces@ietf.org Fri Aug 10 02:58:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJOQk-00007e-Cr; Fri, 10 Aug 2007 02:57:06 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJOQj-00007Z-5M for simple-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 02:57:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJOQf-0008S2-F8 for simple@ietf.org; Fri, 10 Aug 2007 02:57:01 -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 1IJOQd-0002iZ-Qt for simple@ietf.org; Fri, 10 Aug 2007 02:57:01 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7A6uga8008234; Fri, 10 Aug 2007 09:56:51 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 09:56:44 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 09:56:44 +0300 Received: from [172.21.41.68] ([172.21.41.68]) by esebe106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 09:56:43 +0300 Message-ID: <46BC0C2B.5080000@nokia.com> Date: Fri, 10 Aug 2007 09:56:43 +0300 From: Aki Niemi Organization: Nokia User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com> In-Reply-To: <46BC0482.6080401@nsn.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2007 06:56:43.0852 (UTC) FILETIME=[9C6FC8C0:01C7DB1B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: 'Paul Kyzivat' , '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 Inline. Miguel Garcia wrote: > I think I am ok with Brian's e-mail below. To summarize, for people who > are bored of following the discussion, and to confirm myself, I believe > we agreed: > > > For the MSRP reduced scope (only nicknames resolved to the conference > focus). Let's analyzed the simplest sunny case: > > a) Setting the nickname: > > - The NICKNAME method is the mechanism to bind a nickname-string with a > temporary SIP GRUU allocated by the conference server. > - The NICKNAME method contains a Set-Nickname header > - The Set-Nickname header contains the requested nickname-string. Example: > > Set-Nickname: joebob > > - The focus/mixer assigns a GRUU which is valid for the duration of the > conference. The GRUU resolves to the conference focus and obfuscates the > SIP AoR of the user. > > - The 200 OK for the NICKNAME method contains a header, perhaps > Nickname, that contains the assigned URI (GRUU). Perhaps something like > this: > > Nickname: joebob ?? So why the heck would the user even bother with the NICKNAME method, if it anyway ends up getting a GRUU from the focus. I see we're now back to using display-names as nicks... That is not how the rest of the world works. Sorry. > b) Learning participant's nicknames > > - The focus disseminates the nickname (string and URI) in the conference > event package. We spoke about separated elements. > > - Endpoints need to be ready to receive collisions in nickname-strings Don't agree. I don't think it is at all reasonable to assume UIs handle collisions like this, i.e., that you don't require nicks to be unique. First, I saw someone suggest a UI could show as a popup the URI if one hovers over the roster. With what do you hover over a URI if all you have is a 12-keypad and two softbuttons? Second, are users immediately supposed to see that and are indeed a different user, although both have "joebob" as display name? Excuse me, but only geeks handle hex that well. Third, doing automatic suffixes like joebob(2) and so on will just create nonsense as soon as someone sets their display name as joebob(2). And I don't even want to go into explaining how some UTF-8 strings look the same when aren't. > c) Using the nickname: > > - From and To headers in CPIM can contain nickname URIs. They never > carry nickname-strings, which are only bound at the endpoints and the > conference server. Why? > - Side effect: It is also possible to use the nickname URI outside the > conference, for example, in a MESSAGE, while the user is participating > on it. This doesn't depend on whether the URI is a simple: or some GRUU. > I thought a bit about the anonymity parameter in the Set-Nickname, but I > think it is not required for MSRP chat, but just for the generalized > mechanism. The reason: the returned nickname-URI (GRUU) is always > anonymous, at least, you cannot derive the SIP AoR out of it. The user > selects the nickname-string, so he can set any random string, if he > wants to remain discontinued from being "joebob". Again, that's not a nickname any more. Please take a look at XMPP MUC or IRC as a reference of what a nickname is. As interesting as it may be to reinvent wheels, the SIMPLE WG is about 20 years late in this field. I think it's a bit too late to rethink the essence of the nickname. One key decision we would however need to reach is whether a nick is scoped to a chatroom or the chat server. XMPP seems to have the former model, whereas IRC has the latter. I have no idea what model we have here. My proposal: Nicknames are *always* scoped to the conference server (like in IRC). Nicks are reserved so that the server enforces uniqueness. (In fact, it can even enforce its own policies, like disallowing nicknames that look too similar. Some systems do that today.) The nickname is a simple string (SIP URI userpart ABNF production rule), and each participant is accessible from the outside as well, using the nick in the userpart of the chat server URI, e.g.: There is no such thing as an external nickname. By definition, nicknames are additional handles that participants at a chat server may have. However, to gain anonymity, a user might join with an external identity as their *real* ID. For example, instead of my INVITE being from sip:aki.niemi@nokia.com, I would join as sip:AllYourChatRoomsAreBelongToUs@someserver.example.com, if the server allows it. Is there a specific reason why the above would not be acceptable? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 10 09:59:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJUzm-0008Kx-9U; Fri, 10 Aug 2007 09:57:42 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJUzl-0008Kn-CB for simple-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 09:57:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJUzl-0008Kf-2W for simple@ietf.org; Fri, 10 Aug 2007 09:57:41 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJUzj-000665-Ol for simple@ietf.org; Fri, 10 Aug 2007 09:57:41 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IJUy8-0001DZ-P7; Fri, 10 Aug 2007 08:56:01 -0500 From: "Brian Rosen" To: "'Miguel Garcia'" References: <46ADDC1E.10301@nsn.com> <46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Fri, 10 Aug 2007 09:56:04 -0400 Message-ID: <032e01c7db56$3486d330$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 In-Reply-To: <46BC0482.6080401@nsn.com> Thread-Index: AcfbFw/ZH1d9afW2TxOYNztPcLp2vwAPE6+w 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: b7b9551d71acde901886cc48bfc088a6 Cc: 'Paul Kyzivat' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org In line. We're not quite there > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > Sent: Friday, August 10, 2007 2:24 AM > To: Brian Rosen > Cc: 'Paul Kyzivat'; 'SIMPLE mailing list'; 'Niemi Aki' > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > I think I am ok with Brian's e-mail below. To summarize, for people who > are bored of following the discussion, and to confirm myself, I believe > we agreed: > > > For the MSRP reduced scope (only nicknames resolved to the conference > focus). Let's analyzed the simplest sunny case: > > a) Setting the nickname: > > - The NICKNAME method is the mechanism to bind a nickname-string with a > temporary SIP GRUU allocated by the conference server. You only get the GRUU if you request anonymity. If you don't the URI would be your AoR which you entered the chat with. > - The NICKNAME method contains a Set-Nickname header > - The Set-Nickname header contains the requested nickname-string. Example: > > Set-Nickname: joebob > > - The focus/mixer assigns a GRUU which is valid for the duration of the > conference. The GRUU resolves to the conference focus and obfuscates the > SIP AoR of the user. If you request anonymity > > - The 200 OK for the NICKNAME method contains a header, perhaps > Nickname, that contains the assigned URI (GRUU). Perhaps something like > this: > > Nickname: joebob Yes, although the URI occurs only if you request anonymity > > b) Learning participant's nicknames > > - The focus disseminates the nickname (string and URI) in the conference > event package. We spoke about separated elements. Yes > > - Endpoints need to be ready to receive collisions in nickname-strings Yes > > c) Using the nickname: > > - From and To headers in CPIM can contain nickname URIs. They never > carry nickname-strings, which are only bound at the endpoints and the > conference server. Well, of course they can contain the SIP AoR. > > - Side effect: It is also possible to use the nickname URI outside the > conference, for example, in a MESSAGE, while the user is participating > on it. Did we agree to make this mandatory or optional depending on policy at the server? Of course this applies to the GRUU. > > > I thought a bit about the anonymity parameter in the Set-Nickname, but I > think it is not required for MSRP chat, but just for the generalized > mechanism. The reason: the returned nickname-URI (GRUU) is always > anonymous, at least, you cannot derive the SIP AoR out of it. The user > selects the nickname-string, so he can set any random string, if he > wants to remain discontinued from being "joebob". Well, that is because you thought you always got the GRUU. I don't see why you get the GRUU unless you request anonymity > > Comments? > > /Miguel > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 10 10:15: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 1IJVFf-0000bF-DN; Fri, 10 Aug 2007 10:14:07 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJVFe-0000b1-3N for simple-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 10:14:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJVFd-0000as-Px for simple@ietf.org; Fri, 10 Aug 2007 10:14:05 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJVFc-0006WJ-H3 for simple@ietf.org; Fri, 10 Aug 2007 10:14:05 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IJVFL-0005aV-35; Fri, 10 Aug 2007 09:13:47 -0500 From: "Brian Rosen" To: "'Aki Niemi'" , "'Miguel Garcia'" References: <46ADDC1E.10301@nsn.com> <46B07936.70000@nsn.com> <66cd252f0708022200r5d1055dcu91902169846fffeb@mail.gmail.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com> <46BC0C2B.5080000@nokia.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Fri, 10 Aug 2007 10:13:52 -0400 Message-ID: <033301c7db58$b01cc930$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 In-Reply-To: <46BC0C2B.5080000@nokia.com> Thread-Index: AcfbG6FLCTi3aTsvRMemtxDmBH1TjQAOpO0w 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: 33cc095b503da4365ce57c727e553cf1 Cc: 'Paul Kyzivat' , '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 Sure would have been nice if you had chimed in a while ago :( > -----Original Message----- > From: Aki Niemi [mailto:aki.niemi@nokia.com] > Sent: Friday, August 10, 2007 2:57 AM > To: Miguel Garcia > Cc: Brian Rosen; 'Paul Kyzivat'; 'SIMPLE mailing list' > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > Inline. > > Miguel Garcia wrote: > > I think I am ok with Brian's e-mail below. To summarize, for people who > > are bored of following the discussion, and to confirm myself, I believe > > we agreed: > > > > > > For the MSRP reduced scope (only nicknames resolved to the conference > > focus). Let's analyzed the simplest sunny case: > > > > a) Setting the nickname: > > > > - The NICKNAME method is the mechanism to bind a nickname-string with a > > temporary SIP GRUU allocated by the conference server. > > - The NICKNAME method contains a Set-Nickname header > > - The Set-Nickname header contains the requested nickname-string. > Example: > > > > Set-Nickname: joebob > > > > - The focus/mixer assigns a GRUU which is valid for the duration of the > > conference. The GRUU resolves to the conference focus and obfuscates the > > SIP AoR of the user. > > > > - The 200 OK for the NICKNAME method contains a header, perhaps > > Nickname, that contains the assigned URI (GRUU). Perhaps something like > > this: > > > > Nickname: joebob > > ?? > > So why the heck would the user even bother with the NICKNAME method, if > it anyway ends up getting a GRUU from the focus. > > I see we're now back to using display-names as nicks... That is not how > the rest of the world works. Sorry. It's not a display name. It can't be a display name. Look back through the thread. You can get a GRUU associated with this nickname which you can use in an msrp From:/To: to effectively send via nickname. The nickname is a string, the GRUU is an address. They are linked. Now, indeed we have some confusion, because I think you only get the GRUU if you ask for anonymity. If you do that, the only identity other chat members get is your nickname and the anonymous GRUU associated with it. You display the string, and use the URI if you want to send a message to that user. > > > b) Learning participant's nicknames > > > > - The focus disseminates the nickname (string and URI) in the conference > > event package. We spoke about separated elements. > > > > - Endpoints need to be ready to receive collisions in nickname-strings > > Don't agree. I don't think it is at all reasonable to assume UIs handle > collisions like this, i.e., that you don't require nicks to be unique. > > First, I saw someone suggest a UI could show as a popup the URI if one > hovers over the roster. With what do you hover over a URI if all you > have is a 12-keypad and two softbuttons? > > Second, are users immediately supposed to see that > and > are indeed a different > user, although both have "joebob" as display name? Excuse me, but only > geeks handle hex that well. > > Third, doing automatic suffixes like joebob(2) and so on will just > create nonsense as soon as someone sets their display name as joebob(2). > And I don't even want to go into explaining how some UTF-8 strings look > the same when aren't. That's a local UI issue, and it's pretty straightforwardly solvable except when a user intends to defraud. Then it's not so easy. So far, we're not addressing that issue, but it deserves at least a mention in the security considerations sections. > > > c) Using the nickname: > > > > - From and To headers in CPIM can contain nickname URIs. They never > > carry nickname-strings, which are only bound at the endpoints and the > > conference server. > > Why? It stems from the non-uniqueness property, but generally, From/To has addresses and not strings > > > - Side effect: It is also possible to use the nickname URI outside the > > conference, for example, in a MESSAGE, while the user is participating > > on it. > > This doesn't depend on whether the URI is a simple: > > > > or some GRUU. You are correct, although your example doesn't work if the server at chats.example.com is hosting lots of conferences and the domain of the conference is chat34@chats.example.com. Read back in this thread where we have talked about URI construction using nicknames. We concluded that is a bad idea. If you need an address, we provide a GRUU, or you can use the AoR. > > > I thought a bit about the anonymity parameter in the Set-Nickname, but I > > think it is not required for MSRP chat, but just for the generalized > > mechanism. The reason: the returned nickname-URI (GRUU) is always > > anonymous, at least, you cannot derive the SIP AoR out of it. The user > > selects the nickname-string, so he can set any random string, if he > > wants to remain discontinued from being "joebob". > > Again, that's not a nickname any more. Please take a look at XMPP MUC or > IRC as a reference of what a nickname is. As interesting as it may be to > reinvent wheels, the SIMPLE WG is about 20 years late in this field. I > think it's a bit too late to rethink the essence of the nickname. > > One key decision we would however need to reach is whether a nick is > scoped to a chatroom or the chat server. XMPP seems to have the former > model, whereas IRC has the latter. I have no idea what model we have here. We have decided they can be scoped to the chatroom. Policy or implementation can restrict it further, but the clients have to work if it's scoped to the chatroom. > > My proposal: > > Nicknames are *always* scoped to the conference server (like in IRC). I disagree with this limitation > > Nicks are reserved so that the server enforces uniqueness. (In fact, it > can even enforce its own policies, like disallowing nicknames that look > too similar. Some systems do that today.) We believe that since we will allow non-uniqueness some times, we want all clients to deal with the problem from day 1. > > The nickname is a simple string (SIP URI userpart ABNF production rule), > and each participant is accessible from the outside as well, using the > nick in the userpart of the chat server URI, e.g.: > > This doesn't work if the scope of the nickname is the chatroom > > There is no such thing as an external nickname. By definition, nicknames > are additional handles that participants at a chat server may have. We're not promoting external nicknames in msrp-chat. The generalized mechanism will support that idea. > > However, to gain anonymity, a user might join with an external identity > as their *real* ID. For example, instead of my INVITE being from > sip:aki.niemi@nokia.com, I would join as > sip:AllYourChatRoomsAreBelongToUs@someserver.example.com, if the server > allows it. We discussed requiring external anonymous URIs as the only anonymity mechanism; I don't think this is adequate. The chat server should be able to maintain anonymity. The proposal we have does that inexpensively (the chat server can provide an anonymous GRUU to be linked with a nick if the user desires anonymity. > > Is there a specific reason why the above would not be acceptable? Yes, see above _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 10 10:50:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJVnU-0006Vo-94; Fri, 10 Aug 2007 10:49:04 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJVnT-0006TF-JP for simple-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 10:49:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJVnT-0006Rl-8v for simple@ietf.org; Fri, 10 Aug 2007 10:49:03 -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 1IJVnR-0007RI-Gm for simple@ietf.org; Fri, 10 Aug 2007 10:49:03 -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 l7AEmqE1031627; Fri, 10 Aug 2007 17:48:55 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 17:48:53 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 17:48:53 +0300 Received: from [172.21.41.68] ([172.21.41.68]) by esebe106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 17:48:53 +0300 Message-ID: <46BC7AD4.2030809@nokia.com> Date: Fri, 10 Aug 2007 17:48:52 +0300 From: Aki Niemi Organization: Nokia User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ext Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com> <46BC0C2B.5080000@nokia.com> <033301c7db58$b01cc930$640fa8c0@cis.neustar.com> In-Reply-To: <033301c7db58$b01cc930$640fa8c0@cis.neustar.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2007 14:48:53.0028 (UTC) FILETIME=[91F0FE40:01C7DB5D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: 'Paul Kyzivat' , '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 Inline. ext Brian Rosen wrote: >> So why the heck would the user even bother with the NICKNAME method, if >> it anyway ends up getting a GRUU from the focus. >> >> I see we're now back to using display-names as nicks... That is not how >> the rest of the world works. Sorry. > It's not a display name. It can't be a display name. Look back through the > thread. You can get a GRUU associated with this nickname which you can use > in an msrp From:/To: to effectively send via nickname. > > The nickname is a string, the GRUU is an address. They are linked. You say the nickname is a string for which no-one guarantees uniqueness. A non-unique string does not a unique handle for the user make. > Now, indeed we have some confusion, because I think you only get the GRUU if > you ask for anonymity. If you do that, the only identity other chat members > get is your nickname and the anonymous GRUU associated with it. You display > the string, and use the URI if you want to send a message to that user. In other words, now the user does *not* get to pick its nickname (and know that nobody else can use that same nickname), and instead the server generates one for the user. Completely opposite to how Jabber and IRC work. >>> b) Learning participant's nicknames >>> >>> - The focus disseminates the nickname (string and URI) in the conference >>> event package. We spoke about separated elements. >>> >>> - Endpoints need to be ready to receive collisions in nickname-strings >> Don't agree. I don't think it is at all reasonable to assume UIs handle >> collisions like this, i.e., that you don't require nicks to be unique. >> >> First, I saw someone suggest a UI could show as a popup the URI if one >> hovers over the roster. With what do you hover over a URI if all you >> have is a 12-keypad and two softbuttons? >> >> Second, are users immediately supposed to see that >> and >> are indeed a different >> user, although both have "joebob" as display name? Excuse me, but only >> geeks handle hex that well. >> >> Third, doing automatic suffixes like joebob(2) and so on will just >> create nonsense as soon as someone sets their display name as joebob(2). >> And I don't even want to go into explaining how some UTF-8 strings look >> the same when aren't. > That's a local UI issue, and it's pretty straightforwardly solvable except > when a user intends to defraud. Then it's not so easy. So far, we're not > addressing that issue, but it deserves at least a mention in the security > considerations sections. Sure it's a local issue. But guess what happens if, say, the Psi developers ever find out about the SIMPLE chat spec and (lo and behold) try to accommodate it into their *existing* UI. And in any case, nobody has yet to demonstrate what is so horribly broken with the way existing systems use nicknames so that SIMPLE needs to muck with it. >>> c) Using the nickname: >>> >>> - From and To headers in CPIM can contain nickname URIs. They never >>> carry nickname-strings, which are only bound at the endpoints and the >>> conference server. >> Why? > It stems from the non-uniqueness property, but generally, From/To has > addresses and not strings What you say has no bearing on how that URI is generated. The nickname can just as easily be part of that address. >>> - Side effect: It is also possible to use the nickname URI outside the >>> conference, for example, in a MESSAGE, while the user is participating >>> on it. >> This doesn't depend on whether the URI is a simple: >> >> >> >> or some GRUU. > You are correct, although your example doesn't work if the server at > chats.example.com is hosting lots of conferences and the domain of the > conference is chat34@chats.example.com. That's not a domain, chats.example.com is the domain. Now granted, in my model you could not determine whether something was a chat room or a user just by looking at the URI. But that can easily be solved, *without* GRUUs. (I will, however, point out that that model would have its own benefits, like being able to list a sidebar to a room as a roster item.) > Read back in this thread where we > have talked about URI construction using nicknames. We concluded that is a > bad idea. If you need an address, we provide a GRUU, or you can use the > AoR. Well obviously I disagree with it being a bad idea. Ultimately this boils down to a limitation in the SIP URI; we could take a completely different path and specify a new URI parameter for the nickname similar to how Jabber handles this (and I believe someone already suggested that). I just don't get at which point in this thread we concluded that since we need the ability for the *user* to select its own nickname, we need the server to dish out a random GRUU for him. That just doesn't make any sense to me. >>> I thought a bit about the anonymity parameter in the Set-Nickname, but I >>> think it is not required for MSRP chat, but just for the generalized >>> mechanism. The reason: the returned nickname-URI (GRUU) is always >>> anonymous, at least, you cannot derive the SIP AoR out of it. The user >>> selects the nickname-string, so he can set any random string, if he >>> wants to remain discontinued from being "joebob". >> Again, that's not a nickname any more. Please take a look at XMPP MUC or >> IRC as a reference of what a nickname is. As interesting as it may be to >> reinvent wheels, the SIMPLE WG is about 20 years late in this field. I >> think it's a bit too late to rethink the essence of the nickname. >> >> One key decision we would however need to reach is whether a nick is >> scoped to a chatroom or the chat server. XMPP seems to have the former >> model, whereas IRC has the latter. I have no idea what model we have here. > We have decided they can be scoped to the chatroom. Policy or > implementation can restrict it further, but the clients have to work if it's > scoped to the chatroom. Fine. >> My proposal: >> >> Nicknames are *always* scoped to the conference server (like in IRC). > I disagree with this limitation > >> Nicks are reserved so that the server enforces uniqueness. (In fact, it >> can even enforce its own policies, like disallowing nicknames that look >> too similar. Some systems do that today.) > We believe that since we will allow non-uniqueness some times, we want all > clients to deal with the problem from day 1. I have no idea why we would need to allow unique handles for users in chat rooms to *sometimes* be non-unique. What chat system out there allows this? >> The nickname is a simple string (SIP URI userpart ABNF production rule), >> and each participant is accessible from the outside as well, using the >> nick in the userpart of the chat server URI, e.g.: >> >> > This doesn't work if the scope of the nickname is the chatroom >> There is no such thing as an external nickname. By definition, nicknames >> are additional handles that participants at a chat server may have. > We're not promoting external nicknames in msrp-chat. The generalized > mechanism will support that idea. Again, it we bring this discussion back to current systems, this sounds like federation, which may not be that relevant since we work with URIs to begin with. >> However, to gain anonymity, a user might join with an external identity >> as their *real* ID. For example, instead of my INVITE being from >> sip:aki.niemi@nokia.com, I would join as >> sip:AllYourChatRoomsAreBelongToUs@someserver.example.com, if the server >> allows it. > We discussed requiring external anonymous URIs as the only anonymity > mechanism; I don't think this is adequate. The chat server should be able > to maintain anonymity. The proposal we have does that inexpensively (the > chat server can provide an anonymous GRUU to be linked with a nick if the > user desires anonymity. That still doesn't require a GRUU. It's a simple flag on the server whether to allow the real ID (the one in your From header field in the INVITE) to show in the roster or not. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 10 11:18:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJWEM-0005h9-NG; Fri, 10 Aug 2007 11:16:50 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IJWEK-0005gs-NI for simple-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 11:16:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJWEK-0005gW-CV for simple@ietf.org; Fri, 10 Aug 2007 11:16:48 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJWEI-00082K-W4 for simple@ietf.org; Fri, 10 Aug 2007 11:16:48 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IJWDE-00052H-3l; Fri, 10 Aug 2007 10:15:41 -0500 From: "Brian Rosen" To: "'Aki Niemi'" References: <46ADDC1E.10301@nsn.com> <041701c7d5d2$b7e560e0$640fa8c0@cis.neustar.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com> <46BC0C2B.5080000@nokia.com> <033301c7db58$b01cc930$640fa8c0@cis.neustar.com> <46BC7AD4.2030809@nokia.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Fri, 10 Aug 2007 11:15:46 -0400 Message-ID: <034101c7db61$55c2d110$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 In-Reply-To: <46BC7AD4.2030809@nokia.com> Thread-Index: AcfbXY+KvZbPQmXSTxODW7Ox/qtzxgAANdyg 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: 1.7 (+) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: 'Paul Kyzivat' , '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 In line. It's not so bad Aki, really. > -----Original Message----- > From: Aki Niemi [mailto:aki.niemi@nokia.com] > Sent: Friday, August 10, 2007 10:49 AM > To: ext Brian Rosen > Cc: 'Miguel Garcia'; 'Paul Kyzivat'; 'SIMPLE mailing list' > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > Inline. > > ext Brian Rosen wrote: > >> So why the heck would the user even bother with the NICKNAME method, if > >> it anyway ends up getting a GRUU from the focus. > >> > >> I see we're now back to using display-names as nicks... That is not how > >> the rest of the world works. Sorry. > > It's not a display name. It can't be a display name. Look back through > the > > thread. You can get a GRUU associated with this nickname which you can > use > > in an msrp From:/To: to effectively send via nickname. > > > > The nickname is a string, the GRUU is an address. They are linked. > > You say the nickname is a string for which no-one guarantees uniqueness. > A non-unique string does not a unique handle for the user make. The UI can make it unique any way it wants to. The word "handle" can be used in a UI sense or a program/protocol sense. The string is for the UI, the URI is for the program/protocol. > > > Now, indeed we have some confusion, because I think you only get the > GRUU if > > you ask for anonymity. If you do that, the only identity other chat > members > > get is your nickname and the anonymous GRUU associated with it. You > display > > the string, and use the URI if you want to send a message to that user. > > In other words, now the user does *not* get to pick its nickname (and > know that nobody else can use that same nickname), and instead the > server generates one for the user. Completely opposite to how Jabber and > IRC work. I don't know where you got that idea. The user picks a nickname. The server doesn't generate strings, only the URI, and, in my proposal, only if it requests anonymity. Otherwise the URI is the AoR. The server MAY, by policy, restrict nicknames to be unique. The client MUST handle non unique strings. We always have unique URIs. > > >>> b) Learning participant's nicknames > >>> > >>> - The focus disseminates the nickname (string and URI) in the > conference > >>> event package. We spoke about separated elements. > >>> > >>> - Endpoints need to be ready to receive collisions in nickname-strings > >> Don't agree. I don't think it is at all reasonable to assume UIs handle > >> collisions like this, i.e., that you don't require nicks to be unique. > >> > >> First, I saw someone suggest a UI could show as a popup the URI if one > >> hovers over the roster. With what do you hover over a URI if all you > >> have is a 12-keypad and two softbuttons? > >> > >> Second, are users immediately supposed to see that > >> and > >> are indeed a different > >> user, although both have "joebob" as display name? Excuse me, but only > >> geeks handle hex that well. > >> > >> Third, doing automatic suffixes like joebob(2) and so on will just > >> create nonsense as soon as someone sets their display name as > joebob(2). > >> And I don't even want to go into explaining how some UTF-8 strings look > >> the same when aren't. > > That's a local UI issue, and it's pretty straightforwardly solvable > except > > when a user intends to defraud. Then it's not so easy. So far, we're > not > > addressing that issue, but it deserves at least a mention in the > security > > considerations sections. > > Sure it's a local issue. But guess what happens if, say, the Psi > developers ever find out about the SIMPLE chat spec and (lo and behold) > try to accommodate it into their *existing* UI. They can either restrict use of their existing UI to existing servers, restrict to servers that don't allow non-unique nicknames, or be incompatible with the standard, their choice. > > And in any case, nobody has yet to demonstrate what is so horribly > broken with the way existing systems use nicknames so that SIMPLE needs > to muck with it. Non unique nicknames with local display of something different has been done, right? We didn't invent that idea. > > >>> c) Using the nickname: > >>> > >>> - From and To headers in CPIM can contain nickname URIs. They never > >>> carry nickname-strings, which are only bound at the endpoints and the > >>> conference server. > >> Why? > > It stems from the non-uniqueness property, but generally, From/To has > > addresses and not strings > > What you say has no bearing on how that URI is generated. The nickname > can just as easily be part of that address. No, it cannot, at least without a lot of mucking around, or the restriction that uniqueness is to the server and not the chat. Lots of existing implementations won't work with THAT restriction. > > >>> - Side effect: It is also possible to use the nickname URI outside the > >>> conference, for example, in a MESSAGE, while the user is participating > >>> on it. > >> This doesn't depend on whether the URI is a simple: > >> > >> > >> > >> or some GRUU. > > You are correct, although your example doesn't work if the server at > > chats.example.com is hosting lots of conferences and the domain of the > > conference is chat34@chats.example.com. > > That's not a domain, chats.example.com is the domain. Now granted, in my > model you could not determine whether something was a chat room or a > user just by looking at the URI. But that can easily be solved, > *without* GRUUs. (I will, however, point out that that model would have > its own benefits, like being able to list a sidebar to a room as a > roster item.) If the domain that nicks must be unique in is the chat, and not the server, then the domain of the chat is chat34@chats.example.com. It is only when you restrict uniqueness to the server that you can get away with assuming the domain for the URI has nothing before the "@". > > > Read back in this thread where we > > have talked about URI construction using nicknames. We concluded that > is a > > bad idea. If you need an address, we provide a GRUU, or you can use the > > AoR. > > Well obviously I disagree with it being a bad idea. > > Ultimately this boils down to a limitation in the SIP URI; we could take > a completely different path and specify a new URI parameter for the > nickname similar to how Jabber handles this (and I believe someone > already suggested that). Yes, we went through that discussion. It's possible. The current proposal avoids the problem in a different way. It simply doesn't use the string in the URI. > > I just don't get at which point in this thread we concluded that since > we need the ability for the *user* to select its own nickname, we need > the server to dish out a random GRUU for him. That just doesn't make any > sense to me. In my proposal, you only get the GRUU if you request anonymity. In that case, you NEED a GRUU (or something equivalent). If you don't need anonymity, then you don't need a URI other than your AoR at all, so don't make one up. A nickname needs a string for the UI. We supply said string. We don't use the string to make an address out of. That's pretty simple, isn't it? The uniqueness issue is a forward looking one. If you EVER want to be able to have non unique nicknames, you need to do it from day one. > > >>> I thought a bit about the anonymity parameter in the Set-Nickname, but > I > >>> think it is not required for MSRP chat, but just for the generalized > >>> mechanism. The reason: the returned nickname-URI (GRUU) is always > >>> anonymous, at least, you cannot derive the SIP AoR out of it. The user > >>> selects the nickname-string, so he can set any random string, if he > >>> wants to remain discontinued from being "joebob". > >> Again, that's not a nickname any more. Please take a look at XMPP MUC > or > >> IRC as a reference of what a nickname is. As interesting as it may be > to > >> reinvent wheels, the SIMPLE WG is about 20 years late in this field. I > >> think it's a bit too late to rethink the essence of the nickname. > >> > >> One key decision we would however need to reach is whether a nick is > >> scoped to a chatroom or the chat server. XMPP seems to have the former > >> model, whereas IRC has the latter. I have no idea what model we have > here. > > We have decided they can be scoped to the chatroom. Policy or > > implementation can restrict it further, but the clients have to work if > it's > > scoped to the chatroom. > > Fine. Not so fast. If it's fine to scope to the chatroom, then you have a chat34@chats.example.com as the domain of the chat, and you are back to a complex URI construction rule if you use the string in a URI. > > >> My proposal: > >> > >> Nicknames are *always* scoped to the conference server (like in IRC). > > I disagree with this limitation > > > >> Nicks are reserved so that the server enforces uniqueness. (In fact, it > >> can even enforce its own policies, like disallowing nicknames that look > >> too similar. Some systems do that today.) > > We believe that since we will allow non-uniqueness some times, we want > all > > clients to deal with the problem from day 1. > > I have no idea why we would need to allow unique handles for users in > chat rooms to *sometimes* be non-unique. What chat system out there > allows this? Again confusion on what a "handle" is. A UI element that the local UI has to deal with non-uniqueness of a string locally or a program/protocol element where we have a unique URI always, but it doesn't have the string in it? > > >> The nickname is a simple string (SIP URI userpart ABNF production > rule), > >> and each participant is accessible from the outside as well, using the > >> nick in the userpart of the chat server URI, e.g.: > >> > >> > > This doesn't work if the scope of the nickname is the chatroom > > > > >> There is no such thing as an external nickname. By definition, > nicknames > >> are additional handles that participants at a chat server may have. > > We're not promoting external nicknames in msrp-chat. The generalized > > mechanism will support that idea. > > Again, it we bring this discussion back to current systems, this sounds > like federation, which may not be that relevant since we work with URIs > to begin with. No, it's not federation. It's allowing the domain of a nick to not be the domain of the chat. This lets you have a nickname registered once and accepted with multiple services. > > >> However, to gain anonymity, a user might join with an external identity > >> as their *real* ID. For example, instead of my INVITE being from > >> sip:aki.niemi@nokia.com, I would join as > >> sip:AllYourChatRoomsAreBelongToUs@someserver.example.com, if the server > >> allows it. > > We discussed requiring external anonymous URIs as the only anonymity > > mechanism; I don't think this is adequate. The chat server should be > able > > to maintain anonymity. The proposal we have does that inexpensively > (the > > chat server can provide an anonymous GRUU to be linked with a nick if > the > > user desires anonymity. > > That still doesn't require a GRUU. It's a simple flag on the server > whether to allow the real ID (the one in your From header field in the > INVITE) to show in the roster or not. No, you need a unique address to use in msrp From/To which doesn't break anonymity but can be used to address a message to that anonymous user. The GRUU is that address. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 13 03:03: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 1IKTvT-0006JG-7J; Mon, 13 Aug 2007 03:01:19 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IKTvR-0006IT-7s for simple-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 03:01:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKTvN-0006Gk-AS for simple@ietf.org; Mon, 13 Aug 2007 03:01:13 -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 1IKTvL-000456-6F for simple@ietf.org; Mon, 13 Aug 2007 03:01:12 -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 l7D70wIG022650; Mon, 13 Aug 2007 10:01:00 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:00:52 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:00:52 +0300 Received: from [172.21.41.94] ([172.21.41.94]) by esebe106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:00:51 +0300 Message-ID: <46C0019F.8080303@nokia.com> Date: Mon, 13 Aug 2007 10:00:47 +0300 From: Aki Niemi Organization: Nokia User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ext Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46B35AA4.7090106@cisco.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com> <46BC0C2B.5080000@nokia.com> <033301c7db58$b01cc930$640fa8c0@cis.neustar.com> <46BC7AD4.2030809@nokia.com> <034101c7db61$55c2d110$640fa8c0@cis.neustar.c! om> In-Reply-To: <034101c7db61$55c2d110$640fa8c0@cis.neustar.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2007 07:00:51.0684 (UTC) FILETIME=[AF653240:01C7DD77] X-Nokia-AV: Clean X-Spam-Score: 1.7 (+) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: 'Paul Kyzivat' , '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 ext Brian Rosen wrote: > In line. It's not so bad Aki, really. Perhaps I'll be the judge of that. ;) >> You say the nickname is a string for which no-one guarantees uniqueness. >> A non-unique string does not a unique handle for the user make. > The UI can make it unique any way it wants to. > The word "handle" can be used in a UI sense or a program/protocol sense. > The string is for the UI, the URI is for the program/protocol. Again, this is counter to all existing systems, so you better first explain what is so horribly broken with IRC and Jabber that SIMPLE needs to behave differently. >> In other words, now the user does *not* get to pick its nickname (and >> know that nobody else can use that same nickname), and instead the >> server generates one for the user. Completely opposite to how Jabber and >> IRC work. > I don't know where you got that idea. The user picks a nickname. The > server doesn't generate strings, only the URI, and, in my proposal, only if > it requests anonymity. Otherwise the URI is the AoR. I know you have all along argued for this idea that we just use the display-name for the purposes of a nickname. However, that is not how current systems work. > The server MAY, by policy, restrict nicknames to be unique. The client MUST > handle non unique strings. We always have unique URIs. This is nonsensical. Can you please explain where this requirement for non-unique nicknames comes from? >> Sure it's a local issue. But guess what happens if, say, the Psi >> developers ever find out about the SIMPLE chat spec and (lo and behold) >> try to accommodate it into their *existing* UI. > They can either restrict use of their existing UI to existing servers, > restrict to servers that don't allow non-unique nicknames, or be > incompatible with the standard, their choice. Well I tend to think we are here to serve the implementor community, and not vice versa. If the standard makes no sense, then we clearly aren't serving them well (especially if we now, after 20 years of running systems, come up with a concept that says is the same thing but isn't). >> And in any case, nobody has yet to demonstrate what is so horribly >> broken with the way existing systems use nicknames so that SIMPLE needs >> to muck with it. > Non unique nicknames with local display of something different has been > done, right? We didn't invent that idea. Where has it been done? Not in IRC or Jabber, so yes I think you did invent that idea on your own. >> What you say has no bearing on how that URI is generated. The nickname >> can just as easily be part of that address. > No, it cannot, at least without a lot of mucking around, or the restriction > that uniqueness is to the server and not the chat. Lots of existing > implementations won't work with THAT restriction. I don't understand. Could you elaborate on which existing systems you're referring to here, and what exactly you mean by "mucking around"? >> I just don't get at which point in this thread we concluded that since >> we need the ability for the *user* to select its own nickname, we need >> the server to dish out a random GRUU for him. That just doesn't make any >> sense to me. > In my proposal, you only get the GRUU if you request anonymity. In that > case, you NEED a GRUU (or something equivalent). If you don't need > anonymity, then you don't need a URI other than your AoR at all, so don't > make one up. Right, I understand you're proposing that we simply use the display name as a "nickname". In addition, you've proposed this additional mechanism to request anonymity. This is something you've been proposing as long as I remember. And as long as I remember, I've said this is *not* how nicknames work in other systems. > A nickname needs a string for the UI. We supply said string. We don't use > the string to make an address out of. That's pretty simple, isn't it? Simple and useless, I might add. Can we forget about UIs for a moment? We don't do UIs here, and if you look at IRC or Jabber, they definitely use the nickname as an on-the-wire identifier of a channel/chat room participant. Do you disagree? Now, in your proposal, you use the GRUU as an on-the-wire identifier, correct? You must admit these are a different concept altogether. > The uniqueness issue is a forward looking one. If you EVER want to be able > to have non unique nicknames, you need to do it from day one. The point is, by design, you NEVER want to be able to have nicknames collide. That's the whole point! > Not so fast. If it's fine to scope to the chatroom, then you have a > chat34@chats.example.com as the domain of the chat, and you are back to a > complex URI construction rule if you use the string in a URI. There is nothing complex about it: >> How is that complex? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 13 06:10: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 1IKWqB-0004dP-K9; Mon, 13 Aug 2007 06:08:03 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IKWqA-0004dI-PP for simple-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 06:08:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKWqA-0004d9-F3 for simple@ietf.org; Mon, 13 Aug 2007 06:08:02 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKWq9-0007XA-Ug for simple@ietf.org; Mon, 13 Aug 2007 06:08:02 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7DA7v6n031176; Mon, 13 Aug 2007 13:07:58 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 13:07:34 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 13:07:34 +0300 Received: from [172.21.41.94] (esdhcp04194.research.nokia.com [172.21.41.94]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7DA7WTS000929; Mon, 13 Aug 2007 13:07:32 +0300 Message-ID: <46C02D64.60103@nokia.com> Date: Mon, 13 Aug 2007 13:07:32 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ext Miguel Garcia Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com> <46B075ED.80809@nsn.com> In-Reply-To: <46B075ED.80809@nsn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2007 10:07:34.0313 (UTC) FILETIME=[C4AEB990:01C7DD91] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Paul Kyzivat , 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 ext Miguel Garcia wrote: >> or sip:room34@example.com;name="nordicguy" > > better, but I what is a 'name'. A parameter named 'nickname' would even > be better. Still, I think we can reuse the already defined 'user' > parameter of a URI to write a nickname in the userpart. How about just specifying a "nickname" parameter? That would avoid embedding the nick in the userpart, which was I believe something Brian didn't like. Also, when you say "reuse the already defined 'user' parameter", this gives me an instant allergic reaction. Are we really running out of the URI parameter namespace? Also, this would be specification reuse -- of a couple of lines in ABNF at best -- and *not* code reuse. Not worth it. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 13 10:07:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKaYa-0002RA-DW; Mon, 13 Aug 2007 10:06:08 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IKaYZ-0002R5-GV for simple-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 10:06:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKaYZ-0002Qx-52 for simple@ietf.org; Mon, 13 Aug 2007 10:06:07 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKaYX-0006Th-KI for simple@ietf.org; Mon, 13 Aug 2007 10:06:06 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Aug 2007 10:06:06 -0400 X-IronPort-AV: i="4.19,255,1183348800"; d="scan'208"; a="128714602:sNHT73408242" 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 l7DE65ot025022; Mon, 13 Aug 2007 10:06:05 -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 l7DE5rjK025918; Mon, 13 Aug 2007 14:05:57 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, 13 Aug 2007 10:05:53 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:05:53 -0400 Message-ID: <46C06540.2020709@cisco.com> Date: Mon, 13 Aug 2007 10:05:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com> <46BC0C2B.5080000@nokia.com> <033301c7db58$b01cc930$640fa8c0@cis.neustar.com> <46BC7AD4.2030809@nokia.com> <034101c7db61$55c2d110$640fa8c0@cis.neustar.c! om> <46C0019F.8080303@nokia.com> In-Reply-To: <46C0019F.8080303@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2007 14:05:53.0252 (UTC) FILETIME=[0F83AA40:01C7DDB3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13336; t=1187013965; x=1187877965; 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]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20 |To:=20Aki=20Niemi=20; bh=QHIzV7IOICYHINs2tI9xDzw9bkSkx+zVlmJFNGMCFXw=; b=J344wKTPz/6wufGCDhoIxuZQV1qPAzsHUaoGzzgYlvI6yvMP10dW3TFIo1XyMT5Jq8EsclFL LuRZT/ly1aug8RvtTOMcuBSlaH4fyGKADX1yjqPQ4cfR0hhETpDQY/Ek; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 1.7 (+) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 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 Aki, I'm not going to respond point by point below, because it will just confuse things. (I'm not entirely in line with Brian, or others, yet though I thought we were getting close.) But let me explain my reasoning behind "non unique nicknames": - IMO per-chatroom nicknames aren't good enough in general, though they may be appropriate in some cases. When there is a set of related chat rooms that are visited by many of the same people then you would like some confidence that a nickname references the same person in all of them. (I would not like to be surprised to find that "Aki" wasn't you in one ietf-sip-related chatroom.) So IMO there must be *some provision* for nicknames to be reserved to a particular person on a broader basis than one chatroom. - If there is an ability to reserve a nickname for multiple chatrooms, then there must be some agency responsible for doing so. But we certainly don't want to endorse a single such agency. If there are to be multiple agencies assigning nicknames, then nicknames will only be unique within a particular agency. - If I have reserved my nickname with some particular agency then, IMO, I should be able to use that with any chatroom. The set of chatrooms frequented by a community of users may not all be managed by the same entity. In this case, two users may have reserved the "same" nickname from different nickname agencies. And these may be used in the same chatroom, leading to a "collision". As I was originally conceiving this, the nicknames were all scoped by the name of the assigning agency (a domain name). (Note that this is entirely compatible with a chatroom serving as a default nickname assigning agency for participants.) Hence as long as you consider the nickname to include that domain name there aren't really any collisions. It is only if you choose not to display the domain name part that there are collisions. I considered that to be a UI issue that could be solved in many ways. - there could be a default nickname agency/domain per room or server. The UI could suppress the default domain when displaying nicknames, but display it (using "@" notation) otherwise. - When displaying nicknames, a UI could suppress the domain from all nicknames from the same domain as the user's own nickname. - The UI could suppress the domains of all the nicknames, but assign a suffix (e.g. (2), (3)) to distinguish duplicates, or display duplicates with different colors, etc. Personally, I think that concept would still be entirely workable. But I have been able to agree with some of the other ideas that have been proposed. A somewhat separate issue has been the routability of nicknames. The one part of that which has been present from the beginning of the proposal from you guys has been routability via MSRP via the To address in the CPIM header. While I don't have a particular problem with that I find it limiting since it only works for IM. If nicknames are to be routable for one medium then I think they ought to work for other media as well. In general I think that means that they must be usable for routing sip. If nicknames were always of the form @ (before the UI fiddles with them for display purposes) then it is natural to think that they could be turned into a URI, like sip:@, and then be routable. If the domain happens to be served by the same server that handles a chatroom, then participant status in a chatroom can be used to influence the routing rules. If the domain server doesn't happen to be collocated with a chatroom it can still forward requests using a variety of interesting policies. However others wanted to separate the routability from the name itself. Hence there came the notion of having the *usage* of a nickname in a conference be associated with some routable URI. The nickname is of course associated with a participant, and hence with the contact address of that participant. So, if you want to route something to a participant you have selected by nickname you could route to the corresponding contact address. But if the participant chooses to be anonymous, then that doesn't work. So, somebody suggested having the focus assign surrogate contact addresses (gruus) for those participants that choose to be anonymous. While this wasn't my original concept, I have no problem with it. It seems to work fine, and separates the nickname for routability. That means that external nickname agencies don't have to deal with that. Brian took that one step further: Qualification of a nickname with a domain is only necessary during the process of associating a nickname with a conference participant. That domain need not be exposed to other participants. Instead, other participants see only the name part, and distinguish them based on their routable contact address - either the real one or the surrogate gruu. His motivation (if I can put words in his mouth) seemed to be to allow multiple participants to use the same nickname (the displayed part) even if they were all using the focus itself as the nickname assigning agency. Personally I could care less about this last aspect. I think it has the downside of preventing some participants from making multiple connections and having them be perceived as being from the "same" person. And I don't especially care about using the focus as the nickname assigning agency - I think it is a mechanism that should be supported but rarely used. (But that is just my opinion. I'm happy for others to feel differently.) Separating the nickname from the URI used for routability doesn't turn the nickname into a display name in the way that we have come to know and love display names in sip. The key difference is that the nickname usage is controlled and authorized, so that participants have a set of useful conclusions they can draw when they see particular nicknames. IMO there is probably still a bit of fine tuning to do here, but we are on a productive track that can result in something that works for chat, works for other conferences, is flexible, is reasonably easy to implement, and that can have a reasonable UI. To be constructive, I'll suggest the following, picking from things that have already been discussed in this thread: - The MSRP nickname request be allowed with either just or with @. - The name-only form is a request to assign the name within a domain unique to the focus, for the duration of participation, and then associate it with the participant. This can fail if the name is already in use by a participant with a different identity. - The @ form requests that the focus verify with a server for the domain that the requester is allowed to use the nickname, and then associate it with the participant. This can fail if the focus doesn't support it, if it doesn't know how to do verification with that domain, or if verification fails. - Eventually there will be some other, more general, mechanism for doing temporary nickname assignment and nickname association, independent of MSRP. That is still TBD. - Nicknames don't appear in CPIM From/To headers. Instead, the sip contact address of the participant appears. If the user is anonymous, then a surrogate URI provided by the focus appears. - The association between nicknames and contact addresses is learned by each participant via an enhancement to the conference event package. The nicknames delivered this way always are of the @ form. - The chat UI is responsible for obtaining nicknames corresponding to received messages and rendering them in a user-friendly way. If this is burdensome, we could consider having the focus include the nickname as a display name in the CPIM From header. (I'm not wild about it, but it is a possible optimization.) Paul Aki Niemi wrote: > ext Brian Rosen wrote: >> In line. It's not so bad Aki, really. > > Perhaps I'll be the judge of that. ;) > >>> You say the nickname is a string for which no-one guarantees uniqueness. >>> A non-unique string does not a unique handle for the user make. >> The UI can make it unique any way it wants to. >> The word "handle" can be used in a UI sense or a program/protocol sense. >> The string is for the UI, the URI is for the program/protocol. > > Again, this is counter to all existing systems, so you better first > explain what is so horribly broken with IRC and Jabber that SIMPLE needs > to behave differently. > >>> In other words, now the user does *not* get to pick its nickname (and >>> know that nobody else can use that same nickname), and instead the >>> server generates one for the user. Completely opposite to how Jabber and >>> IRC work. >> I don't know where you got that idea. The user picks a nickname. The >> server doesn't generate strings, only the URI, and, in my proposal, only if >> it requests anonymity. Otherwise the URI is the AoR. > > I know you have all along argued for this idea that we just use the > display-name for the purposes of a nickname. However, that is not how > current systems work. > >> The server MAY, by policy, restrict nicknames to be unique. The client MUST >> handle non unique strings. We always have unique URIs. > > This is nonsensical. Can you please explain where this requirement for > non-unique nicknames comes from? > >>> Sure it's a local issue. But guess what happens if, say, the Psi >>> developers ever find out about the SIMPLE chat spec and (lo and behold) >>> try to accommodate it into their *existing* UI. >> They can either restrict use of their existing UI to existing servers, >> restrict to servers that don't allow non-unique nicknames, or be >> incompatible with the standard, their choice. > > Well I tend to think we are here to serve the implementor community, and > not vice versa. If the standard makes no sense, then we clearly aren't > serving them well (especially if we now, after 20 years of running > systems, come up with a concept that says is the same thing but isn't). > >>> And in any case, nobody has yet to demonstrate what is so horribly >>> broken with the way existing systems use nicknames so that SIMPLE needs >>> to muck with it. >> Non unique nicknames with local display of something different has been >> done, right? We didn't invent that idea. > > Where has it been done? Not in IRC or Jabber, so yes I think you did > invent that idea on your own. > >>> What you say has no bearing on how that URI is generated. The nickname >>> can just as easily be part of that address. >> No, it cannot, at least without a lot of mucking around, or the restriction >> that uniqueness is to the server and not the chat. Lots of existing >> implementations won't work with THAT restriction. > > I don't understand. Could you elaborate on which existing systems you're > referring to here, and what exactly you mean by "mucking around"? > >>> I just don't get at which point in this thread we concluded that since >>> we need the ability for the *user* to select its own nickname, we need >>> the server to dish out a random GRUU for him. That just doesn't make any >>> sense to me. >> In my proposal, you only get the GRUU if you request anonymity. In that >> case, you NEED a GRUU (or something equivalent). If you don't need >> anonymity, then you don't need a URI other than your AoR at all, so don't >> make one up. > > Right, I understand you're proposing that we simply use the display name > as a "nickname". In addition, you've proposed this additional mechanism > to request anonymity. This is something you've been proposing as long as > I remember. And as long as I remember, I've said this is *not* how > nicknames work in other systems. > >> A nickname needs a string for the UI. We supply said string. We don't use >> the string to make an address out of. That's pretty simple, isn't it? > > Simple and useless, I might add. > > Can we forget about UIs for a moment? We don't do UIs here, and if you > look at IRC or Jabber, they definitely use the nickname as an > on-the-wire identifier of a channel/chat room participant. Do you disagree? > > Now, in your proposal, you use the GRUU as an on-the-wire identifier, > correct? > > You must admit these are a different concept altogether. > >> The uniqueness issue is a forward looking one. If you EVER want to be able >> to have non unique nicknames, you need to do it from day one. > > The point is, by design, you NEVER want to be able to have nicknames > collide. That's the whole point! > >> Not so fast. If it's fine to scope to the chatroom, then you have a >> chat34@chats.example.com as the domain of the chat, and you are back to a >> complex URI construction rule if you use the string in a URI. > > There is nothing complex about it: > >>> > > How is that complex? > > Cheers, > Aki > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 14 18:57:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL5IC-0007RH-Ai; Tue, 14 Aug 2007 18:55:16 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IL5IA-0007RA-KP for simple-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 18:55:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL5IA-0007R1-7V for simple@ietf.org; Tue, 14 Aug 2007 18:55:14 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL5I8-0003mt-NA for simple@ietf.org; Tue, 14 Aug 2007 18:55:14 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IL5Hn-0005Qm-7v; Tue, 14 Aug 2007 17:54:53 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" , "'Aki Niemi'" References: <46ADDC1E.10301@nsn.com> <46B6B26C.3080002@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com> <46BC0C2B.5080000@nokia.com> <033301c7db58$b01cc930$640fa8c0@cis.neustar.com> <46BC7AD4.2030809@nokia.com> <034101c7db61$55c2d110$640fa8c0@cis.neustar.c! om> <46C0019F.8080303@nokia.com> <46C06540.20207 09@cisco.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Tue, 14 Aug 2007 18:55:00 -0400 Message-ID: <00a201c7dec6$27d59c70$0600a8c0@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: Acfdsxqw6BglOlwYQeGQnGrA3qNzdQBEqRYA In-Reply-To: <46C06540.2020709@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: 1.7 (+) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 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 I am okay with all of this. I assume that: > then ..... This can fail if the name > is already in use by a participant with a different identity. Is a policy issue at the server; the server could have a policy that said it allowed it. The UI has to cope. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, August 13, 2007 10:06 AM > To: Aki Niemi > Cc: ext Brian Rosen; 'Miguel Garcia'; 'SIMPLE mailing list' > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > Aki, > > I'm not going to respond point by point below, because it will just > confuse things. (I'm not entirely in line with Brian, or others, yet > though I thought we were getting close.) But let me explain my reasoning > behind "non unique nicknames": > > - IMO per-chatroom nicknames aren't good enough in general, > though they may be appropriate in some cases. When there > is a set of related chat rooms that are visited by many of > the same people then you would like some confidence that > a nickname references the same person in all of them. > (I would not like to be surprised to find that "Aki" > wasn't you in one ietf-sip-related chatroom.) So IMO there > must be *some provision* for nicknames to be reserved to a > particular person on a broader basis than one chatroom. > > - If there is an ability to reserve a nickname for multiple > chatrooms, then there must be some agency responsible for > doing so. But we certainly don't want to endorse a single > such agency. If there are to be multiple agencies assigning > nicknames, then nicknames will only be unique within a > particular agency. > > - If I have reserved my nickname with some particular agency > then, IMO, I should be able to use that with any chatroom. > The set of chatrooms frequented by a community of users may > not all be managed by the same entity. In this case, two > users may have reserved the "same" nickname from different > nickname agencies. And these may be used in the same chatroom, > leading to a "collision". > > As I was originally conceiving this, the nicknames were all scoped by > the name of the assigning agency (a domain name). (Note that this is > entirely compatible with a chatroom serving as a default nickname > assigning agency for participants.) Hence as long as you consider the > nickname to include that domain name there aren't really any collisions. > It is only if you choose not to display the domain name part that there > are collisions. I considered that to be a UI issue that could be solved > in many ways. > - there could be a default nickname agency/domain per room or server. > The UI could suppress the default domain when displaying nicknames, > but display it (using "@" notation) otherwise. > - When displaying nicknames, a UI could suppress the domain from all > nicknames from the same domain as the user's own nickname. > - The UI could suppress the domains of all the nicknames, but assign > a suffix (e.g. (2), (3)) to distinguish duplicates, or display > duplicates with different colors, etc. > > Personally, I think that concept would still be entirely workable. But I > have been able to agree with some of the other ideas that have been > proposed. > > A somewhat separate issue has been the routability of nicknames. The one > part of that which has been present from the beginning of the proposal > from you guys has been routability via MSRP via the To address in the > CPIM header. While I don't have a particular problem with that I find it > limiting since it only works for IM. If nicknames are to be routable for > one medium then I think they ought to work for other media as well. In > general I think that means that they must be usable for routing sip. > > If nicknames were always of the form @ (before the UI > fiddles with them for display purposes) then it is natural to think that > they could be turned into a URI, like sip:@, and then be > routable. If the domain happens to be served by the same server that > handles a chatroom, then participant status in a chatroom can be used to > influence the routing rules. If the domain server doesn't happen to be > collocated with a chatroom it can still forward requests using a variety > of interesting policies. > > However others wanted to separate the routability from the name itself. > Hence there came the notion of having the *usage* of a nickname in a > conference be associated with some routable URI. The nickname is of > course associated with a participant, and hence with the contact address > of that participant. So, if you want to route something to a participant > you have selected by nickname you could route to the corresponding > contact address. But if the participant chooses to be anonymous, then > that doesn't work. So, somebody suggested having the focus assign > surrogate contact addresses (gruus) for those participants that choose > to be anonymous. While this wasn't my original concept, I have no > problem with it. It seems to work fine, and separates the nickname for > routability. That means that external nickname agencies don't have to > deal with that. > > Brian took that one step further: Qualification of a nickname with a > domain is only necessary during the process of associating a nickname > with a conference participant. That domain need not be exposed to other > participants. Instead, other participants see only the name part, and > distinguish them based on their routable contact address - either the > real one or the surrogate gruu. His motivation (if I can put words in > his mouth) seemed to be to allow multiple participants to use the same > nickname (the displayed part) even if they were all using the focus > itself as the nickname assigning agency. > > Personally I could care less about this last aspect. I think it has the > downside of preventing some participants from making multiple > connections and having them be perceived as being from the "same" > person. And I don't especially care about using the focus as the > nickname assigning agency - I think it is a mechanism that should be > supported but rarely used. (But that is just my opinion. I'm happy for > others to feel differently.) > > Separating the nickname from the URI used for routability doesn't turn > the nickname into a display name in the way that we have come to know > and love display names in sip. The key difference is that the nickname > usage is controlled and authorized, so that participants have a set of > useful conclusions they can draw when they see particular nicknames. > > IMO there is probably still a bit of fine tuning to do here, but we are > on a productive track that can result in something that works for chat, > works for other conferences, is flexible, is reasonably easy to > implement, and that can have a reasonable UI. > > To be constructive, I'll suggest the following, picking from things that > have already been discussed in this thread: > > - The MSRP nickname request be allowed with either just or with > @. > > - The name-only form is a request to assign the name within > a domain unique to the focus, for the duration of participation, and > then associate it with the participant. This can fail if the name > is already in use by a participant with a different identity. > > - The @ form requests that the focus verify with a > server for the domain that the requester is allowed to use > the nickname, and then associate it with the participant. > This can fail if the focus doesn't support it, if it doesn't > know how to do verification with that domain, or if verification > fails. > > - Eventually there will be some other, more general, mechanism for > doing temporary nickname assignment and nickname association, > independent of MSRP. That is still TBD. > > - Nicknames don't appear in CPIM From/To headers. Instead, the > sip contact address of the participant appears. If the user is > anonymous, then a surrogate URI provided by the focus appears. > > - The association between nicknames and contact addresses is learned > by each participant via an enhancement to the conference event > package. The nicknames delivered this way always are of the > @ form. > > - The chat UI is responsible for obtaining nicknames corresponding > to received messages and rendering them in a user-friendly way. > If this is burdensome, we could consider having the focus > include the nickname as a display name in the CPIM From header. > (I'm not wild about it, but it is a possible optimization.) > > Paul > > Aki Niemi wrote: > > ext Brian Rosen wrote: > >> In line. It's not so bad Aki, really. > > > > Perhaps I'll be the judge of that. ;) > > > >>> You say the nickname is a string for which no-one guarantees > uniqueness. > >>> A non-unique string does not a unique handle for the user make. > >> The UI can make it unique any way it wants to. > >> The word "handle" can be used in a UI sense or a program/protocol > sense. > >> The string is for the UI, the URI is for the program/protocol. > > > > Again, this is counter to all existing systems, so you better first > > explain what is so horribly broken with IRC and Jabber that SIMPLE needs > > to behave differently. > > > >>> In other words, now the user does *not* get to pick its nickname (and > >>> know that nobody else can use that same nickname), and instead the > >>> server generates one for the user. Completely opposite to how Jabber > and > >>> IRC work. > >> I don't know where you got that idea. The user picks a nickname. The > >> server doesn't generate strings, only the URI, and, in my proposal, > only if > >> it requests anonymity. Otherwise the URI is the AoR. > > > > I know you have all along argued for this idea that we just use the > > display-name for the purposes of a nickname. However, that is not how > > current systems work. > > > >> The server MAY, by policy, restrict nicknames to be unique. The client > MUST > >> handle non unique strings. We always have unique URIs. > > > > This is nonsensical. Can you please explain where this requirement for > > non-unique nicknames comes from? > > > >>> Sure it's a local issue. But guess what happens if, say, the Psi > >>> developers ever find out about the SIMPLE chat spec and (lo and > behold) > >>> try to accommodate it into their *existing* UI. > >> They can either restrict use of their existing UI to existing servers, > >> restrict to servers that don't allow non-unique nicknames, or be > >> incompatible with the standard, their choice. > > > > Well I tend to think we are here to serve the implementor community, and > > not vice versa. If the standard makes no sense, then we clearly aren't > > serving them well (especially if we now, after 20 years of running > > systems, come up with a concept that says is the same thing but isn't). > > > >>> And in any case, nobody has yet to demonstrate what is so horribly > >>> broken with the way existing systems use nicknames so that SIMPLE > needs > >>> to muck with it. > >> Non unique nicknames with local display of something different has been > >> done, right? We didn't invent that idea. > > > > Where has it been done? Not in IRC or Jabber, so yes I think you did > > invent that idea on your own. > > > >>> What you say has no bearing on how that URI is generated. The nickname > >>> can just as easily be part of that address. > >> No, it cannot, at least without a lot of mucking around, or the > restriction > >> that uniqueness is to the server and not the chat. Lots of existing > >> implementations won't work with THAT restriction. > > > > I don't understand. Could you elaborate on which existing systems you're > > referring to here, and what exactly you mean by "mucking around"? > > > >>> I just don't get at which point in this thread we concluded that since > >>> we need the ability for the *user* to select its own nickname, we need > >>> the server to dish out a random GRUU for him. That just doesn't make > any > >>> sense to me. > >> In my proposal, you only get the GRUU if you request anonymity. In > that > >> case, you NEED a GRUU (or something equivalent). If you don't need > >> anonymity, then you don't need a URI other than your AoR at all, so > don't > >> make one up. > > > > Right, I understand you're proposing that we simply use the display name > > as a "nickname". In addition, you've proposed this additional mechanism > > to request anonymity. This is something you've been proposing as long as > > I remember. And as long as I remember, I've said this is *not* how > > nicknames work in other systems. > > > >> A nickname needs a string for the UI. We supply said string. We don't > use > >> the string to make an address out of. That's pretty simple, isn't it? > > > > Simple and useless, I might add. > > > > Can we forget about UIs for a moment? We don't do UIs here, and if you > > look at IRC or Jabber, they definitely use the nickname as an > > on-the-wire identifier of a channel/chat room participant. Do you > disagree? > > > > Now, in your proposal, you use the GRUU as an on-the-wire identifier, > > correct? > > > > You must admit these are a different concept altogether. > > > >> The uniqueness issue is a forward looking one. If you EVER want to be > able > >> to have non unique nicknames, you need to do it from day one. > > > > The point is, by design, you NEVER want to be able to have nicknames > > collide. That's the whole point! > > > >> Not so fast. If it's fine to scope to the chatroom, then you have a > >> chat34@chats.example.com as the domain of the chat, and you are back to > a > >> complex URI construction rule if you use the string in a URI. > > > > There is nothing complex about it: > > > >>> > > > > How is that complex? > > > > Cheers, > > Aki > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 15 08:38:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILI7S-00041H-GT; Wed, 15 Aug 2007 08:37:02 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ILI7Q-00040r-O6 for simple-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 08:37:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILI7Q-00040j-Du for simple@ietf.org; Wed, 15 Aug 2007 08:37:00 -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 1ILI7O-0003Uy-O7 for simple@ietf.org; Wed, 15 Aug 2007 08:37:00 -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 l7FCaPpE030042; Wed, 15 Aug 2007 15:36:47 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 15:36:23 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 15:36:22 +0300 Received: from [172.21.41.118] ([172.21.41.118]) by esebe106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 15:36:21 +0300 Message-ID: <46C2F343.5020300@nokia.com> Date: Wed, 15 Aug 2007 15:36:19 +0300 From: Aki Niemi Organization: Nokia User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ext Paul Kyzivat Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com> <46BC0C2B.5080000@nokia.com> <033301c7db58$b01cc930$640fa8c0@cis.neustar.com> <46BC7AD4.2030809@nokia.com> <034101c7db61$55c2d110$640fa8c0@cis.neustar.c! om> <46C0019F.8080303@nokia.com> <46C06540.2020709@cis! co.com> In-Reply-To: <46C06540.2020709@cisco.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Aug 2007 12:36:21.0955 (UTC) FILETIME=[E2CC4930:01C7DF38] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e 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 I think you are unnecessarily mixing what is put in the From field of an INVITE with having a nickname in a certain chat room. If you really want identities to stick, and also be of "external" origin, then obviously the SIP URI that you put in the From gives you exactly these properties. You should not confuse that identity with the nickname. In the model I am assuming, the nickname is an *additional* handle that users can pick for themselves in certain chat rooms. In fact, I'd really like to scope these nicknames to the chat server, simply because that's the model IRC has and then basically you get rid of this ambiguity of having the 'Aki' in sipwg chat be different than the 'Aki' in the apparea chat. This would also mean that the namespace on the chat server is shared by both the rooms and the nicks, but I think that's completely fine. I also strongly feel that if you don't agree with the above model for nicknames, then ultimately we are better off ignoring them and just using SIP URIs as identities in MSRP chats rather than inventing our own way of doing nicknames using the display-name (and possibly GRUU) that is incompatible with current systems. Perhaps we could just use SIP to invite to an IRC session or perhaps a Jabber session to interwork with the "legacy" systems. But let me repeat it one more time: this is *not* some trivial user interface trick; nicknames are used as on-the-wire identifiers of chat room participants in current systems. I've yet seen anyone dispute this fact. Cheers, Aki ext Paul Kyzivat wrote: > Aki, > > I'm not going to respond point by point below, because it will just > confuse things. (I'm not entirely in line with Brian, or others, yet > though I thought we were getting close.) But let me explain my reasoning > behind "non unique nicknames": > > - IMO per-chatroom nicknames aren't good enough in general, > though they may be appropriate in some cases. When there > is a set of related chat rooms that are visited by many of > the same people then you would like some confidence that > a nickname references the same person in all of them. > (I would not like to be surprised to find that "Aki" > wasn't you in one ietf-sip-related chatroom.) So IMO there > must be *some provision* for nicknames to be reserved to a > particular person on a broader basis than one chatroom. > > - If there is an ability to reserve a nickname for multiple > chatrooms, then there must be some agency responsible for > doing so. But we certainly don't want to endorse a single > such agency. If there are to be multiple agencies assigning > nicknames, then nicknames will only be unique within a > particular agency. > > - If I have reserved my nickname with some particular agency > then, IMO, I should be able to use that with any chatroom. > The set of chatrooms frequented by a community of users may > not all be managed by the same entity. In this case, two > users may have reserved the "same" nickname from different > nickname agencies. And these may be used in the same chatroom, > leading to a "collision". > > As I was originally conceiving this, the nicknames were all scoped by > the name of the assigning agency (a domain name). (Note that this is > entirely compatible with a chatroom serving as a default nickname > assigning agency for participants.) Hence as long as you consider the > nickname to include that domain name there aren't really any collisions. > It is only if you choose not to display the domain name part that there > are collisions. I considered that to be a UI issue that could be solved > in many ways. > - there could be a default nickname agency/domain per room or server. > The UI could suppress the default domain when displaying nicknames, > but display it (using "@" notation) otherwise. > - When displaying nicknames, a UI could suppress the domain from all > nicknames from the same domain as the user's own nickname. > - The UI could suppress the domains of all the nicknames, but assign > a suffix (e.g. (2), (3)) to distinguish duplicates, or display > duplicates with different colors, etc. > > Personally, I think that concept would still be entirely workable. But I > have been able to agree with some of the other ideas that have been > proposed. > > A somewhat separate issue has been the routability of nicknames. The one > part of that which has been present from the beginning of the proposal > from you guys has been routability via MSRP via the To address in the > CPIM header. While I don't have a particular problem with that I find it > limiting since it only works for IM. If nicknames are to be routable for > one medium then I think they ought to work for other media as well. In > general I think that means that they must be usable for routing sip. > > If nicknames were always of the form @ (before the UI > fiddles with them for display purposes) then it is natural to think that > they could be turned into a URI, like sip:@, and then be > routable. If the domain happens to be served by the same server that > handles a chatroom, then participant status in a chatroom can be used to > influence the routing rules. If the domain server doesn't happen to be > collocated with a chatroom it can still forward requests using a variety > of interesting policies. > > However others wanted to separate the routability from the name itself. > Hence there came the notion of having the *usage* of a nickname in a > conference be associated with some routable URI. The nickname is of > course associated with a participant, and hence with the contact address > of that participant. So, if you want to route something to a participant > you have selected by nickname you could route to the corresponding > contact address. But if the participant chooses to be anonymous, then > that doesn't work. So, somebody suggested having the focus assign > surrogate contact addresses (gruus) for those participants that choose > to be anonymous. While this wasn't my original concept, I have no > problem with it. It seems to work fine, and separates the nickname for > routability. That means that external nickname agencies don't have to > deal with that. > > Brian took that one step further: Qualification of a nickname with a > domain is only necessary during the process of associating a nickname > with a conference participant. That domain need not be exposed to other > participants. Instead, other participants see only the name part, and > distinguish them based on their routable contact address - either the > real one or the surrogate gruu. His motivation (if I can put words in > his mouth) seemed to be to allow multiple participants to use the same > nickname (the displayed part) even if they were all using the focus > itself as the nickname assigning agency. > > Personally I could care less about this last aspect. I think it has the > downside of preventing some participants from making multiple > connections and having them be perceived as being from the "same" > person. And I don't especially care about using the focus as the > nickname assigning agency - I think it is a mechanism that should be > supported but rarely used. (But that is just my opinion. I'm happy for > others to feel differently.) > > Separating the nickname from the URI used for routability doesn't turn > the nickname into a display name in the way that we have come to know > and love display names in sip. The key difference is that the nickname > usage is controlled and authorized, so that participants have a set of > useful conclusions they can draw when they see particular nicknames. > > IMO there is probably still a bit of fine tuning to do here, but we are > on a productive track that can result in something that works for chat, > works for other conferences, is flexible, is reasonably easy to > implement, and that can have a reasonable UI. > > To be constructive, I'll suggest the following, picking from things that > have already been discussed in this thread: > > - The MSRP nickname request be allowed with either just or with > @. > > - The name-only form is a request to assign the name within > a domain unique to the focus, for the duration of participation, and > then associate it with the participant. This can fail if the name > is already in use by a participant with a different identity. > > - The @ form requests that the focus verify with a > server for the domain that the requester is allowed to use > the nickname, and then associate it with the participant. > This can fail if the focus doesn't support it, if it doesn't > know how to do verification with that domain, or if verification > fails. > > - Eventually there will be some other, more general, mechanism for > doing temporary nickname assignment and nickname association, > independent of MSRP. That is still TBD. > > - Nicknames don't appear in CPIM From/To headers. Instead, the > sip contact address of the participant appears. If the user is > anonymous, then a surrogate URI provided by the focus appears. > > - The association between nicknames and contact addresses is learned > by each participant via an enhancement to the conference event > package. The nicknames delivered this way always are of the > @ form. > > - The chat UI is responsible for obtaining nicknames corresponding > to received messages and rendering them in a user-friendly way. > If this is burdensome, we could consider having the focus > include the nickname as a display name in the CPIM From header. > (I'm not wild about it, but it is a possible optimization.) > > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 15 15:04:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILO8L-00027b-LY; Wed, 15 Aug 2007 15:02:21 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ILO8J-00027U-SN for simple-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 15:02:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILO8J-000251-E1 for simple@ietf.org; Wed, 15 Aug 2007 15:02:19 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILO8H-0004R4-Rt for simple@ietf.org; Wed, 15 Aug 2007 15:02:19 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 Aug 2007 15:02:17 -0400 X-IronPort-AV: i="4.19,268,1183348800"; d="scan'208"; a="128970674:sNHT76567372" 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 l7FJ2Hwl015654; Wed, 15 Aug 2007 15:02: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 l7FJ23mv004920; Wed, 15 Aug 2007 19:02:09 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, 15 Aug 2007 15:01:52 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 15:01:52 -0400 Message-ID: <46C34DA0.5000504@cisco.com> Date: Wed, 15 Aug 2007 15:01:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com> <46BC0C2B.5080000@nokia.com> <033301c7db58$b01cc930$640fa8c0@cis.neustar.com> <46BC7AD4.2030809@nokia.com> <034101c7db61$55c2d110$640fa8c0@cis.neustar.c! om> <46C0019F.8080303@nokia.com> <46C06540.20207 09@cisco.com> <00a201c7dec6$27d59c70$0600a8c0@cis.neustar.com> In-Reply-To: <00a201c7dec6$27d59c70$0600a8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Aug 2007 19:01:52.0315 (UTC) FILETIME=[BD9120B0:01C7DF6E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15132; t=1187204537; x=1188068537; 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]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20 |To:=20Brian=20Rosen=20; bh=LC0rVqLuGPWTKMlosXO7QAnAsqQVOfMnTW1BhWJElfE=; b=Trkkmm0XpBikca9uFDGnHAknU8gRn0bQH3sff1jLaBZFre4d32xpHSwG5uIIvWUTAQbHZOzx Qtn1QPaNk2PCKU80gEFMDdQC6EFfbrV4+5VixbY/OlldZEVlGTG97eje; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 1.7 (+) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 Cc: 'Miguel Garcia' , 'Aki Niemi' , '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 Rosen wrote: > I am okay with all of this. I assume that: >> then ..... This can fail if the name >> is already in use by a participant with a different identity. > Is a policy issue at the server; the server could have a policy that said it > allowed it. The UI has to cope. Yes. By saying "may fail" I was explicitly not saying "must fail". However if there have been two requests for the same nickname, and they aren't from sessions of the same user, then if they both succeed then each must be assigned a different domain name part of the nickname, so that the full nickname is unambiguous. This can be arranged by the focus managing multiple domains for nicknames. Whether any implementation would actually want to do this is tbd. But the UI must cope, with two situations: - multiple nicknames that differ only in the domain part - having a requested nickname be rejected Paul > Brian > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, August 13, 2007 10:06 AM >> To: Aki Niemi >> Cc: ext Brian Rosen; 'Miguel Garcia'; 'SIMPLE mailing list' >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >> >> Aki, >> >> I'm not going to respond point by point below, because it will just >> confuse things. (I'm not entirely in line with Brian, or others, yet >> though I thought we were getting close.) But let me explain my reasoning >> behind "non unique nicknames": >> >> - IMO per-chatroom nicknames aren't good enough in general, >> though they may be appropriate in some cases. When there >> is a set of related chat rooms that are visited by many of >> the same people then you would like some confidence that >> a nickname references the same person in all of them. >> (I would not like to be surprised to find that "Aki" >> wasn't you in one ietf-sip-related chatroom.) So IMO there >> must be *some provision* for nicknames to be reserved to a >> particular person on a broader basis than one chatroom. >> >> - If there is an ability to reserve a nickname for multiple >> chatrooms, then there must be some agency responsible for >> doing so. But we certainly don't want to endorse a single >> such agency. If there are to be multiple agencies assigning >> nicknames, then nicknames will only be unique within a >> particular agency. >> >> - If I have reserved my nickname with some particular agency >> then, IMO, I should be able to use that with any chatroom. >> The set of chatrooms frequented by a community of users may >> not all be managed by the same entity. In this case, two >> users may have reserved the "same" nickname from different >> nickname agencies. And these may be used in the same chatroom, >> leading to a "collision". >> >> As I was originally conceiving this, the nicknames were all scoped by >> the name of the assigning agency (a domain name). (Note that this is >> entirely compatible with a chatroom serving as a default nickname >> assigning agency for participants.) Hence as long as you consider the >> nickname to include that domain name there aren't really any collisions. >> It is only if you choose not to display the domain name part that there >> are collisions. I considered that to be a UI issue that could be solved >> in many ways. >> - there could be a default nickname agency/domain per room or server. >> The UI could suppress the default domain when displaying nicknames, >> but display it (using "@" notation) otherwise. >> - When displaying nicknames, a UI could suppress the domain from all >> nicknames from the same domain as the user's own nickname. >> - The UI could suppress the domains of all the nicknames, but assign >> a suffix (e.g. (2), (3)) to distinguish duplicates, or display >> duplicates with different colors, etc. >> >> Personally, I think that concept would still be entirely workable. But I >> have been able to agree with some of the other ideas that have been >> proposed. >> >> A somewhat separate issue has been the routability of nicknames. The one >> part of that which has been present from the beginning of the proposal >> from you guys has been routability via MSRP via the To address in the >> CPIM header. While I don't have a particular problem with that I find it >> limiting since it only works for IM. If nicknames are to be routable for >> one medium then I think they ought to work for other media as well. In >> general I think that means that they must be usable for routing sip. >> >> If nicknames were always of the form @ (before the UI >> fiddles with them for display purposes) then it is natural to think that >> they could be turned into a URI, like sip:@, and then be >> routable. If the domain happens to be served by the same server that >> handles a chatroom, then participant status in a chatroom can be used to >> influence the routing rules. If the domain server doesn't happen to be >> collocated with a chatroom it can still forward requests using a variety >> of interesting policies. >> >> However others wanted to separate the routability from the name itself. >> Hence there came the notion of having the *usage* of a nickname in a >> conference be associated with some routable URI. The nickname is of >> course associated with a participant, and hence with the contact address >> of that participant. So, if you want to route something to a participant >> you have selected by nickname you could route to the corresponding >> contact address. But if the participant chooses to be anonymous, then >> that doesn't work. So, somebody suggested having the focus assign >> surrogate contact addresses (gruus) for those participants that choose >> to be anonymous. While this wasn't my original concept, I have no >> problem with it. It seems to work fine, and separates the nickname for >> routability. That means that external nickname agencies don't have to >> deal with that. >> >> Brian took that one step further: Qualification of a nickname with a >> domain is only necessary during the process of associating a nickname >> with a conference participant. That domain need not be exposed to other >> participants. Instead, other participants see only the name part, and >> distinguish them based on their routable contact address - either the >> real one or the surrogate gruu. His motivation (if I can put words in >> his mouth) seemed to be to allow multiple participants to use the same >> nickname (the displayed part) even if they were all using the focus >> itself as the nickname assigning agency. >> >> Personally I could care less about this last aspect. I think it has the >> downside of preventing some participants from making multiple >> connections and having them be perceived as being from the "same" >> person. And I don't especially care about using the focus as the >> nickname assigning agency - I think it is a mechanism that should be >> supported but rarely used. (But that is just my opinion. I'm happy for >> others to feel differently.) >> >> Separating the nickname from the URI used for routability doesn't turn >> the nickname into a display name in the way that we have come to know >> and love display names in sip. The key difference is that the nickname >> usage is controlled and authorized, so that participants have a set of >> useful conclusions they can draw when they see particular nicknames. >> >> IMO there is probably still a bit of fine tuning to do here, but we are >> on a productive track that can result in something that works for chat, >> works for other conferences, is flexible, is reasonably easy to >> implement, and that can have a reasonable UI. >> >> To be constructive, I'll suggest the following, picking from things that >> have already been discussed in this thread: >> >> - The MSRP nickname request be allowed with either just or with >> @. >> >> - The name-only form is a request to assign the name within >> a domain unique to the focus, for the duration of participation, and >> then associate it with the participant. This can fail if the name >> is already in use by a participant with a different identity. >> >> - The @ form requests that the focus verify with a >> server for the domain that the requester is allowed to use >> the nickname, and then associate it with the participant. >> This can fail if the focus doesn't support it, if it doesn't >> know how to do verification with that domain, or if verification >> fails. >> >> - Eventually there will be some other, more general, mechanism for >> doing temporary nickname assignment and nickname association, >> independent of MSRP. That is still TBD. >> >> - Nicknames don't appear in CPIM From/To headers. Instead, the >> sip contact address of the participant appears. If the user is >> anonymous, then a surrogate URI provided by the focus appears. >> >> - The association between nicknames and contact addresses is learned >> by each participant via an enhancement to the conference event >> package. The nicknames delivered this way always are of the >> @ form. >> >> - The chat UI is responsible for obtaining nicknames corresponding >> to received messages and rendering them in a user-friendly way. >> If this is burdensome, we could consider having the focus >> include the nickname as a display name in the CPIM From header. >> (I'm not wild about it, but it is a possible optimization.) >> >> Paul >> >> Aki Niemi wrote: >>> ext Brian Rosen wrote: >>>> In line. It's not so bad Aki, really. >>> Perhaps I'll be the judge of that. ;) >>> >>>>> You say the nickname is a string for which no-one guarantees >> uniqueness. >>>>> A non-unique string does not a unique handle for the user make. >>>> The UI can make it unique any way it wants to. >>>> The word "handle" can be used in a UI sense or a program/protocol >> sense. >>>> The string is for the UI, the URI is for the program/protocol. >>> Again, this is counter to all existing systems, so you better first >>> explain what is so horribly broken with IRC and Jabber that SIMPLE needs >>> to behave differently. >>> >>>>> In other words, now the user does *not* get to pick its nickname (and >>>>> know that nobody else can use that same nickname), and instead the >>>>> server generates one for the user. Completely opposite to how Jabber >> and >>>>> IRC work. >>>> I don't know where you got that idea. The user picks a nickname. The >>>> server doesn't generate strings, only the URI, and, in my proposal, >> only if >>>> it requests anonymity. Otherwise the URI is the AoR. >>> I know you have all along argued for this idea that we just use the >>> display-name for the purposes of a nickname. However, that is not how >>> current systems work. >>> >>>> The server MAY, by policy, restrict nicknames to be unique. The client >> MUST >>>> handle non unique strings. We always have unique URIs. >>> This is nonsensical. Can you please explain where this requirement for >>> non-unique nicknames comes from? >>> >>>>> Sure it's a local issue. But guess what happens if, say, the Psi >>>>> developers ever find out about the SIMPLE chat spec and (lo and >> behold) >>>>> try to accommodate it into their *existing* UI. >>>> They can either restrict use of their existing UI to existing servers, >>>> restrict to servers that don't allow non-unique nicknames, or be >>>> incompatible with the standard, their choice. >>> Well I tend to think we are here to serve the implementor community, and >>> not vice versa. If the standard makes no sense, then we clearly aren't >>> serving them well (especially if we now, after 20 years of running >>> systems, come up with a concept that says is the same thing but isn't). >>> >>>>> And in any case, nobody has yet to demonstrate what is so horribly >>>>> broken with the way existing systems use nicknames so that SIMPLE >> needs >>>>> to muck with it. >>>> Non unique nicknames with local display of something different has been >>>> done, right? We didn't invent that idea. >>> Where has it been done? Not in IRC or Jabber, so yes I think you did >>> invent that idea on your own. >>> >>>>> What you say has no bearing on how that URI is generated. The nickname >>>>> can just as easily be part of that address. >>>> No, it cannot, at least without a lot of mucking around, or the >> restriction >>>> that uniqueness is to the server and not the chat. Lots of existing >>>> implementations won't work with THAT restriction. >>> I don't understand. Could you elaborate on which existing systems you're >>> referring to here, and what exactly you mean by "mucking around"? >>> >>>>> I just don't get at which point in this thread we concluded that since >>>>> we need the ability for the *user* to select its own nickname, we need >>>>> the server to dish out a random GRUU for him. That just doesn't make >> any >>>>> sense to me. >>>> In my proposal, you only get the GRUU if you request anonymity. In >> that >>>> case, you NEED a GRUU (or something equivalent). If you don't need >>>> anonymity, then you don't need a URI other than your AoR at all, so >> don't >>>> make one up. >>> Right, I understand you're proposing that we simply use the display name >>> as a "nickname". In addition, you've proposed this additional mechanism >>> to request anonymity. This is something you've been proposing as long as >>> I remember. And as long as I remember, I've said this is *not* how >>> nicknames work in other systems. >>> >>>> A nickname needs a string for the UI. We supply said string. We don't >> use >>>> the string to make an address out of. That's pretty simple, isn't it? >>> Simple and useless, I might add. >>> >>> Can we forget about UIs for a moment? We don't do UIs here, and if you >>> look at IRC or Jabber, they definitely use the nickname as an >>> on-the-wire identifier of a channel/chat room participant. Do you >> disagree? >>> Now, in your proposal, you use the GRUU as an on-the-wire identifier, >>> correct? >>> >>> You must admit these are a different concept altogether. >>> >>>> The uniqueness issue is a forward looking one. If you EVER want to be >> able >>>> to have non unique nicknames, you need to do it from day one. >>> The point is, by design, you NEVER want to be able to have nicknames >>> collide. That's the whole point! >>> >>>> Not so fast. If it's fine to scope to the chatroom, then you have a >>>> chat34@chats.example.com as the domain of the chat, and you are back to >> a >>>> complex URI construction rule if you use the string in a URI. >>> There is nothing complex about it: >>> >>>>> >>> How is that complex? >>> >>> Cheers, >>> Aki >>> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 15 16:17:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPH3-0007hL-8s; Wed, 15 Aug 2007 16:15:25 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ILPH1-0007PO-Er for simple-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 16:15:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPH0-0007Kj-W7 for simple@ietf.org; Wed, 15 Aug 2007 16:15:23 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILPGz-000897-JA for simple@ietf.org; Wed, 15 Aug 2007 16:15:22 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1ILPGh-0005vY-BR; Wed, 15 Aug 2007 15:15:05 -0500 From: "Brian Rosen" To: "'Aki Niemi'" , "'ext Paul Kyzivat'" Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Wed, 15 Aug 2007 16:15:13 -0400 Message-ID: <01cb01c7df78$ff816c50$0600a8c0@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: AcffePs1L7rYmfLtT02BBZUzAaxfTg== 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: e1924de3f9fb68e58c31920136007eb1 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 Are we constrained to current system behavior? Is the fact that there are systems that use the nickname as an on-the-wire address a constraint? We've proposed you use AoRs or anonymous GRUUs for addressing. Is that a problem, or just different? I am aware of conference systems that permit nicknames for UI purposes where the nickname is NOT used for addressing, it's just for UI, but to make it work, the nick traverses the wire. Do we wish to outlaw that kind of system? Is it a really big issue to PERMIT name collisions (as long as there is no addressing ambiguity)? A particular server can have a more restrictive policy of course. Is that really a problem? The problem with your position is that the Aki in one chat server can be different from the Aki in another. I don't see the difference between conflicts in the world, a particular service or a particular chat room. I presume when you say "server" you really mean "service". If you don't then I really don't understand what you are looking for. I am unique in all of AOL, not just the particular server that is providing a chatroom for me. The only requirement, taking your position, is uniqueness to chat room, since the addressing via nickname is always within the chatroom. Uniqueness to a service is a UI convention you happen to like because IRQ does that. You know there are services more restrictive than that, yet you want uniqueness to service. I want uniqueness to a domain, which is different from a service only in that the domain is not necessarily the domain of the service. This allows me to register in a domain of my choice and use that nickname in multiple services, assuming these services accept my nickname service. I don't see the big difference, and it seems to provide useful capability. I won't mind having a server that restricts, by policy to only accept names issued by it's own domain. That mimics AOL behavior, for example. Brian > -----Original Message----- > From: Aki Niemi [mailto:aki.niemi@nokia.com] > Sent: Wednesday, August 15, 2007 8:36 AM > To: ext Paul Kyzivat > Cc: ext Brian Rosen; 'Miguel Garcia'; 'SIMPLE mailing list' > Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > I think you are unnecessarily mixing what is put in the From field of an > INVITE with having a nickname in a certain chat room. If you really want > identities to stick, and also be of "external" origin, then obviously > the SIP URI that you put in the From gives you exactly these properties. > You should not confuse that identity with the nickname. > > In the model I am assuming, the nickname is an *additional* handle that > users can pick for themselves in certain chat rooms. In fact, I'd really > like to scope these nicknames to the chat server, simply because that's > the model IRC has and then basically you get rid of this ambiguity of > having the 'Aki' in sipwg chat be different than the 'Aki' in the > apparea chat. This would also mean that the namespace on the chat server > is shared by both the rooms and the nicks, but I think that's completely > fine. > > I also strongly feel that if you don't agree with the above model for > nicknames, then ultimately we are better off ignoring them and just > using SIP URIs as identities in MSRP chats rather than inventing our own > way of doing nicknames using the display-name (and possibly GRUU) that > is incompatible with current systems. Perhaps we could just use SIP to > invite to an IRC session or perhaps a Jabber session to interwork with > the "legacy" systems. > > But let me repeat it one more time: this is *not* some trivial user > interface trick; nicknames are used as on-the-wire identifiers of chat > room participants in current systems. I've yet seen anyone dispute this > fact. > > Cheers, > Aki > > ext Paul Kyzivat wrote: > > Aki, > > > > I'm not going to respond point by point below, because it will just > > confuse things. (I'm not entirely in line with Brian, or others, yet > > though I thought we were getting close.) But let me explain my reasoning > > behind "non unique nicknames": > > > > - IMO per-chatroom nicknames aren't good enough in general, > > though they may be appropriate in some cases. When there > > is a set of related chat rooms that are visited by many of > > the same people then you would like some confidence that > > a nickname references the same person in all of them. > > (I would not like to be surprised to find that "Aki" > > wasn't you in one ietf-sip-related chatroom.) So IMO there > > must be *some provision* for nicknames to be reserved to a > > particular person on a broader basis than one chatroom. > > > > - If there is an ability to reserve a nickname for multiple > > chatrooms, then there must be some agency responsible for > > doing so. But we certainly don't want to endorse a single > > such agency. If there are to be multiple agencies assigning > > nicknames, then nicknames will only be unique within a > > particular agency. > > > > - If I have reserved my nickname with some particular agency > > then, IMO, I should be able to use that with any chatroom. > > The set of chatrooms frequented by a community of users may > > not all be managed by the same entity. In this case, two > > users may have reserved the "same" nickname from different > > nickname agencies. And these may be used in the same chatroom, > > leading to a "collision". > > > > As I was originally conceiving this, the nicknames were all scoped by > > the name of the assigning agency (a domain name). (Note that this is > > entirely compatible with a chatroom serving as a default nickname > > assigning agency for participants.) Hence as long as you consider the > > nickname to include that domain name there aren't really any collisions. > > It is only if you choose not to display the domain name part that there > > are collisions. I considered that to be a UI issue that could be solved > > in many ways. > > - there could be a default nickname agency/domain per room or server. > > The UI could suppress the default domain when displaying nicknames, > > but display it (using "@" notation) otherwise. > > - When displaying nicknames, a UI could suppress the domain from all > > nicknames from the same domain as the user's own nickname. > > - The UI could suppress the domains of all the nicknames, but assign > > a suffix (e.g. (2), (3)) to distinguish duplicates, or display > > duplicates with different colors, etc. > > > > Personally, I think that concept would still be entirely workable. But I > > have been able to agree with some of the other ideas that have been > > proposed. > > > > A somewhat separate issue has been the routability of nicknames. The one > > part of that which has been present from the beginning of the proposal > > from you guys has been routability via MSRP via the To address in the > > CPIM header. While I don't have a particular problem with that I find it > > limiting since it only works for IM. If nicknames are to be routable for > > one medium then I think they ought to work for other media as well. In > > general I think that means that they must be usable for routing sip. > > > > If nicknames were always of the form @ (before the UI > > fiddles with them for display purposes) then it is natural to think that > > they could be turned into a URI, like sip:@, and then be > > routable. If the domain happens to be served by the same server that > > handles a chatroom, then participant status in a chatroom can be used to > > influence the routing rules. If the domain server doesn't happen to be > > collocated with a chatroom it can still forward requests using a variety > > of interesting policies. > > > > However others wanted to separate the routability from the name itself. > > Hence there came the notion of having the *usage* of a nickname in a > > conference be associated with some routable URI. The nickname is of > > course associated with a participant, and hence with the contact address > > of that participant. So, if you want to route something to a participant > > you have selected by nickname you could route to the corresponding > > contact address. But if the participant chooses to be anonymous, then > > that doesn't work. So, somebody suggested having the focus assign > > surrogate contact addresses (gruus) for those participants that choose > > to be anonymous. While this wasn't my original concept, I have no > > problem with it. It seems to work fine, and separates the nickname for > > routability. That means that external nickname agencies don't have to > > deal with that. > > > > Brian took that one step further: Qualification of a nickname with a > > domain is only necessary during the process of associating a nickname > > with a conference participant. That domain need not be exposed to other > > participants. Instead, other participants see only the name part, and > > distinguish them based on their routable contact address - either the > > real one or the surrogate gruu. His motivation (if I can put words in > > his mouth) seemed to be to allow multiple participants to use the same > > nickname (the displayed part) even if they were all using the focus > > itself as the nickname assigning agency. > > > > Personally I could care less about this last aspect. I think it has the > > downside of preventing some participants from making multiple > > connections and having them be perceived as being from the "same" > > person. And I don't especially care about using the focus as the > > nickname assigning agency - I think it is a mechanism that should be > > supported but rarely used. (But that is just my opinion. I'm happy for > > others to feel differently.) > > > > Separating the nickname from the URI used for routability doesn't turn > > the nickname into a display name in the way that we have come to know > > and love display names in sip. The key difference is that the nickname > > usage is controlled and authorized, so that participants have a set of > > useful conclusions they can draw when they see particular nicknames. > > > > IMO there is probably still a bit of fine tuning to do here, but we are > > on a productive track that can result in something that works for chat, > > works for other conferences, is flexible, is reasonably easy to > > implement, and that can have a reasonable UI. > > > > To be constructive, I'll suggest the following, picking from things that > > have already been discussed in this thread: > > > > - The MSRP nickname request be allowed with either just or with > > @. > > > > - The name-only form is a request to assign the name within > > a domain unique to the focus, for the duration of participation, and > > then associate it with the participant. This can fail if the name > > is already in use by a participant with a different identity. > > > > - The @ form requests that the focus verify with a > > server for the domain that the requester is allowed to use > > the nickname, and then associate it with the participant. > > This can fail if the focus doesn't support it, if it doesn't > > know how to do verification with that domain, or if verification > > fails. > > > > - Eventually there will be some other, more general, mechanism for > > doing temporary nickname assignment and nickname association, > > independent of MSRP. That is still TBD. > > > > - Nicknames don't appear in CPIM From/To headers. Instead, the > > sip contact address of the participant appears. If the user is > > anonymous, then a surrogate URI provided by the focus appears. > > > > - The association between nicknames and contact addresses is learned > > by each participant via an enhancement to the conference event > > package. The nicknames delivered this way always are of the > > @ form. > > > > - The chat UI is responsible for obtaining nicknames corresponding > > to received messages and rendering them in a user-friendly way. > > If this is burdensome, we could consider having the focus > > include the nickname as a display name in the CPIM From header. > > (I'm not wild about it, but it is a possible optimization.) > > > > Paul > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 15 18:34:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRQ7-000385-Vh; Wed, 15 Aug 2007 18:32:55 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ILRQ7-00037z-Gh for simple-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 18:32:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRQ7-00037r-48 for simple@ietf.org; Wed, 15 Aug 2007 18:32:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILRQ5-0003XZ-Nl for simple@ietf.org; Wed, 15 Aug 2007 18:32:55 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 Aug 2007 18:32:51 -0400 X-IronPort-AV: i="4.19,268,1183348800"; d="scan'208"; a="128991241:sNHT71517708" 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 l7FMWplm012347; Wed, 15 Aug 2007 18:32:51 -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 l7FMWpjI027496; Wed, 15 Aug 2007 22:32:51 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, 15 Aug 2007 18:32:50 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 18:32:50 -0400 Message-ID: <46C37F13.7090306@cisco.com> Date: Wed, 15 Aug 2007 18:32:51 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com> <46BC0C2B.5080000@nokia.com> <033301c7db58$b01cc930$640fa8c0@cis.neustar.com> <46BC7AD4.2030809@nokia.com> <034101c7db61$55c2d110$640fa8c0@cis.neustar.c! om> <46C0019F.8080303@nokia.com> <46C06540.2020709@cis! co.com> <46C2F343.5020300@nokia.com> In-Reply-To: <46C2F343.5020300@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Aug 2007 22:32:50.0645 (UTC) FILETIME=[36850050:01C7DF8C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12724; t=1187217171; x=1188081171; 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]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20 |To:=20Aki=20Niemi=20; bh=oJT1Tqqmfnqah8YzB8sN8YCffN/xusTS1uPM/vkOY0U=; b=0uqOu/nWiwP5jKc3sGZ6lee4T1DdbMMG1p4o+P2TjVnF8DE8DoiXp/ZaoarhebDUCOTUCJ2F Kqem2ZNgrLrM3bTppCz9FFlQhzszfBAJfKzR+I1hcSjvQ+ZeaIl642fV; 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: 187ae6c2eea74946c0ab707161f6256d 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 Aki Niemi wrote: > I think you are unnecessarily mixing what is put in the From field of an > INVITE with having a nickname in a certain chat room. If you really want > identities to stick, and also be of "external" origin, then obviously > the SIP URI that you put in the From gives you exactly these properties. > You should not confuse that identity with the nickname. I never mentioned the From field of an INVITE in what I wrote. I did mention "identity" once which isn't quite the same thing. I do believe that nicknames serve as a representation of identity. In general I decide who I am chatting with by the nickname I see. If that isn't who I think it is I may say something inappropriate. So it is important. Similarly, it is proposed that messages be delivered to destinations identified by nickname. Again its important that the binding to a nickname be understood. > In the model I am assuming, the nickname is an *additional* handle that > users can pick for themselves in certain chat rooms. Maybe I misunderstand and have your opinions mixed up with others, but I thought part of your concept is that the actual address of the user can be kept confidential, so that other participants will only know that user by the nickname. In that case it becomes the *only* handle, rather than just an *additional* handle. In either case, in some sense it is not what is in the protocol that is important, but rather what is in the UI. If the nickname is what is displayed in the UI, and what the user uses to decide how to target a response, then the *real* identity is irrelevant. > In fact, I'd really > like to scope these nicknames to the chat server, Do you mean the *server*, or the *room* (focus)? The distinction is a big one. If we make it the *server* then it is like the domain that brian and I have been talking about, except that you require users of a focus to always use nicknames from a single domain. > simply because that's > the model IRC has and then basically you get rid of this ambiguity of > having the 'Aki' in sipwg chat be different than the 'Aki' in the > apparea chat. This would also mean that the namespace on the chat server > is shared by both the rooms and the nicks, but I think that's completely > fine. Its still not fine if its FCFS for nicknames based on current participants in conferences on the server. Because then we have that *today* Aki is you in sipwg and apparea, but when I connect tomorrow the Aki I see may be somebody else. (Yes, I agree that some chat rooms may be run that way, and it should be possible to run one that way if you want, but it better not be the only way.) > I also strongly feel that if you don't agree with the above model for > nicknames, then ultimately we are better off ignoring them and just > using SIP URIs as identities in MSRP chats rather than inventing our own > way of doing nicknames using the display-name (and possibly GRUU) that > is incompatible with current systems. I'm not sure what you mean by incompatible with current systems. Today we have a variety of chat clients, and a variety of chat protocols. Many of the clients support multiple protocols. IMO it is important that it be possible to preserve the user experience through a given chat client once it has incorporated an adapter to the new protocol. What we do in the protocol is less important if we can see how the chat client can deal with it. Meanwhile we can have a protocol that is adaptable to the new stuff we want to be able to support, such as full multimedia conferences, etc. Paul > Perhaps we could just use SIP to > invite to an IRC session or perhaps a Jabber session to interwork with > the "legacy" systems. > > But let me repeat it one more time: this is *not* some trivial user > interface trick; nicknames are used as on-the-wire identifiers of chat > room participants in current systems. I've yet seen anyone dispute this > fact. > > Cheers, > Aki > > ext Paul Kyzivat wrote: >> Aki, >> >> I'm not going to respond point by point below, because it will just >> confuse things. (I'm not entirely in line with Brian, or others, yet >> though I thought we were getting close.) But let me explain my reasoning >> behind "non unique nicknames": >> >> - IMO per-chatroom nicknames aren't good enough in general, >> though they may be appropriate in some cases. When there >> is a set of related chat rooms that are visited by many of >> the same people then you would like some confidence that >> a nickname references the same person in all of them. >> (I would not like to be surprised to find that "Aki" >> wasn't you in one ietf-sip-related chatroom.) So IMO there >> must be *some provision* for nicknames to be reserved to a >> particular person on a broader basis than one chatroom. >> >> - If there is an ability to reserve a nickname for multiple >> chatrooms, then there must be some agency responsible for >> doing so. But we certainly don't want to endorse a single >> such agency. If there are to be multiple agencies assigning >> nicknames, then nicknames will only be unique within a >> particular agency. >> >> - If I have reserved my nickname with some particular agency >> then, IMO, I should be able to use that with any chatroom. >> The set of chatrooms frequented by a community of users may >> not all be managed by the same entity. In this case, two >> users may have reserved the "same" nickname from different >> nickname agencies. And these may be used in the same chatroom, >> leading to a "collision". >> >> As I was originally conceiving this, the nicknames were all scoped by >> the name of the assigning agency (a domain name). (Note that this is >> entirely compatible with a chatroom serving as a default nickname >> assigning agency for participants.) Hence as long as you consider the >> nickname to include that domain name there aren't really any collisions. >> It is only if you choose not to display the domain name part that there >> are collisions. I considered that to be a UI issue that could be solved >> in many ways. >> - there could be a default nickname agency/domain per room or server. >> The UI could suppress the default domain when displaying nicknames, >> but display it (using "@" notation) otherwise. >> - When displaying nicknames, a UI could suppress the domain from all >> nicknames from the same domain as the user's own nickname. >> - The UI could suppress the domains of all the nicknames, but assign >> a suffix (e.g. (2), (3)) to distinguish duplicates, or display >> duplicates with different colors, etc. >> >> Personally, I think that concept would still be entirely workable. But I >> have been able to agree with some of the other ideas that have been >> proposed. >> >> A somewhat separate issue has been the routability of nicknames. The one >> part of that which has been present from the beginning of the proposal >> from you guys has been routability via MSRP via the To address in the >> CPIM header. While I don't have a particular problem with that I find it >> limiting since it only works for IM. If nicknames are to be routable for >> one medium then I think they ought to work for other media as well. In >> general I think that means that they must be usable for routing sip. >> >> If nicknames were always of the form @ (before the UI >> fiddles with them for display purposes) then it is natural to think that >> they could be turned into a URI, like sip:@, and then be >> routable. If the domain happens to be served by the same server that >> handles a chatroom, then participant status in a chatroom can be used to >> influence the routing rules. If the domain server doesn't happen to be >> collocated with a chatroom it can still forward requests using a variety >> of interesting policies. >> >> However others wanted to separate the routability from the name itself. >> Hence there came the notion of having the *usage* of a nickname in a >> conference be associated with some routable URI. The nickname is of >> course associated with a participant, and hence with the contact address >> of that participant. So, if you want to route something to a participant >> you have selected by nickname you could route to the corresponding >> contact address. But if the participant chooses to be anonymous, then >> that doesn't work. So, somebody suggested having the focus assign >> surrogate contact addresses (gruus) for those participants that choose >> to be anonymous. While this wasn't my original concept, I have no >> problem with it. It seems to work fine, and separates the nickname for >> routability. That means that external nickname agencies don't have to >> deal with that. >> >> Brian took that one step further: Qualification of a nickname with a >> domain is only necessary during the process of associating a nickname >> with a conference participant. That domain need not be exposed to other >> participants. Instead, other participants see only the name part, and >> distinguish them based on their routable contact address - either the >> real one or the surrogate gruu. His motivation (if I can put words in >> his mouth) seemed to be to allow multiple participants to use the same >> nickname (the displayed part) even if they were all using the focus >> itself as the nickname assigning agency. >> >> Personally I could care less about this last aspect. I think it has the >> downside of preventing some participants from making multiple >> connections and having them be perceived as being from the "same" >> person. And I don't especially care about using the focus as the >> nickname assigning agency - I think it is a mechanism that should be >> supported but rarely used. (But that is just my opinion. I'm happy for >> others to feel differently.) >> >> Separating the nickname from the URI used for routability doesn't turn >> the nickname into a display name in the way that we have come to know >> and love display names in sip. The key difference is that the nickname >> usage is controlled and authorized, so that participants have a set of >> useful conclusions they can draw when they see particular nicknames. >> >> IMO there is probably still a bit of fine tuning to do here, but we are >> on a productive track that can result in something that works for chat, >> works for other conferences, is flexible, is reasonably easy to >> implement, and that can have a reasonable UI. >> >> To be constructive, I'll suggest the following, picking from things that >> have already been discussed in this thread: >> >> - The MSRP nickname request be allowed with either just or with >> @. >> >> - The name-only form is a request to assign the name within >> a domain unique to the focus, for the duration of participation, and >> then associate it with the participant. This can fail if the name >> is already in use by a participant with a different identity. >> >> - The @ form requests that the focus verify with a >> server for the domain that the requester is allowed to use >> the nickname, and then associate it with the participant. >> This can fail if the focus doesn't support it, if it doesn't >> know how to do verification with that domain, or if verification >> fails. >> >> - Eventually there will be some other, more general, mechanism for >> doing temporary nickname assignment and nickname association, >> independent of MSRP. That is still TBD. >> >> - Nicknames don't appear in CPIM From/To headers. Instead, the >> sip contact address of the participant appears. If the user is >> anonymous, then a surrogate URI provided by the focus appears. >> >> - The association between nicknames and contact addresses is learned >> by each participant via an enhancement to the conference event >> package. The nicknames delivered this way always are of the >> @ form. >> >> - The chat UI is responsible for obtaining nicknames corresponding >> to received messages and rendering them in a user-friendly way. >> If this is burdensome, we could consider having the focus >> include the nickname as a display name in the CPIM From header. >> (I'm not wild about it, but it is a possible optimization.) >> >> 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 Aug 15 18:49: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 1ILRdy-0003US-S1; Wed, 15 Aug 2007 18:47:14 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ILRdx-0003P4-Su for simple-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 18:47:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRdx-0003MT-FN for simple@ietf.org; Wed, 15 Aug 2007 18:47:13 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILRdv-00041b-QS for simple@ietf.org; Wed, 15 Aug 2007 18:47:13 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 15 Aug 2007 15:47:11 -0700 X-IronPort-AV: i="4.19,268,1183359600"; d="scan'208"; a="513911699:sNHT72302624" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7FMlBht000989; Wed, 15 Aug 2007 15:47:11 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7FMlAF6022082; Wed, 15 Aug 2007 22:47:10 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 18:47:10 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 18:47:10 -0400 Message-ID: <46C3826F.20305@cisco.com> Date: Wed, 15 Aug 2007 18:47:11 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <01cb01c7df78$ff816c50$0600a8c0@cis.neustar.com> In-Reply-To: <01cb01c7df78$ff816c50$0600a8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Aug 2007 22:47:10.0180 (UTC) FILETIME=[36D7A240:01C7DF8E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13109; t=1187218031; x=1188082031; c=relaxed/simple; s=sjdkim1004; 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]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20; bh=efYyYFOp3uUcAUHar3ki0j7ycRWFo1O2CfFNKcz1sxQ=; b=QzUe0Fpx2gmso587DqlKSNW0FNlJazlMOg1fm4h5EYfa4XoNeLVAmST1cFFgfkmZgFrZOutX qtCHSp0HC1dDCFcpbfh68ftX4wDL5e053KkIJN6sAC8Yps6qrCzqucs0tWdAAqoIHXAWW2i6hy fmkRVQugBCofv/XFg7w+y49DQ=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: 'Miguel Garcia' , 'Aki Niemi' , '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 with Brian. One point added below. Paul Brian Rosen wrote: > Are we constrained to current system behavior? Is the fact that there are > systems that use the nickname as an on-the-wire address a constraint? > We've proposed you use AoRs or anonymous GRUUs for addressing. Is that a > problem, or just different? > > I am aware of conference systems that permit nicknames for UI purposes where > the nickname is NOT used for addressing, it's just for UI, but to make it > work, the nick traverses the wire. Do we wish to outlaw that kind of > system? > > Is it a really big issue to PERMIT name collisions (as long as there is no > addressing ambiguity)? A particular server can have a more restrictive > policy of course. Is that really a problem? > > The problem with your position is that the Aki in one chat server can be > different from the Aki in another. I don't see the difference between > conflicts in the world, a particular service or a particular chat room. I > presume when you say "server" you really mean "service". If you don't then > I really don't understand what you are looking for. I am unique in all of > AOL, not just the particular server that is providing a chatroom for me. > The only requirement, taking your position, is uniqueness to chat room, > since the addressing via nickname is always within the chatroom. Uniqueness > to a service is a UI convention you happen to like because IRQ does that. > You know there are services more restrictive than that, yet you want > uniqueness to service. > > I want uniqueness to a domain, which is different from a service only in > that the domain is not necessarily the domain of the service. This allows > me to register in a domain of my choice and use that nickname in multiple > services, assuming these services accept my nickname service. I don't see > the big difference, and it seems to provide useful capability. I won't mind > having a server that restricts, by policy to only accept names issued by > it's own domain. That mimics AOL behavior, for example. I will *tolerate* a server with that restriction under certain circumstances, but I will *mind* - I won't like it at all. I'll be wanting all those services to become more flexible. Whether they will go along is TBD. > Brian > > >> -----Original Message----- >> From: Aki Niemi [mailto:aki.niemi@nokia.com] >> Sent: Wednesday, August 15, 2007 8:36 AM >> To: ext Paul Kyzivat >> Cc: ext Brian Rosen; 'Miguel Garcia'; 'SIMPLE mailing list' >> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI >> >> I think you are unnecessarily mixing what is put in the From field of an >> INVITE with having a nickname in a certain chat room. If you really want >> identities to stick, and also be of "external" origin, then obviously >> the SIP URI that you put in the From gives you exactly these properties. >> You should not confuse that identity with the nickname. >> >> In the model I am assuming, the nickname is an *additional* handle that >> users can pick for themselves in certain chat rooms. In fact, I'd really >> like to scope these nicknames to the chat server, simply because that's >> the model IRC has and then basically you get rid of this ambiguity of >> having the 'Aki' in sipwg chat be different than the 'Aki' in the >> apparea chat. This would also mean that the namespace on the chat server >> is shared by both the rooms and the nicks, but I think that's completely >> fine. >> >> I also strongly feel that if you don't agree with the above model for >> nicknames, then ultimately we are better off ignoring them and just >> using SIP URIs as identities in MSRP chats rather than inventing our own >> way of doing nicknames using the display-name (and possibly GRUU) that >> is incompatible with current systems. Perhaps we could just use SIP to >> invite to an IRC session or perhaps a Jabber session to interwork with >> the "legacy" systems. >> >> But let me repeat it one more time: this is *not* some trivial user >> interface trick; nicknames are used as on-the-wire identifiers of chat >> room participants in current systems. I've yet seen anyone dispute this >> fact. >> >> Cheers, >> Aki >> >> ext Paul Kyzivat wrote: >>> Aki, >>> >>> I'm not going to respond point by point below, because it will just >>> confuse things. (I'm not entirely in line with Brian, or others, yet >>> though I thought we were getting close.) But let me explain my reasoning >>> behind "non unique nicknames": >>> >>> - IMO per-chatroom nicknames aren't good enough in general, >>> though they may be appropriate in some cases. When there >>> is a set of related chat rooms that are visited by many of >>> the same people then you would like some confidence that >>> a nickname references the same person in all of them. >>> (I would not like to be surprised to find that "Aki" >>> wasn't you in one ietf-sip-related chatroom.) So IMO there >>> must be *some provision* for nicknames to be reserved to a >>> particular person on a broader basis than one chatroom. >>> >>> - If there is an ability to reserve a nickname for multiple >>> chatrooms, then there must be some agency responsible for >>> doing so. But we certainly don't want to endorse a single >>> such agency. If there are to be multiple agencies assigning >>> nicknames, then nicknames will only be unique within a >>> particular agency. >>> >>> - If I have reserved my nickname with some particular agency >>> then, IMO, I should be able to use that with any chatroom. >>> The set of chatrooms frequented by a community of users may >>> not all be managed by the same entity. In this case, two >>> users may have reserved the "same" nickname from different >>> nickname agencies. And these may be used in the same chatroom, >>> leading to a "collision". >>> >>> As I was originally conceiving this, the nicknames were all scoped by >>> the name of the assigning agency (a domain name). (Note that this is >>> entirely compatible with a chatroom serving as a default nickname >>> assigning agency for participants.) Hence as long as you consider the >>> nickname to include that domain name there aren't really any collisions. >>> It is only if you choose not to display the domain name part that there >>> are collisions. I considered that to be a UI issue that could be solved >>> in many ways. >>> - there could be a default nickname agency/domain per room or server. >>> The UI could suppress the default domain when displaying nicknames, >>> but display it (using "@" notation) otherwise. >>> - When displaying nicknames, a UI could suppress the domain from all >>> nicknames from the same domain as the user's own nickname. >>> - The UI could suppress the domains of all the nicknames, but assign >>> a suffix (e.g. (2), (3)) to distinguish duplicates, or display >>> duplicates with different colors, etc. >>> >>> Personally, I think that concept would still be entirely workable. But I >>> have been able to agree with some of the other ideas that have been >>> proposed. >>> >>> A somewhat separate issue has been the routability of nicknames. The one >>> part of that which has been present from the beginning of the proposal >>> from you guys has been routability via MSRP via the To address in the >>> CPIM header. While I don't have a particular problem with that I find it >>> limiting since it only works for IM. If nicknames are to be routable for >>> one medium then I think they ought to work for other media as well. In >>> general I think that means that they must be usable for routing sip. >>> >>> If nicknames were always of the form @ (before the UI >>> fiddles with them for display purposes) then it is natural to think that >>> they could be turned into a URI, like sip:@, and then be >>> routable. If the domain happens to be served by the same server that >>> handles a chatroom, then participant status in a chatroom can be used to >>> influence the routing rules. If the domain server doesn't happen to be >>> collocated with a chatroom it can still forward requests using a variety >>> of interesting policies. >>> >>> However others wanted to separate the routability from the name itself. >>> Hence there came the notion of having the *usage* of a nickname in a >>> conference be associated with some routable URI. The nickname is of >>> course associated with a participant, and hence with the contact address >>> of that participant. So, if you want to route something to a participant >>> you have selected by nickname you could route to the corresponding >>> contact address. But if the participant chooses to be anonymous, then >>> that doesn't work. So, somebody suggested having the focus assign >>> surrogate contact addresses (gruus) for those participants that choose >>> to be anonymous. While this wasn't my original concept, I have no >>> problem with it. It seems to work fine, and separates the nickname for >>> routability. That means that external nickname agencies don't have to >>> deal with that. >>> >>> Brian took that one step further: Qualification of a nickname with a >>> domain is only necessary during the process of associating a nickname >>> with a conference participant. That domain need not be exposed to other >>> participants. Instead, other participants see only the name part, and >>> distinguish them based on their routable contact address - either the >>> real one or the surrogate gruu. His motivation (if I can put words in >>> his mouth) seemed to be to allow multiple participants to use the same >>> nickname (the displayed part) even if they were all using the focus >>> itself as the nickname assigning agency. >>> >>> Personally I could care less about this last aspect. I think it has the >>> downside of preventing some participants from making multiple >>> connections and having them be perceived as being from the "same" >>> person. And I don't especially care about using the focus as the >>> nickname assigning agency - I think it is a mechanism that should be >>> supported but rarely used. (But that is just my opinion. I'm happy for >>> others to feel differently.) >>> >>> Separating the nickname from the URI used for routability doesn't turn >>> the nickname into a display name in the way that we have come to know >>> and love display names in sip. The key difference is that the nickname >>> usage is controlled and authorized, so that participants have a set of >>> useful conclusions they can draw when they see particular nicknames. >>> >>> IMO there is probably still a bit of fine tuning to do here, but we are >>> on a productive track that can result in something that works for chat, >>> works for other conferences, is flexible, is reasonably easy to >>> implement, and that can have a reasonable UI. >>> >>> To be constructive, I'll suggest the following, picking from things that >>> have already been discussed in this thread: >>> >>> - The MSRP nickname request be allowed with either just or with >>> @. >>> >>> - The name-only form is a request to assign the name within >>> a domain unique to the focus, for the duration of participation, and >>> then associate it with the participant. This can fail if the name >>> is already in use by a participant with a different identity. >>> >>> - The @ form requests that the focus verify with a >>> server for the domain that the requester is allowed to use >>> the nickname, and then associate it with the participant. >>> This can fail if the focus doesn't support it, if it doesn't >>> know how to do verification with that domain, or if verification >>> fails. >>> >>> - Eventually there will be some other, more general, mechanism for >>> doing temporary nickname assignment and nickname association, >>> independent of MSRP. That is still TBD. >>> >>> - Nicknames don't appear in CPIM From/To headers. Instead, the >>> sip contact address of the participant appears. If the user is >>> anonymous, then a surrogate URI provided by the focus appears. >>> >>> - The association between nicknames and contact addresses is learned >>> by each participant via an enhancement to the conference event >>> package. The nicknames delivered this way always are of the >>> @ form. >>> >>> - The chat UI is responsible for obtaining nicknames corresponding >>> to received messages and rendering them in a user-friendly way. >>> If this is burdensome, we could consider having the focus >>> include the nickname as a display name in the CPIM From header. >>> (I'm not wild about it, but it is a possible optimization.) >>> >>> 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 Aug 15 18:56: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 1ILRl8-0003R7-PK; Wed, 15 Aug 2007 18:54:38 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ILRl7-0003R0-GY for simple-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 18:54:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRl7-0003Qr-6u for simple@ietf.org; Wed, 15 Aug 2007 18:54:37 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILRl5-00055r-MH for simple@ietf.org; Wed, 15 Aug 2007 18:54:37 -0400 Received: (qmail 26951 invoked by uid 0); 15 Aug 2007 22:54:34 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 15 Aug 2007 22:54:34 -0000 Message-ID: <00a201c7df8f$3c5577a0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Aki Niemi" , "ext Paul Kyzivat" References: <46ADDC1E.10301@nsn.com> <03f601c7d86c$7846c540$640fa8c0@cis.neustar.com> <46B817CD.8090205@nsn.com><071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com><46B88C95.60606@nsn.com><082b01c7d90a$31041540$640fa8c0@cis.neustar.com><46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com><087901c7d931$917494f0$640fa8c0@cis.neustar.com><46B8E20F.60804@cisco.com><089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com><46B907DB.8080301@cisco.com><08c901c7d953$0880f310$640fa8c0@cis.neustar.com><46B95BFF.8090304@nsn.com><094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com><46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com><021601c7dac9$707165f0$640fa8c0@cis.neustar.com><46BB8C63.1050100@cisco.com><023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com><46BC0482.6080401@nsn.com> <46BC0C2B.5080000@nokia.com><033301c7db58$b01cc930$640fa8c0@cis.neustar.com><46BC7AD4.2030809@nokia.com><034101c7db61$55c2d110$640fa8c0@cis.neustar.c! om><46C0019F.8080303@nokia.com> <46C06540.2020709@cis! co.com> <46C2F343.5020300@nokia.com> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Thu, 16 Aug 2007 00:54:28 +0200 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.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Aki, > But let me repeat it one more time: this is *not* some trivial user > interface trick; nicknames are used as on-the-wire identifiers of chat > room participants in current systems. I've yet seen anyone dispute > this fact. Perhaps, but then probably there's other identifiers in the message (say chat session id) that is sent on-the-wire which implicitly scopes the nickname It appears to me that what is being called a "nickname" consists of two parts: an identifier and a scope/context. The identifier is typically used for display in UIs, the combination of identifier and scope is used for addressing/routing (and therefore required to be unique, at least for the duration of the chat session). AFAIK most chat systems don't have the additional concept of a "displayname" like SIP has, i.e. a string which is only used for display but not for addressing (at least not by the protocol, it can be used as "addressing" between the user and the UI) "scope" or "context" here can be the chat room, the chat server, or its domain. There is a hierarchy here, and I sense there is consensus on how to represent it: sip:chatroom@chatserver.domain. What remains under debate is how the "identifier" is added to this base (and then the meta-discussion whether this should be mandated, or provided as guidelines or examples). Uniqueness of the _identifier_ part (i.e. that which gets presented to users) across a set of chatrooms, in the same or in different domains, is a constraint that could be enforced. It would require some distributed protocol, probably best left out of scope / FFS for now. Note that such a "uniqueness scope" is not necessarily representable as a (part of a) single URI - nor is it required to be. This is _orthogonal_ to the design choices for the syntax of the URI. I would suggest to focus the discussion on the syntax of URIs to be used for addressing of users within chat sessions first. Regards, Jeroen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 15 19:00: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 1ILRol-0006CF-MW; Wed, 15 Aug 2007 18:58:23 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ILRok-00067A-G0 for simple-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 18:58:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRok-00065E-4z for simple@ietf.org; Wed, 15 Aug 2007 18:58:22 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILRoi-0005EF-Pw for simple@ietf.org; Wed, 15 Aug 2007 18:58:22 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 15 Aug 2007 15:58:20 -0700 X-IronPort-AV: i="4.19,268,1183359600"; d="scan'208"; a="8410320:sNHT22046322" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7FMwKKD028223; Wed, 15 Aug 2007 15:58:20 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l7FMwJiF018693; Wed, 15 Aug 2007 22:58:19 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, 15 Aug 2007 18:58:19 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 18:58:18 -0400 Message-ID: <46C38509.4090406@cisco.com> Date: Wed, 15 Aug 2007 18:58:17 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46B817CD.8090205@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com> <46BC0C2B.5080000@nokia.com> <033301c7db58$b01cc930$640fa8c0@cis.neustar.com> <46BC7AD4.2030809@nokia.com> <034101c7db61$55c2d110$640fa8c0@cis.neustar.c! om> <46C0019F.8080303@nokia.com> <46C06540.2020709@cis! co.com> <46C2F343.5020300@nokia.com> In-Reply-To: <46C2F343.5020300@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Aug 2007 22:58:18.0953 (UTC) FILETIME=[C5764B90:01C7DF8F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1578; t=1187218700; x=1188082700; c=relaxed/simple; s=sjdkim3002; 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]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20; bh=slLQ8opDRWYc6T7vOSWW2NHZha2tZMV6CPS9jJGPRqQ=; b=C7z4er7tTY2rfKhpUxhXt9GTZjpnNmicGytr04exExOxFdJPtLsfpB4M4CWbxY9gXJv2UJ6o boHUGsQZ8AFFTRFF5ixZO5DHZlszm4yYdlXqV5YN1AXrcjbjRIvougkE; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Aki Niemi wrote: > I think you are unnecessarily mixing what is put in the From field of an > INVITE with having a nickname in a certain chat room. If you really want > identities to stick, and also be of "external" origin, then obviously > the SIP URI that you put in the From gives you exactly these properties. > You should not confuse that identity with the nickname. I thought that for awhile. In particular I did, and still do, see some value in a special kind of anonymizer - one that allows me to sign up for one, or several, aliases that I can use when I want to hide my true identity. If I had that, then I could pick an alias and use it when participating in one or several conferences where I want to be recognized consistently as the same person without revealing who I actually am, and without allowing correlation to my participation elsewhere using my actual identity or other aliases. That could replace some of the use of nicknames. But I don't think it will replace it all. That is where I have been educated in this discussion. In particular, there are cases where the conference organizer will insist on actually knowing who the participants are. However it is still willing to hide that information from the other participants. That is where the nicknames we are discussing become important, because they still provide the anonymity properties and other properties I mentioned above with respect to other participants of the conference, even if not to the administrators of the conference. Thanks, Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 15 19:51: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 1ILScS-00064y-4L; Wed, 15 Aug 2007 19:49:44 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ILScR-00064r-3Y for simple-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 19:49:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILScQ-00064b-P1 for simple@ietf.org; Wed, 15 Aug 2007 19:49:42 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILScQ-0006RV-0P for simple@ietf.org; Wed, 15 Aug 2007 19:49:42 -0400 Received: (qmail 14113 invoked by uid 0); 15 Aug 2007 23:50:53 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 15 Aug 2007 23:50:53 -0000 Message-ID: <012c01c7df96$ef64fd50$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Aki Niemi" Date: Thu, 16 Aug 2007 01:49:35 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 1.5 (+) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: simple@ietf.org Subject: [Simple] assignment of nicknames in niemi-simple-chat 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="===============0535099381==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0535099381== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0128_01C7DFA7.B2BE0AC0" This is a multi-part message in MIME format. ------=_NextPart_000_0128_01C7DFA7.B2BE0AC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Aki, Regarding the selection / assignment of nicknames: 1) Wouldn't it make sense to start with an initial nickname proposed as part of the SDP? similar to codec negotiation. The server could propose an alternative if the desired nickname is already taken. The common scenario would probably be that the desired nickname is obtained Say: a=nickname:alice;display="Alice" and if it's already used, the server could answer a=nickname: alice_1 2) Referring to my earlier mail, if we split the definition of "nickname" as "identifier" (alice) and "scope" ( chatroom@chatserver.domain ), the user has no choice in selecting a scope (it's always a particular chat session (active) at a specific server). Therefore there's lots of redundant information in the example in 9.2. Suggestion: MSRP d93kswow NICKNAME To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp Set-Nickname: "Alice" alice -------d93kswow$The above also does not tie things to "sip:", and does not depend on the UA knowing the structure of URIs used by the server (better not to have a dependency)Regards,Jeroen ------=_NextPart_000_0128_01C7DFA7.B2BE0AC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Aki,
 
Regarding the selection / assignment of = nicknames:
 
1) Wouldn't it make sense to start with = an initial=20 nickname proposed as part of the SDP? similar to codec negotiation. The = server=20 could propose an alternative if the desired nickname is already taken. = The=20 common scenario would probably be that the desired nickname is=20 obtained
 
Say:
 
a=3Dnickname:alice;display=3D"Alice"
 
and if it's already used, the server = could=20 answer
 
a=3Dnickname: alice_1
 
2) Referring to my earlier mail, if we = split the=20 definition of "nickname" as "identifier" (alice) and "scope" ( chatroom@chatserver.domain= ), the=20 user has no choice in selecting a scope (it's always a particular chat = session=20 (active) at a specific server). Therefore there's lots of redundant = information=20 in the example in 9.2.
 
Suggestion:
 
MSRP d93kswow NICKNAME
   To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
   From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
   Set-Nickname: "Alice" alice
 -------d93kswow$
The =
above also does not tie things to "sip:", and does not depend on the UA =
knowing the structure 
of URIs used by the server (better not to have =
a =
dependency)
Regards,
Jeroen
 
 
------=_NextPart_000_0128_01C7DFA7.B2BE0AC0-- --===============0535099381== 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 --===============0535099381==-- From simple-bounces@ietf.org Wed Aug 15 20:08:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILSsc-0001oe-3w; Wed, 15 Aug 2007 20:06:26 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ILSsa-0001oU-JJ for simple-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 20:06:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILSsa-0001mq-77 for simple@ietf.org; Wed, 15 Aug 2007 20:06:24 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILSsZ-0006xn-7P for simple@ietf.org; Wed, 15 Aug 2007 20:06:24 -0400 Received: (qmail 5079 invoked by uid 0); 16 Aug 2007 00:06:00 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 16 Aug 2007 00:06:00 -0000 Message-ID: <001901c7df99$4442b040$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Aki Niemi" References: <012c01c7df96$ef64fd50$0601a8c0@BEMBUSTER> Subject: Re: [Simple] assignment of nicknames in niemi-simple-chat Date: Thu, 16 Aug 2007 02:06:16 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 1.5 (+) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1378366582==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1378366582== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C7DFAA.078FD6D0" This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C7DFAA.078FD6D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In fact, it would probably be better to let the server assign the complete URI, and only allow users to select / change their displayname. And you could perhaps reuse the "i=" attribute for this purpose ( RFC4566: The "i=" field is intended to provide a free-form human-readable description of the session or the purpose of a media stream. It is not suitable for parsing by automata.) So: m=message 7654 TCP/MSRP * i=Alice a=accept-types:message/cpim text/plain text/html a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp a=chatroom:private-messages Set-Nickname would then simply become: Set-Nickname: "Alice" or perhaps this could be done using UPDATE or reINVITE, without a need for MSRP messages Regards, Jeroen ----- Original Message ----- From: Jeroen van Bemmel To: Aki Niemi Cc: simple@ietf.org Sent: Thursday, August 16, 2007 1:49 AM Subject: [Simple] assignment of nicknames in niemi-simple-chat Aki, Regarding the selection / assignment of nicknames: 1) Wouldn't it make sense to start with an initial nickname proposed as part of the SDP? similar to codec negotiation. The server could propose an alternative if the desired nickname is already taken. The common scenario would probably be that the desired nickname is obtained Say: a=nickname:alice;display="Alice" and if it's already used, the server could answer a=nickname: alice_1 2) Referring to my earlier mail, if we split the definition of "nickname" as "identifier" (alice) and "scope" ( chatroom@chatserver.domain ), the user has no choice in selecting a scope (it's always a particular chat session (active) at a specific server). Therefore there's lots of redundant information in the example in 9.2. Suggestion: MSRP d93kswow NICKNAME To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp Set-Nickname: "Alice" alice -------d93kswow$The above also does not tie things to "sip:", and does not depend on the UA knowing the structure of URIs used by the server (better not to have a dependency)Regards,Jeroen ------------------------------------------------------------------------------ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------=_NextPart_000_0015_01C7DFAA.078FD6D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In fact, it would probably be better to = let the=20 server assign the complete URI, and only allow users to select / change = their=20 displayname.
And you could perhaps reuse the "i=3D" = attribute for=20 this purpose ( RFC4566: The "i=3D" field is intended to provide a = free-form=20 human-readable description of the session or the purpose of a media=20 stream.  It is not suitable for parsing by automata.)
 
So:
m=3Dmessage 7654 TCP/MSRP = *
i=3DAlice
a=3Daccept-types:message/cpim text/plain=20 text/html
a=3Dpath:msrp://client.atlanta.example.com:7654/jshA7weztas;= tcp
a=3Dchatroom:private-messages
 
Set-Nickname would then simply = become:
 
Set-Nickname: "Alice"
 
or perhaps this could be done using UPDATE or = reINVITE,=20 without a need for MSRP messages
 
Regards,
Jeroen
 
----- Original Message -----
From:=20 Jeroen = van=20 Bemmel
Sent: Thursday, August 16, 2007 = 1:49=20 AM
Subject: [Simple] assignment of = nicknames=20 in niemi-simple-chat

Aki,
 
Regarding the selection / assignment = of=20 nicknames:
 
1) Wouldn't it make sense to start = with an=20 initial nickname proposed as part of the SDP? similar to codec = negotiation.=20 The server could propose an alternative if the desired nickname is = already=20 taken. The common scenario would probably be that the desired nickname = is=20 obtained
 
Say:
 
a=3Dnickname:alice;display=3D"Alice"
 
and if it's already used, the server = could=20 answer
 
a=3Dnickname: alice_1
 
2) Referring to my earlier mail, if = we split the=20 definition of "nickname" as "identifier" (alice) and "scope" ( chatroom@chatserver.domain= ), the=20 user has no choice in selecting a scope (it's always a particular chat = session=20 (active) at a specific server). Therefore there's lots of redundant=20 information in the example in 9.2.
 
Suggestion:
 
MSRP d93kswow NICKNAME
   To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
   From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
   Set-Nickname: "Alice" alice
 -------d93kswow$
The =
above also does not tie things to "sip:", and does not depend on the UA =
knowing the structure 
of URIs used by the server (better not to have =
a =
dependency)
Regards,
Jeroen
 
 

_______________________________________________
Simple = mailing=20 = list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple<= BR> ------=_NextPart_000_0015_01C7DFAA.078FD6D0-- --===============1378366582== 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 --===============1378366582==-- From simple-bounces@ietf.org Thu Aug 16 02:15: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 1ILYbh-0007Pj-Tq; Thu, 16 Aug 2007 02:13:21 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ILYbg-0007Pd-IH for simple-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 02:13:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILYbg-0007PP-5q for simple@ietf.org; Thu, 16 Aug 2007 02:13:20 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILYbf-0003nd-Bg for simple@ietf.org; Thu, 16 Aug 2007 02:13:19 -0400 Received: (qmail 16951 invoked by uid 0); 16 Aug 2007 06:12:57 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 16 Aug 2007 06:12:57 -0000 Message-ID: <002201c7dfcc$87014bc0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Aki Niemi" , "ext Paul Kyzivat" References: <46C06540.2020709@cis! co.com><46C2F343.5020300@nokia.com> <00a201c7df8f$3c5577a0$0601a8c0@BEMBUSTER> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Thu, 16 Aug 2007 08:13:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 > I would suggest to focus the discussion on the syntax of URIs to be > used for addressing of users within chat sessions first. > As has been suggested before, I personally think that the URI should be a temporary GRUU. By its usage it needs to be globally reachable, and by giving the chat server control over the URIs, it is able to mint temporary GRUUs that are unique to the user+session in the chatroom@chatserver.domain context. Users could then go ahead and REGISTER their assigned temporary GRUU at their registrar, to indicate they are reachable in that virtual room. I see no need to include the nickname's displayname in the URI. Users could omit it to be anonymous (and server could have a policy to not allow that), and conference events can be used to learn these displaynames along with the temporary GRUU of each user Regards, Jeroen PS Is it possible / there a need to have multiple ongoing sessions per chat room? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 16 04:02: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 1ILaHW-0003Hu-EM; Thu, 16 Aug 2007 04:00:38 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ILaHV-0003Ho-OH for simple-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 04:00:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILaHR-0003Hb-9W for simple@ietf.org; Thu, 16 Aug 2007 04:00:33 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILaHQ-0005xH-HV for simple@ietf.org; Thu, 16 Aug 2007 04:00:33 -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 l7G7xlih006917; Thu, 16 Aug 2007 11:00:12 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 11:00:10 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 11:00:09 +0300 Received: from [10.144.23.155] ([10.144.23.155]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 11:00:08 +0300 Message-ID: <46C40408.2020106@nsn.com> Date: Thu, 16 Aug 2007 11:00:08 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: SIMPLE mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2007 08:00:08.0691 (UTC) FILETIME=[76C6A430:01C7DFDB] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Paul Kyzivat , Niemi Aki Petteri Subject: [Simple] [MSRP chat] Conference scoped Nicknames 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: Having trying to follow the discussion about nicknames, I have the feeling that we are going in circles, and this makes me think that we are making a wrong assumption or we have a wrong requirement here. Let me be frank. All the complexity of nicknames is not in the encoding part, but it is in the requirement to make it work with generalized nicknames that can be issued by any service provider. Assuming you have a service provider that allows you to choose your SIP URI, I don't see much difference between requesting a new SIP URI or requesting a general nickname. I think we are mixing both. I would like to remind people what is our approved charter: 4. A mechanism for initiating and managing Instant Message group chat. Any mechanisms created for managing Instant Message group chat are intended to provide a bridge to the conferencing protocols that will be defined in XCON. They will be limited in scope to address only simple Instant Message chat with nicknames and will not attempt to address complex conferencing concepts such as sidebars. Their design must anticipate operating in conjunction with the conferencing protocols XCON is working towards. I therefore propose to reduce our scope to provide a solution that works with nicknames that are issued and consumed by the chat room server only. Furthermore, I propose that we take the assumption that chat room servers have a limitation in that they can only accept nicknames which are used by the chat room server itself. This does not preclude any work on generalized nicknames, rather, we say that they are not applicable to chat rooms. I would encourage people to think this as a compromise that does not limit our mobility for generalized nicknames, but makes a deployable solution today for MSRP chat. Can we, for the the nth time, try to agree on this limitation and re-instantiate the discussion restricted to MSRP chat nicknames? /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 From simple-bounces@ietf.org Thu Aug 16 05:17: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 1ILbS9-0001yK-16; Thu, 16 Aug 2007 05:15:41 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ILbS7-0001y9-H8 for simple-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 05:15:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILbS7-0001xs-57 for simple@ietf.org; Thu, 16 Aug 2007 05:15: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 1ILbS4-0007iC-QX for simple@ietf.org; Thu, 16 Aug 2007 05:15:38 -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 l7G9FRZA009431; Thu, 16 Aug 2007 12:15:31 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 12:15:29 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 12:15:29 +0300 Received: from [172.21.41.118] ([172.21.41.118]) by esebe106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 12:15:28 +0300 Message-ID: <46C415AD.7080608@nokia.com> Date: Thu, 16 Aug 2007 12:15:25 +0300 From: Aki Niemi Organization: Nokia User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ext Paul Kyzivat Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com> <46BC0C2B.5080000@nokia.com> <033301c7db58$b01cc930$640fa8c0@cis.neustar.com> <46BC7AD4.2030809@nokia.com> <034101c7db61$55c2d110$640fa8c0@cis.neustar.c! om> <46C0019F.8080303@nokia.com> <46C06540.2020709@cis! co.com> <46C2F343.5020300@nokia.com> <46C37F13.7090306@cisco.com> In-Reply-To: <46C37F13.7090306@cisco.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2007 09:15:28.0651 (UTC) FILETIME=[FCE1CDB0:01C7DFE5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 ext Paul Kyzivat wrote: > Maybe I misunderstand and have your opinions mixed up with others, but I > thought part of your concept is that the actual address of the user can > be kept confidential, so that other participants will only know that > user by the nickname. In that case it becomes the *only* handle, rather > than just an *additional* handle. I say additional because it wouldn't be the identity (i.e., your asserted SIP ID) with which you join the chat room (i.e., the conference focus). Whether this real ID is shown in the conference event notifications in addition to the nickname is a somewhat orthogonal issue, IMO. > In either case, in some sense it is not what is in the protocol that is > important, but rather what is in the UI. If the nickname is what is > displayed in the UI, and what the user uses to decide how to target a > response, then the *real* identity is irrelevant. I think I agree. But if the nickname is not used on-the-wire to target the response, then things break. I'd be really curious to know how it is intended that UI to cope with colliding nicknames like "Miguel", "Miguel ", and " Miguel", for which the URIs are all GRUUs. What would the roster of this room look like? >> In fact, I'd really >> like to scope these nicknames to the chat server, > > Do you mean the *server*, or the *room* (focus)? The distinction is a > big one. If we make it the *server* then it is like the domain that > brian and I have been talking about, except that you require users of a > focus to always use nicknames from a single domain. I mean the server, like the domain chats.example.com. > Its still not fine if its FCFS for nicknames based on current > participants in conferences on the server. Because then we have that > *today* Aki is you in sipwg and apparea, but when I connect tomorrow the > Aki I see may be somebody else. > > (Yes, I agree that some chat rooms may be run that way, and it should be > possible to run one that way if you want, but it better not be the only > way.) We're not restricting this in any way. Even in the current draft, it is possible to either challenge the NICKNAME method, or tie it in with a specific SIP URI. As an example, the process by which these nicknames would be made to stick could be as follows: 1) User gets a nickname by FCFS basis, 2) User sends a private message to the operator/moderator/owner, and asks to make the nickname stick 3) Moderator does [add any procedure maybe involving email, return-routability checks, web forms, personal visits, CAPTCHAs, whatever], creates credentials and sends them to the user via a private message 4) Now every time the user joins, he is asked to provide said credentials to get the same nickname Existing IRC services like FreeNode have something like this; Jabber could probably accommodate it as well. >> I also strongly feel that if you don't agree with the above model for >> nicknames, then ultimately we are better off ignoring them and just >> using SIP URIs as identities in MSRP chats rather than inventing our own >> way of doing nicknames using the display-name (and possibly GRUU) that >> is incompatible with current systems. > > I'm not sure what you mean by incompatible with current systems. > Today we have a variety of chat clients, and a variety of chat > protocols. Many of the clients support multiple protocols. Can you name them? The only two standard group chat protocols I know of are IRC and Jabber. Can you please elaborate on what the others are? If they are proprietary, at least it would be helpful to get some idea how close to IRC or Jabber they are. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 16 05:42:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILbqi-0004ce-WA; Thu, 16 Aug 2007 05:41:05 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1ILbqh-0004cZ-1u for simple-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 05:41:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILbqg-0004cQ-8V for simple@ietf.org; Thu, 16 Aug 2007 05:41:02 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILbqf-0000PW-7j for simple@ietf.org; Thu, 16 Aug 2007 05:41:02 -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 l7G9ejuu031737; Thu, 16 Aug 2007 12:40:55 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 12:40:40 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 12:40:39 +0300 Received: from [172.21.41.118] ([172.21.41.118]) by esebe106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 12:40:39 +0300 Message-ID: <46C41B93.6020008@nokia.com> Date: Thu, 16 Aug 2007 12:40:35 +0300 From: Aki Niemi Organization: Nokia User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ext Jeroen van Bemmel Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com><46B88C95.60606@nsn.com><082b01c7d90a$31041540$640fa8c0@cis.neustar.com><46B8BCD4.4030800@cisco.com> <46B8BDB4.8080602@nsn.com><087901c7d931$917494f0$640fa8c0@cis.neustar.com><46B8E20F.60804@cisco.com><089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com><46B907DB.8080301@cisco.com><08c901c7d953$0880f310$640fa8c0@cis.neustar.com><46B95BFF.8090304@nsn.com><094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com><46BB068B.9080604@nsn.com> <46BB1ECB.7010001@cisco.com><021601c7dac9$707165f0$640fa8c0@cis.neustar.com><46BB8C63.1050100@cisco.com><023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com><46BC0482.6080401@nsn.com> <46BC0C2B.5080000@nokia.com><033301c7db58$b01cc930$640fa8c0@cis.neustar.com><46BC7AD4.2030809@nokia.com><034101c7db61$55c2d110$640fa8c0@cis.neustar.c! om><46C0019F.8080303@nokia.com> <46C06540.2020709@cis! co.com> <46C2F343.5020300@nokia.com> <00a201c7df8f$3c5577a0$0601a8c0@BEMBUSTER> In-Reply-To: <00a201c7df8f$3c5577a0$0601a8c0@BEMBUSTER> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2007 09:40:39.0268 (UTC) FILETIME=[8147AA40:01C7DFE9] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ext Paul Kyzivat , '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 ext Jeroen van Bemmel wrote: > Perhaps, but then probably there's other identifiers in the message (say > chat session id) that is sent on-the-wire which implicitly scopes the > nickname I was proposing: It appears to me that what is being called a "nickname" consists of two > parts: an identifier and a scope/context. The identifier is typically > used for display in UIs, the combination of identifier and scope is used > for addressing/routing (and therefore required to be unique, at least > for the duration of the chat session). Right. > AFAIK most chat systems don't > have the additional concept of a "displayname" like SIP has, i.e. a > string which is only used for display but not for addressing (at least > not by the protocol, it can be used as "addressing" between the user and > the UI) Yes. I'd also like to point out that the usefulness of the display-name in SIP is debatable. I certainly would not blindly take the display-name and show it to a user on an incoming call. The only name I would show the user is one from the user's own phone book (could call this a petname). And in the absence of a matching entry in the phonebook, I'd display the SIP URI. In case of a non-asserted SIP URI, I'd just tell the user that "Some unknown person, claiming to be sip:... is calling". > "scope" or "context" here can be the chat room, the chat server, or its > domain. There is a hierarchy here, and I sense there is consensus on how > to represent it: sip:chatroom@chatserver.domain. What remains under > debate is how the "identifier" is added to this base (and then the > meta-discussion whether this should be mandated, or provided as > guidelines or examples). I think we're not quite there yet with the model to be able to discuss the syntax. Although I don't think deciding on the syntax is rocket science in this case. :) > Uniqueness of the _identifier_ part (i.e. that which gets presented to > users) across a set of chatrooms, in the same or in different domains, > is a constraint that could be enforced. It would require some > distributed protocol, probably best left out of scope / FFS for now. > Note that such a "uniqueness scope" is not necessarily representable as > a (part of a) single URI - nor is it required to be. This is > _orthogonal_ to the design choices for the syntax of the URI. Clearly, the userparts of SIP URIs can *always* collide; however, within a single domain they cannot. I am arguing that if you intend to have the nickname identity exhibit this global scope (i.e., scope not strictly restricted to either a chat room or a chat server) then we are better off just using the SIP URIs that participants have in the From field of an INVITE. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From DarrylutmostStanley@audience.com Thu Aug 16 10:02:32 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILfvk-0002lV-3F for simple-archive@lists.ietf.org; Thu, 16 Aug 2007 10:02:32 -0400 Received: from catv-5062536d.catv.broadband.hu ([80.98.83.109] helo=lanyi1984.chello.hu) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ILfvj-00088v-L2 for simple-archive@lists.ietf.org; Thu, 16 Aug 2007 10:02:31 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host32872932.audience.com (8.13.1/8.13.1) with SMTP id EGCmU6ST23.192766.xVQ.GAy.3575356542641 for ; Thu, 16 Aug 2007 16:00:52 -0100 Message-ID: <603801c7e00e$22fabc50$6d536250@lanyi1984> From: "Neil Stanley" To: Subject: Improve sperm flavour Date: Thu, 16 Aug 2007 16:00:52 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_6034_01C7E00E.22FABC50" 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.1 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 This is a multi-part message in MIME format. ------=_NextPart_000_6034_01C7E00E.22FABC50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear customer. Girls lie when they say "size doesn't matter" that's just to make us = feel better, The truth is they want their partner to have a huge one, and they will = keep searching until they find it! Now you can be that big man with the new improved and doctor recommended = enlargement pills, Visit us to get your supply before they sell out! ------=_NextPart_000_6034_01C7E00E.22FABC50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Dear = customer.

Girls lie when they say "size = doesn't matter"=20 that's just to make us feel better,

The truth is they want their = partner to have a=20 huge one, and they will keep searching until they find it!

Now you can be that big man with = the new=20 improved and doctor recommended enlargement pills,

Visit us = to get=20 your supply before they sell out!

------=_NextPart_000_6034_01C7E00E.22FABC50-- From simple-bounces@ietf.org Fri Aug 17 10:12:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM2Wt-00013P-8I; Fri, 17 Aug 2007 10:10:23 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IM2Wr-00011Q-SH for simple-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 10:10:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM2Wr-00011H-Ik for simple@ietf.org; Fri, 17 Aug 2007 10:10:21 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM2Wr-00059J-5S for simple@ietf.org; Fri, 17 Aug 2007 10:10:21 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IM2Ul-0002BZ-CV; Fri, 17 Aug 2007 09:08:11 -0500 From: "Brian Rosen" To: "'Aki Niemi'" , "'ext Paul Kyzivat'" References: <46ADDC1E.10301@nsn.com> <071601c7d8f8$8c267c90$640fa8c0@cis.neustar.com> <46B88C95.60606@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com><46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com><46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com><46BC0C2B.5080000@nokia.com> <033301c7db58$b01cc930$640fa8c0@cis.neustar.com> <46BC7AD4.2030809@nokia.com> <034101c7db61$55c2d110$640fa8c0@cis.neustar.c!om> <46C0019F.8080303@nokia.com> <46C06540.2020709@cis! co.com><46C2F343.5020300@nokia.com> <46C37F13.7090306@cisco.com> <46C415AD.7080608@nokia.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Fri, 17 Aug 2007 10:08:11 -0400 Message-ID: <002e01c7e0d8$0f08a110$0700a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46C415AD.7080608@nokia.com> Thread-Index: Acff5kgxyKXqCwsWQwegttixJqshxAA76sDg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 > I say additional because it wouldn't be the identity (i.e., your > asserted SIP ID) with which you join the chat room (i.e., the conference > focus). Whether this real ID is shown in the conference event > notifications in addition to the nickname is a somewhat orthogonal > issue, IMO. Why do you need an additional identity to use for addressing other than for anonymity? If you want anonymity, then you want an anonymous URI, which a GRUU from the focus provides. > I think I agree. But if the nickname is not used on-the-wire to target > the response, then things break. What breaks other than the issue below? > > I'd be really curious to know how it is intended that UI to cope with > colliding nicknames like "Miguel", "Miguel ", and " Miguel", for which > the URIs are all GRUUs. What would the roster of this room look like? Something like ... Miguel ... Miguel ... Miguel Where the first two are "regular" users and the third is anonymous. The URIs can be used to address any messages. The nicknames can be used in the UI for display purposes, presumably with some differentiation viz. Miguel(1), Miguel(2),... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 17 10:47: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 1IM34g-0002v9-9K; Fri, 17 Aug 2007 10:45:18 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IM34e-0002v3-Td for simple-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 10:45:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM34e-0002uv-Iq for simple@ietf.org; Fri, 17 Aug 2007 10:45:16 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM34e-0001AS-0W for simple@ietf.org; Fri, 17 Aug 2007 10:45:16 -0400 Received: (qmail 12673 invoked by uid 0); 17 Aug 2007 14:45:11 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 17 Aug 2007 14:45:11 -0000 Message-ID: <009401c7e0dd$32b40000$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Brian Rosen" , "'Aki Niemi'" , "'ext Paul Kyzivat'" References: co.com><46C2F343.5020300@nokia.com><46C37F13.7090306@cisco.com> <46C415AD.7080608@nokia.com> <002e01c7e0d8$0f08a110$0700a8c0@cis.neustar.com> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Fri, 17 Aug 2007 16:45:03 +0200 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.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Brian, > Something like > > ... Question: does the 'entity' attribute contain an AoR, or a URI that resolves to a user participating in a specific conference session at a specific server? (http://tools.ietf.org/html/draft-ietf-xcon-common-data-model-05#section-4.5.2 says "The element describes a single participant in the conference", it's not clear to me whether that means if the conference context should be reflected in the value). Note also that there's no "nickname" element defined, only "display-text" Should the URI be usable outside the context of the conference? Should users be able to derive the user's AoR from it? The XCON framework talks about a mixed protocol conferencing system, so it could be that miguel.garcia@nsn.com is connected via ISUP. In that case, I suppose communication with that user should go via the conference server? Is it allowed to "optimize" in case both users use SIP? (would go against the centralised model of XCON, right?) In summary, I think the roster would look something like this (as seen at one of the participants): Miguel miguel.garcia@nsn.com Miguel miguel@example.com The last user had 'true', which the conference server stripped (along with the associated-aors, for example) Regards, Jeroen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 17 11:00: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 1IM3Ha-0006EH-OI; Fri, 17 Aug 2007 10:58:38 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IM3Ha-0006E9-72 for simple-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 10:58:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3HZ-0006Ds-Lt for simple@ietf.org; Fri, 17 Aug 2007 10:58:37 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM3HZ-0001gN-0w for simple@ietf.org; Fri, 17 Aug 2007 10:58:37 -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 l7HEvva5019601; Fri, 17 Aug 2007 17:58:23 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 17:58:08 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 17:58:08 +0300 Received: from [172.21.41.113] ([172.21.41.113]) by esebe106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 17:58:07 +0300 Message-ID: <46C5B77B.5090606@nokia.com> Date: Fri, 17 Aug 2007 17:58:03 +0300 From: Aki Niemi Organization: Nokia User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ext Brian Rosen Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com><46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com><46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com><46BC0C2B.5080000@nokia.com> <033301c7db58$b01cc930$640fa8c0@cis.neustar.com> <46BC7AD4.2030809@nokia.com> <034101c7db61$55c2d110$640fa8c0@cis.neustar.c!om> <46C0019F.8080303@nokia.com> <46C06540.2020709@cis! co.com><46C2F343.5020300@nokia.com> <46C37F13.7090306@cisco.com> <46C415AD.7080608@nokia.com> <002e01c7e0d8$0f08a110$0700a8c0@cis.neustar.com> In-Reply-To: <002e01c7e0d8$0f08a110$0700a8c0@cis.neustar.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2007 14:58:07.0680 (UTC) FILETIME=[056E6C00:01C7E0DF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: 'ext Paul Kyzivat' , '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 ext Brian Rosen wrote: >> I'd be really curious to know how it is intended that UI to cope with >> colliding nicknames like "Miguel", "Miguel ", and " Miguel", for which >> the URIs are all GRUUs. What would the roster of this room look like? > Something like > > ... > Miguel > > > ... > Miguel > > > ... > Miguel > > > Where the first two are "regular" users and the third is anonymous. > > The URIs can be used to address any messages. The nicknames can be used in > the UI for display purposes, presumably with some differentiation viz. > Miguel(1), Miguel(2),... I see. So your implementation decided that stripping whitespace was OK to determine whether the nicknames were "equal". I see your UI also decided on one possible scheme to tell them apart. Let's simulate a running discussion: [17:35:05] Miguel(1)-> This chat thing is great. Anyone know how to send a private message? [17:35:40] Miguel(2)-> Hi all! [17:36:01] Miguel(3)-> Ping... Now I decide to reply: [17:36:59] Aki-> Miguel(1): Nope. Might want to try selecting a buddy and right-click. Who is Miguel(1)? One client used an alternative scheme with Miguel_1, Miguel_2 and Miguel_3. So in that chat client, there is no Miguel(1) at all. Of course, Miguel(1) has no idea what his nickname looks like in anyone else's UI. In fact, even the same client implementation may show the Miguels in different order, depending on when they joined. That means that Miguel(1) is Miguel(2) in Brian(2)'s screen, but Miguel_2 in Paul(3)'s screen, which Aki_1(1) thinks is just a little odd. BTW, Aki_1(1) used to be just Aki_1 (he picked that nickname since there already was an Aki in the room), until someone else picked Aki_1 as well, at which point he became Aki_1(1). Or something. Of course, a sane client would probably just drop the nickname (which at this point is a useless piece of information) from the UI and use the URI instead: [17:35:05] chat34@chats.example.com;gr="fe433e334a"-> Hi all! [17:35:10] chat34@chats.example.com;gr="66d7e67ac7"-> Howdy! And so on. I guess I will then reply with: [17:36:50] chat34@chats.example.com;gr="76276dc78a"-> 66d7e67ac7: let's get out of here. I created an IRC channel for us. This is how things break. This is all pretty obvious if you've used IRC. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 17 11:11:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3S7-0006Ww-Si; Fri, 17 Aug 2007 11:09:31 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IM3S6-0006Pt-It for simple-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 11:09:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3S6-0006OF-7Y for simple@ietf.org; Fri, 17 Aug 2007 11:09:30 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM3S5-0001ui-N8 for simple@ietf.org; Fri, 17 Aug 2007 11:09:30 -0400 Received: (qmail 29162 invoked by uid 0); 17 Aug 2007 15:09:01 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 17 Aug 2007 15:09:01 -0000 Message-ID: <00cd01c7e0e0$934e5930$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Aki Niemi" , "ext Brian Rosen" References: <46ADDC1E.10301@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com><46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com><46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com><46BC0C2B.5080000@nokia.com> <033301c7db58$b01cc930$640fa8c0@cis.neustar.com> <46BC7AD4.2030809@nokia.com> <034101c7db61$55c2d110$640fa8c0@cis.neustar.c!om> <46C0019F.8080303@nokia.com><46C06540.2020709@cis! co.com><46C2F343.5020300@nokia.com><46C37F13.7090306@cisco.com> <46C415AD.7080608@nokia.com><002e01c7e0d8$0f08a110$0700a8c0@cis.neustar.com> <46C5B77B.5090606@nokia.com> Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Fri, 17 Aug 2007 17:09:14 +0200 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.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 'ext Paul Kyzivat' , '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 > Let's simulate a running discussion: > > [17:35:05] Miguel(1)-> This chat thing is great. Anyone know how to > send > a private message? > [17:35:40] Miguel(2)-> Hi all! > [17:36:01] Miguel(3)-> Ping... > > Now I decide to reply: > > [17:36:59] Aki-> Miguel(1): Nope. Might want to try selecting a buddy > and right-click. > > Who is Miguel(1)? One client used an alternative scheme with Miguel_1, > Miguel_2 and Miguel_3. So in that chat client, there is no Miguel(1) > at all. > Aki, Obviously, a sanely implemented client would make sure that any local conventions for dealing with duplicate nicknames are never sent across the wire. So in your example, what in your client gets displayed as "Aki -> Miguel(1)" would appear e.g. as "Aki [reply] -> Nope..." at other participants (depending on the conventions that their client implementation is using The scenario above could occur when clients would have the bad habit of including local displaynames in messages they sent (I know some chat clients do this). For MSRP chat, the draft could state that they SHOULD NOT do this. Regards, Jeroen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 17 11:27: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 1IM3hX-0006UG-32; Fri, 17 Aug 2007 11:25:27 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IM3hV-0006U5-8u for simple-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 11:25:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3hU-0006Tw-Tr for simple@ietf.org; Fri, 17 Aug 2007 11:25:24 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM3hU-0003GZ-5n for simple@ietf.org; Fri, 17 Aug 2007 11:25:24 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7HFOj70019761; Fri, 17 Aug 2007 18:25:12 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 18:25:11 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 18:25:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Fri, 17 Aug 2007 18:25:10 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Thread-Index: Acfg4syhM2STzMNGSVSvGNyHeJZqgw== From: To: , , X-OriginalArrivalTime: 17 Aug 2007 15:25:11.0033 (UTC) FILETIME=[CD066E90:01C7E0E2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: pkyzivat@cisco.com, miguel.garcia@nsn.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0364222440==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0364222440== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E0E2.CCA1B90C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E0E2.CCA1B90C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jeroen, People write these messages, not computers. When I write "I agree with = miguel(1)" is your client going to pop up an error? Think about it. Cheers, Aki -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: ext Jeroen van Bemmel L=E4hetetty: 17.08.2007 18:09:33 Vastaanottaja: ext Jeroen van Bemmel;Niemi Aki = (Nokia-TP-MSW/Helsinki);ext Brian Rosen Kopio: ext Paul Kyzivat;Garcia Miguel (NSN - FI/Espoo);SIMPLE mailing = list Aihe: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > Let's simulate a running discussion: > > [17:35:05] Miguel(1)-> This chat thing is great. Anyone know how to > send > a private message? > [17:35:40] Miguel(2)-> Hi all! > [17:36:01] Miguel(3)-> Ping... > > Now I decide to reply: > > [17:36:59] Aki-> Miguel(1): Nope. Might want to try selecting a buddy > and right-click. > > Who is Miguel(1)? One client used an alternative scheme with Miguel_1, > Miguel_2 and Miguel_3. So in that chat client, there is no Miguel(1) > at all. > Aki, Obviously, a sanely implemented client would make sure that any local=20 conventions for dealing with duplicate nicknames are never sent across = the=20 wire. So in your example, what in your client gets displayed as "Aki ->=20 Miguel(1)" would appear e.g. as "Aki [reply] -> Nope..." at other=20 participants (depending on the conventions that their client = implementation=20 is using The scenario above could occur when clients would have the bad habit of=20 including local displaynames in messages they sent (I know some chat = clients=20 do this). For MSRP chat, the draft could state that they SHOULD NOT do = this. Regards, Jeroen=20 ------_=_NextPart_001_01C7E0E2.CCA1B90C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname = URI

Jeroen,

People write these messages, not computers. When I write "I agree = with miguel(1)" is your client going to pop up an error? Think = about it.

Cheers,
Aki

-----Alkuper=E4inen viesti-----
L=E4hett=E4j=E4: ext Jeroen van Bemmel
L=E4hetetty: 17.08.2007 18:09:33
Vastaanottaja: ext Jeroen van Bemmel;Niemi Aki = (Nokia-TP-MSW/Helsinki);ext Brian Rosen
Kopio: ext Paul Kyzivat;Garcia Miguel (NSN - FI/Espoo);SIMPLE mailing = list
Aihe: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI


> Let's simulate a running discussion:
>
> [17:35:05] Miguel(1)-> This chat thing is great. Anyone know how = to
> send
> a private message?
> [17:35:40] Miguel(2)-> Hi all!
> [17:36:01] Miguel(3)-> Ping...
>
> Now I decide to reply:
>
> [17:36:59] Aki-> Miguel(1): Nope. Might want to try selecting a = buddy
> and right-click.
>
> Who is Miguel(1)? One client used an alternative scheme with = Miguel_1,
> Miguel_2 and Miguel_3. So in that chat client, there is no = Miguel(1)
> at all.
>

Aki,

Obviously, a sanely implemented client would make sure that any = local
conventions for dealing with duplicate nicknames are never sent across = the
wire. So in your example, what in your client gets displayed as = "Aki ->
Miguel(1)" would appear e.g. as "Aki [reply] -> = Nope..." at other
participants (depending on the conventions that their client = implementation
is using

The scenario above could occur when clients would have the bad habit = of
including local displaynames in messages they sent (I know some chat = clients
do this). For MSRP chat, the draft could state that they SHOULD NOT do = this.

Regards,
Jeroen

------_=_NextPart_001_01C7E0E2.CCA1B90C-- --===============0364222440== 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 --===============0364222440==-- From simple-bounces@ietf.org Fri Aug 17 11:29:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3k4-0007T9-KD; Fri, 17 Aug 2007 11:28:04 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IM3k3-0007Sw-3t for simple-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 11:28:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3k2-0007Sn-On for simple@ietf.org; Fri, 17 Aug 2007 11:28:02 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM3k2-0003LV-2p for simple@ietf.org; Fri, 17 Aug 2007 11:28:02 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 17 Aug 2007 11:28:00 -0400 X-IronPort-AV: i="4.19,275,1183348800"; d="scan'208"; a="129150544:sNHT1201362010" 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 l7HFRxEm002804; Fri, 17 Aug 2007 11:27:59 -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 l7HFRxjI009613; Fri, 17 Aug 2007 15:27:59 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 11:27:57 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 11:27:57 -0400 Message-ID: <46C5BE7E.2030301@cisco.com> Date: Fri, 17 Aug 2007 11:27:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46B8BCD4.4030800@cisco.com><46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com><46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com><46BC0C2B.5080000@nokia.com> <033301c7db58$b01cc930$640fa8c0@cis.neustar.com> <46BC7AD4.2030809@nokia.com> <034101c7db61$55c2d110$640fa8c0@cis.neustar.c!om> <46C0019F.8080303@nokia.com> <46C06540.2020709@cis! co.com><46C2F343.5020300@nokia.com> <46C37F13.7090306@cisco.com> <46C415AD.7080608@nokia.com> <002e01c7e0d8$0f08a110$0700a8c0@cis.neustar.com> <46C5B77B.5090606@nokia.com> In-Reply-To: <46C5B77B.5090606@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2007 15:27:57.0199 (UTC) FILETIME=[301159F0:01C7E0E3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4129; t=1187364479; x=1188228479; 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]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20 |To:=20Aki=20Niemi=20; bh=mOjaEC66rDS3bluuX/axQAa6AT/gIJu+4JJniURRUuw=; b=p24upgXcGlsirGmGgmlxWkV/k+phqhMR8ny9bT7yZX+k9G439x9CIOQUK65c89tEv11T9DKY gDpBNl93Fkx5TKwY0+HUDx8tilsbHIQvjWd7Zw/FYNJTih1slyxEHuYK; 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: a8a20a483a84f747e56475e290ee868e 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 Sorry - I haven't been keeping up with comments (busy doing my day job). In the below, I do think this is an issue of UI design, and some may be better than others. This is a good example of why nicknames should be tied to domains, with only one valid per domain. Then at least one UI that can be comprehensible is that nicknames are displayed *with* the domain except for one default domain, where they can be suppressed. For instance the default domain could be the domain the user's own nickname is with, or it could be the default domain of the chat room. (The defaulting rule is itself part of the UI design.) So in this case perhaps ietf.org is a nickname domain, and aki@ietf.org, miguel@ietf.org, br@ietf.org and paulk@ietf.org are all owned by us. When participating in chat rooms related to ietf business (whether hosted by ietf, softarmor, columbia, or whatever) we might see these nicknames as just "aki", "miguel", "paulk" etc. If there was another participant with the nickname aki@aol.com then he would indeed be displayed as "aki@aol.com", so there would be no confusion. We shouldn't be specifying UI design here. But its useful to convince ourselves that reasonable UIs are feasible. So far I am convinced they are. Paul Aki Niemi wrote: > ext Brian Rosen wrote: >>> I'd be really curious to know how it is intended that UI to cope with >>> colliding nicknames like "Miguel", "Miguel ", and " Miguel", for which >>> the URIs are all GRUUs. What would the roster of this room look like? >> Something like >> >> ... >> Miguel >> >> >> ... >> Miguel >> >> >> ... >> Miguel >> >> >> Where the first two are "regular" users and the third is anonymous. >> >> The URIs can be used to address any messages. The nicknames can be used in >> the UI for display purposes, presumably with some differentiation viz. >> Miguel(1), Miguel(2),... > > I see. So your implementation decided that stripping whitespace was OK > to determine whether the nicknames were "equal". I see your UI also > decided on one possible scheme to tell them apart. > > Let's simulate a running discussion: > > [17:35:05] Miguel(1)-> This chat thing is great. Anyone know how to send > a private message? > [17:35:40] Miguel(2)-> Hi all! > [17:36:01] Miguel(3)-> Ping... > > Now I decide to reply: > > [17:36:59] Aki-> Miguel(1): Nope. Might want to try selecting a buddy > and right-click. > > Who is Miguel(1)? One client used an alternative scheme with Miguel_1, > Miguel_2 and Miguel_3. So in that chat client, there is no Miguel(1) at all. > > Of course, Miguel(1) has no idea what his nickname looks like in anyone > else's UI. In fact, even the same client implementation may show the > Miguels in different order, depending on when they joined. That means > that Miguel(1) is Miguel(2) in Brian(2)'s screen, but Miguel_2 in > Paul(3)'s screen, which Aki_1(1) thinks is just a little odd. > > BTW, Aki_1(1) used to be just Aki_1 (he picked that nickname since there > already was an Aki in the room), until someone else picked Aki_1 as > well, at which point he became Aki_1(1). Or something. > > Of course, a sane client would probably just drop the nickname (which at > this point is a useless piece of information) from the UI and use the > URI instead: > > [17:35:05] chat34@chats.example.com;gr="fe433e334a"-> Hi all! > [17:35:10] chat34@chats.example.com;gr="66d7e67ac7"-> Howdy! > > And so on. I guess I will then reply with: > > [17:36:50] chat34@chats.example.com;gr="76276dc78a"-> 66d7e67ac7: let's > get out of here. I created an IRC channel for us. > > This is how things break. This is all pretty obvious if you've used IRC. > > Cheers, > Aki > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 17 11:30: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 1IM3kh-0007om-FQ; Fri, 17 Aug 2007 11:28:43 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IM3kg-0007ma-31 for simple-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 11:28:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3kf-0007mS-PP for simple@ietf.org; Fri, 17 Aug 2007 11:28:41 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM3kd-00084y-Pn for simple@ietf.org; Fri, 17 Aug 2007 11:28:41 -0400 Received: from [68.114.74.220] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IM3kP-0004FZ-K7; Fri, 17 Aug 2007 10:28:26 -0500 From: "Brian Rosen" To: "'Aki Niemi'" References: <46ADDC1E.10301@nsn.com> <082b01c7d90a$31041540$640fa8c0@cis.neustar.com> <46B8BCD4.4030800@cisco.com><46B8BDB4.8080602@nsn.com> <087901c7d931$917494f0$640fa8c0@cis.neustar.com> <46B8E20F.60804@cisco.com> <089e01c7d93f$ec515a30$640fa8c0@cis.neustar.com> <46B907DB.8080301@cisco.com> <08c901c7d953$0880f310$640fa8c0@cis.neustar.com> <46B95BFF.8090304@nsn.com> <094501c7d9bf$dac457b0$640fa8c0@cis.neustar.com> <46BB068B.9080604@nsn.com><46BB1ECB.7010001@cisco.com> <021601c7dac9$707165f0$640fa8c0@cis.neustar.com> <46BB8C63.1050100@cisco.com> <023f01c7dae7$ea328b30$640fa8c0@cis.neustar.com> <46BC0482.6080401@nsn.com><46BC0C2B.5080000@nokia.com> <033301c7db58$b01cc930$640fa8c0@cis.neustar.com> <46BC7AD4.2030809@nokia.com> <034101c7db61$55c2d110$640fa8c0@cis.neustar.c!om> <46C0019F.8080303@nokia.com> <46C06540.2020709@cis! co.com><46C2F343.5020300@nokia.com> <46C37F13.7090306@cisco.com> <46C415AD.7080608@nokia.com> <002e01c7e0d8$0f08a110$0700a8c0@cis.neustar.com> <46C5B77B.5090606@nokia.com> Subject: RE: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Fri, 17 Aug 2007 11:28:29 -0400 Message-ID: <00a101c7e0e3$45e063c0$0700a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46C5B77B.5090606@nokia.com> Thread-Index: Acfg3w6QPOjztnb1RP+ewTp5cquYCwAAXa1w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 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: 'ext Paul Kyzivat' , '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 > > The URIs can be used to address any messages. The nicknames can be used > in > > the UI for display purposes, presumably with some differentiation viz. > > Miguel(1), Miguel(2),... > > I see. So your implementation decided that stripping whitespace was OK > to determine whether the nicknames were "equal". I see your UI also > decided on one possible scheme to tell them apart. Yes. I think trying to display spaces as differentiation leads to confusion, but your client could do anything it wanted to. > > Let's simulate a running discussion: > > [17:35:05] Miguel(1)-> This chat thing is great. Anyone know how to send > a private message? > [17:35:40] Miguel(2)-> Hi all! > [17:36:01] Miguel(3)-> Ping... > > Now I decide to reply: > > [17:36:59] Aki-> Miguel(1): Nope. Might want to try selecting a buddy > and right-click. > > Who is Miguel(1)? One client used an alternative scheme with Miguel_1, > Miguel_2 and Miguel_3. So in that chat client, there is no Miguel(1) at > all. In my example, I used two "regular" URIs and one anonymous one. You happened to choose one for which we could show you a URI if we wanted to. In general, since this chat allows nickname collisions, what you know as Miguel(1), someone else might know as Miguel_1, or Miguel with a red background. So what? Your example works. You can send a message to the Miguel who asked the question. In particular you have zero extra information if the chat server enforced a no conflicts rule, and assigned unique nicks. > > Of course, Miguel(1) has no idea what his nickname looks like in anyone > else's UI. In fact, even the same client implementation may show the > Miguels in different order, depending on when they joined. That means > that Miguel(1) is Miguel(2) in Brian(2)'s screen, but Miguel_2 in > Paul(3)'s screen, which Aki_1(1) thinks is just a little odd. Why? There are more than one Miguels. You have a way to keep them straight. If you say "Miguel", you don't know which one. You can send a message to any of them, unambiguously. To get in trouble, you need to have an exchange where you are type what you see Aki(1): No, I meant to say Miguel(2) is wrong. Then you might have a problem. I don't see that as really difficult. If you get too confused, ask the Miguels to choose different nicknames. > > BTW, Aki_1(1) used to be just Aki_1 (he picked that nickname since there > already was an Aki in the room), until someone else picked Aki_1 as > well, at which point he became Aki_1(1). Or something. Yeah, so? There is no more (or less) confusion, and you can address messages to the right one. > > Of course, a sane client would probably just drop the nickname (which at > this point is a useless piece of information) from the UI and use the > URI instead: > > [17:35:05] chat34@chats.example.com;gr="fe433e334a"-> Hi all! > [17:35:10] chat34@chats.example.com;gr="66d7e67ac7"-> Howdy! Well, you can write a client that did that. I wouldn't. > > And so on. I guess I will then reply with: > > [17:36:50] chat34@chats.example.com;gr="76276dc78a"-> 66d7e67ac7: let's > get out of here. I created an IRC channel for us. > > This is how things break. This is all pretty obvious if you've used IRC. I've used IRC a lot. I find it really confusing. I like AOL and other systems where my nickname sticks and when you see br65535, you ALWAYS know it's me. My client may even use br65535(aol) and br65535(gmail) in the obvious circumstance. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 17 11:40: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 1IM3uG-0004Uf-R6; Fri, 17 Aug 2007 11:38:36 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IM3uF-0004Ua-P4 for simple-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 11:38:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3uF-0004US-FZ for simple@ietf.org; Fri, 17 Aug 2007 11:38:35 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM3uD-0008K2-8Z for simple@ietf.org; Fri, 17 Aug 2007 11:38:35 -0400 Received: (qmail 25587 invoked by uid 0); 17 Aug 2007 15:39:44 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 17 Aug 2007 15:39:44 -0000 Message-ID: <00f001c7e0e4$a6015920$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: Subject: Re: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Fri, 17 Aug 2007 17:38:24 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: pkyzivat@cisco.com, miguel.garcia@nsn.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2134085051==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============2134085051== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EC_01C7E0F5.694298D0" This is a multi-part message in MIME format. ------=_NextPart_000_00EC_01C7E0F5.694298D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URIAki, You did not specify which text was human generated versus computer generated, so I made an assumption. Obviously we can't build a system that stops people from sending messages that others may misinterpret. We could write guidelines such as - clients SHOULD show displaynames as received from the conference server, and not try to decorate them - to disambiguate duplicate nicknames, clients SHOULD use a scheme where they add "(n)" to the displayname, where 'n' starts at 1 and is increased for each duplicate nickname using XML document order - servers SHOULD implement a mechanism to ensure unique displaynames but to be honest, I don't think there is much of a problem: humans tend to have their own disambiguation mechanisms built-in Regards, Jeroen ----- Original Message ----- From: aki.niemi@nokia.com To: jbemmel@zonnet.nl ; aki.niemi@nokia.com ; br@brianrosen.net Cc: pkyzivat@cisco.com ; miguel.garcia@nsn.com ; simple@ietf.org Sent: Friday, August 17, 2007 5:25 PM Subject: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Jeroen, People write these messages, not computers. When I write "I agree with miguel(1)" is your client going to pop up an error? Think about it. Cheers, Aki -----Alkuperäinen viesti----- Lähettäjä: ext Jeroen van Bemmel Lähetetty: 17.08.2007 18:09:33 Vastaanottaja: ext Jeroen van Bemmel;Niemi Aki (Nokia-TP-MSW/Helsinki);ext Brian Rosen Kopio: ext Paul Kyzivat;Garcia Miguel (NSN - FI/Espoo);SIMPLE mailing list Aihe: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > Let's simulate a running discussion: > > [17:35:05] Miguel(1)-> This chat thing is great. Anyone know how to > send > a private message? > [17:35:40] Miguel(2)-> Hi all! > [17:36:01] Miguel(3)-> Ping... > > Now I decide to reply: > > [17:36:59] Aki-> Miguel(1): Nope. Might want to try selecting a buddy > and right-click. > > Who is Miguel(1)? One client used an alternative scheme with Miguel_1, > Miguel_2 and Miguel_3. So in that chat client, there is no Miguel(1) > at all. > Aki, Obviously, a sanely implemented client would make sure that any local conventions for dealing with duplicate nicknames are never sent across the wire. So in your example, what in your client gets displayed as "Aki -> Miguel(1)" would appear e.g. as "Aki [reply] -> Nope..." at other participants (depending on the conventions that their client implementation is using The scenario above could occur when clients would have the bad habit of including local displaynames in messages they sent (I know some chat clients do this). For MSRP chat, the draft could state that they SHOULD NOT do this. Regards, Jeroen ------=_NextPart_000_00EC_01C7E0F5.694298D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of = Nickname URI
Aki,
 
You did not specify which text was = human generated=20 versus computer generated, so I made an assumption.
Obviously we can't build a system that = stops people=20 from sending messages that others may misinterpret.
 
We could write guidelines such = as
- clients SHOULD show displaynames as = received from=20 the conference server, and not try to decorate them
- to disambiguate duplicate nicknames, = clients=20 SHOULD use a scheme where they add "(n)" to the displayname, where 'n' = starts at=20 1 and is increased for each duplicate nickname using XML document=20 order
- servers SHOULD implement a mechanism = to ensure=20 unique displaynames
 
but to be honest, I don't think there = is much of=20 a problem: humans tend to have their own disambiguation mechanisms=20 built-in
 
Regards,
Jeroen
 
----- Original Message -----
From:=20 aki.niemi@nokia.com
To: jbemmel@zonnet.nl ; aki.niemi@nokia.com ; br@brianrosen.net=20
Cc: pkyzivat@cisco.com ; miguel.garcia@nsn.com ; simple@ietf.org
Sent: Friday, August 17, 2007 = 5:25=20 PM
Subject: VS: Re: [Simple] [MSRP = chat]=20 Issue 7: Syntax of Nickname URI

Jeroen,

People write these messages, not = computers.=20 When I write "I agree with miguel(1)" is your client going to pop up = an error?=20 Think about it.

Cheers,
Aki

-----Alkuper=E4inen=20 viesti-----
L=E4hett=E4j=E4: ext Jeroen van Bemmel
L=E4hetetty: = 17.08.2007=20 18:09:33
Vastaanottaja: ext Jeroen van Bemmel;Niemi Aki=20 (Nokia-TP-MSW/Helsinki);ext Brian Rosen
Kopio: ext Paul = Kyzivat;Garcia=20 Miguel (NSN - FI/Espoo);SIMPLE mailing list
Aihe: Re: [Simple] = [MSRP chat]=20 Issue 7: Syntax of Nickname URI


> Let's simulate a = running=20 discussion:
>
> [17:35:05] Miguel(1)-> This chat thing = is=20 great. Anyone know how to
> send
> a private = message?
>=20 [17:35:40] Miguel(2)-> Hi all!
> [17:36:01] Miguel(3)->=20 Ping...
>
> Now I decide to reply:
>
> = [17:36:59]=20 Aki-> Miguel(1): Nope. Might want to try selecting a buddy
> = and=20 right-click.
>
> Who is Miguel(1)? One client used an = alternative=20 scheme with Miguel_1,
> Miguel_2 and Miguel_3. So in that chat = client,=20 there is no Miguel(1)
> at = all.
>

Aki,

Obviously, a=20 sanely implemented client would make sure that any = local
conventions for=20 dealing with duplicate nicknames are never sent across the
wire. So = in your=20 example, what in your client gets displayed as "Aki = ->
Miguel(1)" would=20 appear e.g. as "Aki [reply] -> Nope..." at other
participants = (depending=20 on the conventions that their client implementation
is = using

The=20 scenario above could occur when clients would have the bad habit=20 of
including local displaynames in messages they sent (I know some = chat=20 clients
do this). For MSRP chat, the draft could state that they = SHOULD NOT=20 do = this.

Regards,
Jeroen

------=_NextPart_000_00EC_01C7E0F5.694298D0-- --===============2134085051== 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 --===============2134085051==-- From simple-bounces@ietf.org Fri Aug 17 11:56:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM4A6-00046L-JU; Fri, 17 Aug 2007 11:54:58 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IM4A6-00045o-3V for simple-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 11:54:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM4A5-00043f-PH for simple@ietf.org; Fri, 17 Aug 2007 11:54:57 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM4A4-0000KS-J1 for simple@ietf.org; Fri, 17 Aug 2007 11:54:57 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Aug 2007 11:54:56 -0400 X-IronPort-AV: i="4.19,276,1183348800"; d="scan'208"; a="68277891:sNHT60675470" 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 l7HFslKi017452; Fri, 17 Aug 2007 11:54:47 -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 l7HFslmd023953; Fri, 17 Aug 2007 15:54:47 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); Fri, 17 Aug 2007 11:53:55 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 11:53:55 -0400 Message-ID: <46C5C495.8030601@cisco.com> Date: Fri, 17 Aug 2007 11:53:57 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: aki.niemi@nokia.com Subject: Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 17 Aug 2007 15:53:55.0176 (UTC) FILETIME=[D0B1C680:01C7E0E6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2795; t=1187366096; x=1188230096; 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=20VS=3A=20=20Re=3A=20[Simple]=20[MSRP=20chat]=20Issue=2 07=3A=20Syntax=20of=20Nickname=20URI |Sender:=20 |To:=20aki.niemi@nokia.com; bh=4+jdkSG1zZqJSQu2psBmzfHGgVP4P7VRcarlOzfPcN0=; b=WNsCFNiNc2cGErLltGIV2Ge+XI3ch6dkGoEohNYtzefPaf3sE9qSgzksFa05nKfgzhE4CLdj 3BhKCM7saRwteUt9PU3vVCbPhUvESVFb05dcvCUUFtxKNwMLXcY/wkbh; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: simple@ietf.org, miguel.garcia@nsn.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org aki.niemi@nokia.com wrote: > Jeroen, > > People write these messages, not computers. When I write "I agree with > miguel(1)" is your client going to pop up an error? Think about it. People are also likely to write: "I think miguel has gone insane. Last week he said X, and now he says Y" when it turns out that the miguel of last week was different from the miguel of this week. What you want can be achieved by a policy that restricts nicknames to those in a domain chosen by the conference, having relatively long term assignments of nicknames in that domain, and not allowing duplicates within that domain. Almost as good, and more flexible, is the above plus allow nicknames from other domains, with the UIs always displaying the domain with nicknames that are not within the preferred domain of the conference. This means that if for some reason I want to use the nickname "aki", but it is already taken in the ietf.org domain that is default for the conference, I can perhaps sign up for "aki@nick.name". Its not so different from my registering for "aki_2@ietf.org". But its a more stable identifier that I can perhaps use more widely. Paul > Cheers, > Aki > > -----Alkuperäinen viesti----- > Lähettäjä: ext Jeroen van Bemmel > Lähetetty: 17.08.2007 18:09:33 > Vastaanottaja: ext Jeroen van Bemmel;Niemi Aki > (Nokia-TP-MSW/Helsinki);ext Brian Rosen > Kopio: ext Paul Kyzivat;Garcia Miguel (NSN - FI/Espoo);SIMPLE mailing list > Aihe: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > > > Let's simulate a running discussion: > > > > [17:35:05] Miguel(1)-> This chat thing is great. Anyone know how to > > send > > a private message? > > [17:35:40] Miguel(2)-> Hi all! > > [17:36:01] Miguel(3)-> Ping... > > > > Now I decide to reply: > > > > [17:36:59] Aki-> Miguel(1): Nope. Might want to try selecting a buddy > > and right-click. > > > > Who is Miguel(1)? One client used an alternative scheme with Miguel_1, > > Miguel_2 and Miguel_3. So in that chat client, there is no Miguel(1) > > at all. > > > > Aki, > > Obviously, a sanely implemented client would make sure that any local > conventions for dealing with duplicate nicknames are never sent across the > wire. So in your example, what in your client gets displayed as "Aki -> > Miguel(1)" would appear e.g. as "Aki [reply] -> Nope..." at other > participants (depending on the conventions that their client implementation > is using > > The scenario above could occur when clients would have the bad habit of > including local displaynames in messages they sent (I know some chat clients > do this). For MSRP chat, the draft could state that they SHOULD NOT do this. > > Regards, > Jeroen > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 17 12:13: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 1IM4QM-0002eo-Fv; Fri, 17 Aug 2007 12:11:46 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IM4QK-0002UR-JI for simple-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 12:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM4QK-0002Sx-0x for simple@ietf.org; Fri, 17 Aug 2007 12:11:44 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM4QI-0000oM-G3 for simple@ietf.org; Fri, 17 Aug 2007 12:11:44 -0400 Received: (qmail 5420 invoked by uid 0); 17 Aug 2007 16:11:39 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 17 Aug 2007 16:11:39 -0000 Message-ID: <000601c7e0e9$47648400$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Paul Kyzivat" , References: <46C5C495.8030601@cisco.com> Subject: Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Fri, 17 Aug 2007 18:11:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: miguel.garcia@nsn.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org > What you want can be achieved by a policy that restricts nicknames to > those in a domain chosen by the conference, having relatively long > term assignments of nicknames in that domain, and not allowing > duplicates within that domain. This would also require authentication of users against that domain Is this needed in the conference data model? Could it work without being standardized? Regards, Jeroen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 17 12:17: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 1IM4U6-00066i-R4; Fri, 17 Aug 2007 12:15:38 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IM4U1-00063A-Nx for simple-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 12:15:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM4U1-00062y-EE; Fri, 17 Aug 2007 12:15:33 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM4U0-0000uP-7Y; Fri, 17 Aug 2007 12:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 3441A32894; Fri, 17 Aug 2007 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IM4TW-00005P-3p; Fri, 17 Aug 2007 12:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 17 Aug 2007 12:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-diff-06.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources Author(s) : J. Urpalainen, J. Rosenberg Filename : draft-ietf-simple-xcap-diff-06.txt Pages : 16 Date : 2007-8-17 This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). This format indicates the document that has changed and its former and new entity tags. It also can indicate the specific change that was made in the document, using an XML patch format. This format allows also indications of element and attribute content of an XML document. XCAP diff documents can be delivered to clients using a number of means, including a Session Initiation Protocol (SIP) event package. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-xcap-diff-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xcap-diff-06.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-8-17112355.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-diff-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-diff-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-17112355.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Fri Aug 17 12:21: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 1IM4Y2-00058J-08; Fri, 17 Aug 2007 12:19:42 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IM4Y1-000588-6Q for simple-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 12:19:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM4Xz-000574-3g for simple@ietf.org; Fri, 17 Aug 2007 12:19:40 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM4Xy-0005CT-O8 for simple@ietf.org; Fri, 17 Aug 2007 12:19:38 -0400 Received: from [68.114.74.220] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IM4Xi-00066U-81; Fri, 17 Aug 2007 11:19:22 -0500 From: "Brian Rosen" To: "'Jeroen van Bemmel'" , "'Paul Kyzivat'" , References: <46C5C495.8030601@cisco.com> <000601c7e0e9$47648400$0601a8c0@BEMBUSTER> Subject: RE: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI Date: Fri, 17 Aug 2007 12:19:30 -0400 Message-ID: <00be01c7e0ea$65d53870$0700a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000601c7e0e9$47648400$0601a8c0@BEMBUSTER> Thread-Index: Acfg6UhmG8MVn7GhRd6ltpVkq7Jq7QAAJWhQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: miguel.garcia@nsn.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The "generalized" mechanism will (eventually) have a way to authenticate a nickname at a domain against an AoR. Brian > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Friday, August 17, 2007 12:12 PM > To: Paul Kyzivat; aki.niemi@nokia.com > Cc: br@brianrosen.net; miguel.garcia@nsn.com; simple@ietf.org > Subject: Re: VS: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI > > > What you want can be achieved by a policy that restricts nicknames to > > those in a domain chosen by the conference, having relatively long > > term assignments of nicknames in that domain, and not allowing > > duplicates within that domain. > > This would also require authentication of users against that domain > > Is this needed in the conference data model? Could it work without being > standardized? > > Regards, > Jeroen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 17 19:48:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMBWF-0001NI-Ow; Fri, 17 Aug 2007 19:46:19 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IMBWC-0001Kf-HQ for simple-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 19:46:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMBWC-0001KO-6C; Fri, 17 Aug 2007 19:46:16 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMBW5-0003jg-PK; Fri, 17 Aug 2007 19:46:16 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l7HNk8n7039168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 18:46:09 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46C6334B.2030806@nostrum.com> Date: Fri, 17 Aug 2007 18:46:19 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: XCON-IETF , "'simple@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.1/3976/Fri Aug 17 18:21:11 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Simple] Chatroom Gap Analysis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org As we discussed in Chicago, I have produced a gap analysis document that discusses the features available in currently deployed chatroom systems and which of these can be achieved using protocols defined by or currently under definition within the IETF. Until it appears in the archives, you can grab a copy from: http://www.nostrum.com/~adam/ids/draft-roach-xcon-chatroom-analysis-00.txt or http://www.nostrum.com/~adam/ids/draft-roach-xcon-chatroom-analysis-00.html (The document isn't as polished as I'd like, but I think it gets all the important information across). /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 17 23:38:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMF7e-0007yh-4v; Fri, 17 Aug 2007 23:37:10 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IMF7c-0007yY-GD for simple-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 23:37:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMF7c-0007yP-5b; Fri, 17 Aug 2007 23:37:08 -0400 Received: from pne-smtpout1-sn2.hy.skanova.net ([81.228.8.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMF7b-0001CV-FN; Fri, 17 Aug 2007 23:37:07 -0400 Received: from GunnarH (213.64.232.214) by pne-smtpout1-sn2.hy.skanova.net (7.2.075) id 46BFEA480017EF5C; Sat, 18 Aug 2007 05:36:59 +0200 Message-ID: <46BFEA480017EF5C@pne-smtpout1-sn2.hy.skanova.net> (added by postmaster@pne.skanova.net) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Adam Roach'" , "'XCON-IETF'" , Subject: RE: [Simple] Chatroom Gap Analysis - Media and mode aspects Date: Sat, 18 Aug 2007 05:37:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <46C6334B.2030806@nostrum.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 thread-index: AcfhKPZEqX3D1fIqQbiooRh724SFhQAHIs/Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Adam, The draft gives a good overview over many chatroom features. However, I would like to see more on media and mode aspects. Now, the only place I found saying anything about contents is=20 "2.1.9. Sending Files and Images to a Chatroom." saying that you can = send anything to a chatroom. Questions: 1. In your analysis of existing chat-room applications, have you found = more orderly support for audio, video and images in addition to the default support for text? 2. Have you found planned support for text messages in other writing = systems than left-to right? 3. Have you found support for the media to be transmitted and displayed = in real-time as they are created? 4. Have you found support for ordered transition between message mode = and real time mode? I think it would be valuable to cover such aspects as well.=20 Gunnar Hellstr=F6m ------------------------------------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se Tel: +46708204288 www.omnitor.se -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Saturday, August 18, 2007 1:46 AM To: XCON-IETF; 'simple@ietf.org' Subject: [Simple] Chatroom Gap Analysis As we discussed in Chicago, I have produced a gap analysis document that discusses the features available in currently deployed chatroom systems = and which of these can be achieved using protocols defined by or currently = under definition within the IETF. Until it appears in the archives, you can grab a copy from: http://www.nostrum.com/~adam/ids/draft-roach-xcon-chatroom-analysis-00.tx= t or http://www.nostrum.com/~adam/ids/draft-roach-xcon-chatroom-analysis-00.ht= ml (The document isn't as polished as I'd like, but I think it gets all the important information across). /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple __________ NOD32 2468 (20070817) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 20 01:56: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 1IN0DR-0004we-PA; Mon, 20 Aug 2007 01:54:17 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IN0DR-0004wW-3s for simple-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 01:54:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN0DQ-0004wO-PG for simple@ietf.org; Mon, 20 Aug 2007 01:54:16 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN0DQ-0004u1-63 for simple@ietf.org; Mon, 20 Aug 2007 01:54:16 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7K5rvmJ002724 for ; Mon, 20 Aug 2007 08:54:13 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 08:53:51 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 08:53:51 +0300 Received: from [172.21.41.217] ([172.21.41.217]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 08:53:51 +0300 Message-ID: <46C92C6F.4040207@nokia.com> Date: Mon, 20 Aug 2007 08:53:51 +0300 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: simple@ietf.org Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-xcap-diff-06.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Aug 2007 05:53:51.0454 (UTC) FILETIME=[7C0B07E0:01C7E2EE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org ext simple-bounces@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. > > Title : An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources > Author(s) : J. Urpalainen, J. Rosenberg > Filename : draft-ietf-simple-xcap-diff-06.txt > Pages : 16 > Date : 2007-8-17 > > This specification defines a document format that can be used to > indicate that a change has occurred in a document managed by the > Extensible Markup Language (XML) Configuration Access Protocol > (XCAP). This format indicates the document that has changed and its > former and new entity tags. It also can indicate the specific change > that was made in the document, using an XML patch format. This > format allows also indications of element and attribute content of an > XML document. XCAP diff documents can be delivered to clients using > a number of means, including a Session Initiation Protocol (SIP) > event package. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-06.txt > > Changes since 05: -moved element & attribute subscriptions from to this format i-d -removed optional hash as per Jeroen's proposal - element has an additional table describing resource changes/parameter usage -schema changes: - & elements in addition to within , all share a similar "sel" attribute -, and can contain additional attribute content (Anders) -example updated -added Acknowledgements section Comments ? br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 20 11:34: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 1IN9FS-0002ut-Vj; Mon, 20 Aug 2007 11:32:58 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IN9FR-0002uo-Tc for simple-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 11:32:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN9FR-0002ug-I8 for simple@ietf.org; Mon, 20 Aug 2007 11:32:57 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN9FR-0002bw-12 for simple@ietf.org; Mon, 20 Aug 2007 11:32:57 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l7KFWu6w020112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 20 Aug 2007 10:32:56 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) To: SIMPLE mailing list Message-Id: References: <46C948F1.7000503@nokia.com> From: Robert Sparks Date: Mon, 20 Aug 2007 11:32:55 -0400 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.1/4011/Mon Aug 20 07:21:32 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [Simple] Fwd: [Sip] draft-urpalainen-sip-xcap-diff-event-02 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1911051722==" Errors-To: simple-bounces@ietf.org --===============1911051722== Content-Type: multipart/alternative; boundary=Apple-Mail-4-1010861480 --Apple-Mail-4-1010861480 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed In case anyone here is not also watching the SIP list closely... Begin forwarded message: > From: Jari Urpalainen > Date: August 20, 2007 3:55:29 AM EDT (CA) > To: sip@ietf.org > Subject: [Sip] draft-urpalainen-sip-xcap-diff-event-02 > > Hi all! > > I've updated sip-xcap-diff-event-02.txt>. Element & attribute subscriptions were > moved to i-d: simple-xcap-diff-06.txt>. Resource selections are done by a flat > URI list with the XCAP resource list format instead of the "path" > header parameter, and some text nits have been done. The somewhat > controversial initial sync problem still exists when patches are > aggregated. It is however, proposed that we live with that now as > it is a corner case which still can be handled with the proposed > approach, > any comments ? > br, Jari > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --Apple-Mail-4-1010861480 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 In case anyone here is not also = watching the SIP list closely...

Begin forwarded = message:

From: Jari Urpalainen <jari.urpalainen@nokia.com>= ;
Date: August 20, 2007 3:55:29 AM EDT = (CA)
Subject: = [Sip] = draft-urpalainen-sip-xcap-diff-event-02

Hi = all!

I've updated <http://www.ietf.org/internet-drafts/draft-urpalainen-sip-xc= ap-diff-event-02.txt>. Element & attribute subscriptions were = moved to i-d: <http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-06.t= xt>. Resource selections are done by a flat URI list with the = XCAP resource list format instead of the "path" header parameter, and = some text nits have been done. The somewhat controversial initial sync = problem still exists when patches are aggregated. It is however, = proposed that we live with that now as it is a corner case which still = can be handled with the proposed approach,
any = comments ?
br, Jari


This list is = for NEW development of the core SIP Protocol
Use sip-implementors@cs.colum= bia.edu for questions on current sip
Use sipping@ietf.org for new = developments on the application of sip
=

= --Apple-Mail-4-1010861480-- --===============1911051722== 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 --===============1911051722==-- From simple-bounces@ietf.org Mon Aug 20 11:40:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN9LN-0004Y2-Cv; Mon, 20 Aug 2007 11:39:05 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IN9LM-0004Xa-5J for simple-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 11:39:04 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IN9LL-0004Wy-Rz for simple@ietf.org; Mon, 20 Aug 2007 11:39:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN9HR-0003QK-52 for simple@ietf.org; Mon, 20 Aug 2007 11:35:01 -0400 Received: from perseverance-96.encs.concordia.ca ([132.205.96.94] helo=perseverance.services.encs.concordia.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN9HQ-0002f5-Nz for simple@ietf.org; Mon, 20 Aug 2007 11:35:01 -0400 Received: from localhost (nul-web@tact-96.encs.concordia.ca [132.205.96.48]) by perseverance.services.encs.concordia.ca (envelope-from a_vali@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id l7KFYxxk012576 for ; Mon, 20 Aug 2007 11:35:00 -0400 X-Received-HTTP: from lmcpra.ericsson.ca (lmcpra.ericsson.ca [192.75.88.231]) by mail.encs.concordia.ca (Horde MIME library) with HTTP; Mon, 20 Aug 2007 11:34:59 -0400 Message-ID: <20070820113459.eeun1jcy49c84csw@mail.encs.concordia.ca> Date: Mon, 20 Aug 2007 11:34:59 -0400 From: a_vali@encs.concordia.ca To: simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) X-Scanned-By: MIMEDefang 2.58 on perseverance.encs.concordia.ca at 2007/08/20 11:35:00 EDT X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-TMDA-Confirmed: Mon, 20 Aug 2007 11:39:03 -0400 Subject: [Simple] Presence SIP URI X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Dear Staff, I am a Masters Student of Concordia University, Montreal Canada. I =20 have been working on SIP and SIMPLE Presence Model, I have question =20 regarding the Presence entity (e.g. User) in Presence Model which has =20 a public SIP URI to publish his presence information to Presence =20 Service(PS) but I am confuse on the issue of : What if the Presence entity is an Object(any Physical entity except =20 User) so can we assign or that object have its on public SIP URI to =20 public his Presence Information to Presence Service ? Is Presence Model or SIP currently support SIP URI to non-User =20 entities(let say Real world Objects) ? If the answer of one of the above question is yes then: How we can anticipate its(Object's) presence information publishable =20 to Presence Service or available to other users(Subscribers/Watcher) ? The term Object's Presence Information means its location in any =20 instant of time thats what I want to report it to Watcher Application. I hope you understand my point of view and queries, If something is =20 not understandable to you in these queries i glad to explain you =20 further. As my Masters Degree Project I am working on 3GPP(IMS) =20 Presence Architecture[3GPP TS 23.141 R7] in which I am gathering =20 Presence Information from external network(let say Wireless Sensor =20 Network) and make them available to 3GPP(IMS domain). I would appreciate your detail reply soon. Arif Research Assistant ECE Department, Concordia University Montreal, Canada a_vali@encs.concordia.ca _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From ErnestintelligentSimmons@arabnews.com Mon Aug 20 12:53:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INAUy-0004ro-Q5 for simple-archive@lists.ietf.org; Mon, 20 Aug 2007 12:53:04 -0400 Received: from cpe-071-075-254-038.carolina.res.rr.com ([71.75.254.38] helo=dfl2rs71.carolina.rr.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1INAUx-0005Ov-RG for simple-archive@lists.ietf.org; Mon, 20 Aug 2007 12:53:04 -0400 Message-ID: <8e2f01c7e34a$f0d9f750$26fe4b47@DFL2RS71> From: "Bobby Gonzales" To: Subject: Fw: Thanks, we are accepting your loan request Date: Mon, 20 Aug 2007 12:53:37 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_8E2B_01C7E34A.F0D9F750" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 2.0 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is a multi-part message in MIME format. ------=_NextPart_000_8E2B_01C7E34A.F0D9F750 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit score doesn't matter to us! If your family OWN real estate and want IMMEDIATE cash to spend ANY way = you like, or simply wish to LOWER your payments by a third or more, here = is best deal we can offer you TONIGHT (hurry, this offer will expire = THIS EVENING): $480,000+ debt AND EVEN MORE: After further review, our lenders have established the = lowest current payments! Hurry, when our deal is gone, it is gone. Simply finish this = user-friendly form... Do not worry about approval, your your credit report will not disqualify = you! http://sheisnoying.com/ ------=_NextPart_000_8E2B_01C7E34A.F0D9F750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your credit score doesn't matter = to=20 us!
=20
 
If your family OWN real estate and = want IMMEDIATE=20 cash to spend ANY way you like, or simply wish to LOWER your payments by = a=20 third or more, here is best deal we can offer you TONIGHT (hurry, this = offer=20 will expire THIS EVENING):
=20
 
$480,000+ debt
 
AND EVEN MORE: After further review, = our lenders=20 have established the lowest current payments!
=20
 
Hurry, when our deal is gone, it is = gone.=20 Simply finish this user-friendly form...
=20
 
Do not worry about approval, your your = credit=20 report will not disqualify you!
=20
 
http://sheisnoying.com/
------=_NextPart_000_8E2B_01C7E34A.F0D9F750-- From simple-bounces@ietf.org Mon Aug 20 13:20: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 1INAtK-0006CR-9i; Mon, 20 Aug 2007 13:18:14 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1INAtJ-0006CJ-FE for simple-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 13:18:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INAtJ-0006CA-5Y; Mon, 20 Aug 2007 13:18:13 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INAtI-0003Kb-IZ; Mon, 20 Aug 2007 13:18:13 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l7KHI8Po025953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2007 12:18:09 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46C9CCD9.7080002@nostrum.com> Date: Mon, 20 Aug 2007 12:18:17 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= Subject: Re: [Simple] Chatroom Gap Analysis - Media and mode aspects References: <46BFEA480017EF5C@pne-smtpout1-sn2.hy.skanova.net> (added by postmaster@pne.skanova.net) In-Reply-To: <46BFEA480017EF5C@pne-smtpout1-sn2.hy.skanova.net> (added by postmaster@pne.skanova.net) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.1/4011/Mon Aug 20 07:21:32 2007 on shaman.nostrum.com X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nostrum.com id l7KHI8Po025953 X-Spam-Score: -1.4 (-) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: 'XCON-IETF' , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On 8/17/07 10:37 PM, Gunnar Hellstr=F6m wrote: > Questions: > > 1. In your analysis of existing chat-room applications, have you found = more > orderly support for audio, video and images in addition to the default > support for text? > =20 Not so much -- pretty much anything that isn't text tends to result in=20 some variation on a dialog box popping up asking where you want to save=20 the content. MSRP actually does a bit better (in theory, at least),=20 since you can specify an "inline" disposition for (e.g.) images, which=20 *should* cause clients to render the image in the chat window instead of=20 saving it to disk. Exactly how this ends up being implemented is yet to be seen. > 2. Have you found planned support for text messages in other writing sy= stems > than left-to right? > =20 To the same degree as we have support in XMPP/SIMPLE -- the use of=20 UTF-8, in theory, provides all the support necessary for RTL text. In=20 practice, what different clients do when they see an RTL mark varies=20 widely and is often inexplicable. That is: the protocol gets this right, but implementors do random things. > 3. Have you found support for the media to be transmitted and displayed= in > real-time as they are created? > =20 Not in chatroom scenarios, no -- at least, not since ytalk. Do you know=20 of a modern chatroom system that supports this? That said, there's nothing stopping clients from setting up RFC 4103=20 streams towards a mixer -- the tricky part is rendering such mixed=20 streams in a coherent fashion. > 4. Have you found support for ordered transition between message mode a= nd > real time mode? > =20 Not in existing systems, no. All four items you mention above appear to be supported by IETF=20 protocols, although it may not be immediately clear to implementors how=20 a user interface might present them -- perhaps there's room for a=20 document that address, in particular, the interaction of real-time text=20 with multi-user conferences. A "best current practice" of sorts. Is that=20 something you might be interested in tackling? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 20 18: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 1INFm1-000748-2L; Mon, 20 Aug 2007 18:31:01 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1INFlz-00073y-W1 for simple-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 18:30:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INFlz-00073q-Ls for simple@ietf.org; Mon, 20 Aug 2007 18:30:59 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INFlz-00074d-Cb for simple@ietf.org; Mon, 20 Aug 2007 18:30:59 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l7KMUtVr041916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 20 Aug 2007 17:30:59 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <496AAFAF-7A58-4C53-926E-EF48A6775E2B@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIMPLE mailing list From: Robert Sparks Date: Mon, 20 Aug 2007 17:30:58 -0500 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.1/4014/Mon Aug 20 14:33:05 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Simple] SIPit 21 registration is open. 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 SIPit 21 will take place November 5 through 9, 2007 in Beijing, China. The event will be hosted by the BII Group and the Beijing University of Posts and Telecommunications. Registration will be $575 US Dollars per participant. See http://www.sipit.net for more information and to register. See you in Beijing! RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 21 01:03:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INLsV-00067b-62; Tue, 21 Aug 2007 01:02:07 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1INLsT-00067S-UV for simple-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 01:02:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INLsT-00067I-Kv; Tue, 21 Aug 2007 01:02:05 -0400 Received: from pne-smtpout1-sn1.fre.skanova.net ([81.228.11.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INLsS-0003sA-5m; Tue, 21 Aug 2007 01:02:05 -0400 Received: from GunnarH (213.64.232.214) by pne-smtpout1-sn1.fre.skanova.net (7.2.076.2) id 46BB50DE002DA78F; Tue, 21 Aug 2007 07:01:56 +0200 Message-ID: <46BB50DE002DA78F@pne-smtpout1-sn1.fre.skanova.net> (added by postmaster@pne.skanova.net) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Adam Roach'" Subject: RE: [Simple] Chatroom Gap Analysis - Media and mode aspects Date: Tue, 21 Aug 2007 07:01:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <46C9CCD9.7080002@nostrum.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcfjTkDz6kiOZausS6qpAOE9qCLFfQAXoTQg X-Spam-Score: -1.0 (-) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: 'XCON-IETF' , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Adam, You say "All four items you mention above appear to be supported by IETF = protocols, although it may not be immediately clear to implementors how a user interface might present them -- perhaps there's room for a document that address, in particular, the interaction of real-time text with = multi-user conferences. A "best current practice" of sorts. Is that something you = might be interested in tackling?" I have started on a document in that direction.=20 See:=20 http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-01.txt It describes a way to present real-time text that feels very familiar = for the IM and chatroom user. It just adds the opportunity to see the = entries from selected parties in the session while they are created. It says that RFC 4103 would be the natural transport protocol for the = text, while also MSRP would be suitable if you take care to not transmit more = than at most once per second from parties actively composing entries.=20 You are right in that real-time text mixer for multi-user conferences = may need further elaboration. Especially the requirement to allow remote = erasure of already transmitted text is a challenge for a real-time text mixer. Do you see XCON or SIMPLE to be a suitable group for further work on = this draft? ---- My question had not only real-time text background. I am equally = interested in for example seeing good support for video in chat rooms, where the = video entries are not seen just as attachments to the text entry, but are = handled with full support for easy recording, entry and display in the chatroom. = So, I would appreciate if you could expand the media section a bit with more = on planned handling of multimedia contents.=20 -Gunnar -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Monday, August 20, 2007 7:18 PM To: Gunnar Hellstr=F6m Cc: 'XCON-IETF'; simple@ietf.org Subject: Re: [Simple] Chatroom Gap Analysis - Media and mode aspects On 8/17/07 10:37 PM, Gunnar Hellstr=F6m wrote: > Questions: > > 1. In your analysis of existing chat-room applications, have you found = > more orderly support for audio, video and images in addition to the=20 > default support for text? > =20 Not so much -- pretty much anything that isn't text tends to result in = some variation on a dialog box popping up asking where you want to save the content. MSRP actually does a bit better (in theory, at least), since = you can specify an "inline" disposition for (e.g.) images, which *should* cause clients to render the image in the chat window instead of saving it to disk. Exactly how this ends up being implemented is yet to be seen. > 2. Have you found planned support for text messages in other writing=20 > systems than left-to right? > =20 To the same degree as we have support in XMPP/SIMPLE -- the use of = UTF-8, in theory, provides all the support necessary for RTL text. In practice, = what different clients do when they see an RTL mark varies widely and is = often inexplicable. That is: the protocol gets this right, but implementors do random = things. > 3. Have you found support for the media to be transmitted and=20 > displayed in real-time as they are created? > =20 Not in chatroom scenarios, no -- at least, not since ytalk. Do you know = of a modern chatroom system that supports this? That said, there's nothing stopping clients from setting up RFC 4103 = streams towards a mixer -- the tricky part is rendering such mixed streams in a coherent fashion. > 4. Have you found support for ordered transition between message mode=20 > and real time mode? > =20 Not in existing systems, no. All four items you mention above appear to be supported by IETF = protocols, although it may not be immediately clear to implementors how a user interface might present them -- perhaps there's room for a document that address, in particular, the interaction of real-time text with = multi-user conferences. A "best current practice" of sorts. Is that something you = might be interested in tackling? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple __________ NOD32 2470 (20070819) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 21 10:29: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 1INUhe-0004GQ-EZ; Tue, 21 Aug 2007 10:27:30 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1INUhc-0004EX-Ej for simple-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 10:27:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INUhc-0004E3-2k; Tue, 21 Aug 2007 10:27:28 -0400 Received: from ns1.neustar.com ([156.154.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INUhb-0003KZ-4M; Tue, 21 Aug 2007 10:27:27 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id CCDB826E7A; Tue, 21 Aug 2007 14:27:26 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1INUha-0005tW-L3; Tue, 21 Aug 2007 10:27:26 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 21 Aug 2007 10:27:26 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: simple chair , Internet Architecture Board , simple mailing list , RFC Editor Subject: [Simple] Protocol Action: 'Presence Authorization Rules' to Proposed Standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The IESG has approved the following document: - 'Presence Authorization Rules ' as a Proposed Standard This document is the product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-10.txt Technical Summary There are three functions in a presence system; namely subscriptions, publishing and notifications. Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information, when sending notifications, can be given to which watchers, and when. This specification defines an XML document format for expressing presence authorization rules. Such a document can be manipulated by clients using XCAP, although other techniques are permitted. Working Group Summary This document reflects WG consensus. It defines the Presence Authorisation rules. Censensus was particularly strong. This document heavily depends on draft-ietf-geopriv-common-policy defined by the geopriv WG. Protocol Quality This document was reviewed for the IESG by Jon Peterson. Hisham Khartabil was the PROTO shepherd for this document. Gen-ART review was provided by Pasi Eronen. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 21 11:35:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVjM-0004yg-V2; Tue, 21 Aug 2007 11:33:21 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1INVjL-0004y8-EV for simple-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 11:33:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVjL-0004xy-4r; Tue, 21 Aug 2007 11:33:19 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INVjJ-0005rj-QR; Tue, 21 Aug 2007 11:33:19 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l7LFXBui096148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 10:33:12 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46CB05C3.5030909@nostrum.com> Date: Tue, 21 Aug 2007 10:33:23 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= Subject: Re: [Simple] Chatroom Gap Analysis - Media and mode aspects References: <46BB50DE002DA78F@pne-smtpout1-sn1.fre.skanova.net> (added by postmaster@pne.skanova.net) In-Reply-To: <46BB50DE002DA78F@pne-smtpout1-sn1.fre.skanova.net> (added by postmaster@pne.skanova.net) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.1/4019/Tue Aug 21 06:37:05 2007 on shaman.nostrum.com X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nostrum.com id l7LFXBui096148 X-Spam-Score: -1.4 (-) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'XCON-IETF' , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On 8/21/07 12:01 AM, Gunnar Hellstr=F6m wrote: > You are right in that real-time text mixer for multi-user conferences m= ay > need further elaboration. Especially the requirement to allow remote er= asure > of already transmitted text is a challenge for a real-time text mixer. > > Do you see XCON or SIMPLE to be a suitable group for further work on th= is > draft? > =20 The draft you currently have isn't conference specific -- it seems aimed=20 at one-to-one chat sessions. Between the two groups, I'd say SIMPLE is=20 the more appropriate, if you want to drive it through a working group. As a personal observation, this kind of work has generally received low=20 participation in SIMPLE, so you might be able to save yourself some=20 process overhead by publishing it as informational. I would contact the=20 RAI ADs for advice on the topic, though. > My question had not only real-time text background. I am equally intere= sted > in for example seeing good support for video in chat rooms, where the v= ideo > entries are not seen just as attachments to the text entry, but are han= dled > with full support for easy recording, entry and display in the chatroom= . So, > I would appreciate if you could expand the media section a bit with mor= e on > planned handling of multimedia contents.=20 > =20 What I think I hear you describing isn't as much "video in a chatroom"=20 as it is "multimodal conferencing", where the modes include (1) a text=20 chatroom, and (2) a video RTP stream. Correct me if that's not what you=20 mean. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 21 14:35:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INYY8-0002NZ-Ii; Tue, 21 Aug 2007 14:33:56 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1INYY6-0002NN-UN for simple-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 14:33:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INYY6-0002NE-JT; Tue, 21 Aug 2007 14:33:54 -0400 Received: from pne-smtpout2-sn2.hy.skanova.net ([81.228.8.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INYY5-0008C5-Tp; Tue, 21 Aug 2007 14:33:54 -0400 Received: from GunnarH (213.64.232.214) by pne-smtpout2-sn2.hy.skanova.net (7.2.075) id 46245DE101DDE54C; Tue, 21 Aug 2007 20:33:44 +0200 Message-ID: <46245DE101DDE54C@pne-smtpout2-sn2.hy.skanova.net> (added by postmaster@pne.skanova.net) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Adam Roach'" Subject: RE: [Simple] Chatroom Gap Analysis - Media and mode aspects Date: Tue, 21 Aug 2007 20:33:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <46CB05C3.5030909@nostrum.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcfkCJq4j5nYR/e0T9O9e+JAUv1VJQAEhyKA X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: 'XCON-IETF' , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Adam, You say: "What I think I hear you describing isn't as much "video in a chatroom"=20 as it is "multimodal conferencing", where the modes include (1) a text chatroom, and (2) a video RTP stream. Correct me if that's not what you mean."=20 No, I mean well integrated multimedia chat-rooms, where for example = video entries may come up as for example a thumbnail picture that strts to = play when you click on it. Text and audio and images belonging to such = entries are also displayed, on request. About the draft-hellstrom-text-preview, you say: "The draft you currently have isn't conference specific -- it seems = aimed at one-to-one chat sessions. Between the two groups, I'd say SIMPLE is the = more appropriate, if you want to drive it through a working group." It talks about hiding and displaying preview from different = participants, and labelling entries depending on the source etc. So, it is = definitively aiming at the multi-participant situation, with the minimum number of participants being two.=20 With this real-time preview, the border between a real-time conference = and a chat-room is disappearing. . Another item: I also have experienced that some chat roomms may have one audio stream playing in order to present an attractive environment for the room. The = same could be defined for video and text. Gunnar -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, August 21, 2007 5:33 PM To: Gunnar Hellstr=F6m Cc: 'XCON-IETF'; simple@ietf.org Subject: Re: [Simple] Chatroom Gap Analysis - Media and mode aspects On 8/21/07 12:01 AM, Gunnar Hellstr=F6m wrote: > You are right in that real-time text mixer for multi-user conferences=20 > may need further elaboration. Especially the requirement to allow=20 > remote erasure of already transmitted text is a challenge for a = real-time text mixer. > > Do you see XCON or SIMPLE to be a suitable group for further work on=20 > this draft? > =20 The draft you currently have isn't conference specific -- it seems aimed = at one-to-one chat sessions. Between the two groups, I'd say SIMPLE is the = more appropriate, if you want to drive it through a working group. As a personal observation, this kind of work has generally received low participation in SIMPLE, so you might be able to save yourself some = process overhead by publishing it as informational. I would contact the RAI ADs = for advice on the topic, though. > My question had not only real-time text background. I am equally=20 > interested in for example seeing good support for video in chat rooms, = > where the video entries are not seen just as attachments to the text=20 > entry, but are handled with full support for easy recording, entry and = > display in the chatroom. So, I would appreciate if you could expand=20 > the media section a bit with more on planned handling of multimedia contents. > =20 What I think I hear you describing isn't as much "video in a chatroom"=20 as it is "multimodal conferencing", where the modes include (1) a text chatroom, and (2) a video RTP stream. Correct me if that's not what you mean. /a __________ NOD32 2472 (20070821) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 21 17:41: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 1INbRs-0002SN-KK; Tue, 21 Aug 2007 17:39:40 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1INbRr-0002SH-PS for simple-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 17:39:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INbRr-0002S7-Fq for simple@ietf.org; Tue, 21 Aug 2007 17:39:39 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INbRq-0008Tg-SA for simple@ietf.org; Tue, 21 Aug 2007 17:39:39 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l7LLdb1P001319 for ; Tue, 21 Aug 2007 14:39:37 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l7LLdZKS010223 for ; Tue, 21 Aug 2007 14:39:36 -0700 Received: from 172.24.28.189 ([172.24.28.189]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Tue, 21 Aug 2007 21:39:35 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 21 Aug 2007 17:39:34 -0400 From: Eric Burger To: Message-ID: Thread-Topic: And now, for something different Thread-Index: AcfkO8OmAh7p+1AvEdy/WQAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Simple] And now, for something different 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 Any takers for http://www.ietf.org/internet-drafts/draft-burger-simple-im-cancel-request-00 .txt ??? The Abstract: This document describes a mechanism for a user agent client to request the marking of a previously sent Instant Message as cancelled. From a user's perspective, the user agent server, or other proxies or relay points in the network, can effectively remove the first message, giving the impression the first message was cancelled. This document describes the utility of such a function, as well as the futility of attempting to create a true message cancellation feature. This was a discussion topic in the SIP WG in Chicago. This draft is considerably different than the draft discussed there. Is this of interest for the SIMPLE group? Thanks. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 21 18:29: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 1INcCG-0006HE-9N; Tue, 21 Aug 2007 18:27:36 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1INcCE-0006H7-Vg for simple-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 18:27:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INcCE-0006Gz-M1 for simple@ietf.org; Tue, 21 Aug 2007 18:27:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INcCD-0001JD-Dk for simple@ietf.org; Tue, 21 Aug 2007 18:27:34 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Aug 2007 18:27:33 -0400 X-IronPort-AV: i="4.19,291,1183348800"; d="scan'208"; a="68646595:sNHT48590236" 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 l7LMRXCh008538; Tue, 21 Aug 2007 18:27:33 -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 l7LMRTxs014316; Tue, 21 Aug 2007 22:27:29 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 18:27:28 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 18:27:28 -0400 Message-ID: <46CB66D2.60905@cisco.com> Date: Tue, 21 Aug 2007 18:27:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Burger Subject: Re: [Simple] And now, for something different References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Aug 2007 22:27:28.0533 (UTC) FILETIME=[75011C50:01C7E442] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1898; t=1187735253; x=1188599253; 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]=20And=20now, =20for=20something=20different |Sender:=20 |To:=20Eric=20Burger=20; bh=pkHIOrgvK0Brj/pZperB7Ng8AXJ1oe/YnKonBMn8R+I=; b=BoFv0ve3t0QsH4l6/M+C65TNnlYP/OGoyNo6lwUrUVu+JErcu1eO2yHuYXSBeKTlLsZbDeB+ wo8hVc97QAbuXhj5QiLBuE6PjpqtjU7zTanfrkCDLTCW92esaFMF/4zA; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I like it - to the extent that if you want something like that then it is probably the best that can be done. OTOH its still not very high on my priority list for things that need to be done at all. I don't currently use any IM that does store and forward, so its utility is moot for me. If I did, I suppose I might use it on rare occasion (if I could remember how). Paul Eric Burger wrote: > Any takers for > http://www.ietf.org/internet-drafts/draft-burger-simple-im-cancel-request-00 > .txt > > ??? > > The Abstract: > This document describes a mechanism for a user agent client to > request the marking of a previously sent Instant Message as > cancelled. From a user's perspective, the user agent server, or > other proxies or relay points in the network, can effectively remove > the first message, giving the impression the first message was > cancelled. This document describes the utility of such a function, > as well as the futility of attempting to create a true message > cancellation feature. > > > This was a discussion topic in the SIP WG in Chicago. This draft is > considerably different than the draft discussed there. > > Is this of interest for the SIMPLE group? > > Thanks. > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > > > _______________________________________________ > 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 Aug 28 03:41: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 1IPvfq-0003M8-R5; Tue, 28 Aug 2007 03:39:42 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IPvfq-0003M2-9w for simple-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 03:39:42 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IPvfq-0003Lu-0f for simple@ietf.org; Tue, 28 Aug 2007 03:39:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvPL-0007Tb-0j for simple@ietf.org; Tue, 28 Aug 2007 03:22:39 -0400 Received: from fk-out-0910.google.com ([209.85.128.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPvPJ-0002wd-OC for simple@ietf.org; Tue, 28 Aug 2007 03:22:38 -0400 Received: by fk-out-0910.google.com with SMTP id z23so1640366fkz for ; Tue, 28 Aug 2007 00:22:37 -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=btonthlmvyIgL3v/mnV/HXpMGMFHWKiTv58tkZtAmTAng9zqmMr+JFalsRVtCmT5LRwjh/B9CasdqqpzNdJ5bHOlXiDkGYLgz86tBHUUuD4XpRKUQMdifgMJ65+Zf2fkp4ON+GZud5n33FAnmTtNe3pYsKZL7qHaSv0xzxqL4u4= 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=cPa1BGwu1XYwBtpKBH6aExkwe/E0IbUFLf2mstvXfi9fQm0W2XY0LesGfBcLaikYAZVmbAcyNaZEfUZuCmGRwhYMh0iX5ZyYRV30fRJdZl2xwLluGEYLDfdtZEp5LpNraJBhMWOl3/t5xbboKE7ETkl0Ko7c6kPpYC1Qf8kEAfQ= Received: by 10.82.183.19 with SMTP id g19mr16026288buf.1188285756430; Tue, 28 Aug 2007 00:22:36 -0700 (PDT) Received: by 10.82.155.6 with HTTP; Tue, 28 Aug 2007 00:22:36 -0700 (PDT) Message-ID: <214710f30708280022tc1575d5v2f86a49b227f8fec@mail.gmail.com> Date: Tue, 28 Aug 2007 12:52:36 +0530 From: "Reddeppa Reddy L" To: simple@ietf.org, ben@estacado.net MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-TMDA-Confirmed: Tue, 28 Aug 2007 03:39:41 -0400 Cc: Subject: [Simple] Regarding MSRP Reports 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="===============1183116475==" Errors-To: simple-bounces@ietf.org --===============1183116475== Content-Type: multipart/alternative; boundary="----=_Part_123989_3220313.1188285756397" ------=_Part_123989_3220313.1188285756397 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Ben, I have following doubt about usage MSRP Reports. In the MSRP specification, it is mentioned that Reports indicate the "delivery status" of messages. Does the delivery status "Success" means 1. Application has just received the complete message from MSRP stack (receiving end point) OR 2. Application has received the complete message from MSRP stack and is able to process it successfully. I hope Ben or somebody from the group clarify my doubt. Thanks in advance, Reddeppa Reddy L Samsung India Software Operations Pvt Ltd, India. ------=_Part_123989_3220313.1188285756397 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Ben,

I have following doubt about usage MSRP Reports.

In the MSRP specification, it is mentioned that Reports indicate the "delivery status" of messages. Does the delivery status "Success" means

1. Application has just received the complete message from MSRP stack (receiving end point) OR
2. Application has received the complete message from MSRP stack and is able to process it successfully.

I hope Ben or somebody from the group clarify my doubt.

Thanks in advance,
Reddeppa Reddy L
Samsung India Software Operations Pvt Ltd, India.

------=_Part_123989_3220313.1188285756397-- --===============1183116475== 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 --===============1183116475==-- From simple-bounces@ietf.org Tue Aug 28 09:25:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ12L-0005Wc-IM; Tue, 28 Aug 2007 09:23:17 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IQ12K-0005WW-1C for simple-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 09:23:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ12J-0005WK-NM for simple@ietf.org; Tue, 28 Aug 2007 09:23:15 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ12J-0007rk-8Y for simple@ietf.org; Tue, 28 Aug 2007 09:23:15 -0400 Received: from [10.0.1.200] (adsl-68-94-26-246.dsl.rcsntx.swbell.net [68.94.26.246]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l7SDN7FN062262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Aug 2007 08:23:11 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <214710f30708280022tc1575d5v2f86a49b227f8fec@mail.gmail.com> References: <214710f30708280022tc1575d5v2f86a49b227f8fec@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Tue, 28 Aug 2007 08:23:07 -0500 To: "Reddeppa Reddy L" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: simple@ietf.org Subject: [Simple] Re: Regarding MSRP Reports X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Aug 28, 2007, at 2:22 AM, Reddeppa Reddy L wrote: > Hi Ben, > > I have following doubt about usage MSRP Reports. > > In the MSRP specification, it is mentioned that Reports indicate > the "delivery status" of messages. Does the delivery status > "Success" means > > 1. Application has just received the complete message from MSRP > stack (receiving end point) OR > 2. Application has received the complete message from MSRP stack > and is able to process it successfully. It means the application has received and processed the byte-range of the message as indicated in the byte-range header field. It could be the whole message or a subset. Keep in mind that "processed" is not a well defined term. A success report should indicate that automatic processing, local policy checks, etc, have succeeded. It is _not_ a guarantee that a human has, or ever will, see the message. Hope this helps! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 30 03:09: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 1IQe7Y-0004fT-TR; Thu, 30 Aug 2007 03:07:16 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IQe7X-0004fB-HW for simple-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 03:07:15 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IQe7X-0004f1-5O for simple@ietf.org; Thu, 30 Aug 2007 03:07:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQe35-00033C-KJ for simple@ietf.org; Thu, 30 Aug 2007 03:02:39 -0400 Received: from [212.25.80.121] (helo=VRZIL-MR.il.veraznetworks.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQe34-0004jP-ON for simple@ietf.org; Thu, 30 Aug 2007 03:02:39 -0400 Received: from VRZIL-EX01.il.veraznetworks.com ([172.29.1.6]) by VRZIL-MR.il.veraznetworks.com with InterScan Message Security Suite; Thu, 30 Aug 2007 10:04:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Aug 2007 10:02:36 +0300 Message-ID: <30F0D7625E0DEC4E83A2A94596BC18B701F70255@VRZIL-EX01.il.veraznetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Report with a body Thread-Index: Acfq076xCqyPgChJSG6GbluGSRtN6A== From: "Arie Reches" To: X-Spam-Score: 1.6 (+) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 X-TMDA-Confirmed: Thu, 30 Aug 2007 03:07:15 -0400 Subject: [Simple] Report with a body 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="===============1374277269==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1374277269== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EAD4.2A7AB680" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EAD4.2A7AB680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 In section 4.1.2 of draft-ietf-simple-message-sessions-19 mentioned that a REPORT message may include a body. =20 The problem is that the Byte-Range header of the REPORT message is relating SEND message. =20 Can you give an example of REPORT message with Body. =20 The example for report message without a body is: MSRP dkei38sd REPORT To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp Message-ID: 12339sdqwer Byte-Range: 1-106/106 Status: 000 200 OK -------dkei38sd$ =20 How the same report with a body shall be formatted? Arie ------_=_NextPart_001_01C7EAD4.2A7AB680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

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

 

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

 

         =    Can you give an example of REPORT message with Body.

 

         =    The example for report message without a body = is:

         =       MSRP dkei38sd = REPORT

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

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

   Message-ID: = 12339sdqwer

   Byte-Range: = 1-106/106

   Status: 000 = 200 OK

  =  -------dkei38sd$

 

         =    How the same report with a body shall be = formatted?

Arie

------_=_NextPart_001_01C7EAD4.2A7AB680-- --===============1374277269== 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 --===============1374277269==-- From KellieadenosineFair@andy-roddick.org Thu Aug 30 17:45:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQrpb-0004GU-Di for simple-archive@lists.ietf.org; Thu, 30 Aug 2007 17:45:39 -0400 Received: from [208.29.186.127] (helo=dustybox.nep.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IQrpY-0007wW-Da for simple-archive@lists.ietf.org; Thu, 30 Aug 2007 17:45:39 -0400 Message-ID: <0ff701c7eb4f$ba673c20$7fba1dd0@dustybox> From: "Josefina Swan" To: Subject: Fwd: Thank you, we are ready to lend your company money Date: Thu, 30 Aug 2007 17:48:35 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0FF3_01C7EB4F.BA673C20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ------=_NextPart_000_0FF3_01C7EB4F.BA673C20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If you have your own business and wish IMMEDIATE cash to spend ANY way = you like or want Extra money to give the company a boost or wish A low = interest loan - NO STRINGS ATTACHED, here is the deal we can offer you = NOW (hurry, this tender will expire TODAY): $58,000+ loan Hurry, when our best deal is gone, it is gone. Simply Call Us Free on = 877-292-6890 ------=_NextPart_000_0FF3_01C7EB4F.BA673C20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you have your own business and wish = IMMEDIATE=20 cash to spend ANY way you like or want Extra money to give the company a = boost=20 or wish A low interest loan - NO STRINGS ATTACHED, here is the deal we = can=20 offer you NOW (hurry, this tender will expire TODAY):
=20
 
$58,000+ loan
 
Hurry, when our best deal is gone, it = is gone.=20 Simply Call Us Free on 877-292-6890
------=_NextPart_000_0FF3_01C7EB4F.BA673C20-- From simple-bounces@ietf.org Thu Aug 30 18:58:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQsw5-0005eE-K1; Thu, 30 Aug 2007 18:56:25 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IQsw3-0005e7-VV for simple-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 18:56:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQsw3-0005dz-J4 for simple@ietf.org; Thu, 30 Aug 2007 18:56:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQsw2-0007Vx-VW for simple@ietf.org; Thu, 30 Aug 2007 18:56:23 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Aug 2007 18:56:24 -0400 X-IronPort-AV: i="4.19,327,1183348800"; d="scan'208,217"; a="130536480:sNHT95100350" 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 l7UMuMKV014051; Thu, 30 Aug 2007 18:56:22 -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 l7UMuALn008249; Thu, 30 Aug 2007 22:56:14 GMT Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 18:56:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple] Report with a body Date: Thu, 30 Aug 2007 18:56:06 -0400 Message-ID: <8983EC086A9D954BA74D9763E853CF3E03C4C148@xmb-rtp-215.amer.cisco.com> In-Reply-To: <30F0D7625E0DEC4E83A2A94596BC18B701F70255@VRZIL-EX01.il.veraznetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Report with a body Thread-Index: Acfq076xCqyPgChJSG6GbluGSRtN6AAhJmTw From: "Sanjay Sinha \(sanjsinh\)" To: "Arie Reches" , X-OriginalArrivalTime: 30 Aug 2007 22:56:09.0932 (UTC) FILETIME=[F4C180C0:01C7EB58] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11581; t=1188514582; x=1189378582; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20\(sanjsinh\)=22=20 |Subject:=20RE=3A=20[Simple]=20Report=20with=20a=20body |Sender:=20 |To:=20=22Arie=20Reches=22=20, =20; bh=WVwIGzCm5n3EtMEdzwlwge06iySYJ+ux059PAEYRgiM=; b=PL+4ICecEZeHoVAUCY0aN/KEGjef0fPUuwUNCJk5aSesxz7qmsoYSFbaUGv8qnj/J81FDLO1 GwNgiCFHGuSCTS1kfaMuXuu1BMIoR8e+hKVArrtHqY89qlwAMB8kXkJx; Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 1.5 (+) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 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="===============0714950983==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0714950983== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EB58.F44E508F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EB58.F44E508F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I think the headers in REPORT will contain sufficient information about this request to the sender and body is purely informational. =20 An example would be something like: =20 MSRP dkei38sd REPORT To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp Message-ID: 12339sdqwer Byte-Range: 1-106/106 Status: 000 200 OK Content-Type: text/plain =20 Success -------dkei38sd$ =20 Sanjay =20 ________________________________ From: Arie Reches [mailto:Arie.Reches@veraznetworks.com]=20 Sent: Thursday, August 30, 2007 3:03 AM To: simple@ietf.org Subject: [Simple] Report with a body =09 =09 Hi, =20 In section 4.1.2 of draft-ietf-simple-message-sessions-19 mentioned that a REPORT message may include a body. =20 The problem is that the Byte-Range header of the REPORT message is relating SEND message. =20 Can you give an example of REPORT message with Body. =20 The example for report message without a body is: MSRP dkei38sd REPORT To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp Message-ID: 12339sdqwer Byte-Range: 1-106/106 Status: 000 200 OK -------dkei38sd$ =20 How the same report with a body shall be formatted? Arie ------_=_NextPart_001_01C7EB58.F44E508F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I think the headers in REPORT will contain = sufficient=20 information about this request to the sender and body is purely=20 informational.
 
An example would be something = like:
 
MSRP dkei38sd REPORT
To-Path:=20 msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path:=20 msrp://bob.example.com:8888/9di4eae923wzd;tcp
Message-ID:=20 12339sdqwer
Byte-Range:=20 1-106/106
Status: 000=20 200 OK
Content-Type:=20 text/plain
 
Success
-------dkei38sd$
 
Sanjay
 

From: Arie Reches=20 [mailto:Arie.Reches@veraznetworks.com]
Sent: Thursday, = August 30,=20 2007 3:03 AM
To: simple@ietf.org
Subject: [Simple] = Report=20 with a body

Hi,

 

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

 

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

 

           = =20 Can you give an example of REPORT message with=20 Body.

 

           = =20 The example for report message without a body = is:

           = =20    MSRP dkei38sd REPORT

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

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

   Message-ID: = 12339sdqwer

   Byte-Range: = 1-106/106

   Status: 000 = 200=20 OK

 =20  -------dkei38sd$

 

           = =20 How the same report with a body shall be=20 formatted?

Arie

= ------_=_NextPart_001_01C7EB58.F44E508F-- --===============0714950983== 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 --===============0714950983==--