Hello Group,

While receiving success/failure reports. is it possible= to receive=A0overlapping=A0byte range.

for exampl= e=A0

is it possible to receive first success report with byte range 1-200. = and second=A0

success report with byte range 100-300.

<= br>

Thanks & Regards

Prasun Bheri --20cf303f6aeac22bce04b63b9387-- From ben@nostrum.com Wed Jan 11 06:14:47 2012 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 E0A4021F8637 for ; Wed, 11 Jan 2012 06:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.204 X-Spam-Level: X-Spam-Status: No, score=-101.204 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 zTf6ZRc6xpcw for ; Wed, 11 Jan 2012 06:14:47 -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 4C8F421F85BB for ; Wed, 11 Jan 2012 06:14:47 -0800 (PST) Received: from [10.99.22.56] (mobile-166-205-010-208.mycingular.net [166.205.10.208] (may be forged)) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q0BEEdEe069135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Jan 2012 08:14:44 -0600 (CST) (envelope-from ben@nostrum.com) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5871AFE2-1263-49B1-9132-BB00E91621C3@nostrum.com> X-Mailer: iPhone Mail (9A405) From: Ben Campbell Date: Wed, 11 Jan 2012 08:14:33 -0600 To: prasun bheri Received-SPF: pass (nostrum.com: 166.205.10.208 is authenticated by a trusted mechanism) Cc: "Simple@ietf.org" Subject: Re: [Simple] Is it possible to receive success/failure report with overlapping byte range. 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, 11 Jan 2012 14:14:48 -0000 On Jan 11, 2012, at 1:27 AM, prasun bheri wrote: >=20 > Hello Group, > While receiving success/failure reports. is it possible to receive overlap= ping byte range. >=20 > for example=20 > is it possible to receive first success report with byte range 1-200. and s= econd=20 > success report with byte range 100-300. >=20 I assume you are talking about MSRP. While it would be odd to get such a response without having actually sent ov= erlapping chunks, it's not forbidden. Postel's maxim would suggest that an i= mplementation should be able to handle it if they receive it. It seems reaso= nable to treat such reports as cumulative. Hope this helps! Ben. From gonzalo.camarillo@ericsson.com Fri Jan 20 04:27:03 2012 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 355AE21F84EB for ; Fri, 20 Jan 2012 04:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.796 X-Spam-Level: X-Spam-Status: No, score=-108.796 tagged_above=-999 required=5 tests=[AWL=1.803, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 r12rPXMFrUha for ; Fri, 20 Jan 2012 04:27:02 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 67D8821F8510 for ; Fri, 20 Jan 2012 04:27:02 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-c4-4f195d95e01d Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F9.22.23425.59D591F4; Fri, 20 Jan 2012 13:27:01 +0100 (CET) Received: from [131.160.36.157] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Fri, 20 Jan 2012 13:27:00 +0100 Message-ID: <4F195D94.1000506@ericsson.com> Date: Fri, 20 Jan 2012 14:27:00 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: simple@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [Simple] A comment on draft-ietf-simple-chat-12 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, 20 Jan 2012 12:27:03 -0000 Hi, a quick comment on draft-ietf-simple-chat-12 before I start its IETF LC: http://tools.ietf.org/html/draft-ietf-simple-chat-12 Requirement 2 says the following: REQ-2: A conference participant must be able to determine the identities of the sender and recipient of the received IMs. A few lines below, requirements 5 and 7 talk about participants having nicknames, pseudonyms, real identities, and anonymous identities. What would be a good way to rephrase requirement 2 so that it is clear what type of identity it refers to? Thanks, Gonzalo From miguel.a.garcia@ericsson.com Fri Jan 20 04:54:47 2012 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 58AC221F8557 for ; Fri, 20 Jan 2012 04:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.216 X-Spam-Level: X-Spam-Status: No, score=-9.216 tagged_above=-999 required=5 tests=[AWL=1.383, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 5Cdrbres8eVX for ; Fri, 20 Jan 2012 04:54:46 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 636E721F851D for ; Fri, 20 Jan 2012 04:54:46 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-eb-4f196414ee38 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 95.48.23425.414691F4; Fri, 20 Jan 2012 13:54:44 +0100 (CET) Received: from [159.107.48.31] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Fri, 20 Jan 2012 13:54:44 +0100 Message-ID: <4F196413.1010601@ericsson.com> Date: Fri, 20 Jan 2012 13:54:43 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Gonzalo Camarillo References: <4F195D94.1000506@ericsson.com> In-Reply-To: <4F195D94.1000506@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] A comment on draft-ietf-simple-chat-12 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, 20 Jan 2012 12:54:47 -0000 Gonzalo, The requirement talks on purpose about "identities" with the ambiguity that the word "identities" carry, meaning that we don't really specify whether those identities are SIP identities, tel URL identities, nicknames, or social security identities :-) Then requirements 5 and 7 expand a bit more on the type of identities that must be supported by the system. So, to answer your question, Req-2 deliberately leaves unspecified the type of identity of a sender and recipients, since this will depend on a number of factors, to mention a few: - whether nicknames are supported/used. - whether anonymity is requested. - The type of real identity used by the user. I still leaning towards leaving the requirement written as it is now. /Miguel On 20/01/2012 13:27, Gonzalo Camarillo wrote: > Hi, > > a quick comment on draft-ietf-simple-chat-12 before I start its IETF LC: > > http://tools.ietf.org/html/draft-ietf-simple-chat-12 > > Requirement 2 says the following: > > REQ-2: A conference participant must be able to determine the > identities of the sender and recipient of the received IMs. > > A few lines below, requirements 5 and 7 talk about participants having > nicknames, pseudonyms, real identities, and anonymous identities. > > What would be a good way to rephrase requirement 2 so that it is clear > what type of identity it refers to? > > Thanks, > > Gonzalo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From stpeter@stpeter.im Fri Jan 20 07:05:52 2012 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 AD9A421F85C0 for ; Fri, 20 Jan 2012 07:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.772 X-Spam-Level: X-Spam-Status: No, score=-102.772 tagged_above=-999 required=5 tests=[AWL=-0.173, 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 xep7ekeSy6jU for ; Fri, 20 Jan 2012 07:05:52 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2D78A21F85B8 for ; Fri, 20 Jan 2012 07:05:52 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 23B1840058; Fri, 20 Jan 2012 08:15:20 -0700 (MST) Message-ID: <4F1982CD.2040908@stpeter.im> Date: Fri, 20 Jan 2012 08:05:49 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <4F195D94.1000506@ericsson.com> <4F196413.1010601@ericsson.com> In-Reply-To: <4F196413.1010601@ericsson.com> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" Subject: Re: [Simple] A comment on draft-ietf-simple-chat-12 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, 20 Jan 2012 15:05:52 -0000 Further: I'd encourage you to use the word "identifier" because "identity" is vague and overloaded. On 1/20/12 5:54 AM, Miguel A. Garcia wrote: > Gonzalo, > > The requirement talks on purpose about "identities" with the ambiguity > that the word "identities" carry, meaning that we don't really specify > whether those identities are SIP identities, tel URL identities, > nicknames, or social security identities :-) > > Then requirements 5 and 7 expand a bit more on the type of identities > that must be supported by the system. > > So, to answer your question, Req-2 deliberately leaves unspecified the > type of identity of a sender and recipients, since this will depend on a > number of factors, to mention a few: > - whether nicknames are supported/used. > - whether anonymity is requested. > - The type of real identity used by the user. > > I still leaning towards leaving the requirement written as it is now. > > /Miguel > > On 20/01/2012 13:27, Gonzalo Camarillo wrote: >> Hi, >> >> a quick comment on draft-ietf-simple-chat-12 before I start its IETF LC: >> >> http://tools.ietf.org/html/draft-ietf-simple-chat-12 >> >> Requirement 2 says the following: >> >> REQ-2: A conference participant must be able to determine the >> identities of the sender and recipient of the received IMs. >> >> A few lines below, requirements 5 and 7 talk about participants having >> nicknames, pseudonyms, real identities, and anonymous identities. >> >> What would be a good way to rephrase requirement 2 so that it is clear >> what type of identity it refers to? >> >> Thanks, >> >> Gonzalo >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple From gonzalo.camarillo@ericsson.com Sun Jan 22 23:34:52 2012 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 8BB6F21F8637 for ; Sun, 22 Jan 2012 23:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.976 X-Spam-Level: X-Spam-Status: No, score=-108.976 tagged_above=-999 required=5 tests=[AWL=1.623, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 QOC8YCoeVTZV for ; Sun, 22 Jan 2012 23:34:52 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B3A3521F8456 for ; Sun, 22 Jan 2012 23:34:51 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-28-4f1d0d998767 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 24.D3.23425.A9D0D1F4; Mon, 23 Jan 2012 08:34:50 +0100 (CET) Received: from [131.160.36.115] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 23 Jan 2012 08:34:49 +0100 Message-ID: <4F1D0D99.4070904@ericsson.com> Date: Mon, 23 Jan 2012 09:34:49 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: Peter Saint-Andre References: <4F195D94.1000506@ericsson.com> <4F196413.1010601@ericsson.com> <4F1982CD.2040908@stpeter.im> In-Reply-To: <4F1982CD.2040908@stpeter.im> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] A comment on draft-ietf-simple-chat-12 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, 23 Jan 2012 07:34:52 -0000 Hi, right, this sounds more like an identifier, because claiming that a participant will be able to determine your identity when you are an anonymous user is not clear at all. In any case, I am OK with not specifying which exact identifier will be used. However, the requirement should be clear that the vagueness was introduced on purpose. An extra sentence should be enough for the reader to understand what the requirement actually means. Thanks, Gonzalo On 20/01/2012 5:05 PM, Peter Saint-Andre wrote: > Further: I'd encourage you to use the word "identifier" because > "identity" is vague and overloaded. > > On 1/20/12 5:54 AM, Miguel A. Garcia wrote: >> Gonzalo, >> >> The requirement talks on purpose about "identities" with the ambiguity >> that the word "identities" carry, meaning that we don't really specify >> whether those identities are SIP identities, tel URL identities, >> nicknames, or social security identities :-) >> >> Then requirements 5 and 7 expand a bit more on the type of identities >> that must be supported by the system. >> >> So, to answer your question, Req-2 deliberately leaves unspecified the >> type of identity of a sender and recipients, since this will depend on a >> number of factors, to mention a few: >> - whether nicknames are supported/used. >> - whether anonymity is requested. >> - The type of real identity used by the user. >> >> I still leaning towards leaving the requirement written as it is now. >> >> /Miguel >> >> On 20/01/2012 13:27, Gonzalo Camarillo wrote: >>> Hi, >>> >>> a quick comment on draft-ietf-simple-chat-12 before I start its IETF LC: >>> >>> http://tools.ietf.org/html/draft-ietf-simple-chat-12 >>> >>> Requirement 2 says the following: >>> >>> REQ-2: A conference participant must be able to determine the >>> identities of the sender and recipient of the received IMs. >>> >>> A few lines below, requirements 5 and 7 talk about participants having >>> nicknames, pseudonyms, real identities, and anonymous identities. >>> >>> What would be a good way to rephrase requirement 2 so that it is clear >>> what type of identity it refers to? >>> >>> Thanks, >>> >>> Gonzalo >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple From miguel.a.garcia@ericsson.com Sun Jan 22 23:46:48 2012 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 585F521F84B9 for ; Sun, 22 Jan 2012 23:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.413 X-Spam-Level: X-Spam-Status: No, score=-9.413 tagged_above=-999 required=5 tests=[AWL=1.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 cBBoZ8eako7v for ; Sun, 22 Jan 2012 23:46:47 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5616621F8494 for ; Sun, 22 Jan 2012 23:46:47 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-41-4f1d106646de Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.76.23425.6601D1F4; Mon, 23 Jan 2012 08:46:46 +0100 (CET) Received: from [159.107.24.205] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 23 Jan 2012 08:46:45 +0100 Message-ID: <4F1D1064.6050600@ericsson.com> Date: Mon, 23 Jan 2012 08:46:44 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Gonzalo Camarillo References: <4F195D94.1000506@ericsson.com> <4F196413.1010601@ericsson.com> <4F1982CD.2040908@stpeter.im> <4F1D0D99.4070904@ericsson.com> In-Reply-To: <4F1D0D99.4070904@ericsson.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] A comment on draft-ietf-simple-chat-12 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, 23 Jan 2012 07:46:48 -0000 I agree with Peter's and Gonzalo's subsequent comment. So, we will replace "identity" with "identifier" and clarify that the type of identifier is determined by the following requirements. /Miguel On 23/01/2012 8:34, Gonzalo Camarillo wrote: > Hi, > > right, this sounds more like an identifier, because claiming that a > participant will be able to determine your identity when you are an > anonymous user is not clear at all. > > In any case, I am OK with not specifying which exact identifier will be > used. However, the requirement should be clear that the vagueness was > introduced on purpose. An extra sentence should be enough for the reader > to understand what the requirement actually means. > > Thanks, > > Gonzalo > > > On 20/01/2012 5:05 PM, Peter Saint-Andre wrote: >> Further: I'd encourage you to use the word "identifier" because >> "identity" is vague and overloaded. >> >> On 1/20/12 5:54 AM, Miguel A. Garcia wrote: >>> Gonzalo, >>> >>> The requirement talks on purpose about "identities" with the ambiguity >>> that the word "identities" carry, meaning that we don't really specify >>> whether those identities are SIP identities, tel URL identities, >>> nicknames, or social security identities :-) >>> >>> Then requirements 5 and 7 expand a bit more on the type of identities >>> that must be supported by the system. >>> >>> So, to answer your question, Req-2 deliberately leaves unspecified the >>> type of identity of a sender and recipients, since this will depend on a >>> number of factors, to mention a few: >>> - whether nicknames are supported/used. >>> - whether anonymity is requested. >>> - The type of real identity used by the user. >>> >>> I still leaning towards leaving the requirement written as it is now. >>> >>> /Miguel >>> >>> On 20/01/2012 13:27, Gonzalo Camarillo wrote: >>>> Hi, >>>> >>>> a quick comment on draft-ietf-simple-chat-12 before I start its IETF LC: >>>> >>>> http://tools.ietf.org/html/draft-ietf-simple-chat-12 >>>> >>>> Requirement 2 says the following: >>>> >>>> REQ-2: A conference participant must be able to determine the >>>> identities of the sender and recipient of the received IMs. >>>> >>>> A few lines below, requirements 5 and 7 talk about participants having >>>> nicknames, pseudonyms, real identities, and anonymous identities. >>>> >>>> What would be a good way to rephrase requirement 2 so that it is clear >>>> what type of identity it refers to? >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From gonzalo.camarillo@ericsson.com Mon Jan 23 00:10:44 2012 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 53CB321F8604 for ; Mon, 23 Jan 2012 00:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.124 X-Spam-Level: X-Spam-Status: No, score=-109.124 tagged_above=-999 required=5 tests=[AWL=1.475, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 QpzAhByIU3B5 for ; Mon, 23 Jan 2012 00:10:43 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A6C5621F85FC for ; Mon, 23 Jan 2012 00:10:42 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-d2-4f1d16011918 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 19.05.27041.1061D1F4; Mon, 23 Jan 2012 09:10:41 +0100 (CET) Received: from [131.160.36.115] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 23 Jan 2012 09:10:41 +0100 Message-ID: <4F1D1600.4070302@ericsson.com> Date: Mon, 23 Jan 2012 10:10:40 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: Miguel Garcia A References: <4F195D94.1000506@ericsson.com> <4F196413.1010601@ericsson.com> <4F1982CD.2040908@stpeter.im> <4F1D0D99.4070904@ericsson.com> <4F1D1064.6050600@ericsson.com> In-Reply-To: <4F1D1064.6050600@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] A comment on draft-ietf-simple-chat-12 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, 23 Jan 2012 08:10:44 -0000 Hi Miguel Angel, thanks. As soon as the new revision hits the archives I will initiate the IETF LC. Cheers, Gonzalo On 23/01/2012 9:46 AM, Miguel Garcia A wrote: > I agree with Peter's and Gonzalo's subsequent comment. > > So, we will replace "identity" with "identifier" and clarify that the > type of identifier is determined by the following requirements. > > /Miguel > > On 23/01/2012 8:34, Gonzalo Camarillo wrote: >> Hi, >> >> right, this sounds more like an identifier, because claiming that a >> participant will be able to determine your identity when you are an >> anonymous user is not clear at all. >> >> In any case, I am OK with not specifying which exact identifier will be >> used. However, the requirement should be clear that the vagueness was >> introduced on purpose. An extra sentence should be enough for the reader >> to understand what the requirement actually means. >> >> Thanks, >> >> Gonzalo >> >> >> On 20/01/2012 5:05 PM, Peter Saint-Andre wrote: >>> Further: I'd encourage you to use the word "identifier" because >>> "identity" is vague and overloaded. >>> >>> On 1/20/12 5:54 AM, Miguel A. Garcia wrote: >>>> Gonzalo, >>>> >>>> The requirement talks on purpose about "identities" with the ambiguity >>>> that the word "identities" carry, meaning that we don't really specify >>>> whether those identities are SIP identities, tel URL identities, >>>> nicknames, or social security identities :-) >>>> >>>> Then requirements 5 and 7 expand a bit more on the type of identities >>>> that must be supported by the system. >>>> >>>> So, to answer your question, Req-2 deliberately leaves unspecified the >>>> type of identity of a sender and recipients, since this will depend on a >>>> number of factors, to mention a few: >>>> - whether nicknames are supported/used. >>>> - whether anonymity is requested. >>>> - The type of real identity used by the user. >>>> >>>> I still leaning towards leaving the requirement written as it is now. >>>> >>>> /Miguel >>>> >>>> On 20/01/2012 13:27, Gonzalo Camarillo wrote: >>>>> Hi, >>>>> >>>>> a quick comment on draft-ietf-simple-chat-12 before I start its IETF LC: >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-simple-chat-12 >>>>> >>>>> Requirement 2 says the following: >>>>> >>>>> REQ-2: A conference participant must be able to determine the >>>>> identities of the sender and recipient of the received IMs. >>>>> >>>>> A few lines below, requirements 5 and 7 talk about participants having >>>>> nicknames, pseudonyms, real identities, and anonymous identities. >>>>> >>>>> What would be a good way to rephrase requirement 2 so that it is clear >>>>> what type of identity it refers to? >>>>> >>>>> Thanks, >>>>> >>>>> Gonzalo >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/simple >> > From internet-drafts@ietf.org Mon Jan 23 01:40:08 2012 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 734C021F867D; Mon, 23 Jan 2012 01:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 BvZdkhh29u6h; Mon, 23 Jan 2012 01:40:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715B121F8659; Mon, 23 Jan 2012 01:39:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120123093949.21849.9411.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2012 01:39:49 -0800 Cc: simple@ietf.org Subject: [Simple] I-D Action: draft-ietf-simple-chat-13.txt 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, 23 Jan 2012 09:40:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP for Instant Messaging and Presenc= e Leveraging Extensions Working Group of the IETF. Title : Multi-party Chat Using the Message Session Relay Protoco= l (MSRP) Author(s) : Aki Niemi Miguel A. Garcia-Martin Geir A. Sandbakken Filename : draft-ietf-simple-chat-13.txt Pages : 35 Date : 2012-01-23 The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-simple-chat-13.txt From miguel.a.garcia@ericsson.com Mon Jan 23 01:42:09 2012 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 BDBB121F84F3 for ; Mon, 23 Jan 2012 01:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.561 X-Spam-Level: X-Spam-Status: No, score=-9.561 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 fRbJKeifgoJ4 for ; Mon, 23 Jan 2012 01:42:09 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D831E21F84EC for ; Mon, 23 Jan 2012 01:42:08 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-57-4f1d2b6f5c82 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B5.E5.23425.F6B2D1F4; Mon, 23 Jan 2012 10:42:08 +0100 (CET) Received: from [159.107.24.205] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 23 Jan 2012 10:42:07 +0100 Message-ID: <4F1D2B6E.2080501@ericsson.com> Date: Mon, 23 Jan 2012 10:42:06 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Gonzalo Camarillo References: <4F195D94.1000506@ericsson.com> <4F196413.1010601@ericsson.com> <4F1982CD.2040908@stpeter.im> <4F1D0D99.4070904@ericsson.com> <4F1D1064.6050600@ericsson.com> <4F1D1600.4070302@ericsson.com> In-Reply-To: <4F1D1600.4070302@ericsson.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] A comment on draft-ietf-simple-chat-12 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, 23 Jan 2012 09:42:09 -0000 Hi: I have just posted version -13. I have replaced "identity" with "identifier" in most of the occurrences throughout the document. Additionally, I had clarified that requirement #2 refers to the identifier used by the sender or recipient when he/she joined the chat room. I think this is ready now. BR, Miguel On 23/01/2012 9:10, Gonzalo Camarillo wrote: > Hi Miguel Angel, > > thanks. As soon as the new revision hits the archives I will initiate > the IETF LC. > > Cheers, > > Gonzalo > > On 23/01/2012 9:46 AM, Miguel Garcia A wrote: >> I agree with Peter's and Gonzalo's subsequent comment. >> >> So, we will replace "identity" with "identifier" and clarify that the >> type of identifier is determined by the following requirements. >> >> /Miguel >> >> On 23/01/2012 8:34, Gonzalo Camarillo wrote: >>> Hi, >>> >>> right, this sounds more like an identifier, because claiming that a >>> participant will be able to determine your identity when you are an >>> anonymous user is not clear at all. >>> >>> In any case, I am OK with not specifying which exact identifier will be >>> used. However, the requirement should be clear that the vagueness was >>> introduced on purpose. An extra sentence should be enough for the reader >>> to understand what the requirement actually means. >>> >>> Thanks, >>> >>> Gonzalo >>> >>> >>> On 20/01/2012 5:05 PM, Peter Saint-Andre wrote: >>>> Further: I'd encourage you to use the word "identifier" because >>>> "identity" is vague and overloaded. >>>> >>>> On 1/20/12 5:54 AM, Miguel A. Garcia wrote: >>>>> Gonzalo, >>>>> >>>>> The requirement talks on purpose about "identities" with the ambiguity >>>>> that the word "identities" carry, meaning that we don't really specify >>>>> whether those identities are SIP identities, tel URL identities, >>>>> nicknames, or social security identities :-) >>>>> >>>>> Then requirements 5 and 7 expand a bit more on the type of identities >>>>> that must be supported by the system. >>>>> >>>>> So, to answer your question, Req-2 deliberately leaves unspecified the >>>>> type of identity of a sender and recipients, since this will depend on a >>>>> number of factors, to mention a few: >>>>> - whether nicknames are supported/used. >>>>> - whether anonymity is requested. >>>>> - The type of real identity used by the user. >>>>> >>>>> I still leaning towards leaving the requirement written as it is now. >>>>> >>>>> /Miguel >>>>> >>>>> On 20/01/2012 13:27, Gonzalo Camarillo wrote: >>>>>> Hi, >>>>>> >>>>>> a quick comment on draft-ietf-simple-chat-12 before I start its IETF LC: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-simple-chat-12 >>>>>> >>>>>> Requirement 2 says the following: >>>>>> >>>>>> REQ-2: A conference participant must be able to determine the >>>>>> identities of the sender and recipient of the received IMs. >>>>>> >>>>>> A few lines below, requirements 5 and 7 talk about participants having >>>>>> nicknames, pseudonyms, real identities, and anonymous identities. >>>>>> >>>>>> What would be a good way to rephrase requirement 2 so that it is clear >>>>>> what type of identity it refers to? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/simple >>> >> > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From gonzalo.camarillo@ericsson.com Mon Jan 23 06:03:47 2012 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 48BEF21F850D for ; Mon, 23 Jan 2012 06:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.44 X-Spam-Level: X-Spam-Status: No, score=-109.44 tagged_above=-999 required=5 tests=[AWL=1.159, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 V9NxFnx8a4yC for ; Mon, 23 Jan 2012 06:03:46 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1E421F8471 for ; Mon, 23 Jan 2012 06:03:46 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-a3-4f1d68c13e84 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F6.F2.02613.1C86D1F4; Mon, 23 Jan 2012 15:03:45 +0100 (CET) Received: from [131.160.36.115] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 23 Jan 2012 15:03:44 +0100 Message-ID: <4F1D68C0.1050804@ericsson.com> Date: Mon, 23 Jan 2012 16:03:44 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: Miguel Garcia A References: <4F195D94.1000506@ericsson.com> <4F196413.1010601@ericsson.com> <4F1982CD.2040908@stpeter.im> <4F1D0D99.4070904@ericsson.com> <4F1D1064.6050600@ericsson.com> <4F1D1600.4070302@ericsson.com> <4F1D2B6E.2080501@ericsson.com> In-Reply-To: <4F1D2B6E.2080501@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] A comment on draft-ietf-simple-chat-12 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, 23 Jan 2012 14:03:47 -0000 Hi, thanks. I have just requested the IETF LC. Cheers, Gonzalo On 23/01/2012 11:42 AM, Miguel Garcia A wrote: > Hi: > > I have just posted version -13. I have replaced "identity" with > "identifier" in most of the occurrences throughout the document. > Additionally, I had clarified that requirement #2 refers to the > identifier used by the sender or recipient when he/she joined the chat room. > > I think this is ready now. > > BR, > > Miguel > > On 23/01/2012 9:10, Gonzalo Camarillo wrote: >> Hi Miguel Angel, >> >> thanks. As soon as the new revision hits the archives I will initiate >> the IETF LC. >> >> Cheers, >> >> Gonzalo >> >> On 23/01/2012 9:46 AM, Miguel Garcia A wrote: >>> I agree with Peter's and Gonzalo's subsequent comment. >>> >>> So, we will replace "identity" with "identifier" and clarify that the >>> type of identifier is determined by the following requirements. >>> >>> /Miguel >>> >>> On 23/01/2012 8:34, Gonzalo Camarillo wrote: >>>> Hi, >>>> >>>> right, this sounds more like an identifier, because claiming that a >>>> participant will be able to determine your identity when you are an >>>> anonymous user is not clear at all. >>>> >>>> In any case, I am OK with not specifying which exact identifier will be >>>> used. However, the requirement should be clear that the vagueness was >>>> introduced on purpose. An extra sentence should be enough for the reader >>>> to understand what the requirement actually means. >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> >>>> On 20/01/2012 5:05 PM, Peter Saint-Andre wrote: >>>>> Further: I'd encourage you to use the word "identifier" because >>>>> "identity" is vague and overloaded. >>>>> >>>>> On 1/20/12 5:54 AM, Miguel A. Garcia wrote: >>>>>> Gonzalo, >>>>>> >>>>>> The requirement talks on purpose about "identities" with the ambiguity >>>>>> that the word "identities" carry, meaning that we don't really specify >>>>>> whether those identities are SIP identities, tel URL identities, >>>>>> nicknames, or social security identities :-) >>>>>> >>>>>> Then requirements 5 and 7 expand a bit more on the type of identities >>>>>> that must be supported by the system. >>>>>> >>>>>> So, to answer your question, Req-2 deliberately leaves unspecified the >>>>>> type of identity of a sender and recipients, since this will depend on a >>>>>> number of factors, to mention a few: >>>>>> - whether nicknames are supported/used. >>>>>> - whether anonymity is requested. >>>>>> - The type of real identity used by the user. >>>>>> >>>>>> I still leaning towards leaving the requirement written as it is now. >>>>>> >>>>>> /Miguel >>>>>> >>>>>> On 20/01/2012 13:27, Gonzalo Camarillo wrote: >>>>>>> Hi, >>>>>>> >>>>>>> a quick comment on draft-ietf-simple-chat-12 before I start its IETF LC: >>>>>>> >>>>>>> http://tools.ietf.org/html/draft-ietf-simple-chat-12 >>>>>>> >>>>>>> Requirement 2 says the following: >>>>>>> >>>>>>> REQ-2: A conference participant must be able to determine the >>>>>>> identities of the sender and recipient of the received IMs. >>>>>>> >>>>>>> A few lines below, requirements 5 and 7 talk about participants having >>>>>>> nicknames, pseudonyms, real identities, and anonymous identities. >>>>>>> >>>>>>> What would be a good way to rephrase requirement 2 so that it is clear >>>>>>> what type of identity it refers to? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Gonzalo >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Simple mailing list >>>>>>> Simple@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/simple >>>> >>> >> > From iesg-secretary@ietf.org Mon Jan 23 07:47:37 2012 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 8610C21F8749; Mon, 23 Jan 2012 07:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 jqr0PTmqjK7H; Mon, 23 Jan 2012 07:47:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089DE21F8746; Mon, 23 Jan 2012 07:47:37 -0800 (PST) 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.64p1 Message-ID: <20120123154737.16006.3624.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2012 07:47:37 -0800 Cc: simple@ietf.org Subject: [Simple] Last Call: (Multi-party Chat Using 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: Mon, 23 Jan 2012 15:47:37 -0000 The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'Multi-party Chat Using 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 2012-02-06. 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 The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. Note that This document has a downward reference to RFC 4353. Please comment during the last call on the appropriateness of this downref. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-simple-chat/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-simple-chat/ No IPR declarations have been submitted directly on this I-D. From prasun.bheri@gmail.com Wed Jan 25 08:34:15 2012 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 3FFCE21F8574 for ; Wed, 25 Jan 2012 08:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.133 X-Spam-Level: X-Spam-Status: No, score=-3.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Q32lZ3T4aZzf for ; Wed, 25 Jan 2012 08:34:14 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D86921F857F for ; Wed, 25 Jan 2012 08:34:14 -0800 (PST) Received: by lahl5 with SMTP id l5so1364510lah.31 for ; Wed, 25 Jan 2012 08:34:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=ncQGHLon0j0RzjvKCpnrYAod0wYqoJK0lixx5IXnkbw=; b=bDSDsZXjdLbskmFvKEQiSXhiaoVEmKmo4UEETLVCSGjEEn9ZEcwGtuyK5qa3WyfSju A8Wi8Krz55toZ6yFyp7NZOab6gINay/tUFGbd4gygXQjHPLx7bZt9KW+/YNadxFkodjZ Aq/6y9X2zJm+DXTB59zyL4JLzWU9JrcuVnfhk= Received: by 10.112.25.74 with SMTP id a10mr4522937lbg.58.1327509253251; Wed, 25 Jan 2012 08:34:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.3.234 with HTTP; Wed, 25 Jan 2012 08:33:32 -0800 (PST) From: prasun bheri Date: Wed, 25 Jan 2012 22:03:32 +0530 Message-ID: To: Simple@ietf.org Content-Type: multipart/alternative; boundary=bcaec55556ba79e27804b75cd5c0 Subject: [Simple] Few queries in regards to MSRP 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, 25 Jan 2012 16:34:15 -0000 --bcaec55556ba79e27804b75cd5c0 Content-Type: text/plain; charset=ISO-8859-1 Hello Group, I have these following queries with respect to MSRP: 1. Section 5.4 says "*active endpoint MUST immediately issue a SEND request"* however no timeout period is specified so hoping its application specific, I would like to know on what factors does this timeout value depend on? I am using MSRP to deliver and/or receive MMS messages, so any suggestions on initial timeout value in this case? What would be the right thing to do when initial message is not received immediately? 2. In case of active end point, if no payload is immediately available, protocol requires that active endpoint sends an empty send message with byte-range 1-0/0, Could this send message have same message-id as that of payload's message-id that follows this initial send? My understanding is that both of these should have different message id, but I would like to hear your comment on this. 3. Once a session is created, is there a way to know if this communication is only one way or half duplex or full duplex? Thanks & Regards Prasun Bheri --bcaec55556ba79e27804b75cd5c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Group,

I have these following=A0queries with respe= ct to MSRP:

=A0

Section 5.4 says "active endpoint MUST immediately issue a SEND request"=A0however n= o timeout period is specified so hoping its application specific, I would l= ike to know on what factors does this timeout value depend on? I am using M= SRP to deliver and/or receive MMS messages, so any suggestions on initial t= imeout value in this case? What would be the right thing to do when initial= message is not received immediately?
In case of active end point, if no payload is immediately available, pr= otocol requires that active endpoint sends an empty send message with byte-= range 1-0/0, Could this send message have same message-id as that of payloa= d's message-id that follows this initial send? My understanding is that= both of these should have different message id, but I would like to hear y= our comment on this.
Once a session is created, is there a way to know if this communication= is only one way or half duplex or full duplex?

Thanks & Regards

Prasun Bheri

--bcaec55556ba79e27804b75cd5c0-- From ben@nostrum.com Wed Jan 25 12:58:07 2012 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 CC8BF11E80B9 for ; Wed, 25 Jan 2012 12:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.155, 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 ygGpXbUPiHzL for ; Wed, 25 Jan 2012 12:58:07 -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 0D6B511E80C5 for ; Wed, 25 Jan 2012 12:58:06 -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 q0PKvxX1066051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Jan 2012 14:58:03 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_B59449E7-8DD8-4B1A-8E32-357A42EC567B" From: Ben Campbell In-Reply-To: Date: Wed, 25 Jan 2012 14:58:01 -0600 Message-Id: <1943ECE7-582A-43F8-8B96-CC79E27441EA@nostrum.com> References: To: prasun bheri 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] Few queries in regards to MSRP 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, 25 Jan 2012 20:58:07 -0000 --Apple-Mail=_B59449E7-8DD8-4B1A-8E32-357A42EC567B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, see inline: On Jan 25, 2012, at 10:33 AM, prasun bheri wrote: > Hello Group, >=20 > I have these following queries with respect to MSRP: > =20 > Section 5.4 says "active endpoint MUST immediately issue a SEND = request" however no timeout period is specified so hoping its = application specific, I would like to know on what factors does this = timeout value depend on? I am using MSRP to deliver and/or receive MMS = messages, so any suggestions on initial timeout value in this case? What = would be the right thing to do when initial message is not received = immediately? There's not a timeout per se for this. The idea is that, if the active = party doesn't have an actual message ready to send when it sets up the = connection, it should send a dummy message. The passive party should not assume anything about the identity of the = active party until it receives at least the header fields for a Send = request. Afterwards, it can determine the connected party by comparing = the received MSRP URI to the one it handed out in the SDP. If it doesn't = get something in a timely matter, it could drop the connection (and tear = down the SIP dialog)--but timely manner here probably means minutes, not = seconds. > In case of active end point, if no payload is immediately available, = protocol requires that active endpoint sends an empty send message with = byte-range 1-0/0, Could this send message have same message-id as that = of payload's message-id that follows this initial send? My understanding = is that both of these should have different message id, but I would like = to hear your comment on this. Since it would not be part of any subsequent message payload, it should = have a different message-id. > Once a session is created, is there a way to know if this = communication is only one way or half duplex or full duplex? This would normally be part of the session setup--i.e. in the SDP = exchange. See section 8.9 of RFC 4975. Hope this helps! Ben.= --Apple-Mail=_B59449E7-8DD8-4B1A-8E32-357A42EC567B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

Hello = Group,

I have these following queries with = respect to MSRP:

Section 5.4 says = "active endpoint MUST immediately issue a SEND request" however = no timeout period is specified so hoping its application specific, I = would like to know on what factors does this timeout value depend on? I = am using MSRP to deliver and/or receive MMS messages, so any suggestions = on initial timeout value in this case? What would be the right thing to = do when initial message is not received = immediately?

There's not = a timeout per se for this. The idea is that, if the active party doesn't = have an actual message ready to send when it sets up the connection, it = should send a dummy message.

The passive party = should not assume anything about the identity of the active party until = it receives at least the header fields for a Send request. Afterwards, = it can determine the connected party by comparing the received MSRP URI = to the one it handed out in the SDP. If it doesn't get something in a = timely matter, it could drop the connection (and tear down the SIP = dialog)--but timely manner here probably means minutes, not = seconds.

In case of active end point, if no payload is immediately available, = protocol requires that active endpoint sends an empty send message with = byte-range 1-0/0, Could this send message have same message-id as that = of payload's message-id that follows this initial send? My understanding = is that both of these should have different message id, but I would like = to hear your comment on this.

Since it = would not be part of any subsequent message payload, it should have a = different message-id.

=
Once a session is created, is there a way to know if this = communication is only one way or half duplex or full = duplex?

This would normally be part of = the session setup--i.e. in the SDP exchange. See section 8.9 of RFC = 4975.

Hope this = helps!

Ben.

= --Apple-Mail=_B59449E7-8DD8-4B1A-8E32-357A42EC567B--