From iesg-secretary@ietf.org Thu Nov 3 07:03:46 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E59D1F0CB1; Thu, 3 Nov 2011 07:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id als1hPuautiQ; Thu, 3 Nov 2011 07:03:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C79B1F0C9B; Thu, 3 Nov 2011 07:03:45 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111103140345.5636.82476.idtracker@ietfa.amsl.com> Date: Thu, 03 Nov 2011 07:03:45 -0700 Cc: simple@ietf.org Subject: [Simple] Last Call: (Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)) to Proposed Standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 14:03:46 -0000 The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-11-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of the extension is optional. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages, and thus also enables a secure end-to-end MSRP communication in networks where such middleboxes are deployed. The document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-simple-msrp-cema/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-simple-msrp-cema/ No IPR declarations have been submitted directly on this I-D. From wwwrun@rfc-editor.org Fri Nov 4 07:14:24 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CB721F8C5E for ; Fri, 4 Nov 2011 07:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFNRZR13HQtU for ; Fri, 4 Nov 2011 07:14:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7D23B21F8C44 for ; Fri, 4 Nov 2011 07:14:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C00066219F; Fri, 4 Nov 2011 07:09:53 -0700 (PDT) To: eburger@standardstrack.com, hisham.khartabil@gmail.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com From: RFC Errata System Message-Id: <20111104140953.C00066219F@rfc-editor.org> Date: Fri, 4 Nov 2011 07:09:53 -0700 (PDT) Cc: rfc-editor@rfc-editor.org, simple@ietf.org, dan.price@infinite.com Subject: [Simple] [Technical Errata Reported] RFC5438 (3013) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 14:14:25 -0000 The following errata report has been submitted for RFC5438, "Instant Message Disposition Notification (IMDN)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5438&eid=3013 -------------------------------------- Type: Technical Reported by: Dan Price Section: 7.2.1.1 Original Text ------------- From: Bob To: Alice NS: imdn imdn.Message-ID: d834jied93rf Content-type: message/imdn+xml Content-Disposition: notification Content-length: ... Corrected Text -------------- From: Bob To: Alice NS: imdn imdn.Message-ID: d834jied93rf Content-type: message/imdn+xml Content-Disposition: notification Content-length: ... Notes ----- None of the examples in this RFC comply with the format of CPIM defined in RFC 3862, in which the message metadata headers are separated from the headers of the encapsulated MIME object by a blank line. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5438 (draft-ietf-simple-imdn-10) -------------------------------------- Title : Instant Message Disposition Notification (IMDN) Publication Date : February 2009 Author(s) : E. Burger, H. Khartabil Category : PROPOSED STANDARD Source : SIP for Instant Messaging and Presence Leveraging Extensions Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nancy.greene@ericsson.com Fri Nov 4 07:48:27 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C0B21F8B7A for ; Fri, 4 Nov 2011 07:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euiZ-tkaIamk for ; Fri, 4 Nov 2011 07:48:26 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C63AC21F8C16 for ; Fri, 4 Nov 2011 07:48:25 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA4EmFJO031173; Fri, 4 Nov 2011 09:48:18 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.174]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 4 Nov 2011 10:48:13 -0400 From: Nancy Greene To: RFC Errata System , "eburger@standardstrack.com" , "hisham.khartabil@gmail.com" , Gonzalo Camarillo , "rjsparks@nostrum.com" , "ben@nostrum.com" Date: Fri, 4 Nov 2011 10:48:12 -0400 Thread-Topic: [Simple] [Technical Errata Reported] RFC5438 (3013) Thread-Index: Acya/Bh3XzVGF1JOSLmmOxUjpW9q9AABH8kA Message-ID: References: <20111104140953.C00066219F@rfc-editor.org> In-Reply-To: <20111104140953.C00066219F@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "simple@ietf.org" , "dan.price@infinite.com" Subject: Re: [Simple] [Technical Errata Reported] RFC5438 (3013) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 14:48:27 -0000 This is the same issue I raised on the sip-implementor's list. Good to see = this errata finally posted! https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-September/027= 736.html Nancy=20 www.ericsson.com - This Communication is Confidential. We only send and re= ceive email on the basis of the term set out at www.ericsson.com/email_disc= laimer =20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= RFC Errata System Sent: November-04-11 10:10 AM To: eburger@standardstrack.com; hisham.khartabil@gmail.com; Gonzalo Camaril= lo; rjsparks@nostrum.com; ben@nostrum.com; hisham.khartabil@gmail.com Cc: rfc-editor@rfc-editor.org; simple@ietf.org; dan.price@infinite.com Subject: [Simple] [Technical Errata Reported] RFC5438 (3013) The following errata report has been submitted for RFC5438, "Instant Messag= e Disposition Notification (IMDN)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D5438&eid=3D3013 -------------------------------------- Type: Technical Reported by: Dan Price Section: 7.2.1.1 Original Text ------------- From: Bob To: Alice NS: imdn imdn.Message-ID: d834jied93rf Content-type: message/imdn+xml Content-Disposition: notification Content-length: ... Corrected Text -------------- From: Bob To: Alice NS: imdn imdn.Message-ID: d834jied93rf Content-type: message/imdn+xml Content-Disposition: notification Content-length: ... Notes ----- None of the examples in this RFC comply with the format of CPIM defined in = RFC 3862, in which the message metadata headers are separated from the head= ers of the encapsulated MIME object by a blank line. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Re= ply All" to discuss whether it should be verified or rejected. When a decis= ion is reached, the verifying party (IESG) can log in to change the status = and edit the report, if necessary.=20 -------------------------------------- RFC5438 (draft-ietf-simple-imdn-10) -------------------------------------- Title : Instant Message Disposition Notification (IMDN) Publication Date : February 2009 Author(s) : E. Burger, H. Khartabil Category : PROPOSED STANDARD Source : SIP for Instant Messaging and Presence Leveraging Ext= ensions Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From hisham.khartabil@gmail.com Sun Nov 6 19:57:27 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5FA1F0C35 for ; Sun, 6 Nov 2011 19:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBIjS-UFERdd for ; Sun, 6 Nov 2011 19:57:26 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 68B151F0C34 for ; Sun, 6 Nov 2011 19:57:26 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so3700286bkb.31 for ; Sun, 06 Nov 2011 19:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oXHBOY1ezeNYaq6mFkB0E5coVwhxcrjL3DFraShHwGw=; b=GHoKT8pjfAv0xSLXhi2k8xZyUdIbnhj3xezO6RkyE1lO1bvpAr+1PQG6NkikUKrmGj qSd9ojuYrxedt/RkAyVUsJeQh5eisg2cgHwRG+bO8+HzRAqB0EVBswInZcFP4q+KYsBS /+qmRzK6ExuOezixXwKCFoJ2vnEiXUU2+1Zp8= MIME-Version: 1.0 Received: by 10.204.9.1 with SMTP id j1mr17928871bkj.57.1320638245338; Sun, 06 Nov 2011 19:57:25 -0800 (PST) Received: by 10.204.54.19 with HTTP; Sun, 6 Nov 2011 19:57:24 -0800 (PST) In-Reply-To: References: <20111104140953.C00066219F@rfc-editor.org> Date: Mon, 7 Nov 2011 14:57:25 +1100 Message-ID: From: Hisham Khartabil To: Nancy Greene Content-Type: multipart/alternative; boundary=00151758f34c7d7e6b04b11d0d4c Cc: "dan.price@infinite.com" , "simple@ietf.org" , RFC Errata System Subject: Re: [Simple] [Technical Errata Reported] RFC5438 (3013) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 03:57:27 -0000 --00151758f34c7d7e6b04b11d0d4c Content-Type: text/plain; charset=ISO-8859-1 Hi, I see separators in the examples in RFC3862, but I fail to find the text that mandates that or describes it. Can you point it out to me? Thanks, Hisham On 5 November 2011 01:48, Nancy Greene wrote: > This is the same issue I raised on the sip-implementor's list. Good to see > this errata finally posted! > > https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-September/027736.html > > Nancy > > > www.ericsson.com - This Communication is Confidential. We only send and > receive email on the basis of the term set out at > www.ericsson.com/email_disclaimer > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of RFC Errata System > Sent: November-04-11 10:10 AM > To: eburger@standardstrack.com; hisham.khartabil@gmail.com; Gonzalo > Camarillo; rjsparks@nostrum.com; ben@nostrum.com; > hisham.khartabil@gmail.com > Cc: rfc-editor@rfc-editor.org; simple@ietf.org; dan.price@infinite.com > Subject: [Simple] [Technical Errata Reported] RFC5438 (3013) > > > The following errata report has been submitted for RFC5438, "Instant > Message Disposition Notification (IMDN)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5438&eid=3013 > > -------------------------------------- > Type: Technical > Reported by: Dan Price > > Section: 7.2.1.1 > > Original Text > ------------- > From: Bob > To: Alice > NS: imdn > imdn.Message-ID: d834jied93rf > Content-type: message/imdn+xml > Content-Disposition: notification > Content-length: ... > > > Corrected Text > -------------- > From: Bob > To: Alice > NS: imdn > imdn.Message-ID: d834jied93rf > > Content-type: message/imdn+xml > Content-Disposition: notification > Content-length: ... > > > Notes > ----- > None of the examples in this RFC comply with the format of CPIM defined in > RFC 3862, in which the message metadata headers are separated from the > headers of the encapsulated MIME object by a blank line. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please use > "Reply All" to discuss whether it should be verified or rejected. When a > decision is reached, the verifying party (IESG) can log in to change the > status and edit the report, if necessary. > > -------------------------------------- > RFC5438 (draft-ietf-simple-imdn-10) > -------------------------------------- > Title : Instant Message Disposition Notification (IMDN) > Publication Date : February 2009 > Author(s) : E. Burger, H. Khartabil > Category : PROPOSED STANDARD > Source : SIP for Instant Messaging and Presence Leveraging > Extensions > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > --00151758f34c7d7e6b04b11d0d4c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I see separators in the examples in RFC3862, but I fail to find = the text that mandates that or describes it. Can you point it out to me?
Thanks,
Hisham

On 5 November 2011= 01:48, Nancy Greene <nancy.greene@ericsson.com> wrote:
This is the same issue I raised on the sip-= implementor's list. Good to see this errata finally posted!
https://lists.cs.columbia.edu/piperm= ail/sip-implementors/2011-September/027736.html

Nancy


www.ericsson.com = =A0- This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email_disclaimer

-----Original Message-----
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.or= g] On Behalf Of RFC Errata System
Sent: November-04-11 10:10 AM
To: eburger@standardstrack.co= m; hisham.khartabil@gmail= .com; Gonzalo Camarillo; rjspar= ks@nostrum.com; ben@nostrum.com;= hisham.khartabil@gmail.com
Cc: rfc-editor@rfc-editor.org<= /a>; simple@ietf.org; dan.price@infinite.com
Subject: [Simple] [Technical Errata Reported] RFC5438 (3013)


