From simple-bounces@ietf.org Mon May 02 15:57:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSh3B-0001iW-4j; Mon, 02 May 2005 15:57:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSh38-0001fO-P8 for simple@megatron.ietf.org; Mon, 02 May 2005 15:57:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28837 for ; Mon, 2 May 2005 15:57:48 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DShGr-0005p9-Fa for simple@ietf.org; Mon, 02 May 2005 16:12:03 -0400 Received: from [64.101.149.196] ([64.101.149.196]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j42K0SYN008945 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 2 May 2005 15:00:29 -0500 In-Reply-To: <1850f3705d118aca5304afc7fea6308c@ekabal.com> References: <40d9d5ad8542b37bc0de84d1687217f6@ekabal.com> <426DA57A.7010809@cs.columbia.edu> <426DB587.7090604@cs.columbia.edu> <9a5a39471199885157c7f1795c065e44@ekabal.com> <426EF39F.2080908@cs.columbia.edu> <1850f3705d118aca5304afc7fea6308c@ekabal.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Simple] Free text in presence documents Date: Mon, 2 May 2005 14:58:11 -0500 To: Rohan Mahy X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org WG" , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org > > On Apr 26, 2005, at 19:06, Henning Schulzrinne wrote: > >> Rohan Mahy wrote: >> >>> I disagree that it explains any more to the human observer *here* >>> under the mood element than it would in a generic textual element >>> hanging under person. >> >> No. Even in this contrived example, the sentence >> >> "I'm getting my paycheck!" >> >> has a different meaning when it appears next to mood 'happy' compared >> to a location reference. See also the item about filtering. > > what different meaning? In "mood happy", it mean's "I'm happy, because I'm getting my paycheck". In "location", it means "I'm not at my desk because I'm at the paymaster's desk". -- dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 04 09:50:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTKHD-00034L-L8; Wed, 04 May 2005 09:50:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTKHB-00034C-Ob for simple@megatron.ietf.org; Wed, 04 May 2005 09:50:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09241 for ; Wed, 4 May 2005 09:50:55 -0400 (EDT) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTKVG-00078H-OS for simple@ietf.org; Wed, 04 May 2005 10:05:32 -0400 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id 72AA5A8974 for ; Wed, 4 May 2005 15:50:46 +0200 (CEST) Received: from [192.168.1.45] (unknown [82.196.214.14]) by voyager.coretrek.no (Postfix) with ESMTP id 8157CA895E for ; Wed, 4 May 2005 15:50:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: <716f86965a506f9681efe302582da123@telio.no> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "simple@ietf.org WG" From: Hisham Khartabil Date: Wed, 4 May 2005 15:50:49 +0200 X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Simple] Instant Message Delivery and Read Reports X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I have submitted a new draft regarding IM delivery and read reports. Until it appears in the archive, please pick up a copy from http://www.imsbook.com/hisham/draft-khartabil-simple-message-delivery- read-report-00.txt Comments are most welcome about the idea of delivery and read reports for instant messages. Technical comments are also welcome at this point. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 04 11:16:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLcQ-0002W3-Km; Wed, 04 May 2005 11:16:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLcO-0002SH-RS for simple@megatron.ietf.org; Wed, 04 May 2005 11:16:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20147 for ; Wed, 4 May 2005 11:16:54 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTLqU-0001LF-Me for simple@ietf.org; Wed, 04 May 2005 11:31:32 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 04 May 2005 11:30:10 -0400 X-IronPort-AV: i="3.92,154,1112587200"; d="scan'208"; a="47529743:sNHT1644789442" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j44FFxRw000246; Wed, 4 May 2005 11:16:33 -0400 (EDT) Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 11:16:31 -0400 Received: from cisco.com ([161.44.79.173]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 11:16:30 -0400 Message-ID: <4278E74E.4000702@cisco.com> Date: Wed, 04 May 2005 11:16:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] Instant Message Delivery and Read Reports References: <716f86965a506f9681efe302582da123@telio.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2005 15:16:30.0935 (UTC) FILETIME=[40188670:01C550BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org WG" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hisham, Thanks for doing this. I think it is on the right track. I have some relatively minor comments, and then one more major one. First the minor ones: 1) Section 3.1: > The Message-ID field is populated with a value that is > random is space and time. ^^^^^^ Don't you mean "unique"? Random is one way to approximate unique, but I don't know what "random in space and time" is, and I think unique is really the goal. 2) Section 3.1: If an endpoint sending an Instant message and has requested a positive-delivery, negative-delivery and/or read report, it MUST NOT start any timers. I don't understand why this is here. Must not set any timers for what? Is this intended to change behavior that the client might otherwise have it it hadn't requested a report? Or is this just intended to say that there are no time limits associated with when delivery reports may be received? 3) Section 3.2 The delivery report SHOULD NOT contain a Message-ID header field. Why? It is a standard mime header, and it is harmless. It isn't useful, but so what? At least explain the SHOULD NOT as just being related to the uselessness and possible confusion. 4) Section 3.3 This talks about returning 485 if it can't determine if a message has been read. Might be good to talk about other possible error responses that are appropriate, such as: 401 (unauthorized), or 603 (decline). 5) Section 6.2 After reading this I still don't think I understand exactly how an exploder is supposed to work. Then, the more fundamental thing: 6) The example in 3.2: Content-type: Message/CPIM From: Bob To: Alice Content-type: message/status-report Content-Disposition: confirm I think this is wrong - if Content-Disposition is to be used, it should be *outside* the CPIM wrapper. If it is inside of CPIM, then maybe we shouldn't be using content-disposition at all, but rather some other new header. My concern is that the SIP application processing MESSAGE needs to know what to do with body parts it sees. If there was a multipart containing a CPIM and and S/MIME, it would be wanting to decide at that level, before opening the CPIM - which might be the responsibility of an entirely different piece of code. If the distinction between what is a message and what is a delivery report needs to be made at the sip message processing level, then the C-D needs to be outside the CPIM. But if the distinction needs to be made later, then the C-D for both should be render, and something inside the CPIM should determine this. If we think both messages and delivery reports can make it through gateways transparently, then we should make this something inside the CPIM. If we think they can't, and that gateways will be responsible for creating and consuming these reports, then using C-D outside the CPIM seems right. I'm now thinking this makes better sense as something inside the CPIM, not involving Content-Disposition. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri May 06 05:51:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTzUk-00008p-Tu; Fri, 06 May 2005 05:51:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTzUj-00008V-Ve for simple@megatron.ietf.org; Fri, 06 May 2005 05:51:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21893 for ; Fri, 6 May 2005 05:51:38 -0400 (EDT) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTzj8-0006vV-B8 for simple@ietf.org; Fri, 06 May 2005 06:06:39 -0400 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id 915ABA98E9 for ; Fri, 6 May 2005 11:51:25 +0200 (CEST) Received: from [192.168.1.38] (unknown [82.196.214.14]) by voyager.coretrek.no (Postfix) with ESMTP id 90BE6A98DB for ; Fri, 6 May 2005 11:51:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <716f86965a506f9681efe302582da123@telio.no> References: <716f86965a506f9681efe302582da123@telio.no> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Instant Message Delivery and Read Reports Date: Fri, 6 May 2005 11:51:29 +0200 To: "simple@ietf.org WG" X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I was asked to shorten the name of the draft. It is now http://www.ietf.org/internet-drafts/draft-khartabil-simple-im-report -00.txt Hisham On May 4, 2005, at 3:50 PM, Hisham Khartabil wrote: > I have submitted a new draft regarding IM delivery and read reports. > Until it appears in the archive, please pick up a copy from > > http://www.imsbook.com/hisham/draft-khartabil-simple-message-delivery- > read-report-00.txt > > Comments are most welcome about the idea of delivery and read reports > for instant messages. Technical comments are also welcome at this > point. > > Regards, > Hisham > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon May 16 13:43:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXjca-0006kh-Lv; Mon, 16 May 2005 13:43:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXjcY-0006kc-Hq for simple@megatron.ietf.org; Mon, 16 May 2005 13:43:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15610 for ; Mon, 16 May 2005 13:43:13 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXjt7-0005SP-Od for simple@ietf.org; Mon, 16 May 2005 14:00:23 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4GHgvdv003598 for ; Mon, 16 May 2005 10:42:57 -0700 (PDT) Received: from [160.39.251.93] (vpn-10-50-16-76.qualcomm.com [10.50.16.76]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4GHgtHc025479 for ; Mon, 16 May 2005 10:42:56 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Mon, 16 May 2005 10:42:53 -0700 To: simple@ietf.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Simple] element issue for common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Howdy, In today's GEOPRIV meeting, Hannes pointed out that at IETF 62, the SIMPLE WG agreed to ask for the introduction of an element to the common policy document. Sorry that I wasn't there to follow the discussion directly, but I believe this is contrary to the basic design of additive permissions. In previous discussions within GEOPRIV, the relative ease with which some identities may be minted has led to the conclusion that this would either be useless or would encourage people to warp the additive permissions principle. To put this in concrete terms, if a grant of permissions to element contains an element of "evil.example" in order to prevent the folks from "evil.example" from access, the relative ease with which "evil.example" folks can create "unknown-ethics.example" makes this of questionable utility. At most, it forces the attacker to mint an identity. What's the use case for which this is not true? Or the use case in which an additive permission does not behave in this way? I would really appreciate this use case being put forward before the common policy document is changed. Thanks, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon May 16 22:42:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXs21-0004Qo-DO; Mon, 16 May 2005 22:42:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXs1z-0004Qi-J9 for simple@megatron.ietf.org; Mon, 16 May 2005 22:42:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01817 for ; Mon, 16 May 2005 22:42:01 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXsId-0005La-Hj for simple@ietf.org; Mon, 16 May 2005 22:59:17 -0400 Received: from [192.168.1.103] (c-67-164-135-116.hsd1.tx.comcast.net [67.164.135.116]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j4H2fsc1076869 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 16 May 2005 21:41:55 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <318634CB-54AD-4D76-87DB-90C620A23C76@nostrum.com> Content-Transfer-Encoding: quoted-printable From: Ben Campbell Subject: Re: [Simple] message-sessions-10 WGLC: unique message ID and fail ed connections? Date: Mon, 16 May 2005 21:41:48 -0500 To: SIMPLE mailing list X-Mailer: Apple Mail (2.728) Received-SPF: pass (nostrum.com: 67.164.135.116 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Not like Ben, apparently, as Ben is _much_ later coming to this =20 party. Sorry about that. I'd make excuses but it would be rather =20 pointless. The original point in allowing the use of the same message ID in a =20 replacement session is so the sender can tell the receiver that "this =20= is the same as a previous message I tried to send but don't know if =20 it succeeded. If you have already gotten this, ignore it." (Or =20 overwrite it, but that is a different argument.) So, if we mandate that we cannot ever repeat a message ID, we take =20 away that ability. I can resend the message if I want, but if the =20 recipient has already gotten it, he will get it again. Are people okay with removing that feature? Or am I misreading this =20 whole argument? On Apr 26, 2005, at 2:56 PM, Eric Burger wrote: > I agree wholeheartedly. Yes, like Ben, I'm coming to this party late. > However, a unique message ID fixes a bunch of problems we can see =20 > coming > (see previous thread). Moreover, it makes message delivery =20 > notification (my > next project) a lot easier. > > Since the namespace of Message ID is rather large, and SMTP has been > generating unique Message ID's for, what, 20 years, do you think we =20= > could > get consensus on this issue? > > >> -----Original Message----- >> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org] On Behalf Of Ignacio M=E1s >> Ivars (KI/EAB) >> Sent: Thursday, April 14, 2005 8:13 AM >> To: Gonzalo Camarillo (JO/LMF); Paul Kyzivat >> Cc: SIMPLE mailing list >> Subject: RE: [Simple] message-sessions-10 WGLC: unique >> message ID and failed connections? >> >> Paul, Gonzalo: >> >> I agree completely with Gonzalo's comment. That is why I was >> suggesting that we just add the paragraph from RFC 2822 were >> the uniqueness of message ID is defined, i.e: >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Drfc2= 822 >> The "Message-ID:" field provides a unique message identifier that >> refers to a particular version of a particular message. The >> uniqueness of the message identifier is guaranteed by the host =20 >> that >> generates it. This message identifier is intended to be >> machine readable and not necessarily meaningful to humans. >> A message >> identifier pertains to exactly one instantiation of a particular >> message; subsequent revisions to the message each receive >> new message >> identifiers. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Drfc28= 22 >> >> That would not introduce any other disruptment to the draft, would =20= >> it? >> >> /Ignacio >> >> -----Original Message----- >> From: Gonzalo Camarillo >> To: Paul Kyzivat >> Cc: Ignacio M=E1s Ivars (KI/EAB); SIMPLE mailing list >> Sent: 4/13/2005 8:41 PM >> Subject: Re: [Simple] message-sessions-10 WGLC: unique >> message ID and failed connections? >> >> Paul, >> >> >>> But, as with everything else, this could get complex in a 3pcc >>> situation. A 3pcc controller might do a transfer using >>> >> reinvites. As >> >>> result, one endpoint thinks it has a replacement session, while the >>> other thinks it has a new session. The guy who thinks its a new >>> >> session >> >>> can't very well know what message ids had been used before. >>> >> >> I agree with you on this one. We have already been there >> (e.g., the comedia and the preconditions stuff), and relaying >> on the concept of a SIP session to set the scope of any >> media-related identifier is not a good idea. >> >> Paul and I tried exactly the same in comedia (using >> identifiers scoped by the SIP session) and cocluded that they >> did not work. >> >> >>> Its only >>> soluiton is to use message ids that are guaranteed to be >>> >> globally > unique. >> >> Yes, I agree this is the way to resolve the problem. In fact, >> I believe this is how RFC 2822 defines uniqueness of message >> identifiers. With your proposal we kill two birds with the >> same stone. We align with RFC >> 2822 and we resolve the session mobility problem. >> >> Thanks, >> >> Gonzalo >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 17 03:16:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXwJu-0005JD-AV; Tue, 17 May 2005 03:16:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXwJr-0005Fc-51 for simple@megatron.ietf.org; Tue, 17 May 2005 03:16:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17093 for ; Tue, 17 May 2005 03:16:45 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXwaY-0002xC-Bj for simple@ietf.org; Tue, 17 May 2005 03:34:03 -0400 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j4H7GWPK009232; Tue, 17 May 2005 09:16:44 +0200 Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 09:16:41 +0200 Received: from localhost ([147.214.118.130]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 09:16:41 +0200 Received: (nullmailer pid 8260 invoked by uid 1000); Tue, 17 May 2005 07:16:41 -0000 Subject: Re: [Simple] message-sessions-10 WGLC: unique message ID and fail ed connections? From: Ignacio Mas Ivars To: Ben Campbell In-Reply-To: <318634CB-54AD-4D76-87DB-90C620A23C76@nostrum.com> References: <318634CB-54AD-4D76-87DB-90C620A23C76@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Organization: KI/EAB/TGB/B Date: Tue, 17 May 2005 09:16:40 +0200 Message-Id: <1116314201.7556.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-OriginalArrivalTime: 17 May 2005 07:16:41.0355 (UTC) FILETIME=[5F89FDB0:01C55AB0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable Cc: SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Well, rpecisely because we want the receiver to be able to differentiate that this is the same message being resent we need to have unique message IDs in time and space. The scenario you describe is perfectly possible. If the sender wants to resend the message it will use the same message ID and the receiver knows positively that it is a copy of the previous message. The problem can arise when we don't require ID's to be unique, since there could be some pathological scenarios where the receiver can have doubts on whether is the same or a new message. So, in my opinion we are precisely ensuring that we can have that ability. We never said that you can't repeat a message ID, only that you can't repeat message ID in two *different* messages... or am I missing something here? /Ignacio On Mon, 2005-05-16 at 21:41 -0500, Ben Campbell wrote: > Not like Ben, apparently, as Ben is _much_ later coming to this =20 > party. Sorry about that. I'd make excuses but it would be rather =20 > pointless. >=20 > The original point in allowing the use of the same message ID in a =20 > replacement session is so the sender can tell the receiver that "this =20 > is the same as a previous message I tried to send but don't know if =20 > it succeeded. If you have already gotten this, ignore it." (Or =20 > overwrite it, but that is a different argument.) >=20 > So, if we mandate that we cannot ever repeat a message ID, we take =20 > away that ability. I can resend the message if I want, but if the =20 > recipient has already gotten it, he will get it again. >=20 > Are people okay with removing that feature? Or am I misreading this =20 > whole argument? >=20 >=20 > On Apr 26, 2005, at 2:56 PM, Eric Burger wrote: >=20 > > I agree wholeheartedly. Yes, like Ben, I'm coming to this party late. > > However, a unique message ID fixes a bunch of problems we can see =20 > > coming > > (see previous thread). Moreover, it makes message delivery =20 > > notification (my > > next project) a lot easier. > > > > Since the namespace of Message ID is rather large, and SMTP has been > > generating unique Message ID's for, what, 20 years, do you think we =20 > > could > > get consensus on this issue? > > > > > >> -----Original Message----- > >> From: simple-bounces@ietf.org > >> [mailto:simple-bounces@ietf.org] On Behalf Of Ignacio M=E1s > >> Ivars (KI/EAB) > >> Sent: Thursday, April 14, 2005 8:13 AM > >> To: Gonzalo Camarillo (JO/LMF); Paul Kyzivat > >> Cc: SIMPLE mailing list > >> Subject: RE: [Simple] message-sessions-10 WGLC: unique > >> message ID and failed connections? > >> > >> Paul, Gonzalo: > >> > >> I agree completely with Gonzalo's comment. That is why I was > >> suggesting that we just add the paragraph from RFC 2822 were > >> the uniqueness of message ID is defined, i.e: > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Drfc= 2822 > >> The "Message-ID:" field provides a unique message identifier that > >> refers to a particular version of a particular message. The > >> uniqueness of the message identifier is guaranteed by the host =20 > >> that > >> generates it. This message identifier is intended to be > >> machine readable and not necessarily meaningful to humans. > >> A message > >> identifier pertains to exactly one instantiation of a particular > >> message; subsequent revisions to the message each receive > >> new message > >> identifiers. > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Drfc2= 822 > >> > >> That would not introduce any other disruptment to the draft, would =20 > >> it? > >> > >> /Ignacio > >> > >> -----Original Message----- > >> From: Gonzalo Camarillo > >> To: Paul Kyzivat > >> Cc: Ignacio M=E1s Ivars (KI/EAB); SIMPLE mailing list > >> Sent: 4/13/2005 8:41 PM > >> Subject: Re: [Simple] message-sessions-10 WGLC: unique > >> message ID and failed connections? > >> > >> Paul, > >> > >> > >>> But, as with everything else, this could get complex in a 3pcc > >>> situation. A 3pcc controller might do a transfer using > >>> > >> reinvites. As > >> > >>> result, one endpoint thinks it has a replacement session, while the > >>> other thinks it has a new session. The guy who thinks its a new > >>> > >> session > >> > >>> can't very well know what message ids had been used before. > >>> > >> > >> I agree with you on this one. We have already been there > >> (e.g., the comedia and the preconditions stuff), and relaying > >> on the concept of a SIP session to set the scope of any > >> media-related identifier is not a good idea. > >> > >> Paul and I tried exactly the same in comedia (using > >> identifiers scoped by the SIP session) and cocluded that they > >> did not work. > >> > >> > >>> Its only > >>> soluiton is to use message ids that are guaranteed to be > >>> > >> globally > unique. > >> > >> Yes, I agree this is the way to resolve the problem. In fact, > >> I believe this is how RFC 2822 defines uniqueness of message > >> identifiers. With your proposal we kill two birds with the > >> same stone. We align with RFC > >> 2822 and we resolve the session mobility problem. > >> > >> Thanks, > >> > >> Gonzalo > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > >> > >> > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple --=20 Ignacio M=E1s Ivars Service enablers and protocols, Ericsson Research (EAB/TBG/B) Ericsson AB Phone: +46 8 4045580 Torshamsgatan 23 Fax: +46 8 7575720 SE-164 80 Stockholm, Sweden mailto: ignacio.mas.ivars@ericsson.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 17 06:24:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXzFS-0000Q3-G6; Tue, 17 May 2005 06:24:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXzFR-0000N7-43 for simple@megatron.ietf.org; Tue, 17 May 2005 06:24:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03525 for ; Tue, 17 May 2005 06:24:21 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXzW9-0004gk-27 for simple@ietf.org; Tue, 17 May 2005 06:41:42 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IGM00E7GPNICH@dns2.cselt.it> for simple@ietf.org; Tue, 17 May 2005 12:11:42 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 12:23:01 +0200 Date: Tue, 17 May 2005 12:23:58 +0200 From: Goix Walter Subject: RE: [Simple] Instant Message Delivery and Read Reports To: Hisham Khartabil , simple@ietf.org Message-id: <91C9464F6AFC0647A2D8069E25DBF496E00E89@EXC01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Simple] Instant Message Delivery and Read Reports Thread-Index: AcVSIXQm67INceEZR6+PQTOLlFFm/QImxO3A Content-class: urn:content-classes:message X-OriginalArrivalTime: 17 May 2005 10:23:01.0203 (UTC) FILETIME=[673F6A30:01C55ACA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I've just gone through the document that is pretty interesting. A couple of general comments/questions: - Why is the draft limited to message/cpim? I understand there may be the need to exchange id and delivery notification transparently no matter the transport (MESSAGE, msrp or other), but then this may limit its use to message/cpim content-type only. It may be interesting to have an alternative solution at higher level that could also apply to other content types, such as text/plain or others. - For intermediary-type of behavior, it may be interesting to use RLS-type of XML data format to get delivery information about each user. In this case, it may also be interesting to have the option to request delivery notification through an event-based paradigm, as an alternative to get notified=20 - Is the 'timer' related to some Expires: header or similar to be included in the message? walter > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Hisham Khartabil > Sent: Friday, May 06, 2005 11:51 AM > To: simple@ietf.org WG > Subject: Re: [Simple] Instant Message Delivery and Read Reports >=20 >=20 > I was asked to shorten the name of the draft. It is now >=20 > http://www.ietf.org/internet-drafts/draft-khartabil-simple-im-report=20 > -00.txt >=20 > Hisham >=20 > On May 4, 2005, at 3:50 PM, Hisham Khartabil wrote: >=20 > > I have submitted a new draft regarding IM delivery and read reports. > > Until it appears in the archive, please pick up a copy from > > > >=20 > http://www.imsbook.com/hisham/draft-khartabil-> simple-message-delivery- > > read-report-00.txt > > > > Comments are most welcome about the idea of delivery and=20 > read reports > > for instant messages. Technical comments are also welcome at this =20 > > point. > > > > Regards, > > Hisham > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 17 08:47:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY1UN-00087C-NV; Tue, 17 May 2005 08:47:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY1UI-000871-JG for simple@megatron.ietf.org; Tue, 17 May 2005 08:47:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18069 for ; Tue, 17 May 2005 08:47:52 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY1l2-0004Rs-5s for simple@ietf.org; Tue, 17 May 2005 09:05:13 -0400 Received: from [192.168.1.103] (c-67-164-135-116.hsd1.tx.comcast.net [67.164.135.116]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j4HCligD018265 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 17 May 2005 07:47:45 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <1116314201.7556.10.camel@localhost.localdomain> References: <318634CB-54AD-4D76-87DB-90C620A23C76@nostrum.com> <1116314201.7556.10.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <13168A2B-781D-4224-9362-00D5ABD0C0F7@nostrum.com> Content-Transfer-Encoding: quoted-printable From: Ben Campbell Subject: Re: [Simple] message-sessions-10 WGLC: unique message ID and fail ed connections? Date: Tue, 17 May 2005 07:47:38 -0500 To: Ignacio Mas Ivars X-Mailer: Apple Mail (2.728) Received-SPF: pass (nostrum.com: 67.164.135.116 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: quoted-printable Cc: SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org To summarize then, you are saying that Message ID should be unique, =20 but if we resend the _same_ message we still use the _same_ message =20 ID. Is this correct? If so, then I think this is a good idea. I think I got confused by previous statements about a different =20 _version_ of the message getting a new ID. Or maybe I just can't read. On May 17, 2005, at 2:16 AM, Ignacio Mas Ivars wrote: > Well, rpecisely because we want the receiver to be able to =20 > differentiate > that this is the same message being resent we need to have unique > message IDs in time and space. The scenario you describe is perfectly > possible. If the sender wants to resend the message it will use the =20= > same > message ID and the receiver knows positively that it is a copy of the > previous message. The problem can arise when we don't require ID's =20 > to be > unique, since there could be some pathological scenarios where the > receiver can have doubts on whether is the same or a new message. =20 > So, in > my opinion we are precisely ensuring that we can have that ability. We > never said that you can't repeat a message ID, only that you can't > repeat message ID in two *different* messages... or am I missing > something here? > > /Ignacio > > > On Mon, 2005-05-16 at 21:41 -0500, Ben Campbell wrote: > >> Not like Ben, apparently, as Ben is _much_ later coming to this >> party. Sorry about that. I'd make excuses but it would be rather >> pointless. >> >> The original point in allowing the use of the same message ID in a >> replacement session is so the sender can tell the receiver that "this >> is the same as a previous message I tried to send but don't know if >> it succeeded. If you have already gotten this, ignore it." (Or >> overwrite it, but that is a different argument.) >> >> So, if we mandate that we cannot ever repeat a message ID, we take >> away that ability. I can resend the message if I want, but if the >> recipient has already gotten it, he will get it again. >> >> Are people okay with removing that feature? Or am I misreading this >> whole argument? >> >> >> On Apr 26, 2005, at 2:56 PM, Eric Burger wrote: >> >> >>> I agree wholeheartedly. Yes, like Ben, I'm coming to this party =20 >>> late. >>> However, a unique message ID fixes a bunch of problems we can see >>> coming >>> (see previous thread). Moreover, it makes message delivery >>> notification (my >>> next project) a lot easier. >>> >>> Since the namespace of Message ID is rather large, and SMTP has been >>> generating unique Message ID's for, what, 20 years, do you think we >>> could >>> get consensus on this issue? >>> >>> >>> >>>> -----Original Message----- >>>> From: simple-bounces@ietf.org >>>> [mailto:simple-bounces@ietf.org] On Behalf Of Ignacio M=E1s >>>> Ivars (KI/EAB) >>>> Sent: Thursday, April 14, 2005 8:13 AM >>>> To: Gonzalo Camarillo (JO/LMF); Paul Kyzivat >>>> Cc: SIMPLE mailing list >>>> Subject: RE: [Simple] message-sessions-10 WGLC: unique >>>> message ID and failed connections? >>>> >>>> Paul, Gonzalo: >>>> >>>> I agree completely with Gonzalo's comment. That is why I was >>>> suggesting that we just add the paragraph from RFC 2822 were >>>> the uniqueness of message ID is defined, i.e: >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Drf= c2822 >>>> The "Message-ID:" field provides a unique message identifier that >>>> refers to a particular version of a particular message. The >>>> uniqueness of the message identifier is guaranteed by the host >>>> that >>>> generates it. This message identifier is intended to be >>>> machine readable and not necessarily meaningful to humans. >>>> A message >>>> identifier pertains to exactly one instantiation of a particular >>>> message; subsequent revisions to the message each receive >>>> new message >>>> identifiers. >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Drfc= 2822 >>>> >>>> That would not introduce any other disruptment to the draft, would >>>> it? >>>> >>>> /Ignacio >>>> >>>> -----Original Message----- >>>> From: Gonzalo Camarillo >>>> To: Paul Kyzivat >>>> Cc: Ignacio M=E1s Ivars (KI/EAB); SIMPLE mailing list >>>> Sent: 4/13/2005 8:41 PM >>>> Subject: Re: [Simple] message-sessions-10 WGLC: unique >>>> message ID and failed connections? >>>> >>>> Paul, >>>> >>>> >>>> >>>>> But, as with everything else, this could get complex in a 3pcc >>>>> situation. A 3pcc controller might do a transfer using >>>>> >>>>> >>>> reinvites. As >>>> >>>> >>>>> result, one endpoint thinks it has a replacement session, while =20= >>>>> the >>>>> other thinks it has a new session. The guy who thinks its a new >>>>> >>>>> >>>> session >>>> >>>> >>>>> can't very well know what message ids had been used before. >>>>> >>>>> >>>> >>>> I agree with you on this one. We have already been there >>>> (e.g., the comedia and the preconditions stuff), and relaying >>>> on the concept of a SIP session to set the scope of any >>>> media-related identifier is not a good idea. >>>> >>>> Paul and I tried exactly the same in comedia (using >>>> identifiers scoped by the SIP session) and cocluded that they >>>> did not work. >>>> >>>> >>>> >>>>> Its only >>>>> soluiton is to use message ids that are guaranteed to be >>>>> >>>>> >>>> globally > unique. >>>> >>>> Yes, I agree this is the way to resolve the problem. In fact, >>>> I believe this is how RFC 2822 defines uniqueness of message >>>> identifiers. With your proposal we kill two birds with the >>>> same stone. We align with RFC >>>> 2822 and we resolve the session mobility problem. >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > --=20 > Ignacio M=E1s Ivars > Service enablers and protocols, Ericsson Research (EAB/TBG/B) > Ericsson AB Phone: +46 8 4045580 > Torshamsgatan 23 Fax: +46 8 7575720 > SE-164 80 Stockholm, Sweden mailto: ignacio.mas.ivars@ericsson.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 17 08:57:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY1dD-0001V1-Qh; Tue, 17 May 2005 08:57:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY1dB-0001Qu-2g for simple@megatron.ietf.org; Tue, 17 May 2005 08:57:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19064 for ; Tue, 17 May 2005 08:57:03 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY1tu-0004zI-I9 for simple@ietf.org; Tue, 17 May 2005 09:14:24 -0400 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id j4HCunVI006498; Tue, 17 May 2005 07:56:49 -0500 Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 17 May 2005 07:56:43 -0500 Message-ID: <1116334554.19758.3.camel@localhost.localdomain> From: Ignacio Mas Ivars To: Ben Campbell Subject: Re: [Simple] message-sessions-10 WGLC: unique message ID and fail ed connections? Date: Tue, 17 May 2005 07:56:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 1.6 (+) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0962154725==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0962154725== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55ADF.DBECC020" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C55ADF.DBECC020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, that is what I meant! I am sorry if I did not make it clear with = my messages. I believe this solves all the problems we could foresee with delayed reports while still allowing to identify a replicate message. /Ignacio On Tue, 2005-05-17 at 07:47 -0500, Ben Campbell wrote: > To summarize then, you are saying that Message ID should be unique, =20 > but if we resend the _same_ message we still use the _same_ message =20 > ID. Is this correct? >=20 > If so, then I think this is a good idea. >=20 > I think I got confused by previous statements about a different =20 > _version_ of the message getting a new ID. Or maybe I just can't = read. >=20 > On May 17, 2005, at 2:16 AM, Ignacio Mas Ivars wrote: >=20 > > Well, rpecisely because we want the receiver to be able to =20 > > differentiate > > that this is the same message being resent we need to have unique > > message IDs in time and space. The scenario you describe is = perfectly > > possible. If the sender wants to resend the message it will use the = =20 > > same > > message ID and the receiver knows positively that it is a copy of = the > > previous message. The problem can arise when we don't require ID's = > > to be > > unique, since there could be some pathological scenarios where the > > receiver can have doubts on whether is the same or a new message. =20 > > So, in > > my opinion we are precisely ensuring that we can have that ability. = We > > never said that you can't repeat a message ID, only that you can't > > repeat message ID in two *different* messages... or am I missing > > something here? > > > > /Ignacio > > > > > > --=20 Ignacio M=E1s Ivars Service enablers and protocols, Ericsson Research (EAB/TBG/B) Ericsson AB Phone: +46 8 4045580 Torshamsgatan 23 Fax: +46 8 7575720 SE-164 80 Stockholm, Sweden mailto: ignacio.mas.ivars@ericsson.com ------_=_NextPart_001_01C55ADF.DBECC020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Simple] message-sessions-10 WGLC: unique message ID and = failed connections?