The following errata report has been submitted for RFC5438, "Instant M= essage Disposition Notification (IMDN)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc= =3D5438&eid=3D3013

--------------------------------------
Type: Technical
Reported by: Dan Price <dan.pr= ice@infinite.com>

Section: 7.2.1.1

Original Text
-------------
=A0 From: Bob <im:bob@example.c= om>
=A0 To: Alice <im:alice@examp= le.com>
=A0 NS: imdn <urn:ietf:params:imdn>
=A0 imdn.Message-ID: d834jied93rf
=A0 Content-type: message/imdn+xml
=A0 Content-Disposition: notification
=A0 Content-length: ...


Corrected Text
--------------
=A0 From: Bob <im:bob@example.c= om>
=A0 To: Alice <im:alice@examp= le.com>
=A0 NS: imdn <urn:ietf:params:imdn>
=A0 imdn.Message-ID: d834jied93rf

=A0 Content-type: message/imdn+xml
=A0 Content-Disposition: notification
=A0 Content-length: ...


Notes
-----
None of the examples in this RFC comply with the format of CPIM defined in = RFC 3862, in which the message metadata headers are separated from the head= ers of the encapsulated MIME object by a blank line.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se use "Reply All" to discuss whether it should be verified or re= jected. When a decision is reached, the verifying party (IESG) can log in t= o change the status and edit the report, if necessary.

--------------------------------------
RFC5438 (draft-ietf-simple-imdn-10)
--------------------------------------
Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Instant Message Disposition Notificatio= n (IMDN)
Publication Date =A0 =A0: February 2009
Author(s) =A0 =A0 =A0 =A0 =A0 : E. Burger, H. Khartabil
Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD
Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: SIP for Instant Messaging and Presence = Leveraging Extensions
Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Real-time Applications and Infrastruc= ture
Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
Verifying Party =A0 =A0 : IESG
_______________________________________________
Simple mailing list
Simple@ietf.org
= https://www.ietf.org/mailman/listinfo/simple

--00151758f34c7d7e6b04b11d0d4c-- From rjsparks@nostrum.com Mon Nov 7 07:32:38 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4609D21F8B59 for ; Mon, 7 Nov 2011 07:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OLmU2HnXU5N for ; Mon, 7 Nov 2011 07:32:34 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA7221F8B79 for ; Mon, 7 Nov 2011 07:32:34 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pA7FW9ns076037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Nov 2011 09:32:09 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-37-922829032 From: Robert Sparks In-Reply-To: Date: Mon, 7 Nov 2011 09:32:08 -0600 Message-Id: <56F9E2DE-61E5-4C91-99D9-A9338FBB8893@nostrum.com> References: <20111104140953.C00066219F@rfc-editor.org> To: Hisham Khartabil X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Nancy Greene , "simple@ietf.org" , "dan.price@infinite.com" , RFC Errata System Subject: Re: [Simple] [Technical Errata Reported] RFC5438 (3013) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 15:32:38 -0000 --Apple-Mail-37-922829032 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I don't find 2119 language, but the requirement is described in the = second paragraph of section 2. I've marked this hold for document update. RjS On Nov 6, 2011, at 9:57 PM, Hisham Khartabil wrote: > Hi, >=20 > I see separators in the examples in RFC3862, but I fail to find the = text that mandates that or describes it. Can you point it out to me? >=20 > Thanks, > Hisham >=20 > On 5 November 2011 01:48, Nancy Greene = wrote: > This is the same issue I raised on the sip-implementor's list. Good to = see this errata finally posted! > = https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-September/02= 7736.html >=20 > Nancy >=20 >=20 > www.ericsson.com - This Communication is Confidential. We only send = and receive email on the basis of the term set out at = www.ericsson.com/email_disclaimer >=20 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf Of RFC Errata System > Sent: November-04-11 10:10 AM > To: eburger@standardstrack.com; hisham.khartabil@gmail.com; Gonzalo = Camarillo; rjsparks@nostrum.com; ben@nostrum.com; = hisham.khartabil@gmail.com > Cc: rfc-editor@rfc-editor.org; simple@ietf.org; dan.price@infinite.com > Subject: [Simple] [Technical Errata Reported] RFC5438 (3013) >=20 >=20 > The following errata report has been submitted for RFC5438, "Instant = Message Disposition Notification (IMDN)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5438&eid=3D3013 >=20 > -------------------------------------- > Type: Technical > Reported by: Dan Price >=20 > Section: 7.2.1.1 >=20 > Original Text > ------------- > From: Bob > To: Alice > NS: imdn > imdn.Message-ID: d834jied93rf > Content-type: message/imdn+xml > Content-Disposition: notification > Content-length: ... >=20 >=20 > Corrected Text > -------------- > From: Bob > To: Alice > NS: imdn > imdn.Message-ID: d834jied93rf >=20 > Content-type: message/imdn+xml > Content-Disposition: notification > Content-length: ... >=20 >=20 > Notes > ----- > None of the examples in this RFC comply with the format of CPIM = defined in RFC 3862, in which the message metadata headers are separated = from the headers of the encapsulated MIME object by a blank line. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please = use "Reply All" to discuss whether it should be verified or rejected. = When a decision is reached, the verifying party (IESG) can log in to = change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC5438 (draft-ietf-simple-imdn-10) > -------------------------------------- > Title : Instant Message Disposition Notification (IMDN) > Publication Date : February 2009 > Author(s) : E. Burger, H. Khartabil > Category : PROPOSED STANDARD > Source : SIP for Instant Messaging and Presence = Leveraging Extensions > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 --Apple-Mail-37-922829032 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I don't find 2119 language, but the requirement is described in the second paragraph of section 2.
I've marked this hold for document update.

RjS

On Nov 6, 2011, at 9:57 PM, Hisham Khartabil wrote:

Hi,

I see separators in the examples in RFC3862, but I fail to find the text that mandates that or describes it. Can you point it out to me?

Thanks,
Hisham

On 5 November 2011 01:48, Nancy Greene <nancy.greene@ericsson.com> wrote:
This is the same issue I raised on the sip-implementor's list. Good to see this errata finally posted!
https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-September/027736.html

Nancy


www.ericsson.com  - This Communication is Confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer

-----Original Message-----
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of RFC Errata System
Sent: November-04-11 10:10 AM
To: eburger@standardstrack.com; hisham.khartabil@gmail.com; Gonzalo Camarillo; rjsparks@nostrum.com; ben@nostrum.com; hisham.khartabil@gmail.com
Cc: rfc-editor@rfc-editor.org; simple@ietf.org; dan.price@infinite.com
Subject: [Simple] [Technical Errata Reported] RFC5438 (3013)


The following errata report has been submitted for RFC5438, "Instant Message Disposition Notification (IMDN)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5438&eid=3013

--------------------------------------
Type: Technical
Reported by: Dan Price <dan.price@infinite.com>

Section: 7.2.1.1

Original Text
-------------
  From: Bob <im:bob@example.com>
  To: Alice <im:alice@example.com>
  NS: imdn <urn:ietf:params:imdn>
  imdn.Message-ID: d834jied93rf
  Content-type: message/imdn+xml
  Content-Disposition: notification
  Content-length: ...


Corrected Text
--------------
  From: Bob <im:bob@example.com>
  To: Alice <im:alice@example.com>
  NS: imdn <urn:ietf:params:imdn>
  imdn.Message-ID: d834jied93rf

  Content-type: message/imdn+xml
  Content-Disposition: notification
  Content-length: ...


Notes
-----
None of the examples in this RFC comply with the format of CPIM defined in RFC 3862, in which the message metadata headers are separated from the headers of the encapsulated MIME object by a blank line.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5438 (draft-ietf-simple-imdn-10)
--------------------------------------
Title               : Instant Message Disposition Notification (IMDN)
Publication Date    : February 2009
Author(s)           : E. Burger, H. Khartabil
Category            : PROPOSED STANDARD
Source              : SIP for Instant Messaging and Presence Leveraging Extensions
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple


--Apple-Mail-37-922829032-- From miguel.a.garcia@ericsson.com Tue Nov 22 03:39:14 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B8021F8D57 for ; Tue, 22 Nov 2011 03:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clAIRyiPeizX for ; Tue, 22 Nov 2011 03:39:14 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id BF31321F8D54 for ; Tue, 22 Nov 2011 03:39:13 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-3b-4ecb89e0d5e5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EE.46.13753.0E98BCE4; Tue, 22 Nov 2011 12:39:12 +0100 (CET) Received: from [159.107.24.191] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 22 Nov 2011 12:39:12 +0100 Message-ID: <4ECB89DF.1020803@ericsson.com> Date: Tue, 22 Nov 2011 12:39:11 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Paul Kyzivat References: <4E8E3299.6030407@alum.mit.edu> In-Reply-To: <4E8E3299.6030407@alum.mit.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 11:39:14 -0000 Hi Paul, I noticed that we never discussed this issue in depth. Allow me to come back to it. I believe the general principle is that a nickname gets associated to a SIP AOR, establishing a one-to-one relationship between them. Therefore, if a user joins the conference under the same SIP AOR, he should be only allowed to use the same nickname that has been already associated from other devices. In any other case, an error should be generated. Do you agree? /Miguel On 07/10/2011 0:58, Paul Kyzivat wrote: > Somehow I missed the WGLC of draft-ietf-simple-chat-10 until I came > across the post-WGLC review request sent to MMUSIC. As I was looking > through it I came across a possible issue that isn't related to SDP > usage. Maybe its too late to do anything about it, and maybe nothing > needs to be done about it, but I'll mention it anyway: > > Section 7, in multiple places, requires that nicknames be unambiguous. > The most specific is: > > The reservation of a nickname can fail, e.g. if the NICKNAME request > contains a malformed or non-existent Use-Nickname header field, or if > the same nickname has already been reserved by another participant in > the conference. > > Elsewhere in the document the possibility is raised that the same user > may connect to the chat from multiple devices, and that private messages > addressed to the user would then be delivered to all those devices. > > So, in such a case, can each of the devices request the same nickname? > Or must they each request a distinct nickname? It seems like it would be > desirable to permit them all to use the same nickname. Its unclear to me > whether the draft intends to permit this. > > Sorry to be so tardy, > Paul > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From pkyzivat@alum.mit.edu Wed Nov 23 10:02:15 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B3811E80B2 for ; Wed, 23 Nov 2011 10:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nY7kJUn3DDS3 for ; Wed, 23 Nov 2011 10:02:15 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2215411E80A5 for ; Wed, 23 Nov 2011 10:02:14 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id 0hhh1i0041ei1Bg53i2Fwy; Wed, 23 Nov 2011 18:02:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta24.westchester.pa.mail.comcast.net with comcast id 0i2F1i00V07duvL3ki2FJd; Wed, 23 Nov 2011 18:02:15 +0000 Message-ID: <4ECD3529.60204@alum.mit.edu> Date: Thu, 24 Nov 2011 02:02:17 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> In-Reply-To: <4ECB89DF.1020803@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 18:02:16 -0000 On 11/22/11 7:39 PM, Miguel A. Garcia wrote: > Hi Paul, > > I noticed that we never discussed this issue in depth. Allow me to come > back to it. > > I believe the general principle is that a nickname gets associated to a > SIP AOR, establishing a one-to-one relationship between them. Therefore, > if a user joins the conference under the same SIP AOR, he should be only > allowed to use the same nickname that has been already associated from > other devices. In any other case, an error should be generated. > > Do you agree? Conceptually that works for me. But I'm confused by the mechanics. Isn't the request for a nickname is made in the context of an MSRP session? And isn't it assumed that it will go away when the session is terminated, unless the nickname was prereserved via some unspecified means? If so, how is this intended to work if multiple MSRP sessions are established using the same AOR? Is it that each should request the nickname? Or only the first? If session X requests the nickname, and then session Y is established but does not request the nickname, can it still use the nickname? Then, if session X is terminated, is the nickname still active for session Y? If session X requests nickname NX, and session Y then requests nickname NY, does NY then become the nickname for both X and Y? I can see several ways this *could* work: - the nickname is bound to an AOR. Once assigned, it applies to all sessions from that AOR. If assigned by the nickname request (rather than being preassigned) it would go away when there are no sessions for that AOR. - the nickname is bound to one AOR and one or more sessions. It is bound to both by the nickname request. Multiple sessions can bind the same nickname to one AOR. Once assigned it applies only to the sessions that bound it. If assigned by the nickname request it will be unbound from a session when the session ends, and from the AOR when there are no sessions binding that nickname. (Two sessions with the same AOR could have the same nickname, different nicknames, or no nicknames.) - the nickname is bound only to a session, not to an AOR. The nicknames for sessions must all be unique. Maybe there are more, but those are the ones that come to me. Take your pick. But right now the draft really doesn't say how it works. Thanks, Paul > /Miguel > > On 07/10/2011 0:58, Paul Kyzivat wrote: >> Somehow I missed the WGLC of draft-ietf-simple-chat-10 until I came >> across the post-WGLC review request sent to MMUSIC. As I was looking >> through it I came across a possible issue that isn't related to SDP >> usage. Maybe its too late to do anything about it, and maybe nothing >> needs to be done about it, but I'll mention it anyway: >> >> Section 7, in multiple places, requires that nicknames be unambiguous. >> The most specific is: >> >> The reservation of a nickname can fail, e.g. if the NICKNAME request >> contains a malformed or non-existent Use-Nickname header field, or if >> the same nickname has already been reserved by another participant in >> the conference. >> >> Elsewhere in the document the possibility is raised that the same user >> may connect to the chat from multiple devices, and that private messages >> addressed to the user would then be delivered to all those devices. >> >> So, in such a case, can each of the devices request the same nickname? >> Or must they each request a distinct nickname? It seems like it would be >> desirable to permit them all to use the same nickname. Its unclear to me >> whether the draft intends to permit this. >> >> Sorry to be so tardy, >> Paul >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> > From ben@nostrum.com Wed Nov 23 10:42:34 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6133211E80A5 for ; Wed, 23 Nov 2011 10:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.326 X-Spam-Level: X-Spam-Status: No, score=-102.326 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNFoIDlNItgK for ; Wed, 23 Nov 2011 10:42:33 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CAFBE11E80B1 for ; Wed, 23 Nov 2011 10:42:33 -0800 (PST) Received: from dn3-53.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pANIgB7t067572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Nov 2011 12:42:12 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4ECD3529.60204@alum.mit.edu> Date: Wed, 23 Nov 2011 12:42:14 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> <4ECD3529.60204@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 18:42:34 -0000 (as individual) On Nov 23, 2011, at 12:02 PM, Paul Kyzivat wrote: > On 11/22/11 7:39 PM, Miguel A. Garcia wrote: >> Hi Paul, >>=20 >> I noticed that we never discussed this issue in depth. Allow me to = come >> back to it. >>=20 >> I believe the general principle is that a nickname gets associated to = a >> SIP AOR, establishing a one-to-one relationship between them. = Therefore, >> if a user joins the conference under the same SIP AOR, he should be = only >> allowed to use the same nickname that has been already associated = from >> other devices. In any other case, an error should be generated. >>=20 >> Do you agree? >=20 > Conceptually that works for me. But I'm confused by the mechanics. > Isn't the request for a nickname is made in the context of an MSRP = session? And isn't it assumed that it will go away when the session is = terminated, unless the nickname was prereserved via some unspecified = means? >=20 > If so, how is this intended to work if multiple MSRP sessions are = established using the same AOR? Is it that each should request the = nickname? Or only the first? If session X requests the nickname, and = then session Y is established but does not request the nickname, can it = still use the nickname? Then, if session X is terminated, is the = nickname still active for session Y? If session X requests nickname NX, = and session Y then requests nickname NY, does NY then become the = nickname for both X and Y? >=20 > I can see several ways this *could* work: > - the nickname is bound to an AOR. Once assigned, it applies to > all sessions from that AOR. If assigned by the nickname request > (rather than being preassigned) it would go away when there are > no sessions for that AOR. >=20 > - the nickname is bound to one AOR and one or more sessions. > It is bound to both by the nickname request. Multiple sessions > can bind the same nickname to one AOR. Once assigned it applies > only to the sessions that bound it. If assigned by the nickname > request it will be unbound from a session when the session ends, > and from the AOR when there are no sessions binding that nickname. > (Two sessions with the same AOR could have the same nickname, > different nicknames, or no nicknames.) >=20 > - the nickname is bound only to a session, not to an AOR. > The nicknames for sessions must all be unique. I think this is the right answer, but I think it's really "bound to an = AoR in the scope of a session". It seems like any scoping of nicknames = beyond a specific session should be a matter of local policy. Is there = anything that stops an implementation from binding a nickname across = multiple simultaneous sessions or even multiple sequential sessions if = it wants to? >=20 > Maybe there are more, but those are the ones that come to me. > Take your pick. But right now the draft really doesn't say how it = works. >=20 > Thanks, > Paul >=20 >> /Miguel >>=20 From ben@nostrum.com Wed Nov 23 11:18:38 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E48B11E80AC for ; Wed, 23 Nov 2011 11:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtI39oYdrZoe for ; Wed, 23 Nov 2011 11:18:37 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AB13911E8090 for ; Wed, 23 Nov 2011 11:18:37 -0800 (PST) Received: from dn3-53.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pANJHh0v072819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 23 Nov 2011 13:18:36 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 23 Nov 2011 13:18:37 -0600 Message-Id: <224F77C8-C598-479D-9684-2FD44D8FDE45@nostrum.com> To: Simple WG Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Simple] Test--please ignore X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 19:18:38 -0000 Nothing to see here, please move along From miguel.a.garcia@ericsson.com Thu Nov 24 01:45:08 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D76021F8BF3 for ; Thu, 24 Nov 2011 01:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.418 X-Spam-Level: X-Spam-Status: No, score=-6.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WPNU3SNXUdo for ; Thu, 24 Nov 2011 01:45:07 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 56B2921F89BA for ; Thu, 24 Nov 2011 01:45:07 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-0b-4ece1222697e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 7A.8D.09514.2221ECE4; Thu, 24 Nov 2011 10:45:06 +0100 (CET) Received: from [159.107.24.181] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 24 Nov 2011 10:45:04 +0100 Message-ID: <4ECE121F.6070908@ericsson.com> Date: Thu, 24 Nov 2011 10:45:03 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Ben Campbell References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> <4ECD3529.60204@alum.mit.edu> <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> In-Reply-To: <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Simple WG , Paul Kyzivat Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 09:45:08 -0000 On 23/11/2011 19:42, Ben Campbell wrote: >> - the nickname is bound only to a session, not to an AOR. >> The nicknames for sessions must all be unique. > > I think this is the right answer, but I think it's really "bound to an AoR in the scope of a session". It seems like any scoping of nicknames beyond a specific session should be a matter of local policy. Is there anything that stops an implementation from binding a nickname across multiple simultaneous sessions or even multiple sequential sessions if it wants to? > I wouldn't like to see this option as the only one. I would like to join the conference with the same AOR from different devices and use the same nickname. Basically, I would like to hide the fact that I am using several devices to join the chat, and be known with a single nickname across all devices. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ben@nostrum.com Thu Nov 24 05:39:08 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B4621F8B75 for ; Thu, 24 Nov 2011 05:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Sct3J1C6ao7 for ; Thu, 24 Nov 2011 05:39:08 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACC621F8B6F for ; Thu, 24 Nov 2011 05:39:08 -0800 (PST) Received: from [10.0.1.19] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pAODd3vc037940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Nov 2011 07:39:03 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: <4ECE121F.6070908@ericsson.com> Date: Thu, 24 Nov 2011 07:39:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <522D1E1F-9A8F-4392-94E4-FBB73CB38190@nostrum.com> References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> <4ECD3529.60204@alum.mit.edu> <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> <4ECE121F.6070908@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: Simple WG , Paul Kyzivat Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 13:39:08 -0000 On Nov 24, 2011, at 3:45 AM, Miguel A. Garcia wrote: > On 23/11/2011 19:42, Ben Campbell wrote: >>> - the nickname is bound only to a session, not to an AOR. >>> The nicknames for sessions must all be unique. >>=20 >> I think this is the right answer, but I think it's really "bound to = an AoR in the scope of a session". It seems like any scoping of = nicknames beyond a specific session should be a matter of local policy. = Is there anything that stops an implementation from binding a nickname = across multiple simultaneous sessions or even multiple sequential = sessions if it wants to? >>=20 >=20 > I wouldn't like to see this option as the only one. I would like to = join the conference with the same AOR from different devices and use the = same nickname. Basically, I would like to hide the fact that I am using = several devices to join the chat, and be known with a single nickname = across all devices. Sure, but isn't that still a local policy choice on how an = implementation handles the same nicknames across multiple MSRP sessions? >=20 > /Miguel > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain From ben@nostrum.com Thu Nov 24 05:44:02 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F2321F8C1C for ; Thu, 24 Nov 2011 05:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJewcBm+6Aiq for ; Thu, 24 Nov 2011 05:44:01 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 931F021F8C20 for ; Thu, 24 Nov 2011 05:43:56 -0800 (PST) Received: from [10.0.1.19] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pAODhqIr038635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Nov 2011 07:43:53 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: <522D1E1F-9A8F-4392-94E4-FBB73CB38190@nostrum.com> Date: Thu, 24 Nov 2011 07:43:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> <4ECD3529.60204@alum.mit.edu> <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> <4ECE121F.6070908@ericsson.com> <522D1E1F-9A8F-4392-94E4-FBB73CB38190@nostrum.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: Simple WG , Paul Kyzivat Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 13:44:02 -0000 On Nov 24, 2011, at 7:39 AM, Ben Campbell wrote: >=20 > On Nov 24, 2011, at 3:45 AM, Miguel A. Garcia wrote: >=20 >> On 23/11/2011 19:42, Ben Campbell wrote: >>>> - the nickname is bound only to a session, not to an AOR. >>>> The nicknames for sessions must all be unique. >>>=20 >>> I think this is the right answer, but I think it's really "bound to = an AoR in the scope of a session". It seems like any scoping of = nicknames beyond a specific session should be a matter of local policy. = Is there anything that stops an implementation from binding a nickname = across multiple simultaneous sessions or even multiple sequential = sessions if it wants to? >>>=20 >>=20 >> I wouldn't like to see this option as the only one. I would like to = join the conference with the same AOR from different devices and use the = same nickname. Basically, I would like to hide the fact that I am using = several devices to join the chat, and be known with a single nickname = across all devices. >=20 > Sure, but isn't that still a local policy choice on how an = implementation handles the same nicknames across multiple MSRP sessions? To elaborate: Would it make sense to say something the effect that a = nick is bound to an AoR for the scope of the MSRP session. A conference = server MAY, as a matter of local policy, bind the nick at a higher = scope. For example=85 [list a few use cases] Or do you think the other use cases need to be standardized? This is = more of a user experience question than an interop question, as long as = we have a way of telling a client it can't use a particular nickname. >=20 >>=20 >> /Miguel >> --=20 >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >=20 From pkyzivat@alum.mit.edu Mon Nov 28 11:47:53 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424AF1F0C6F for ; Mon, 28 Nov 2011 11:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Zz-l5QUMx34 for ; Mon, 28 Nov 2011 11:47:52 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 31EC41F0C6A for ; Mon, 28 Nov 2011 11:47:51 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta04.westchester.pa.mail.comcast.net with comcast id 2fyZ1i0081YDfWL54jnsLV; Mon, 28 Nov 2011 19:47:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id 2jnr1i00N07duvL3gjnrME; Mon, 28 Nov 2011 19:47:51 +0000 Message-ID: <4ED3E567.40104@alum.mit.edu> Date: Tue, 29 Nov 2011 03:47:51 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Ben Campbell References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> <4ECD3529.60204@alum.mit.edu> <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> <4ECE121F.6070908@ericsson.com> <522D1E1F-9A8F-4392-94E4-FBB73CB38190@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Simple WG Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 19:47:53 -0000 On 11/24/11 9:43 PM, Ben Campbell wrote: > > On Nov 24, 2011, at 7:39 AM, Ben Campbell wrote: > >> >> On Nov 24, 2011, at 3:45 AM, Miguel A. Garcia wrote: >> >>> On 23/11/2011 19:42, Ben Campbell wrote: >>>>> - the nickname is bound only to a session, not to an AOR. >>>>> The nicknames for sessions must all be unique. >>>> >>>> I think this is the right answer, but I think it's really "bound to an AoR in the scope of a session". It seems like any scoping of nicknames beyond a specific session should be a matter of local policy. Is there anything that stops an implementation from binding a nickname across multiple simultaneous sessions or even multiple sequential sessions if it wants to? >>>> >>> >>> I wouldn't like to see this option as the only one. I would like to join the conference with the same AOR from different devices and use the same nickname. Basically, I would like to hide the fact that I am using several devices to join the chat, and be known with a single nickname across all devices. >> >> Sure, but isn't that still a local policy choice on how an implementation handles the same nicknames across multiple MSRP sessions? > > To elaborate: Would it make sense to say something the effect that a nick is bound to an AoR for the scope of the MSRP session. A conference server MAY, as a matter of local policy, bind the nick at a higher scope. For example… [list a few use cases] > > Or do you think the other use cases need to be standardized? This is more of a user experience question than an interop question, as long as we have a way of telling a client it can't use a particular nickname. I think there can be room for policy differences here, if people feel that to be important. But then the usage mechanisms should be clear so that a UA can understand what it is getting. I can see binding the nickname to an AOR for some duration, thus guaranteeing that some other AOR can't use it. But there should then be some determinism as to whether such a binding is then automatically applied to each session from that AOR, or if it must be requested by each session that wants it. And if the nickname can be used with more than one session of the same AOR, then the lifetime of the binding needs to be specified - is it till the last session using it terminates? Or till the conference terminates? This will impact end user behavior: must the user specify the nickname independently on each of his devices? And, *may* the user use a different nickname from each of his devices even though the AOR is the same? Thanks, Paul From ben@nostrum.com Mon Nov 28 12:18:22 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A5D11E80D7 for ; Mon, 28 Nov 2011 12:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qE17Zj31Zfsh for ; Mon, 28 Nov 2011 12:18:21 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CD6DC11E808E for ; Mon, 28 Nov 2011 12:18:20 -0800 (PST) Received: from dn3-53.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pASKIFEH052537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Nov 2011 14:18:16 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: <4ED3E567.40104@alum.mit.edu> Date: Mon, 28 Nov 2011 14:18:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <99FCDF92-4AED-41DA-8353-A03861774D8A@nostrum.com> References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> <4ECD3529.60204@alum.mit.edu> <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> <4ECE121F.6070908@ericsson.com> <522D1E1F-9A8F-4392-94E4-FBB73CB38190@nostrum.com> <4ED3E567.40104@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 20:18:22 -0000 On Nov 28, 2011, at 1:47 PM, Paul Kyzivat wrote: > On 11/24/11 9:43 PM, Ben Campbell wrote: >>=20 >> On Nov 24, 2011, at 7:39 AM, Ben Campbell wrote: >>=20 >>>=20 >>> On Nov 24, 2011, at 3:45 AM, Miguel A. Garcia wrote: >>>=20 >>>> On 23/11/2011 19:42, Ben Campbell wrote: >>>>>> - the nickname is bound only to a session, not to an AOR. >>>>>> The nicknames for sessions must all be unique. >>>>>=20 >>>>> I think this is the right answer, but I think it's really "bound = to an AoR in the scope of a session". It seems like any scoping of = nicknames beyond a specific session should be a matter of local policy. = Is there anything that stops an implementation from binding a nickname = across multiple simultaneous sessions or even multiple sequential = sessions if it wants to? >>>>>=20 >>>>=20 >>>> I wouldn't like to see this option as the only one. I would like to = join the conference with the same AOR from different devices and use the = same nickname. Basically, I would like to hide the fact that I am using = several devices to join the chat, and be known with a single nickname = across all devices. >>>=20 >>> Sure, but isn't that still a local policy choice on how an = implementation handles the same nicknames across multiple MSRP sessions? >>=20 >> To elaborate: Would it make sense to say something the effect that a = nick is bound to an AoR for the scope of the MSRP session. A conference = server MAY, as a matter of local policy, bind the nick at a higher = scope. For example=85 [list a few use cases] >>=20 >> Or do you think the other use cases need to be standardized? This is = more of a user experience question than an interop question, as long as = we have a way of telling a client it can't use a particular nickname. >=20 > I think there can be room for policy differences here, if people feel = that to be important. But then the usage mechanisms should be clear so = that a UA can understand what it is getting. >=20 > I can see binding the nickname to an AOR for some duration, thus = guaranteeing that some other AOR can't use it. >=20 > But there should then be some determinism as to whether such a binding = is then automatically applied to each session from that AOR, or if it = must be requested by each session that wants it. >=20 > And if the nickname can be used with more than one session of the same = AOR, then the lifetime of the binding needs to be specified - is it till = the last session using it terminates? Or till the conference terminates? >=20 > This will impact end user behavior: must the user specify the nickname = independently on each of his devices? And, *may* the user use a = different nickname from each of his devices even though the AOR is the = same? Ah, I think I see where you are going.=20 My knee jerk reaction is that the client should have to re-request the = nickname for each MSRP session. It would be dangerous for a conference = server to simply assume that a second session from the same AoR should = have the same nickname. My thoughts were more along the line of if a = client was _allowed_ to use the same nickname in more than one MSRP = session. It seems like that a conference server SHOULD NOT (or maybe MUST NOT) = assume the same nickname applies for more than one session from the same = AoR, but MAY allow it. Allowing a nickname means accepting a nickname = request, but never means assuming a nickname for a session when none was = explicitly requested on that session.=20 The policy question is about what a conference server allows. Or more to = the point, what it rejects. But never what it _assumes_. For example, = reject a nickname request if it is already in use for another session in = the same conference. Or, reject a nickname request if it is already in = use by a different AoR in the same conference. Or reject it if it used = by a different AoR for any active conference. Or if it was used in an = active conference in the last XXX minutes. Or something else. Ben.= From pkyzivat@alum.mit.edu Mon Nov 28 14:57:34 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D53D21F8CE5 for ; Mon, 28 Nov 2011 14:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWhggd6bnpnb for ; Mon, 28 Nov 2011 14:57:33 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5F85721F8C9B for ; Mon, 28 Nov 2011 14:57:33 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta01.westchester.pa.mail.comcast.net with comcast id 2mpd1i0031HzFnQ51mxZM9; Mon, 28 Nov 2011 22:57:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta14.westchester.pa.mail.comcast.net with comcast id 2mxZ1i00c07duvL3amxZzR; Mon, 28 Nov 2011 22:57:33 +0000 Message-ID: <4ED411DB.7040604@alum.mit.edu> Date: Tue, 29 Nov 2011 06:57:31 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: simple@ietf.org References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> <4ECD3529.60204@alum.mit.edu> <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> <4ECE121F.6070908@ericsson.com> <522D1E1F-9A8F-4392-94E4-FBB73CB38190@nostrum.com> <4ED3E567.40104@alum.mit.edu> <99FCDF92-4AED-41DA-8353-A03861774D8A@nostrum.com> In-Reply-To: <99FCDF92-4AED-41DA-8353-A03861774D8A@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 22:57:34 -0000 On 11/29/11 4:18 AM, Ben Campbell wrote: > > On Nov 28, 2011, at 1:47 PM, Paul Kyzivat wrote: > >> On 11/24/11 9:43 PM, Ben Campbell wrote: >>> >>> On Nov 24, 2011, at 7:39 AM, Ben Campbell wrote: >>> >>>> >>>> On Nov 24, 2011, at 3:45 AM, Miguel A. Garcia wrote: >>>> >>>>> On 23/11/2011 19:42, Ben Campbell wrote: >>>>>>> - the nickname is bound only to a session, not to an AOR. >>>>>>> The nicknames for sessions must all be unique. >>>>>> >>>>>> I think this is the right answer, but I think it's really "bound to an AoR in the scope of a session". It seems like any scoping of nicknames beyond a specific session should be a matter of local policy. Is there anything that stops an implementation from binding a nickname across multiple simultaneous sessions or even multiple sequential sessions if it wants to? >>>>>> >>>>> >>>>> I wouldn't like to see this option as the only one. I would like to join the conference with the same AOR from different devices and use the same nickname. Basically, I would like to hide the fact that I am using several devices to join the chat, and be known with a single nickname across all devices. >>>> >>>> Sure, but isn't that still a local policy choice on how an implementation handles the same nicknames across multiple MSRP sessions? >>> >>> To elaborate: Would it make sense to say something the effect that a nick is bound to an AoR for the scope of the MSRP session. A conference server MAY, as a matter of local policy, bind the nick at a higher scope. For example… [list a few use cases] >>> >>> Or do you think the other use cases need to be standardized? This is more of a user experience question than an interop question, as long as we have a way of telling a client it can't use a particular nickname. >> >> I think there can be room for policy differences here, if people feel that to be important. But then the usage mechanisms should be clear so that a UA can understand what it is getting. >> >> I can see binding the nickname to an AOR for some duration, thus guaranteeing that some other AOR can't use it. >> >> But there should then be some determinism as to whether such a binding is then automatically applied to each session from that AOR, or if it must be requested by each session that wants it. >> >> And if the nickname can be used with more than one session of the same AOR, then the lifetime of the binding needs to be specified - is it till the last session using it terminates? Or till the conference terminates? >> >> This will impact end user behavior: must the user specify the nickname independently on each of his devices? And, *may* the user use a different nickname from each of his devices even though the AOR is the same? > > Ah, I think I see where you are going. > > My knee jerk reaction is that the client should have to re-request the nickname for each MSRP session. It would be dangerous for a conference server to simply assume that a second session from the same AoR should have the same nickname. My thoughts were more along the line of if a client was _allowed_ to use the same nickname in more than one MSRP session. > > It seems like that a conference server SHOULD NOT (or maybe MUST NOT) assume the same nickname applies for more than one session from the same AoR, but MAY allow it. Allowing a nickname means accepting a nickname request, but never means assuming a nickname for a session when none was explicitly requested on that session. I almost buy that logic. But consider a server that allows *permanent* assignment of a nickname to an AOR. In that case it might make a lot of sense to apply the nickname to sessions by default. The fine line to walk here is to provide enough consistency in the protocol and its usage to give predictable behavior, while still permitting policy flexibility to the server. If multiple sessions for the same AOR can request different nicknames, then I guess all of those would be bound to the AOR. In thata case it would not make much sense for the assignment to apply to other sessions, since it would be necessary to decide *which* of them would be used. I guess it would be possible to add some option to the nickname request to designate it as the default for the AOR. (With only one at a time being permitted to be the default. Or that could be left to later, with no default for now. The important thing is to get enough semantics nailed down to provide implementers with reasonable and consistent behavior. Thanks, Paul > The policy question is about what a conference server allows. Or more to the point, what it rejects. But never what it _assumes_. For example, reject a nickname request if it is already in use for another session in the same conference. Or, reject a nickname request if it is already in use by a different AoR in the same conference. Or reject it if it used by a different AoR for any active conference. Or if it was used in an active conference in the last XXX minutes. Or something else. > > > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From ben@nostrum.com Mon Nov 28 15:16:21 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC4C1F0C55 for ; Mon, 28 Nov 2011 15:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCIdlQnhQ4yf for ; Mon, 28 Nov 2011 15:16:21 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CB7F41F0C4A for ; Mon, 28 Nov 2011 15:16:20 -0800 (PST) Received: from dn3-53.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pASNGIGH079117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Nov 2011 17:16:19 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: <4ED411DB.7040604@alum.mit.edu> Date: Mon, 28 Nov 2011 17:16:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <930392AA-4A56-4FB1-B157-C30AED841913@nostrum.com> References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> <4ECD3529.60204@alum.mit.edu> <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> <4ECE121F.6070908@ericsson.com> <522D1E1F-9A8F-4392-94E4-FBB73CB38190@nostrum.com> <4ED3E567.40104@alum.mit.edu> <99FCDF92-4AED-41DA-8353-A03861774D8A@nostrum.com> <4ED411DB.7040604@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: simple@ietf.org Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 23:16:21 -0000 On Nov 28, 2011, at 4:57 PM, Paul Kyzivat wrote: > On 11/29/11 4:18 AM, Ben Campbell wrote: >>=20 >> On Nov 28, 2011, at 1:47 PM, Paul Kyzivat wrote: >>=20 >>>=20 [=85] >>> I think there can be room for policy differences here, if people = feel that to be important. But then the usage mechanisms should be clear = so that a UA can understand what it is getting. >>>=20 >>> I can see binding the nickname to an AOR for some duration, thus = guaranteeing that some other AOR can't use it. >>>=20 >>> But there should then be some determinism as to whether such a = binding is then automatically applied to each session from that AOR, or = if it must be requested by each session that wants it. >>>=20 >>> And if the nickname can be used with more than one session of the = same AOR, then the lifetime of the binding needs to be specified - is it = till the last session using it terminates? Or till the conference = terminates? >>>=20 >>> This will impact end user behavior: must the user specify the = nickname independently on each of his devices? And, *may* the user use a = different nickname from each of his devices even though the AOR is the = same? >>=20 >> Ah, I think I see where you are going. >>=20 >> My knee jerk reaction is that the client should have to re-request = the nickname for each MSRP session. It would be dangerous for a = conference server to simply assume that a second session from the same = AoR should have the same nickname. My thoughts were more along the line = of if a client was _allowed_ to use the same nickname in more than one = MSRP session. >>=20 >> It seems like that a conference server SHOULD NOT (or maybe MUST NOT) = assume the same nickname applies for more than one session from the same = AoR, but MAY allow it. Allowing a nickname means accepting a nickname = request, but never means assuming a nickname for a session when none was = explicitly requested on that session. >=20 > I almost buy that logic. But consider a server that allows *permanent* = assignment of a nickname to an AOR. In that case it might make a lot of = sense to apply the nickname to sessions by default. Is it a permanent _assignment_ or a permanent _reservation_? That is, = does this mean that all the sessions for an AoR will automatically get = the nickname, or that sessions for some other AoR _can't_ get the = nickname? >=20 > The fine line to walk here is to provide enough consistency in the = protocol and its usage to give predictable behavior, while still = permitting policy flexibility to the server. I agree. And it seems to me that the approach of never assigning a = nickname unless explicitly requested in the session gives the most = predictable for any remaining policy choice--and avoids the potential = for embarrassment when I suddenly realize the hard way that my = drinking-buddy chat room is hosted on the same service as my church = chatroom. That is, I'm afraid any automatic or default assignments have = the potential to be a privacy problem. >=20 > If multiple sessions for the same AOR can request different nicknames, = then I guess all of those would be bound to the AOR. In thata case it = would not make much sense for the assignment to apply to other sessions, = since it would be necessary to decide *which* of them would be used. My argument above is that it is, in a generic sense, _dangerous_ to = assume an assignment in any one session gets applied to any other = session. >=20 > I guess it would be possible to add some option to the nickname = request to designate it as the default for the AOR. (With only one at a = time being permitted to be the default. Or that could be left to later, = with no default for now. How expensive is one nickname transaction per session really going to = be? What problem is solved by default nicknames? Is it a question of not = having to remember my nickname across multiple clients? >=20 > The important thing is to get enough semantics nailed down to provide = implementers with reasonable and consistent behavior. I totally agree, and thank you for making me realize this was a more = complex issue than I originally thought :-) >=20 > Thanks, > Paul >=20 >> The policy question is about what a conference server allows. Or more = to the point, what it rejects. But never what it _assumes_. For example, = reject a nickname request if it is already in use for another session in = the same conference. Or, reject a nickname request if it is already in = use by a different AoR in the same conference. Or reject it if it used = by a different AoR for any active conference. Or if it was used in an = active conference in the last XXX minutes. Or something else. >>=20 >>=20 >> Ben. >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From pkyzivat@alum.mit.edu Tue Nov 29 17:29:35 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA1821F85FF for ; Tue, 29 Nov 2011 17:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 060yxHAT5YeW for ; Tue, 29 Nov 2011 17:29:34 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 72B6D21F85CE for ; Tue, 29 Nov 2011 17:29:33 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta05.westchester.pa.mail.comcast.net with comcast id 3DBn1i0011c6gX855DVZVX; Wed, 30 Nov 2011 01:29:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id 3DVY1i00n07duvL3jDVY9G; Wed, 30 Nov 2011 01:29:33 +0000 Message-ID: <4ED586FB.6090409@alum.mit.edu> Date: Wed, 30 Nov 2011 09:29:31 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: simple@ietf.org References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> <4ECD3529.60204@alum.mit.edu> <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> <4ECE121F.6070908@ericsson.com> <522D1E1F-9A8F-4392-94E4-FBB73CB38190@nostrum.com> <4ED3E567.40104@alum.mit.edu> <99FCDF92-4AED-41DA-8353-A03861774D8A@nostrum.com> <4ED411DB.7040604@alum.mit.edu> <930392AA-4A56-4FB1-B157-C30AED841913@nostrum.com> In-Reply-To: <930392AA-4A56-4FB1-B157-C30AED841913@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 01:29:35 -0000 Ben, I'm ok with everything you say. But if there are multiple endpoints using the same AOR, that want to use the same nickname, then there is the issue of how they all discover what nickname to use. If there were a way to discover the nicknames that have been reserved for the AOR, and there happened to be only one, then each endpoint could perhaps automatically request that one. Alternately, we could imagine that the server could be configured with a policy to not only reserve a nickname for an AOR, but also to automatically request it for each UA that establishes a session with the AOR. Either of those approaches requires a little bit of protocol support to enable the behavior and clue the UA in that it has happened. Thanks, Paul On 11/29/11 7:16 AM, Ben Campbell wrote: > > On Nov 28, 2011, at 4:57 PM, Paul Kyzivat wrote: > >> On 11/29/11 4:18 AM, Ben Campbell wrote: >>> >>> On Nov 28, 2011, at 1:47 PM, Paul Kyzivat wrote: >>> >>>> > > […] > >>>> I think there can be room for policy differences here, if people feel that to be important. But then the usage mechanisms should be clear so that a UA can understand what it is getting. >>>> >>>> I can see binding the nickname to an AOR for some duration, thus guaranteeing that some other AOR can't use it. >>>> >>>> But there should then be some determinism as to whether such a binding is then automatically applied to each session from that AOR, or if it must be requested by each session that wants it. >>>> >>>> And if the nickname can be used with more than one session of the same AOR, then the lifetime of the binding needs to be specified - is it till the last session using it terminates? Or till the conference terminates? >>>> >>>> This will impact end user behavior: must the user specify the nickname independently on each of his devices? And, *may* the user use a different nickname from each of his devices even though the AOR is the same? >>> >>> Ah, I think I see where you are going. >>> >>> My knee jerk reaction is that the client should have to re-request the nickname for each MSRP session. It would be dangerous for a conference server to simply assume that a second session from the same AoR should have the same nickname. My thoughts were more along the line of if a client was _allowed_ to use the same nickname in more than one MSRP session. >>> >>> It seems like that a conference server SHOULD NOT (or maybe MUST NOT) assume the same nickname applies for more than one session from the same AoR, but MAY allow it. Allowing a nickname means accepting a nickname request, but never means assuming a nickname for a session when none was explicitly requested on that session. >> >> I almost buy that logic. But consider a server that allows *permanent* assignment of a nickname to an AOR. In that case it might make a lot of sense to apply the nickname to sessions by default. > > Is it a permanent _assignment_ or a permanent _reservation_? That is, does this mean that all the sessions for an AoR will automatically get the nickname, or that sessions for some other AoR _can't_ get the nickname? > >> >> The fine line to walk here is to provide enough consistency in the protocol and its usage to give predictable behavior, while still permitting policy flexibility to the server. > > I agree. And it seems to me that the approach of never assigning a nickname unless explicitly requested in the session gives the most predictable for any remaining policy choice--and avoids the potential for embarrassment when I suddenly realize the hard way that my drinking-buddy chat room is hosted on the same service as my church chatroom. That is, I'm afraid any automatic or default assignments have the potential to be a privacy problem. > > >> >> If multiple sessions for the same AOR can request different nicknames, then I guess all of those would be bound to the AOR. In thata case it would not make much sense for the assignment to apply to other sessions, since it would be necessary to decide *which* of them would be used. > > My argument above is that it is, in a generic sense, _dangerous_ to assume an assignment in any one session gets applied to any other session. > >> >> I guess it would be possible to add some option to the nickname request to designate it as the default for the AOR. (With only one at a time being permitted to be the default. Or that could be left to later, with no default for now. > > How expensive is one nickname transaction per session really going to be? What problem is solved by default nicknames? Is it a question of not having to remember my nickname across multiple clients? > >> >> The important thing is to get enough semantics nailed down to provide implementers with reasonable and consistent behavior. > > I totally agree, and thank you for making me realize this was a more complex issue than I originally thought :-) > >> >> Thanks, >> Paul >> >>> The policy question is about what a conference server allows. Or more to the point, what it rejects. But never what it _assumes_. For example, reject a nickname request if it is already in use for another session in the same conference. Or, reject a nickname request if it is already in use by a different AoR in the same conference. Or reject it if it used by a different AoR for any active conference. Or if it was used in an active conference in the last XXX minutes. Or something else. >>> >>> >>> Ben. >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From ben@nostrum.com Tue Nov 29 21:03:45 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E57F21F88B7 for ; Tue, 29 Nov 2011 21:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lv+wnwtc2yob for ; Tue, 29 Nov 2011 21:03:44 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDCC21F85AE for ; Tue, 29 Nov 2011 21:03:44 -0800 (PST) Received: from [10.0.1.19] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pAU53fjo047889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 Nov 2011 23:03:41 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: <4ED586FB.6090409@alum.mit.edu> Date: Tue, 29 Nov 2011 23:03:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3B22625C-BABD-4C51-B389-6D507F0A079D@nostrum.com> References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> <4ECD3529.60204@alum.mit.edu> <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> <4ECE121F.6070908@ericsson.com> <522D1E1F-9A8F-4392-94E4-FBB73CB38190@nostrum.com> <4ED3E567.40104@alum.mit.edu> <99FCDF92-4AED-41DA-8353-A03861774D8A@nostrum.com> <4ED411DB.7040604@alum.mit.edu> <930392AA-4A56-4FB1-B157-C30AED841913@nostrum.com> <4ED586FB.6090409@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: simple@ietf.org Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 05:03:45 -0000 (still as individual) On Nov 29, 2011, at 7:29 PM, Paul Kyzivat wrote: > Ben, >=20 > I'm ok with everything you say. But if there are multiple endpoints = using the same AOR, that want to use the same nickname, then there is = the issue of how they all discover what nickname to use. Their human tells them? :-) (Yeah, I know=85) >=20 > If there were a way to discover the nicknames that have been reserved = for the AOR, and there happened to be only one, then each endpoint could = perhaps automatically request that one. That's an interesting problem. I can see maybe having the nickname = method return a list of available nicknames, if applicable. And maybe a = "selected" one. But that's adding a lot of mechanism late in this = effort. Any chance we can just mention it as an "out of scope" issue, = and if anyone cares enough about a nickname sync extension to work on = it, that can be a separate effort? >=20 > Alternately, we could imagine that the server could be configured with = a policy to not only reserve a nickname for an AOR, but also to = automatically request it for each UA that establishes a session with the = AOR. My concern here is that nickname usage policies could be arbitrarily = complex. >=20 > Either of those approaches requires a little bit of protocol support = to enable the behavior and clue the UA in that it has happened. >=20 > Thanks, > Paul >=20 > On 11/29/11 7:16 AM, Ben Campbell wrote: >>=20 >> On Nov 28, 2011, at 4:57 PM, Paul Kyzivat wrote: >>=20 >>> On 11/29/11 4:18 AM, Ben Campbell wrote: >>>>=20 >>>> On Nov 28, 2011, at 1:47 PM, Paul Kyzivat wrote: >>>>=20 >>>>>=20 >>=20 >> [=85] >>=20 >>>>> I think there can be room for policy differences here, if people = feel that to be important. But then the usage mechanisms should be clear = so that a UA can understand what it is getting. >>>>>=20 >>>>> I can see binding the nickname to an AOR for some duration, thus = guaranteeing that some other AOR can't use it. >>>>>=20 >>>>> But there should then be some determinism as to whether such a = binding is then automatically applied to each session from that AOR, or = if it must be requested by each session that wants it. >>>>>=20 >>>>> And if the nickname can be used with more than one session of the = same AOR, then the lifetime of the binding needs to be specified - is it = till the last session using it terminates? Or till the conference = terminates? >>>>>=20 >>>>> This will impact end user behavior: must the user specify the = nickname independently on each of his devices? And, *may* the user use a = different nickname from each of his devices even though the AOR is the = same? >>>>=20 >>>> Ah, I think I see where you are going. >>>>=20 >>>> My knee jerk reaction is that the client should have to re-request = the nickname for each MSRP session. It would be dangerous for a = conference server to simply assume that a second session from the same = AoR should have the same nickname. My thoughts were more along the line = of if a client was _allowed_ to use the same nickname in more than one = MSRP session. >>>>=20 >>>> It seems like that a conference server SHOULD NOT (or maybe MUST = NOT) assume the same nickname applies for more than one session from the = same AoR, but MAY allow it. Allowing a nickname means accepting a = nickname request, but never means assuming a nickname for a session when = none was explicitly requested on that session. >>>=20 >>> I almost buy that logic. But consider a server that allows = *permanent* assignment of a nickname to an AOR. In that case it might = make a lot of sense to apply the nickname to sessions by default. >>=20 >> Is it a permanent _assignment_ or a permanent _reservation_? That is, = does this mean that all the sessions for an AoR will automatically get = the nickname, or that sessions for some other AoR _can't_ get the = nickname? >>=20 >>>=20 >>> The fine line to walk here is to provide enough consistency in the = protocol and its usage to give predictable behavior, while still = permitting policy flexibility to the server. >>=20 >> I agree. And it seems to me that the approach of never assigning a = nickname unless explicitly requested in the session gives the most = predictable for any remaining policy choice--and avoids the potential = for embarrassment when I suddenly realize the hard way that my = drinking-buddy chat room is hosted on the same service as my church = chatroom. That is, I'm afraid any automatic or default assignments have = the potential to be a privacy problem. >>=20 >>=20 >>>=20 >>> If multiple sessions for the same AOR can request different = nicknames, then I guess all of those would be bound to the AOR. In thata = case it would not make much sense for the assignment to apply to other = sessions, since it would be necessary to decide *which* of them would be = used. >>=20 >> My argument above is that it is, in a generic sense, _dangerous_ to = assume an assignment in any one session gets applied to any other = session. >>=20 >>>=20 >>> I guess it would be possible to add some option to the nickname = request to designate it as the default for the AOR. (With only one at a = time being permitted to be the default. Or that could be left to later, = with no default for now. >>=20 >> How expensive is one nickname transaction per session really going to = be? What problem is solved by default nicknames? Is it a question of not = having to remember my nickname across multiple clients? >>=20 >>>=20 >>> The important thing is to get enough semantics nailed down to = provide implementers with reasonable and consistent behavior. >>=20 >> I totally agree, and thank you for making me realize this was a more = complex issue than I originally thought :-) >>=20 >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> The policy question is about what a conference server allows. Or = more to the point, what it rejects. But never what it _assumes_. For = example, reject a nickname request if it is already in use for another = session in the same conference. Or, reject a nickname request if it is = already in use by a different AoR in the same conference. Or reject it = if it used by a different AoR for any active conference. Or if it was = used in an active conference in the last XXX minutes. Or something else. >>>>=20 >>>>=20 >>>> Ben. >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>>=20 >>>=20 >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Tue Nov 29 21:07:11 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81B11F0C44 for ; Tue, 29 Nov 2011 21:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNtxxJsMrPj2 for ; Tue, 29 Nov 2011 21:07:10 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CA1791F0C41 for ; Tue, 29 Nov 2011 21:07:09 -0800 (PST) Received: from [10.0.1.19] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pAU577oY048468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 29 Nov 2011 23:07:09 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Ben Campbell In-Reply-To: <3B22625C-BABD-4C51-B389-6D507F0A079D@nostrum.com> Date: Tue, 29 Nov 2011 23:07:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> <4ECD3529.60204@alum.mit.edu> <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> <4ECE121F.6070908@ericsson.com> <522D1E1F-9A8F-4392-94E4-FBB73CB38190@nostrum.com> <4ED3E567.40104@alum.mit.edu> <99FCDF92-4AED-41DA-8353-A03861774D8A@nostrum.com> <4ED411DB.7040604@alum.mit.edu> <930392AA-4A56-4FB1-B157-C30AED841913@nostrum.com> <4ED586FB.6090409@alum.mit.edu> <3B22625C-BABD-4C51-B389-6D507F0A079D@nostrum.com> To: Simple WG X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 05:07:11 -0000 (as chair this time) Surely Paul, Miguel, and I aren't the only ones still in this = conversation? If anyone else has thoughts or opinions, please speak up. Thanks! Ben. On Nov 29, 2011, at 11:03 PM, Ben Campbell wrote: > (still as individual) >=20 > On Nov 29, 2011, at 7:29 PM, Paul Kyzivat wrote: >=20 >> Ben, >>=20 >> I'm ok with everything you say. But if there are multiple endpoints = using the same AOR, that want to use the same nickname, then there is = the issue of how they all discover what nickname to use. >=20 > Their human tells them? :-) (Yeah, I know=85) >=20 >>=20 >> If there were a way to discover the nicknames that have been reserved = for the AOR, and there happened to be only one, then each endpoint could = perhaps automatically request that one. >=20 > That's an interesting problem. I can see maybe having the nickname = method return a list of available nicknames, if applicable. And maybe a = "selected" one. But that's adding a lot of mechanism late in this = effort. Any chance we can just mention it as an "out of scope" issue, = and if anyone cares enough about a nickname sync extension to work on = it, that can be a separate effort? >=20 >>=20 >> Alternately, we could imagine that the server could be configured = with a policy to not only reserve a nickname for an AOR, but also to = automatically request it for each UA that establishes a session with the = AOR. >=20 > My concern here is that nickname usage policies could be arbitrarily = complex. >=20 >>=20 >> Either of those approaches requires a little bit of protocol support = to enable the behavior and clue the UA in that it has happened. >>=20 >> Thanks, >> Paul >>=20 >> On 11/29/11 7:16 AM, Ben Campbell wrote: >>>=20 >>> On Nov 28, 2011, at 4:57 PM, Paul Kyzivat wrote: >>>=20 >>>> On 11/29/11 4:18 AM, Ben Campbell wrote: >>>>>=20 >>>>> On Nov 28, 2011, at 1:47 PM, Paul Kyzivat wrote: >>>>>=20 >>>>>>=20 >>>=20 >>> [=85] >>>=20 >>>>>> I think there can be room for policy differences here, if people = feel that to be important. But then the usage mechanisms should be clear = so that a UA can understand what it is getting. >>>>>>=20 >>>>>> I can see binding the nickname to an AOR for some duration, thus = guaranteeing that some other AOR can't use it. >>>>>>=20 >>>>>> But there should then be some determinism as to whether such a = binding is then automatically applied to each session from that AOR, or = if it must be requested by each session that wants it. >>>>>>=20 >>>>>> And if the nickname can be used with more than one session of the = same AOR, then the lifetime of the binding needs to be specified - is it = till the last session using it terminates? Or till the conference = terminates? >>>>>>=20 >>>>>> This will impact end user behavior: must the user specify the = nickname independently on each of his devices? And, *may* the user use a = different nickname from each of his devices even though the AOR is the = same? >>>>>=20 >>>>> Ah, I think I see where you are going. >>>>>=20 >>>>> My knee jerk reaction is that the client should have to re-request = the nickname for each MSRP session. It would be dangerous for a = conference server to simply assume that a second session from the same = AoR should have the same nickname. My thoughts were more along the line = of if a client was _allowed_ to use the same nickname in more than one = MSRP session. >>>>>=20 >>>>> It seems like that a conference server SHOULD NOT (or maybe MUST = NOT) assume the same nickname applies for more than one session from the = same AoR, but MAY allow it. Allowing a nickname means accepting a = nickname request, but never means assuming a nickname for a session when = none was explicitly requested on that session. >>>>=20 >>>> I almost buy that logic. But consider a server that allows = *permanent* assignment of a nickname to an AOR. In that case it might = make a lot of sense to apply the nickname to sessions by default. >>>=20 >>> Is it a permanent _assignment_ or a permanent _reservation_? That = is, does this mean that all the sessions for an AoR will automatically = get the nickname, or that sessions for some other AoR _can't_ get the = nickname? >>>=20 >>>>=20 >>>> The fine line to walk here is to provide enough consistency in the = protocol and its usage to give predictable behavior, while still = permitting policy flexibility to the server. >>>=20 >>> I agree. And it seems to me that the approach of never assigning a = nickname unless explicitly requested in the session gives the most = predictable for any remaining policy choice--and avoids the potential = for embarrassment when I suddenly realize the hard way that my = drinking-buddy chat room is hosted on the same service as my church = chatroom. That is, I'm afraid any automatic or default assignments have = the potential to be a privacy problem. >>>=20 >>>=20 >>>>=20 >>>> If multiple sessions for the same AOR can request different = nicknames, then I guess all of those would be bound to the AOR. In thata = case it would not make much sense for the assignment to apply to other = sessions, since it would be necessary to decide *which* of them would be = used. >>>=20 >>> My argument above is that it is, in a generic sense, _dangerous_ to = assume an assignment in any one session gets applied to any other = session. >>>=20 >>>>=20 >>>> I guess it would be possible to add some option to the nickname = request to designate it as the default for the AOR. (With only one at a = time being permitted to be the default. Or that could be left to later, = with no default for now. >>>=20 >>> How expensive is one nickname transaction per session really going = to be? What problem is solved by default nicknames? Is it a question of = not having to remember my nickname across multiple clients? >>>=20 >>>>=20 >>>> The important thing is to get enough semantics nailed down to = provide implementers with reasonable and consistent behavior. >>>=20 >>> I totally agree, and thank you for making me realize this was a more = complex issue than I originally thought :-) >>>=20 >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>>> The policy question is about what a conference server allows. Or = more to the point, what it rejects. But never what it _assumes_. For = example, reject a nickname request if it is already in use for another = session in the same conference. Or, reject a nickname request if it is = already in use by a different AoR in the same conference. Or reject it = if it used by a different AoR for any active conference. Or if it was = used in an active conference in the last XXX minutes. Or something else. >>>>>=20 >>>>>=20 >>>>> Ben. >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/simple >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 From miguel.a.garcia@ericsson.com Wed Nov 30 03:23:18 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E8021F8880 for ; Wed, 30 Nov 2011 03:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9scjnizegOth for ; Wed, 30 Nov 2011 03:23:17 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6776C21F85A1 for ; Wed, 30 Nov 2011 03:23:17 -0800 (PST) X-AuditID: c1b4fb3d-b7b5fae00000219a-52-4ed6122455a7 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 93.C4.08602.42216DE4; Wed, 30 Nov 2011 12:23:16 +0100 (CET) Received: from [159.107.24.199] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 30 Nov 2011 12:23:15 +0100 Message-ID: <4ED61221.2070405@ericsson.com> Date: Wed, 30 Nov 2011 12:23:13 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Ben Campbell References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> <4ECD3529.60204@alum.mit.edu> <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> <4ECE121F.6070908@ericsson.com> <522D1E1F-9A8F-4392-94E4-FBB73CB38190@nostrum.com> <4ED3E567.40104@alum.mit.edu> <99FCDF92-4AED-41DA-8353-A03861774D8A@nostrum.com> In-Reply-To: <99FCDF92-4AED-41DA-8353-A03861774D8A@nostrum.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Simple WG , Paul Kyzivat Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 11:23:18 -0000 Since we are converging, do you have any comments to the following text? Once the conference server has reserved a nickname and has bound it to a URI (e.g., a SIP Address-of-Record), the conference server MAY allow the usage of the same nickname by the same user (identified by the same URI, such as a SIP AoR) over a second MSRP session. This might be the case if the user joins the same conference from a different SIP UA. In this case, the user MAY request the same or a different nickname than that used in conjunction with the first MSRP session; the conference server MAY accept the usage of the same nickname by the same user. The conference server MUST NOT automatically assign the same nickname to more than one MSRP session established from the same URI, because this can create confusion to the user as whether the same nickname is bound to the second MSRP session. /Miguel On 28/11/2011 21:18, Ben Campbell wrote: > > On Nov 28, 2011, at 1:47 PM, Paul Kyzivat wrote: > >> On 11/24/11 9:43 PM, Ben Campbell wrote: >>> >>> On Nov 24, 2011, at 7:39 AM, Ben Campbell wrote: >>> >>>> >>>> On Nov 24, 2011, at 3:45 AM, Miguel A. Garcia wrote: >>>> >>>>> On 23/11/2011 19:42, Ben Campbell wrote: >>>>>>> - the nickname is bound only to a session, not to an AOR. >>>>>>> The nicknames for sessions must all be unique. >>>>>> >>>>>> I think this is the right answer, but I think it's really "bound to an AoR in the scope of a session". It seems like any scoping of nicknames beyond a specific session should be a matter of local policy. Is there anything that stops an implementation from binding a nickname across multiple simultaneous sessions or even multiple sequential sessions if it wants to? >>>>>> >>>>> >>>>> I wouldn't like to see this option as the only one. I would like to join the conference with the same AOR from different devices and use the same nickname. Basically, I would like to hide the fact that I am using several devices to join the chat, and be known with a single nickname across all devices. >>>> >>>> Sure, but isn't that still a local policy choice on how an implementation handles the same nicknames across multiple MSRP sessions? >>> >>> To elaborate: Would it make sense to say something the effect that a nick is bound to an AoR for the scope of the MSRP session. A conference server MAY, as a matter of local policy, bind the nick at a higher scope. For example… [list a few use cases] >>> >>> Or do you think the other use cases need to be standardized? This is more of a user experience question than an interop question, as long as we have a way of telling a client it can't use a particular nickname. >> >> I think there can be room for policy differences here, if people feel that to be important. But then the usage mechanisms should be clear so that a UA can understand what it is getting. >> >> I can see binding the nickname to an AOR for some duration, thus guaranteeing that some other AOR can't use it. >> >> But there should then be some determinism as to whether such a binding is then automatically applied to each session from that AOR, or if it must be requested by each session that wants it. >> >> And if the nickname can be used with more than one session of the same AOR, then the lifetime of the binding needs to be specified - is it till the last session using it terminates? Or till the conference terminates? >> >> This will impact end user behavior: must the user specify the nickname independently on each of his devices? And, *may* the user use a different nickname from each of his devices even though the AOR is the same? > > Ah, I think I see where you are going. > > My knee jerk reaction is that the client should have to re-request the nickname for each MSRP session. It would be dangerous for a conference server to simply assume that a second session from the same AoR should have the same nickname. My thoughts were more along the line of if a client was _allowed_ to use the same nickname in more than one MSRP session. > > It seems like that a conference server SHOULD NOT (or maybe MUST NOT) assume the same nickname applies for more than one session from the same AoR, but MAY allow it. Allowing a nickname means accepting a nickname request, but never means assuming a nickname for a session when none was explicitly requested on that session. > > The policy question is about what a conference server allows. Or more to the point, what it rejects. But never what it _assumes_. For example, reject a nickname request if it is already in use for another session in the same conference. Or, reject a nickname request if it is already in use by a different AoR in the same conference. Or reject it if it used by a different AoR for any active conference. Or if it was used in an active conference in the last XXX minutes. Or something else. > > > Ben. -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From pkyzivat@alum.mit.edu Wed Nov 30 14:30:55 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F11411E80D0 for ; Wed, 30 Nov 2011 14:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOK4-Ukz-KiE for ; Wed, 30 Nov 2011 14:30:54 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 829CE11E809D for ; Wed, 30 Nov 2011 14:30:54 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta04.westchester.pa.mail.comcast.net with comcast id 3aM11i0020cZkys54aWvx8; Wed, 30 Nov 2011 22:30:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta10.westchester.pa.mail.comcast.net with comcast id 3aWu1i01607duvL3WaWusY; Wed, 30 Nov 2011 22:30:54 +0000 Message-ID: <4ED6AE9C.8030108@alum.mit.edu> Date: Thu, 01 Dec 2011 06:30:52 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> <4ECD3529.60204@alum.mit.edu> <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> <4ECE121F.6070908@ericsson.com> <522D1E1F-9A8F-4392-94E4-FBB73CB38190@nostrum.com> <4ED3E567.40104@alum.mit.edu> <99FCDF92-4AED-41DA-8353-A03861774D8A@nostrum.com> <4ED61221.2070405@ericsson.com> In-Reply-To: <4ED61221.2070405@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Simple WG Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:30:55 -0000 I wouldn't object to this. Thanks, Paul On 11/30/11 7:23 PM, Miguel A. Garcia wrote: > Since we are converging, do you have any comments to the following text? > > Once the conference server has reserved a nickname and has > bound it to a URI (e.g., a SIP Address-of-Record), the > conference server MAY allow the usage of the same nickname > by the same user (identified by the same URI, such as a SIP > AoR) over a second MSRP session. This might be the case if > the user joins the same conference from a different SIP > UA. In this case, the user MAY request the same or a > different nickname than that used in conjunction with the > first MSRP session; the conference server MAY accept the > usage of the same nickname by the same user. The conference > server MUST NOT automatically assign the same nickname to > more than one MSRP session established from the same URI, > because this can create confusion to the user as whether the > same nickname is bound to the second MSRP session. > > /Miguel > > > > On 28/11/2011 21:18, Ben Campbell wrote: >> >> On Nov 28, 2011, at 1:47 PM, Paul Kyzivat wrote: >> >>> On 11/24/11 9:43 PM, Ben Campbell wrote: >>>> >>>> On Nov 24, 2011, at 7:39 AM, Ben Campbell wrote: >>>> >>>>> >>>>> On Nov 24, 2011, at 3:45 AM, Miguel A. Garcia wrote: >>>>> >>>>>> On 23/11/2011 19:42, Ben Campbell wrote: >>>>>>>> - the nickname is bound only to a session, not to an AOR. >>>>>>>> The nicknames for sessions must all be unique. >>>>>>> >>>>>>> I think this is the right answer, but I think it's really "bound >>>>>>> to an AoR in the scope of a session". It seems like any scoping >>>>>>> of nicknames beyond a specific session should be a matter of >>>>>>> local policy. Is there anything that stops an implementation from >>>>>>> binding a nickname across multiple simultaneous sessions or even >>>>>>> multiple sequential sessions if it wants to? >>>>>>> >>>>>> >>>>>> I wouldn't like to see this option as the only one. I would like >>>>>> to join the conference with the same AOR from different devices >>>>>> and use the same nickname. Basically, I would like to hide the >>>>>> fact that I am using several devices to join the chat, and be >>>>>> known with a single nickname across all devices. >>>>> >>>>> Sure, but isn't that still a local policy choice on how an >>>>> implementation handles the same nicknames across multiple MSRP >>>>> sessions? >>>> >>>> To elaborate: Would it make sense to say something the effect that a >>>> nick is bound to an AoR for the scope of the MSRP session. A >>>> conference server MAY, as a matter of local policy, bind the nick at >>>> a higher scope. For example… [list a few use cases] >>>> >>>> Or do you think the other use cases need to be standardized? This is >>>> more of a user experience question than an interop question, as long >>>> as we have a way of telling a client it can't use a particular >>>> nickname. >>> >>> I think there can be room for policy differences here, if people feel >>> that to be important. But then the usage mechanisms should be clear >>> so that a UA can understand what it is getting. >>> >>> I can see binding the nickname to an AOR for some duration, thus >>> guaranteeing that some other AOR can't use it. >>> >>> But there should then be some determinism as to whether such a >>> binding is then automatically applied to each session from that AOR, >>> or if it must be requested by each session that wants it. >>> >>> And if the nickname can be used with more than one session of the >>> same AOR, then the lifetime of the binding needs to be specified - is >>> it till the last session using it terminates? Or till the conference >>> terminates? >>> >>> This will impact end user behavior: must the user specify the >>> nickname independently on each of his devices? And, *may* the user >>> use a different nickname from each of his devices even though the AOR >>> is the same? >> >> Ah, I think I see where you are going. >> >> My knee jerk reaction is that the client should have to re-request the >> nickname for each MSRP session. It would be dangerous for a conference >> server to simply assume that a second session from the same AoR should >> have the same nickname. My thoughts were more along the line of if a >> client was _allowed_ to use the same nickname in more than one MSRP >> session. >> >> It seems like that a conference server SHOULD NOT (or maybe MUST NOT) >> assume the same nickname applies for more than one session from the >> same AoR, but MAY allow it. Allowing a nickname means accepting a >> nickname request, but never means assuming a nickname for a session >> when none was explicitly requested on that session. >> >> The policy question is about what a conference server allows. Or more >> to the point, what it rejects. But never what it _assumes_. For >> example, reject a nickname request if it is already in use for another >> session in the same conference. Or, reject a nickname request if it is >> already in use by a different AoR in the same conference. Or reject it >> if it used by a different AoR for any active conference. Or if it was >> used in an active conference in the last XXX minutes. Or something else. >> >> >> Ben. > From ben@nostrum.com Wed Nov 30 14:35:12 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8381F0C4E for ; Wed, 30 Nov 2011 14:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXsqvi6Nz+vc for ; Wed, 30 Nov 2011 14:35:11 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 888E31F0C35 for ; Wed, 30 Nov 2011 14:35:11 -0800 (PST) Received: from dn3-53.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pAUMZ6vF008664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Nov 2011 16:35:07 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: <4ED6AE9C.8030108@alum.mit.edu> Date: Wed, 30 Nov 2011 16:35:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> <4ECD3529.60204@alum.mit.edu> <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> <4ECE121F.6070908@ericsson.com> <522D1E1F-9A8F-4392-94E4-FBB73CB38190@nostrum.com> <4ED3E567.40104@alum.mit.edu> <99FCDF92-4AED-41DA-8353-A03861774D8A@nostrum.com> <4ED61221.2070405@ericsson.com> <4ED6AE9C.8030108@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:35:12 -0000 Given the "MUST NOT automatically assign" part, do we need to put any = constraints on what nicknames the conference server MAY allow? For = example, is it illegal to allow two different AoRs to use the same = nickname, if the service provider has some a priori knowledge that they = represent the same entity? On Nov 30, 2011, at 4:30 PM, Paul Kyzivat wrote: > I wouldn't object to this. >=20 > Thanks, > Paul >=20 > On 11/30/11 7:23 PM, Miguel A. Garcia wrote: >> Since we are converging, do you have any comments to the following = text? >>=20 >> Once the conference server has reserved a nickname and has >> bound it to a URI (e.g., a SIP Address-of-Record), the >> conference server MAY allow the usage of the same nickname >> by the same user (identified by the same URI, such as a SIP >> AoR) over a second MSRP session. This might be the case if >> the user joins the same conference from a different SIP >> UA. In this case, the user MAY request the same or a >> different nickname than that used in conjunction with the >> first MSRP session; the conference server MAY accept the >> usage of the same nickname by the same user. The conference >> server MUST NOT automatically assign the same nickname to >> more than one MSRP session established from the same URI, >> because this can create confusion to the user as whether the >> same nickname is bound to the second MSRP session. >>=20 >> /Miguel >>=20 >>=20 >>=20 >> On 28/11/2011 21:18, Ben Campbell wrote: >>>=20 >>> On Nov 28, 2011, at 1:47 PM, Paul Kyzivat wrote: >>>=20 >>>> On 11/24/11 9:43 PM, Ben Campbell wrote: >>>>>=20 >>>>> On Nov 24, 2011, at 7:39 AM, Ben Campbell wrote: >>>>>=20 >>>>>>=20 >>>>>> On Nov 24, 2011, at 3:45 AM, Miguel A. Garcia wrote: >>>>>>=20 >>>>>>> On 23/11/2011 19:42, Ben Campbell wrote: >>>>>>>>> - the nickname is bound only to a session, not to an AOR. >>>>>>>>> The nicknames for sessions must all be unique. >>>>>>>>=20 >>>>>>>> I think this is the right answer, but I think it's really = "bound >>>>>>>> to an AoR in the scope of a session". It seems like any scoping >>>>>>>> of nicknames beyond a specific session should be a matter of >>>>>>>> local policy. Is there anything that stops an implementation = from >>>>>>>> binding a nickname across multiple simultaneous sessions or = even >>>>>>>> multiple sequential sessions if it wants to? >>>>>>>>=20 >>>>>>>=20 >>>>>>> I wouldn't like to see this option as the only one. I would like >>>>>>> to join the conference with the same AOR from different devices >>>>>>> and use the same nickname. Basically, I would like to hide the >>>>>>> fact that I am using several devices to join the chat, and be >>>>>>> known with a single nickname across all devices. >>>>>>=20 >>>>>> Sure, but isn't that still a local policy choice on how an >>>>>> implementation handles the same nicknames across multiple MSRP >>>>>> sessions? >>>>>=20 >>>>> To elaborate: Would it make sense to say something the effect that = a >>>>> nick is bound to an AoR for the scope of the MSRP session. A >>>>> conference server MAY, as a matter of local policy, bind the nick = at >>>>> a higher scope. For example=85 [list a few use cases] >>>>>=20 >>>>> Or do you think the other use cases need to be standardized? This = is >>>>> more of a user experience question than an interop question, as = long >>>>> as we have a way of telling a client it can't use a particular >>>>> nickname. >>>>=20 >>>> I think there can be room for policy differences here, if people = feel >>>> that to be important. But then the usage mechanisms should be clear >>>> so that a UA can understand what it is getting. >>>>=20 >>>> I can see binding the nickname to an AOR for some duration, thus >>>> guaranteeing that some other AOR can't use it. >>>>=20 >>>> But there should then be some determinism as to whether such a >>>> binding is then automatically applied to each session from that = AOR, >>>> or if it must be requested by each session that wants it. >>>>=20 >>>> And if the nickname can be used with more than one session of the >>>> same AOR, then the lifetime of the binding needs to be specified - = is >>>> it till the last session using it terminates? Or till the = conference >>>> terminates? >>>>=20 >>>> This will impact end user behavior: must the user specify the >>>> nickname independently on each of his devices? And, *may* the user >>>> use a different nickname from each of his devices even though the = AOR >>>> is the same? >>>=20 >>> Ah, I think I see where you are going. >>>=20 >>> My knee jerk reaction is that the client should have to re-request = the >>> nickname for each MSRP session. It would be dangerous for a = conference >>> server to simply assume that a second session from the same AoR = should >>> have the same nickname. My thoughts were more along the line of if a >>> client was _allowed_ to use the same nickname in more than one MSRP >>> session. >>>=20 >>> It seems like that a conference server SHOULD NOT (or maybe MUST = NOT) >>> assume the same nickname applies for more than one session from the >>> same AoR, but MAY allow it. Allowing a nickname means accepting a >>> nickname request, but never means assuming a nickname for a session >>> when none was explicitly requested on that session. >>>=20 >>> The policy question is about what a conference server allows. Or = more >>> to the point, what it rejects. But never what it _assumes_. For >>> example, reject a nickname request if it is already in use for = another >>> session in the same conference. Or, reject a nickname request if it = is >>> already in use by a different AoR in the same conference. Or reject = it >>> if it used by a different AoR for any active conference. Or if it = was >>> used in an active conference in the last XXX minutes. Or something = else. >>>=20 >>>=20 >>> Ben. >>=20 >=20