Yes, that is what I meant! I am sorry if I did not = make it clear with my
messages. I believe this solves all the problems we = could foresee with
delayed reports while still allowing to identify a = replicate message.

/Ignacio

On Tue, 2005-05-17 at 07:47 -0500, Ben Campbell = wrote:
> To summarize then, you are saying that Message = ID should be unique, 
> but if we resend the _same_ message we still = use the _same_ message 
> ID. Is this correct?
>
> If so, then I think this is a good idea.
>
> I think I got confused by previous statements = about a different 
> _version_ of the message getting a new ID. Or = maybe I just can't read.
>
> On May 17, 2005, at 2:16 AM, Ignacio Mas Ivars = wrote:
>
> > Well, rpecisely because we want the = receiver to be able to 
> > differentiate
> > that this is the same message being resent = we need to have unique
> > message IDs in time and space. The = scenario you describe is perfectly
> > possible. If the sender wants to resend = the message it will use the 
> > same
> > message ID and the receiver knows = positively that it is a copy of the
> > previous message. The problem can arise = when we don't require ID's 
> > to be
> > unique, since there could be some = pathological scenarios where the
> > receiver can have doubts on whether is the = same or a new message. 
> > So, in
> > my opinion we are precisely ensuring that = we can have that ability. We
> > never said that you can't repeat a message = ID, only that you can't
> > repeat message ID in two *different* = messages... or am I missing
> > something here?
> >
> > /Ignacio
> >
> >
> >
--
Ignacio M=E1s Ivars
Service enablers and protocols, Ericsson Research = (EAB/TBG/B)
Ericsson = AB           &nbs= p;         Phone: +46 8 = 4045580
Torshamsgatan = 23           &nbs= p;    Fax:   +46 8 7575720
SE-164 80 Stockholm, Sweden     = mailto: ignacio.mas.ivars@ericsson.com

------_=_NextPart_001_01C55ADF.DBECC020-- --===============0962154725== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0962154725==-- From simple-bounces@ietf.org Tue May 17 09:59:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY2bd-0008Tn-MN; Tue, 17 May 2005 09:59:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY2bb-0008Tf-W1 for simple@megatron.ietf.org; Tue, 17 May 2005 09:59:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25488 for ; Tue, 17 May 2005 09:59:29 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY2sL-0000I0-MY for simple@ietf.org; Tue, 17 May 2005 10:16:51 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 17 May 2005 09:59:22 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4HDx8e8018127; Tue, 17 May 2005 09:59:19 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 09:59:09 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 09:59:09 -0400 Message-ID: <4289F8AD.5090205@cisco.com> Date: Tue, 17 May 2005 09:59:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Simple] message-sessions-10 WGLC: unique message ID and fail ed connections? References: <318634CB-54AD-4D76-87DB-90C620A23C76@nostrum.com> <1116314201.7556.10.camel@localhost.localdomain> <13168A2B-781D-4224-9362-00D5ABD0C0F7@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 17 May 2005 13:59:09.0691 (UTC) FILETIME=[9911A4B0:01C55AE8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA25488 Cc: SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Ben Campbell wrote: > To summarize then, you are saying that Message ID should be unique, bu= t=20 > if we resend the _same_ message we still use the _same_ message ID. Is= =20 > this correct? Yes, yes, yes - this is how it must be! If I type "Are you there" into my client, then it needs to assign a=20 message ID to that and then try to send it. If there is some problem=20 with the stream, then it can reinvite to reestablish the stream and then=20 send the same message with the same message ID. If I type "Are you there" *again*, then that needs to be assigned a=20 *different" message ID. I don't know how much of this we must say, but we must be clear. Paul > If so, then I think this is a good idea. >=20 > I think I got confused by previous statements about a different =20 > _version_ of the message getting a new ID. Or maybe I just can't read. >=20 > On May 17, 2005, at 2:16 AM, Ignacio Mas Ivars wrote: >=20 >> Well, rpecisely because we want the receiver to be able to differenti= ate >> that this is the same message being resent we need to have unique >> message IDs in time and space. The scenario you describe is perfectly >> possible. If the sender wants to resend the message it will use the s= ame >> message ID and the receiver knows positively that it is a copy of the >> previous message. The problem can arise when we don't require ID's to= be >> unique, since there could be some pathological scenarios where the >> receiver can have doubts on whether is the same or a new message. So,= in >> my opinion we are precisely ensuring that we can have that ability. We >> never said that you can't repeat a message ID, only that you can't >> repeat message ID in two *different* messages... or am I missing >> something here? >> >> /Ignacio >> >> >> On Mon, 2005-05-16 at 21:41 -0500, Ben Campbell wrote: >> >>> Not like Ben, apparently, as Ben is _much_ later coming to this >>> party. Sorry about that. I'd make excuses but it would be rather >>> pointless. >>> >>> The original point in allowing the use of the same message ID in a >>> replacement session is so the sender can tell the receiver that "this >>> is the same as a previous message I tried to send but don't know if >>> it succeeded. If you have already gotten this, ignore it." (Or >>> overwrite it, but that is a different argument.) >>> >>> So, if we mandate that we cannot ever repeat a message ID, we take >>> away that ability. I can resend the message if I want, but if the >>> recipient has already gotten it, he will get it again. >>> >>> Are people okay with removing that feature? Or am I misreading this >>> whole argument? >>> >>> >>> On Apr 26, 2005, at 2:56 PM, Eric Burger wrote: >>> >>> >>>> I agree wholeheartedly. Yes, like Ben, I'm coming to this party la= te. >>>> However, a unique message ID fixes a bunch of problems we can see >>>> coming >>>> (see previous thread). Moreover, it makes message delivery >>>> notification (my >>>> next project) a lot easier. >>>> >>>> Since the namespace of Message ID is rather large, and SMTP has been >>>> generating unique Message ID's for, what, 20 years, do you think we >>>> could >>>> get consensus on this issue? >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: simple-bounces@ietf.org >>>>> [mailto:simple-bounces@ietf.org] On Behalf Of Ignacio M=E1s >>>>> Ivars (KI/EAB) >>>>> Sent: Thursday, April 14, 2005 8:13 AM >>>>> To: Gonzalo Camarillo (JO/LMF); Paul Kyzivat >>>>> Cc: SIMPLE mailing list >>>>> Subject: RE: [Simple] message-sessions-10 WGLC: unique >>>>> message ID and failed connections? >>>>> >>>>> Paul, Gonzalo: >>>>> >>>>> I agree completely with Gonzalo's comment. That is why I was >>>>> suggesting that we just add the paragraph from RFC 2822 were >>>>> the uniqueness of message ID is defined, i.e: >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= rfc2822 >>>>> The "Message-ID:" field provides a unique message identifier that >>>>> refers to a particular version of a particular message. The >>>>> uniqueness of the message identifier is guaranteed by the host >>>>> that >>>>> generates it. This message identifier is intended to be >>>>> machine readable and not necessarily meaningful to humans. >>>>> A message >>>>> identifier pertains to exactly one instantiation of a particular >>>>> message; subsequent revisions to the message each receive >>>>> new message >>>>> identifiers. >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dr= fc2822 >>>>> >>>>> That would not introduce any other disruptment to the draft, would >>>>> it? >>>>> >>>>> /Ignacio >>>>> >>>>> -----Original Message----- >>>>> From: Gonzalo Camarillo >>>>> To: Paul Kyzivat >>>>> Cc: Ignacio M=E1s Ivars (KI/EAB); SIMPLE mailing list >>>>> Sent: 4/13/2005 8:41 PM >>>>> Subject: Re: [Simple] message-sessions-10 WGLC: unique >>>>> message ID and failed connections? >>>>> >>>>> Paul, >>>>> >>>>> >>>>> >>>>>> But, as with everything else, this could get complex in a 3pcc >>>>>> situation. A 3pcc controller might do a transfer using >>>>>> >>>>>> >>>>> reinvites. As >>>>> >>>>> >>>>>> result, one endpoint thinks it has a replacement session, while t= he >>>>>> other thinks it has a new session. The guy who thinks its a new >>>>>> >>>>>> >>>>> session >>>>> >>>>> >>>>>> can't very well know what message ids had been used before. >>>>>> >>>>>> >>>>> >>>>> I agree with you on this one. We have already been there >>>>> (e.g., the comedia and the preconditions stuff), and relaying >>>>> on the concept of a SIP session to set the scope of any >>>>> media-related identifier is not a good idea. >>>>> >>>>> Paul and I tried exactly the same in comedia (using >>>>> identifiers scoped by the SIP session) and cocluded that they >>>>> did not work. >>>>> >>>>> >>>>> >>>>>> Its only >>>>>> soluiton is to use message ids that are guaranteed to be >>>>>> >>>>>> >>>>> globally > unique. >>>>> >>>>> Yes, I agree this is the way to resolve the problem. In fact, >>>>> I believe this is how RFC 2822 defines uniqueness of message >>>>> identifiers. With your proposal we kill two birds with the >>>>> same stone. We align with RFC >>>>> 2822 and we resolve the session mobility problem. >>>>> >>>>> Thanks, >>>>> >>>>> Gonzalo >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> --=20 >> Ignacio M=E1s Ivars >> Service enablers and protocols, Ericsson Research (EAB/TBG/B) >> Ericsson AB Phone: +46 8 4045580 >> Torshamsgatan 23 Fax: +46 8 7575720 >> SE-164 80 Stockholm, Sweden mailto: ignacio.mas.ivars@ericsson.com >> >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 17 10:06:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY2im-0001t6-C8; Tue, 17 May 2005 10:06:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY2il-0001ss-3e for simple@megatron.ietf.org; Tue, 17 May 2005 10:06:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26661 for ; Tue, 17 May 2005 10:06:52 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY2zV-0000hu-6b for simple@ietf.org; Tue, 17 May 2005 10:24:14 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 17 May 2005 10:06:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4HE6BeS021499; Tue, 17 May 2005 10:06:42 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 10:06:39 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 10:06:38 -0400 Message-ID: <4289FA6E.6010200@cisco.com> Date: Tue, 17 May 2005 10:06:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Goix Walter Subject: Re: [Simple] Instant Message Delivery and Read Reports References: <91C9464F6AFC0647A2D8069E25DBF496E00E89@EXC01B.cselt.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2005 14:06:38.0886 (UTC) FILETIME=[A4CF5C60:01C55AE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Goix Walter wrote: > I've just gone through the document that is pretty interesting. > A couple of general comments/questions: > > - Why is the draft limited to message/cpim? I understand there may be > the need to exchange id and delivery notification transparently no > matter the transport (MESSAGE, msrp or other), but then this may limit > its use to message/cpim content-type only. It may be interesting to have > an alternative solution at higher level that could also apply to other > content types, such as text/plain or others. The point of using CPIM is to decouple it from MSRP. "Limiting" it to CPIM does not prevent it from applying to other content precisely because CPIM is itself a wrapper type and may contain all those other types. CPIM becomes the higher level solution you are looking for. > - For intermediary-type of behavior, it may be interesting to use > RLS-type of XML data format to get delivery information about each > user. In this case, it may also be interesting to have the option to > request delivery notification through an event-based paradigm, as an > alternative to get notified Please say more - I don't have a clear idea what you have in mind. The problem with having the intermediary package of the reports is that it doesn't know how long to wait. Paul > - Is the 'timer' related to some Expires: header or similar to be > included in the message? > > walter > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org] On Behalf Of Hisham Khartabil >>Sent: Friday, May 06, 2005 11:51 AM >>To: simple@ietf.org WG >>Subject: Re: [Simple] Instant Message Delivery and Read Reports >> >> >>I was asked to shorten the name of the draft. It is now >> >>http://www.ietf.org/internet-drafts/draft-khartabil-simple-im-report >>-00.txt >> >>Hisham >> >>On May 4, 2005, at 3:50 PM, Hisham Khartabil wrote: >> >> >>>I have submitted a new draft regarding IM delivery and read reports. >>>Until it appears in the archive, please pick up a copy from >>> >>> >> >>http://www.imsbook.com/hisham/draft-khartabil-> > > simple-message-delivery- > >>>read-report-00.txt >>> >>>Comments are most welcome about the idea of delivery and >> >>read reports >> >>>for instant messages. Technical comments are also welcome at this >>>point. >>> >>>Regards, >>>Hisham >>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. > > ==================================================================== > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > ==================================================================== > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 17 11:59:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY4U5-0003nq-8f; Tue, 17 May 2005 11:59:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY4U3-0003ng-PO for simple@megatron.ietf.org; Tue, 17 May 2005 11:59:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09202 for ; Tue, 17 May 2005 11:59:48 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY4kn-0007Bf-80 for simple@ietf.org; Tue, 17 May 2005 12:17:12 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IGN00J085MSWT@dns1.cselt.it> for simple@ietf.org; Tue, 17 May 2005 17:56:52 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 18:02:37 +0200 Date: Tue, 17 May 2005 17:59:25 +0200 From: Goix Walter Subject: RE: [Simple] Instant Message Delivery and Read Reports To: Paul Kyzivat , Goix Walter Message-id: <91C9464F6AFC0647A2D8069E25DBF496E00E90@EXC01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Simple] Instant Message Delivery and Read Reports Thread-Index: AcVa6bzyuFN22qbQRbGF8cUMl+FchQACDZ4Q content-class: urn:content-classes:message X-OriginalArrivalTime: 17 May 2005 16:02:37.0937 (UTC) FILETIME=[D8BA4610:01C55AF9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org [snip] >=20 > The point of using CPIM is to decouple it from MSRP. "Limiting" it to=20 > CPIM does not prevent it from applying to other content precisely=20 > because CPIM is itself a wrapper type and may contain all those other=20 > types. CPIM becomes the higher level solution you are looking for. Sure. My point was just about avoiding overhead by encapsuling messages, by defining support for both with and without cpim encapsulation. For sure cpim guarantees independence from the actual transport mechanism if we use it to carry the message-id, receipt-request and actual delivery report. In this case I would be interesting to lower an optional Expires: header or similar as a message header in the cpim envelope to indicate the validity duration. >=20 > > - For intermediary-type of behavior, it may be interesting to use=20 > > RLS-type of XML data format to get delivery information about each=20 > > user. In this case, it may also be interesting to have the=20 > option to=20 > > request delivery notification through an event-based=20 > paradigm, as an=20 > > alternative to get notified >=20 > Please say more - I don't have a clear idea what you have in=20 > mind. The=20 > problem with having the intermediary package of the reports=20 > is that it=20 > doesn't know how long to wait. The idea was, as an alternative to the current proposal of sending back one IM per delivery notification in the intermediary, for the intermediary to provide a subscription-based mechanism for a watcher to get notified about delivery reports. This could enable, based on policies, other watchers to get notified about the message delivery besides the message sender itself. Optionally, the event package could also enable control over the sending process to interrupt the sending process. Besides, reusing an RLS-type of XML format could ease the notification of delivery state to the watcher. The time for which the intermediary keeps the reports may be implementation dependent (a certain amount of time after the last positive/negative/read report has been received), or based on some extra parameter provided by the original sender (time limited by local configuration). Whilst the reports are kept by the intermediary, the watcher can log out and back in without losing the report information, while this would require an additional store-and-forward feature in a MESSAGE paradigm. I also understand that the 1-to-1 MESSAGE paradigm at the intermediary between the received and the sent delivery report does not require additional implementation in the sender (and the intermediary). It is not clear to me what the value of the is. The examples do not include the scheme of the URI (may im: be provided as sip: if the recipient was a SIP endpoint) nor provide a good understanding of the actual value to be put in in case of redirection. In any case, would this be the AOR of the user, or its contact (in case of forking to distinguish endpoints) ? walter Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu May 19 04:32:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYgSQ-0006jQ-8g; Thu, 19 May 2005 04:32:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYgSO-0006jL-Ly for simple@megatron.ietf.org; Thu, 19 May 2005 04:32:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05267 for ; Thu, 19 May 2005 04:32:38 -0400 (EDT) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYgjV-0001gS-6p for simple@ietf.org; Thu, 19 May 2005 04:50:22 -0400 Received: from esebh106.NOE.Nokia.com ([172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4J8WTef023121; Thu, 19 May 2005 11:32:36 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 May 2005 11:32:35 +0300 Received: from [192.89.6.40] ([10.162.253.41]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 19 May 2005 11:32:35 +0300 Message-ID: <428C4F21.5030004@nokia.com> Date: Thu, 19 May 2005 11:32:33 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Ted Hardie Subject: Re: [Simple] element issue for common policy References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2005 08:32:35.0580 (UTC) FILETIME=[4EE513C0:01C55C4D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, ext Ted Hardie wrote: > Howdy, > In today's GEOPRIV meeting, Hannes pointed out that > at IETF 62, the SIMPLE WG agreed to ask for the > introduction of an element to the common > policy document. Sorry that I wasn't there to follow the discussion > directly, > but I believe this is contrary to the basic design of additive > permissions. In previous discussions within GEOPRIV, the > relative ease with which some identities may be minted has > led to the conclusion that this would either be useless > or would encourage people to warp the additive permissions > principle. > To put this in concrete terms, if a grant of permissions to > element contains an > element of "evil.example" in order to prevent the > folks from "evil.example" from access, the relative > ease with which "evil.example" folks can create > "unknown-ethics.example" makes this of questionable > utility. Yes, and I don't think anyone is arguing otherwise. But at least this seems of less questionable utility compared to excepting identities only, where simple URL scheme / application specific constructs like 'username+unknown-ethics@example.com' are an easy way to get around the exceptions. The next step is to use except a domain, then a TLD. I think the asusmption is that registering a new domain name, let alone a new TLD requires increasingly more effort. > At most, it forces the attacker to mint an identity. > What's the use case for which this is not true? Or the > use case in which an additive permission does not behave > in this way? I don't quite follow. Are you saying domain exceptions should always be wildcards for domains? > I would really appreciate this use case being > put forward before the common policy document is changed. I have put forward this use cases several times, which I think demonstrates the need for the any-except construct. It is the ordinary reactive authorization policy, where everyone *initially* gets to ask for permission to subscribe to your presence information. I say "initially", because a user has to have an option not to be bothered by any more of these requests coming from the "example.com" domain that has proven a playground for phishers and spammers. For implementing this policy with common policy, we need the any-identity condition to match any authenticated identity for the "confirm" action. In addition, we need safeguards against the weak domains, namely the domain exception. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 24 15:47:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DafMu-0007Fa-Tv; Tue, 24 May 2005 15:47:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DafMp-0007Ee-TI; Tue, 24 May 2005 15:47:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07168; Tue, 24 May 2005 15:47:06 -0400 (EDT) Message-Id: <200505241947.PAA07168@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 24 May 2005 15:47:05 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-notify-05.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-notify-05.txt Pages : 15 Date : 2005-5-24 By default, presence delivered using the Presence Event Package for the Session Initiation Protocol is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even a just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of presence data that has actually changed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-notify-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-notify-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-24155101.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-notify-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-notify-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-24155101.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Tue May 24 16:58:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DagUD-0006QT-TJ; Tue, 24 May 2005 16:58:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DagU9-0006Oz-Es for simple@megatron.ietf.org; Tue, 24 May 2005 16:58:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23888 for ; Tue, 24 May 2005 16:58:43 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DagmO-0000Ls-6p for simple@ietf.org; Tue, 24 May 2005 17:17:37 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4OKwWdv014067; Tue, 24 May 2005 13:58:32 -0700 (PDT) Received: from [129.46.74.128] (vpn-10-50-0-107.qualcomm.com [10.50.0.107]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4OKwT3M016289; Tue, 24 May 2005 13:58:30 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <428C4F21.5030004@nokia.com> References: <428C4F21.5030004@nokia.com> Date: Tue, 24 May 2005 13:58:28 -0700 To: Aki Niemi From: Ted Hardie Subject: Re: [Simple] element issue for common policy Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Aki Niemi writes: >> >> To put this in concrete terms, if a grant of permissions to >> element contains an >>element of "evil.example" in order to prevent the >>folks from "evil.example" from access, the relative >>ease with which "evil.example" folks can create >>"unknown-ethics.example" makes this of questionable >>utility. > >Yes, and I don't think anyone is arguing otherwise. But at least >this seems of less questionable utility compared to excepting >identities only, where simple URL scheme / application specific >constructs like 'username+unknown-ethics@example.com' are an easy >way to get around the exceptions. > >The next step is to use except a domain, then a TLD. I think the >asusmption is that registering a new domain name, let alone a new >TLD requires increasingly more effort. I believe there is no functional difference in the difficulty of getting the identity username+unknown-ethics@example.com and username@anydomain.example. The hoop that must be jumped through to get an identity in any number of domains is quite small; even if all of those domains were successfully included in except-domain clauses the cost for minting a domain is around 5 euros and less in bulk. That means that someone at "evil.example" would have to exhaust all of the y*, a*, m* and similar identity minting domains before having to shell out anything and could then do so for trivial costs. > >I have put forward this use cases several times, which I think >demonstrates the need for the any-except construct. It is the >ordinary reactive authorization policy, where everyone *initially* >gets to ask for permission to subscribe to your presence >information. I say "initially", because a user has to have an option >not to be bothered by any more of these requests coming from the >"example.com" domain that has proven a playground for phishers and >spammers. Doing it this way doesn't require the underlying protocol to behave this way; setting it up as reactive authorization so that someone can pre-program the answer "no" to any set they like has the same effect and fits far better into the model. It is still trivially circumvented with the same methods above, of course, but at least in the mean time you haven't changed the model for permissions. >For implementing this policy with common policy, we need the >any-identity condition to match any authenticated identity for the >"confirm" action. In addition, we need safeguards against the weak >domains, namely the domain exception. I think this is based on a fundamentally flawed assumption, that the set of "weak domains" is bounded and knowable. We have ample experience in other contexts to demonstrate that this is not the case for lots of other cases. That set changes over time, sometimes at great rates, and the use of a higher-layer denial for it is both as effective and more appropriate. Speaking personally, I do not believe the "except domain" construction is sufficiently useful to warrant introduction at this stage of protocol work. regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 24 17:26:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DagvL-0003Hb-RX; Tue, 24 May 2005 17:26:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DagvL-0003HT-02 for simple@megatron.ietf.org; Tue, 24 May 2005 17:26:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25603 for ; Tue, 24 May 2005 17:26:48 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DahDa-0001R0-VQ for simple@ietf.org; Tue, 24 May 2005 17:45:43 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 24 May 2005 14:26:09 -0700 X-IronPort-AV: i="3.93,133,1115017200"; d="scan'208"; a="269196727:sNHT1902484700" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4OLPHmW015796; Tue, 24 May 2005 14:26:00 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 14:26:05 -0700 Received: from cisco.com ([161.44.79.130]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 14:26:05 -0700 Message-ID: <42939BEC.9040508@cisco.com> Date: Tue, 24 May 2005 17:26:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Simple] element issue for common policy References: <428C4F21.5030004@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2005 21:26:05.0491 (UTC) FILETIME=[316C4030:01C560A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: Aki Niemi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Ted, How do you imagine people should administer their presence authorization rules? It would seem that watcherinfo and pending status cannot in general work as the way to learn who wants to be authorized. If I set the default authorization to pending then I get spammed with authorization requests, but if I set the default authorization to reject, and only consider subscribers from a named set of domains, then I never learn about legitimate subscribers from other domains. Paul Ted Hardie wrote: > Aki Niemi writes: > >>> >>> To put this in concrete terms, if a grant of permissions to >>> element contains an >>> element of "evil.example" in order to prevent the >>> folks from "evil.example" from access, the relative >>> ease with which "evil.example" folks can create >>> "unknown-ethics.example" makes this of questionable >>> utility. >> >> >> Yes, and I don't think anyone is arguing otherwise. But at least this >> seems of less questionable utility compared to excepting identities >> only, where simple URL scheme / application specific constructs like >> 'username+unknown-ethics@example.com' are an easy way to get around >> the exceptions. >> >> The next step is to use except a domain, then a TLD. I think the >> asusmption is that registering a new domain name, let alone a new TLD >> requires increasingly more effort. > > > I believe there is no functional difference in the difficulty of getting > the identity > username+unknown-ethics@example.com and username@anydomain.example. > The hoop that must be jumped through to get an identity in any number of > domains is quite small; even if all of those domains were successfully > included > in except-domain clauses the cost for minting a domain is around 5 euros > and less in bulk. That means that someone at "evil.example" would have > to exhaust all of the y*, a*, m* and similar identity minting > domains before having to shell out anything and could then do so > for trivial costs. > >> >> I have put forward this use cases several times, which I think >> demonstrates the need for the any-except construct. It is the ordinary >> reactive authorization policy, where everyone *initially* gets to ask >> for permission to subscribe to your presence information. I say >> "initially", because a user has to have an option not to be bothered >> by any more of these requests coming from the "example.com" domain >> that has proven a playground for phishers and spammers. > > > Doing it this way doesn't require the underlying protocol to behave this > way; > setting it up as reactive authorization so that someone can pre-program the > answer "no" to any set they like has the same effect and fits far better > into > the model. It is still trivially circumvented with the same methods above, > of course, but at least in the mean time you haven't changed the model for > permissions. > >> For implementing this policy with common policy, we need the >> any-identity condition to match any authenticated identity for the >> "confirm" action. In addition, we need safeguards against the weak >> domains, namely the domain exception. > > > I think this is based on a fundamentally flawed assumption, that the set of > "weak domains" is bounded and knowable. We have ample experience in > other contexts to demonstrate that this is not the case for lots of other > cases. That set changes over time, sometimes at great rates, and the use > of a higher-layer denial for it is both as effective and more appropriate. > > Speaking personally, I do not believe the "except domain" construction > is sufficiently > useful to warrant introduction at this stage of protocol work. > regards, > Ted Hardie > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 24 18:25:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DahqQ-0005H8-OM; Tue, 24 May 2005 18:25:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DahqP-0005H3-AU for simple@megatron.ietf.org; Tue, 24 May 2005 18:25:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00780 for ; Tue, 24 May 2005 18:25:46 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dai8f-0003qZ-Qt for simple@ietf.org; Tue, 24 May 2005 18:44:42 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4OMPadv023487; Tue, 24 May 2005 15:25:37 -0700 (PDT) Received: from [129.46.74.128] (vpn-10-50-16-111.qualcomm.com [10.50.16.111]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4OMPXJ9023803; Tue, 24 May 2005 15:25:34 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <42939BEC.9040508@cisco.com> References: <428C4F21.5030004@nokia.com> <42939BEC.9040508@cisco.com> Date: Tue, 24 May 2005 15:25:31 -0700 To: Paul Kyzivat From: Ted Hardie Subject: Re: [Simple] element issue for common policy Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Aki Niemi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org At 5:26 PM -0400 5/24/05, Paul Kyzivat wrote: >Ted, > >How do you imagine people should administer their presence >authorization rules? It would seem that watcherinfo and pending >status cannot in general work as the way to learn who wants to be >authorized. If I set the default authorization to pending then I get >spammed with authorization requests, but if I set the default >authorization to reject, and only consider subscribers from a named >set of domains, then I never learn about legitimate subscribers from >other domains. > > Paul Paul, Let's say the real rule is "I grant the following permissions to those in the set (authorized)". To get into the set (authorized), I must put you into the set either via a rule or by explicit action. I can create a rule that says "Everyone from mycompany.example is in set (authorized)". I can create a rule that says "Everyone may be placed in set (pending) from which I may place them in (authorized)". If I want to avoid seeing all of the entries in (pending) because I don't want to be spammed by requests, I can do one of two things: try to limit access to (pending) via a set of rules on who may be in (pending) or treat the problem as automation of the disposition decision. As I understand it, Aki is arguing that the element is a useful mechanism for limiting access to (authorized); it may also be a tool he'd use for limiting access to (pending). I don't think it is useful, for the reasons I've outlined, and I do believe it runs contrary to the additive permissions model in a way that is going to pose later problems. I also believe that the automation of the disposition decision does the same job; I can set up a process (note, not a *rule*) that moves things out of (pending) on my behalf. That process can use whatever heuristics I describe and they can be lots more granular or clever than the can be (e.g. remove requests from (pending) when there are more than N requests with the same username substring within Y seconds). That process can also be me, the human, when I don't care to automate anything. The fundamental problem you pose: "I never learn about legitimate subscribers from other domains" also occurs in any case where legitimate subscribers and black-hats can be matched on the same rule. Yes, it does occur for the "reject all, grant to mycompany.example" case. Unless all legitimate subscribers abandon those for whom minting an identity is easy, though, the is also particularly subject to this problem. You can ease it with multi-stage processing (automation moves some from (pending) to (suspicious) and others to (probably good)). But if you are going to use the system in a way that allows potentially anyone to request authorization (that is, without a white-list), dealing with unwanted requests is one of the costs of allowing legitimate requests through. I personally believe that style approaches are just not likely to be the right bang for the buck. regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 24 19:18:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daieu-0005Yy-FZ; Tue, 24 May 2005 19:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daier-0005X3-SJ for simple@megatron.ietf.org; Tue, 24 May 2005 19:17:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04623 for ; Tue, 24 May 2005 19:17:54 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Daix8-0005vw-J9 for simple@ietf.org; Tue, 24 May 2005 19:36:51 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 24 May 2005 16:17:47 -0700 X-IronPort-AV: i="3.93,133,1115017200"; d="scan'208"; a="638353724:sNHT1603683276" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4ONGvmY005158; Tue, 24 May 2005 16:17:40 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 16:17:44 -0700 Received: from cisco.com ([161.44.79.130]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 16:17:44 -0700 Message-ID: <4293B617.6000400@cisco.com> Date: Tue, 24 May 2005 19:17:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Simple] element issue for common policy References: <428C4F21.5030004@nokia.com> <42939BEC.9040508@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2005 23:17:44.0350 (UTC) FILETIME=[CA4103E0:01C560B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit Cc: Aki Niemi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Ted - comments inline. Thanks, Paul Ted Hardie wrote: > At 5:26 PM -0400 5/24/05, Paul Kyzivat wrote: > >> Ted, >> >> How do you imagine people should administer their presence >> authorization rules? It would seem that watcherinfo and pending status >> cannot in general work as the way to learn who wants to be authorized. >> If I set the default authorization to pending then I get spammed with >> authorization requests, but if I set the default authorization to >> reject, and only consider subscribers from a named set of domains, >> then I never learn about legitimate subscribers from other domains. >> >> Paul > > > Paul, > Let's say the real rule is "I grant the following permissions to > those in the > set (authorized)". To get into the set (authorized), I must put you > into the set either > via a rule or by explicit action. I can create a rule that says > "Everyone from mycompany.example is in set (authorized)". I can create > a rule that says > "Everyone may be placed in set (pending) from which I may place them in > (authorized)". Both of those are fine in some cases, but maybe not sufficient. > If I want to avoid seeing all of the entries in (pending) because I > don't want to be > spammed by requests, I can do one of two things: try to limit access to > (pending) > via a set of rules on who may be in (pending) This is hard if you can't anticipate all the places legitimate subscribers may come from. > or treat the problem as > automation > of the disposition decision. As I understand it, Aki is arguing that > the > element is a useful mechanism for limiting access to (authorized); it > may also > be a tool he'd use for limiting access to (pending). It was my interpretation that he was proposing to use it to limit access to pending. That is what I had in mind too. > I don't think it > is useful, for the reasons I've outlined, It certainly isn't perfect. But it can be another tool in the bag to help manage a problem. If there was an alternative that would do as well then maybe we wouldn't need it, but I haven't seen the alternative. > and I do believe it runs > contrary to the > additive permissions model in a way that is going to pose later > problems. We already have other similar "exceptions" to the additive model. I believe they have been framed in a way that avoids the problems. > I also believe > that the automation of the disposition decision does the same job; I can > set up a process (note, not a *rule*) that moves things out of (pending) on > my behalf. That process can use whatever heuristics I describe and they > can be lots more granular or clever than the can be > (e.g. remove requests from (pending) when there are more than N requests > with the same username substring within Y seconds). Yes, that is a possibility. But that particular rule has easy work arounds But I wonder if rules to detect malicious subscribers are what is needed. I may be naive, but I don't anticipate a flood of malicious subscribers. What is the point? The only one I can think of is DOS, and there will no doubt have to be some other solution to that. I think it is more likely that there just might be a lot of distinct pests. For instance, if you participate in some public forum where your address becomes well known, there might just be lots of "groupies" bugging you. If you can block them in big chunks (e.g. everybody at qualcomm.com seems to be a pest) then that is just a help. > That process > can also be me, the human, when I don't care to automate anything. That is always an option. Its just not always good enough. > The fundamental problem you pose: "I never learn about legitimate > subscribers from other domains" also occurs in any case where legitimate > subscribers > and black-hats can be matched on the same rule. Yes, it does occur for the > "reject all, grant to mycompany.example" case. Yep. That is why use of any such tool must be a thought out decision. ("Are the problems from this domain bad enough to block it?" OR "Do I want to allow people to pend from that domain even though there may be some pests there?") > Unless all legitimate > subscribers abandon those for whom minting an identity is easy, though, the > is also particularly subject to this problem. You can > ease > it with multi-stage processing (automation moves some from (pending) to > (suspicious) and others to (probably good)). I don't know what you have in mind here regarding the status of these potential subscribers, and the UI at each end, while they are in these interim states. Without changing the event package, at the implementation level they are either rejected, pending, or accepted. Additional states have to map into one of these. Then they could affect the UI on the notifier end, but not on the subscriber end. > But if you are going to use > the system in a way that allows potentially anyone to request authorization > (that is, without a white-list), dealing with unwanted requests is one > of the costs > of allowing legitimate requests through. Yes, that is understood. The trick is to minimize the pain of doing so. > I personally believe that > > style approaches are just not likely to be the right bang for the buck. There is certainly room for different opinions on how much bang you get. But how big a buck are we talking about here? If its not such a big buck, then perhaps it is worth allowing as an option. The biggest buck here is probably in the design of user friendly UIs to manage all of this. That is somebody else's buck. > regards, > Ted Hardie > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 25 12:13:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DayVu-0006O5-CC; Wed, 25 May 2005 12:13:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DayVt-0006Nz-Fc for simple@megatron.ietf.org; Wed, 25 May 2005 12:13:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24751 for ; Wed, 25 May 2005 12:13:43 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DayoI-0001gx-BW for simple@ietf.org; Wed, 25 May 2005 12:32:47 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 25 May 2005 09:13:34 -0700 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4PGDV3Q022682; Wed, 25 May 2005 09:13:31 -0700 (PDT) Received: from [192.168.1.100] (che-vpn-cluster-2-89.cisco.com [10.86.242.89]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AJV67971; Wed, 25 May 2005 09:13:30 -0700 (PDT) Message-ID: <4294A429.90300@cisco.com> Date: Wed, 25 May 2005 12:13:29 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Simple] element issue for common policy References: <428C4F21.5030004@nokia.com> <42939BEC.9040508@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , Aki Niemi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org A question inline. Ted Hardie wrote: > that the automation of the disposition decision does the same job; I can > set up a process (note, not a *rule*) that moves things out of (pending) on > my behalf. That process can use whatever heuristics I describe and they > can be lots more granular or clever than the can be > (e.g. remove requests from (pending) when there are more than N requests > with the same username substring within Y seconds). That process > can also be me, the human, when I don't care to automate anything. I'm not sure I understand the difference between a process that moves things out of pending on my behalf, where presumably that process places them into "rejected" if they are from select domains, and a rule that works in the same way. Can you clarify? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple