From simple-bounces@ietf.org Fri Jun 03 15:56:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeIHS-0001QI-Ae; Fri, 03 Jun 2005 15:56:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeIHO-0001PZ-U4; Fri, 03 Jun 2005 15:56:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29405; Fri, 3 Jun 2005 15:56:29 -0400 (EDT) Message-Id: <200506031956.PAA29405@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 03 Jun 2005 15:56:29 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-cipid-04.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : CIPID: Contact Information in Presence Information Data Format Author(s) : H. Schulzrinne Filename : draft-ietf-simple-cipid-04.txt Pages : 10 Date : 2005-6-3 The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for Presence Information Data Format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-cipid-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-cipid-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-3162907.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-cipid-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-cipid-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-3162907.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Fri Jun 03 15:57:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeIHx-0001c5-E3; Fri, 03 Jun 2005 15:57:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeIHt-0001ao-Eg; Fri, 03 Jun 2005 15:57:01 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29540; Fri, 3 Jun 2005 15:56:59 -0400 (EDT) Message-Id: <200506031956.PAA29540@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 03 Jun 2005 15:56:59 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-rpid-06.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-simple-rpid-06.txt Pages : 37 Date : 2005-6-3 The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. That format defines a textual note, an indication of availability (open or closed) and a Universal Resource Identifier (URI) for communication. The Rich Presence Information Data Format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media might be private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers and the overall role of the presentity. These extensions include characteristics and status information for person, service (tuple) and devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-rpid-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-rpid-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-3162914.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-rpid-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-rpid-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-3162914.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Fri Jun 03 15:57:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeIIW-0001kX-W9; Fri, 03 Jun 2005 15:57:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeIIR-0001jk-FU; Fri, 03 Jun 2005 15:57:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29747; Fri, 3 Jun 2005 15:57:33 -0400 (EDT) Message-Id: <200506031957.PAA29747@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 03 Jun 2005 15:57:33 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-future-03.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Presence Information for Past and Future Time Intervals Author(s) : H. Schulzrinne Filename : draft-ietf-simple-future-03.txt Pages : 14 Date : 2005-6-3 The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The timed presence extension adds elements to PIDF that allow a presentity to declare their status for a time interval fully in the future or the past. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-future-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-future-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-future-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-3162923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-future-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-future-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-3162923.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Fri Jun 03 15:58:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeIIy-0001pO-OP; Fri, 03 Jun 2005 15:58:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeIIu-0001oV-2r; Fri, 03 Jun 2005 15:58:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29792; Fri, 3 Jun 2005 15:58:02 -0400 (EDT) Message-Id: <200506031958.PAA29792@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 03 Jun 2005 15:58:02 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-04.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : User Agent Capability Extension to Presence Information Data Format (PIDF) Author(s) : M. Lonnfors, K. Kiss Filename : draft-ietf-simple-prescaps-ext-04.txt Pages : 32 Date : 2005-6-3 Interoperation of instant messaging and presence systems has been defined in the IMPP working group. The IMPP WG has come up with baseline interoperable operations and formats for presence and instant messaging systems. This memo defines an extension to represent RFC3840 capabilities in the Presence Information Document Format (PIDF) compliant presence documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-prescaps-ext-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-prescaps-ext-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-3162929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-prescaps-ext-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-prescaps-ext-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-3162929.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 Sat Jun 04 10:23:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeZYj-0000mp-66; Sat, 04 Jun 2005 10:23:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeZYh-0000mk-CN for simple@megatron.ietf.org; Sat, 04 Jun 2005 10:23:31 -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 KAA05853 for ; Sat, 4 Jun 2005 10:23:27 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeZt6-0004mL-Fq for simple@ietf.org; Sat, 04 Jun 2005 10:44:37 -0400 Received: from [192.168.0.31] (pool-141-153-205-126.mad.east.verizon.net [141.153.205.126]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j54ENQp7020492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 4 Jun 2005 10:23:27 -0400 (EDT) Message-ID: <42A1B8FB.3010508@cs.columbia.edu> Date: Sat, 04 Jun 2005 10:21:47 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Simple] RPID, CIPID, timed-status drafts 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 posted new snapshots of the triad of rich presence drafts. You can find HTML versions at http://www.cs.columbia.edu/sip/draft/rpid/draft-ietf-simple-rpid-06.html http://www.cs.columbia.edu/sip/draft/cipid/draft-ietf-simple-cipid-04.html http://www.cs.columbia.edu/sip/draft/timed-status/draft-ietf-simple-future-03.html These are not final, but meant to encourage discussion and quick closure. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jun 05 09:17:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dev0Z-0004v0-Jw; Sun, 05 Jun 2005 09:17:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dev0X-0004ul-AV for simple@megatron.ietf.org; Sun, 05 Jun 2005 09:17: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 JAA05776 for ; Sun, 5 Jun 2005 09:17:37 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DevL8-0007Yd-Jl for simple@ietf.org; Sun, 05 Jun 2005 09:38:59 -0400 Received: from [192.168.0.31] (pool-141-153-205-126.mad.east.verizon.net [141.153.205.126]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j55DHZpH021632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 5 Jun 2005 09:17:36 -0400 (EDT) Message-ID: <42A2FB6C.3010201@cs.columbia.edu> Date: Sun, 05 Jun 2005 09:17:32 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Subject: [Simple] Timed presence 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 Timed status allows to indicate that presence information is valid at a time either in the future or the past. The current draft http://www.cs.columbia.edu/sip/draft/timed-status/draft-ietf-simple-future-03.html defines a new "wrapper" that allows to include any other presence information with a validity time range. Unfortunately, this is somewhat less than elegant: For example, rich presence (RPID) also has timing information (since/until) for many elements. The mechanism predates the data model work and there hasn't been a whole lot of discussion on how to make the two play nice with each other. Based on where PIDF can be extended, there appear to be three possible approaches: (1) One simple mechanism is to avoid use of timed-status for all new presence elements that are defined in RPID and elsewhere and only define a very narrowly scoped timed basic status that addresses that problem that PIDF doesn't have this information. In other words, open All other elements, where applicable, would just use the since/until notation. This also works for PIDF-LO, since it currently extends in PIDF. (2) Another solution, bumping up one level, is to associate time with , and to create a . (3) The highest-level solution is to have a timed-presence, as in existing tuple information This avoids having multiple activities with different time ranges, for example, within . My current inclination is to do (3), but I can see merits in all three approaches. I'd like to conclude this draft as soon as possible, so I'd appreciate feedback. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jun 05 23:29:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Df8Ia-0007AH-8j; Sun, 05 Jun 2005 23:29:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Df8IY-00078E-Ld for simple@megatron.ietf.org; Sun, 05 Jun 2005 23:29:10 -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 XAA25031 for ; Sun, 5 Jun 2005 23:29:08 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Df8dJ-0005bW-BN for simple@ietf.org; Sun, 05 Jun 2005 23:50:38 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Jun 2005 20:28:57 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j563Sqbw015417; Sun, 5 Jun 2005 20:28:52 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 5 Jun 2005 23:28:54 -0400 Received: from [192.168.1.100] ([10.86.240.139]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 5 Jun 2005 23:28:53 -0400 Message-ID: <42A3C2F3.1090703@cisco.com> Date: Sun, 05 Jun 2005 23:28:51 -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: Henning Schulzrinne Subject: Re: [Simple] Timed presence References: <42A2FB6C.3010201@cs.columbia.edu> In-Reply-To: <42A2FB6C.3010201@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2005 03:28:53.0904 (UTC) FILETIME=[DD5D7900:01C56A47] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: Simple 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 Henning Schulzrinne wrote: > Timed status allows to indicate that presence information is valid at a > time either in the future or the past. The current draft > > http://www.cs.columbia.edu/sip/draft/timed-status/draft-ietf-simple-future-03.html > > > defines a new "wrapper" that allows to include any other presence > information with a validity time range. Unfortunately, this is somewhat > less than elegant: For example, rich presence (RPID) also has timing > information (since/until) for many elements. Right, but thats not a new problem, nor has the data model work changed that. I believe that our reconciliation of these two was that timed-status ONLY dealt with predictive presence information; that is, information that describes the future. The since and until stuff used within other attributes defines current status, such that the since and until range has to encapsulate the current time. > Based on where PIDF can be extended, there appear to be three possible > approaches: > > (1) One simple mechanism is to avoid use of timed-status for all new > presence elements that are defined in RPID and elsewhere and only define > a very narrowly scoped timed basic status that addresses that problem > that PIDF doesn't have this information. In other words, > > > open > > > All other elements, where applicable, would just use the since/until > notation. This also works for PIDF-LO, since it currently extends > in PIDF. > > (2) Another solution, bumping up one level, is to associate time with > , and to create a . > > (3) The highest-level solution is to have a timed-presence, as in > > > > existing tuple information > > > > > > > > > > > This avoids having multiple activities with different time ranges, for > example, within . > > My current inclination is to do (3), but I can see merits in all three > approaches. There is a third, which is to extend the way timed-status currently works (whtin a tuple) to also work within a person or device: future-stuff future stuff -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 From simple-bounces@ietf.org Mon Jun 06 10:06:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfIEu-00053W-RO; Mon, 06 Jun 2005 10:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfIEs-00053O-IN for simple@megatron.ietf.org; Mon, 06 Jun 2005 10:06:02 -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 KAA02570 for ; Mon, 6 Jun 2005 10:06:00 -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 1DfIZj-0001bc-Jy for simple@ietf.org; Mon, 06 Jun 2005 10:27:36 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 06 Jun 2005 07:05:53 -0700 X-IronPort-AV: i="3.93,174,1115017200"; d="scan'208"; a="641285902:sNHT28973976" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j56E5ImC000035; Mon, 6 Jun 2005 07:05:44 -0700 (PDT) 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); Mon, 6 Jun 2005 10:05:41 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 10:05:41 -0400 Message-ID: <42A45834.50206@cisco.com> Date: Mon, 06 Jun 2005 10:05:40 -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: Jonathan Rosenberg Subject: Re: [Simple] Timed presence References: <42A2FB6C.3010201@cs.columbia.edu> <42A3C2F3.1090703@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2005 14:05:41.0212 (UTC) FILETIME=[D2B201C0:01C56AA0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Cc: Simple 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 Jonathan Rosenberg wrote: > > > Henning Schulzrinne wrote: > >> Timed status allows to indicate that presence information is valid at >> a time either in the future or the past. The current draft >> >> http://www.cs.columbia.edu/sip/draft/timed-status/draft-ietf-simple-future-03.html >> >> >> defines a new "wrapper" that allows to include any other presence >> information with a validity time range. Unfortunately, this is >> somewhat less than elegant: For example, rich presence (RPID) also has >> timing information (since/until) for many elements. > > > Right, but thats not a new problem, nor has the data model work changed > that. I believe that our reconciliation of these two was that > timed-status ONLY dealt with predictive presence information; that is, > information that describes the future. The since and until stuff used > within other attributes defines current status, such that the since and > until range has to encapsulate the current time. The current status, and 'since' information are both (hopefully) describing known facts. The timed-status when talking about the future, and 'until' are both predictions. Both suffer from the possibility of being incorrect. While I think it has been said that you shouldn't publish a timed-status with a range encompassing the current time, after it is published the current time can catch up with it. That has always been of some concern to me. But I guess it could simply be viewed as status of questionable accuracy that can be used in absence of something better. There is also the slippery slope here to including full calendaring info in presence, which IMO is more than we want. >> Based on where PIDF can be extended, there appear to be three possible >> approaches: >> >> (1) One simple mechanism is to avoid use of timed-status for all new >> presence elements that are defined in RPID and elsewhere and only >> define a very narrowly scoped timed basic status that addresses that >> problem that PIDF doesn't have this information. In other words, >> >> >> open >> >> >> All other elements, where applicable, would just use the since/until >> notation. This also works for PIDF-LO, since it currently extends >> in PIDF. Maybe. >> (2) Another solution, bumping up one level, is to associate time with >> , and to create a . I think this would just confuse things. >> (3) The highest-level solution is to have a timed-presence, as in >> >> >> >> existing tuple information >> >> >> >> >> >> >> >> >> >> >> This avoids having multiple activities with different time ranges, for >> example, within . While I can see some merit in this from the perspective of the watcher, I don't see how one would ever get the information to create this. How would the publishers of bits and pieces of presence info use this? My original reason for being interested in this was to cover the following scenario: - I have a multimedia device. (Say voice, video, IM.) - When I am not on a call, I am normally open with capabilities for all three media. (one tuple) - when I am on a call, that may diminish my availability for another call. Details are policy, but lets assume I can only take one voice and/or video call at a time, but can take up to 5 IM calls at a time. - I express my diminished availability by changing by current presence status. So when on a voice call I say I am still open, but only for IM. (Also indicating "on the phone".) - My expectation is that when the call is over I will go back to being available for all media. - a watcher that sees my status when I am on the phone can see that I am available for IM, but has no way to know that I also have voice and video capability, just not right now. So I wanted to use the old future-status to indicate that in the future I would be available for voice,video, and IM. The problem with this, of course, is that my phone, which is probably the one publishing presence, can't generally estimate when I wll be off the phone. So for this to work I would need a future-status/timed-status that doesn't say *when* in the future it will be true. Perhaps this is a problem that should be solved in some other way, but I had hoped that timed-status could be the solution. Its just a little more extreme case of the times in timed-status being predictions rather than truths. It could in fact be handled by setting the start time to the current time, on the assumption that the current call could end at any time. >> My current inclination is to do (3), but I can see merits in all three >> approaches. > > > There is a third, which is to extend the way timed-status currently > works (whtin a tuple) to also work within a person or device: > > > > > future-stuff > > > > > > future stuff > > > I generally agree with that. I also wonder if perhaps we ought to deprecate use of 'until' in regular status when the until value is a prediction rather than a certainty. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 06 10:11:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfIKC-00068e-2M; Mon, 06 Jun 2005 10:11:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfIKA-00067v-As for simple@megatron.ietf.org; Mon, 06 Jun 2005 10:11:30 -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 KAA03561 for ; Mon, 6 Jun 2005 10:11:28 -0400 (EDT) Received: from smtp1.clb.oleane.net ([213.56.31.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfIf0-0001n8-IZ for simple@ietf.org; Mon, 06 Jun 2005 10:33:04 -0400 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) (authenticated) by smtp1.clb.oleane.net with ESMTP id j56EBI5P029248 for ; Mon, 6 Jun 2005 16:11:19 +0200 Message-Id: <200506061411.j56EBI5P029248@smtp1.clb.oleane.net> From: "Chantal Ladouce" To: Date: Mon, 6 Jun 2005 16:11:13 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcVqoZZlANXwrHlzQ6OpT3zZrCp2RA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Subject: [Simple] WiMAX Summit - Paris - France - Call for proposals 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="===============0112268355==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0112268355== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C56AB2.5C68EB70" This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C56AB2.5C68EB70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The third edition of the WiMAX Summit, the most important European event dedicated to this technology, will stand in Paris next February 21-24, 2006. A call for proposals is online at: http://www.upperside.fr/wimax2006/wimax2006intro.htm The dead line for turning in abstracts is June 30. ------=_NextPart_000_0026_01C56AB2.5C68EB70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The third edition of the WiMAX Summit, the = most important European event dedicated to this technology, will stand in = Paris next = February 21-24, 2006.

A call for proposals is online = at:

http://www= .upperside.fr/wimax2006/wimax2006intro.htm

The dead line for turning in abstracts is June = 30.

 

 

------=_NextPart_000_0026_01C56AB2.5C68EB70-- --===============0112268355== 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 --===============0112268355==-- From simple-bounces@ietf.org Mon Jun 06 10:57:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfJ2G-0004SY-AC; Mon, 06 Jun 2005 10:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfJ2E-0004SQ-49 for simple@megatron.ietf.org; Mon, 06 Jun 2005 10:57:02 -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 KAA07801 for ; Mon, 6 Jun 2005 10:56:59 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfJN5-0002rk-T5 for simple@ietf.org; Mon, 06 Jun 2005 11:18:36 -0400 Received: from [193.208.138.36] (pc-n36.wlan.inet.fi [193.208.138.36]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j56EuvHN025232 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 6 Jun 2005 10:56:59 -0400 (EDT) In-Reply-To: <42A45834.50206@cisco.com> References: <42A2FB6C.3010201@cs.columbia.edu> <42A3C2F3.1090703@cisco.com> <42A45834.50206@cisco.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <141D8D40-1A2A-4CD2-B78F-9E9D53F871B4@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Simple] Timed presence Date: Mon, 6 Jun 2005 10:57:26 -0400 To: Paul Kyzivat X-Mailer: Apple Mail (2.728) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: Simple 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 > > There is also the slippery slope here to including full calendaring > info in presence, which IMO is more than we want. > I agree we don't want to use this draft as a calendar synchronization protocol. > >>> (3) The highest-level solution is to have a timed-presence, as in >>> >>> >>> >>> existing tuple information >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> This avoids having multiple activities with different time >>> ranges, for example, within . >>> > > While I can see some merit in this from the perspective of the > watcher, I don't see how one would ever get the information to > create this. How would the publishers of bits and pieces of > presence info use this? > > My original reason for being interested in this was to cover the > following scenario: > > - I have a multimedia device. (Say voice, video, IM.) > - When I am not on a call, I am normally open with capabilities for > all three media. (one tuple) > - when I am on a call, that may diminish my availability for > another call. Details are policy, but lets assume I can only > take one voice and/or video call at a time, but can take up to > 5 IM calls at a time. > - I express my diminished availability by changing by current > presence status. So when on a voice call I say I am still open, > but only for IM. (Also indicating "on the phone".) > - My expectation is that when the call is over I will go back to > being available for all media. > - a watcher that sees my status when I am on the phone can see > that I am available for IM, but has no way to know that I > also have voice and video capability, just not right now. > > So I wanted to use the old future-status to indicate that in the > future I would be available for voice,video, and IM. > > The problem with this, of course, is that my phone, which is > probably the one publishing presence, can't generally estimate when > I wll be off the phone. So for this to work I would need a future- > status/timed-status that doesn't say *when* in the future it will > be true. > > Perhaps this is a problem that should be solved in some other way, > but I had hoped that timed-status could be the solution. Its just a > little more extreme case of the times in timed-status being > predictions rather than truths. It could in fact be handled by > setting the start time to the current time, on the assumption that > the current call could end at any time. > I'm not sure this is a good fit. The model you're describing is more of a "idle" presence, i.e., you'll never have more media than a set, but may have less if you are using one or more of those resources. I suspect that in practice, you'll get something akin to the "5 minute" convention, i.e., "I'm on another call right now, talk to me in 5 minutes" or the "minute convention" ("I'll be with you in a minute"). There is no assumption that this is actually going to be precisely 300 seconds or 60 seconds. See also http://www.worldwidewords.org/qa/qa-new1.htm _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 06 11:42:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfJjq-0002cl-3i; Mon, 06 Jun 2005 11:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfJjm-0002cW-TF for simple@megatron.ietf.org; Mon, 06 Jun 2005 11:42:04 -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 LAA11662 for ; Mon, 6 Jun 2005 11:42:00 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfK4e-0003uH-0O for simple@ietf.org; Mon, 06 Jun 2005 12:03:37 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 06 Jun 2005 11:41:53 -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 j56FfG5Q019085; Mon, 6 Jun 2005 11:41:49 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 11:41:49 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 11:41:49 -0400 Message-ID: <42A46EBC.8020701@cisco.com> Date: Mon, 06 Jun 2005 11:41:48 -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: Henning Schulzrinne Subject: Re: [Simple] Timed presence References: <42A2FB6C.3010201@cs.columbia.edu> <42A3C2F3.1090703@cisco.com> <42A45834.50206@cisco.com> <141D8D40-1A2A-4CD2-B78F-9E9D53F871B4@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2005 15:41:49.0260 (UTC) FILETIME=[40B848C0:01C56AAE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: Simple 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 Henning Schulzrinne wrote: >> >> There is also the slippery slope here to including full calendaring >> info in presence, which IMO is more than we want. >> > > I agree we don't want to use this draft as a calendar synchronization > protocol. > >> >>>> (3) The highest-level solution is to have a timed-presence, as in >>>> >>>> >>>> >>>> existing tuple information >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> This avoids having multiple activities with different time ranges, >>>> for example, within . >>>> >> >> While I can see some merit in this from the perspective of the >> watcher, I don't see how one would ever get the information to create >> this. How would the publishers of bits and pieces of presence info >> use this? >> >> My original reason for being interested in this was to cover the >> following scenario: >> >> - I have a multimedia device. (Say voice, video, IM.) >> - When I am not on a call, I am normally open with capabilities for >> all three media. (one tuple) >> - when I am on a call, that may diminish my availability for >> another call. Details are policy, but lets assume I can only >> take one voice and/or video call at a time, but can take up to >> 5 IM calls at a time. >> - I express my diminished availability by changing by current >> presence status. So when on a voice call I say I am still open, >> but only for IM. (Also indicating "on the phone".) >> - My expectation is that when the call is over I will go back to >> being available for all media. >> - a watcher that sees my status when I am on the phone can see >> that I am available for IM, but has no way to know that I >> also have voice and video capability, just not right now. >> >> So I wanted to use the old future-status to indicate that in the >> future I would be available for voice,video, and IM. >> >> The problem with this, of course, is that my phone, which is probably >> the one publishing presence, can't generally estimate when I wll be >> off the phone. So for this to work I would need a future- >> status/timed-status that doesn't say *when* in the future it will be >> true. >> >> Perhaps this is a problem that should be solved in some other way, >> but I had hoped that timed-status could be the solution. Its just a >> little more extreme case of the times in timed-status being >> predictions rather than truths. It could in fact be handled by >> setting the start time to the current time, on the assumption that >> the current call could end at any time. >> > > I'm not sure this is a good fit. The model you're describing is more of > a "idle" presence, i.e., you'll never have more media than a set, but > may have less if you are using one or more of those resources. > > I suspect that in practice, you'll get something akin to the "5 minute" > convention, i.e., "I'm on another call right now, talk to me in 5 > minutes" or the "minute convention" ("I'll be with you in a minute"). > There is no assumption that this is actually going to be precisely 300 > seconds or 60 seconds. If its not a good fit, do you have a suggestion for something that is a better fit? I think timed-status is a reasonable fit precisely because the future times are generally just estimates anyway and shouldn't be taken too literally. An alternative I floated once (which didn't seem to get traction) was to permit prescaps both directly below and and also below . The value in status would be the "current" value while the one higher up would be the "default" value. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 06 12:29:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfKTU-0008Vm-1o; Mon, 06 Jun 2005 12:29:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfKTT-0008Vh-ES for simple@megatron.ietf.org; Mon, 06 Jun 2005 12:29:15 -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 MAA14659 for ; Mon, 6 Jun 2005 12:29:12 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfKoL-0004qX-7k for simple@ietf.org; Mon, 06 Jun 2005 12:50:50 -0400 Received: from [193.208.138.36] (pc-n36.wlan.inet.fi [193.208.138.36]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j56GS31c001547 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 6 Jun 2005 12:28:04 -0400 (EDT) In-Reply-To: <42A46EBC.8020701@cisco.com> References: <42A2FB6C.3010201@cs.columbia.edu> <42A3C2F3.1090703@cisco.com> <42A45834.50206@cisco.com> <141D8D40-1A2A-4CD2-B78F-9E9D53F871B4@cs.columbia.edu> <42A46EBC.8020701@cisco.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2068401D-D392-490D-AFCC-2F58026BAB47@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Simple] Timed presence Date: Mon, 6 Jun 2005 12:28:29 -0400 To: Paul Kyzivat X-Mailer: Apple Mail (2.728) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Simple 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 > > If its not a good fit, do you have a suggestion for something that > is a better fit? > > I think timed-status is a reasonable fit precisely because the > future times are generally just estimates anyway and shouldn't be > taken too literally. > I agree - while the fit isn't perfect, it's the closest we have and there doesn't seem to be much point in defining a separate, overlapping mechanism. > An alternative I floated once (which didn't seem to get traction) > was to permit prescaps both directly below and and > also below . The value in status would be the "current" > value while the one higher up would be the "default" value. > The hard part is defining what "default" means and what a user would do with this without any time indication. At least, with the timed- status, for some cases, such as scheduled calls, you can provide a pretty good estimate. Even for your phone call case, since the likelihood that calls exceed 10 minutes is small, providing a ten- minute estimate seems good enough. Presumably, after 10 minutes, you'd look again and check if the status has changed. Teenagers could presumably increase that interval. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 06 13:49:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLil-0001Wn-20; Mon, 06 Jun 2005 13:49:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLij-0001Wi-W7 for simple@megatron.ietf.org; Mon, 06 Jun 2005 13:49:06 -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 NAA21823 for ; Mon, 6 Jun 2005 13:49:04 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfM3a-0006tu-Mw for simple@ietf.org; Mon, 06 Jun 2005 14:10:41 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 06 Jun 2005 13:48:55 -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 j56Hlt5W000960 for ; Mon, 6 Jun 2005 13:48:52 -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); Mon, 6 Jun 2005 13:47:34 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 13:47:34 -0400 Message-ID: <42A48C36.5000907@cisco.com> Date: Mon, 06 Jun 2005 13:47:34 -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: simple@ietf.org References: <200506031958.PAA29792@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2005 17:47:34.0372 (UTC) FILETIME=[D1F50240:01C56ABF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Subject: [Simple] Re:draft-ietf-simple-prescaps-ext-04.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I just took a look at this again. I have a few suggestions. Thanks for continuing to push this, Paul > 3.2 Service capability document > > Elements belonging to this document are used to describe > characteristics of a service. All elements defined in this section > describe static data about the service. ^^^^^^ Why is this described as static data? Capabilities can change for a variety of reasons: - a capability may be enabled or disabled by the user. E.g. a phone may potentially have video capabilities, but the user may have disabled them because he does not want to be seen. - the resources needed to support the capability may be temporarily unavailable. E.g. a softphone may be temporarily unavailable for audio because another application on the device has taken control of the audio components of the device. - a capability may be temporarily unavailable because the service has the necessary resources committed to other calls that it is processing. I believe all of these to be valid reasons to change the set of capabilities that are published. I suggest that the 2nd sentence of section 3.2 be removed. > 3.2.11 element > > The element indicates the setting, business or personal, in > which a communications service is used as defined in RFC3840 [6]. > > The element can contain two elements: and > . All classes that are supported by the service are > listed under element and all classes that are not > supported by the service are listed under element. > > and elements can contain and > elements followed by any number of optional extension > elements from other namespaces. The semantics of business and > personal are defined in RFC3840 [6] as: > > o : The service is used for business communications. > > o : The service is used for personal communications. > > Any value that is register to IANA to SIP Media Feature Tag > Registration Tree as sip.class media feature tag can be used as a > value of an extension element. If appropriate value is not > registered it SHOULD be registed as defined in RFC3840 [6]. The above confuses me. Suppose another value (e.g. 'charity') were added to the sip.class feature tag registration. How does a new element get defined? Similar comment for 3.2.12, 3.2.14, 3.2.16, 3.2.17, 3.2.19, 3.3.2. The problem is that someone can go through the iana process for adding a new feature tag value and then it can be used in sip callee caps. But to use it in a presence document you will need to define an xml element to represent it. There will be no mechanism to trace which extension xml element goes with a particular new feature tag value. Two people could define independent xml extensions for the same value. This could be solved by making the iana registry for feature tags cross reference an xml element definition. But that doesn't seem feasible. I think I prefer the approach you have taken for schemes and languages. > 3.2.15.1 element > > The element has a single attribute called "maxvalue". The ^^^^^ s/// > 3.3.3 element This is essentially the same as 3.2.15. The schema only defines it once, but that isn't clear from this description. I think it might be sufficient to cross reference 3.2.15 from this section. > 5. Examples ... > > Example service > ^^^^^^^^^^^^^ The above seems to be the result of some kind of editing error. > > > > minOccurs="0"/> > minOccurs="0"/> > > My knowledge of xml is very limited, but I believe to get the equivalent to what is in callee caps, supported and unsupported each need maxOccurs="unbounded". _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 06 15:32:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfNKx-0005fi-43; Mon, 06 Jun 2005 15:32:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfNKr-0005fY-0q for simple@megatron.ietf.org; Mon, 06 Jun 2005 15:32:37 -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 PAA01987 for ; Mon, 6 Jun 2005 15:32:31 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfNfk-00018A-5q for simple@ietf.org; Mon, 06 Jun 2005 15:54:09 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jun 2005 12:32:21 -0700 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jun 2005 12:32:21 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Timed presence Date: Mon, 6 Jun 2005 12:32:20 -0700 Message-ID: <1BEC4DA05ABCD34FACFCFC82086AC247064E0C26@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: [Simple] Timed presence Thread-Index: AcVqqFM3gbPjcO3ORHaNTfeUHthEvQAJZ5/A From: "Tim Rang" To: "Henning Schulzrinne" , "Paul Kyzivat" X-OriginalArrivalTime: 06 Jun 2005 19:32:21.0245 (UTC) FILETIME=[7539B2D0:01C56ACE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable Cc: Simple 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 I disagree. I see very few practical applications of future presence, and calendar info is one of them. As Paul stated, it's difficult to provide a reasonable estimate of when a presence transition will occur in general. The most reliable way to do so is to predict based on previously scheduled activities, meetings, out of office time, etc, all of which are generally captured in a person's calendar. I'd stop short of calling for calendar synchronization, but it seems to me to be one of the primary sources of future presence. Tim Rang -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, June 06, 2005 7:57 AM To: Paul Kyzivat Cc: Simple WG Subject: Re: [Simple] Timed presence > > There is also the slippery slope here to including full calendaring =20 > info in presence, which IMO is more than we want. > I agree we don't want to use this draft as a calendar synchronization =20 protocol. > >>> (3) The highest-level solution is to have a timed-presence, as in >>> >>> >>> >>> existing tuple information >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> This avoids having multiple activities with different time =20 >>> ranges, for example, within . >>> > > While I can see some merit in this from the perspective of the =20 > watcher, I don't see how one would ever get the information to =20 > create this. How would the publishers of bits and pieces of =20 > presence info use this? > > My original reason for being interested in this was to cover the =20 > following scenario: > > - I have a multimedia device. (Say voice, video, IM.) > - When I am not on a call, I am normally open with capabilities for > all three media. (one tuple) > - when I am on a call, that may diminish my availability for > another call. Details are policy, but lets assume I can only > take one voice and/or video call at a time, but can take up to > 5 IM calls at a time. > - I express my diminished availability by changing by current > presence status. So when on a voice call I say I am still open, > but only for IM. (Also indicating "on the phone".) > - My expectation is that when the call is over I will go back to > being available for all media. > - a watcher that sees my status when I am on the phone can see > that I am available for IM, but has no way to know that I > also have voice and video capability, just not right now. > > So I wanted to use the old future-status to indicate that in the =20 > future I would be available for voice,video, and IM. > > The problem with this, of course, is that my phone, which is =20 > probably the one publishing presence, can't generally estimate when =20 > I wll be off the phone. So for this to work I would need a future-=20 > status/timed-status that doesn't say *when* in the future it will =20 > be true. > > Perhaps this is a problem that should be solved in some other way, =20 > but I had hoped that timed-status could be the solution. Its just a =20 > little more extreme case of the times in timed-status being =20 > predictions rather than truths. It could in fact be handled by =20 > setting the start time to the current time, on the assumption that =20 > the current call could end at any time. > I'm not sure this is a good fit. The model you're describing is more =20 of a "idle" presence, i.e., you'll never have more media than a set, =20 but may have less if you are using one or more of those resources. I suspect that in practice, you'll get something akin to the "5 =20 minute" convention, i.e., "I'm on another call right now, talk to me =20 in 5 minutes" or the "minute convention" ("I'll be with you in a =20 minute"). There is no assumption that this is actually going to be =20 precisely 300 seconds or 60 seconds. See also http://www.worldwidewords.org/qa/qa-new1.htm _______________________________________________ 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 Jun 06 15:43:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfNVq-00076t-Cv; Mon, 06 Jun 2005 15:43:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfNVm-00076C-J1 for simple@megatron.ietf.org; Mon, 06 Jun 2005 15:43: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 PAA02806 for ; Mon, 6 Jun 2005 15:43:48 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfNqe-0001V4-1P for simple@ietf.org; Mon, 06 Jun 2005 16:05:27 -0400 Received: from [193.208.138.36] (pc-n36.wlan.inet.fi [193.208.138.36]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j56JgWSk014812 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 6 Jun 2005 15:42:34 -0400 (EDT) In-Reply-To: <1BEC4DA05ABCD34FACFCFC82086AC247064E0C26@RED-MSG-43.redmond.corp.microsoft.com> References: <1BEC4DA05ABCD34FACFCFC82086AC247064E0C26@RED-MSG-43.redmond.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D1EE349-F96A-44D9-AFED-60001C2B7D7E@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Simple] Timed presence Date: Mon, 6 Jun 2005 15:43:01 -0400 To: "Tim Rang" X-Mailer: Apple Mail (2.728) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , Simple 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 I don't think we're disagreeing :-) I think we both agree that calendars are the primary source of this type of information. When I said calendar synchronization protocol, I meant a protocol that would allow two iCal instances to stay in sync, e.g., to sync a PDA and Outlook. I don't think timed presence can (or should) do that job. On Jun 6, 2005, at 3:32 PM, Tim Rang wrote: > I disagree. I see very few practical applications of future presence, > and calendar info is one of them. As Paul stated, it's difficult to > provide a reasonable estimate of when a presence transition will occur > in general. The most reliable way to do so is to predict based on > previously scheduled activities, meetings, out of office time, etc, > all > of which are generally captured in a person's calendar. > > I'd stop short of calling for calendar synchronization, but it > seems to > me to be one of the primary sources of future presence. > > Tim Rang > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 07 04:50:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfZmi-00077z-8f; Tue, 07 Jun 2005 04:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfZmg-00077u-NR for simple@megatron.ietf.org; Tue, 07 Jun 2005 04:50:06 -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 EAA01226 for ; Tue, 7 Jun 2005 04:50:04 -0400 (EDT) Received: from [82.196.203.119] (helo=office-owa-01.HQ.TELIO.NO) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfa7g-0005LT-F1 for simple@ietf.org; Tue, 07 Jun 2005 05:11:49 -0400 Received: from [192.168.1.53] ([192.168.1.53]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Jun 2005 10:52:38 +0200 In-Reply-To: <42A45834.50206@cisco.com> References: <42A2FB6C.3010201@cs.columbia.edu> <42A3C2F3.1090703@cisco.com> <42A45834.50206@cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Timed presence Date: Tue, 7 Jun 2005 10:49:47 +0200 To: Paul Kyzivat X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 07 Jun 2005 08:52:38.0316 (UTC) FILETIME=[41A146C0:01C56B3E] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: Simple 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 Jun 6, 2005, at 4:05 PM, Paul Kyzivat wrote: > > > Jonathan Rosenberg wrote: >> Henning Schulzrinne wrote: >>> Timed status allows to indicate that presence information is valid >>> at a time either in the future or the past. The current draft >>> >>> http://www.cs.columbia.edu/sip/draft/timed-status/draft-ietf-simple- >>> future-03.html >>> >>> defines a new "wrapper" that allows to include any other presence >>> information with a validity time range. Unfortunately, this is >>> somewhat less than elegant: For example, rich presence (RPID) also >>> has timing information (since/until) for many elements. >> Right, but thats not a new problem, nor has the data model work >> changed that. I believe that our reconciliation of these two was that >> timed-status ONLY dealt with predictive presence information; that >> is, information that describes the future. The since and until stuff >> used within other attributes defines current status, such that the >> since and until range has to encapsulate the current time. > > The current status, and 'since' information are both (hopefully) > describing known facts. > > The timed-status when talking about the future, and 'until' are both > predictions. Both suffer from the possibility of being incorrect. > > While I think it has been said that you shouldn't publish a > timed-status with a range encompassing the current time, after it is > published the current time can catch up with it. That has always been > of some concern to me. But I guess it could simply be viewed as status > of questionable accuracy that can be used in absence of something > better. > This is where composition policy would kick in. A compositor may simply throw this out if the time has arrived. or? Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 07 05:54:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfanF-00089D-4m; Tue, 07 Jun 2005 05:54:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfanD-000898-OY for simple@megatron.ietf.org; Tue, 07 Jun 2005 05:54:43 -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 FAA05497 for ; Tue, 7 Jun 2005 05:54:39 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfb8C-0006ZH-Og for simple@ietf.org; Tue, 07 Jun 2005 06:16:25 -0400 Received: from [193.234.219.175] (w175.nomadiclab.com [193.234.219.175]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j579sbhe005380 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 7 Jun 2005 05:54:38 -0400 (EDT) In-Reply-To: References: <42A2FB6C.3010201@cs.columbia.edu> <42A3C2F3.1090703@cisco.com> <42A45834.50206@cisco.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9759C71E-6ED4-419A-8BE8-328F40696BAA@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Simple] Timed presence Date: Tue, 7 Jun 2005 05:55:06 -0400 To: Hisham Khartabil X-Mailer: Apple Mail (2.728) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , Simple 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 > This is where composition policy would kick in. A compositor may > simply throw this out if the time has arrived. or? > Depends. If the NOTIFY arrives at 3.30 pm and the future time is 4 pm, the compositor would have to realize at 4 pm that it needs to update the status even though nothing else might have changed (no additional PUBLISH have arrived). My mental model of a compositor was reactive, i.e., it would never create new event notifications, just create one when a new external (PUBLISH) event triggered this. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 07 08:07:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfcry-0006MB-KM; Tue, 07 Jun 2005 08:07:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfcrx-0006K3-4M for simple@megatron.ietf.org; Tue, 07 Jun 2005 08:07: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 IAA16658 for ; Tue, 7 Jun 2005 08:07:43 -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 1DfdCx-0001Ea-RK for simple@ietf.org; Tue, 07 Jun 2005 08:29:30 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2005 05:07:33 -0700 X-IronPort-AV: i="3.93,178,1115017200"; d="scan'208"; a="275328963:sNHT29047480" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j57C7Plw028319; Tue, 7 Jun 2005 05:07:26 -0700 (PDT) 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, 7 Jun 2005 08:07:30 -0400 Received: from cisco.com ([10.86.240.37]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Jun 2005 08:07:29 -0400 Message-ID: <42A58E01.7090705@cisco.com> Date: Tue, 07 Jun 2005 08:07:29 -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: Henning Schulzrinne Subject: Re: [Simple] Timed presence References: <42A2FB6C.3010201@cs.columbia.edu> <42A3C2F3.1090703@cisco.com> <42A45834.50206@cisco.com> <9759C71E-6ED4-419A-8BE8-328F40696BAA@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2005 12:07:29.0786 (UTC) FILETIME=[7A4A05A0:01C56B59] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Simple 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 Henning Schulzrinne wrote: >> This is where composition policy would kick in. A compositor may >> simply throw this out if the time has arrived. or? >> > > Depends. If the NOTIFY arrives at 3.30 pm and the future time is 4 pm, > the compositor would have to realize at 4 pm that it needs to update > the status even though nothing else might have changed (no additional > PUBLISH have arrived). My mental model of a compositor was reactive, > i.e., it would never create new event notifications, just create one > when a new external (PUBLISH) event triggered this. My mental model is that composition can be done by either the presence server or the watcher, or both. When it is done by the presence server it can embody policy decisions specified by the presentity. It may be necessary for the presence server to do it to obscure detail that it doesn't want to disclose. Otherwise the choice of where it is done is merely a matter of convenience and optimization. In this case, at 4pm it may be necessary to reconsider what status to display. This reconsideration can be done by the watcher if the raw status was made available to it. If the composer in the presence server had hidden this than it may need to do the reconsideration. But, if the current status had been "on the phone" and closed, while the future status is available and open, then at 4pm I would be inclined to consider the status to remain the same. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 07 13:21:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfhl7-0007bv-3e; Tue, 07 Jun 2005 13:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfhl2-0007Zv-4d for simple@megatron.ietf.org; Tue, 07 Jun 2005 13:21:00 -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 NAA12775 for ; Tue, 7 Jun 2005 13:20:53 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfi66-0008SJ-OY for simple@ietf.org; Tue, 07 Jun 2005 13:42:44 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j57HKfCK015247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Jun 2005 10:20:42 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-16-131.qualcomm.com [10.50.16.131]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j57HKcNv012121; Tue, 7 Jun 2005 10:20:39 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4294A429.90300@cisco.com> References: <428C4F21.5030004@nokia.com> <42939BEC.9040508@cisco.com> <4294A429.90300@cisco.com> Date: Tue, 7 Jun 2005 10:20:36 -0700 To: Jonathan Rosenberg 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: d8ae4fd88fcaf47c1a71c804d04f413d 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 Hi Jonathan, For some bizarre reason, both copies of this just now turned up in my mail box; I apologize for the long delay in replying. If there are other messages you have out to me for which you're expecting a reply, please re-send. At 12:13 PM -0400 5/25/05, Jonathan Rosenberg wrote: >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. There are a couple of things that I was trying to get at here. One of the issues that drove geopriv to the additive permissions only point of view was that you didn't necessarily know what order permissions would be granted in (especially where some are incorporated from external sources). That means the processing model for an additive/subtractive model requires all of the rules to be present and somehow sorted correctly to get to the intended state. If you can't resolve an external reference in that case you either get nothing (because you're very conservative) or you reveal to much (because you're insufficiently paranoid). In going to an additive permissions model, you know that whatever permissions have been granted up to a specific point are intended and that you are being at least as conservative as was intended. You also are free to process the directives in any order. Except clauses that are clearly tied to specific directives are better than all-out negative permissions, but they can remain problematic in their interaction with user expectations. If I say "Grant anyone access to my timezone, except Hisham" and also say "Grant any wg chair in APPs access to my full location", Hisham will get my time zone--but this may not be what a user expects, especially if the user expectation is driven by a sense of "override" and wrote the "except Hisham" after the first rule was in place. For a process model, all of the additive rules are done first before a process kicks in--this means that you can guarantee an evaluation order-- all the rules and then later the processes (which I should probably call something other than "process"). Personally, I think that helps, especially if the rules are constructed so as to put those which require post-rule evaluation into what are essentially pending states (as this leaves the "you are being at least as conservative as intended" in place). A human can do the post-rule evaluation, or it can be done by a process/agent/heuristic engine of whatever complexity is appropriate. That's the other main point--I believe that the "grant any, except domain" is so close to useless that it is not worth it; it is trivially easy to mint identities that escape this clause. To get to something that actually successfully excluded someone here, I think you'd eventually need something of close to arbitrary complexity, and that this does not belong in the rules language "Anyone may know my timezone except those whose identities are associated with domains that have been recently minted, are in this list, or were paid for by credit cards traceable to "Hisham Khartabil" or were paid for in ways that are not traceable." *might* succeed in keeping Hisham from knowing what timezone I'm in. But even then, he has only to get a friend to loan him a cc to get past it. regards, Ted _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 09 09:29:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgN67-00067S-O7; Thu, 09 Jun 2005 09:29:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgN66-00067K-21 for simple@megatron.ietf.org; Thu, 09 Jun 2005 09:29:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29256 for ; Thu, 9 Jun 2005 09:29:24 -0400 (EDT) Received: from royk.itea.ntnu.no ([129.241.190.230]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgNRZ-00037B-32 for simple@ietf.org; Thu, 09 Jun 2005 09:51:37 -0400 Received: from localhost (localhost [127.0.0.1]) by royk.itea.ntnu.no (Postfix) with ESMTP id 0590266C9C for ; Thu, 9 Jun 2005 15:29:24 +0200 (CEST) Received: from [129.241.222.31] (vpn-22231.vpn-s.ntnu.no [129.241.222.31]) by royk.itea.ntnu.no (Postfix) with ESMTP for ; Thu, 9 Jun 2005 15:29:23 +0200 (CEST) Message-ID: <42A84436.3030009@stud.ntnu.no> Date: Thu, 09 Jun 2005 15:29:26 +0200 From: =?ISO-8859-1?Q?Egil_=D8sthus?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Subject: [Simple] SIP, SIMPLE and general context information X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: egilconr@gmail.com 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, I'm looking into ways to distribute general context information, and=20 have some questions connected to SIMPLE. SIMPLE is used to transport presence information to a watcher. In the=20 introduction of RFC 3856 it is argued why SIP Events is an appropriate=20 way to distribute presence information. I agree in the arguments given=20 in the RFC, but there are some details that still is not clear to me.=20 Presence status is a special kind of the more general Context=20 Information. What I'm uncertain about, is whether SIMPLE should be used=20 for distribution of other kinds of context information as well?=20 Arguments that support this approach is that it is convenient to have=20 only one protocol taking care of distributing all sorts of context=20 information (e.g. Temperature, Light level, geographical location and so=20 on). Also, the arguements given why SIMPLE is a proper protocol for=20 presence info distribution goes for many of the other kinds of context=20 information. Technically speaking, it is not any problem using SIMPLE=20 for this matter, what I belive is the problem is that this approach is=20 in conflict with the "Guidelines for Authors of Extensions to the=20 Session Initiation Protocol (SIP)" internet draft=20 (http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-09.txt).=20 Section 3.1 defines SIPs solution space, and I have a hard time=20 convincing myself that distribution of general context information is=20 within the solution space of SIP, in other words SIP is not an=20 appropriate protocol. Then again, it seems kind of strange to me to=20 define one protocol per each kind of context information type. (e.g. one=20 for geographical location, one for temperature and so on). Should SIP=20 Events (like SIMPLE) be used to distribute all kinds of context=20 information (i.e. breaking the sip guidelines draft)? Should presence be=20 distributed by SIMPLE, and other kinds of context information=20 distributed by other protocols, i.e. creating a great number of context=20 distribution protocols? Or should a general protocol for context=20 information be designed, taking care of all sorts of context=20 information, i.e.dropping SIMPLE? Any comments helping to clarify this matter is highly appreciated! Cheers, Egil C. =D8sthus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 09 10:12:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgNld-0008FO-Gb; Thu, 09 Jun 2005 10:12:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgNlb-0008FJ-9V for simple@megatron.ietf.org; Thu, 09 Jun 2005 10:12:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04352 for ; Thu, 9 Jun 2005 10:12:17 -0400 (EDT) Received: from [82.196.203.119] (helo=office-owa-01.HQ.TELIO.NO) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgO72-0005Ab-Kc for simple@ietf.org; Thu, 09 Jun 2005 10:34:31 -0400 Received: from [192.168.1.64] ([192.168.1.64]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jun 2005 16:14:56 +0200 In-Reply-To: <42A84436.3030009@stud.ntnu.no> References: <42A84436.3030009@stud.ntnu.no> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <309b3e317bf68022f04bf8f04c3cf977@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] SIP, SIMPLE and general context information Date: Thu, 9 Jun 2005 16:11:58 +0200 To: egilconr@gmail.com X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 09 Jun 2005 14:14:56.0941 (UTC) FILETIME=[9D2CC5D0:01C56CFD] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 Egil, RFC 3856 is an event package built from the SIP Event Notification =20 Framework (RFC3265). Please take a look at that RFC and see if it =20 suites your needs. Note that this framework is not SIMPLE specific, it =20= is a SIP extension. Regards, Hisham On Jun 9, 2005, at 3:29 PM, Egil =D8sthus wrote: > Hi, > > I'm looking into ways to distribute general context information, and =20= > have some questions connected to SIMPLE. > > SIMPLE is used to transport presence information to a watcher. In the =20= > introduction of RFC 3856 it is argued why SIP Events is an appropriate = =20 > way to distribute presence information. I agree in the arguments given = =20 > in the RFC, but there are some details that still is not clear to me. =20= > Presence status is a special kind of the more general Context =20 > Information. What I'm uncertain about, is whether SIMPLE should be =20 > used for distribution of other kinds of context information as well? =20= > Arguments that support this approach is that it is convenient to have =20= > only one protocol taking care of distributing all sorts of context =20 > information (e.g. Temperature, Light level, geographical location and =20= > so on). Also, the arguements given why SIMPLE is a proper protocol for = =20 > presence info distribution goes for many of the other kinds of context = =20 > information. Technically speaking, it is not any problem using SIMPLE =20= > for this matter, what I belive is the problem is that this approach is = =20 > in conflict with the "Guidelines for Authors of Extensions to the =20 > Session Initiation Protocol (SIP)" internet draft =20 > (http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines=20 > -09.txt). Section 3.1 defines SIPs solution space, and I have a hard =20= > time convincing myself that distribution of general context =20 > information is within the solution space of SIP, in other words SIP is = =20 > not an appropriate protocol. Then again, it seems kind of strange to =20= > me to define one protocol per each kind of context information type. =20= > (e.g. one for geographical location, one for temperature and so on). =20= > Should SIP Events (like SIMPLE) be used to distribute all kinds of =20= > context information (i.e. breaking the sip guidelines draft)? Should =20= > presence be distributed by SIMPLE, and other kinds of context =20 > information distributed by other protocols, i.e. creating a great =20 > number of context distribution protocols? Or should a general protocol = =20 > for context information be designed, taking care of all sorts of =20 > context information, i.e.dropping SIMPLE? > > Any comments helping to clarify this matter is highly appreciated! > > Cheers, > Egil C. =D8sthus > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 09 10:29:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgO2K-0004oa-TX; Thu, 09 Jun 2005 10:29:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgO2I-0004oU-Lf for simple@megatron.ietf.org; Thu, 09 Jun 2005 10:29:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06619 for ; Thu, 9 Jun 2005 10:29:32 -0400 (EDT) Received: from royk.itea.ntnu.no ([129.241.190.230]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgONm-0006Q6-4q for simple@ietf.org; Thu, 09 Jun 2005 10:51:46 -0400 Received: from localhost (localhost [127.0.0.1]) by royk.itea.ntnu.no (Postfix) with ESMTP id 2EC9367099; Thu, 9 Jun 2005 16:29:27 +0200 (CEST) Received: from [129.241.222.31] (vpn-22231.vpn-s.ntnu.no [129.241.222.31]) by royk.itea.ntnu.no (Postfix) with ESMTP; Thu, 9 Jun 2005 16:29:25 +0200 (CEST) Message-ID: <42A85248.5010808@stud.ntnu.no> Date: Thu, 09 Jun 2005 16:29:28 +0200 From: =?ISO-8859-1?Q?Egil_=D8sthus?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] SIP, SIMPLE and general context information References: <42A84436.3030009@stud.ntnu.no> <309b3e317bf68022f04bf8f04c3cf977@telio.no> In-Reply-To: <309b3e317bf68022f04bf8f04c3cf977@telio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: egilconr@gmail.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: egilconr@gmail.com 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, I'm aware that SIMPLE is build upon the SIP Event Notification Framework=20 (RFC3265). I still belive that my arguments apply though, but I realize=20 that my questions partly is related to SIP itself, as well as SIMPLE. Cheers Egil Hisham Khartabil wrote: > Egil, > > RFC 3856 is an event package built from the SIP Event Notification =20 > Framework (RFC3265). Please take a look at that RFC and see if it =20 > suites your needs. Note that this framework is not SIMPLE specific,=20 > it is a SIP extension. > > Regards, > Hisham > > On Jun 9, 2005, at 3:29 PM, Egil =D8sthus wrote: > >> Hi, >> >> I'm looking into ways to distribute general context information, and =20 >> have some questions connected to SIMPLE. >> >> SIMPLE is used to transport presence information to a watcher. In=20 >> the introduction of RFC 3856 it is argued why SIP Events is an=20 >> appropriate way to distribute presence information. I agree in the=20 >> arguments given in the RFC, but there are some details that still is=20 >> not clear to me. Presence status is a special kind of the more=20 >> general Context Information. What I'm uncertain about, is whether=20 >> SIMPLE should be used for distribution of other kinds of context=20 >> information as well? Arguments that support this approach is that it=20 >> is convenient to have only one protocol taking care of distributing=20 >> all sorts of context information (e.g. Temperature, Light level,=20 >> geographical location and so on). Also, the arguements given why=20 >> SIMPLE is a proper protocol for presence info distribution goes for=20 >> many of the other kinds of context information. Technically=20 >> speaking, it is not any problem using SIMPLE for this matter, what I=20 >> belive is the problem is that this approach is in conflict with the=20 >> "Guidelines for Authors of Extensions to the Session Initiation=20 >> Protocol (SIP)" internet draft =20 >> (http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines=20 >> -09.txt). Section 3.1 defines SIPs solution space, and I have a hard =20 >> time convincing myself that distribution of general context =20 >> information is within the solution space of SIP, in other words SIP=20 >> is not an appropriate protocol. Then again, it seems kind of strange=20 >> to me to define one protocol per each kind of context information=20 >> type. (e.g. one for geographical location, one for temperature and=20 >> so on). Should SIP Events (like SIMPLE) be used to distribute all=20 >> kinds of context information (i.e. breaking the sip guidelines=20 >> draft)? Should presence be distributed by SIMPLE, and other kinds of=20 >> context information distributed by other protocols, i.e. creating a=20 >> great number of context distribution protocols? Or should a general=20 >> protocol for context information be designed, taking care of all=20 >> sorts of context information, i.e.dropping SIMPLE? >> >> Any comments helping to clarify this matter is highly appreciated! >> >> Cheers, >> Egil C. =D8sthus >> >> _______________________________________________ >> 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 Thu Jun 09 12:59:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgQN4-0005hy-4L; Thu, 09 Jun 2005 12:59:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgQN1-0005hi-Th for simple@megatron.ietf.org; Thu, 09 Jun 2005 12:59:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21612 for ; Thu, 9 Jun 2005 12:59:04 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgQiU-0007Hj-Ot for simple@ietf.org; Thu, 09 Jun 2005 13:21:21 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 09 Jun 2005 12:58:57 -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 j59GvD54009661; Thu, 9 Jun 2005 12:57:21 -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); Thu, 9 Jun 2005 12:57:15 -0400 Received: from cisco.com ([10.86.242.37]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Jun 2005 12:57:15 -0400 Message-ID: <42A874EA.4080104@cisco.com> Date: Thu, 09 Jun 2005 12:57:14 -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: egilconr@gmail.com Subject: Re: [Simple] SIP, SIMPLE and general context information References: <42A84436.3030009@stud.ntnu.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 09 Jun 2005 16:57:15.0311 (UTC) FILETIME=[49B21BF0:01C56D14] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA21612 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 Egil, I am not sure what you mean by "general context information". Your=20 question is essentially one of whether this information you are=20 interested in is suitable for inclusion in a PIDF document, presumably=20 using some extension TBD. That is a somewhat subjective decision. The first criterion is whether=20 the information pertains to a *presentity*. Perhaps temperature would=20 qualify, it it is temperature of a presentity, but probably not if it is=20 the temperature of a swimming pool. If you try to claim the swimming=20 pool is itself a presentity then I think you have surely gone too far. Paul Egil =D8sthus wrote: > Hi, >=20 > I'm looking into ways to distribute general context information, and=20 > have some questions connected to SIMPLE. >=20 > SIMPLE is used to transport presence information to a watcher. In the=20 > introduction of RFC 3856 it is argued why SIP Events is an appropriate=20 > way to distribute presence information. I agree in the arguments given=20 > in the RFC, but there are some details that still is not clear to me.=20 > Presence status is a special kind of the more general Context=20 > Information. What I'm uncertain about, is whether SIMPLE should be used= =20 > for distribution of other kinds of context information as well?=20 > Arguments that support this approach is that it is convenient to have=20 > only one protocol taking care of distributing all sorts of context=20 > information (e.g. Temperature, Light level, geographical location and s= o=20 > on). Also, the arguements given why SIMPLE is a proper protocol for=20 > presence info distribution goes for many of the other kinds of context=20 > information. Technically speaking, it is not any problem using SIMPLE=20 > for this matter, what I belive is the problem is that this approach is=20 > in conflict with the "Guidelines for Authors of Extensions to the=20 > Session Initiation Protocol (SIP)" internet draft=20 > (http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-09.txt).= =20 > Section 3.1 defines SIPs solution space, and I have a hard time=20 > convincing myself that distribution of general context information is=20 > within the solution space of SIP, in other words SIP is not an=20 > appropriate protocol. Then again, it seems kind of strange to me to=20 > define one protocol per each kind of context information type. (e.g. on= e=20 > for geographical location, one for temperature and so on). Should SIP=20 > Events (like SIMPLE) be used to distribute all kinds of context=20 > information (i.e. breaking the sip guidelines draft)? Should presence b= e=20 > distributed by SIMPLE, and other kinds of context information=20 > distributed by other protocols, i.e. creating a great number of context= =20 > distribution protocols? Or should a general protocol for context=20 > information be designed, taking care of all sorts of context=20 > information, i.e.dropping SIMPLE? >=20 > Any comments helping to clarify this matter is highly appreciated! >=20 > Cheers, > Egil C. =D8sthus >=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 Thu Jun 09 13:18:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgQg3-0002eD-V4; Thu, 09 Jun 2005 13:18:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgQg2-0002e8-Hg for simple@megatron.ietf.org; Thu, 09 Jun 2005 13:18:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23959 for ; Thu, 9 Jun 2005 13:18:43 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgR1O-0000Y0-MW for simple@ietf.org; Thu, 09 Jun 2005 13:41:00 -0400 Received: from [192.168.1.56] ([212.122.58.178]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j59HI82S028581 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 9 Jun 2005 13:18:34 -0400 (EDT) In-Reply-To: <42A58E01.7090705@cisco.com> References: <42A2FB6C.3010201@cs.columbia.edu> <42A3C2F3.1090703@cisco.com> <42A45834.50206@cisco.com> <9759C71E-6ED4-419A-8BE8-328F40696BAA@cs.columbia.edu> <42A58E01.7090705@cisco.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76B471BE-2C6D-4101-808A-6C317453AA5B@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Simple] Timed presence Date: Thu, 9 Jun 2005 01:58:06 -0400 To: Paul Kyzivat X-Mailer: Apple Mail (2.728) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.6 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: Simple 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 > My mental model is that composition can be done by either the > presence server or the watcher, or both. When it is done by the > presence server it can embody policy decisions specified by the > presentity. It may be necessary for the presence server to do it to > obscure detail that it doesn't want to disclose. Otherwise the > choice of where it is done is merely a matter of convenience and > optimization. For me, composition implies the creation of a new presence document. Clearly, the watcher needs to decide what information to display and may decide to drop information it considers unreliable or outdated, but I'm not sure whether calling this composition helps. In any event, I don't think this makes much of a difference for the case at hand. > > In this case, at 4pm it may be necessary to reconsider what status > to display. This reconsideration can be done by the watcher if the > raw status was made available to it. If the composer in the > presence server had hidden this than it may need to do the > reconsideration. > I would rather not have the PA be expected to do this. This greatly complicates implementations. Since the watcher can already do this, there seems little gain by extending the expected PA behavior that way. Clearly, nothing we say prevents a PA from creating new presence documents any time it sees fit, but I wouldn't want to make this part of the common composition policy, for example. > But, if the current status had been "on the phone" and closed, > while the future status is available and open, then at 4pm I would > be inclined to consider the status to remain the same. > > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 09 14:21:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgReI-0005o2-HF; Thu, 09 Jun 2005 14:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgReH-0005nu-6i for simple@megatron.ietf.org; Thu, 09 Jun 2005 14:21:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00798 for ; Thu, 9 Jun 2005 14:20:58 -0400 (EDT) Received: from royk.itea.ntnu.no ([129.241.190.230]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgRzl-00011y-13 for simple@ietf.org; Thu, 09 Jun 2005 14:43:14 -0400 Received: from localhost (localhost [127.0.0.1]) by royk.itea.ntnu.no (Postfix) with ESMTP id 96F4366C84; Thu, 9 Jun 2005 20:20:57 +0200 (CEST) Received: from [129.241.222.31] (vpn-22231.vpn-s.ntnu.no [129.241.222.31]) by royk.itea.ntnu.no (Postfix) with ESMTP; Thu, 9 Jun 2005 20:20:56 +0200 (CEST) Message-ID: <42A88889.10808@stud.ntnu.no> Date: Thu, 09 Jun 2005 20:20:57 +0200 From: =?ISO-8859-1?Q?Egil_=D8sthus?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] SIP, SIMPLE and general context information References: <42A84436.3030009@stud.ntnu.no> <42A874EA.4080104@cisco.com> In-Reply-To: <42A874EA.4080104@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: egilconr@gmail.com 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 Paul Kyzivat wrote: > Egil, > > I am not sure what you mean by "general context information". Your > question is essentially one of whether this information you are > interested in is suitable for inclusion in a PIDF document, presumably > using some extension TBD. Yes. > > That is a somewhat subjective decision. The first criterion is whether > the information pertains to a *presentity*. Perhaps temperature would > qualify, it it is temperature of a presentity, but probably not if it > is the temperature of a swimming pool. If you try to claim the > swimming pool is itself a presentity then I think you have surely gone > too far. > > Certainly, I do not claim that a swimming pool is a presentity. Temperature was just an example from the top of my head. Still, I can imagine that quite a few context aware applications could benefint from knowing the user's temperature, e.g. within medical applications. How to transfer this information "the most clever way", is still a bit unclear to me, but I starting to suspect that one general context delivery protocol might be a bit ambitious. It might be more clever to define several application specific context distribution protocols. Cheers, Egil _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 10 00:13:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgatV-0005AF-7m; Fri, 10 Jun 2005 00:13:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfkZp-0002pu-3e for simple@megatron.ietf.org; Tue, 07 Jun 2005 16:21:33 -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 QAA05453 for ; Tue, 7 Jun 2005 16:21:30 -0400 (EDT) Received: from mail1.followap.com ([194.90.96.46] helo=mail.followap.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfkuv-0006Ik-57 for simple@ietf.org; Tue, 07 Jun 2005 16:43:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-rpid-06.txt Date: Tue, 7 Jun 2005 23:15:10 +0300 Message-ID: <8E5AB0A04458904BB9B079055261033C9E456B@mail.followap.com> Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-rpid-06.txt Thread-Index: AcVod5OFf6sDcEFfTdiapUIQzXC9sADJMsBQ From: "Fridy Sharon-Fridman" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 10 Jun 2005 00:13:15 -0400 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 Minor comment - reference [8] can be changed to the RFC (3856). Thanks, --Fridy/Followap -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, June 03, 2005 10:57 PM To: i-d-announce@ietf.org Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-rpid-06.txt 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 : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-simple-rpid-06.txt Pages : 37 Date : 2005-6-3 =09 The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. That format defines a textual note, an indication of availability (open or closed) and a Universal Resource Identifier (URI) for communication. The Rich Presence Information Data Format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media might be private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers and the overall role of the presentity. These extensions include characteristics and status information for person, service (tuple) and devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-06.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-rpid-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-rpid-06.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. *** eSafe scanned this email for malicious content *** *** IMPORTANT: Do not open attachments from unrecognized senders *** _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 10 10:29:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgkVn-0001Pw-Rr; Fri, 10 Jun 2005 10:29:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgkVn-0001Pr-8j for simple@megatron.ietf.org; Fri, 10 Jun 2005 10:29:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24972 for ; Fri, 10 Jun 2005 10:29:28 -0400 (EDT) Received: from banana.cc.columbia.edu ([128.59.29.54] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgkrR-0005YT-QY for simple@ietf.org; Fri, 10 Jun 2005 10:51:56 -0400 Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5AEPabK005423; Fri, 10 Jun 2005 10:25:36 -0400 (EDT) Received: from localhost (rs2194@localhost) by banana.cc.columbia.edu (8.13.0/8.12.3/Submit) with ESMTP id j5AEPZeR005420; Fri, 10 Jun 2005 10:25:35 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: rs2194 owned process doing -bs Date: Fri, 10 Jun 2005 10:25:35 -0400 (EDT) From: Ron Shacham To: simple@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.9 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: thakolsri@docomolab-euro.com, kellerer@docomolab-euro.com, hgs@cs.columbia.edu Subject: [Simple] MSRP offerer role 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 Hello, The MSRP draft (5.4) specifies that the initiator of the messaging session (offerer) also opens the TCP connection, and this offerer must start the session by immediately sending out a SEND request. Although the draft mentions motivations for allowing negotiaton of the first role, I wish to present another one that applies to all of the offerer roles. We are working on specifying in our draft on Session Mobility, draft-shacham-sipping-session-mobility-00 the call flows for transfering MSRP sessions between endpoints. One of our models, which uses Third-party Call Control, requires such a negotiation mechanism. Since the controller (Mobile Node) only has a SIP signaling relationship with the target device, and that device otherwise communicates directly with the remote party (Correspondent Node), as in the case of continuous media, either the target device or the Corr. Node must be informed that it should take on the responsibilities of the "offerer", even though they are both, inherently, recipients of an offer. On another note, has there been discussion on specifying MSRP capability as part of callee-caps? Is it widely supported enough right now for this? This question also has applications to our draft. Regards, Ron _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 10 11:13:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DglCb-0002ac-8b; Fri, 10 Jun 2005 11:13:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DglCY-0002aX-KO for simple@megatron.ietf.org; Fri, 10 Jun 2005 11:13:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29272 for ; Fri, 10 Jun 2005 11:13:40 -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 1DglYF-00036l-Dd for simple@ietf.org; Fri, 10 Jun 2005 11:36:07 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 10 Jun 2005 08:13:32 -0700 X-IronPort-AV: i="3.93,189,1115017200"; d="scan'208"; a="642678960:sNHT28240992" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5AFDOlw018503; Fri, 10 Jun 2005 08:13:24 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 11:13:17 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 11:13:17 -0400 Message-ID: <42A9AE0C.6070403@cisco.com> Date: Fri, 10 Jun 2005 11:13:16 -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: Ron Shacham Subject: Re: [Simple] MSRP offerer role References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2005 15:13:17.0247 (UTC) FILETIME=[EDEED4F0:01C56DCE] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: thakolsri@docomolab-euro.com, simple@ietf.org, kellerer@docomolab-euro.com, hgs@cs.columbia.edu 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 Ron - comments inline. Paul Ron Shacham wrote: > Hello, > The MSRP draft (5.4) specifies that the initiator of the messaging > session (offerer) also opens the TCP connection, and > this offerer must start the session by immediately sending out a SEND > request. Although the draft mentions motivations for allowing > negotiaton of the first role, I wish to present another one that applies > to all of the offerer roles. > > We are working on specifying in our draft on Session Mobility, > draft-shacham-sipping-session-mobility-00 the > call flows for transfering MSRP sessions between endpoints. One of our > models, which uses Third-party Call Control, requires such a negotiation > mechanism. Since the controller (Mobile Node) only has a SIP signaling > relationship with the target device, and that device otherwise > communicates directly with the remote party (Correspondent Node), as in > the case of > continuous media, either the target device or the Corr. Node must be > informed that it should take on the responsibilities of the "offerer", > even though they are both, inherently, recipients of an offer. I am not understanding the point you are making. I think what you are saying is just the usual situation for 3pcc regardless of what media are being used. The controller in the middle wants to orchestrate an offer/answer exchange between the two parties it is coordinating. To do so, it normally chooses one party to be the offerer, and initiates things by sending it an offerless invite. The new issues introduced by MSRP seem to be: - the endpoint will have to somehow decide that it should offer MSRP. this isn't unique to MSRP. It is an issue as soon as there is more that one medium that can be used with sip. The simple answer is that the endpoint should probably offer everything it is willing to use at the time. - the endpoint chosen to be offerer will also have to be the active party in MSRP session establishment. > On another note, has there been discussion on specifying MSRP capability > as part of callee-caps? Is it widely supported enough right now for this? > This question also has applications to our draft. When you ask "is *it* widely supported enough right now", what do you mean by "it"? callee-caps or MSRP? How much is enough? It certainly shouldn't hurt to use callee caps to advertise support, even if nobody else supports it. Depending on others having used callee caps may be a bit dicy. But the situation may be better in the case of MSRP, because there is probably little or no support for it out there yet. You can probably establish a precedent and ensure that all MSRP implementations do advertise support via callee caps. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 10 11:38:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dglar-0000js-78; Fri, 10 Jun 2005 11:38:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dglap-0000jm-FI for simple@megatron.ietf.org; Fri, 10 Jun 2005 11:38:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01820 for ; Fri, 10 Jun 2005 11:38:44 -0400 (EDT) Received: from mango.cc.columbia.edu ([128.59.29.52] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DglwW-0004cq-Gx for simple@ietf.org; Fri, 10 Jun 2005 12:01:12 -0400 Received: from mango.cc.columbia.edu (localhost [127.0.0.1]) by mango.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5AFcViM023092; Fri, 10 Jun 2005 11:38:31 -0400 (EDT) Received: from localhost (rs2194@localhost) by mango.cc.columbia.edu (8.13.0/8.12.3/Submit) with ESMTP id j5AFcVIT023088; Fri, 10 Jun 2005 11:38:31 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: rs2194 owned process doing -bs Date: Fri, 10 Jun 2005 11:38:31 -0400 (EDT) From: Ron Shacham To: Paul Kyzivat Subject: Re: [Simple] MSRP offerer role In-Reply-To: <42A9AE0C.6070403@cisco.com> Message-ID: References: <42A9AE0C.6070403@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.9 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: thakolsri@docomolab-euro.com, simple@ietf.org, kellerer@docomolab-euro.com, hgs@cs.columbia.edu 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 Paul, Sorry for the ambiguity. See the clarifications below. Ron On Fri, 10 Jun 2005, Paul Kyzivat wrote: > Ron - comments inline. > > Paul > > Ron Shacham wrote: >> Hello, >> The MSRP draft (5.4) specifies that the initiator of the messaging session >> (offerer) also opens the TCP connection, and >> this offerer must start the session by immediately sending out a SEND >> request. Although the draft mentions motivations for allowing negotiaton >> of the first role, I wish to present another one that applies to all of the >> offerer roles. >> >> We are working on specifying in our draft on Session Mobility, >> draft-shacham-sipping-session-mobility-00 the >> call flows for transfering MSRP sessions between endpoints. One of our >> models, which uses Third-party Call Control, requires such a negotiation >> mechanism. Since the controller (Mobile Node) only has a SIP signaling >> relationship with the target device, and that device otherwise communicates >> directly with the remote party (Correspondent Node), as in the case of >> continuous media, either the target device or the Corr. Node must be >> informed that it should take on the responsibilities of the "offerer", even >> though they are both, inherently, recipients of an offer. > > I am not understanding the point you are making. > > I think what you are saying is just the usual situation for 3pcc regardless > of what media are being used. The controller in the middle wants to > orchestrate an offer/answer exchange between the two parties it is > coordinating. > > To do so, it normally chooses one party to be the offerer, and initiates > things by sending it an offerless invite. > > The new issues introduced by MSRP seem to be: > - the endpoint will have to somehow decide that it should offer MSRP. > this isn't unique to MSRP. It is an issue as soon as there is more > that one medium that can be used with sip. The simple answer is > that the endpoint should probably offer everything it is willing > to use at the time. > > - the endpoint chosen to be offerer will also have to be the > active party in MSRP session establishment. The second point you make here is the issue I was raising. There must be a way to negotiate the active party. This role in the session is what makes MSRP different from other media we are supporting. > >> On another note, has there been discussion on specifying MSRP capability >> as part of callee-caps? Is it widely supported enough right now for this? >> This question also has applications to our draft. > > When you ask "is *it* widely supported enough right now", what do you mean by > "it"? callee-caps or MSRP? How much is enough? MSRP. > > It certainly shouldn't hurt to use callee caps to advertise support, even if > nobody else supports it. Depending on others having used callee caps may be a > bit dicy. But the situation may be better in the case of MSRP, because there > is probably little or no support for it out there yet. You can probably > establish a precedent and ensure that all MSRP implementations do advertise > support via callee caps. Your point is well taken--that MSRP should be able to grow along with its callee-caps. Is there interest in defining this in the MSRP draft? > > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 10 13:41:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgnVY-0000LZ-NR; Fri, 10 Jun 2005 13:41:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgnVX-0000KZ-5O for simple@megatron.ietf.org; Fri, 10 Jun 2005 13:41:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14324 for ; Fri, 10 Jun 2005 13:41:25 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgnrE-0005jn-Nf for simple@ietf.org; Fri, 10 Jun 2005 14:03:53 -0400 Received: from [64.101.149.222] (mbeisel-w2k01.cisco.com [64.101.149.222] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j5AHhcO6004529 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 10 Jun 2005 12:43:39 -0500 In-Reply-To: <42A874EA.4080104@cisco.com> References: <42A84436.3030009@stud.ntnu.no> <42A874EA.4080104@cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <81cfb781070434936c701b3fc7b16925@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Simple] SIP, SIMPLE and general context information Date: Fri, 10 Jun 2005 12:40:22 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: egilconr@gmail.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Jun 9, 2005, at 11:57 AM, Paul Kyzivat wrote: > > That is a somewhat subjective decision. The first criterion is whether > the information pertains to a *presentity*. Perhaps temperature would > qualify, it it is temperature of a presentity, but probably not if it > is the temperature of a swimming pool. If you try to claim the > swimming pool is itself a presentity then I think you have surely gone > too far. > > Robots have presence too, you human-chauvinist! Seriously. I'll climb way out on a limb here. People, machines, and anything else that is potentially instrumented exhibit changes in state that influence the way other entities/objects/systems interact with them. This "state" may include levels of business/idleness, location, general demeanor or condition, and many other aspects. The presence model provides a useful framework for encoding, distributing, and controlling access to this information in many cases. For example, I wouldn't mind having location and some physiological information for my dog Zena showing up in my presence/IM client. Things like "In living room, sleeping" or "In yard, sleeping", or "In food bowl, sleeping" would be nice to know. Putting them into the framework of the presence application by which I currently know that my friend Vaugh is on-line but hasn't played with his computer in the last two hours and ten minutes would be useful. I also wouldn't mind instrumenting a few more things. For example, being the obsessive-compulsive but absent-minded sort that I am, I can never remember whether I remember to close the garage door, and this worries me. I'd be tickled to be able to look at my presence client and see "Garage Door: Closed". And I can't operate my VCR correctly, so it would be nice to look at my buddy list at 7:30 and see that my VCR is in fact recording the teletubbies show, so I won't have to wonder if I set it wrong (I'll KNOW it's wrong!). Sure, some of this could be done via SNMP, if I had a way to get SNMP through all the firewalls involved, collate the data, and display it in a useful way in an application. But once we've done that, we've invented presence-over-SNMP, which wasn't a design goal. "SIP for light bulbs" was greatly reviled. After all, who really wants to talk to light bulbs, and if they do, why would they need SIP when light-bulb-telepathy makes just as much sense? But "SIMPLE for light bulbs" might actually be relevant. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 10 15:59:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgpek-0006NY-Gt; Fri, 10 Jun 2005 15:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgpei-0006Mm-VI for simple@megatron.ietf.org; Fri, 10 Jun 2005 15:59:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01862 for ; Fri, 10 Jun 2005 15:59:01 -0400 (EDT) Received: from atlas.jabber.org ([208.245.212.69] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgq0O-0005JB-Mi for simple@ietf.org; Fri, 10 Jun 2005 16:21:31 -0400 Received: by atlas.jabber.org (Postfix, from userid 1005) id B15E221A44B; Fri, 10 Jun 2005 15:01:56 -0500 (CDT) Date: Fri, 10 Jun 2005 15:01:56 -0500 From: Peter Saint-Andre To: xmppwg@jabber.org, simple@ietf.org Message-ID: <20050610200156.GI21499@jabber.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Simple] FW: I-D ACTION:draft-saintandre-xmpp-simple-03.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org FYI. I think this I-D may have the longest title in IETF history. ;-) ----- Forwarded message from Internet-Drafts@ietf.org ----- To: i-d-announce@ietf.org =46rom: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-saintandre-xmpp-simple-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Basic Messaging and Presence Interoperability between=20 the Extensible Messaging and Presence Protocol (XMPP)=20 and Session Initiation Protocol (SIP) Extensions for=20 Instant Messaging and Presence (SIMPLE) Author(s) : P. Saint-Andre, et al. Filename : draft-saintandre-xmpp-simple-03.txt Pages : 25 Date : 2005-6-10 =09 This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of presence information and single instant messages between systems that implement the Extensible Messaging and Presence Protocol (XMPP) and those that implement the basic extensions to the Session Initiation Protocol (SIP) for instant messaging and presence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-simple-03.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the = message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-saintandre-xmpp-simple-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-saintandre-xmpp-simple-03.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ----- End forwarded message ----- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 10 16:00:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgpfw-0007Nm-CQ; Fri, 10 Jun 2005 16:00:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgpfu-0007Mf-GQ for simple@megatron.ietf.org; Fri, 10 Jun 2005 16:00:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02475 for ; Fri, 10 Jun 2005 16:00:16 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgq1c-0005UK-Dx for simple@ietf.org; Fri, 10 Jun 2005 16:22:45 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 10 Jun 2005 13:00:07 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5AJxiNQ014925; Fri, 10 Jun 2005 16:00:03 -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); Fri, 10 Jun 2005 15:59:55 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 15:59:55 -0400 Message-ID: <42A9F13A.7060409@cisco.com> Date: Fri, 10 Jun 2005 15:59:54 -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: Ron Shacham Subject: Re: [Simple] MSRP offerer role References: <42A9AE0C.6070403@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2005 19:59:55.0127 (UTC) FILETIME=[F8AB1070:01C56DF6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: thakolsri@docomolab-euro.com, simple@ietf.org, kellerer@docomolab-euro.com, hgs@cs.columbia.edu 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 Ron Shacham wrote: > Paul, > Sorry for the ambiguity. See the clarifications below. > > Ron > > On Fri, 10 Jun 2005, Paul Kyzivat wrote: > >> Ron - comments inline. >> >> Paul >> >> Ron Shacham wrote: >> >>> Hello, >>> The MSRP draft (5.4) specifies that the initiator of the messaging >>> session (offerer) also opens the TCP connection, and >>> this offerer must start the session by immediately sending out a SEND >>> request. Although the draft mentions motivations for allowing >>> negotiaton of the first role, I wish to present another one that >>> applies to all of the offerer roles. >>> >>> We are working on specifying in our draft on Session Mobility, >>> draft-shacham-sipping-session-mobility-00 the >>> call flows for transfering MSRP sessions between endpoints. One of >>> our models, which uses Third-party Call Control, requires such a >>> negotiation mechanism. Since the controller (Mobile Node) only has a >>> SIP signaling relationship with the target device, and that device >>> otherwise communicates directly with the remote party (Correspondent >>> Node), as in the case of >>> continuous media, either the target device or the Corr. Node must be >>> informed that it should take on the responsibilities of the >>> "offerer", even though they are both, inherently, recipients of an >>> offer. >> >> >> I am not understanding the point you are making. >> >> I think what you are saying is just the usual situation for 3pcc >> regardless of what media are being used. The controller in the middle >> wants to orchestrate an offer/answer exchange between the two parties >> it is coordinating. >> >> To do so, it normally chooses one party to be the offerer, and >> initiates things by sending it an offerless invite. >> >> The new issues introduced by MSRP seem to be: >> - the endpoint will have to somehow decide that it should offer MSRP. >> this isn't unique to MSRP. It is an issue as soon as there is more >> that one medium that can be used with sip. The simple answer is >> that the endpoint should probably offer everything it is willing >> to use at the time. >> >> - the endpoint chosen to be offerer will also have to be the >> active party in MSRP session establishment. > > > The second point you make here is the issue I was raising. There must > be a way to negotiate the active party. This role in the session is > what makes MSRP different from other media we are supporting. Do you have a suggestion here? There was an explicit decision to not get into the complexity that comedia has around negotiating this. (I am not convinced that is implementable.) I believe all the cases where there an endpoint might have difficulty taking either role are dealt with by the endpoint using a relay. >>> On another note, has there been discussion on specifying MSRP capability >>> as part of callee-caps? Is it widely supported enough right now for >>> this? >>> This question also has applications to our draft. >> >> >> When you ask "is *it* widely supported enough right now", what do you >> mean by "it"? callee-caps or MSRP? How much is enough? > > > MSRP. > >> >> It certainly shouldn't hurt to use callee caps to advertise support, >> even if nobody else supports it. Depending on others having used >> callee caps may be a bit dicy. But the situation may be better in the >> case of MSRP, because there is probably little or no support for it >> out there yet. You can probably establish a precedent and ensure that >> all MSRP implementations do advertise support via callee caps. > > > Your point is well taken--that MSRP should be able to grow along with > its callee-caps. Is there interest in defining this in the MSRP draft? Since the way of signaling this in SDP is m=message ... the callee caps way of representing it is: +sip.message _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jun 11 02:00:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgz2G-00069B-5L; Sat, 11 Jun 2005 02:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgz2E-000694-Cy for simple@megatron.ietf.org; Sat, 11 Jun 2005 01:59:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16594 for ; Sat, 11 Jun 2005 01:59:57 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgzO3-0001Zz-1a for simple@ietf.org; Sat, 11 Jun 2005 02:22:31 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 11 Jun 2005 01:59:50 -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 j5B5wt4u003001; Sat, 11 Jun 2005 01:58:56 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 11 Jun 2005 01:58:55 -0400 Received: from [192.168.1.100] ([10.86.240.115]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 11 Jun 2005 01:58:55 -0400 Message-ID: <42AA7D9F.9080401@cisco.com> Date: Sat, 11 Jun 2005 01:58:55 -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: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jun 2005 05:58:55.0508 (UTC) FILETIME=[A6CDFD40:01C56E4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Allison Mankin Subject: [Simple] updated XCAP spec 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 Folks, I've just submitted an update to the core xcap spec. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-07.txt This is based on IESG comments made during the review of the document. The changes are: * new text in the security considerations section: Because XCAP is a usage of HTTP and not a separate protocol, it runs on the same port numbers as HTTP traffic normally does. This makes it difficult to apply port-based filtering rules in firewalls to separate the treatment of XCAP traffic from other HTTP traffic. However, this problem exists broadly today because HTTP is used to access a wide breadth of content, all on the same port, and XCAP views application configuration documents as just another type of HTTP content. As such, separate treatment of XCAP traffic from other HTTP traffic requires firewalls to examine the URL itself. There is no foolproof way to identify a URL as pointing to an XCAP resource. However, the presence of the double tilde (~~) is a strong hint that the URL points to an XML element or attribute. As always, care must be taken in looking for the double-tilde due to the breadth of ways in which a URI can be encoded on-the-wire [30] [31]. * bug in the schema which was using urn:ietf:xml:params:ns:xcap-caps for the namespace instead of urn:ietf:params:xml:ns:xcap-caps * fixed bug in the examples, which were missing the double-tilde in a few places (!!) * updated reference to xcap-package to xcap-diff based on filename change 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 From simple-bounces@ietf.org Mon Jun 13 15:43:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhuqN-0006Vo-KV; Mon, 13 Jun 2005 15:43:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhuqJ-0006P3-Ai; Mon, 13 Jun 2005 15:43:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16836; Mon, 13 Jun 2005 15:43:29 -0400 (EDT) Message-Id: <200506131943.PAA16836@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 13 Jun 2005 15:43:29 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-07.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 : The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-07.txt Pages : 61 Date : 2005-6-13 This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-xcap-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xcap-07.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-6-13160908.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-13160908.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 Mon Jun 13 17:38:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhwdG-0004Lo-VZ; Mon, 13 Jun 2005 17:38:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhwdF-0004L6-Hm for simple@megatron.ietf.org; Mon, 13 Jun 2005 17:38:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08222 for ; Mon, 13 Jun 2005 17:38:07 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhwzZ-0007Nx-QM for simple@ietf.org; Mon, 13 Jun 2005 18:01:16 -0400 Received: from [10.10.2.230] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j5DLfLFn005171 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 13 Jun 2005 16:41:22 -0500 Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: "simple@ietf.org WG" From: Dean Willis Date: Mon, 13 Jun 2005 16:38:08 -0500 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [Simple] Link to external article: Presence application -- Employment status 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 So, do we need to account for this explicitly in RPID, or is this proof that codes lacking semantic specificity are still quite useful? http://www.wired.com/news/culture/0,1284,67789,00.html -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 13 18:12:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhxAW-0005On-DN; Mon, 13 Jun 2005 18:12:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhxAT-0005Oi-Kb for simple@megatron.ietf.org; Mon, 13 Jun 2005 18:12:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12261 for ; Mon, 13 Jun 2005 18:12:26 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhxWp-0000lY-5Y for simple@ietf.org; Mon, 13 Jun 2005 18:35:36 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 13 Jun 2005 18:12:19 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5DMA45Q028045; Mon, 13 Jun 2005 18:10:44 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 18:10:36 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 18:10:35 -0400 Message-ID: <42AE045C.205@cisco.com> Date: Mon, 13 Jun 2005 18:10:36 -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: Dean Willis Subject: Re: [Simple] Link to external article: Presence application -- Employment status References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jun 2005 22:10:35.0560 (UTC) FILETIME=[B92B7280:01C57064] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 I think it is fine for Note to be used for stuff like this, as long as the UIs actually display the note. If this sort of thing becomes important enough that it be possible to translate it into another language or an icon then it will be time to define a new activity value or an entirely new element. Paul Dean Willis wrote: > So, do we need to account for this explicitly in RPID, or is this proof > that codes lacking semantic specificity are still quite useful? > > http://www.wired.com/news/culture/0,1284,67789,00.html > > > -- > Dean > > > _______________________________________________ > 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 Jun 13 19:34:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhyS6-0004Dl-13; Mon, 13 Jun 2005 19:34:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhyS4-0004DT-4w for simple@megatron.ietf.org; Mon, 13 Jun 2005 19:34:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20912 for ; Mon, 13 Jun 2005 19:34:41 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhyoM-0004ue-1R for simple@ietf.org; Mon, 13 Jun 2005 19:57:51 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0II1001AZQOQA9@dns1.cselt.it> for simple@ietf.org; Tue, 14 Jun 2005 01:31:38 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Jun 2005 01:37:40 +0200 Date: Tue, 14 Jun 2005 01:34:22 +0200 From: Goix Walter Subject: RE: [Simple] Re:draft-ietf-simple-prescaps-ext-04.txt To: Paul Kyzivat , simple@ietf.org Message-id: <91C9464F6AFC0647A2D8069E25DBF496A8F775@EXC01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Simple] Re:draft-ietf-simple-prescaps-ext-04.txt Thread-Index: AcVqwIITqY9msf6iTR+U4+Fh1PA/SQFqp4ms content-class: urn:content-classes:message X-OriginalArrivalTime: 13 Jun 2005 23:37:40.0359 (UTC) FILETIME=[E3648170:01C57070] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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 A couple of more comments/questions on the issues raised by Paul. - Representing caps as elements that need to be registered through iana = rather than values of elements seems to be a bit restricting, especially = with regards to forthcoming extensions, methods, event packages or = whatever that we have not yet been thinking about. Updating the schema = or defining prescaps extension namespaces just to add support for an = extra cap is a quite heavy process. Any other reason that justifies such = a design rather than simple strings such as Paul suggested? - i agree with paul that service caps, as published into a presence doc, = may change dynamically based on a number of reasons (SIP UA = configuration may be an additional one). This emphasizes the need to = include such information into a presence doc since it may vary over = time. I also understand a similar doc may be used to statically describe = a UA stack, probably with a wider list of caps than the dynamic - user = related - subset of servcaps to be published or notified to a watcher. - How should be interpreted ? does that mean that any = other value not listed within but defined in the = namespace is actually supported? are both elements implicitely = exclusive, i.e. should the presence of means that any other = value, which is specified is the current namespace, is not supported = even if the element is not present? If so, it may be = worth detail it a bit more in the document. - how is the list of supported methods in the servcaps related to the = 'methods' parameter of the contact URI in the tuple/contact element = whenever present? what if both values are not sync, for example after = some filtering on a presence server? which information should be = considered the most relevant by a watcher? - 'unsupported' would save 2 chars per element instead of 'notsupported' = ;-) walter > 3.2 Service capability document > > Elements belonging to this document are used to describe > characteristics of a service. All elements defined in this section > describe static data about the service. ^^^^^^ Why is this described as static data? Capabilities can change for a variety of reasons: - a capability may be enabled or disabled by the user. E.g. a phone may potentially have video capabilities, but the user may have disabled them because he does not want to be seen. - the resources needed to support the capability may be temporarily unavailable. E.g. a softphone may be temporarily unavailable for audio because another application on the device has taken control of the audio components of the device. - a capability may be temporarily unavailable because the service has the necessary resources committed to other calls that it is processing. I believe all of these to be valid reasons to change the set of capabilities that are published. I suggest that the 2nd sentence of section 3.2 be removed. > 3.2.11 element > > The element indicates the setting, business or personal, in > which a communications service is used as defined in RFC3840 [6]. > > The element can contain two elements: and > . All classes that are supported by the service are > listed under element and all classes that are not > supported by the service are listed under element. > > and elements can contain and > elements followed by any number of optional extension > elements from other namespaces. The semantics of business and > personal are defined in RFC3840 [6] as: > > o : The service is used for business communications. > > o : The service is used for personal communications. > > Any value that is register to IANA to SIP Media Feature Tag > Registration Tree as sip.class media feature tag can be used as a > value of an extension element. If appropriate value is not > registered it SHOULD be registed as defined in RFC3840 [6]. The above confuses me. Suppose another value (e.g. 'charity') were added to the sip.class feature tag registration. How does a new element get defined? Similar comment for 3.2.12, 3.2.14, 3.2.16, 3.2.17, 3.2.19, 3.3.2. The problem is that someone can go through the iana process for adding a new feature tag value and then it can be used in sip callee caps. But to use it in a presence document you will need to define an xml element to represent it. There will be no mechanism to trace which extension xml element goes with a particular new feature tag value. Two people could define independent xml extensions for the same value. This could be solved by making the iana registry for feature tags cross reference an xml element definition. But that doesn't seem feasible. I think I prefer the approach you have taken for schemes and languages. > 3.2.15.1 element > > The element has a single attribute called "maxvalue". The ^^^^^ s/// > 3.3.3 element This is essentially the same as 3.2.15. The schema only defines it once, but that isn't clear from this description. I think it might be sufficient to cross reference 3.2.15 from this section. > 5. Examples ... > > Example service > ^^^^^^^^^^^^^ The above seems to be the result of some kind of editing error. > > > > minOccurs=3D"0"/> > minOccurs=3D"0"/> > > My knowledge of xml is very limited, but I believe to get the equivalent to what is in callee caps, supported and unsupported each need maxOccurs=3D"unbounded". _______________________________________________ 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. =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 Mon Jun 13 22:01:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di0js-0007V5-PV; Mon, 13 Jun 2005 22:01:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di0jr-0007UW-8Q for simple@megatron.ietf.org; Mon, 13 Jun 2005 22:01:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00581 for ; Mon, 13 Jun 2005 22:01:13 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di16E-0002mv-CM for simple@ietf.org; Mon, 13 Jun 2005 22:24:24 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-4.cisco.com with ESMTP; 13 Jun 2005 19:01:01 -0700 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 j5E20f5A017819; Mon, 13 Jun 2005 22:00:55 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 22:00:54 -0400 Received: from [192.168.1.100] ([10.86.242.183]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 22:00:54 -0400 Message-ID: <42AE3A55.6030109@cisco.com> Date: Mon, 13 Jun 2005 22:00:53 -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: Paul Kyzivat Subject: Re: [Simple] Link to external article: Presence application -- Employment status References: <42AE045C.205@cisco.com> In-Reply-To: <42AE045C.205@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2005 02:00:54.0339 (UTC) FILETIME=[E5CDC930:01C57084] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org WG" , Dean Willis 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 We will never be able to anticipate all of the use cases and information that people want to convey in their presence. I heard another example recently of teens setting their status to convey the topic of conversation in an IM conversation with their friends, almost like a form of multicast group chat through IM status. This is what note is for. I continue to believe we need freeform text throughout the fields to enable this. If it becomes commonplace and mature enough in a particular area, then we can define specific extensions to convey semantics. -Jonathan R. Paul Kyzivat wrote: > I think it is fine for Note to be used for stuff like this, as long as > the UIs actually display the note. > > If this sort of thing becomes important enough that it be possible to > translate it into another language or an icon then it will be time to > define a new activity value or an entirely new element. > > Paul > > Dean Willis wrote: > >> So, do we need to account for this explicitly in RPID, or is this >> proof that codes lacking semantic specificity are still quite useful? >> >> http://www.wired.com/news/culture/0,1284,67789,00.html >> >> >> -- >> Dean >> >> >> _______________________________________________ >> 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 > -- 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 From simple-bounces@ietf.org Tue Jun 14 04:19:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di6eK-0004gV-Cm; Tue, 14 Jun 2005 04:19:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di6eI-0004gJ-On for simple@megatron.ietf.org; Tue, 14 Jun 2005 04:19:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21037 for ; Tue, 14 Jun 2005 04:19:53 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di70j-0002S9-QS for simple@ietf.org; Tue, 14 Jun 2005 04:43:07 -0400 Received: from [192.89.6.47] (net-47.nrpn.net [192.89.6.47]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5E8Jo4d024744 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 14 Jun 2005 04:19:52 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <96903622-6D74-4E8A-B697-CA7E84BBBB88@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Simple] Link to external article: Presence application -- Employment status Date: Tue, 14 Jun 2005 04:20:28 -0400 To: Dean Willis X-Mailer: Apple Mail (2.728) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 I think both - we have 'working', so 'looking-for-work' is a fairly natural counterpart. already has a notes element, but if folks believe that other elements missing notes need one, let me know (soon). This should make SIMPLE and RPID the next must-have tool for Hollywood (or day laborers). In general, I think we'll see more use of presence for longer-term "keeping up" indications. The creative use of 'away' messages has been popular on college campuses for a number of years. See http://www.awaymessages.com/ On Jun 13, 2005, at 5:38 PM, Dean Willis wrote: > So, do we need to account for this explicitly in RPID, or is this > proof that codes lacking semantic specificity are still quite useful? > > http://www.wired.com/news/culture/0,1284,67789,00.html > > > -- > Dean > > > _______________________________________________ > 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 Jun 14 07:42:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di9nw-0006cU-RB; Tue, 14 Jun 2005 07:42:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di9nv-0006cP-0I for simple@megatron.ietf.org; Tue, 14 Jun 2005 07:42:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05422 for ; Tue, 14 Jun 2005 07:42:02 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiAAO-000395-JN for simple@ietf.org; Tue, 14 Jun 2005 08:05:17 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2005 07:41:54 -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 j5EBf54u003807; Tue, 14 Jun 2005 07:41:06 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Jun 2005 07:40:54 -0400 Received: from cisco.com ([10.86.242.6]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Jun 2005 07:40:53 -0400 Message-ID: <42AEC244.2090504@cisco.com> Date: Tue, 14 Jun 2005 07:40:52 -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: Henning Schulzrinne Subject: Re: [Simple] Link to external article: Presence application -- Employment status References: <96903622-6D74-4E8A-B697-CA7E84BBBB88@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2005 11:40:53.0818 (UTC) FILETIME=[EBE8E1A0:01C570D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org WG" , Dean Willis 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 Henning Schulzrinne wrote: > I think both - we have 'working', so 'looking-for-work' is a fairly > natural counterpart. already has a notes element, but if > folks believe that other elements missing notes need one, let me know > (soon). I was looking at this recently, and I noticed one thing that may be worth consideration. The Note in Activities may occur only once per instance of Activities. I can see usage models where it might be helpful if the Note element could appear multiple times. This usage would be helpful if a client views the note as an extension mechanism for adding new values. If it views it this way, then it may just want to have a configuration option to define new elements, and then have those new elements appear in a pick list with the predefined elements. As currently defined, each element that has a Note must treat it as a special case in the UI becuase it obeys different rules. I don't feel stringly about this, but it is worth a moment of consideration. Paul > This should make SIMPLE and RPID the next must-have tool for Hollywood > (or day laborers). In general, I think we'll see more use of presence > for longer-term "keeping up" indications. The creative use of 'away' > messages has been popular on college campuses for a number of years. > See http://www.awaymessages.com/ > > On Jun 13, 2005, at 5:38 PM, Dean Willis wrote: > >> So, do we need to account for this explicitly in RPID, or is this >> proof that codes lacking semantic specificity are still quite useful? >> >> http://www.wired.com/news/culture/0,1284,67789,00.html >> >> >> -- >> Dean >> >> >> _______________________________________________ >> 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 Jun 14 08:32:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiAaJ-0006kJ-CD; Tue, 14 Jun 2005 08:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiAaI-0006kD-Da for simple@megatron.ietf.org; Tue, 14 Jun 2005 08:32:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09433 for ; Tue, 14 Jun 2005 08:32:01 -0400 (EDT) Received: from p04.nexlink.net ([80.86.195.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiAwl-0005No-IZ for simple@ietf.org; Tue, 14 Jun 2005 08:55:17 -0400 Received: (qmail 1368 invoked from network); 14 Jun 2005 12:28:07 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 14 Jun 2005 12:28:07 -0000 Received: from d83-179-9-42.cust.tele2.fr (d83-179-9-42.cust.tele2.fr [83.179.9.42]) by webmail.tech-invite.com (IMP) with HTTP for ; Tue, 14 Jun 2005 14:28:06 +0200 Message-ID: <1118752086.42aecd56beefe@webmail.tech-invite.com> Date: Tue, 14 Jun 2005 14:28:06 +0200 From: =?iso-8859-1?b?Sm/rbA==?= Repiquet To: simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 83.179.9.42 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 8bit Subject: [Simple] xcap-diff-00 and xcap-package-03 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, The "xcap-diff-00" and "xcap-package-03" documents are both in the list of I-Ds for the SIMPLE WG, with same title, same abstract... >From outside, it seems that "xcap-diff-00" has replaced "xcap-package-03" but this is confusing. Is there any reason why these two documents co-exist? Thanks J. Repiquet ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 15 01:24:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiQON-00023Y-Oy; Wed, 15 Jun 2005 01:24:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiQOK-00021f-OZ for simple@megatron.ietf.org; Wed, 15 Jun 2005 01:24:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07608 for ; Wed, 15 Jun 2005 01:24:44 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiQkx-0005oP-07 for simple@ietf.org; Wed, 15 Jun 2005 01:48:08 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 15 Jun 2005 01:24:35 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5F5KWNK011222; Wed, 15 Jun 2005 01:20:59 -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); Wed, 15 Jun 2005 01:20:46 -0400 Received: from [192.168.1.100] ([10.86.242.15]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 01:20:46 -0400 Message-ID: <42AFBAAD.2020803@cisco.com> Date: Wed, 15 Jun 2005 01:20:45 -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: =?ISO-8859-1?Q?Jo=EBl_Repiquet?= Subject: Re: [Simple] xcap-diff-00 and xcap-package-03 References: <1118752086.42aecd56beefe@webmail.tech-invite.com> In-Reply-To: <1118752086.42aecd56beefe@webmail.tech-invite.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 15 Jun 2005 05:20:46.0143 (UTC) FILETIME=[FBE39CF0:01C57169] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id BAA07608 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 There was a renaming since the filename was quite inaccurate.=20 xcap-diff-00 replaces xcap-package-03. -Jonathan R. Jo=EBl Repiquet wrote: > Hi, >=20 > The "xcap-diff-00" and "xcap-package-03" documents are both in the list= of I-Ds > for the SIMPLE WG, with same title, same abstract... >>From outside, it seems that "xcap-diff-00" has replaced "xcap-package-0= 3" but > this is confusing. >=20 > Is there any reason why these two documents co-exist? >=20 > Thanks >=20 > J. Repiquet >=20 > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 --=20 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 From simple-bounces@ietf.org Wed Jun 15 05:33:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiUHT-0007Zf-Eb; Wed, 15 Jun 2005 05:33:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiUHS-0007ZV-6h for simple@megatron.ietf.org; Wed, 15 Jun 2005 05:33:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26056 for ; Wed, 15 Jun 2005 05:33:52 -0400 (EDT) Received: from web26202.mail.ukl.yahoo.com ([217.12.10.239]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DiUe7-0002e2-Mn for simple@ietf.org; Wed, 15 Jun 2005 05:57:19 -0400 Received: (qmail 19004 invoked by uid 60001); 15 Jun 2005 09:33:44 -0000 Message-ID: <20050615093344.19002.qmail@web26202.mail.ukl.yahoo.com> Received: from [194.237.142.13] by web26202.mail.ukl.yahoo.com via HTTP; Wed, 15 Jun 2005 11:33:44 CEST Date: Wed, 15 Jun 2005 11:33:44 +0200 (CEST) From: Salvatore Loreto To: simple@ietf.org, sipping@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Simple] simple and TV X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: salvatore.loreto@ieee.org 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, I'm researching about possible interaction between TV boxer decoder and SIP / Presence services, for interactive services. What do you think about the above scenario? Do you know if there are some studio/researches about? thank you in advance /sal ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.beta.messenger.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 15 07:44:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiWK9-0007Gv-F5; Wed, 15 Jun 2005 07:44:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiWK7-0007Gq-Ch for simple@megatron.ietf.org; Wed, 15 Jun 2005 07:44:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04864 for ; Wed, 15 Jun 2005 07:44:46 -0400 (EDT) Received: from p04.nexlink.net ([80.86.195.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiWgk-0001jn-QE for simple@ietf.org; Wed, 15 Jun 2005 08:08:14 -0400 Received: (qmail 1155 invoked from network); 15 Jun 2005 11:40:46 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 15 Jun 2005 11:40:46 -0000 Received: from d213-103-64-214.cust.tele2.fr (d213-103-64-214.cust.tele2.fr [213.103.64.214]) by webmail.tech-invite.com (IMP) with HTTP for ; Wed, 15 Jun 2005 13:40:46 +0200 Message-ID: <1118835646.42b013be49be9@webmail.tech-invite.com> Date: Wed, 15 Jun 2005 13:40:46 +0200 From: =?iso-8859-1?b?Sm/rbA==?= Repiquet To: Jonathan Rosenberg Subject: Re: [Simple] xcap-diff-00 and xcap-package-03 References: <1118752086.42aecd56beefe@webmail.tech-invite.com> <42AFBAAD.2020803@cisco.com> In-Reply-To: <42AFBAAD.2020803@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 213.103.64.214 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA04864 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 Thanks! My point was also that, as a result, "xcap-package-03" should be removed = from the I-D list in the SIMPLE Charter page: the 4th one in the list. Quoting Jonathan Rosenberg : > There was a renaming since the filename was quite inaccurate. > xcap-diff-00 replaces xcap-package-03. > > -Jonathan R. > > Jo=EBl Repiquet wrote: > > > Hi, > > > > The "xcap-diff-00" and "xcap-package-03" documents are both in the li= st of > I-Ds > > for the SIMPLE WG, with same title, same abstract... > >>From outside, it seems that "xcap-diff-00" has replaced "xcap-package= -03" > but > > this is confusing. > > > > Is there any reason why these two documents co-exist? > > > > Thanks > > > > J. Repiquet > > > > ---------------------------------------------------------------- > > This message was sent using IMP, the Internet Messaging Program. > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-271= 1 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > -- http://www.tech-invite.com ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 15 13:16:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DibVO-00035h-PH; Wed, 15 Jun 2005 13:16:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DibVN-00035c-6Q for simple@megatron.ietf.org; Wed, 15 Jun 2005 13:16:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04532 for ; Wed, 15 Jun 2005 13:16:42 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dibs6-0005KF-ER for simple@ietf.org; Wed, 15 Jun 2005 13:40:15 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5FHGd2i017645; Wed, 15 Jun 2005 20:16:39 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jun 2005 20:16:36 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jun 2005 20:16:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re:draft-ietf-simple-prescaps-ext-04.txt Date: Wed, 15 Jun 2005 20:16:35 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850FB1BF7E@esebe103.NOE.Nokia.com> Thread-Topic: [Simple] Re:draft-ietf-simple-prescaps-ext-04.txt Thread-Index: AcVqwLljWSJ/VLLQQWeitfn44s2R/QHCsQWg To: , X-OriginalArrivalTime: 15 Jun 2005 17:16:36.0373 (UTC) FILETIME=[FC389C50:01C571CD] X-Spam-Score: 0.3 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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 Hi, Thanks for comments. Sorry for the delay with this one.=20 Inline:=20 >I just took a look at this again. I have a few suggestions. > > Thanks for continuing to push this, > Paul > >> 3.2 Service capability document >>=20 >> Elements belonging to this document are used to describe >> characteristics of a service. All elements defined in=20 >this section >> describe static data about the service. > ^^^^^^ > >Why is this described as static data? Capabilities can change=20 >for a variety of reasons: > >- a capability may be enabled or disabled by the user. > E.g. a phone may potentially have video capabilities, > but the user may have disabled them because he does not > want to be seen. > >- the resources needed to support the capability may be > temporarily unavailable. E.g. a softphone may be temporarily > unavailable for audio because another application on the > device has taken control of the audio components of the device. > >- a capability may be temporarily unavailable because the > service has the necessary resources committed to other > calls that it is processing. > >I believe all of these to be valid reasons to change the set=20 >of capabilities that are published. > >I suggest that the 2nd sentence of section 3.2 be removed. Yes, all the points above are valid. The reason for using 'static' is that when the text was written the data model ID recommended to use that. I will remove it from next version as it probably causes more comfusion that good.=20 >> 3.2.11 element >>=20 >> The element indicates the setting, business or=20 >personal, in >> which a communications service is used as defined in RFC3840 [6]. >>=20 >> The element can contain two elements: and >> . All classes that are supported by the service are >> listed under element and all classes that are not >> supported by the service are listed under element. >>=20 >> and elements can contain and >> elements followed by any number of optional extension >> elements from other namespaces. The semantics of business and >> personal are defined in RFC3840 [6] as: >>=20 >> o : The service is used for business communications. >>=20 >> o : The service is used for personal communications. >>=20 >> Any value that is register to IANA to SIP Media Feature Tag >> Registration Tree as sip.class media feature tag can be used as a >> value of an extension element. If appropriate value is not >> registered it SHOULD be registed as defined in RFC3840 [6]. > >The above confuses me. Suppose another value (e.g. 'charity')=20 >were added to the sip.class feature tag registration. How does=20 >a new element get defined? > >Similar comment for 3.2.12, 3.2.14, 3.2.16, 3.2.17, 3.2.19, 3.3.2. > >The problem is that someone can go through the iana process=20 >for adding a new feature tag value and then it can be used in=20 >sip callee caps. But to use it in a presence document you will=20 >need to define an xml element to represent it. There will be=20 >no mechanism to trace which extension xml element goes with a=20 >particular new feature tag value. Two people could define=20 >independent xml extensions for the same value. > >This could be solved by making the iana registry for feature=20 >tags cross reference an xml element definition. But that=20 >doesn't seem feasible. > >I think I prefer the approach you have taken for schemes and languages. We have been discussion this for ages and we have tried these both approaches. How the schema is currently written is based on group's consensus and I won't be doing any changes to these things unless it is absolute necessary. >> 3.2.15.1 element >>=20 >> The element has a single attribute called "maxvalue". The > ^^^^^ > >s/// Will fix >> 3.3.3 element > >This is essentially the same as 3.2.15. The schema only=20 >defines it once, but that isn't clear from this description. I=20 >think it might be sufficient to cross reference 3.2.15 from=20 >this section. Right, will fix >> 5. Examples >... >> >> Example service >> > ^^^^^^^^^^^^^ >The above seems to be the result of some kind of editing error. Yes, too aggressive replace operation. Will fix > >> >> >> >> > minOccurs=3D"0"/> >> > minOccurs=3D"0"/> >> >> > >My knowledge of xml is very limited, but I believe to get the=20 >equivalent to what is in callee caps, supported and=20 >unsupported each need maxOccurs=3D"unbounded". Could you elaborate. What kind of use case you have in mind?=20 You can specify multiple ranges (use multiple , , etc) inside a single tag. - Mikko=20 >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 15 16: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 1Dienn-00016g-GH; Wed, 15 Jun 2005 16: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 1Dienj-000135-GP for simple@megatron.ietf.org; Wed, 15 Jun 2005 16:47:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05500 for ; Wed, 15 Jun 2005 16:47:53 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DifAT-0005Tw-RZ for simple@ietf.org; Wed, 15 Jun 2005 17:11:27 -0400 Received: from [10.10.2.230] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j5FKpE0m018506 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Jun 2005 15:51:16 -0500 In-Reply-To: <1118835646.42b013be49be9@webmail.tech-invite.com> References: <1118752086.42aecd56beefe@webmail.tech-invite.com> <42AFBAAD.2020803@cisco.com> <1118835646.42b013be49be9@webmail.tech-invite.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <39853f668eef5a0137cc3dc7b782fc83@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [Simple] xcap-diff-00 and xcap-package-03 Date: Wed, 15 Jun 2005 15:47:48 -0500 To: =?ISO-8859-1?Q?Jo=EBl_Repiquet?= X-Mailer: Apple Mail (2.622) 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 On behalf of the SIMPLE chairs, I've asked the ID people to mark=20 xcap-package-03 "dead". -- Dean On Jun 15, 2005, at 6:40 AM, Jo=EBl Repiquet wrote: > Thanks! > My point was also that, as a result, "xcap-package-03" should be=20 > removed from > the I-D list in the SIMPLE Charter page: the 4th one in the list. > > > > > Quoting Jonathan Rosenberg : > >> There was a renaming since the filename was quite inaccurate. >> xcap-diff-00 replaces xcap-package-03. >> >> -Jonathan R. >> >> Jo=EBl Repiquet wrote: >> >>> Hi, >>> >>> The "xcap-diff-00" and "xcap-package-03" documents are both in the=20= >>> list of >> I-Ds >>> for the SIMPLE WG, with same title, same abstract... >>>> =46rom outside, it seems that "xcap-diff-00" has replaced=20 >>>> "xcap-package-03" >> but >>> this is confusing. >>> >>> Is there any reason why these two documents co-exist? >>> >>> Thanks >>> >>> J. Repiquet >>> >>> ---------------------------------------------------------------- >>> This message was sent using IMP, the Internet Messaging Program. >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Director, Service Provider VoIP Architecture Parsippany, NJ=20 >> 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> > > > -- > http://www.tech-invite.com > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 15 22:14:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DijtW-0002vV-OG; Wed, 15 Jun 2005 22:14:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DijtU-0002vD-CL for simple@megatron.ietf.org; Wed, 15 Jun 2005 22:14:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04261 for ; Wed, 15 Jun 2005 22:14:05 -0400 (EDT) Received: from ms1.leadtek.com.tw ([202.39.71.16] helo=es1.leadtek.com.tw) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DikGC-0006x3-Of for simple@ietf.org; Wed, 15 Jun 2005 22:37:42 -0400 Received: from 0934xp ([172.16.5.73]) by es1.leadtek.com.tw with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 10:12:41 +0800 Message-ID: <005e01c57218$e0ba1440$490510ac@0934xp> From: "Leo" To: Subject: [Simple] Question about Watcher-list Date: Thu, 16 Jun 2005 10:12:42 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 16 Jun 2005 02:12:41.0474 (UTC) FILETIME=[E01D8620:01C57218] X-Spam-Score: 1.1 (+) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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="===============2070747383==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============2070747383== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01C5725B.EECEFC60" This is a multi-part message in MIME format. ------=_NextPart_000_005B_01C5725B.EECEFC60 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi, Why the watcherinfo subscriber need to maintain the watcher-list? The notifier (Server) knows every watcher's state, pending or active. Once the watcherinfo subscriber approved them, the server knew that. Whenever a watcher subscribes, the server knew that it had been approved = and can move to active state.=20 So the server could only nofity those watcher who are in pending state = to subscriber when it subscribe. Does watcher list have any correlation with buddy list? Thanks. Leo Engineer of R & D Dept. IX Leadtek Research Inc.=20 -------------------------------------------------------------------------= ------- TEL: +886 (0)2 8226 5800 Ext. 781 FAX: +886 (0)2 8226 5471 18F, 166, Chien Yi Road, Chung Ho City, Taipei County, Taiwan (235), R. O. C. =20 -------------------------------------------------------------------------= ------- ------=_NextPart_000_005B_01C5725B.EECEFC60 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi,
 
Why the watcherinfo subscriber need to maintain the = watcher-list?
The notifier (Server) knows every watcher's state, pending or = active.
Once the watcherinfo subscriber approved them, the server knew = that.
Whenever a watcher subscribes, the server knew that it had been=20 approved and can move to active state. 
So the server could only nofity those watcher who are in pending = state to=20 subscriber when it subscribe.
 
Does watcher list have any correlation with buddy list?
 
Thanks.
 
Leo
 
Engineer of R=20 & D Dept. IX
Leadtek Research=20 Inc. =
TEL: +886 (0)2 = 8226 5800 Ext.=20 781
FAX: +886 (0)2 = 8226=20 5471
18F, 166, Chien Yi Road, Chung Ho City,
Taipei County, = Taiwan=20 (235), R. O. C.
------=_NextPart_000_005B_01C5725B.EECEFC60-- --===============2070747383== 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 --===============2070747383==-- From simple-bounces@ietf.org Thu Jun 16 07:23:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DisSu-0004z6-GS; Thu, 16 Jun 2005 07:23:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DisSt-0004z0-0M for simple@megatron.ietf.org; Thu, 16 Jun 2005 07:23:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07961 for ; Thu, 16 Jun 2005 07:23:14 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dispi-0006hW-Oj for simple@ietf.org; Thu, 16 Jun 2005 07:46:58 -0400 Received: from [192.168.0.31] (pool-141-153-173-119.mad.east.verizon.net [141.153.173.119]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5GBN4QL002455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Jun 2005 07:23:05 -0400 (EDT) Message-ID: <42B16101.2030906@cs.columbia.edu> Date: Thu, 16 Jun 2005 07:22:41 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Link to external article: Presence application -- Employment status References: <96903622-6D74-4E8A-B697-CA7E84BBBB88@cs.columbia.edu> <42AEC244.2090504@cisco.com> In-Reply-To: <42AEC244.2090504@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Paul Kyzivat wrote: > The Note in Activities may occur only once per instance of Activities. I > can see usage models where it might be helpful if the Note element could > appear multiple times. > > This usage would be helpful if a client views the note as an extension > mechanism for adding new values. If it views it this way, then it may > just want to have a configuration option to define new elements, and > then have those new elements appear in a pick list with the predefined > elements. I'm not sure I'm getting what you're suggesting. Something like: First note Second note ? > > As currently defined, each element that has a Note must treat it as a > special case in the UI becuase it obeys different rules. At least the intent was to either have exactly one note element or none, so the UI could be something like: Activities: [drop-down with multi-selection] [... note ....] Type of place: [drop-down with one selection] [... note ....] Relationship: [drop-down with one selection] > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 16 08:41:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ditga-0003Ho-3U; Thu, 16 Jun 2005 08:41:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DitgY-0003Hj-FG for simple@megatron.ietf.org; Thu, 16 Jun 2005 08:41:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14991 for ; Thu, 16 Jun 2005 08:41:25 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diu3R-0004YQ-1Z for simple@ietf.org; Thu, 16 Jun 2005 09:05:10 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5GCcmXY016270; Thu, 16 Jun 2005 15:38:55 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Jun 2005 15:41:25 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Jun 2005 15:41:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re:draft-ietf-simple-prescaps-ext-04.txt Date: Thu, 16 Jun 2005 15:41:25 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850FDE3CDF@esebe103.NOE.Nokia.com> Thread-Topic: [Simple] Re:draft-ietf-simple-prescaps-ext-04.txt Thread-Index: AcVqwIITqY9msf6iTR+U4+Fh1PA/SQFqp4msAFi/FIA= To: , , X-OriginalArrivalTime: 16 Jun 2005 12:41:25.0337 (UTC) FILETIME=[B54A3490:01C57270] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 Hi, Thanks for comments. Inline: > >A couple of more comments/questions on the issues raised by Paul. > >- Representing caps as elements that need to be registered=20 >through iana rather than values of elements seems to be a bit=20 >restricting, especially with regards to forthcoming=20 >extensions, methods, event packages or whatever that we have=20 >not yet been thinking about. Updating the schema or defining=20 >prescaps extension namespaces just to add support for an extra=20 >cap is a quite heavy process. Any other reason that justifies=20 >such a design rather than simple strings such as Paul suggested? As I commented to Paul this issue has been discussed before. One of the reasons that you need to define new XML schema for new elements is that doing so you also define the semantic for that element.=20 >- i agree with paul that service caps, as published into a=20 >presence doc, may change dynamically based on a number of=20 >reasons (SIP UA configuration may be an additional one). This=20 >emphasizes the need to include such information into a=20 >presence doc since it may vary over time. I also understand a=20 >similar doc may be used to statically describe a UA stack,=20 >probably with a wider list of caps than the dynamic - user=20 >related - subset of servcaps to be published or notified to a watcher. Yes, this will be changed. >- How should be interpreted ? does that mean=20 >that any other value not listed within but=20 >defined in the namespace is actually supported?=20 No, all values listed in are explicitly not supported. Values that are listed may or may not be supported but the presentity doesn't want you to make decisions based on those. >are both=20 >elements implicitely exclusive, i.e. should the presence of=20 > means that any other value, which is specified is=20 >the current namespace, is not supported even if the=20 > element is not present? If so, it may be worth=20 >detail it a bit more in the document. I can add more text about this. >- how is the list of supported methods in the servcaps related=20 >to the 'methods' parameter of the contact URI in the=20 >tuple/contact element whenever present? what if both values=20 >are not sync, for example after some filtering on a presence=20 >server? which information should be considered the most=20 >relevant by a watcher? I haven't actually though about this at all. I have been thinking that URI value in contact would not be parsed to detect support for specific capabilities but would only be used by watchers to contact presentity. I would imagine that values in servcaps would be most relevant for the watcher in decision making. >- 'unsupported' would save 2 chars per element instead of=20 >'notsupported' ;-) Yes, we could even do -> and -> - Mikko >walter > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 16 09:35:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiuWW-000796-0z; Thu, 16 Jun 2005 09:35:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiuWU-00077u-0I for simple@megatron.ietf.org; Thu, 16 Jun 2005 09:35:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19874 for ; Thu, 16 Jun 2005 09:35:05 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiutM-0008By-5C for simple@ietf.org; Thu, 16 Jun 2005 09:58:50 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2005 09:34:59 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5GDXiVP001409; Thu, 16 Jun 2005 09:34:11 -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); Thu, 16 Jun 2005 09:34:10 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 09:34:10 -0400 Message-ID: <42B17FD1.5010900@cisco.com> Date: Thu, 16 Jun 2005 09:34: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: Henning Schulzrinne Subject: Re: [Simple] Link to external article: Presence application -- Employment status References: <96903622-6D74-4E8A-B697-CA7E84BBBB88@cs.columbia.edu> <42AEC244.2090504@cisco.com> <42B16101.2030906@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2005 13:34:10.0856 (UTC) FILETIME=[14161280:01C57278] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Henning Schulzrinne wrote: > Paul Kyzivat wrote: > >> The Note in Activities may occur only once per instance of Activities. >> I can see usage models where it might be helpful if the Note element >> could appear multiple times. >> >> This usage would be helpful if a client views the note as an extension >> mechanism for adding new values. If it views it this way, then it may >> just want to have a configuration option to define new elements, and >> then have those new elements appear in a pick list with the predefined >> elements. > > > I'm not sure I'm getting what you're suggesting. Something like: > > > First note > Second note > > Yes, something like that. >> As currently defined, each element that has a Note must treat it as a >> special case in the UI becuase it obeys different rules. Right. I'm just questioning if those different rules are the best ones here. > At least the intent was to either have exactly one note element or none, > so the UI could be something like: > > Activities: [drop-down with multi-selection] [... note ....] > Type of place: [drop-down with one selection] [... note ....] > Relationship: [drop-down with one selection] Yes. An alternative might be: Activities: [drop-down with multi-selection] where one of the selections is "other" and leads to a dialog to define "other". This would then be remembered and appear in the drop down list in the future. This would give the end user extensibility. Now the same thing could be done even if only one note is permitted. But then the UI is odd, because it will permit multi-selection of the predefined elements and any one of the extensions, but not two of the extensions. An implementation like that would probably get a lot of support calls from confused users. It is not a big deal, but I think it is worth thinking about the kind of UIs will and won't be facilitated. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 16 10:34:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DivRS-0004sC-39; Thu, 16 Jun 2005 10:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DivRP-0004s5-M8 for simple@megatron.ietf.org; Thu, 16 Jun 2005 10:33:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26792 for ; Thu, 16 Jun 2005 10:33:54 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DivoI-0003dz-0H for simple@ietf.org; Thu, 16 Jun 2005 10:57:40 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5GETs8n006040; Thu, 16 Jun 2005 17:29:55 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Jun 2005 17:33:50 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Jun 2005 17:33:49 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] element issue for common policy Date: Thu, 16 Jun 2005 17:33:49 +0300 Message-ID: Thread-Topic: [Simple] element issue for common policy Thread-Index: AcVrhaN8n+1o8Aw7QFy4Qr+4aParmAG9zAQQ To: , X-OriginalArrivalTime: 16 Jun 2005 14:33:49.0905 (UTC) FILETIME=[695D9C10:01C57280] X-Spam-Score: 0.3 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: quoted-printable Cc: pkyzivat@cisco.com, aki.niemi@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi Ted, I don't still get your point why this type of exceptions within a = particular rule/directive would be against the additive model of = permissions. I think you would still get the same results whichever way = you evaluate the permissions, and you would never reveal more if a = permission is lost - which seem to be the two main points of additive = permissions. In fact, the separate post-processing after the authorization decision = has been already done, is much more contradictory to the model, since = then you may be enforcing exceptions that are "global", and if that part = of the process fails, you may end up revealing more information. As = Jonathan was asking, I see little difference in having a rule in common = policy saying "deny this guy" (which is clealy wrong in terms of the = additiveness principle) and having a separate facility saying "if this = guy gets through the auth policy, deny him". The point about identity/domain minting is valid, however. It is clear = that you will not get perfect protection with identity or domain = exceptions, because of the reasons you explain. My view of the situation = is still a bit different than yours for the following reasons: 1. If someone is concerned about identity minting, they can decide NOT = to use the exceptions. This decision can be done at many levels: service provider can ban = them, client vendor can band them, UI designer can ban them, the user = can decide not to use them. The main point: I do *NOT* think that in = this case it is the IETF's business to do this decision! In fact, I'm = afraind that it IETF does this, other organizations and vendors are = forced to hack around this with the loss of interoperability, since as = far as I know, some sort of black-listing capability is a clear must = from user expectation point of view. 2. There are many many cases where users would not need to care about = identity minting. For instance, if I want to block my mother for a = while, I can be pretty sure she won't go about minting another identity = to get the access. Regards, Markus =20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Ted Hardie > Sent: 07 June, 2005 20:21 > To: Jonathan Rosenberg > Cc: Paul Kyzivat; Niemi Aki (Nokia-NRC/Helsinki); simple@ietf.org > Subject: Re: [Simple] element issue for common policy >=20 >=20 > Hi Jonathan, >=20 > For some bizarre reason, both copies of this just now turned=20 > up in my mail box; > I apologize for the long delay in replying. If there are=20 > other messages you > have out to me for which you're expecting a reply, please re-send. >=20 > At 12:13 PM -0400 5/25/05, Jonathan Rosenberg wrote: > >A question inline. > > > >Ted Hardie wrote: > > > >>that the automation of the disposition decision does the=20 > same job; I can > >>set up a process (note, not a *rule*) that moves things out=20 > of (pending) on > >>my behalf. That process can use whatever heuristics I=20 > describe and they > >>can be lots more granular or clever than the can be > >>(e.g. remove requests from (pending) when there are more=20 > 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=20 > >moves things out of pending on my behalf, where presumably that=20 > >process places them into "rejected" if they are from select domains,=20 > >and a rule that works in the same way. >=20 > There are a couple of things that I was trying to get at here. One=20 > of the issues > that drove geopriv to the additive permissions only point of=20 > view was that > you didn't necessarily know what order permissions would be granted in > (especially where some are incorporated from external=20 > sources). That means > the processing model for an additive/subtractive model requires all of > the rules to be present and somehow sorted correctly to get=20 > to the intended > state. If you can't resolve an external reference in that=20 > case you either > get nothing (because you're very conservative) or you reveal=20 > to much (because > you're insufficiently paranoid). In going to an additive=20 > permissions model, > you know that whatever permissions have been granted up to a specific > point are intended and that you are being at least as conservative as > was intended. You also are free to process the directives in=20 > any order. >=20 > Except clauses that are clearly tied to specific directives are better > than all-out negative permissions, but they can remain problematic > in their interaction with user expectations. If I say "Grant anyone > access to my timezone, except Hisham" and also say "Grant any > wg chair in APPs access to my full location", Hisham will get my > time zone--but this may not be what a user expects, especially > if the user expectation is driven by a sense of "override" and > wrote the "except Hisham" after the first rule was in place. >=20 > For a process model, all of the additive rules are done first > before a process kicks in--this means that you can guarantee=20 > an evaluation > order-- all the rules and then later the processes (which I=20 > should probably > call something other than "process"). Personally, I think that helps, > especially if the rules are constructed so as to put those which > require post-rule evaluation into what are essentially pending > states (as this leaves the "you are being at least as conservative > as intended" in place). A human can do the post-rule evaluation, > or it can be done by a process/agent/heuristic engine of whatever > complexity is appropriate. >=20 > That's the other main point--I believe that the "grant any, except > domain" is so close to useless that it is not worth it; it is=20 > trivially > easy to mint identities that escape this clause. To get to something > that actually successfully excluded someone here, I think you'd > eventually need something of close to arbitrary complexity, and > that this does not belong in the rules language "Anyone may=20 > know my timezone > except those whose identities are associated with domains=20 > that have been > recently minted, are in this list, or were paid for by credit cards > traceable to "Hisham Khartabil" or were paid for in ways that are > not traceable." *might* succeed in keeping Hisham from knowing > what timezone I'm in. But even then, he has only to get a friend > to loan him a cc to get past it. >=20 > regards, > Ted >=20 >=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 Thu Jun 16 11:37:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwQp-0003Uz-Hf; Thu, 16 Jun 2005 11:37:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwQo-0003Tf-As for simple@megatron.ietf.org; Thu, 16 Jun 2005 11:37:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02803 for ; Thu, 16 Jun 2005 11:37:20 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diwni-0007bk-DC for simple@ietf.org; Thu, 16 Jun 2005 12:01:07 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2005 17:37:15 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5GFb5wM025175; Thu, 16 Jun 2005 17:37:12 +0200 (MEST) Received: from xbh-rtp-211.amer.cisco.com ([64.102.31.102]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 17:37:06 +0200 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); Thu, 16 Jun 2005 11:37:04 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 11:37:03 -0400 Message-ID: <42B19C9E.1050302@cisco.com> Date: Thu, 16 Jun 2005 11:37:02 -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: mikko.lonnfors@nokia.com Subject: Re: [Simple] Re:draft-ietf-simple-prescaps-ext-04.txt References: <8B1D53AEF7B03449A6D3771B3B7F850FDE3CDF@esebe103.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2005 15:37:03.0836 (UTC) FILETIME=[3EB989C0:01C57289] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Walter.Goix@TILAB.COM X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org mikko.lonnfors@nokia.com wrote: > Hi, > > Thanks for comments. Inline: > > >>A couple of more comments/questions on the issues raised by Paul. >> >>- Representing caps as elements that need to be registered >>through iana rather than values of elements seems to be a bit >>restricting, especially with regards to forthcoming >>extensions, methods, event packages or whatever that we have >>not yet been thinking about. Updating the schema or defining >>prescaps extension namespaces just to add support for an extra >>cap is a quite heavy process. Any other reason that justifies >>such a design rather than simple strings such as Paul suggested? > > > As I commented to Paul this issue has been discussed before. One of the > reasons that you need to define new XML schema for new elements is that > doing so you also define the semantic for that element. I'm not so much bothered by the need to define a new schema as I am by the lack of any clear way to discover if that has been done. There could be a new feature tag value registered in IANA, and you and I could both decide we want to use it in prescaps. We could each go ahead and define an XML extension to handle it. And they we would not interoperate. And I'm not *as* concenred with entirely new feature tags as I am with new values for existing ones. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 16 15:09:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DizkS-0005uP-IU; Thu, 16 Jun 2005 15:09:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DizkP-0005uK-Gj for simple@megatron.ietf.org; Thu, 16 Jun 2005 15:09:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26797 for ; Thu, 16 Jun 2005 15:09:48 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj07L-0005ip-Al for simple@ietf.org; Thu, 16 Jun 2005 15:33:36 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0II600F33YFGJ3@dns1.cselt.it> for simple@ietf.org; Thu, 16 Jun 2005 21:06:52 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 21:12:56 +0200 Date: Thu, 16 Jun 2005 21:09:37 +0200 From: Goix Walter Subject: RE: [Simple] Re:draft-ietf-simple-prescaps-ext-04.txt To: mikko.lonnfors@nokia.com, Walter.Goix@TILAB.COM, pkyzivat@cisco.com, simple@ietf.org Message-id: <91C9464F6AFC0647A2D8069E25DBF496A8F7B8@EXC01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Simple] Re:draft-ietf-simple-prescaps-ext-04.txt Thread-Index: AcVqwIITqY9msf6iTR+U4+Fh1PA/SQFqp4msAFi/FIAANIbXxg== content-class: urn:content-classes:message X-OriginalArrivalTime: 16 Jun 2005 19:12:56.0296 (UTC) FILETIME=[66FE1680:01C572A7] X-Spam-Score: 2.0 (++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 comments inline... =20 > >A couple of more comments/questions on the issues raised by Paul. > >- Representing caps as elements that need to be registered >through iana rather than values of elements seems to be a bit >restricting, especially with regards to forthcoming >extensions, methods, event packages or whatever that we have >not yet been thinking about. Updating the schema or defining >prescaps extension namespaces just to add support for an extra >cap is a quite heavy process. Any other reason that justifies >such a design rather than simple strings such as Paul suggested? As I commented to Paul this issue has been discussed before. One of the reasons that you need to define new XML schema for new elements is that doing so you also define the semantic for that element. =20 [walter] i have a similar concern than paul regarding this issues. i = agree with you on the risk of different vendors using the same value for = different meanings if no semantics is defined, but it may strongly limit = the evolution of the schema to add new caps while extensions are being = defined. Typically, values we've been discussing on need to be = registered with iana and have some meaning associated. if some vendor = uses some value which is not registered with iana but can possibly be = defined in the future then we may end up with interop issues, unless = each cap has a well-defined naming convention (e.g. feature tags) that = allows for proprietary values. in the latter case, i don't see any true = issue in using free values since we will be able to distinguish between = proprietary and standard values. this would add a lot more flexibilitity = (e.g. for feature tags) regarding event packages, there names have to be registered with iana = anyway so i wouldn't expect proprietary event packages and hence = different meanings. we are close to get 'dialog' and probably = 'sip-profile' as RFCs so it would be interesting to add them to the = draft as soon as they become rfc. The point is that such a solution will = freezee the list of such elements at the time the prescaps draft will = become rfc, and would typically need subsequent versions for each new = extension/evt pkg. [snip] >- How should be interpreted ? does that mean >that any other value not listed within but >defined in the namespace is actually supported? No, all values listed in are explicitly not supported. Values that are listed may or may not be supported but the presentity doesn't want you to make decisions based on those. =20 [walter] may a watcher interprete a value for a specific = method as a dnd? As an example, would MESSAGE mean not = "willing" to receive it or not "able"? Is this again only a hint? How = should the presentity answer to a MESSAGE in this case, 501 because it = is truly not supported, or may it accept it anyway? How to guarantee = "message dnd" not to be implemented this way? or on the contrary would = you see it as a reasonable way to implement it? 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 Jun 16 15:58:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0VU-0007qf-6F; Thu, 16 Jun 2005 15:58:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0VS-0007qX-Pa for simple@megatron.ietf.org; Thu, 16 Jun 2005 15:58:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01735 for ; Thu, 16 Jun 2005 15:58:25 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj0sP-0000ST-35 for simple@ietf.org; Thu, 16 Jun 2005 16:22:14 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2005 15:58:20 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5GJvDVD007583; Thu, 16 Jun 2005 15:57:31 -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); Thu, 16 Jun 2005 15:57:22 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 15:57:21 -0400 Message-ID: <42B1D9A1.5040405@cisco.com> Date: Thu, 16 Jun 2005 15:57:21 -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] Re:draft-ietf-simple-prescaps-ext-04.txt References: <91C9464F6AFC0647A2D8069E25DBF496A8F7B8@EXC01B.cselt.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2005 19:57:21.0946 (UTC) FILETIME=[9BD7FFA0:01C572AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: mikko.lonnfors@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Goix Walter wrote: >>- How should be interpreted ? does that mean >>that any other value not listed within but >>defined in the namespace is actually supported? > > No, all values listed in are explicitly not supported. > Values that are listed may or may not be supported but the presentity > doesn't want you to make decisions based on those. > > [walter] may a watcher interprete a value for a specific method as a dnd? As an example, would MESSAGE mean not "willing" to receive it or not "able"? Is this again only a hint? How should the presentity answer to a MESSAGE in this case, 501 because it is truly not supported, or may it accept it anyway? How to guarantee "message dnd" not to be implemented this way? or on the contrary would you see it as a reasonable way to implement it? The semantics here should not be redefined, but rather should only be by reference to callee caps RFC 3840. IMO that means not willing or not able - the watcher can't tell. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 16 17:11:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj1dd-0007XM-KE; Thu, 16 Jun 2005 17:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj1dc-0007XC-SW for simple@megatron.ietf.org; Thu, 16 Jun 2005 17:11:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16099 for ; Thu, 16 Jun 2005 17:10:55 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj20b-0007qG-5g for simple@ietf.org; Thu, 16 Jun 2005 17:34:45 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j5GL9jmD006063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Jun 2005 17:09:46 -0400 (EDT) Message-ID: <42B1EA94.1080203@cs.columbia.edu> Date: Thu, 16 Jun 2005 17:09:40 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Link to external article: Presence application -- Employment status References: <96903622-6D74-4E8A-B697-CA7E84BBBB88@cs.columbia.edu> <42AEC244.2090504@cisco.com> <42B16101.2030906@cs.columbia.edu> <42B17FD1.5010900@cisco.com> In-Reply-To: <42B17FD1.5010900@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Paul Kyzivat wrote: > >> At least the intent was to either have exactly one note element or >> none, so the UI could be something like: >> >> Activities: [drop-down with multi-selection] [... note ....] >> Type of place: [drop-down with one selection] [... note ....] >> Relationship: [drop-down with one selection] > > > Yes. An alternative might be: > > Activities: [drop-down with multi-selection] > > where one of the selections is "other" and leads to a dialog to define > "other". This would then be remembered and appear in the drop down list > in the future. This would give the end user extensibility. There are really two different things that you're applying 'notes' to, namely as a means of providing additional context for an enumerated value, explaining or adding detail, or as a way to add user-defined values without extending the schema. I'm not sure it's a good idea to commingle the two. Different solutions have been proposed, along the lines of The grass is 2' high Moving lawn > > Now the same thing could be done even if only one note is permitted. But > then the UI is odd, because it will permit multi-selection of the > predefined elements and any one of the extensions, but not two of the > extensions. An implementation like that would probably get a lot of > support calls from confused users. > > It is not a big deal, but I think it is worth thinking about the kind of > UIs will and won't be facilitated. > > Paul > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 16 18:34:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj2wX-0000YT-1Q; Thu, 16 Jun 2005 18:34:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj2wV-0000YO-0v for simple@megatron.ietf.org; Thu, 16 Jun 2005 18:34:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22138 for ; Thu, 16 Jun 2005 18:34:28 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj3JT-00044J-Vj for simple@ietf.org; Thu, 16 Jun 2005 18:58:20 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2005 18:34:26 -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 j5GMVpi9009970; Thu, 16 Jun 2005 18:32:50 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 18:32:38 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 18:32:38 -0400 Message-ID: <42B1FE05.1010200@cisco.com> Date: Thu, 16 Jun 2005 18:32:37 -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: Henning Schulzrinne Subject: Re: [Simple] Link to external article: Presence application -- Employment status References: <96903622-6D74-4E8A-B697-CA7E84BBBB88@cs.columbia.edu> <42AEC244.2090504@cisco.com> <42B16101.2030906@cs.columbia.edu> <42B17FD1.5010900@cisco.com> <42B1EA94.1080203@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2005 22:32:38.0237 (UTC) FILETIME=[4CC930D0:01C572C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Henning, OK - I like what you suggest! (Wish I had thought of it.) Paul Henning Schulzrinne wrote: > Paul Kyzivat wrote: > >> >>> At least the intent was to either have exactly one note element or >>> none, so the UI could be something like: >>> >>> Activities: [drop-down with multi-selection] [... note ....] >>> Type of place: [drop-down with one selection] [... note ....] >>> Relationship: [drop-down with one selection] >> >> >> >> Yes. An alternative might be: >> >> Activities: [drop-down with multi-selection] >> >> where one of the selections is "other" and leads to a dialog to define >> "other". This would then be remembered and appear in the drop down >> list in the future. This would give the end user extensibility. > > > There are really two different things that you're applying 'notes' to, > namely as a means of providing additional context for an enumerated > value, explaining or adding detail, or as a way to add user-defined > values without extending the schema. I'm not sure it's a good idea to > commingle the two. > > Different solutions have been proposed, along the lines of > > > The grass is 2' high > Moving lawn > > >> >> Now the same thing could be done even if only one note is permitted. >> But then the UI is odd, because it will permit multi-selection of the >> predefined elements and any one of the extensions, but not two of the >> extensions. An implementation like that would probably get a lot of >> support calls from confused users. >> >> It is not a big deal, but I think it is worth thinking about the kind >> of UIs will and won't be facilitated. >> >> Paul >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jun 18 12:42:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjgPF-000083-Ht; Sat, 18 Jun 2005 12:42:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjgPD-00007y-AL for simple@megatron.ietf.org; Sat, 18 Jun 2005 12:42:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25293 for ; Sat, 18 Jun 2005 12:42:47 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjgmX-0008Fh-GZ for simple@ietf.org; Sat, 18 Jun 2005 13:06:58 -0400 Received: from [192.168.0.31] (pool-141-153-173-119.mad.east.verizon.net [141.153.173.119]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5IGgmpc008864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 18 Jun 2005 12:42:48 -0400 (EDT) Message-ID: <42B44F00.1040002@cs.columbia.edu> Date: Sat, 18 Jun 2005 12:42:40 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 3.0 (+++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Simple] tel as device identifier 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 Currently, there is no really good device identifier (device-id), as none of the obvious candidates (IMSI, MAC address, etc) currently have a URN definition. In order to speed deployment, one quick-and-easy suggestion is to use the tel URL. While this does not always identify a single device, in many practical cases of interest, it does. Examples where this is likely to work reasonably well include mobile phones and residential analog phones (i.e., without ENUM). Comments? Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jun 18 14:01:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjhdP-0001eW-65; Sat, 18 Jun 2005 14:01:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjhdL-0001eR-9k for simple@megatron.ietf.org; Sat, 18 Jun 2005 14:01:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00087 for ; Sat, 18 Jun 2005 14:01:29 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dji0f-0002w5-8v for simple@ietf.org; Sat, 18 Jun 2005 14:25:39 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-4.cisco.com with ESMTP; 18 Jun 2005 11:01:19 -0700 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 j5II1Gne004400; Sat, 18 Jun 2005 14:01:17 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 18 Jun 2005 14:01:16 -0400 Received: from cisco.com ([10.86.241.1]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 18 Jun 2005 14:01:16 -0400 Message-ID: <42B4616B.9000300@cisco.com> Date: Sat, 18 Jun 2005 14:01:15 -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: Henning Schulzrinne Subject: Re: [Simple] tel as device identifier References: <42B44F00.1040002@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jun 2005 18:01:16.0342 (UTC) FILETIME=[B8D8AD60:01C5742F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Simple 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 Henning, I think the problem is that presumably the device itself must decide if this can be used as a device-id. I don't know how the device would be able to decide that it is the only one that will be trying to use the phone number as a device id. If it is a human deciding to do this then I think it can work. Paul Henning Schulzrinne wrote: > Currently, there is no really good device identifier (device-id), as > none of the obvious candidates (IMSI, MAC address, etc) currently have a > URN definition. In order to speed deployment, one quick-and-easy > suggestion is to use the tel URL. While this does not always identify a > single device, in many practical cases of interest, it does. Examples > where this is likely to work reasonably well include mobile phones and > residential analog phones (i.e., without ENUM). > > Comments? > > Henning > > _______________________________________________ > 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 Sat Jun 18 15:10:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjiiG-0002VD-NC; Sat, 18 Jun 2005 15:10:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjiiE-0002V8-NB for simple@megatron.ietf.org; Sat, 18 Jun 2005 15:10:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05689 for ; Sat, 18 Jun 2005 15:10:34 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Djj5Y-0005Sw-7n for simple@ietf.org; Sat, 18 Jun 2005 15:34:45 -0400 Received: from [192.168.0.31] (pool-141-153-173-119.mad.east.verizon.net [141.153.173.119]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5IJ8PAW021689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 18 Jun 2005 15:08:26 -0400 (EDT) Message-ID: <42B47120.7010403@cs.columbia.edu> Date: Sat, 18 Jun 2005 15:08:16 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] tel as device identifier References: <42B44F00.1040002@cs.columbia.edu> <42B4616B.9000300@cisco.com> In-Reply-To: <42B4616B.9000300@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Simple 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 Paul Kyzivat wrote: > Henning, > > I think the problem is that presumably the device itself must decide if > this can be used as a device-id. I don't know how the device would be > able to decide that it is the only one that will be trying to use the > phone number as a device id. > > If it is a human deciding to do this then I think it can work. Initially, I suspect that most devices won't do any publishing on their own, so this will have to be entered manually. I agree that this is not a long-term or universal solution, but we lack deployable alternatives. For current cell phones, 'tel' should work reasonably well. As far as I know, each cell number is assigned to exactly one device at a time. Even for residential phones, while there might be multiple devices on a single piece of wire, the phone company (ILEC) could certainly assign this as an identifier. These multiple devices act essentially as if they were one - there's no way to reach just one of them. (Indeed, this application motivates my question.) Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jun 19 17:20:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk7Dn-0006w5-IX; Sun, 19 Jun 2005 17:20:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk7Di-0006vx-Hu for simple@megatron.ietf.org; Sun, 19 Jun 2005 17:20:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07807 for ; Sun, 19 Jun 2005 17:20:43 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dk7bG-0006VR-4u for simple@ietf.org; Sun, 19 Jun 2005 17:45:08 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IIC0042RO0K1E@dns2.cselt.it> for simple@ietf.org; Sun, 19 Jun 2005 23:07:32 +0200 (MEST) Received: from iowa2k01a.cselt.it ([163.162.242.201]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Jun 2005 23:19:12 +0200 Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Jun 2005 23:23:51 +0200 Date: Sun, 19 Jun 2005 23:20:30 +0200 From: Goix Walter Subject: RE: [Simple] tel as device identifier To: Henning Schulzrinne , Paul Kyzivat Message-id: <91C9464F6AFC0647A2D8069E25DBF496A8F7CE@EXC01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Simple] tel as device identifier Thread-Index: AcV0OaZ6AIai5THGRTCKKemlBqZH0gA2Yll4 Content-class: urn:content-classes:message X-OriginalArrivalTime: 19 Jun 2005 21:23:51.0140 (UTC) FILETIME=[30156A40:01C57515] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: Simple 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 Henning, =20 in current networks, most of the cell and residential phones do not = actually know the public phone number they're attached to, so the = information would need to be entered either manually on the device = whenever possible, or automatically within the network. Whenever entered = manually (for example on a mobile phone), the tel: URI shall be asserted = in some way, which is not easy to check. When assigned by a network by a = presence network agent, which publishes on behalf of the device, the = publishing entity would probably need to know both the phone number and = the SIP identity of the user to publish for. This would imply the = publisher to be part of a company, which is both ilec+SIP service = provider. =20 as easily deployable solution, do we need/want a device-id, which is = human understandable or meaningfull in some way, or does any kind of = unique id meet our reqs? in that case some kind of urn:uuid may be = easier. =20 Walter ________________________________ From: simple-bounces@ietf.org on behalf of Henning Schulzrinne Sent: Sat 6/18/2005 9:08 PM To: Paul Kyzivat Cc: Simple WG Subject: Re: [Simple] tel as device identifier Paul Kyzivat wrote: > Henning, > > I think the problem is that presumably the device itself must decide = if > this can be used as a device-id. I don't know how the device would be > able to decide that it is the only one that will be trying to use the > phone number as a device id. > > If it is a human deciding to do this then I think it can work. Initially, I suspect that most devices won't do any publishing on their own, so this will have to be entered manually. I agree that this is not a long-term or universal solution, but we lack deployable alternatives. For current cell phones, 'tel' should work reasonably well. As far as I know, each cell number is assigned to exactly one device at a time. Even for residential phones, while there might be multiple devices on a single piece of wire, the phone company (ILEC) could certainly assign this as an identifier. These multiple devices act essentially as if they were one - there's no way to reach just one of them. (Indeed, this application motivates my question.) Henning _______________________________________________ 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. =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 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 Mon Jun 20 11:28:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkOC9-0006tC-BA; Mon, 20 Jun 2005 11:28:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkOC6-0006t4-Rg for simple@megatron.ietf.org; Mon, 20 Jun 2005 11:28:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09957 for ; Mon, 20 Jun 2005 11:28:12 -0400 (EDT) Received: from h93074.serverkompetenz.net ([81.169.138.67]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkOZp-0004Xj-Ao for simple@ietf.org; Mon, 20 Jun 2005 11:52:46 -0400 Received: from tester.mmweg (tester.mmweg.RWTH-Aachen.DE [134.130.118.31]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by h93074.serverkompetenz.net (Postfix) with ESMTP id 13F6E24983 for ; Mon, 20 Jun 2005 17:14:29 +0200 (CEST) From: Sebastian Ley To: simple@ietf.org Date: Mon, 20 Jun 2005 17:28:04 +0200 User-Agent: KMail/1.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506201728.04800.sebastian@withouthat.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Subject: [Simple] Note on XCAP directories 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 Hello, I am currently studying the XCAP protocol for my diploma thesis. I have a small remark on section 8.2.1: "If the parent URI has no path separator, it is referring to the directory into which the document should be inserted. If this directory does not exist, the server MUST return a 409 response, [...]" The draft repeatedly states, that directories do not necessarily mean filesystem directories, which is a reasonable assumption, since impementors may want to use database backends. I see two problems: 1) XCAP does not have a means to create "directories". That means that directories must be static and mandated by the application usage. An implementor of a specific application usage would have to make sure that the proper directories are created upon initializing an application usage for a user. In that case this structure should be part of an application usage description. 2) Databases usually have no directory concept. Assuming that implemetors will use database rather than filesystem backends, they need additional logic to apply this concept to databases. So, I propose one of the following: Don't mandate the 409 but mandate that directories must be created if necessary. This adds more flexibility for the application usages, and allows database users to just use the document selector as index, without adding any directory support. Regards, Sebastian -- PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key Fingerprint: A46A 753F AEDC 2C01 BE6E F6DB 97E0 3309 9FD6 E3E6 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 20 11:44:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkORe-0000MJ-27; Mon, 20 Jun 2005 11:44:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkORc-0000ME-Bf for simple@megatron.ietf.org; Mon, 20 Jun 2005 11:44:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11432 for ; Mon, 20 Jun 2005 11:44:14 -0400 (EDT) Received: from mail-src.takas.lt ([212.59.31.78]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkOpL-0004xU-Ff for Simple@ietf.org; Mon, 20 Jun 2005 12:08:48 -0400 Received: from renatus ([85.206.108.177]) by mail-src.takas.lt with Microsoft SMTPSVC(5.0.2195.6713); Mon, 20 Jun 2005 18:44:13 +0300 Message-ID: <007d01c575ae$ea0b1000$3a9efea9@renatus> From: "Renatas Vaiciunas" To: Date: Mon, 20 Jun 2005 18:44:10 +0300 Organization: Personal/Owner MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 20 Jun 2005 15:44:13.0186 (UTC) FILETIME=[E84A2620:01C575AE] X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Simple] (no subject) 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="===============1411567691==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1411567691== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007A_01C575C8.0C5C4610" This is a multi-part message in MIME format. ------=_NextPart_000_007A_01C575C8.0C5C4610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Privacy Act (5U.S.C._552a) $LocalAdmin$ =20 ------=_NextPart_000_007A_01C575C8.0C5C4610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
<mail-src.takas.lt #5.7.1 smtp;550 5.7.1 Access denied>
 
 
Privacy Act=20 (5U.S.C._552a)
$LocalAdmin$   =
------=_NextPart_000_007A_01C575C8.0C5C4610-- --===============1411567691== 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 --===============1411567691==-- From simple-bounces@ietf.org Mon Jun 20 17:57:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkUGX-0003OV-St; Mon, 20 Jun 2005 17:57:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkUGW-0003OQ-CJ for simple@megatron.ietf.org; Mon, 20 Jun 2005 17:57:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13431 for ; Mon, 20 Jun 2005 17:57:09 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkUeI-0006qu-O7 for simple@ietf.org; Mon, 20 Jun 2005 18:21:48 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-4.cisco.com with ESMTP; 20 Jun 2005 14:57:01 -0700 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 j5KLuEoA014290; Mon, 20 Jun 2005 17:56:55 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Jun 2005 17:56:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] tel as device identifier Date: Mon, 20 Jun 2005 17:56:51 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E34716BC@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Simple] tel as device identifier Thread-Index: AcV0JQEl6olYCLfDTUeZBsEn0gyuqABvPOqg From: "Michael Hammer \(mhammer\)" To: "Henning Schulzrinne" , "Simple WG" X-OriginalArrivalTime: 20 Jun 2005 21:56:52.0489 (UTC) FILETIME=[F7790790:01C575E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 You should have mentioned IMEI which GSM phones use. But, to get to the heart of your question, would you consider an IP address a device identifier? I would suspect not, but don't see why one type of routing address should be treated different from another. The use of such addresses could be problematic. There are services where one tel number may alert multiple devices. I don't have a better answer for you, but would just note that on the ENUM list there was much gnashing of teeth over the fact that someone might put an E.164 number into the directory without the user opting-in. They viewed it as a white pages thing, versus a core routing infrastructure dependency. Just wondering what sort of privacy gotchas will result. Mike > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Henning Schulzrinne > Sent: Saturday, June 18, 2005 12:43 PM > To: Simple WG > Subject: [Simple] tel as device identifier >=20 > Currently, there is no really good device identifier=20 > (device-id), as none of the obvious candidates (IMSI, MAC=20 > address, etc) currently have a URN definition. In order to=20 > speed deployment, one quick-and-easy suggestion is to use the=20 > tel URL. While this does not always identify a single device,=20 > in many practical cases of interest, it does. Examples where=20 > this is likely to work reasonably well include mobile phones=20 > and residential analog phones (i.e., without ENUM). >=20 > Comments? >=20 > Henning >=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 Mon Jun 20 21:44:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkXoe-0002Cn-C9; Mon, 20 Jun 2005 21:44:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkXod-0002CM-4X for simple@megatron.ietf.org; Mon, 20 Jun 2005 21:44:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02313 for ; Mon, 20 Jun 2005 21:44:37 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkYCR-0004A7-Tk for simple@ietf.org; Mon, 20 Jun 2005 22:09:16 -0400 Received: from [131.161.248.91] (open-131-161-248-91.cliq.com [131.161.248.91]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j5L1iG103290; Mon, 20 Jun 2005 18:44:16 -0700 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <770e9959d3c738d838e8e7dee219ad3d@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Mon, 20 Jun 2005 18:44:07 -0700 To: "simple@ietf.org WG" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy Subject: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension 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 Everyone, Despite the thread on the list from late March and early April about Basic vs Digest authentication, I don't feel like we came to consensus on this issue. First I would like to apologize for my lack of attention on this particular issue, and that it has remained open for so long. The arguments in favor of Digest authentication included a number of incorrect assumptions (marked "I") which need to be clarified in the draft. Among them: I: Relays for user B get to see the username and password for user A. A: This never happens. user A only sends AUTH requests to *its* relays, never to the relays used to forward requests on to another user. I: User B sends its password in the clear over the network. A: Use of TLS is mandatory, user B only sends its password inside a TLS-protected channel. I: The Security Area Directors will never allow this. A: Based on preliminary discussions, I believe this will be acceptable to the Security ADs. Again, use of TLS is mandatory. This is exactly like the common usage of SMTP using PLAIN user authentication over a TLS-protected channel, which is a very widely deployed model. I: If I use RADIUS I have to send the username and password in the clear A: The MSRP relay can hash the password before sending to the RADIUS server, or send all RADIUS traffic over a protected channel. There are two other concerns with Basic which are accurate: 1. If example.com has an inner relay and an outer relay, credentials for outer.example.com are revealed to inner.example.com as AUTH requests are forwarded to outer.example.com. This limitation is clearly explained in the Security Considerations section. 2. The other issue that Avshalom brought up is that the relay administrator has access to the password, or an attacker who can gain access to the relay machine. While the administrator could mount a dictionary attack on a Digest protected password, its obviously easier to get access to the password when it isn't hashed at all. When I originally tried to map the draft onto Digest, I was planning to do something like this: - realm is a string provided by the server. it SHOULD be the host name of the relay. - the domains parameter is ignored - note that the nonce algorithm based on ETags doesn't work - do not support auth-int, but always include the qop parameter with auth - the digest-uri parameter is the right-most URI in the To-Path header - the alg parameter is ??? - the cnonce and the nonce-count MUST be sent - the Method from A2 is always AUTH - there is never a body for AUTH so A2 is just AUTH: plus the Request-URI - I have no idea what to do about MD5 vs. MD5-sess. - I have no idea whether the nextnonce parameter is useful here. - I don't think the response authentication parameter is useful at all. However, the security considerations needs to describe what would or would not be protected here. Remember that we have no integrity over the Use-Path header from client to outermost relay even if we use this, unless we redefine the A2 to include the value of the Use-Path header instead of the entity-body. The arguments in favor of Basic authentication are: 1. Basic authentication is much simpler to implement than Digest, and the authors feel that with TLS protection of the channel that its security is good enough. We expect MSRP AUTH to be used within a single administrative domain, and the limitation of the server seeing the plain text password is similar to the way that many email services are deployed with TLS. 2. Digest authentication is not a great fit to MSRP and as a result its not obvious what to specify for all the parameters. What do we do? My proposal is to go with Basic. I have updated the draft leaving Basic in place. I feel this is appropriate given the relative security of the base draft, and given what would be needed to do Digest properly. If the consensus of the group is that we should do Digest instead, then I urge someone to propose specific text answering the questions I discuss above, that would go into the draft. thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 21 01:59:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkbnE-00067J-7N; Tue, 21 Jun 2005 01:59:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkbnB-00067E-81 for simple@megatron.ietf.org; Tue, 21 Jun 2005 01:59:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22399 for ; Tue, 21 Jun 2005 01:59:24 -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 1DkcB1-00024p-NN for simple@ietf.org; Tue, 21 Jun 2005 02:24:05 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 Jun 2005 22:59:14 -0700 X-IronPort-AV: i="3.93,216,1115017200"; d="scan'208"; a="281155799:sNHT28204792" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5L5x8lO014044; Mon, 20 Jun 2005 22:59:08 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Jun 2005 23:01:36 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 20 Jun 2005 22:59:09 -0700 Subject: Re: [Simple] MSRP Relays: Transaction and Report model From: Cullen Jennings To: Orit Levin , "simple@ietf.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Jun 2005 06:01:36.0939 (UTC) FILETIME=[AF27E7B0:01C57626] X-Spam-Score: 1.1 (+) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit 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 Thanks for the good catches - I fixed these. On 3/21/05 6:34 PM, "Orit Levin" wrote: > Guys, > There is a couple of contradicting statements in the > draft-ietf-simple-msrp-relays-03 regarding a relay "state machine" > processing a message: > > 1. Text in the bottom of page 5 suggests that in case of the > "failure-flag" being TRUE, the receiving relay MUST immediately response > with "200 OK" to the previous hop. Instead of "200 OK", it should be > "final response". Below is a suggestion for more explicit wording: > > ----------------------------- > If the "failure-flag" is set to TRUE (or is TRUE by default), the > receiving local relay MUST immediately response with one of the final > responses: > - If the final response is 2XX, the previous hop cleans the state. In > case of further local error condition encountered by the local relay > (e.g. parsing, timeout, lack of resources), the local relay is > responsible for constructing the error report and sending it back to the > original source of the message. > - If the final response conveys an error, the previous hop is > responsible for constructing the error report and sending it back to the > original sender of the message. > > If the "failure-flag" is set to PARTIAL and the local relay encounters a > problem (e.g. parsing error, timeout, lack of resources), it is > responsible for constructing the error report and sending it back to the > original source of the message. > > If the "failure-flag" is set to FALSE and a local relay encounters a > problem, the message MUST be dropped silently. > ----------------------------- > > This way it will become consistent with "6.4.1 Forwarding SEND > requests". > > 2. In 6.4.1 itself, there is another problem, though. It currently says > (top of page 18): > > -------------- > If there is a problem further processing the SEND request, or in the > response that the relay receives in sending the SEND request to the > next hop, and the Failure-Report header is "yes" or "partial", then > the relay MUST respond with an appropriate error response in a REPORT > back to the previous hop. > -------------- > > Instead of "back to previous hop" it needs to say "back to original > source of the message". > > 3. Top Page 9. > > "Unlike the SEND request which is acknowledged along every hop, REPORT > responses are never acknowledged." > > Needs to become: > > "Unlike the SEND request which can be acknowledged along every hop, > REPORT responses are never acknowledged." > > Thanks, > Orit. > > _______________________________________________ > 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 Jun 21 06:03:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkfbM-0002GT-9c; Tue, 21 Jun 2005 06:03:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkfbK-0002GO-Fa for simple@megatron.ietf.org; Tue, 21 Jun 2005 06:03:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29885 for ; Tue, 21 Jun 2005 06:03:24 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkfzC-0007pk-V8 for simple@ietf.org; Tue, 21 Jun 2005 06:28:08 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5L9xAT0009958; Tue, 21 Jun 2005 12:59:10 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Jun 2005 13:03:18 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Jun 2005 13:03:18 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jun 2005 13:03:18 +0300 Message-ID: Thread-Topic: [Simple] xcap-diff-00 and xcap-package-03 Thread-Index: AcVxar+S0RPnELOLSPyrK7j9ObmXIgEKV/mA To: X-OriginalArrivalTime: 21 Jun 2005 10:03:18.0969 (UTC) FILETIME=[730A1290:01C57648] X-Spam-Score: 0.3 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: [Simple] simple-presence-rules: Question on Component ID 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, I have a question related to how tuple Contact addresses are handled in = presence authorization. I copied the text in the current draft below. = The draft says that by default the Contact URI should be "randomized". = In SIP, I assume that this, as well as the "obfuscation" option, has to = work so that the Presence Server assings the URI and maintains an = internal mapping between the "randomized" URI and the original contact = URI. This means that the Presence Server (or in theory some other = elements who works together with the PS) becomes a SIP proxy/redirect = for all requests that are destined to the "randomized" Contact URIs. Is = this correct? I can understand how this can work for SIP URIs. However, I think it = becomes infeasible for any other type of URI, given the requirement that = the advertised service must actually be reached using the randomized = URI. For instance, how can a Presence Server reasonably do the = randomization or obfuscation for tel: or mailto:, let alone to a URI = scheme that it does not even understand?=20 Regards, Markus --- 3.3.2.14 Component ID The service and device components both include identifiers (the and elements, respectively), which can reveal information to a watcher about the presentity. However, these identifiers must be present in the document in order for it to be meaningful. As a result, the permission defines transformations that can be applied to these identifiers (both of which are URI). It is an enumerated integer type. Its values are: randomize: This instructs the presence server to randomize the service URI and device ID, such that its value is different in each notification sent to a watcher, and each value is chosen with a minimum of 128 bits of randomness. The precise mechanism for this randomization is a matter of implementation. The service URI MUST still be usable for reaching that particular service, however. The value of this permission is assigned a numeric value of 0. obfuscate: This instructs the presence server to apply a static transformation to the service URI and device ID, such that the actual value is never revealed to the watcher. However, since the transformation is done through a static function, the value seen by the watcher remains unchanged as long as the URI remains unchanged. The service URI MUST still be usable for reaching that particular service, however. The value of this permission is assigned a numeric value of 1. allow: This instructs the presence server to provide the service URI and device ID to the watcher without modification for the purposes of privacy. The value of this permission is assigned a numeric value of 2. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 21 10:33:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkjoG-0001hf-2X; Tue, 21 Jun 2005 10:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkjoE-0001hY-UF for simple@megatron.ietf.org; Tue, 21 Jun 2005 10:33:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24905 for ; Tue, 21 Jun 2005 10:33:00 -0400 (EDT) Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkkCA-0006n6-Ma for simple@ietf.org; Tue, 21 Jun 2005 10:57:47 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5LEWedt004889; Tue, 21 Jun 2005 17:32:44 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Jun 2005 17:32:44 +0300 Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 21 Jun 2005 17:32:43 +0300 Received: from xitami.research.nokia.com (xitami.research.nokia.com [172.21.50.105]) by kusti.research.nokia.com (Postfix) with ESMTP id AFB6793B6A; Tue, 21 Jun 2005 17:32:43 +0300 (EEST) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by xitami.research.nokia.com (Postfix) with ESMTP id 95346124; Tue, 21 Jun 2005 17:32:43 +0300 (EEST) Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-xcap-07.txt From: Jari Urpalainen To: ext Jonathan Rosenberg In-Reply-To: <200506131943.PAA16836@ietf.org> References: <200506131943.PAA16836@ietf.org> Content-Type: text/plain Date: Tue, 21 Jun 2005 17:32:43 +0300 Message-Id: <1119364363.8658.97.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2005 14:32:44.0023 (UTC) FILETIME=[16299070:01C5766E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 On Mon, 2005-06-13 at 15:43 -0400, ext simple-bounces@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. > > Title : The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) > Author(s) : J. Rosenberg > Filename : draft-ietf-simple-xcap-07.txt > Pages : 61 > Date : 2005-6-13 > > This specification defines the Extensible Markup Language (XML) > Configuration Access Protocol (XCAP). XCAP allows a client to read, > write and modify application configuration data, stored in XML format > on a server. XCAP maps XML document sub-trees and element attributes > to HTTP URIs, so that these components can be directly accessed by > HTTP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-07.txt > Hi Jonathan! Some nits: 6.3: instead of "namespace attributes" -> "namespace nodes" 6.3: example has an additional linefeed within the text content of 6.4: examples of xmlns() schemes contain quoted uris -> remove quotation 7.4: "* indicates all children" -> "* indicates all element children" 7.4: I'll propose adding some text to avoid ambiguity when adding new elements when positional constraints are used: e.g. put ~~/foo[3][@id="d"] () would lead to ambiguity, before or after ? same kind of situation e.g. with: put ~~/foo[3] () So I'll propose adding something like this: if positional constraints are used within the node selector the added element must be at the first possible location. 12: when putting to there's some "whitespace magic" when is generated. As these whitespace text node selections are beyond the scope of XCAP, it might be reasonable to clarify it with some text. thanks, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 21 14:31:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DknWm-0007co-RG; Tue, 21 Jun 2005 14:31:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DknWl-0007cj-0G for simple@megatron.ietf.org; Tue, 21 Jun 2005 14:31:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15335 for ; Tue, 21 Jun 2005 14:31:13 -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 1Dknui-00050s-4v for simple@ietf.org; Tue, 21 Jun 2005 14:56:01 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 21 Jun 2005 11:31:04 -0700 X-IronPort-AV: i="3.93,218,1115017200"; d="scan'208"; a="644966217:sNHT28046512" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5LIV1lO009090; Tue, 21 Jun 2005 11:31:02 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Jun 2005 11:33:28 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 21 Jun 2005 11:31:00 -0700 Subject: Re: [Simple] tel as device identifier From: Cullen Jennings To: Henning Schulzrinne , "simple@ietf.org" Message-ID: In-Reply-To: <42B44F00.1040002@cs.columbia.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Jun 2005 18:33:28.0116 (UTC) FILETIME=[B7833F40:01C5768F] X-Spam-Score: 1.1 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit 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 tel is definitely not a unique device identifier - i have many devices with the same tel. Why not just use an UUID URN as a device id. On 6/18/05 9:42 AM, "Henning Schulzrinne" wrote: > Currently, there is no really good device identifier (device-id), as > none of the obvious candidates (IMSI, MAC address, etc) currently have a > URN definition. In order to speed deployment, one quick-and-easy > suggestion is to use the tel URL. While this does not always identify a > single device, in many practical cases of interest, it does. Examples > where this is likely to work reasonably well include mobile phones and > residential analog phones (i.e., without ENUM). > > Comments? > > Henning > > _______________________________________________ > 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 Jun 21 15:53:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkoo0-0005cp-W7; Tue, 21 Jun 2005 15:53:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkonw-0005c5-LI; Tue, 21 Jun 2005 15:53:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25136; Tue, 21 Jun 2005 15:53:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkpBv-0007aB-P8; Tue, 21 Jun 2005 16:17:51 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1Dkonv-0004j2-3O; Tue, 21 Jun 2005 15:53:03 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 21 Jun 2005 15:53:03 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Internet Architecture Board , simple mailing list , RFC Editor Subject: [Simple] Protocol Action: 'The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)' to Proposed Standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The IESG has approved the following document: - 'The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) ' as a Proposed Standard This document is the product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group. The IESG contact persons are Ted Hardie and Scott Hollenbeck. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-07.txt Technical Summary In many communications applications, such as Voice over IP, instant messaging, and presence, it is necessary for network servers to access per-user information in the process of servicing a request. While this per-user information resides on servers within the network, it is managed by the end user themselves. Management can be done through many access points, including the web, a wireless handset, or a PC application. Among these per-user information stores are presence lists and authorization policiies, requirements for which have been specified by the SIMPLE working group. This specification describes a protocol that can be used to manipulate this per-user data. XCAP is essentially a set of conventions for mapping XML documents and document components into HTTP URLs, rules for how the modification of one resource affects another, data validation constraints, and authorization policies associated with access to those resources. Because of this structure, normal HTTP primitives can be used to manipulate the data. XCAP is meant to support the configuration needs for a multiplicity of applications, rather than just a single one. It is not, however, a general purpose XML search protocol or XML database update protocol. Working Group Summary The working group came to consensus on this approach after significant discussion of the trade-offs. Adoption of an existing specification, like XPATH, was considered, but the balance of capabilities did not seem right to the working group; insteada more restricted set of capabilities tuned to this specific use case was agreed. There were comments during the Last Call period, and this document reflects changes made to handle the issues raised. Protocol Quality This document was reviewed for the IESG by Ted Hardie. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 21 16:08:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkp2w-0002HA-HI; Tue, 21 Jun 2005 16:08:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkp2v-0002Go-E2 for simple@megatron.ietf.org; Tue, 21 Jun 2005 16:08:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29141 for ; Tue, 21 Jun 2005 16:08:31 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkpQt-0000Su-53 for simple@ietf.org; Tue, 21 Jun 2005 16:33:20 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 21 Jun 2005 13:08:23 -0700 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5LK8FlO014840; Tue, 21 Jun 2005 13:08:15 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Jun 2005 13:10:46 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 21 Jun 2005 13:08:18 -0700 From: Cullen Jennings To: "simple@ietf.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Jun 2005 20:10:46.0480 (UTC) FILETIME=[4F72E500:01C5769D] X-Spam-Score: 1.1 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy Subject: [Simple] Rev of draft-ietf-simple-msrp-relays 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 Until it shows up in the drafts directory, you can find it at http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-msrp-rela ys-04.html I think that we got all the comments from the mailing list included. The only issue that I am still aware of that might still be open is the thread about Basic+TLS vs. Digest+TLS for AUTH. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 21 19:59:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkseJ-0004Lb-7r; Tue, 21 Jun 2005 19:59:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkseH-0004KO-DK for simple@megatron.ietf.org; Tue, 21 Jun 2005 19:59:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28618 for ; Tue, 21 Jun 2005 19:59:20 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkt2H-0003QD-V0 for simple@ietf.org; Tue, 21 Jun 2005 20:24:10 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id j5LNwX6C024825; Tue, 21 Jun 2005 18:58:33 -0500 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 21 Jun 2005 18:53:24 -0500 Message-ID: From: "Nancy Greene (QC/EMC)" To: "'Paul Kyzivat'" , Ron Shacham Subject: RE: [Simple] MSRP offerer role Date: Tue, 21 Jun 2005 18:58:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) X-Spam-Score: 0.8 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: "Nancy Greene \(QC/EMC\)" , thakolsri@docomolab-euro.com, simple@ietf.org, kellerer@docomolab-euro.com, hgs@cs.columbia.edu 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="===============0409246082==" 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. --===============0409246082== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C576BD.1E1D824E" 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_01C576BD.1E1D824E Content-Type: text/plain; charset="iso-8859-1" There is a draft available defining the base tag for msrp now. If I understand correctly, the callee caps way of defining it in an Accept-Contact or Contact header is just "message", not "+sip.message": http://www.ietf.org/internet-drafts/draft-camarillo-sipping-message-tag-00.t xt Nancy >>> It certainly shouldn't hurt to use callee caps to advertise support, >>> even if nobody else supports it. Depending on others having used >>> callee caps may be a bit dicy. But the situation may be better in the >>> case of MSRP, because there is probably little or no support for it >>> out there yet. You can probably establish a precedent and ensure that >>> all MSRP implementations do advertise support via callee caps. >> >> >> Your point is well taken--that MSRP should be able to grow along with >> its callee-caps. Is there interest in defining this in the MSRP draft? > >Since the way of signaling this in SDP is > > m=message ... > >the callee caps way of representing it is: > > +sip.message Nancy ------_=_NextPart_001_01C576BD.1E1D824E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] MSRP offerer role

There is a draft available defining the base tag for = msrp now. If I understand correctly, the callee caps way of defining it = in an Accept-Contact or Contact header is just "message", not = "+sip.message":

http://www.ietf.org/internet-drafts/draft-camarillo-si= pping-message-tag-00.txt

Nancy


>>> It certainly shouldn't hurt to use = callee caps to advertise support,
>>> even if nobody else supports it. = Depending on others having used
>>> callee caps may be a bit dicy. But the = situation may be better in the
>>> case of MSRP, because there is probably = little or no support for it
>>> out there yet. You can probably = establish a precedent and ensure that
>>> all MSRP implementations do advertise = support via callee caps.
>>
>>
>> Your point is well taken--that MSRP should = be able to grow along with
>> its callee-caps.  Is there interest in = defining this in the MSRP draft?
>
>Since the way of signaling this in SDP is
>
>       m=3Dmessage = ...
>
>the callee caps way of representing it = is:
>
>       = +sip.message

Nancy

------_=_NextPart_001_01C576BD.1E1D824E-- --===============0409246082== 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 --===============0409246082==-- From simple-bounces@ietf.org Tue Jun 21 20:09:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DksoO-0000mW-LP; Tue, 21 Jun 2005 20:09:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DksoN-0000mO-HJ for simple@megatron.ietf.org; Tue, 21 Jun 2005 20:09:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29364 for ; Tue, 21 Jun 2005 20:09:46 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DktCN-0003fH-SF for simple@ietf.org; Tue, 21 Jun 2005 20:34:37 -0400 Received: from [192.168.0.31] (pool-141-153-173-119.mad.east.verizon.net [141.153.173.119]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5M08gWs002113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jun 2005 20:08:43 -0400 (EDT) Message-ID: <42B8AC0D.6040306@cs.columbia.edu> Date: Tue, 21 Jun 2005 20:08:45 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple] tel as device identifier References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 Cullen Jennings wrote: > tel is definitely not a unique device identifier - i have many devices with > the same tel. Why not just use an UUID URN as a device id. My vague recollection was that UUID were considered unsuitable and therefore removed from the data model draft. I'm looking for other deployable solutions. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 21 21:11:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dktlt-0005S0-1o; Tue, 21 Jun 2005 21:11:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dktlr-0005Rk-DP for simple@megatron.ietf.org; Tue, 21 Jun 2005 21:11:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04016 for ; Tue, 21 Jun 2005 21:11:13 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dku9t-0005A0-5i for simple@ietf.org; Tue, 21 Jun 2005 21:36:05 -0400 Received: from [64.101.100.88] ([64.101.100.88]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j5M1DIii006056 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 21 Jun 2005 20:13:19 -0500 In-Reply-To: <42B8AC0D.6040306@cs.columbia.edu> References: <42B8AC0D.6040306@cs.columbia.edu> 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] tel as device identifier Date: Tue, 21 Jun 2005 20:09:59 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "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 On Jun 21, 2005, at 7:08 PM, Henning Schulzrinne wrote: > Cullen Jennings wrote: >> tel is definitely not a unique device identifier - i have many >> devices with >> the same tel. Why not just use an UUID URN as a device id. > > My vague recollection was that UUID were considered unsuitable and > therefore removed from the data model draft. I'm looking for other > deployable solutions. > IMSI, IMEI, ESN, MEID, and ethernet MAC addresses all come to mind as relatively unique device identifiers. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 21 21:15:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dktq3-0007id-9v; Tue, 21 Jun 2005 21:15:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dktq1-0007gA-C5 for simple@megatron.ietf.org; Tue, 21 Jun 2005 21:15:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04300 for ; Tue, 21 Jun 2005 21:15:31 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkuE2-0005FC-Ar for simple@ietf.org; Tue, 21 Jun 2005 21:40:23 -0400 Received: from [192.168.0.31] (pool-141-153-173-119.mad.east.verizon.net [141.153.173.119]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5M1EOfb008063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jun 2005 21:14:25 -0400 (EDT) Message-ID: <42B8BB77.3050606@cs.columbia.edu> Date: Tue, 21 Jun 2005 21:14:31 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Simple] tel as device identifier References: <42B8AC0D.6040306@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "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 > IMSI, IMEI, ESN, MEID, and ethernet MAC addresses all come to mind as > relatively unique device identifiers. Agreed, but do URN forms of these exist? I think it would be quite useful if somebody could define urn:imsi: urn:imei: urn:mac: etc. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 22 06:24:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl2Pc-0002Pa-V8; Wed, 22 Jun 2005 06:24:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl2Pb-0002PV-AR for simple@megatron.ietf.org; Wed, 22 Jun 2005 06:24:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21739 for ; Wed, 22 Jun 2005 06:24:48 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl2nh-00025E-3g for simple@ietf.org; Wed, 22 Jun 2005 06:49:46 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j5MAOec4012002; Wed, 22 Jun 2005 05:24:41 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Jun 2005 11:24:39 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290523@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Henning Schulzrinne'" Subject: RE: [Simple] tel as device identifier Date: Wed, 22 Jun 2005 11:24:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 For IMSI, it is done for a different purpose but http://www.3gpp.org/ftp/Specs/html-info/23003.htm subclause 13.3 converts an IMSI into a URL, so I guess it could also specify its use as a URN fairly easily. For those who don't want all the details, you end up with something like: 234150999999999@ims.mnc015.mcc234.3gppnetwork.org regards Keith > -----Original Message----- > From: simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org]On Behalf > Of Henning Schulzrinne > Sent: 22 June 2005 02:15 > To: Dean Willis > Cc: Cullen Jennings; simple@ietf.org > Subject: Re: [Simple] tel as device identifier > > > > > IMSI, IMEI, ESN, MEID, and ethernet MAC addresses all come > to mind as > > relatively unique device identifiers. > > Agreed, but do URN forms of these exist? I think it would be quite > useful if somebody could define > > urn:imsi: > urn:imei: > urn:mac: > > etc. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 22 09:10:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4zW-0004yA-La; Wed, 22 Jun 2005 09:10:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4zU-0004xQ-NV for simple@megatron.ietf.org; Wed, 22 Jun 2005 09:10:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06871 for ; Wed, 22 Jun 2005 09:10:02 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl5Nb-0007I2-UZ for simple@ietf.org; Wed, 22 Jun 2005 09:35:01 -0400 Received: from [192.168.0.31] (pool-141-153-173-119.mad.east.verizon.net [141.153.173.119]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5MD9wZ0004343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jun 2005 09:10:02 -0400 (EDT) Message-ID: <42B96300.8020709@cs.columbia.edu> Date: Wed, 22 Jun 2005 09:09:20 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Simple] tel as device identifier References: <475FF955A05DD411980D00508B6D5FB00C290523@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C290523@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 Drage, Keith (Keith) wrote: > For IMSI, it is done for a different purpose but http://www.3gpp.org/ftp/Specs/html-info/23003.htm subclause 13.3 converts an IMSI into a URL, so I guess it could also specify its use as a URN fairly easily. > > For those who don't want all the details, you end up with something like: > > 234150999999999@ims.mnc015.mcc234.3gppnetwork.org Is this a SIP URL, an HTTP URL or something else? A URL without a scheme isn't a URL... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 22 12:08:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl7mN-0001mq-TY; Wed, 22 Jun 2005 12:08:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl7mN-0001l3-4n for simple@megatron.ietf.org; Wed, 22 Jun 2005 12:08:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27440 for ; Wed, 22 Jun 2005 12:08:40 -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 1Dl8AW-0005Sc-Fk for simple@ietf.org; Wed, 22 Jun 2005 12:33:41 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 22 Jun 2005 09:08:33 -0700 X-IronPort-AV: i="3.93,221,1115017200"; d="scan'208"; a="645128061:sNHT470660822" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5MG8I9O023398; Wed, 22 Jun 2005 09:08:28 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 09:01:09 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 22 Jun 2005 08:58:41 -0700 Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension From: Cullen Jennings To: Rohan Mahy , "simple@ietf.org" Message-ID: In-Reply-To: <770e9959d3c738d838e8e7dee219ad3d@ekabal.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Jun 2005 16:01:09.0646 (UTC) FILETIME=[9AF922E0:01C57743] X-Spam-Score: 1.1 (+) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit 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 have not really provided much input on this issues - that is partially because I could go either way if we could just finish this. That said, let me outline a few points that I see as relevant to the decision.... The significant argument I have seen made an attack where someone broke into the relay server (or had access to it because they were the administrator) of it and thus gained access to all the stored passwords. We are worried about people using the information to log in as the a given user to this relay and also, assuming the users use the same password other places, to long on to other boxes. This is definitely an important attack to consider. If we go with the Digest route, any reasonable server will end up storing H(A1). It may do this directly or via a radius server. Now if someone gets H(A1), the can not discover my password and long on to some other server where I may have used the same password. However, they can use that to log on to this same relay server as me. The last sentence is important, using Digest, if the attacker gets my stored H(A1) then can log on as me to this box (but not others). Now consider the Basic+TLS approach, any reasonable implementation will store the usual hash of password plus salt solution. If an attacker gets this stored information, they can log on other boxes, but even more than this, they can not log onto this box using what they learned. Both solutions protect against the stored information being used to log on another box and the Digest+TLS also protects against it being used to log on the same relay. I'm not sure I view this as an amazing advantage for Basic+TLS - I view the real advantage of Basic+TLS be the simplicity it brings and that much of what Digest is designed to provide, MSRP has no use for. Next point has to do with this being a password at all - if we think this is something a human generates, remembers, and types in, well then it is a password and the above attacks are worth considering. Personally, I think it is going to be come configuration information generated by the system and downloaded to the client then used to connect to the relay. In this form it is far more of a cookie than a password and the above attacks are far less interesting because there will not be other systems that use the same password. Cullen On 6/20/05 6:44 PM, "Rohan Mahy" wrote: > Hi Everyone, > > Despite the thread on the list from late March and early April about > Basic vs Digest authentication, I don't feel like we came to consensus > on this issue. First I would like to apologize for my lack of attention > on this particular issue, and that it has remained open for so long. > > The arguments in favor of Digest authentication included a number of > incorrect assumptions (marked "I") which need to be clarified in the > draft. Among them: > > I: Relays for user B get to see the username and password for user A. > A: This never happens. user A only sends AUTH requests to *its* > relays, never to the relays used to forward requests on to another > user. > > I: User B sends its password in the clear over the network. > A: Use of TLS is mandatory, user B only sends its password inside a > TLS-protected channel. > > I: The Security Area Directors will never allow this. > A: Based on preliminary discussions, I believe this will be acceptable > to the Security ADs. Again, use of TLS is mandatory. This is exactly > like the common usage of SMTP using PLAIN user authentication over a > TLS-protected channel, which is a very widely deployed model. > > I: If I use RADIUS I have to send the username and password in the clear > A: The MSRP relay can hash the password before sending to the RADIUS > server, or send all RADIUS traffic over a protected channel. > > There are two other concerns with Basic which are accurate: > > 1. If example.com has an inner relay and an outer relay, credentials > for outer.example.com are revealed to inner.example.com as AUTH > requests are forwarded to outer.example.com. This limitation is > clearly explained in the Security Considerations section. > > 2. The other issue that Avshalom brought up is that the relay > administrator has access to the password, or an attacker who can gain > access to the relay machine. While the administrator could mount a > dictionary attack on a Digest protected password, its obviously easier > to get access to the password when it isn't hashed at all. > > When I originally tried to map the draft onto Digest, I was planning to > do something like this: > > - realm is a string provided by the server. it SHOULD be the host name > of the relay. > - the domains parameter is ignored > - note that the nonce algorithm based on ETags doesn't work > - do not support auth-int, but always include the qop parameter with > auth > - the digest-uri parameter is the right-most URI in the To-Path header > - the alg parameter is ??? > - the cnonce and the nonce-count MUST be sent > - the Method from A2 is always AUTH > - there is never a body for AUTH so A2 is just AUTH: plus the > Request-URI > - I have no idea what to do about MD5 vs. MD5-sess. > - I have no idea whether the nextnonce parameter is useful here. > - I don't think the response authentication parameter is useful at all. > However, the security considerations needs to describe what would or > would not be protected here. Remember that we have no integrity over > the Use-Path header from client to outermost relay even if we use this, > unless we redefine the A2 to include the value of the Use-Path header > instead of the entity-body. > > The arguments in favor of Basic authentication are: > > 1. Basic authentication is much simpler to implement than Digest, and > the authors feel that with TLS protection of the channel that its > security is good enough. We expect MSRP AUTH to be used within a single > administrative domain, and the limitation of the server seeing the > plain text password is similar to the way that many email services are > deployed with TLS. > > 2. Digest authentication is not a great fit to MSRP and as a result its > not obvious what to specify for all the parameters. > > > What do we do? My proposal is to go with Basic. I have updated the > draft leaving Basic in place. I feel this is appropriate given the > relative security of the base draft, and given what would be needed to > do Digest properly. If the consensus of the group is that we should do > Digest instead, then I urge someone to propose specific text answering > the questions I discuss above, that would go into the draft. > > thanks, > -rohan > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 22 13:14:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl8oA-00085q-Ae; Wed, 22 Jun 2005 13:14:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl8o9-00085N-00 for simple@megatron.ietf.org; Wed, 22 Jun 2005 13:14:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03770 for ; Wed, 22 Jun 2005 13:14:33 -0400 (EDT) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl9CI-0007o7-Kn for simple@ietf.org; Wed, 22 Jun 2005 13:39:35 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j5MHEPmf148826 for ; Wed, 22 Jun 2005 17:14:25 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5MHEOe6164008 for ; Wed, 22 Jun 2005 19:14:24 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j5MHEOQh031759 for ; Wed, 22 Jun 2005 19:14:24 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j5MHEO6s031756; Wed, 22 Jun 2005 19:14:24 +0200 In-Reply-To: To: Cullen Jennings Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04112005NP April 11, 2005 Message-ID: From: Avshalom Houri Date: Wed, 22 Jun 2005 20:14:23 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(V70_M4_01112005 Sidepack 2802|March 1, 2005) at 22/06/2005 20:14:23, Serialize complete at 22/06/2005 20:14:23 X-Spam-Score: 1.8 (+) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: simple , , ietf.org.cnri.reston.va.us 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="===============0665221020==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============0665221020== Content-Type: text/html; charset="US-ASCII"
Cullen,

Not sure I understand.

In digest, the server will send a nonce to the user thus preventing replay attacks by replacing the nonce every time.
The hashed value stored in the server can not be used for logging again to the server since the server will accept only nonced passwords.

In basic authentication anyone that has an access to the server code may get the cleartext password and do with it whatever they want.

Avshalom



Cullen Jennings <fluffy@cisco.com>
Sent by: simple-bounces@ietf.org

22/06/2005 06:58 PM

To
Rohan Mahy <rohan@ekabal.com>, "simple@ietf.org" <simple@ietf.org>
cc
Subject
Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP        relays extension






I have not really provided much input on this issues - that is partially
because I could go either way if we could just finish this. That said, let
me outline a few points that I see as relevant to the decision....

The significant argument  I have seen made an attack where someone broke
into the relay server (or had access to it because they were the
administrator) of it and thus gained access to all the stored passwords. We
are worried about people using the information to log in as the a given user
to this relay and also, assuming the users use the same password other
places, to long on to other boxes. This is definitely an important attack to
consider.

If we go with the Digest route, any reasonable server will end up storing
H(A1). It may do this directly or via a radius server. Now if someone gets
H(A1), the can not discover my password and long on to some other server
where I may have used the same password. However, they can use that to log
on to this same relay server as me. The last sentence is important, using
Digest, if the attacker gets my stored H(A1) then can log on as me to this
box (but not others).

Now consider the Basic+TLS approach, any reasonable implementation will
store the usual hash of password plus salt solution. If an attacker gets
this stored information, they can log on other boxes, but even more than
this, they can not log onto this box using what they learned.

Both solutions protect against the stored information being used to log on
another box and the Digest+TLS also protects against it being used to log on
the same relay.

I'm not sure I view this as an amazing advantage for Basic+TLS - I view the
real advantage of Basic+TLS be the simplicity it brings and that much of
what Digest is designed to provide, MSRP has no use for.

Next point has to do with this being a password at all - if we think this is
something a human generates, remembers, and types in, well then it is a
password and the above attacks are worth considering. Personally, I think it
is going to be come configuration information generated by the system and
downloaded to the client then used to connect to the relay. In this form it
is far more of a cookie than a password and the above attacks are far less
interesting because there will not be other systems that use the same
password.

Cullen



On 6/20/05 6:44 PM, "Rohan Mahy" <rohan@ekabal.com> wrote:

> Hi Everyone,
>
> Despite the thread on the list from late March and early April about
> Basic vs Digest authentication, I don't feel like we came to consensus
> on this issue. First I would like to apologize for my lack of attention
> on this particular issue, and that it has remained open for so long.
>
> The arguments in favor of Digest authentication included a number of
> incorrect assumptions (marked "I") which need to be clarified in the
> draft.  Among them:
>
> I: Relays for user B get to see the username and password for user A.
> A: This never happens.  user A only sends AUTH requests to *its*
> relays, never to the relays used to forward requests on to another
> user.
>
> I: User B sends its password in the clear over the network.
> A: Use of TLS is mandatory, user B only sends its password inside a
> TLS-protected channel.
>
> I: The Security Area Directors will never allow this.
> A: Based on preliminary discussions, I believe this will be acceptable
> to the Security ADs.  Again, use of TLS is mandatory.  This is exactly
> like the common usage of SMTP using PLAIN user authentication over a
> TLS-protected channel, which is a very widely deployed model.
>
> I: If I use RADIUS I have to send the username and password in the clear
> A: The MSRP relay can hash the password before sending to the RADIUS
> server, or send all RADIUS traffic over a protected channel.
>
> There are two other concerns with Basic which are accurate:
>
> 1. If example.com has an inner relay and an outer relay, credentials
> for outer.example.com are revealed to inner.example.com as AUTH
> requests are forwarded to outer.example.com.  This limitation is
> clearly explained in the Security Considerations section.
>
> 2. The other issue that Avshalom brought up is that the relay
> administrator has access to the password, or an attacker who can gain
> access to the relay machine.  While the administrator could mount a
> dictionary attack on a Digest protected password, its obviously easier
> to get access to the password when it isn't hashed at all.
>
> When I originally tried to map the draft onto Digest, I was planning to
> do something like this:
>
> - realm is a string provided by the server. it SHOULD be the host name
> of the relay.
> - the domains parameter is ignored
> - note that the nonce algorithm based on ETags doesn't work
> - do not support auth-int, but always include the qop parameter with
> auth
> - the digest-uri parameter is the right-most URI in the To-Path header
> - the alg parameter is ???
> - the cnonce and the nonce-count MUST be sent
> - the Method from A2 is always AUTH
> - there is never a body for AUTH so A2 is just AUTH: plus the
> Request-URI
> - I have no idea what to do about MD5 vs. MD5-sess.
> - I have no idea whether the nextnonce parameter is useful here.
> - I don't think the response authentication parameter is useful at all.
>   However, the security considerations needs to describe what would or
> would not be protected here.  Remember that we have no integrity over
> the Use-Path header from client to outermost relay even if we use this,
> unless we redefine the A2 to include the value of the Use-Path header
> instead of the entity-body.
>
> The arguments in favor of Basic authentication are:
>
> 1. Basic authentication is much simpler to implement than Digest, and
> the authors feel that with TLS protection of the channel that its
> security is good enough. We expect MSRP AUTH to be used within a single
> administrative domain, and the limitation of the server seeing the
> plain text password is similar to the way that many email services are
> deployed with TLS.
>
> 2. Digest authentication is not a great fit to MSRP and as a result its
> not obvious what to specify for all the parameters.
>
>
> What do we do?  My proposal is to go with Basic.  I have updated the
> draft leaving Basic in place.  I feel this is appropriate given the
> relative security of the base draft, and given what would be needed to
> do Digest properly.  If the consensus of the group is that we should do
> Digest instead, then I urge someone to propose specific text answering
> the questions I discuss above, that would go into the draft.
>
> thanks,
> -rohan
>
>
> _______________________________________________
> 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
--===============0665221020== 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 --===============0665221020==-- From simple-bounces@ietf.org Wed Jun 22 15:50:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlBEv-0007pQ-Nm; Wed, 22 Jun 2005 15:50:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlBEc-0007jq-Nh; Wed, 22 Jun 2005 15:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23276; Wed, 22 Jun 2005 15:50:04 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlBcm-0000CX-1y; Wed, 22 Jun 2005 16:15:04 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DlBEX-0004Xb-UZ; Wed, 22 Jun 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 22 Jun 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-msrp-relays-04.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : Relay Extensions for the Message Sessions Relay Protocol (MSRP) Author(s) : C. Jennings, R. Mahy Filename : draft-ietf-simple-msrp-relays-04.txt Pages : 28 Date : 2005-6-22 The SIMPLE Working Group uses two separate models for conveying instant messages. Pager-mode messages stand alone and are not part of a SIP (Session Initiation Protocol) session, whereas Session-mode messages are setup as part of a session using the SIP protocol. MSRP (Message Sessions Relay Protocol) is a protocol for near-real-time, peer-to-peer exchange of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-relays-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-msrp-relays-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-msrp-relays-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-22145218.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-msrp-relays-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-msrp-relays-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-22145218.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Jun 22 16:21:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlBij-0003L3-9y; Wed, 22 Jun 2005 16:21:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlBih-0003Kj-OL for simple@megatron.ietf.org; Wed, 22 Jun 2005 16:21:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29705 for ; Wed, 22 Jun 2005 16:21:05 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlBvU-0002Jf-NZ for simple@ietf.org; Wed, 22 Jun 2005 16:34:26 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 22 Jun 2005 13:09:14 -0700 X-IronPort-AV: i="3.93,221,1115017200"; d="scan'208"; a="193493514:sNHT26930560" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5MK93od014154; Wed, 22 Jun 2005 13:09:08 -0700 (PDT) Received: from 10.32.130.34 ([10.32.130.34]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 22 Jun 2005 20:11:36 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 22 Jun 2005 13:09:07 -0700 Subject: Re: [Simple] tel as device identifier From: Cullen Jennings To: Henning Schulzrinne , Dean Willis Message-ID: In-Reply-To: <42B8BB77.3050606@cs.columbia.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 On 6/21/05 6:14 PM, "Henning Schulzrinne" wrote: > >> IMSI, IMEI, ESN, MEID, and ethernet MAC addresses all come to mind as >> relatively unique device identifiers. I might be wrong but I think the answer is yes they do and it is called uuid _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 22 17:39:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlCw0-00041X-VL; Wed, 22 Jun 2005 17:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlCvz-00041O-4R for simple@megatron.ietf.org; Wed, 22 Jun 2005 17:38:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08045 for ; Wed, 22 Jun 2005 17:38:55 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlDKA-0003qI-HT for simple@ietf.org; Wed, 22 Jun 2005 18:03:59 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j5MLcnmD008316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jun 2005 17:38:50 -0400 (EDT) Message-ID: <42B9DA64.7070502@cs.columbia.edu> Date: Wed, 22 Jun 2005 17:38:44 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple] tel as device identifier References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" , Dean Willis 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 It seems like we had this discussion before. The conclusion was, if I recall correctly, that the UUID "experts" advised Jonathan that this would not be an appropriate device identifier since the UUID contains time-dependent components (see http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-05.txt, Section 4.1.2) and one would have to kludge some pseudo-UUID that set these values to, say, zero. Cullen Jennings wrote: > On 6/21/05 6:14 PM, "Henning Schulzrinne" wrote: > > >>>IMSI, IMEI, ESN, MEID, and ethernet MAC addresses all come to mind as >>>relatively unique device identifiers. > > > I might be wrong but I think the answer is yes they do and it is called uuid > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 22 17:45:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlD1w-0005Wj-Ft; Wed, 22 Jun 2005 17:45:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlD1u-0005WU-8y for simple@megatron.ietf.org; Wed, 22 Jun 2005 17:45:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08506 for ; Wed, 22 Jun 2005 17:45:03 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlDQ5-00047l-Sj for simple@ietf.org; Wed, 22 Jun 2005 18:10:07 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Jun 2005 14:44:56 -0700 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5MLirVX002771; Wed, 22 Jun 2005 14:44:54 -0700 (PDT) Received: from 10.32.130.34 ([10.32.130.34]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 22 Jun 2005 21:47:21 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 22 Jun 2005 14:44:52 -0700 Subject: Re: [Simple] tel as device identifier From: Cullen Jennings To: Henning Schulzrinne Message-ID: In-Reply-To: <42B9DA64.7070502@cs.columbia.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" , Dean Willis 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 Yes, but I think that was about trying to correlate things from various applications on same device. It seem the case you are interesting in you just want a stable unique identifier for each application on the device so I'm not sure that I see any problem with the time based stuff. Anyways, I don't know if UUID is right or not but it seemed to me that tel was not right. On 6/22/05 2:38 PM, "Henning Schulzrinne" wrote: > It seems like we had this discussion before. The conclusion was, if I > recall correctly, that the UUID "experts" advised Jonathan that this > would not be an appropriate device identifier since the UUID contains > time-dependent components (see > http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-05.txt, > Section 4.1.2) and one would have to kludge some pseudo-UUID that set > these values to, say, zero. > > Cullen Jennings wrote: >> On 6/21/05 6:14 PM, "Henning Schulzrinne" wrote: >> >> >>>> IMSI, IMEI, ESN, MEID, and ethernet MAC addresses all come to mind as >>>> relatively unique device identifiers. >> >> >> I might be wrong but I think the answer is yes they do and it is called uuid >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 23 00:27:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlJJP-0003nS-8a; Thu, 23 Jun 2005 00:27:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlJJN-0003nN-Im for simple@megatron.ietf.org; Thu, 23 Jun 2005 00:27:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08736 for ; Thu, 23 Jun 2005 00:27:29 -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 1DlJhd-0004pL-CR for simple@ietf.org; Thu, 23 Jun 2005 00:52:37 -0400 Received: from [192.168.0.102] (c-24-1-149-120.hsd1.tx.comcast.net [24.1.149.120]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j5N4REl6073761 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 22 Jun 2005 23:27:15 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <01b07a25c7bb56ac58189b14ea92bc49@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: WGLC: MSRP relays (was Fwd: [Simple] I-D ACTION:draft-ietf-simple-msrp-relays-04.txt) Date: Wed, 22 Jun 2005 23:28:09 -0500 To: Simple WG X-Mailer: Apple Mail (2.622) Received-SPF: pass (nostrum.com: 24.1.149.120 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 All - Most of this draft has been intensely discussed. We have one remaining issue that I'm not convinced we have consensus around (Digest/Basic). Rohan has started a thread to close it. Please help bring that thread to a close quickly. Anticipating that we will be able to close that discussion, I'm issuing a WGLC on this version of the document. Please have your comments in by July 2nd. This will give us time to rev the draft based on the comments before the ID cutoff. RjS Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: June 22, 2005 2:50:01 PM CDT > To: i-d-announce@ietf.org > Cc: simple@ietf.org > Subject: [Simple] I-D ACTION:draft-ietf-simple-msrp-relays-04.txt > > 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 : Relay Extensions for the Message Sessions Relay Protocol > (MSRP) > Author(s) : C. Jennings, R. Mahy > Filename : draft-ietf-simple-msrp-relays-04.txt > Pages : 28 > Date : 2005-6-22 > > The SIMPLE Working Group uses two separate models for conveying > instant messages. Pager-mode messages stand alone and are not part > of a SIP (Session Initiation Protocol) session, whereas Session-mode > messages are setup as part of a session using the SIP protocol. > MSRP > (Message Sessions Relay Protocol) is a protocol for near-real-time, > peer-to-peer exchange of binary content without intermediaries, > which > is designed to be signaled using a separate rendezvous protocol such > as SIP. This document introduces the notion of message relay > intermediaries to MSRP and describes the extensions necessary to use > them. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-relays > -04.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-simple-msrp-relays-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-simple-msrp-relays-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2005-6-22145218.I-D@ietf.org> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 23 10:43:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlSvS-00081z-0C; Thu, 23 Jun 2005 10:43:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlSvR-00081u-7D for simple@megatron.ietf.org; Thu, 23 Jun 2005 10:43:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18219 for ; Thu, 23 Jun 2005 10:43:27 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlTJl-0007Wt-Si for simple@ietf.org; Thu, 23 Jun 2005 11:08:39 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 23 Jun 2005 10:43:20 -0400 X-IronPort-AV: i="3.93,224,1115006400"; d="scan'208"; a="59277582:sNHT26310232" 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 j5NEaOaW023377; Thu, 23 Jun 2005 10:42:33 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Jun 2005 10:42:02 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Jun 2005 10:42:00 -0400 Message-ID: <42BACA38.9050807@cisco.com> Date: Thu, 23 Jun 2005 10:42:00 -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: fluffy@cisco.com, simple@ietf.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2005 14:42:00.0548 (UTC) FILETIME=[B6B40A40:01C57801] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Subject: [Simple] Re: WGLC of draft-ietf-simple-msrp-relays-04.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Just a couple of little things: In the 2nd and 3rd REPORT messages on page 7, there seems to be an extra From-Path header. Last paragraph of 3.1 - says that the URI can only be used once. So the client will need to do a separate AUTH for each session. I thought we were going to permit the client to add extra data on the end and use the result for multiple sessions. When sending an AUTH request, the client MAY add an Expires header to request a MSRP URI that is valid for no longer than the provided interval (an whole number of seconds). The server will include an Expires header in a successful response indicating how long its URI from the Use-Path will be valid. Note that each server can return an independent expiration time. If we are authenticating with a pair of relays R1 and R2, getting uris U1 and U2 with expiration times E1 and E2, what happens if E1 ne E2? It seems that a particular session using a path with U1 and U2 will only be good for the min(E1,E2). This might be worth pointing out. Something like: Note that each server can return an independent expiration time. A session will become inoperable after the shortest expiration time of URIs on its path passes. Perhaps this is sufficiently obvious that it need not be said - I don't feel strongly about it. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 23 11:24:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlTYp-0000vU-Mx; Thu, 23 Jun 2005 11:24:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlTYn-0000vP-T0 for simple@megatron.ietf.org; Thu, 23 Jun 2005 11:24:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23566 for ; Thu, 23 Jun 2005 11:24:08 -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 1DlTx8-0001Gd-Rx for simple@ietf.org; Thu, 23 Jun 2005 11:49:20 -0400 Received: from [192.168.1.100] (dsl001-129-066.dfw1.dsl.speakeasy.net [72.1.129.66]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j5NFO0LW020795 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 23 Jun 2005 10:24:01 -0500 (CDT) (envelope-from rjsparks@nostrum.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: Robert Sparks Date: Thu, 23 Jun 2005 10:24:51 -0500 To: Simple WG X-Mailer: Apple Mail (2.622) Received-SPF: pass (nostrum.com: 72.1.129.66 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLE meeting in Paris 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 Folks - Just a heads up - Given the use of our slots in Minneapolis and the current set of threads on the list, I'm having a hard time justifying to myself a request for more than a single 2.5 hr slot in Paris. That's what I'm currently planning to put in a request for. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 23 11:32:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlThF-0002sT-SD; Thu, 23 Jun 2005 11:32:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlThE-0002sM-4i for simple@megatron.ietf.org; Thu, 23 Jun 2005 11:32:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24582 for ; Thu, 23 Jun 2005 11:32:50 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlU5Z-0001mF-9a for simple@ietf.org; Thu, 23 Jun 2005 11:58:02 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j5NFWimD013156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jun 2005 11:32:45 -0400 (EDT) Message-ID: <42BAD617.5040104@cs.columbia.edu> Date: Thu, 23 Jun 2005 11:32:39 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Simple] SIMPLE meeting in Paris References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Simple 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 I think the theme for the meeting should be "what do we need to do to finish this item up well before the next meeting"? Our charter ran out in September 2004 (and we aren't even working on the last charter item, as far as I can tell). Having commitments and WGLC dates planned ahead of time might also provide additional thrust. Robert Sparks wrote: > Folks - > > Just a heads up - > > Given the use of our slots in Minneapolis and the current set of threads > on the list, > I'm having a hard time justifying to myself a request for more than a > single 2.5 hr > slot in Paris. That's what I'm currently planning to put in a request for. > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 23 12:53:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlUx3-0005Vj-WC; Thu, 23 Jun 2005 12:53:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlUx2-0005Ve-PN for simple@megatron.ietf.org; Thu, 23 Jun 2005 12:53:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03657 for ; Thu, 23 Jun 2005 12:53:14 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlVLO-000654-Ci for simple@ietf.org; Thu, 23 Jun 2005 13:18:27 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 23 Jun 2005 09:53:05 -0700 X-IronPort-AV: i="3.93,224,1115017200"; d="scan'208"; a="193722774:sNHT28803276" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5NGqUVx016506; Thu, 23 Jun 2005 09:53:03 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Jun 2005 12:52:45 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Jun 2005 12:53:02 -0400 Message-ID: <42BAE8E7.4010405@cisco.com> Date: Thu, 23 Jun 2005 12:52:55 -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: Henning Schulzrinne Subject: Re: [Simple] SIMPLE meeting in Paris References: <42BAD617.5040104@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2005 16:53:02.0533 (UTC) FILETIME=[04CFBF50:01C57814] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Simple 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 I think there is a subject that hasn't been seriously discussed that IMO SHOULD be within the charter of SIMPLE. If it looks like everything else is wrapping up it may be time to consider it. That subject is the coexistence and/or interoperation of page mode and session mode IM, and perhaps other forms such as XMPP. I think we are on a path towards a balkanized world where different even those who "implement SIMPLE" can't exchange IMs. Exactly how to deal with this - usage guidelines, gateways, etc. is an open question to me right now. Another area where we have so far punted in presence composition policies. However here it may just be that the time isn't right - that nobody has enough experience to propose something useful. The above is not intended to suggest that we need more time in Paris. But it is intended to suggest that it might be premature for SIMPLE to close up shop. We might want to discuss charter changes. Paul Henning Schulzrinne wrote: > I think the theme for the meeting should be "what do we need to do to > finish this item up well before the next meeting"? Our charter ran out > in September 2004 (and we aren't even working on the last charter item, > as far as I can tell). Having commitments and WGLC dates planned ahead > of time might also provide additional thrust. > > Robert Sparks wrote: > >> Folks - >> >> Just a heads up - >> >> Given the use of our slots in Minneapolis and the current set of >> threads on the list, >> I'm having a hard time justifying to myself a request for more than a >> single 2.5 hr >> slot in Paris. That's what I'm currently planning to put in a request >> for. >> >> RjS >> >> >> _______________________________________________ >> 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 Thu Jun 23 14:04:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlW4N-0002nl-Ut; Thu, 23 Jun 2005 14:04:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlW4M-0002ng-Hh for simple@megatron.ietf.org; Thu, 23 Jun 2005 14:04:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11067 for ; Thu, 23 Jun 2005 14:04:51 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlWSg-0001M8-57 for simple@ietf.org; Thu, 23 Jun 2005 14:30:04 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5NI4G011157; Thu, 23 Jun 2005 14:04:16 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jun 2005 14:04:16 -0400 Message-ID: <1ECE0EB50388174790F9694F77522CCF02ECE4DB@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "'Cullen Jennings'" , "'Henning Schulzrinne'" , "'simple@ietf.org'" Subject: RE: [Simple] tel as device identifier Date: Thu, 23 Jun 2005 14:04:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1986422681==" 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. --===============1986422681== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5781D.F3D4413B" 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_01C5781D.F3D4413B Content-Type: text/plain Yeah, I agree with Cullen. Tel is definitively not a device identifier. Even in most old traditional PBXs, you have a device identifier that is used internally for that purpose. There are hunt group numbers, 800 numbers, portable numbers, and with SIP now, my telephone numbers rings a whole bunch of different devices. It is anything but a device identifier, and the trend is intensifying. > -----Original Message----- > From: simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: Tuesday, June 21, 2005 11:31 > To: Henning Schulzrinne; simple@ietf.org > Subject: Re: [Simple] tel as device identifier > > > > tel is definitely not a unique device identifier - i have > many devices with the same tel. Why not just use an UUID URN > as a device id. > > > > > On 6/18/05 9:42 AM, "Henning Schulzrinne" wrote: > > > Currently, there is no really good device identifier > (device-id), as > > none of the obvious candidates (IMSI, MAC address, etc) > currently have > > a URN definition. In order to speed deployment, one quick-and-easy > > suggestion is to use the tel URL. While this does not > always identify > > a single device, in many practical cases of interest, it does. > > Examples where this is likely to work reasonably well > include mobile > > phones and residential analog phones (i.e., without ENUM). > > > > Comments? > > > > Henning > > > > _______________________________________________ > > 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 > > ------_=_NextPart_001_01C5781D.F3D4413B Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Simple] tel as device identifier

Yeah, I agree with Cullen.

Tel is definitively not a device identifier. Even in = most old traditional PBXs, you
have a device identifier that is used internally for = that purpose.

There are hunt group numbers, 800 numbers, portable = numbers, and with SIP now, my telephone
numbers rings a whole bunch of different devices. =

It is anything but a device identifier, and the trend = is intensifying.



> -----Original Message-----
> From: simple-bounces@ietf.org
> [mailto:simple-bounces@ietf.org] On Behalf Of Cullen Jennings
> Sent: Tuesday, June 21, 2005 11:31
> To: Henning Schulzrinne; simple@ietf.org
> Subject: Re: [Simple] tel as device = identifier
>
>
>
> tel is definitely not a unique device = identifier - i have
> many devices with the same tel. Why not just = use an UUID  URN
> as a device id.
>
>
>
>
> On 6/18/05 9:42 AM, "Henning = Schulzrinne" <hgs@cs.columbia.edu> wrote:
>
> > Currently, there is no really good device = identifier
> (device-id), as
> > none of the obvious candidates (IMSI, MAC = address, etc)
> currently have
> > a URN definition. In order to speed = deployment, one quick-and-easy
> > suggestion is to use the tel URL. While = this does not
> always identify
> > a single device, in many practical cases = of interest, it does.
> > Examples where this is likely to work = reasonably well
> include mobile
> > phones and residential analog phones = (i.e., without ENUM).
> >
> > Comments?
> >
> > Henning
> >
> > = _______________________________________________
> > 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
>
>

------_=_NextPart_001_01C5781D.F3D4413B-- --===============1986422681== 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 --===============1986422681==-- From simple-bounces@ietf.org Fri Jun 24 00:03:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlfPa-0001uY-IZ; Fri, 24 Jun 2005 00:03:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkzPS-0006ci-8u for simple@megatron.ietf.org; Wed, 22 Jun 2005 03:12:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06476 for ; Wed, 22 Jun 2005 03:12:28 -0400 (EDT) Received: from mail1.followap.com ([194.90.96.46] helo=mail.followap.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkznW-0005Zn-6P for simple@ietf.org; Wed, 22 Jun 2005 03:37:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Jun 2005 10:04:16 +0300 Message-ID: <8E5AB0A04458904BB9B079055261033CA8E8D5@mail.followap.com> Thread-Topic: draft-ietf-simple-partial-publish-02 - MIME Error Thread-Index: AcV2+Jpj/4TQ+/OMRq63hOQy2nvPsQ== From: "Fridy Sharon-Fridman" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 X-Mailman-Approved-At: Fri, 24 Jun 2005 00:03:24 -0400 Cc: eva-maria.leppanen@nokia.com, simple@ietf.org Subject: [Simple] draft-ietf-simple-partial-publish-02 - MIME Error 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="===============2146065910==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============2146065910== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C576F9.461D1936" This is a multi-part message in MIME format. ------_=_NextPart_001_01C576F9.461D1936 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Aki, =20 'application/pidf-partial+xml' has been changed to 'application/pidf-diff+xml' throughout the document, but not in 3.2 (p .4). =20 Cheers, --Fridy / Followap ------_=_NextPart_001_01C576F9.461D1936 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Aki,

 

'application/pidf-partial+xml' has been changed to = 'application/pidf-diff+xml' throughout the document, but not in 3.2 (p = .4).

 

Cheers,

--Fridy / Followap

------_=_NextPart_001_01C576F9.461D1936-- --===============2146065910== 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 --===============2146065910==-- From simple-bounces@ietf.org Fri Jun 24 11:57:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlqYd-0003s8-LE; Fri, 24 Jun 2005 11:57:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlqYb-0003rs-3c for simple@megatron.ietf.org; Fri, 24 Jun 2005 11:57:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19645 for ; Fri, 24 Jun 2005 11:57:26 -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 1Dlqx8-0007Ar-5H for simple@ietf.org; Fri, 24 Jun 2005 12:22:51 -0400 Received: from [192.168.1.118] (dsl001-129-066.dfw1.dsl.speakeasy.net [72.1.129.66]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j5OFvD37028438 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 24 Jun 2005 10:57:18 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <770e9959d3c738d838e8e7dee219ad3d@ekabal.com> References: <770e9959d3c738d838e8e7dee219ad3d@ekabal.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <59441C0C-B511-478A-89D6-35CC3006C9F8@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension Date: Fri, 24 Jun 2005 10:57:06 -0500 To: Rohan Mahy X-Mailer: Apple Mail (2.730) Received-SPF: pass (nostrum.com: 72.1.129.66 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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 I am sensitive to the fact basic is easier to implement, simpler to specify, etc. However, "accurate concern number" 1 feels like a show stopper. The particular use case I imagine is that I am roaming onto someone else's network (a Hotel, for example) that forces all MSRP traffic through its relay. I might have a high-security job where my credentials must not be revealed to _anyone_ outside of my organization. What do I do? If we go with basic for now, does that in any way preclude doing a followup effort on how to use digest? On Jun 20, 2005, at 8:44 PM, Rohan Mahy wrote: > Hi Everyone, > > Despite the thread on the list from late March and early April > about Basic vs Digest authentication, I don't feel like we came to > consensus on this issue. First I would like to apologize for my > lack of attention on this particular issue, and that it has > remained open for so long. > > The arguments in favor of Digest authentication included a number > of incorrect assumptions (marked "I") which need to be clarified in > the draft. Among them: > > I: Relays for user B get to see the username and password for user A. > A: This never happens. user A only sends AUTH requests to *its* > relays, never to the relays used to forward requests on to another > user. > > I: User B sends its password in the clear over the network. > A: Use of TLS is mandatory, user B only sends its password inside a > TLS-protected channel. > > I: The Security Area Directors will never allow this. > A: Based on preliminary discussions, I believe this will be > acceptable to the Security ADs. Again, use of TLS is mandatory. > This is exactly like the common usage of SMTP using PLAIN user > authentication over a TLS-protected channel, which is a very widely > deployed model. > > I: If I use RADIUS I have to send the username and password in the > clear > A: The MSRP relay can hash the password before sending to the > RADIUS server, or send all RADIUS traffic over a protected channel. > > There are two other concerns with Basic which are accurate: > > 1. If example.com has an inner relay and an outer relay, > credentials for outer.example.com are revealed to inner.example.com > as AUTH requests are forwarded to outer.example.com. This > limitation is clearly explained in the Security Considerations > section. > > 2. The other issue that Avshalom brought up is that the relay > administrator has access to the password, or an attacker who can > gain access to the relay machine. While the administrator could > mount a dictionary attack on a Digest protected password, its > obviously easier to get access to the password when it isn't hashed > at all. > > When I originally tried to map the draft onto Digest, I was > planning to do something like this: > > - realm is a string provided by the server. it SHOULD be the host > name of the relay. > - the domains parameter is ignored > - note that the nonce algorithm based on ETags doesn't work > - do not support auth-int, but always include the qop parameter > with auth > - the digest-uri parameter is the right-most URI in the To-Path header > - the alg parameter is ??? > - the cnonce and the nonce-count MUST be sent > - the Method from A2 is always AUTH > - there is never a body for AUTH so A2 is just AUTH: plus the > Request-URI > - I have no idea what to do about MD5 vs. MD5-sess. > - I have no idea whether the nextnonce parameter is useful here. > - I don't think the response authentication parameter is useful at > all. However, the security considerations needs to describe what > would or would not be protected here. Remember that we have no > integrity over the Use-Path header from client to outermost relay > even if we use this, unless we redefine the A2 to include the value > of the Use-Path header instead of the entity-body. > > The arguments in favor of Basic authentication are: > > 1. Basic authentication is much simpler to implement than Digest, > and the authors feel that with TLS protection of the channel that > its security is good enough. We expect MSRP AUTH to be used within > a single administrative domain, and the limitation of the server > seeing the plain text password is similar to the way that many > email services are deployed with TLS. > > 2. Digest authentication is not a great fit to MSRP and as a result > its not obvious what to specify for all the parameters. > > > What do we do? My proposal is to go with Basic. I have updated > the draft leaving Basic in place. I feel this is appropriate given > the relative security of the base draft, and given what would be > needed to do Digest properly. If the consensus of the group is > that we should do Digest instead, then I urge someone to propose > specific text answering the questions I discuss above, that would > go into the draft. > > thanks, > -rohan > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 24 14:52:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DltHf-0002WG-OA; Fri, 24 Jun 2005 14:52:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DltHe-0002W4-ET for simple@megatron.ietf.org; Fri, 24 Jun 2005 14:52:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02437 for ; Fri, 24 Jun 2005 14:52:08 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DltgE-0005jT-8B for simple@ietf.org; Fri, 24 Jun 2005 15:17:34 -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 j5OImlcQ023342; Fri, 24 Jun 2005 11:48:48 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5OImiHV010231; Fri, 24 Jun 2005 11:48:45 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 24 Jun 2005 11:48:41 -0700 To: Markus.Isomaki@nokia.com, From: Ted Hardie Subject: RE: [Simple] element issue for common policy Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: pkyzivat@cisco.com, aki.niemi@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Howdy, Sorry for the long delay in replying, and thanks to Robert for the reminder. At 5:33 PM +0300 6/16/05, Markus.Isomaki@nokia.com wrote: >Hi Ted, > >I don't still get your point why this type of exceptions within a particular rule/directive would be against the additive model of permissions. I think you would still get the same results whichever way you evaluate the permissions, and you would never reveal more if a permission is lost - which seem to be the two main points of additive permissions. I agree that having the clause for applicability within the rule is better than the cases GeoPriv was most concerned with (it's always processed at the same time, so the evaluation order problem isn't salient). It is, though, a negative permission--it's a grant to all followed by a revoke to a limited set. One of the issues I expressed is that the limited set isn't useful, because of identity minting. The other is that the except clause here forces a change to the processing model. I'm concerned that changing the processing model to (Grant, followed by revoke) will open us to things that will have the problems GeoPriv wanted to avoid. >In fact, the separate post-processing after the authorization decision has been already done, is much more contradictory to the model, since then you may be enforcing exceptions that are "global", and if that part of the process fails, you may end up revealing more information. As Jonathan was asking, I see little difference in having a rule in common policy saying "deny this guy" (which is clealy wrong in terms of the additiveness principle) and having a separate facility saying "if this guy gets through the auth policy, deny him". I was arguing that the auth policy does not say "grant", but says "mark for further processing"; from my perspective, that means that you have *not* granted any permissions and that any later processing does not have the same effect as revocation of a previous grant. It also means that there is no chance that the failure of that process to run will reveal more information; if the post-processing is faulty, obviously, you can end up with it doing wild and crazy things. Since I don't think the post-processing is a subject for standardization, I agree that this is a risk. I think, though, that we're going to see post-processing in any case (as I don't see the standards mechanisms meeting all the needs). >The point about identity/domain minting is valid, however. It is clear that you will not get perfect protection with identity or domain exceptions, because of the reasons you explain. My view of the situation is still a bit different than yours for the following reasons: >1. If someone is concerned about identity minting, they can decide NOT to use the exceptions. > This decision can be done at many levels: service provider can ban them, client vendor can band them, UI designer can ban them, the user can decide not to use them. The main point: I do *NOT* think that in this case it is the IETF's business to do this decision! In fact, I'm afraind that it IETF does this, other organizations and vendors are forced to hack around this with the loss of interoperability, since as far as I know, some sort of black-listing capability is a clear must from user expectation point of view. Do you believe that this except-based processing is enough to meet the market needs here, or will we see post-processing in any case? I can't, personally, imagine someone selling a black-listing capability that worked at the granularity of a domain, and that was one of the reasons I asked for use cases. To put this another way, if we keep fairly strictly to additive permissions in rules, it is clear to an implementor how to manage those rules; if we have some Grant/Revoke logic at the rule level and a different set of Revocation logic that is only available through post-processing, I think we are putting things at risk for less predictable results. >2. There are many many cases where users would not need to care about identity minting. For instance, if I want to block my mother for a while, I can be pretty sure she won't go about minting another identity to get the access. Again, though, is this the right granularity for the use case at hand? And again, my apologies for the delay in replying. regards, Ted Hardie >Regards, > Markus > >> -----Original Message----- >> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org]On Behalf >> Of ext Ted Hardie >> Sent: 07 June, 2005 20:21 >> To: Jonathan Rosenberg >> Cc: Paul Kyzivat; Niemi Aki (Nokia-NRC/Helsinki); simple@ietf.org >> Subject: Re: [Simple] element issue for common policy >> >> >> Hi Jonathan, >> >> For some bizarre reason, both copies of this just now turned >> up in my mail box; >> I apologize for the long delay in replying. If there are >> other messages you >> have out to me for which you're expecting a reply, please re-send. >> >> At 12:13 PM -0400 5/25/05, Jonathan Rosenberg wrote: >> >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. >> >> There are a couple of things that I was trying to get at here. One >> of the issues >> that drove geopriv to the additive permissions only point of >> view was that >> you didn't necessarily know what order permissions would be granted in >> (especially where some are incorporated from external >> sources). That means >> the processing model for an additive/subtractive model requires all of >> the rules to be present and somehow sorted correctly to get >> to the intended >> state. If you can't resolve an external reference in that >> case you either >> get nothing (because you're very conservative) or you reveal >> to much (because >> you're insufficiently paranoid). In going to an additive >> permissions model, >> you know that whatever permissions have been granted up to a specific >> point are intended and that you are being at least as conservative as >> was intended. You also are free to process the directives in >> any order. >> >> Except clauses that are clearly tied to specific directives are better >> than all-out negative permissions, but they can remain problematic >> in their interaction with user expectations. If I say "Grant anyone >> access to my timezone, except Hisham" and also say "Grant any >> wg chair in APPs access to my full location", Hisham will get my >> time zone--but this may not be what a user expects, especially >> if the user expectation is driven by a sense of "override" and >> wrote the "except Hisham" after the first rule was in place. >> >> For a process model, all of the additive rules are done first >> before a process kicks in--this means that you can guarantee >> an evaluation >> order-- all the rules and then later the processes (which I >> should probably >> call something other than "process"). Personally, I think that helps, >> especially if the rules are constructed so as to put those which >> require post-rule evaluation into what are essentially pending >> states (as this leaves the "you are being at least as conservative >> as intended" in place). A human can do the post-rule evaluation, >> or it can be done by a process/agent/heuristic engine of whatever >> complexity is appropriate. >> >> That's the other main point--I believe that the "grant any, except > > domain" is so close to useless that it is not worth it; it is >> trivially >> easy to mint identities that escape this clause. To get to something >> that actually successfully excluded someone here, I think you'd >> eventually need something of close to arbitrary complexity, and >> that this does not belong in the rules language "Anyone may >> know my timezone >> except those whose identities are associated with domains >> that have been >> recently minted, are in this list, or were paid for by credit cards >> traceable to "Hisham Khartabil" or were paid for in ways that are >> not traceable." *might* succeed in keeping Hisham from knowing >> what timezone I'm in. But even then, he has only to get a friend >> to loan him a cc to get past it. >> >> regards, >> Ted >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 24 17:36:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlvqH-0004Nm-Ld; Fri, 24 Jun 2005 17:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlvqF-0004Nf-JB for simple@megatron.ietf.org; Fri, 24 Jun 2005 17:36:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27269 for ; Fri, 24 Jun 2005 17:36:01 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlwEp-0006FF-Eh for simple@ietf.org; Fri, 24 Jun 2005 18:01:29 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j5OLZumD001973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Jun 2005 17:35:57 -0400 (EDT) Message-ID: <42BC7CB6.7070503@cs.columbia.edu> Date: Fri, 24 Jun 2005 17:35:50 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: 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-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 Ted Hardie wrote: > I agree that having the clause for applicability within the > rule is better than the cases GeoPriv was most concerned with (it's > always processed at the same time, so the evaluation order problem > isn't salient). It is, though, a negative permission--it's a grant > to all followed by a revoke to a limited set. One of the issues I > expressed is that the limited set isn't useful, because of identity > minting. The other is that the except clause here forces a change to > the processing model. I'm concerned that changing the processing > model to (Grant, followed by revoke) will open us to things that will > have the problems GeoPriv wanted to avoid. I don't quite agree with the statement of the model made above. This is not "grant, then revoke". Rather, the exception condition restricts the matching of the rule. Logically speaking, rule processing proceeds in two phases: (1) Determine if the rule matches a request (subscription, location request, etc.) (2) Execute the actions and grant the permissions (it's a bit more complicated, but irrelevant for this discussion). The "all except" part only affects the matching (step 1), not the action (step 2). This is an important difference, as it avoids the privacy unsafety issues that grant-then-revoke would have. Rules are binary in matching, i.e., they either match or don't, and thus the consequences you seem to fear cannot occur, inside or outside of the geopriv context. I want to make the difference clear since I was also confused on this point when this whole discussion started a year or so ago. Thus, to make up another example that avoids the identity-minting issue, "Apply this rule at any location except New York" would be perfectly fine. The distinction becomes clearer if you consider hypothetically that we might allow regular expressions in the matching part. We could have something like [^0-9] which can be phrases as "any character except 0-9". Or, if we had a numeric matching condition, something like "x > 9 || x < 0" could just as easily be phrased as "any x except between 0 and 9". Clearly, neither of these examples are "grant/revoke" conditions. > Do you believe that this except-based processing is enough to meet > the market needs here, or will we see post-processing in any case? I > can't, personally, imagine someone selling a black-listing capability > that worked at the granularity of a domain, and that was one of the > reasons I asked for use cases. This is apparently common for email. For example, there are folks who blacklist aol.com, yahoo.com and hotmail.com as they perceive them to be favorite sources of fake email addresses and/or individuals whose communication they can do without. I've put email domains on my blacklist when somebody didn't pay attention to my unsubscribe request. > > To put this another way, if we keep fairly strictly to additive > permissions in rules, it is clear to an implementor how to manage > those rules; if we have some Grant/Revoke logic at the rule level and > a different set of Revocation logic that is only available through > post-processing, I think we are putting things at risk for less > predictable results. Please see above. I don't think it is helpful to phrase this as grant/revoke, as it does not fit that model. There is never anything granted that could be revoked - the rule just isn't invoked. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jun 25 11:45:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmCqY-0008Ni-DK; Sat, 25 Jun 2005 11:45:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmCqU-0008NU-2X for simple@megatron.ietf.org; Sat, 25 Jun 2005 11:45:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12262 for ; Sat, 25 Jun 2005 11:45:23 -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 1DmDFF-00011h-8H for simple@ietf.org; Sat, 25 Jun 2005 12:11:01 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 25 Jun 2005 08:45:16 -0700 X-IronPort-AV: i="3.93,229,1115017200"; d="scan'208"; a="645777931:sNHT32865330" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5PFj6vM010988; Sat, 25 Jun 2005 08:45:11 -0700 (PDT) Received: from [10.255.254.200] ([10.21.146.13]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 25 Jun 2005 08:49:19 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 25 Jun 2005 08:45:04 -0700 Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension From: Cullen Jennings To: Avshalom Houri Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Jun 2005 15:49:19.0313 (UTC) FILETIME=[72D22C10:01C5799D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 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 Consider how a password works on a UNIX system, if you get access to the /etc/passwd file, you don't find out what my password is because the password is not stored but instead a hashed+salt version of it is. This is how people that implemented the Basic+TLS scheme would do it. Now consider how Apache stores the the HTTP digest credentials. It stores the H(A1) value which does not include the nonce. I might be wrong on this but I think that if the attacker new the H(A1), they could compute the response to logon to this particular realm even when a new nonce was presented. Cullen On 6/22/05 10:14 AM, "Avshalom Houri" wrote: > > Cullen, > > Not sure I understand. > > In digest, the server will send a nonce to the user thus preventing replay > attacks by replacing the nonce every time. > The hashed value stored in the server can not be used for logging again to the > server since the server will accept only nonced passwords. > > In basic authentication anyone that has an access to the server code may get > the cleartext password and do with it whatever they want. > > Avshalom > > > > Cullen Jennings > Sent by: simple-bounces@ietf.org 22/06/2005 06:58 PM > To > Rohan Mahy , "simple@ietf.org" > cc > Subject > Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays > extension > > > > > > I have not really provided much input on this issues - that is partially > because I could go either way if we could just finish this. That said, let > me outline a few points that I see as relevant to the decision.... > > The significant argument I have seen made an attack where someone broke > into the relay server (or had access to it because they were the > administrator) of it and thus gained access to all the stored passwords. We > are worried about people using the information to log in as the a given user > to this relay and also, assuming the users use the same password other > places, to long on to other boxes. This is definitely an important attack to > consider. > > If we go with the Digest route, any reasonable server will end up storing > H(A1). It may do this directly or via a radius server. Now if someone gets > H(A1), the can not discover my password and long on to some other server > where I may have used the same password. However, they can use that to log > on to this same relay server as me. The last sentence is important, using > Digest, if the attacker gets my stored H(A1) then can log on as me to this > box (but not others). > > Now consider the Basic+TLS approach, any reasonable implementation will > store the usual hash of password plus salt solution. If an attacker gets > this stored information, they can log on other boxes, but even more than > this, they can not log onto this box using what they learned. > > Both solutions protect against the stored information being used to log on > another box and the Digest+TLS also protects against it being used to log on > the same relay. > > I'm not sure I view this as an amazing advantage for Basic+TLS - I view the > real advantage of Basic+TLS be the simplicity it brings and that much of > what Digest is designed to provide, MSRP has no use for. > > Next point has to do with this being a password at all - if we think this is > something a human generates, remembers, and types in, well then it is a > password and the above attacks are worth considering. Personally, I think it > is going to be come configuration information generated by the system and > downloaded to the client then used to connect to the relay. In this form it > is far more of a cookie than a password and the above attacks are far less > interesting because there will not be other systems that use the same > password. > > Cullen > > > > On 6/20/05 6:44 PM, "Rohan Mahy" wrote: > >> Hi Everyone, >> >> Despite the thread on the list from late March and early April about >> Basic vs Digest authentication, I don't feel like we came to consensus >> on this issue. First I would like to apologize for my lack of attention >> on this particular issue, and that it has remained open for so long. >> >> The arguments in favor of Digest authentication included a number of >> incorrect assumptions (marked "I") which need to be clarified in the >> draft. Among them: >> >> I: Relays for user B get to see the username and password for user A. >> A: This never happens. user A only sends AUTH requests to *its* >> relays, never to the relays used to forward requests on to another >> user. >> >> I: User B sends its password in the clear over the network. >> A: Use of TLS is mandatory, user B only sends its password inside a >> TLS-protected channel. >> >> I: The Security Area Directors will never allow this. >> A: Based on preliminary discussions, I believe this will be acceptable >> to the Security ADs. Again, use of TLS is mandatory. This is exactly >> like the common usage of SMTP using PLAIN user authentication over a >> TLS-protected channel, which is a very widely deployed model. >> >> I: If I use RADIUS I have to send the username and password in the clear >> A: The MSRP relay can hash the password before sending to the RADIUS >> server, or send all RADIUS traffic over a protected channel. >> >> There are two other concerns with Basic which are accurate: >> >> 1. If example.com has an inner relay and an outer relay, credentials >> for outer.example.com are revealed to inner.example.com as AUTH >> requests are forwarded to outer.example.com. This limitation is >> clearly explained in the Security Considerations section. >> >> 2. The other issue that Avshalom brought up is that the relay >> administrator has access to the password, or an attacker who can gain >> access to the relay machine. While the administrator could mount a >> dictionary attack on a Digest protected password, its obviously easier >> to get access to the password when it isn't hashed at all. >> >> When I originally tried to map the draft onto Digest, I was planning to >> do something like this: >> >> - realm is a string provided by the server. it SHOULD be the host name >> of the relay. >> - the domains parameter is ignored >> - note that the nonce algorithm based on ETags doesn't work >> - do not support auth-int, but always include the qop parameter with >> auth >> - the digest-uri parameter is the right-most URI in the To-Path header >> - the alg parameter is ??? >> - the cnonce and the nonce-count MUST be sent >> - the Method from A2 is always AUTH >> - there is never a body for AUTH so A2 is just AUTH: plus the >> Request-URI >> - I have no idea what to do about MD5 vs. MD5-sess. >> - I have no idea whether the nextnonce parameter is useful here. >> - I don't think the response authentication parameter is useful at all. >> However, the security considerations needs to describe what would or >> would not be protected here. Remember that we have no integrity over >> the Use-Path header from client to outermost relay even if we use this, >> unless we redefine the A2 to include the value of the Use-Path header >> instead of the entity-body. >> >> The arguments in favor of Basic authentication are: >> >> 1. Basic authentication is much simpler to implement than Digest, and >> the authors feel that with TLS protection of the channel that its >> security is good enough. We expect MSRP AUTH to be used within a single >> administrative domain, and the limitation of the server seeing the >> plain text password is similar to the way that many email services are >> deployed with TLS. >> >> 2. Digest authentication is not a great fit to MSRP and as a result its >> not obvious what to specify for all the parameters. >> >> >> What do we do? My proposal is to go with Basic. I have updated the >> draft leaving Basic in place. I feel this is appropriate given the >> relative security of the base draft, and given what would be needed to >> do Digest properly. If the consensus of the group is that we should do >> Digest instead, then I urge someone to propose specific text answering >> the questions I discuss above, that would go into the draft. >> >> thanks, >> -rohan >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jun 25 23:03:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmNR2-0002ll-HZ; Sat, 25 Jun 2005 23:03:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmNR0-0002lg-Uv for simple@megatron.ietf.org; Sat, 25 Jun 2005 23:03:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00082 for ; Sat, 25 Jun 2005 23:03:48 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmNpr-00081i-Jv for simple@ietf.org; Sat, 25 Jun 2005 23:29:32 -0400 Received: from [192.168.0.31] (pool-141-153-173-119.mad.east.verizon.net [141.153.173.119]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5Q33lcO014301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 25 Jun 2005 23:03:48 -0400 (EDT) Message-ID: <42BE1B08.3090006@cs.columbia.edu> Date: Sat, 25 Jun 2005 23:03:36 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [Simple] RPID IANA 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'm cleaning up the RPID document to get it ready for WGLC. For historical reasons, the document calls for IANA registries of various items, such as activities. However, since extensions are now done via namespaces it seems less clear that this is needed. Any opinions? Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jun 26 11:58:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmZWJ-0001AV-2e; Sun, 26 Jun 2005 11:58:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmZW5-00017A-Nk for simple@megatron.ietf.org; Sun, 26 Jun 2005 11:57:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04594 for ; Sun, 26 Jun 2005 11:57:50 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmZfP-0005hN-Sb for simple@ietf.org; Sun, 26 Jun 2005 12:07:34 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id DCB1D6C021; Sun, 26 Jun 2005 11:41:39 -0400 (EDT) Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension From: Scott Lawrence To: Cullen Jennings In-Reply-To: References: Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Sun, 26 Jun 2005 11:41:37 -0400 Message-Id: <1119800497.4884.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Avshalom Houri , "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 On Sat, 2005-06-25 at 08:45 -0700, Cullen Jennings wrote: > Consider how a password works on a UNIX system, if you get access to the > /etc/passwd file, you don't find out what my password is because the > password is not stored but instead a hashed+salt version of it is. This is > how people that implemented the Basic+TLS scheme would do it. > > Now consider how Apache stores the the HTTP digest credentials. It stores > the H(A1) value which does not include the nonce. I might be wrong on this > but I think that if the attacker new the H(A1), they could compute the > response to logon to this particular realm even when a new nonce was > presented. You are correct - anyone who knows H(A1) can authenticate themselves on the server. The reason that servers typically store the H(A1) rather than the plaintext password is that users often use the same passwords on multiple systems - recovering the plaintext from the H(A1) is 'computationally infeasible', so the plaintext, and thus any other systems where the same password was used, is safe. Since the 'realm' component on other systems will be different, that H(A1) is not useful to an attacker there. -- Scott Lawrence, Consulting Engineer Pingtel Corp. http://www.pingtel.com/ +1.781.938.5306 x162 or sip:slawrence@pingtel.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jun 26 12:05:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmZdB-0003mq-Vx; Sun, 26 Jun 2005 12:05:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmZdA-0003la-JQ for simple@megatron.ietf.org; Sun, 26 Jun 2005 12:05:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10148 for ; Sun, 26 Jun 2005 12:05:06 -0400 (EDT) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmTsM-0002hJ-NP for simple@ietf.org; Sun, 26 Jun 2005 05:56:31 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 8306C194467 for ; Sun, 26 Jun 2005 11:30:12 +0200 (CEST) Received: from [10.0.0.1] ([82.194.52.5]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Jun 2005 11:33:56 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0cccd4bbc210cb4dcfea49ed0234c0dc@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension Date: Sun, 26 Jun 2005 11:30:05 +0200 To: Cullen Jennings X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 26 Jun 2005 09:33:56.0926 (UTC) FILETIME=[2CD865E0:01C57A32] X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Content-Transfer-Encoding: 7bit Cc: Avshalom Houri , "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 Cullen, Rohan, You're not selling the Basic Authentication solution very well. Simplicity is not a good reason as far as I'm concerned. You could argue your same arguments for SIP Basic authentication (that Basic+TLS and hash+salt is enough), but we deprecated Basic still, for a reason. Why doesnt that reason also apply to MRSP relays? People have concerns with Basic. Using Digest well not compromise the security of the system, and will make everybody happy. Unless you have real technical issues and concerns with using Digest, I believe we need to go with it. Regards, Hisham On Jun 25, 2005, at 5:45 PM, Cullen Jennings wrote: > > Consider how a password works on a UNIX system, if you get access to > the > /etc/passwd file, you don't find out what my password is because the > password is not stored but instead a hashed+salt version of it is. > This is > how people that implemented the Basic+TLS scheme would do it. > > Now consider how Apache stores the the HTTP digest credentials. It > stores > the H(A1) value which does not include the nonce. I might be wrong on > this > but I think that if the attacker new the H(A1), they could compute the > response to logon to this particular realm even when a new nonce was > presented. > > Cullen > > On 6/22/05 10:14 AM, "Avshalom Houri" wrote: > >> >> Cullen, >> >> Not sure I understand. >> >> In digest, the server will send a nonce to the user thus preventing >> replay >> attacks by replacing the nonce every time. >> The hashed value stored in the server can not be used for logging >> again to the >> server since the server will accept only nonced passwords. >> >> In basic authentication anyone that has an access to the server code >> may get >> the cleartext password and do with it whatever they want. >> >> Avshalom >> >> >> >> Cullen Jennings >> Sent by: simple-bounces@ietf.org 22/06/2005 06:58 PM >> To >> Rohan Mahy , "simple@ietf.org" >> cc >> Subject >> Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP >> relays >> extension >> >> >> >> >> >> I have not really provided much input on this issues - that is >> partially >> because I could go either way if we could just finish this. That >> said, let >> me outline a few points that I see as relevant to the decision.... >> >> The significant argument I have seen made an attack where someone >> broke >> into the relay server (or had access to it because they were the >> administrator) of it and thus gained access to all the stored >> passwords. We >> are worried about people using the information to log in as the a >> given user >> to this relay and also, assuming the users use the same password other >> places, to long on to other boxes. This is definitely an important >> attack to >> consider. >> >> If we go with the Digest route, any reasonable server will end up >> storing >> H(A1). It may do this directly or via a radius server. Now if someone >> gets >> H(A1), the can not discover my password and long on to some other >> server >> where I may have used the same password. However, they can use that >> to log >> on to this same relay server as me. The last sentence is important, >> using >> Digest, if the attacker gets my stored H(A1) then can log on as me to >> this >> box (but not others). >> >> Now consider the Basic+TLS approach, any reasonable implementation >> will >> store the usual hash of password plus salt solution. If an attacker >> gets >> this stored information, they can log on other boxes, but even more >> than >> this, they can not log onto this box using what they learned. >> >> Both solutions protect against the stored information being used to >> log on >> another box and the Digest+TLS also protects against it being used to >> log on >> the same relay. >> >> I'm not sure I view this as an amazing advantage for Basic+TLS - I >> view the >> real advantage of Basic+TLS be the simplicity it brings and that much >> of >> what Digest is designed to provide, MSRP has no use for. >> >> Next point has to do with this being a password at all - if we think >> this is >> something a human generates, remembers, and types in, well then it is >> a >> password and the above attacks are worth considering. Personally, I >> think it >> is going to be come configuration information generated by the system >> and >> downloaded to the client then used to connect to the relay. In this >> form it >> is far more of a cookie than a password and the above attacks are far >> less >> interesting because there will not be other systems that use the same >> password. >> >> Cullen >> >> >> >> On 6/20/05 6:44 PM, "Rohan Mahy" wrote: >> >>> Hi Everyone, >>> >>> Despite the thread on the list from late March and early April about >>> Basic vs Digest authentication, I don't feel like we came to >>> consensus >>> on this issue. First I would like to apologize for my lack of >>> attention >>> on this particular issue, and that it has remained open for so long. >>> >>> The arguments in favor of Digest authentication included a number of >>> incorrect assumptions (marked "I") which need to be clarified in the >>> draft. Among them: >>> >>> I: Relays for user B get to see the username and password for user A. >>> A: This never happens. user A only sends AUTH requests to *its* >>> relays, never to the relays used to forward requests on to another >>> user. >>> >>> I: User B sends its password in the clear over the network. >>> A: Use of TLS is mandatory, user B only sends its password inside a >>> TLS-protected channel. >>> >>> I: The Security Area Directors will never allow this. >>> A: Based on preliminary discussions, I believe this will be >>> acceptable >>> to the Security ADs. Again, use of TLS is mandatory. This is >>> exactly >>> like the common usage of SMTP using PLAIN user authentication over a >>> TLS-protected channel, which is a very widely deployed model. >>> >>> I: If I use RADIUS I have to send the username and password in the >>> clear >>> A: The MSRP relay can hash the password before sending to the RADIUS >>> server, or send all RADIUS traffic over a protected channel. >>> >>> There are two other concerns with Basic which are accurate: >>> >>> 1. If example.com has an inner relay and an outer relay, credentials >>> for outer.example.com are revealed to inner.example.com as AUTH >>> requests are forwarded to outer.example.com. This limitation is >>> clearly explained in the Security Considerations section. >>> >>> 2. The other issue that Avshalom brought up is that the relay >>> administrator has access to the password, or an attacker who can gain >>> access to the relay machine. While the administrator could mount a >>> dictionary attack on a Digest protected password, its obviously >>> easier >>> to get access to the password when it isn't hashed at all. >>> >>> When I originally tried to map the draft onto Digest, I was planning >>> to >>> do something like this: >>> >>> - realm is a string provided by the server. it SHOULD be the host >>> name >>> of the relay. >>> - the domains parameter is ignored >>> - note that the nonce algorithm based on ETags doesn't work >>> - do not support auth-int, but always include the qop parameter with >>> auth >>> - the digest-uri parameter is the right-most URI in the To-Path >>> header >>> - the alg parameter is ??? >>> - the cnonce and the nonce-count MUST be sent >>> - the Method from A2 is always AUTH >>> - there is never a body for AUTH so A2 is just AUTH: plus the >>> Request-URI >>> - I have no idea what to do about MD5 vs. MD5-sess. >>> - I have no idea whether the nextnonce parameter is useful here. >>> - I don't think the response authentication parameter is useful at >>> all. >>> However, the security considerations needs to describe what would >>> or >>> would not be protected here. Remember that we have no integrity over >>> the Use-Path header from client to outermost relay even if we use >>> this, >>> unless we redefine the A2 to include the value of the Use-Path header >>> instead of the entity-body. >>> >>> The arguments in favor of Basic authentication are: >>> >>> 1. Basic authentication is much simpler to implement than Digest, and >>> the authors feel that with TLS protection of the channel that its >>> security is good enough. We expect MSRP AUTH to be used within a >>> single >>> administrative domain, and the limitation of the server seeing the >>> plain text password is similar to the way that many email services >>> are >>> deployed with TLS. >>> >>> 2. Digest authentication is not a great fit to MSRP and as a result >>> its >>> not obvious what to specify for all the parameters. >>> >>> >>> What do we do? My proposal is to go with Basic. I have updated the >>> draft leaving Basic in place. I feel this is appropriate given the >>> relative security of the base draft, and given what would be needed >>> to >>> do Digest properly. If the consensus of the group is that we should >>> do >>> Digest instead, then I urge someone to propose specific text >>> answering >>> the questions I discuss above, that would go into the draft. >>> >>> thanks, >>> -rohan >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jun 26 14: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 1DmbgY-0002vE-1p; Sun, 26 Jun 2005 14: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 1DmbgW-0002v5-NW for simple@megatron.ietf.org; Sun, 26 Jun 2005 14:16:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29366 for ; Sun, 26 Jun 2005 14:16:47 -0400 (EDT) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmc5U-0007X4-FW for simple@ietf.org; Sun, 26 Jun 2005 14:42:38 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5QIFUC2010245; Sun, 26 Jun 2005 21:15:31 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Jun 2005 21:15:24 +0300 Received: from [192.168.1.175] ([10.162.252.109]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 26 Jun 2005 21:15:23 +0300 Message-ID: <42BEF0BB.6080405@nokia.com> Date: Sun, 26 Jun 2005 21:15:23 +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 Hisham Khartabil Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension References: <0cccd4bbc210cb4dcfea49ed0234c0dc@telio.no> In-Reply-To: <0cccd4bbc210cb4dcfea49ed0234c0dc@telio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2005 18:15:23.0898 (UTC) FILETIME=[055575A0:01C57A7B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Avshalom Houri , "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 Inline. ext Hisham Khartabil wrote: > You're not selling the Basic Authentication solution very well. > Simplicity is not a good reason as far as I'm concerned. You could argue > your same arguments for SIP Basic authentication (that Basic+TLS and > hash+salt is enough), but we deprecated Basic still, for a reason. Why > doesnt that reason also apply to MRSP relays? Comparing SIP and MSRP may not be that wise here. The SIP model differs from the MSRP relay model significantly, since in SIP TLS is only hop-by-hop, and so even with transport security, an outbound proxy would have full access to the Basic password. Since in MSRP the client is supposed to have a TLS session up with the relay before any authentication is done, I don't see the problem. I would also like to separate protocol security from the discussion of how credentials are stored in the relay. IMHO, the latter can be screwed up in so many ways [1] we may just as well simply concentrate on the former. The latter is also an implementation issue. > People have concerns with Basic. Using Digest well not compromise the > security of the system, and will make everybody happy. Unless you have > real technical issues and concerns with using Digest, I believe we need > to go with it. I'm fine with Basic. I agree it's easier to implement, interoperates better and works fine when used in a TLS session authenticated with a server certificate. Digest would be an option if TLS was somehow deemed insufficient, or too much of a burden. It is neither, since TLS+basic (or username/password in an HTML form) has been proven to work in the web, and as has been pointed out by various people in other threads, server certificates are nowadays really dirt cheap. Cheers, Aki [1] Referring to the recent credit card number theft, where I'm sure most if not all numbers were sent via an SSL protected site. > Regards, > Hisham > > On Jun 25, 2005, at 5:45 PM, Cullen Jennings wrote: > >> >> Consider how a password works on a UNIX system, if you get access to the >> /etc/passwd file, you don't find out what my password is because the >> password is not stored but instead a hashed+salt version of it is. >> This is >> how people that implemented the Basic+TLS scheme would do it. >> >> Now consider how Apache stores the the HTTP digest credentials. It stores >> the H(A1) value which does not include the nonce. I might be wrong on >> this >> but I think that if the attacker new the H(A1), they could compute the >> response to logon to this particular realm even when a new nonce was >> presented. >> >> Cullen >> >> On 6/22/05 10:14 AM, "Avshalom Houri" wrote: >> >>> >>> Cullen, >>> >>> Not sure I understand. >>> >>> In digest, the server will send a nonce to the user thus preventing >>> replay >>> attacks by replacing the nonce every time. >>> The hashed value stored in the server can not be used for logging >>> again to the >>> server since the server will accept only nonced passwords. >>> >>> In basic authentication anyone that has an access to the server code >>> may get >>> the cleartext password and do with it whatever they want. >>> >>> Avshalom >>> >>> >>> >>> Cullen Jennings >>> Sent by: simple-bounces@ietf.org 22/06/2005 06:58 PM >>> To >>> Rohan Mahy , "simple@ietf.org" >>> cc >>> Subject >>> Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP >>> relays >>> extension >>> >>> >>> >>> >>> >>> I have not really provided much input on this issues - that is partially >>> because I could go either way if we could just finish this. That >>> said, let >>> me outline a few points that I see as relevant to the decision.... >>> >>> The significant argument I have seen made an attack where someone broke >>> into the relay server (or had access to it because they were the >>> administrator) of it and thus gained access to all the stored >>> passwords. We >>> are worried about people using the information to log in as the a >>> given user >>> to this relay and also, assuming the users use the same password other >>> places, to long on to other boxes. This is definitely an important >>> attack to >>> consider. >>> >>> If we go with the Digest route, any reasonable server will end up >>> storing >>> H(A1). It may do this directly or via a radius server. Now if someone >>> gets >>> H(A1), the can not discover my password and long on to some other server >>> where I may have used the same password. However, they can use that >>> to log >>> on to this same relay server as me. The last sentence is important, >>> using >>> Digest, if the attacker gets my stored H(A1) then can log on as me to >>> this >>> box (but not others). >>> >>> Now consider the Basic+TLS approach, any reasonable implementation will >>> store the usual hash of password plus salt solution. If an attacker gets >>> this stored information, they can log on other boxes, but even more than >>> this, they can not log onto this box using what they learned. >>> >>> Both solutions protect against the stored information being used to >>> log on >>> another box and the Digest+TLS also protects against it being used to >>> log on >>> the same relay. >>> >>> I'm not sure I view this as an amazing advantage for Basic+TLS - I >>> view the >>> real advantage of Basic+TLS be the simplicity it brings and that much of >>> what Digest is designed to provide, MSRP has no use for. >>> >>> Next point has to do with this being a password at all - if we think >>> this is >>> something a human generates, remembers, and types in, well then it is a >>> password and the above attacks are worth considering. Personally, I >>> think it >>> is going to be come configuration information generated by the system >>> and >>> downloaded to the client then used to connect to the relay. In this >>> form it >>> is far more of a cookie than a password and the above attacks are far >>> less >>> interesting because there will not be other systems that use the same >>> password. >>> >>> Cullen >>> >>> >>> >>> On 6/20/05 6:44 PM, "Rohan Mahy" wrote: >>> >>>> Hi Everyone, >>>> >>>> Despite the thread on the list from late March and early April about >>>> Basic vs Digest authentication, I don't feel like we came to consensus >>>> on this issue. First I would like to apologize for my lack of attention >>>> on this particular issue, and that it has remained open for so long. >>>> >>>> The arguments in favor of Digest authentication included a number of >>>> incorrect assumptions (marked "I") which need to be clarified in the >>>> draft. Among them: >>>> >>>> I: Relays for user B get to see the username and password for user A. >>>> A: This never happens. user A only sends AUTH requests to *its* >>>> relays, never to the relays used to forward requests on to another >>>> user. >>>> >>>> I: User B sends its password in the clear over the network. >>>> A: Use of TLS is mandatory, user B only sends its password inside a >>>> TLS-protected channel. >>>> >>>> I: The Security Area Directors will never allow this. >>>> A: Based on preliminary discussions, I believe this will be acceptable >>>> to the Security ADs. Again, use of TLS is mandatory. This is exactly >>>> like the common usage of SMTP using PLAIN user authentication over a >>>> TLS-protected channel, which is a very widely deployed model. >>>> >>>> I: If I use RADIUS I have to send the username and password in the >>>> clear >>>> A: The MSRP relay can hash the password before sending to the RADIUS >>>> server, or send all RADIUS traffic over a protected channel. >>>> >>>> There are two other concerns with Basic which are accurate: >>>> >>>> 1. If example.com has an inner relay and an outer relay, credentials >>>> for outer.example.com are revealed to inner.example.com as AUTH >>>> requests are forwarded to outer.example.com. This limitation is >>>> clearly explained in the Security Considerations section. >>>> >>>> 2. The other issue that Avshalom brought up is that the relay >>>> administrator has access to the password, or an attacker who can gain >>>> access to the relay machine. While the administrator could mount a >>>> dictionary attack on a Digest protected password, its obviously easier >>>> to get access to the password when it isn't hashed at all. >>>> >>>> When I originally tried to map the draft onto Digest, I was planning to >>>> do something like this: >>>> >>>> - realm is a string provided by the server. it SHOULD be the host name >>>> of the relay. >>>> - the domains parameter is ignored >>>> - note that the nonce algorithm based on ETags doesn't work >>>> - do not support auth-int, but always include the qop parameter with >>>> auth >>>> - the digest-uri parameter is the right-most URI in the To-Path header >>>> - the alg parameter is ??? >>>> - the cnonce and the nonce-count MUST be sent >>>> - the Method from A2 is always AUTH >>>> - there is never a body for AUTH so A2 is just AUTH: plus the >>>> Request-URI >>>> - I have no idea what to do about MD5 vs. MD5-sess. >>>> - I have no idea whether the nextnonce parameter is useful here. >>>> - I don't think the response authentication parameter is useful at all. >>>> However, the security considerations needs to describe what would or >>>> would not be protected here. Remember that we have no integrity over >>>> the Use-Path header from client to outermost relay even if we use this, >>>> unless we redefine the A2 to include the value of the Use-Path header >>>> instead of the entity-body. >>>> >>>> The arguments in favor of Basic authentication are: >>>> >>>> 1. Basic authentication is much simpler to implement than Digest, and >>>> the authors feel that with TLS protection of the channel that its >>>> security is good enough. We expect MSRP AUTH to be used within a single >>>> administrative domain, and the limitation of the server seeing the >>>> plain text password is similar to the way that many email services are >>>> deployed with TLS. >>>> >>>> 2. Digest authentication is not a great fit to MSRP and as a result its >>>> not obvious what to specify for all the parameters. >>>> >>>> >>>> What do we do? My proposal is to go with Basic. I have updated the >>>> draft leaving Basic in place. I feel this is appropriate given the >>>> relative security of the base draft, and given what would be needed to >>>> do Digest properly. If the consensus of the group is that we should do >>>> Digest instead, then I urge someone to propose specific text answering >>>> the questions I discuss above, that would go into the draft. >>>> >>>> thanks, >>>> -rohan >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > 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 Sun Jun 26 23:58:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmklR-0000QC-1p; Sun, 26 Jun 2005 23:58:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmklO-0000Q4-M7 for simple@megatron.ietf.org; Sun, 26 Jun 2005 23:58:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13227 for ; Sun, 26 Jun 2005 23:58:23 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmlAR-0005ja-Db for simple@ietf.org; Mon, 27 Jun 2005 00:24:21 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 26 Jun 2005 20:58:15 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j5R3wCbp029748; Sun, 26 Jun 2005 20:58:12 -0700 (PDT) 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); Sun, 26 Jun 2005 23:58:11 -0400 Received: from cisco.com ([10.86.240.189]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 26 Jun 2005 23:58:11 -0400 Message-ID: <42BF7952.7060603@cisco.com> Date: Sun, 26 Jun 2005 23:58:10 -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: Henning Schulzrinne Subject: Re: [Simple] RPID IANA References: <42BE1B08.3090006@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2005 03:58:11.0587 (UTC) FILETIME=[6FB35D30:01C57ACC] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Simple 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 As long as each element that contains an enumeration can be arbitrarily extended with additional elements, I think that is probably ok. However the downside to that approach is that there is no place to go to discover what all the currently defined values are. I think the problem is worse for precaps. In that case there is one mechanism for registering new feature tags that may be used in callee caps, but no corresponding mechanism for the corresponding prescaps elements. I'm troubled by that one but people haven't liked the approaches that seem to work for it. Paul Henning Schulzrinne wrote: > I'm cleaning up the RPID document to get it ready for WGLC. For > historical reasons, the document calls for IANA registries of various > items, such as activities. However, since extensions are now done via > namespaces it seems less clear that this is needed. Any opinions? > > Henning > > _______________________________________________ > 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 Jun 27 02:11:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmmpr-0005DZ-Lz; Mon, 27 Jun 2005 02:11:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmmpo-0005DL-K6 for simple@megatron.ietf.org; Mon, 27 Jun 2005 02:11:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02760 for ; Mon, 27 Jun 2005 02:11:06 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmnEt-0003Sk-O2 for simple@ietf.org; Mon, 27 Jun 2005 02:37:04 -0400 Received: from [131.161.248.83] (open-131-161-248-83.cliq.com [131.161.248.83]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j5R6Ao110279; Sun, 26 Jun 2005 23:10:50 -0700 In-Reply-To: <59441C0C-B511-478A-89D6-35CC3006C9F8@nostrum.com> References: <770e9959d3c738d838e8e7dee219ad3d@ekabal.com> <59441C0C-B511-478A-89D6-35CC3006C9F8@nostrum.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <61b30d95f6c0697c53771f44b9970b25@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension Date: Sun, 26 Jun 2005 23:10:41 -0700 To: Ben Campbell X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , "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 On Jun 24, 2005, at 8:57, Ben Campbell wrote: > I am sensitive to the fact basic is easier to implement, simpler to > specify, etc. However, "accurate concern number" 1 feels like a show > stopper. > > The particular use case I imagine is that I am roaming onto someone > else's network (a Hotel, for example) that forces all MSRP traffic > through its relay. I might have a high-security job where my > credentials must not be revealed to _anyone_ outside of my > organization. What do I do? If you have a high security job then you have no business relaying your traffic through a hotel relay regardless of protocol. Besides, you will probably use an IPsec VPN or (rarely) an SSH tunnel. Encouraging random relays run by folks you don't trust is just plain a bad idea. > If we go with basic for now, does that in any way preclude doing a > followup effort on how to use digest? no. thanks, -rohan > On Jun 20, 2005, at 8:44 PM, Rohan Mahy wrote: > >> Hi Everyone, >> >> Despite the thread on the list from late March and early April about >> Basic vs Digest authentication, I don't feel like we came to >> consensus on this issue. First I would like to apologize for my lack >> of attention on this particular issue, and that it has remained open >> for so long. >> >> The arguments in favor of Digest authentication included a number of >> incorrect assumptions (marked "I") which need to be clarified in the >> draft. Among them: >> >> I: Relays for user B get to see the username and password for user A. >> A: This never happens. user A only sends AUTH requests to *its* >> relays, never to the relays used to forward requests on to another >> user. >> >> I: User B sends its password in the clear over the network. >> A: Use of TLS is mandatory, user B only sends its password inside a >> TLS-protected channel. >> >> I: The Security Area Directors will never allow this. >> A: Based on preliminary discussions, I believe this will be >> acceptable to the Security ADs. Again, use of TLS is mandatory. >> This is exactly like the common usage of SMTP using PLAIN user >> authentication over a TLS-protected channel, which is a very widely >> deployed model. >> >> I: If I use RADIUS I have to send the username and password in the >> clear >> A: The MSRP relay can hash the password before sending to the RADIUS >> server, or send all RADIUS traffic over a protected channel. >> >> There are two other concerns with Basic which are accurate: >> >> 1. If example.com has an inner relay and an outer relay, credentials >> for outer.example.com are revealed to inner.example.com as AUTH >> requests are forwarded to outer.example.com. This limitation is >> clearly explained in the Security Considerations section. >> >> 2. The other issue that Avshalom brought up is that the relay >> administrator has access to the password, or an attacker who can gain >> access to the relay machine. While the administrator could mount a >> dictionary attack on a Digest protected password, its obviously >> easier to get access to the password when it isn't hashed at all. >> >> When I originally tried to map the draft onto Digest, I was planning >> to do something like this: >> >> - realm is a string provided by the server. it SHOULD be the host >> name of the relay. >> - the domains parameter is ignored >> - note that the nonce algorithm based on ETags doesn't work >> - do not support auth-int, but always include the qop parameter with >> auth >> - the digest-uri parameter is the right-most URI in the To-Path header >> - the alg parameter is ??? >> - the cnonce and the nonce-count MUST be sent >> - the Method from A2 is always AUTH >> - there is never a body for AUTH so A2 is just AUTH: plus the >> Request-URI >> - I have no idea what to do about MD5 vs. MD5-sess. >> - I have no idea whether the nextnonce parameter is useful here. >> - I don't think the response authentication parameter is useful at >> all. However, the security considerations needs to describe what >> would or would not be protected here. Remember that we have no >> integrity over the Use-Path header from client to outermost relay >> even if we use this, unless we redefine the A2 to include the value >> of the Use-Path header instead of the entity-body. >> >> The arguments in favor of Basic authentication are: >> >> 1. Basic authentication is much simpler to implement than Digest, and >> the authors feel that with TLS protection of the channel that its >> security is good enough. We expect MSRP AUTH to be used within a >> single administrative domain, and the limitation of the server seeing >> the plain text password is similar to the way that many email >> services are deployed with TLS. >> >> 2. Digest authentication is not a great fit to MSRP and as a result >> its not obvious what to specify for all the parameters. >> >> >> What do we do? My proposal is to go with Basic. I have updated the >> draft leaving Basic in place. I feel this is appropriate given the >> relative security of the base draft, and given what would be needed >> to do Digest properly. If the consensus of the group is that we >> should do Digest instead, then I urge someone to propose specific >> text answering the questions I discuss above, that would go into the >> draft. >> >> thanks, >> -rohan >> >> >> _______________________________________________ >> 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 Jun 27 05:54:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmqK4-0006sB-FZ; Mon, 27 Jun 2005 05:54:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmqK0-0006rt-SB for simple@megatron.ietf.org; Mon, 27 Jun 2005 05:54:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00741 for ; Mon, 27 Jun 2005 05:54:30 -0400 (EDT) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmqj8-0008LF-Ai for simple@ietf.org; Mon, 27 Jun 2005 06:20:31 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 53EE7194459 for ; Mon, 27 Jun 2005 11:54:21 +0200 (CEST) Received: from [10.0.0.1] ([82.194.52.5]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Jun 2005 11:58:07 +0200 In-Reply-To: <42BEF0BB.6080405@nokia.com> References: <0cccd4bbc210cb4dcfea49ed0234c0dc@telio.no> <42BEF0BB.6080405@nokia.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: Hisham Khartabil Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension Date: Mon, 27 Jun 2005 11:54:15 +0200 To: Aki Niemi X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 27 Jun 2005 09:58:08.0247 (UTC) FILETIME=[B8502870:01C57AFE] X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Avshalom Houri , "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 On Jun 26, 2005, at 8:15 PM, Aki Niemi wrote: > Inline. > > ext Hisham Khartabil wrote: >> You're not selling the Basic Authentication solution very well. >> Simplicity is not a good reason as far as I'm concerned. You could >> argue your same arguments for SIP Basic authentication (that >> Basic+TLS and hash+salt is enough), but we deprecated Basic still, >> for a reason. Why doesnt that reason also apply to MRSP relays? > > Comparing SIP and MSRP may not be that wise here. The SIP model > differs from the MSRP relay model significantly, since in SIP TLS is > only hop-by-hop, and so even with transport security, an outbound > proxy would have full access to the Basic password. > > Since in MSRP the client is supposed to have a TLS session up with the > relay before any authentication is done, I don't see the problem. > > I would also like to separate protocol security from the discussion of > how credentials are stored in the relay. IMHO, the latter can be > screwed up in so many ways [1] we may just as well simply concentrate > on the former. The latter is also an implementation issue. > >> People have concerns with Basic. Using Digest well not compromise the >> security of the system, and will make everybody happy. Unless you >> have real technical issues and concerns with using Digest, I believe >> we need to go with it. > > I'm fine with Basic. The question I'm trying to ask is: Are you fine with Digest also? (I think we can safely assume that Digest is just as good as Basic in this case :) ) If Digest does the job, and makes everyone happy, then we use it. What is the technical objection for using Digest? > I agree it's easier to implement, interoperates better and works fine > when used in a TLS session authenticated with a server certificate. I agree with those points also, but they do not address some of folk's concerns including storing passwords in the clear, etc. Hisham > > Digest would be an option if TLS was somehow deemed insufficient, or > too much of a burden. It is neither, since TLS+basic (or > username/password in an HTML form) has been proven to work in the web, > and as has been pointed out by various people in other threads, server > certificates are nowadays really dirt cheap. > > Cheers, > Aki > > [1] Referring to the recent credit card number theft, where I'm sure > most if not all numbers were sent via an SSL protected site. > >> Regards, >> Hisham >> On Jun 25, 2005, at 5:45 PM, Cullen Jennings wrote: >>> >>> Consider how a password works on a UNIX system, if you get access to >>> the >>> /etc/passwd file, you don't find out what my password is because the >>> password is not stored but instead a hashed+salt version of it is. >>> This is >>> how people that implemented the Basic+TLS scheme would do it. >>> >>> Now consider how Apache stores the the HTTP digest credentials. It >>> stores >>> the H(A1) value which does not include the nonce. I might be wrong >>> on this >>> but I think that if the attacker new the H(A1), they could compute >>> the >>> response to logon to this particular realm even when a new nonce was >>> presented. >>> >>> Cullen >>> >>> On 6/22/05 10:14 AM, "Avshalom Houri" wrote: >>> >>>> >>>> Cullen, >>>> >>>> Not sure I understand. >>>> >>>> In digest, the server will send a nonce to the user thus preventing >>>> replay >>>> attacks by replacing the nonce every time. >>>> The hashed value stored in the server can not be used for logging >>>> again to the >>>> server since the server will accept only nonced passwords. >>>> >>>> In basic authentication anyone that has an access to the server >>>> code may get >>>> the cleartext password and do with it whatever they want. >>>> >>>> Avshalom >>>> >>>> >>>> >>>> Cullen Jennings >>>> Sent by: simple-bounces@ietf.org 22/06/2005 06:58 PM >>>> To >>>> Rohan Mahy , "simple@ietf.org" >>>> cc >>>> Subject >>>> Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP >>>> relays >>>> extension >>>> >>>> >>>> >>>> >>>> >>>> I have not really provided much input on this issues - that is >>>> partially >>>> because I could go either way if we could just finish this. That >>>> said, let >>>> me outline a few points that I see as relevant to the decision.... >>>> >>>> The significant argument I have seen made an attack where someone >>>> broke >>>> into the relay server (or had access to it because they were the >>>> administrator) of it and thus gained access to all the stored >>>> passwords. We >>>> are worried about people using the information to log in as the a >>>> given user >>>> to this relay and also, assuming the users use the same password >>>> other >>>> places, to long on to other boxes. This is definitely an important >>>> attack to >>>> consider. >>>> >>>> If we go with the Digest route, any reasonable server will end up >>>> storing >>>> H(A1). It may do this directly or via a radius server. Now if >>>> someone gets >>>> H(A1), the can not discover my password and long on to some other >>>> server >>>> where I may have used the same password. However, they can use that >>>> to log >>>> on to this same relay server as me. The last sentence is important, >>>> using >>>> Digest, if the attacker gets my stored H(A1) then can log on as me >>>> to this >>>> box (but not others). >>>> >>>> Now consider the Basic+TLS approach, any reasonable implementation >>>> will >>>> store the usual hash of password plus salt solution. If an attacker >>>> gets >>>> this stored information, they can log on other boxes, but even more >>>> than >>>> this, they can not log onto this box using what they learned. >>>> >>>> Both solutions protect against the stored information being used to >>>> log on >>>> another box and the Digest+TLS also protects against it being used >>>> to log on >>>> the same relay. >>>> >>>> I'm not sure I view this as an amazing advantage for Basic+TLS - I >>>> view the >>>> real advantage of Basic+TLS be the simplicity it brings and that >>>> much of >>>> what Digest is designed to provide, MSRP has no use for. >>>> >>>> Next point has to do with this being a password at all - if we >>>> think this is >>>> something a human generates, remembers, and types in, well then it >>>> is a >>>> password and the above attacks are worth considering. Personally, I >>>> think it >>>> is going to be come configuration information generated by the >>>> system and >>>> downloaded to the client then used to connect to the relay. In this >>>> form it >>>> is far more of a cookie than a password and the above attacks are >>>> far less >>>> interesting because there will not be other systems that use the >>>> same >>>> password. >>>> >>>> Cullen >>>> >>>> >>>> >>>> On 6/20/05 6:44 PM, "Rohan Mahy" wrote: >>>> >>>>> Hi Everyone, >>>>> >>>>> Despite the thread on the list from late March and early April >>>>> about >>>>> Basic vs Digest authentication, I don't feel like we came to >>>>> consensus >>>>> on this issue. First I would like to apologize for my lack of >>>>> attention >>>>> on this particular issue, and that it has remained open for so >>>>> long. >>>>> >>>>> The arguments in favor of Digest authentication included a number >>>>> of >>>>> incorrect assumptions (marked "I") which need to be clarified in >>>>> the >>>>> draft. Among them: >>>>> >>>>> I: Relays for user B get to see the username and password for user >>>>> A. >>>>> A: This never happens. user A only sends AUTH requests to *its* >>>>> relays, never to the relays used to forward requests on to another >>>>> user. >>>>> >>>>> I: User B sends its password in the clear over the network. >>>>> A: Use of TLS is mandatory, user B only sends its password inside a >>>>> TLS-protected channel. >>>>> >>>>> I: The Security Area Directors will never allow this. >>>>> A: Based on preliminary discussions, I believe this will be >>>>> acceptable >>>>> to the Security ADs. Again, use of TLS is mandatory. This is >>>>> exactly >>>>> like the common usage of SMTP using PLAIN user authentication over >>>>> a >>>>> TLS-protected channel, which is a very widely deployed model. >>>>> >>>>> I: If I use RADIUS I have to send the username and password in the >>>>> clear >>>>> A: The MSRP relay can hash the password before sending to the >>>>> RADIUS >>>>> server, or send all RADIUS traffic over a protected channel. >>>>> >>>>> There are two other concerns with Basic which are accurate: >>>>> >>>>> 1. If example.com has an inner relay and an outer relay, >>>>> credentials >>>>> for outer.example.com are revealed to inner.example.com as AUTH >>>>> requests are forwarded to outer.example.com. This limitation is >>>>> clearly explained in the Security Considerations section. >>>>> >>>>> 2. The other issue that Avshalom brought up is that the relay >>>>> administrator has access to the password, or an attacker who can >>>>> gain >>>>> access to the relay machine. While the administrator could mount a >>>>> dictionary attack on a Digest protected password, its obviously >>>>> easier >>>>> to get access to the password when it isn't hashed at all. >>>>> >>>>> When I originally tried to map the draft onto Digest, I was >>>>> planning to >>>>> do something like this: >>>>> >>>>> - realm is a string provided by the server. it SHOULD be the host >>>>> name >>>>> of the relay. >>>>> - the domains parameter is ignored >>>>> - note that the nonce algorithm based on ETags doesn't work >>>>> - do not support auth-int, but always include the qop parameter >>>>> with >>>>> auth >>>>> - the digest-uri parameter is the right-most URI in the To-Path >>>>> header >>>>> - the alg parameter is ??? >>>>> - the cnonce and the nonce-count MUST be sent >>>>> - the Method from A2 is always AUTH >>>>> - there is never a body for AUTH so A2 is just AUTH: plus the >>>>> Request-URI >>>>> - I have no idea what to do about MD5 vs. MD5-sess. >>>>> - I have no idea whether the nextnonce parameter is useful here. >>>>> - I don't think the response authentication parameter is useful at >>>>> all. >>>>> However, the security considerations needs to describe what >>>>> would or >>>>> would not be protected here. Remember that we have no integrity >>>>> over >>>>> the Use-Path header from client to outermost relay even if we use >>>>> this, >>>>> unless we redefine the A2 to include the value of the Use-Path >>>>> header >>>>> instead of the entity-body. >>>>> >>>>> The arguments in favor of Basic authentication are: >>>>> >>>>> 1. Basic authentication is much simpler to implement than Digest, >>>>> and >>>>> the authors feel that with TLS protection of the channel that its >>>>> security is good enough. We expect MSRP AUTH to be used within a >>>>> single >>>>> administrative domain, and the limitation of the server seeing the >>>>> plain text password is similar to the way that many email services >>>>> are >>>>> deployed with TLS. >>>>> >>>>> 2. Digest authentication is not a great fit to MSRP and as a >>>>> result its >>>>> not obvious what to specify for all the parameters. >>>>> >>>>> >>>>> What do we do? My proposal is to go with Basic. I have updated >>>>> the >>>>> draft leaving Basic in place. I feel this is appropriate given the >>>>> relative security of the base draft, and given what would be >>>>> needed to >>>>> do Digest properly. If the consensus of the group is that we >>>>> should do >>>>> Digest instead, then I urge someone to propose specific text >>>>> answering >>>>> the questions I discuss above, that would go into the draft. >>>>> >>>>> thanks, >>>>> -rohan >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> _______________________________________________ >> 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 Jun 27 10:18:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmuR4-0004RR-Hv; Mon, 27 Jun 2005 10:18:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmuR2-0004R0-H0 for simple@megatron.ietf.org; Mon, 27 Jun 2005 10:18:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25571 for ; Mon, 27 Jun 2005 10:18:01 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmuqB-0005Hh-4k for simple@ietf.org; Mon, 27 Jun 2005 10:44:04 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j5REHra6143962 for ; Mon, 27 Jun 2005 14:17:53 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5REHqRW084954 for ; Mon, 27 Jun 2005 16:17:52 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j5REHqnW028340 for ; Mon, 27 Jun 2005 16:17:52 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j5REHqGO028337; Mon, 27 Jun 2005 16:17:52 +0200 In-Reply-To: To: "simple@ietf.org" Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04112005NP April 11, 2005 Message-ID: From: Avshalom Houri Date: Mon, 27 Jun 2005 17:17:50 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(V70_M4_01112005 Sidepack 2802|March 1, 2005) at 27/06/2005 17:17:52, Serialize complete at 27/06/2005 17:17:52 X-Spam-Score: 2.6 (++) X-Scan-Signature: 9b281509fec590bb711c36d4c3ba4f74 Cc: Cullen Jennings , Aki Niemi 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="===============0380308261==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============0380308261== Content-Type: text/html; charset="US-ASCII"
From RFC 2617:

 request-digest  = <"> < KD ( H(A1),     unq(nonce-value)
                                          ":" nc-value
                                          ":" unq(cnonce-value)
                                          ":" unq(qop-value)
                                          ":" H(A2)
                                  ) <">

A1       = unq(username-value) ":" unq(realm-value) ":" passwd


--------------

So if the server has H(A1) stored and it is compromised, the attacker is able
to login to the servers that serve the same realm and use digest. The attacker
will have to re-ngineer client software in order to really be able to make use
of H(A1).

However, if the server actually gets the clear password somewhere during the
authentication (even if it was sent via TLS) process then the attacker can use
any normal UI interface to pretend to be that user. I doubt if this will be
acceptable for enterprises.

In addition, scenario 1 in Rohan's email below is still very concerning
(as Ben have described and you do not need to have a high security job
in order to be concerned about this scenario).

In order to go ahead can we come with a way to enable a relay to offer basic
or digest or other method in its 401 response? This way servers can be configured
to use different methods according to the required security level and clients can
reject too weak method if they want. This will also enable clients that do not
have enough memory/CPU and that work in a protected environment to use only basic
authentication.

Avshalom




Hisham Khartabil <hisham.khartabil@telio.no>

27/06/2005 12:54 PM

To
Aki Niemi <aki.niemi@nokia.com>
cc
"simple@ietf.org" <simple@ietf.org>, Cullen Jennings <fluffy@cisco.com>, Avshalom Houri/Haifa/IBM@IBMIL
Subject
Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension






On Jun 26, 2005, at 8:15 PM, Aki Niemi wrote:

> Inline.
>
> ext Hisham Khartabil wrote:
>> You're not selling the Basic Authentication solution very well.
>> Simplicity is not a good reason as far as I'm concerned. You could
>> argue your same arguments for SIP Basic authentication (that
>> Basic+TLS and hash+salt is enough), but we deprecated Basic still,
>> for a reason. Why doesnt that reason also apply to MRSP relays?
>
> Comparing SIP and MSRP may not be that wise here. The SIP model
> differs from the MSRP relay model significantly, since in SIP TLS is
> only hop-by-hop, and so even with transport security, an outbound
> proxy would have full access to the Basic password.
>
> Since in MSRP the client is supposed to have a TLS session up with the
> relay before any authentication is done, I don't see the problem.
>
> I would also like to separate protocol security from the discussion of
> how credentials are stored in the relay. IMHO, the latter can be
> screwed up in so many ways [1] we may just as well simply concentrate
> on the former. The latter is also an implementation issue.
>
>> People have concerns with Basic. Using Digest well not compromise the
>> security of the system, and will make everybody happy. Unless you
>> have real technical issues and concerns with using Digest, I believe
>> we need to go with it.
>
> I'm fine with Basic.

The question I'm trying to ask is: Are you fine with Digest also? (I
think we can safely assume that Digest is just as good as Basic in this
case :) ) If Digest does the job, and makes everyone happy, then we use
it. What is the technical objection for using Digest?

> I agree it's easier to implement, interoperates better and works fine
> when used in a TLS session authenticated with a server certificate.

I agree with those points also, but they do not address some of folk's
concerns including storing passwords in the clear, etc.

Hisham

>
> Digest would be an option if TLS was somehow deemed insufficient, or
> too much of a burden. It is neither, since TLS+basic (or
> username/password in an HTML form) has been proven to work in the web,
> and as has been pointed out by various people in other threads, server
> certificates are nowadays really dirt cheap.
>
> Cheers,
> Aki
>
> [1] Referring to the recent credit card number theft, where I'm sure
> most if not all numbers were sent via an SSL protected site.
>
>> Regards,
>> Hisham
>> On Jun 25, 2005, at 5:45 PM, Cullen Jennings wrote:
>>>
>>> Consider how a password works on a UNIX system, if you get access to
>>> the
>>> /etc/passwd file, you don't find out what my password is because the
>>> password is not stored but instead a hashed+salt version of it is.
>>> This is
>>> how people that implemented the Basic+TLS scheme would do it.
>>>
>>> Now consider how Apache stores the the HTTP digest credentials. It
>>> stores
>>> the H(A1) value which does not include the nonce. I might be wrong
>>> on this
>>> but I think that if the attacker new the H(A1), they could compute
>>> the
>>> response to logon to this particular realm even when a new nonce was
>>> presented.
>>>
>>> Cullen
>>>
>>> On 6/22/05 10:14 AM, "Avshalom Houri" <AVSHALOM@il.ibm.com> wrote:
>>>
>>>>
>>>> Cullen,
>>>>
>>>> Not sure I understand.
>>>>
>>>> In digest, the server will send a nonce to the user thus preventing
>>>> replay
>>>> attacks by replacing the nonce every time.
>>>> The hashed value stored in the server can not be used for logging
>>>> again to the
>>>> server since the server will accept only nonced passwords.
>>>>
>>>> In basic authentication anyone that has an access to the server
>>>> code may get
>>>> the cleartext password and do with it whatever they want.
>>>>
>>>> Avshalom
>>>>
>>>>
>>>>
>>>> Cullen Jennings <fluffy@cisco.com>
>>>> Sent by: simple-bounces@ietf.org 22/06/2005 06:58 PM
>>>> To
>>>> Rohan Mahy <rohan@ekabal.com>, "simple@ietf.org" <simple@ietf.org>
>>>> cc
>>>> Subject
>>>> Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP    
>>>>     relays
>>>> extension
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I have not really provided much input on this issues - that is
>>>> partially
>>>> because I could go either way if we could just finish this. That
>>>> said, let
>>>> me outline a few points that I see as relevant to the decision....
>>>>
>>>> The significant argument  I have seen made an attack where someone
>>>> broke
>>>> into the relay server (or had access to it because they were the
>>>> administrator) of it and thus gained access to all the stored
>>>> passwords. We
>>>> are worried about people using the information to log in as the a
>>>> given user
>>>> to this relay and also, assuming the users use the same password
>>>> other
>>>> places, to long on to other boxes. This is definitely an important
>>>> attack to
>>>> consider.
>>>>
>>>> If we go with the Digest route, any reasonable server will end up
>>>> storing
>>>> H(A1). It may do this directly or via a radius server. Now if
>>>> someone gets
>>>> H(A1), the can not discover my password and long on to some other
>>>> server
>>>> where I may have used the same password. However, they can use that
>>>> to log
>>>> on to this same relay server as me. The last sentence is important,
>>>> using
>>>> Digest, if the attacker gets my stored H(A1) then can log on as me
>>>> to this
>>>> box (but not others).
>>>>
>>>> Now consider the Basic+TLS approach, any reasonable implementation
>>>> will
>>>> store the usual hash of password plus salt solution. If an attacker
>>>> gets
>>>> this stored information, they can log on other boxes, but even more
>>>> than
>>>> this, they can not log onto this box using what they learned.
>>>>
>>>> Both solutions protect against the stored information being used to
>>>> log on
>>>> another box and the Digest+TLS also protects against it being used
>>>> to log on
>>>> the same relay.
>>>>
>>>> I'm not sure I view this as an amazing advantage for Basic+TLS - I
>>>> view the
>>>> real advantage of Basic+TLS be the simplicity it brings and that
>>>> much of
>>>> what Digest is designed to provide, MSRP has no use for.
>>>>
>>>> Next point has to do with this being a password at all - if we
>>>> think this is
>>>> something a human generates, remembers, and types in, well then it
>>>> is a
>>>> password and the above attacks are worth considering. Personally, I
>>>> think it
>>>> is going to be come configuration information generated by the
>>>> system and
>>>> downloaded to the client then used to connect to the relay. In this
>>>> form it
>>>> is far more of a cookie than a password and the above attacks are
>>>> far less
>>>> interesting because there will not be other systems that use the
>>>> same
>>>> password.
>>>>
>>>> Cullen
>>>>
>>>>
>>>>
>>>> On 6/20/05 6:44 PM, "Rohan Mahy" <rohan@ekabal.com> wrote:
>>>>
>>>>> Hi Everyone,
>>>>>
>>>>> Despite the thread on the list from late March and early April
>>>>> about
>>>>> Basic vs Digest authentication, I don't feel like we came to
>>>>> consensus
>>>>> on this issue. First I would like to apologize for my lack of
>>>>> attention
>>>>> on this particular issue, and that it has remained open for so
>>>>> long.
>>>>>
>>>>> The arguments in favor of Digest authentication included a number
>>>>> of
>>>>> incorrect assumptions (marked "I") which need to be clarified in
>>>>> the
>>>>> draft.  Among them:
>>>>>
>>>>> I: Relays for user B get to see the username and password for user
>>>>> A.
>>>>> A: This never happens.  user A only sends AUTH requests to *its*
>>>>> relays, never to the relays used to forward requests on to another
>>>>> user.
>>>>>
>>>>> I: User B sends its password in the clear over the network.
>>>>> A: Use of TLS is mandatory, user B only sends its password inside a
>>>>> TLS-protected channel.
>>>>>
>>>>> I: The Security Area Directors will never allow this.
>>>>> A: Based on preliminary discussions, I believe this will be
>>>>> acceptable
>>>>> to the Security ADs.  Again, use of TLS is mandatory.  This is
>>>>> exactly
>>>>> like the common usage of SMTP using PLAIN user authentication over
>>>>> a
>>>>> TLS-protected channel, which is a very widely deployed model.
>>>>>
>>>>> I: If I use RADIUS I have to send the username and password in the
>>>>> clear
>>>>> A: The MSRP relay can hash the password before sending to the
>>>>> RADIUS
>>>>> server, or send all RADIUS traffic over a protected channel.
>>>>>
>>>>> There are two other concerns with Basic which are accurate:
>>>>>
>>>>> 1. If example.com has an inner relay and an outer relay,
>>>>> credentials
>>>>> for outer.example.com are revealed to inner.example.com as AUTH
>>>>> requests are forwarded to outer.example.com.  This limitation is
>>>>> clearly explained in the Security Considerations section.
>>>>>
>>>>> 2. The other issue that Avshalom brought up is that the relay
>>>>> administrator has access to the password, or an attacker who can
>>>>> gain
>>>>> access to the relay machine.  While the administrator could mount a
>>>>> dictionary attack on a Digest protected password, its obviously
>>>>> easier
>>>>> to get access to the password when it isn't hashed at all.
>>>>>
>>>>> When I originally tried to map the draft onto Digest, I was
>>>>> planning to
>>>>> do something like this:
>>>>>
>>>>> - realm is a string provided by the server. it SHOULD be the host
>>>>> name
>>>>> of the relay.
>>>>> - the domains parameter is ignored
>>>>> - note that the nonce algorithm based on ETags doesn't work
>>>>> - do not support auth-int, but always include the qop parameter
>>>>> with
>>>>> auth
>>>>> - the digest-uri parameter is the right-most URI in the To-Path
>>>>> header
>>>>> - the alg parameter is ???
>>>>> - the cnonce and the nonce-count MUST be sent
>>>>> - the Method from A2 is always AUTH
>>>>> - there is never a body for AUTH so A2 is just AUTH: plus the
>>>>> Request-URI
>>>>> - I have no idea what to do about MD5 vs. MD5-sess.
>>>>> - I have no idea whether the nextnonce parameter is useful here.
>>>>> - I don't think the response authentication parameter is useful at
>>>>> all.
>>>>>   However, the security considerations needs to describe what
>>>>> would or
>>>>> would not be protected here.  Remember that we have no integrity
>>>>> over
>>>>> the Use-Path header from client to outermost relay even if we use
>>>>> this,
>>>>> unless we redefine the A2 to include the value of the Use-Path
>>>>> header
>>>>> instead of the entity-body.
>>>>>
>>>>> The arguments in favor of Basic authentication are:
>>>>>
>>>>> 1. Basic authentication is much simpler to implement than Digest,
>>>>> and
>>>>> the authors feel that with TLS protection of the channel that its
>>>>> security is good enough. We expect MSRP AUTH to be used within a
>>>>> single
>>>>> administrative domain, and the limitation of the server seeing the
>>>>> plain text password is similar to the way that many email services
>>>>> are
>>>>> deployed with TLS.
>>>>>
>>>>> 2. Digest authentication is not a great fit to MSRP and as a
>>>>> result its
>>>>> not obvious what to specify for all the parameters.
>>>>>
>>>>>
>>>>> What do we do?  My proposal is to go with Basic.  I have updated
>>>>> the
>>>>> draft leaving Basic in place.  I feel this is appropriate given the
>>>>> relative security of the base draft, and given what would be
>>>>> needed to
>>>>> do Digest properly.  If the consensus of the group is that we
>>>>> should do
>>>>> Digest instead, then I urge someone to propose specific text
>>>>> answering
>>>>> the questions I discuss above, that would go into the draft.
>>>>>
>>>>> thanks,
>>>>> -rohan
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Simple mailing list
>>>>> Simple@ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/simple
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Simple mailing list
>>>> Simple@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/simple
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Simple mailing list
>>>> Simple@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/simple
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Simple mailing list
>>> Simple@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/simple
>>>
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www1.ietf.org/mailman/listinfo/simple
>
--===============0380308261== 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 --===============0380308261==-- From simple-bounces@ietf.org Mon Jun 27 10:40:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmun9-0000VD-Lb; Mon, 27 Jun 2005 10:40:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmun8-0000V3-8A for simple@megatron.ietf.org; Mon, 27 Jun 2005 10:40:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28674 for ; Mon, 27 Jun 2005 10:40:51 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmvCH-0006Ej-Fu for simple@ietf.org; Mon, 27 Jun 2005 11:06:54 -0400 Received: from [10.59.1.25] (h-67-103-241-182.lsanca54.covad.net [67.103.241.182]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5REdWbe023270 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 27 Jun 2005 10:39:34 -0400 (EDT) In-Reply-To: <42BF7952.7060603@cisco.com> References: <42BE1B08.3090006@cs.columbia.edu> <42BF7952.7060603@cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Simple] RPID IANA Date: Mon, 27 Jun 2005 10:39:33 -0400 To: Paul Kyzivat X-Mailer: Apple Mail (2.730) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: Simple 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 On Jun 26, 2005, at 11:58 PM, Paul Kyzivat wrote: > As long as each element that contains an enumeration can be > arbitrarily extended with additional elements, I think that is > probably ok. However the downside to that approach is that there is > no place to go to discover what all the currently defined values are. Indeed; one approach to deal with this is to require the same extension mechanism as for PIDF. In particular, rather than having separate registries for each of these items, simply say that any extension (could be new top-level elements parallel to or a new activity value) need to be registered via IANA. This doesn't prevent private extensions, but that isn't the goal. > > I think the problem is worse for precaps. In that case there is one > mechanism for registering new feature tags that may be used in > callee caps, but no corresponding mechanism for the corresponding > prescaps elements. I'm troubled by that one but people haven't > liked the approaches that seem to work for it. > > Paul > > Henning Schulzrinne wrote: > >> I'm cleaning up the RPID document to get it ready for WGLC. For >> historical reasons, the document calls for IANA registries of >> various items, such as activities. However, since extensions are >> now done via namespaces it seems less clear that this is needed. >> Any opinions? >> Henning >> _______________________________________________ >> 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 Jun 27 11:38:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmvgR-00048l-Vh; Mon, 27 Jun 2005 11:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmvgQ-00048c-D0 for simple@megatron.ietf.org; Mon, 27 Jun 2005 11:38:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03865 for ; Mon, 27 Jun 2005 11:37:59 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmw5Y-00088L-Sr for simple@ietf.org; Mon, 27 Jun 2005 12:04:03 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j5RFboew231126 for ; Mon, 27 Jun 2005 15:37:50 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5RFboRW110796 for ; Mon, 27 Jun 2005 17:37:50 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j5RFbo6s013031 for ; Mon, 27 Jun 2005 17:37:50 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j5RFboob013028 for ; Mon, 27 Jun 2005 17:37:50 +0200 In-Reply-To: <42BAE8E7.4010405@cisco.com> To: Simple WG Subject: Re: [Simple] SIMPLE meeting in Paris MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04112005NP April 11, 2005 Message-ID: From: Avshalom Houri Date: Mon, 27 Jun 2005 18:37:48 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(V70_M4_01112005 Sidepack 2802|March 1, 2005) at 27/06/2005 18:37:50, Serialize complete at 27/06/2005 18:37:50 X-Spam-Score: 2.6 (++) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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="===============1329416390==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1329416390== Content-Type: text/html; charset="US-ASCII"
We should give a push to the arch document. I have started something but it has expired and a lot have been changed
in SIMPLE.

The document is part of the charter and is going to be very long document with a lot of effort.

Avshalom



Paul Kyzivat <pkyzivat@cisco.com>
Sent by: simple-bounces@ietf.org

23/06/2005 07:52 PM

To
Henning Schulzrinne <hgs@cs.columbia.edu>
cc
Simple WG <simple@ietf.org>
Subject
Re: [Simple] SIMPLE meeting in Paris





I think there is a subject that hasn't been seriously discussed that IMO
SHOULD be within the charter of SIMPLE. If it looks like everything else
is wrapping up it may be time to consider it.

That subject is the coexistence and/or interoperation of page mode and
session mode IM, and perhaps other forms such as XMPP. I think we are on
a path towards a balkanized world where different even those who
"implement SIMPLE" can't exchange IMs.

Exactly how to deal with this - usage guidelines, gateways, etc. is an
open question to me right now.

Another area where we have so far punted in presence composition
policies. However here it may just be that the time isn't right - that
nobody has enough experience to propose something useful.

The above is not intended to suggest that we need more time in Paris.
But it is intended to suggest that it might be premature for SIMPLE to
close up shop. We might want to discuss charter changes.

                Paul

Henning Schulzrinne wrote:
> I think the theme for the meeting should be "what do we need to do to
> finish this item up well before the next meeting"? Our charter ran out
> in September 2004 (and we aren't even working on the last charter item,
> as far as I can tell). Having commitments and WGLC dates planned ahead
> of time might also provide additional thrust.
>
> Robert Sparks wrote:
>
>> Folks -
>>
>> Just a heads up -
>>
>> Given the use of our slots in Minneapolis and the current set of
>> threads on the list,
>> I'm having a hard time justifying to myself a request for more than a
>> single 2.5 hr
>> slot in Paris. That's what I'm currently planning to put in a request
>> for.
>>
>> RjS
>>
>>
>> _______________________________________________
>> 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
--===============1329416390== 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 --===============1329416390==-- From simple-bounces@ietf.org Mon Jun 27 12:12:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmwDk-0002gm-Se; Mon, 27 Jun 2005 12:12:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmwDi-0002dk-RO for simple@megatron.ietf.org; Mon, 27 Jun 2005 12:12:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07510 for ; Mon, 27 Jun 2005 12:12:23 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmwct-0000ls-2V for simple@ietf.org; Mon, 27 Jun 2005 12:38:28 -0400 Received: from [192.168.2.181] (63-239-8-31.priorityevents.net [63.239.8.31]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5RGCL7T022484 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 27 Jun 2005 12:12:22 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Simple] SIMPLE meeting in Paris Date: Mon, 27 Jun 2005 12:12:23 -0400 To: Avshalom Houri X-Mailer: Apple Mail (2.730) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Simple 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 Given the data model and related documents, I think we can keep this to be more of a "road map" to the SIMPLE (and some GEOPRIV) documents, rather than a 50 pager. That might actually cause it to get published this decade... On Jun 27, 2005, at 11:37 AM, Avshalom Houri wrote: > > We should give a push to the arch document. I have started > something but it has expired and a lot have been changed > in SIMPLE. > > The document is part of the charter and is going to be very long > document with a lot of effort. > > Avshalom > > > > Paul Kyzivat > Sent by: simple-bounces@ietf.org > 23/06/2005 07:52 PM > > To > Henning Schulzrinne > cc > Simple WG > Subject > Re: [Simple] SIMPLE meeting in Paris > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 27 15:44:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmzX0-0004aK-3U; Mon, 27 Jun 2005 15:44:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmzWy-0004aA-RA for simple@megatron.ietf.org; Mon, 27 Jun 2005 15:44:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29038 for ; Mon, 27 Jun 2005 15:44:30 -0400 (EDT) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmzwB-00007m-2f for simple@ietf.org; Mon, 27 Jun 2005 16:10:36 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5RJhHgu031114; Mon, 27 Jun 2005 22:43:17 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Jun 2005 22:43:17 +0300 Received: from [192.168.1.175] ([10.162.252.208]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 27 Jun 2005 22:43:18 +0300 Message-ID: <42C056D3.5080308@nokia.com> Date: Mon, 27 Jun 2005 22:43:15 +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 Hisham Khartabil Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension References: <0cccd4bbc210cb4dcfea49ed0234c0dc@telio.no> <42BEF0BB.6080405@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2005 19:43:18.0161 (UTC) FILETIME=[7773E010:01C57B50] X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Avshalom Houri , "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 ext Hisham Khartabil wrote: >> >> I'm fine with Basic. > > > The question I'm trying to ask is: Are you fine with Digest also? (I > think we can safely assume that Digest is just as good as Basic in this > case :) ) If Digest does the job, and makes everyone happy, then we use > it. What is the technical objection for using Digest? No, I'm not fine with digest. It isn't "just as good" considering that it is harder to specify and implement. I think you're asking the question the wrong way. >> I agree it's easier to implement, interoperates better and works fine >> when used in a TLS session authenticated with a server certificate. > > > I agree with those points also, but they do not address some of folk's > concerns including storing passwords in the clear, etc. Like I said, that seems like a different problem, and an implementation issue. Cheers, Aki > Hisham > >> >> Digest would be an option if TLS was somehow deemed insufficient, or >> too much of a burden. It is neither, since TLS+basic (or >> username/password in an HTML form) has been proven to work in the web, >> and as has been pointed out by various people in other threads, server >> certificates are nowadays really dirt cheap. >> >> Cheers, >> Aki >> >> [1] Referring to the recent credit card number theft, where I'm sure >> most if not all numbers were sent via an SSL protected site. >> >>> Regards, >>> Hisham >>> On Jun 25, 2005, at 5:45 PM, Cullen Jennings wrote: >>> >>>> >>>> Consider how a password works on a UNIX system, if you get access to >>>> the >>>> /etc/passwd file, you don't find out what my password is because the >>>> password is not stored but instead a hashed+salt version of it is. >>>> This is >>>> how people that implemented the Basic+TLS scheme would do it. >>>> >>>> Now consider how Apache stores the the HTTP digest credentials. It >>>> stores >>>> the H(A1) value which does not include the nonce. I might be wrong >>>> on this >>>> but I think that if the attacker new the H(A1), they could compute the >>>> response to logon to this particular realm even when a new nonce was >>>> presented. >>>> >>>> Cullen >>>> >>>> On 6/22/05 10:14 AM, "Avshalom Houri" wrote: >>>> >>>>> >>>>> Cullen, >>>>> >>>>> Not sure I understand. >>>>> >>>>> In digest, the server will send a nonce to the user thus preventing >>>>> replay >>>>> attacks by replacing the nonce every time. >>>>> The hashed value stored in the server can not be used for logging >>>>> again to the >>>>> server since the server will accept only nonced passwords. >>>>> >>>>> In basic authentication anyone that has an access to the server >>>>> code may get >>>>> the cleartext password and do with it whatever they want. >>>>> >>>>> Avshalom >>>>> >>>>> >>>>> >>>>> Cullen Jennings >>>>> Sent by: simple-bounces@ietf.org 22/06/2005 06:58 PM >>>>> To >>>>> Rohan Mahy , "simple@ietf.org" >>>>> cc >>>>> Subject >>>>> Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP >>>>> relays >>>>> extension >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I have not really provided much input on this issues - that is >>>>> partially >>>>> because I could go either way if we could just finish this. That >>>>> said, let >>>>> me outline a few points that I see as relevant to the decision.... >>>>> >>>>> The significant argument I have seen made an attack where someone >>>>> broke >>>>> into the relay server (or had access to it because they were the >>>>> administrator) of it and thus gained access to all the stored >>>>> passwords. We >>>>> are worried about people using the information to log in as the a >>>>> given user >>>>> to this relay and also, assuming the users use the same password other >>>>> places, to long on to other boxes. This is definitely an important >>>>> attack to >>>>> consider. >>>>> >>>>> If we go with the Digest route, any reasonable server will end up >>>>> storing >>>>> H(A1). It may do this directly or via a radius server. Now if >>>>> someone gets >>>>> H(A1), the can not discover my password and long on to some other >>>>> server >>>>> where I may have used the same password. However, they can use that >>>>> to log >>>>> on to this same relay server as me. The last sentence is important, >>>>> using >>>>> Digest, if the attacker gets my stored H(A1) then can log on as me >>>>> to this >>>>> box (but not others). >>>>> >>>>> Now consider the Basic+TLS approach, any reasonable implementation >>>>> will >>>>> store the usual hash of password plus salt solution. If an attacker >>>>> gets >>>>> this stored information, they can log on other boxes, but even more >>>>> than >>>>> this, they can not log onto this box using what they learned. >>>>> >>>>> Both solutions protect against the stored information being used to >>>>> log on >>>>> another box and the Digest+TLS also protects against it being used >>>>> to log on >>>>> the same relay. >>>>> >>>>> I'm not sure I view this as an amazing advantage for Basic+TLS - I >>>>> view the >>>>> real advantage of Basic+TLS be the simplicity it brings and that >>>>> much of >>>>> what Digest is designed to provide, MSRP has no use for. >>>>> >>>>> Next point has to do with this being a password at all - if we >>>>> think this is >>>>> something a human generates, remembers, and types in, well then it >>>>> is a >>>>> password and the above attacks are worth considering. Personally, I >>>>> think it >>>>> is going to be come configuration information generated by the >>>>> system and >>>>> downloaded to the client then used to connect to the relay. In this >>>>> form it >>>>> is far more of a cookie than a password and the above attacks are >>>>> far less >>>>> interesting because there will not be other systems that use the same >>>>> password. >>>>> >>>>> Cullen >>>>> >>>>> >>>>> >>>>> On 6/20/05 6:44 PM, "Rohan Mahy" wrote: >>>>> >>>>>> Hi Everyone, >>>>>> >>>>>> Despite the thread on the list from late March and early April about >>>>>> Basic vs Digest authentication, I don't feel like we came to >>>>>> consensus >>>>>> on this issue. First I would like to apologize for my lack of >>>>>> attention >>>>>> on this particular issue, and that it has remained open for so long. >>>>>> >>>>>> The arguments in favor of Digest authentication included a number of >>>>>> incorrect assumptions (marked "I") which need to be clarified in the >>>>>> draft. Among them: >>>>>> >>>>>> I: Relays for user B get to see the username and password for user A. >>>>>> A: This never happens. user A only sends AUTH requests to *its* >>>>>> relays, never to the relays used to forward requests on to another >>>>>> user. >>>>>> >>>>>> I: User B sends its password in the clear over the network. >>>>>> A: Use of TLS is mandatory, user B only sends its password inside a >>>>>> TLS-protected channel. >>>>>> >>>>>> I: The Security Area Directors will never allow this. >>>>>> A: Based on preliminary discussions, I believe this will be >>>>>> acceptable >>>>>> to the Security ADs. Again, use of TLS is mandatory. This is >>>>>> exactly >>>>>> like the common usage of SMTP using PLAIN user authentication over a >>>>>> TLS-protected channel, which is a very widely deployed model. >>>>>> >>>>>> I: If I use RADIUS I have to send the username and password in the >>>>>> clear >>>>>> A: The MSRP relay can hash the password before sending to the RADIUS >>>>>> server, or send all RADIUS traffic over a protected channel. >>>>>> >>>>>> There are two other concerns with Basic which are accurate: >>>>>> >>>>>> 1. If example.com has an inner relay and an outer relay, credentials >>>>>> for outer.example.com are revealed to inner.example.com as AUTH >>>>>> requests are forwarded to outer.example.com. This limitation is >>>>>> clearly explained in the Security Considerations section. >>>>>> >>>>>> 2. The other issue that Avshalom brought up is that the relay >>>>>> administrator has access to the password, or an attacker who can gain >>>>>> access to the relay machine. While the administrator could mount a >>>>>> dictionary attack on a Digest protected password, its obviously >>>>>> easier >>>>>> to get access to the password when it isn't hashed at all. >>>>>> >>>>>> When I originally tried to map the draft onto Digest, I was >>>>>> planning to >>>>>> do something like this: >>>>>> >>>>>> - realm is a string provided by the server. it SHOULD be the host >>>>>> name >>>>>> of the relay. >>>>>> - the domains parameter is ignored >>>>>> - note that the nonce algorithm based on ETags doesn't work >>>>>> - do not support auth-int, but always include the qop parameter with >>>>>> auth >>>>>> - the digest-uri parameter is the right-most URI in the To-Path >>>>>> header >>>>>> - the alg parameter is ??? >>>>>> - the cnonce and the nonce-count MUST be sent >>>>>> - the Method from A2 is always AUTH >>>>>> - there is never a body for AUTH so A2 is just AUTH: plus the >>>>>> Request-URI >>>>>> - I have no idea what to do about MD5 vs. MD5-sess. >>>>>> - I have no idea whether the nextnonce parameter is useful here. >>>>>> - I don't think the response authentication parameter is useful at >>>>>> all. >>>>>> However, the security considerations needs to describe what >>>>>> would or >>>>>> would not be protected here. Remember that we have no integrity over >>>>>> the Use-Path header from client to outermost relay even if we use >>>>>> this, >>>>>> unless we redefine the A2 to include the value of the Use-Path header >>>>>> instead of the entity-body. >>>>>> >>>>>> The arguments in favor of Basic authentication are: >>>>>> >>>>>> 1. Basic authentication is much simpler to implement than Digest, and >>>>>> the authors feel that with TLS protection of the channel that its >>>>>> security is good enough. We expect MSRP AUTH to be used within a >>>>>> single >>>>>> administrative domain, and the limitation of the server seeing the >>>>>> plain text password is similar to the way that many email services >>>>>> are >>>>>> deployed with TLS. >>>>>> >>>>>> 2. Digest authentication is not a great fit to MSRP and as a >>>>>> result its >>>>>> not obvious what to specify for all the parameters. >>>>>> >>>>>> >>>>>> What do we do? My proposal is to go with Basic. I have updated the >>>>>> draft leaving Basic in place. I feel this is appropriate given the >>>>>> relative security of the base draft, and given what would be >>>>>> needed to >>>>>> do Digest properly. If the consensus of the group is that we >>>>>> should do >>>>>> Digest instead, then I urge someone to propose specific text >>>>>> answering >>>>>> the questions I discuss above, that would go into the draft. >>>>>> >>>>>> thanks, >>>>>> -rohan >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>> _______________________________________________ >>> 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 Jun 27 15:50:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmzch-00079e-Gy; Mon, 27 Jun 2005 15:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmzcO-00074S-GR; Mon, 27 Jun 2005 15:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00222; Mon, 27 Jun 2005 15:50:06 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn01Z-0000gq-Cs; Mon, 27 Jun 2005 16:16:09 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DmzcI-0002c8-Ji; Mon, 27 Jun 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 27 Jun 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-future-04.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals Author(s) : H. Schulzrinne Filename : draft-ietf-simple-future-04.txt Pages : 14 Date : 2005-6-27 The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. This document extends PIDF, adding a timed status extension ( element) that allows a presentity to declare its status for a time interval fully in the future or the past. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-future-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-future-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-future-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-27150856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-future-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-future-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-27150856.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 Mon Jun 27 15:50:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmzcu-0007FS-9r; Mon, 27 Jun 2005 15:50:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmzcQ-000753-O2; Mon, 27 Jun 2005 15:50:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00243; Mon, 27 Jun 2005 15:50:07 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn01Y-0000gp-GG; Mon, 27 Jun 2005 16:16:08 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DmzcI-0002bj-IU; Mon, 27 Jun 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 27 Jun 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-rpid-07.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 : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-simple-rpid-07.txt Pages : 38 Date : 2005-6-27 The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. That format defines a textual note, an indication of availability (open or closed) and a Universal Resource Identifier (URI) for communication. The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status and the overall role of the presentity. These extensions include presence information for persons, services (tuples) and devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-07.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-rpid-07.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-rpid-07.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-6-27150824.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-rpid-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-rpid-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-27150824.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 Mon Jun 27 15:50:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmzcz-0007HU-WF; Mon, 27 Jun 2005 15:50:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmzcR-00075U-NR for simple@megatron.ietf.org; Mon, 27 Jun 2005 15:50:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00262 for ; Mon, 27 Jun 2005 15:50:09 -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 1Dn01c-0000gT-Pc for simple@ietf.org; Mon, 27 Jun 2005 16:16:13 -0400 Received: from [131.107.53.54] ([131.107.53.54]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j5RJntCo036462 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 27 Jun 2005 14:49:56 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <61b30d95f6c0697c53771f44b9970b25@ekabal.com> References: <770e9959d3c738d838e8e7dee219ad3d@ekabal.com> <59441C0C-B511-478A-89D6-35CC3006C9F8@nostrum.com> <61b30d95f6c0697c53771f44b9970b25@ekabal.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension Date: Mon, 27 Jun 2005 09:38:10 -0500 To: Rohan Mahy X-Mailer: Apple Mail (2.730) Received-SPF: pass (nostrum.com: 131.107.53.54 is authenticated by a trusted mechanism) X-Spam-Score: 0.7 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 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 On Jun 27, 2005, at 1:10 AM, Rohan Mahy wrote: > > On Jun 24, 2005, at 8:57, Ben Campbell wrote: > > >> I am sensitive to the fact basic is easier to implement, simpler >> to specify, etc. However, "accurate concern number" 1 feels like >> a show stopper. >> >> The particular use case I imagine is that I am roaming onto >> someone else's network (a Hotel, for example) that forces all MSRP >> traffic through its relay. I might have a high-security job where >> my credentials must not be revealed to _anyone_ outside of my >> organization. What do I do? >> > > If you have a high security job then you have no business relaying > your traffic through a hotel relay regardless of protocol. > Besides, you will probably use an IPsec VPN or (rarely) an SSH > tunnel. Encouraging random relays run by folks you don't trust is > just plain a bad idea. > If it were entirely my choice, I would never use an HTTP proxy or an outbound SMTP server other than my home one. But these are sometimes forced on me by the local network. I have visited more than one company that locks down everything that does not go through some relay that they control. If we make this choice, we are saying that under those conditions, I have a choice of either revealing my password, or not communicating. That does not seem very satisfying. (But see my next comment before spending too much time rebutting this one :-) ) > >> If we go with basic for now, does that in any way preclude doing a >> followup effort on how to use digest? >> > > no. In that case, I am willing to accept basic for now, in order to get this work done, as long as the issues are clearly spelled out in the security considerations. > > thanks, > -rohan > > >> On Jun 20, 2005, at 8:44 PM, Rohan Mahy wrote: >> >> >>> Hi Everyone, >>> >>> Despite the thread on the list from late March and early April >>> about Basic vs Digest authentication, I don't feel like we came >>> to consensus on this issue. First I would like to apologize for >>> my lack of attention on this particular issue, and that it has >>> remained open for so long. >>> >>> The arguments in favor of Digest authentication included a number >>> of incorrect assumptions (marked "I") which need to be clarified >>> in the draft. Among them: >>> >>> I: Relays for user B get to see the username and password for >>> user A. >>> A: This never happens. user A only sends AUTH requests to *its* >>> relays, never to the relays used to forward requests on to >>> another user. >>> >>> I: User B sends its password in the clear over the network. >>> A: Use of TLS is mandatory, user B only sends its password inside >>> a TLS-protected channel. >>> >>> I: The Security Area Directors will never allow this. >>> A: Based on preliminary discussions, I believe this will be >>> acceptable to the Security ADs. Again, use of TLS is mandatory. >>> This is exactly like the common usage of SMTP using PLAIN user >>> authentication over a TLS-protected channel, which is a very >>> widely deployed model. >>> >>> I: If I use RADIUS I have to send the username and password in >>> the clear >>> A: The MSRP relay can hash the password before sending to the >>> RADIUS server, or send all RADIUS traffic over a protected channel. >>> >>> There are two other concerns with Basic which are accurate: >>> >>> 1. If example.com has an inner relay and an outer relay, >>> credentials for outer.example.com are revealed to >>> inner.example.com as AUTH requests are forwarded to >>> outer.example.com. This limitation is clearly explained in the >>> Security Considerations section. >>> >>> 2. The other issue that Avshalom brought up is that the relay >>> administrator has access to the password, or an attacker who can >>> gain access to the relay machine. While the administrator could >>> mount a dictionary attack on a Digest protected password, its >>> obviously easier to get access to the password when it isn't >>> hashed at all. >>> >>> When I originally tried to map the draft onto Digest, I was >>> planning to do something like this: >>> >>> - realm is a string provided by the server. it SHOULD be the host >>> name of the relay. >>> - the domains parameter is ignored >>> - note that the nonce algorithm based on ETags doesn't work >>> - do not support auth-int, but always include the qop parameter >>> with auth >>> - the digest-uri parameter is the right-most URI in the To-Path >>> header >>> - the alg parameter is ??? >>> - the cnonce and the nonce-count MUST be sent >>> - the Method from A2 is always AUTH >>> - there is never a body for AUTH so A2 is just AUTH: plus the >>> Request-URI >>> - I have no idea what to do about MD5 vs. MD5-sess. >>> - I have no idea whether the nextnonce parameter is useful here. >>> - I don't think the response authentication parameter is useful >>> at all. However, the security considerations needs to describe >>> what would or would not be protected here. Remember that we have >>> no integrity over the Use-Path header from client to outermost >>> relay even if we use this, unless we redefine the A2 to include >>> the value of the Use-Path header instead of the entity-body. >>> >>> The arguments in favor of Basic authentication are: >>> >>> 1. Basic authentication is much simpler to implement than Digest, >>> and the authors feel that with TLS protection of the channel that >>> its security is good enough. We expect MSRP AUTH to be used >>> within a single administrative domain, and the limitation of the >>> server seeing the plain text password is similar to the way that >>> many email services are deployed with TLS. >>> >>> 2. Digest authentication is not a great fit to MSRP and as a >>> result its not obvious what to specify for all the parameters. >>> >>> >>> What do we do? My proposal is to go with Basic. I have updated >>> the draft leaving Basic in place. I feel this is appropriate >>> given the relative security of the base draft, and given what >>> would be needed to do Digest properly. If the consensus of the >>> group is that we should do Digest instead, then I urge someone to >>> propose specific text answering the questions I discuss above, >>> that would go into the draft. >>> >>> thanks, >>> -rohan >>> >>> >>> _______________________________________________ >>> 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 Jun 27 15:50:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmzd2-0007IO-Ek; Mon, 27 Jun 2005 15:50:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmzcR-00075K-Oa; Mon, 27 Jun 2005 15:50:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00245; Mon, 27 Jun 2005 15:50:08 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn01b-0000go-NS; Mon, 27 Jun 2005 16:16:11 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DmzcI-0002bB-HI; Mon, 27 Jun 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 27 Jun 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-cipid-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 : CIPID: Contact Information in Presence Information Data Format Author(s) : H. Schulzrinne Filename : draft-ietf-simple-cipid-05.txt Pages : 10 Date : 2005-6-27 The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for Presence Information Data Format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-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-cipid-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-cipid-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-6-27150752.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-cipid-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-cipid-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-27150752.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 Mon Jun 27 21:55:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn5K8-0008EH-MF; Mon, 27 Jun 2005 21:55:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn5K1-0008DY-Po for simple@megatron.ietf.org; Mon, 27 Jun 2005 21:55:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22373 for ; Mon, 27 Jun 2005 21:55:31 -0400 (EDT) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn5jH-0003xH-1S for simple@ietf.org; Mon, 27 Jun 2005 22:21:40 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 6EEEE194459 for ; Tue, 28 Jun 2005 03:55:14 +0200 (CEST) Received: from [10.0.0.1] ([82.194.52.5]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 03:59:02 +0200 In-Reply-To: <42C056D3.5080308@nokia.com> References: <0cccd4bbc210cb4dcfea49ed0234c0dc@telio.no> <42BEF0BB.6080405@nokia.com> <42C056D3.5080308@nokia.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: Hisham Khartabil Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension Date: Tue, 28 Jun 2005 03:55:08 +0200 To: Aki Niemi X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 28 Jun 2005 01:59:03.0318 (UTC) FILETIME=[F569D360:01C57B84] X-Spam-Score: 0.0 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Avshalom Houri , "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 On Jun 27, 2005, at 9:43 PM, Aki Niemi wrote: > > > ext Hisham Khartabil wrote: >>> >>> I'm fine with Basic. >> The question I'm trying to ask is: Are you fine with Digest also? (I >> think we can safely assume that Digest is just as good as Basic in >> this case :) ) If Digest does the job, and makes everyone happy, then >> we use it. What is the technical objection for using Digest? > > No, I'm not fine with digest. It isn't "just as good" considering that > it is harder to specify and implement. I think you're asking the > question the wrong way. Why is it harder to specify? and why is it harder to implement. You need to sell your arguments better. I'm not arguing for one or the other. I just want to make sure the the people with issues are satisfied with your answers. > >>> I agree it's easier to implement, interoperates better and works >>> fine when used in a TLS session authenticated with a server >>> certificate. >> I agree with those points also, but they do not address some of >> folk's concerns including storing passwords in the clear, etc. > > Like I said, that seems like a different problem, and an > implementation issue. It is not an implementation issue. If you use Basic, you store the password differently than using Digest. In any case, this was just an example of the concerns that people have. We need to make sure we address them all. (See Ben's post as another example). Hisham > > Cheers, > Aki > >> Hisham >>> >>> Digest would be an option if TLS was somehow deemed insufficient, or >>> too much of a burden. It is neither, since TLS+basic (or >>> username/password in an HTML form) has been proven to work in the >>> web, and as has been pointed out by various people in other threads, >>> server certificates are nowadays really dirt cheap. >>> >>> Cheers, >>> Aki >>> >>> [1] Referring to the recent credit card number theft, where I'm sure >>> most if not all numbers were sent via an SSL protected site. >>> >>>> Regards, >>>> Hisham >>>> On Jun 25, 2005, at 5:45 PM, Cullen Jennings wrote: >>>> >>>>> >>>>> Consider how a password works on a UNIX system, if you get access >>>>> to the >>>>> /etc/passwd file, you don't find out what my password is because >>>>> the >>>>> password is not stored but instead a hashed+salt version of it is. >>>>> This is >>>>> how people that implemented the Basic+TLS scheme would do it. >>>>> >>>>> Now consider how Apache stores the the HTTP digest credentials. It >>>>> stores >>>>> the H(A1) value which does not include the nonce. I might be wrong >>>>> on this >>>>> but I think that if the attacker new the H(A1), they could compute >>>>> the >>>>> response to logon to this particular realm even when a new nonce >>>>> was >>>>> presented. >>>>> >>>>> Cullen >>>>> >>>>> On 6/22/05 10:14 AM, "Avshalom Houri" wrote: >>>>> >>>>>> >>>>>> Cullen, >>>>>> >>>>>> Not sure I understand. >>>>>> >>>>>> In digest, the server will send a nonce to the user thus >>>>>> preventing replay >>>>>> attacks by replacing the nonce every time. >>>>>> The hashed value stored in the server can not be used for logging >>>>>> again to the >>>>>> server since the server will accept only nonced passwords. >>>>>> >>>>>> In basic authentication anyone that has an access to the server >>>>>> code may get >>>>>> the cleartext password and do with it whatever they want. >>>>>> >>>>>> Avshalom >>>>>> >>>>>> >>>>>> >>>>>> Cullen Jennings >>>>>> Sent by: simple-bounces@ietf.org 22/06/2005 06:58 PM >>>>>> To >>>>>> Rohan Mahy , "simple@ietf.org" >>>>>> cc >>>>>> Subject >>>>>> Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP >>>>>> relays >>>>>> extension >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I have not really provided much input on this issues - that is >>>>>> partially >>>>>> because I could go either way if we could just finish this. That >>>>>> said, let >>>>>> me outline a few points that I see as relevant to the decision.... >>>>>> >>>>>> The significant argument I have seen made an attack where >>>>>> someone broke >>>>>> into the relay server (or had access to it because they were the >>>>>> administrator) of it and thus gained access to all the stored >>>>>> passwords. We >>>>>> are worried about people using the information to log in as the a >>>>>> given user >>>>>> to this relay and also, assuming the users use the same password >>>>>> other >>>>>> places, to long on to other boxes. This is definitely an >>>>>> important attack to >>>>>> consider. >>>>>> >>>>>> If we go with the Digest route, any reasonable server will end up >>>>>> storing >>>>>> H(A1). It may do this directly or via a radius server. Now if >>>>>> someone gets >>>>>> H(A1), the can not discover my password and long on to some other >>>>>> server >>>>>> where I may have used the same password. However, they can use >>>>>> that to log >>>>>> on to this same relay server as me. The last sentence is >>>>>> important, using >>>>>> Digest, if the attacker gets my stored H(A1) then can log on as >>>>>> me to this >>>>>> box (but not others). >>>>>> >>>>>> Now consider the Basic+TLS approach, any reasonable >>>>>> implementation will >>>>>> store the usual hash of password plus salt solution. If an >>>>>> attacker gets >>>>>> this stored information, they can log on other boxes, but even >>>>>> more than >>>>>> this, they can not log onto this box using what they learned. >>>>>> >>>>>> Both solutions protect against the stored information being used >>>>>> to log on >>>>>> another box and the Digest+TLS also protects against it being >>>>>> used to log on >>>>>> the same relay. >>>>>> >>>>>> I'm not sure I view this as an amazing advantage for Basic+TLS - >>>>>> I view the >>>>>> real advantage of Basic+TLS be the simplicity it brings and that >>>>>> much of >>>>>> what Digest is designed to provide, MSRP has no use for. >>>>>> >>>>>> Next point has to do with this being a password at all - if we >>>>>> think this is >>>>>> something a human generates, remembers, and types in, well then >>>>>> it is a >>>>>> password and the above attacks are worth considering. Personally, >>>>>> I think it >>>>>> is going to be come configuration information generated by the >>>>>> system and >>>>>> downloaded to the client then used to connect to the relay. In >>>>>> this form it >>>>>> is far more of a cookie than a password and the above attacks are >>>>>> far less >>>>>> interesting because there will not be other systems that use the >>>>>> same >>>>>> password. >>>>>> >>>>>> Cullen >>>>>> >>>>>> >>>>>> >>>>>> On 6/20/05 6:44 PM, "Rohan Mahy" wrote: >>>>>> >>>>>>> Hi Everyone, >>>>>>> >>>>>>> Despite the thread on the list from late March and early April >>>>>>> about >>>>>>> Basic vs Digest authentication, I don't feel like we came to >>>>>>> consensus >>>>>>> on this issue. First I would like to apologize for my lack of >>>>>>> attention >>>>>>> on this particular issue, and that it has remained open for so >>>>>>> long. >>>>>>> >>>>>>> The arguments in favor of Digest authentication included a >>>>>>> number of >>>>>>> incorrect assumptions (marked "I") which need to be clarified in >>>>>>> the >>>>>>> draft. Among them: >>>>>>> >>>>>>> I: Relays for user B get to see the username and password for >>>>>>> user A. >>>>>>> A: This never happens. user A only sends AUTH requests to *its* >>>>>>> relays, never to the relays used to forward requests on to >>>>>>> another >>>>>>> user. >>>>>>> >>>>>>> I: User B sends its password in the clear over the network. >>>>>>> A: Use of TLS is mandatory, user B only sends its password >>>>>>> inside a >>>>>>> TLS-protected channel. >>>>>>> >>>>>>> I: The Security Area Directors will never allow this. >>>>>>> A: Based on preliminary discussions, I believe this will be >>>>>>> acceptable >>>>>>> to the Security ADs. Again, use of TLS is mandatory. This is >>>>>>> exactly >>>>>>> like the common usage of SMTP using PLAIN user authentication >>>>>>> over a >>>>>>> TLS-protected channel, which is a very widely deployed model. >>>>>>> >>>>>>> I: If I use RADIUS I have to send the username and password in >>>>>>> the clear >>>>>>> A: The MSRP relay can hash the password before sending to the >>>>>>> RADIUS >>>>>>> server, or send all RADIUS traffic over a protected channel. >>>>>>> >>>>>>> There are two other concerns with Basic which are accurate: >>>>>>> >>>>>>> 1. If example.com has an inner relay and an outer relay, >>>>>>> credentials >>>>>>> for outer.example.com are revealed to inner.example.com as AUTH >>>>>>> requests are forwarded to outer.example.com. This limitation is >>>>>>> clearly explained in the Security Considerations section. >>>>>>> >>>>>>> 2. The other issue that Avshalom brought up is that the relay >>>>>>> administrator has access to the password, or an attacker who can >>>>>>> gain >>>>>>> access to the relay machine. While the administrator could >>>>>>> mount a >>>>>>> dictionary attack on a Digest protected password, its obviously >>>>>>> easier >>>>>>> to get access to the password when it isn't hashed at all. >>>>>>> >>>>>>> When I originally tried to map the draft onto Digest, I was >>>>>>> planning to >>>>>>> do something like this: >>>>>>> >>>>>>> - realm is a string provided by the server. it SHOULD be the >>>>>>> host name >>>>>>> of the relay. >>>>>>> - the domains parameter is ignored >>>>>>> - note that the nonce algorithm based on ETags doesn't work >>>>>>> - do not support auth-int, but always include the qop parameter >>>>>>> with >>>>>>> auth >>>>>>> - the digest-uri parameter is the right-most URI in the To-Path >>>>>>> header >>>>>>> - the alg parameter is ??? >>>>>>> - the cnonce and the nonce-count MUST be sent >>>>>>> - the Method from A2 is always AUTH >>>>>>> - there is never a body for AUTH so A2 is just AUTH: plus the >>>>>>> Request-URI >>>>>>> - I have no idea what to do about MD5 vs. MD5-sess. >>>>>>> - I have no idea whether the nextnonce parameter is useful here. >>>>>>> - I don't think the response authentication parameter is useful >>>>>>> at all. >>>>>>> However, the security considerations needs to describe what >>>>>>> would or >>>>>>> would not be protected here. Remember that we have no integrity >>>>>>> over >>>>>>> the Use-Path header from client to outermost relay even if we >>>>>>> use this, >>>>>>> unless we redefine the A2 to include the value of the Use-Path >>>>>>> header >>>>>>> instead of the entity-body. >>>>>>> >>>>>>> The arguments in favor of Basic authentication are: >>>>>>> >>>>>>> 1. Basic authentication is much simpler to implement than >>>>>>> Digest, and >>>>>>> the authors feel that with TLS protection of the channel that its >>>>>>> security is good enough. We expect MSRP AUTH to be used within a >>>>>>> single >>>>>>> administrative domain, and the limitation of the server seeing >>>>>>> the >>>>>>> plain text password is similar to the way that many email >>>>>>> services are >>>>>>> deployed with TLS. >>>>>>> >>>>>>> 2. Digest authentication is not a great fit to MSRP and as a >>>>>>> result its >>>>>>> not obvious what to specify for all the parameters. >>>>>>> >>>>>>> >>>>>>> What do we do? My proposal is to go with Basic. I have updated >>>>>>> the >>>>>>> draft leaving Basic in place. I feel this is appropriate given >>>>>>> the >>>>>>> relative security of the base draft, and given what would be >>>>>>> needed to >>>>>>> do Digest properly. If the consensus of the group is that we >>>>>>> should do >>>>>>> Digest instead, then I urge someone to propose specific text >>>>>>> answering >>>>>>> the questions I discuss above, that would go into the draft. >>>>>>> >>>>>>> thanks, >>>>>>> -rohan >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Simple mailing list >>>>>>> Simple@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>> _______________________________________________ >>>> 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 Jun 27 21:58:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn5MW-0000mv-81; Mon, 27 Jun 2005 21:58:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn5MU-0000mq-Je for simple@megatron.ietf.org; Mon, 27 Jun 2005 21:58:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22538 for ; Mon, 27 Jun 2005 21:58:04 -0400 (EDT) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn5lk-0004Fr-Nn for simple@ietf.org; Mon, 27 Jun 2005 22:24:13 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 219CA194459 for ; Tue, 28 Jun 2005 03:57:57 +0200 (CEST) Received: from [10.0.0.1] ([82.194.52.5]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 04:01:47 +0200 In-Reply-To: References: <770e9959d3c738d838e8e7dee219ad3d@ekabal.com> <59441C0C-B511-478A-89D6-35CC3006C9F8@nostrum.com> <61b30d95f6c0697c53771f44b9970b25@ekabal.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4a71a5943840a6776a69316ccd169aef@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension Date: Tue, 28 Jun 2005 03:57:53 +0200 To: Ben Campbell X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 28 Jun 2005 02:01:48.0179 (UTC) FILETIME=[57AD9E30:01C57B85] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , "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 On Jun 27, 2005, at 4:38 PM, Ben Campbell wrote: > > On Jun 27, 2005, at 1:10 AM, Rohan Mahy wrote: > >> >> On Jun 24, 2005, at 8:57, Ben Campbell wrote: >> >> >>> I am sensitive to the fact basic is easier to implement, simpler to >>> specify, etc. However, "accurate concern number" 1 feels like a >>> show stopper. >>> >>> The particular use case I imagine is that I am roaming onto someone >>> else's network (a Hotel, for example) that forces all MSRP traffic >>> through its relay. I might have a high-security job where my >>> credentials must not be revealed to _anyone_ outside of my >>> organization. What do I do? >>> >> >> If you have a high security job then you have no business relaying >> your traffic through a hotel relay regardless of protocol. Besides, >> you will probably use an IPsec VPN or (rarely) an SSH tunnel. >> Encouraging random relays run by folks you don't trust is just plain >> a bad idea. >> > > If it were entirely my choice, I would never use an HTTP proxy or an > outbound SMTP server other than my home one. But these are sometimes > forced on me by the local network. I have visited more than one > company that locks down everything that does not go through some relay > that they control. If we make this choice, we are saying that under > those conditions, I have a choice of either revealing my password, or > not communicating. That does not seem very satisfying. > > (But see my next comment before spending too much time rebutting this > one :-) ) > >> >>> If we go with basic for now, does that in any way preclude doing a >>> followup effort on how to use digest? >>> >> >> no. > > In that case, I am willing to accept basic for now, in order to get > this work done, as long as the issues are clearly spelled out in the > security considerations. If we are aware of a problem and we are aware of the how to fix it, then why would we ignore such problem? Please convince me that specifying digest (which i think was already specified in an earlier version of the draft) will delay us further than this issue itself. Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 28 00:55:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn87i-0000pZ-P8; Tue, 28 Jun 2005 00:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn87g-0000oy-S3 for simple@megatron.ietf.org; Tue, 28 Jun 2005 00:55:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05553 for ; Tue, 28 Jun 2005 00:54:57 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn8Wx-0000Eq-R7 for simple@ietf.org; Tue, 28 Jun 2005 01:21:09 -0400 Received: from [10.59.1.4] (h-67-103-241-182.lsanca54.covad.net [67.103.241.182]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5S4stoO010077 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 28 Jun 2005 00:54:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <7349AA12-8EFA-4950-9823-3B5F9DE15003@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Simple WG From: Henning Schulzrinne Date: Tue, 28 Jun 2005 00:54:56 -0400 X-Mailer: Apple Mail (2.730) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Subject: [Simple] New versions of RPID, CIPID, timed-status 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 gone through the three "rich presence" drafts and cleaned up some inconsistencies and left-over text. Beyond some textual clean- up, there were no major changes, with some minor additions: - Added place-of-worship and stadium as locations; - Added documentation for something; - Added 'id' attributes to RPID elements to make referencing via XPath and similar operations easier (and supporting PIDF/RPID extensions that need to reference elements); - Added attribute extensibility to RPID (not yet done for CIPID; unclear that there's a need); - Dealt with the problems of timing in making time constraints in RPID less strict (the old ones were rather difficult to implement in practice); - Adjusted RPID IANA considerations to just have namespaces, without value registries (the latter were left over from the early days of tokens for activities and moods). There will likely be a WGLC for these documents soon, but there is no reason to wait with your comments until then... You can find HTML versions for easy reading at http://www.cs.columbia.edu/sip/draft/rpid/draft-ietf-simple-rpid-07.html http://www.cs.columbia.edu/sip/draft/cipid/draft-ietf-simple- cipid-05.html http://www.cs.columbia.edu/sip/draft/timed-status/draft-ietf-simple- future-04.html Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 28 02:37:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn9jK-0003z5-Ic; Tue, 28 Jun 2005 02:37:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn9jJ-0003z0-4h for simple@megatron.ietf.org; Tue, 28 Jun 2005 02:37:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03725 for ; Tue, 28 Jun 2005 02:37:55 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnA8b-0008Jr-3g for simple@ietf.org; Tue, 28 Jun 2005 03:04:05 -0400 Received: from [131.161.248.83] (open-131-161-248-83.cliq.com [131.161.248.83]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j5S6be116830; Mon, 27 Jun 2005 23:37:40 -0700 In-Reply-To: <4a71a5943840a6776a69316ccd169aef@telio.no> References: <770e9959d3c738d838e8e7dee219ad3d@ekabal.com> <59441C0C-B511-478A-89D6-35CC3006C9F8@nostrum.com> <61b30d95f6c0697c53771f44b9970b25@ekabal.com> <4a71a5943840a6776a69316ccd169aef@telio.no> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <764a769d860d02493cc15eb19e18577d@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension Date: Mon, 27 Jun 2005 23:37:32 -0700 To: Hisham Khartabil X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org WG" , Rohan Mahy 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 Jun 27, 2005, at 18:57, Hisham Khartabil wrote: > > On Jun 27, 2005, at 4:38 PM, Ben Campbell wrote: > >> >> On Jun 27, 2005, at 1:10 AM, Rohan Mahy wrote: >> >>> >>> On Jun 24, 2005, at 8:57, Ben Campbell wrote: >>> >>> >>>> I am sensitive to the fact basic is easier to implement, simpler to >>>> specify, etc. However, "accurate concern number" 1 feels like a >>>> show stopper. >>>> >>>> The particular use case I imagine is that I am roaming onto someone >>>> else's network (a Hotel, for example) that forces all MSRP traffic >>>> through its relay. I might have a high-security job where my >>>> credentials must not be revealed to _anyone_ outside of my >>>> organization. What do I do? >>>> >>> >>> If you have a high security job then you have no business relaying >>> your traffic through a hotel relay regardless of protocol. Besides, >>> you will probably use an IPsec VPN or (rarely) an SSH tunnel. >>> Encouraging random relays run by folks you don't trust is just plain >>> a bad idea. >>> >> >> If it were entirely my choice, I would never use an HTTP proxy or an >> outbound SMTP server other than my home one. But these are sometimes >> forced on me by the local network. I have visited more than one >> company that locks down everything that does not go through some >> relay that they control. If we make this choice, we are saying that >> under those conditions, I have a choice of either revealing my >> password, or not communicating. That does not seem very satisfying. >> >> (But see my next comment before spending too much time rebutting this >> one :-) ) >> >>> >>>> If we go with basic for now, does that in any way preclude doing a >>>> followup effort on how to use digest? >>>> >>> >>> no. >> >> In that case, I am willing to accept basic for now, in order to get >> this work done, as long as the issues are clearly spelled out in the >> security considerations. > > If we are aware of a problem and we are aware of the how to fix it, > then why would we ignore such problem? We rule problems out of scope all the time. Is MSRP useful in the situations where Basic is useful? Absolutely. This is an enormous proportion of the expected deployment scenarios. As for the specific problem in this thread, I am aware that sending my media through a relay with whom I have no actual trust relationship is a problem. A good way to fix that problem is to tell people very clearly in the draft not to do that. That's exactly what I have done. > Please convince me that specifying digest (which i think was already > specified in an earlier version of the draft) will delay us further > than this issue itself. Specifying Digest is essentially trying to make a mapping which does not fit very well. I feel that the ambiguity and underspecificity about how to do Digest for MSRP will take a long time to get right. thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 28 11:22:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnHuz-000769-A9; Tue, 28 Jun 2005 11:22:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnHuw-00075y-Lv for simple@megatron.ietf.org; Tue, 28 Jun 2005 11:22:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18974 for ; Tue, 28 Jun 2005 11:22:28 -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 1DnIKJ-0006dD-FA for simple@ietf.org; Tue, 28 Jun 2005 11:48:44 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 28 Jun 2005 08:22:20 -0700 X-IronPort-AV: i="3.93,239,1115017200"; d="scan'208"; a="283856176:sNHT43520116" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5SFMGvM016609; Tue, 28 Jun 2005 08:22:16 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 08:26:34 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 28 Jun 2005 07:35:11 -0700 Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension From: Cullen Jennings To: Rohan Mahy , Avshalom Houri Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Jun 2005 15:26:35.0922 (UTC) FILETIME=[C56A7720:01C57BF5] X-Spam-Score: 1.1 (+) X-Scan-Signature: 3dc828214e948ff35b815af10e94a823 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" , Aki Niemi 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 First two side notes 1) 100% agreement with Aki. 2) I'm not sure how much I care about any of this, I think it is Rohan not me who is trying to sell it. I'm mostly just trying to keep people straight on the facts as best I can make sense of them. On to my real comment .... Like all protocol things, we should make this as simple as possible but no simpler. TLS+Basic is simpler to understand and implement than TLS+Digest. It seems the question revolves around is this too simple. The argument that it is too simple revolves around the server seeing (not storing) the password. It is interesting to consider how this is done today. I note that for web applications, imap, pop and no doubt others, it seem that I personally deliver my password inside a TLS connection to a server fairly often. The other questions is what password is used. If this is really a password that the user sets and types in, then that is one thing since the user likely uses the same password on multiple systems. In every deployment I am considering this password is a machine generated string downloaded in a config file and is delivered back to more or less the same servers that generated it - in this sort of case I don't see any problem with the server seeing it. This is not the same as SIP because SIP works without TLS. This is something worth noting here. MSRP to the relays really truly requires you to use TLS. A secret or cookie is passed in the result of the AUTH. If this is not protected by TLS, attackers can do evil things. You really do have to do the AUTH inside a TLS connection. If it was possible to do AUTH without TLS, no one would be suggesting Basic. Anyway, I'm not married to any particular outcome of this discussion but I would like to see the choice made for good technical reasons. (and I would like to have it resolved). On 6/27/05 2:54 AM, "Hisham Khartabil" wrote: > > On Jun 26, 2005, at 8:15 PM, Aki Niemi wrote: > >> Inline. >> >> ext Hisham Khartabil wrote: >>> You're not selling the Basic Authentication solution very well. >>> Simplicity is not a good reason as far as I'm concerned. You could >>> argue your same arguments for SIP Basic authentication (that >>> Basic+TLS and hash+salt is enough), but we deprecated Basic still, >>> for a reason. Why doesnt that reason also apply to MRSP relays? >> >> Comparing SIP and MSRP may not be that wise here. The SIP model >> differs from the MSRP relay model significantly, since in SIP TLS is >> only hop-by-hop, and so even with transport security, an outbound >> proxy would have full access to the Basic password. >> >> Since in MSRP the client is supposed to have a TLS session up with the >> relay before any authentication is done, I don't see the problem. >> >> I would also like to separate protocol security from the discussion of >> how credentials are stored in the relay. IMHO, the latter can be >> screwed up in so many ways [1] we may just as well simply concentrate >> on the former. The latter is also an implementation issue. >> >>> People have concerns with Basic. Using Digest well not compromise the >>> security of the system, and will make everybody happy. Unless you >>> have real technical issues and concerns with using Digest, I believe >>> we need to go with it. >> >> I'm fine with Basic. > > The question I'm trying to ask is: Are you fine with Digest also? (I > think we can safely assume that Digest is just as good as Basic in this > case :) ) If Digest does the job, and makes everyone happy, then we use > it. What is the technical objection for using Digest? > >> I agree it's easier to implement, interoperates better and works fine >> when used in a TLS session authenticated with a server certificate. > > I agree with those points also, but they do not address some of folk's > concerns including storing passwords in the clear, etc. > > Hisham > >> >> Digest would be an option if TLS was somehow deemed insufficient, or >> too much of a burden. It is neither, since TLS+basic (or >> username/password in an HTML form) has been proven to work in the web, >> and as has been pointed out by various people in other threads, server >> certificates are nowadays really dirt cheap. >> >> Cheers, >> Aki >> >> [1] Referring to the recent credit card number theft, where I'm sure >> most if not all numbers were sent via an SSL protected site. >> >>> Regards, >>> Hisham >>> On Jun 25, 2005, at 5:45 PM, Cullen Jennings wrote: >>>> >>>> Consider how a password works on a UNIX system, if you get access to >>>> the >>>> /etc/passwd file, you don't find out what my password is because the >>>> password is not stored but instead a hashed+salt version of it is. >>>> This is >>>> how people that implemented the Basic+TLS scheme would do it. >>>> >>>> Now consider how Apache stores the the HTTP digest credentials. It >>>> stores >>>> the H(A1) value which does not include the nonce. I might be wrong >>>> on this >>>> but I think that if the attacker new the H(A1), they could compute >>>> the >>>> response to logon to this particular realm even when a new nonce was >>>> presented. >>>> >>>> Cullen >>>> >>>> On 6/22/05 10:14 AM, "Avshalom Houri" wrote: >>>> >>>>> >>>>> Cullen, >>>>> >>>>> Not sure I understand. >>>>> >>>>> In digest, the server will send a nonce to the user thus preventing >>>>> replay >>>>> attacks by replacing the nonce every time. >>>>> The hashed value stored in the server can not be used for logging >>>>> again to the >>>>> server since the server will accept only nonced passwords. >>>>> >>>>> In basic authentication anyone that has an access to the server >>>>> code may get >>>>> the cleartext password and do with it whatever they want. >>>>> >>>>> Avshalom >>>>> >>>>> >>>>> >>>>> Cullen Jennings >>>>> Sent by: simple-bounces@ietf.org 22/06/2005 06:58 PM >>>>> To >>>>> Rohan Mahy , "simple@ietf.org" >>>>> cc >>>>> Subject >>>>> Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP >>>>> relays >>>>> extension >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I have not really provided much input on this issues - that is >>>>> partially >>>>> because I could go either way if we could just finish this. That >>>>> said, let >>>>> me outline a few points that I see as relevant to the decision.... >>>>> >>>>> The significant argument I have seen made an attack where someone >>>>> broke >>>>> into the relay server (or had access to it because they were the >>>>> administrator) of it and thus gained access to all the stored >>>>> passwords. We >>>>> are worried about people using the information to log in as the a >>>>> given user >>>>> to this relay and also, assuming the users use the same password >>>>> other >>>>> places, to long on to other boxes. This is definitely an important >>>>> attack to >>>>> consider. >>>>> >>>>> If we go with the Digest route, any reasonable server will end up >>>>> storing >>>>> H(A1). It may do this directly or via a radius server. Now if >>>>> someone gets >>>>> H(A1), the can not discover my password and long on to some other >>>>> server >>>>> where I may have used the same password. However, they can use that >>>>> to log >>>>> on to this same relay server as me. The last sentence is important, >>>>> using >>>>> Digest, if the attacker gets my stored H(A1) then can log on as me >>>>> to this >>>>> box (but not others). >>>>> >>>>> Now consider the Basic+TLS approach, any reasonable implementation >>>>> will >>>>> store the usual hash of password plus salt solution. If an attacker >>>>> gets >>>>> this stored information, they can log on other boxes, but even more >>>>> than >>>>> this, they can not log onto this box using what they learned. >>>>> >>>>> Both solutions protect against the stored information being used to >>>>> log on >>>>> another box and the Digest+TLS also protects against it being used >>>>> to log on >>>>> the same relay. >>>>> >>>>> I'm not sure I view this as an amazing advantage for Basic+TLS - I >>>>> view the >>>>> real advantage of Basic+TLS be the simplicity it brings and that >>>>> much of >>>>> what Digest is designed to provide, MSRP has no use for. >>>>> >>>>> Next point has to do with this being a password at all - if we >>>>> think this is >>>>> something a human generates, remembers, and types in, well then it >>>>> is a >>>>> password and the above attacks are worth considering. Personally, I >>>>> think it >>>>> is going to be come configuration information generated by the >>>>> system and >>>>> downloaded to the client then used to connect to the relay. In this >>>>> form it >>>>> is far more of a cookie than a password and the above attacks are >>>>> far less >>>>> interesting because there will not be other systems that use the >>>>> same >>>>> password. >>>>> >>>>> Cullen >>>>> >>>>> >>>>> >>>>> On 6/20/05 6:44 PM, "Rohan Mahy" wrote: >>>>> >>>>>> Hi Everyone, >>>>>> >>>>>> Despite the thread on the list from late March and early April >>>>>> about >>>>>> Basic vs Digest authentication, I don't feel like we came to >>>>>> consensus >>>>>> on this issue. First I would like to apologize for my lack of >>>>>> attention >>>>>> on this particular issue, and that it has remained open for so >>>>>> long. >>>>>> >>>>>> The arguments in favor of Digest authentication included a number >>>>>> of >>>>>> incorrect assumptions (marked "I") which need to be clarified in >>>>>> the >>>>>> draft. Among them: >>>>>> >>>>>> I: Relays for user B get to see the username and password for user >>>>>> A. >>>>>> A: This never happens. user A only sends AUTH requests to *its* >>>>>> relays, never to the relays used to forward requests on to another >>>>>> user. >>>>>> >>>>>> I: User B sends its password in the clear over the network. >>>>>> A: Use of TLS is mandatory, user B only sends its password inside a >>>>>> TLS-protected channel. >>>>>> >>>>>> I: The Security Area Directors will never allow this. >>>>>> A: Based on preliminary discussions, I believe this will be >>>>>> acceptable >>>>>> to the Security ADs. Again, use of TLS is mandatory. This is >>>>>> exactly >>>>>> like the common usage of SMTP using PLAIN user authentication over >>>>>> a >>>>>> TLS-protected channel, which is a very widely deployed model. >>>>>> >>>>>> I: If I use RADIUS I have to send the username and password in the >>>>>> clear >>>>>> A: The MSRP relay can hash the password before sending to the >>>>>> RADIUS >>>>>> server, or send all RADIUS traffic over a protected channel. >>>>>> >>>>>> There are two other concerns with Basic which are accurate: >>>>>> >>>>>> 1. If example.com has an inner relay and an outer relay, >>>>>> credentials >>>>>> for outer.example.com are revealed to inner.example.com as AUTH >>>>>> requests are forwarded to outer.example.com. This limitation is >>>>>> clearly explained in the Security Considerations section. >>>>>> >>>>>> 2. The other issue that Avshalom brought up is that the relay >>>>>> administrator has access to the password, or an attacker who can >>>>>> gain >>>>>> access to the relay machine. While the administrator could mount a >>>>>> dictionary attack on a Digest protected password, its obviously >>>>>> easier >>>>>> to get access to the password when it isn't hashed at all. >>>>>> >>>>>> When I originally tried to map the draft onto Digest, I was >>>>>> planning to >>>>>> do something like this: >>>>>> >>>>>> - realm is a string provided by the server. it SHOULD be the host >>>>>> name >>>>>> of the relay. >>>>>> - the domains parameter is ignored >>>>>> - note that the nonce algorithm based on ETags doesn't work >>>>>> - do not support auth-int, but always include the qop parameter >>>>>> with >>>>>> auth >>>>>> - the digest-uri parameter is the right-most URI in the To-Path >>>>>> header >>>>>> - the alg parameter is ??? >>>>>> - the cnonce and the nonce-count MUST be sent >>>>>> - the Method from A2 is always AUTH >>>>>> - there is never a body for AUTH so A2 is just AUTH: plus the >>>>>> Request-URI >>>>>> - I have no idea what to do about MD5 vs. MD5-sess. >>>>>> - I have no idea whether the nextnonce parameter is useful here. >>>>>> - I don't think the response authentication parameter is useful at >>>>>> all. >>>>>> However, the security considerations needs to describe what >>>>>> would or >>>>>> would not be protected here. Remember that we have no integrity >>>>>> over >>>>>> the Use-Path header from client to outermost relay even if we use >>>>>> this, >>>>>> unless we redefine the A2 to include the value of the Use-Path >>>>>> header >>>>>> instead of the entity-body. >>>>>> >>>>>> The arguments in favor of Basic authentication are: >>>>>> >>>>>> 1. Basic authentication is much simpler to implement than Digest, >>>>>> and >>>>>> the authors feel that with TLS protection of the channel that its >>>>>> security is good enough. We expect MSRP AUTH to be used within a >>>>>> single >>>>>> administrative domain, and the limitation of the server seeing the >>>>>> plain text password is similar to the way that many email services >>>>>> are >>>>>> deployed with TLS. >>>>>> >>>>>> 2. Digest authentication is not a great fit to MSRP and as a >>>>>> result its >>>>>> not obvious what to specify for all the parameters. >>>>>> >>>>>> >>>>>> What do we do? My proposal is to go with Basic. I have updated >>>>>> the >>>>>> draft leaving Basic in place. I feel this is appropriate given the >>>>>> relative security of the base draft, and given what would be >>>>>> needed to >>>>>> do Digest properly. If the consensus of the group is that we >>>>>> should do >>>>>> Digest instead, then I urge someone to propose specific text >>>>>> answering >>>>>> the questions I discuss above, that would go into the draft. >>>>>> >>>>>> thanks, >>>>>> -rohan >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>> _______________________________________________ >>> 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 Jun 28 11:22:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnHvP-0007Cq-BQ; Tue, 28 Jun 2005 11:22:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnHvN-0007Ci-H4 for simple@megatron.ietf.org; Tue, 28 Jun 2005 11:22:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19163 for ; Tue, 28 Jun 2005 11:22:55 -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 1DnIKj-0006eq-Uo for simple@ietf.org; Tue, 28 Jun 2005 11:49:11 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 28 Jun 2005 08:22:22 -0700 X-IronPort-AV: i="3.93,239,1115017200"; d="scan'208"; a="646084700:sNHT3998124816" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5SFMIvM016645; Tue, 28 Jun 2005 08:22:18 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 08:26:37 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 28 Jun 2005 07:43:12 -0700 Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension From: Cullen Jennings To: Avshalom Houri , "simple@ietf.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Jun 2005 15:26:37.0922 (UTC) FILETIME=[C69BA420:01C57BF5] X-Spam-Score: 1.1 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Aki Niemi 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 6/27/05 7:17 AM, "Avshalom Houri" wrote: > In order to go ahead can we come with a way to enable a relay to offer basic > or digest or other method in its 401 response? This way servers can be > configured > to use different methods according to the required security level and clients > can > reject too weak method if they want. This will also enable clients that do not > have enough memory/CPU and that work in a protected environment to use only > basic > authentication. Few trivial notes ... I don't think there is a very good argument to be made that there are devices that are capable of TLS but can't do digest. (I know you are not making this argument but just tossing in this comment) Thought I can live with either basic/digest I would really prefer one over both. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 28 14:02:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnKPv-0007uc-4A; Tue, 28 Jun 2005 14:02:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnKPt-0007tg-GE for simple@megatron.ietf.org; Tue, 28 Jun 2005 14:02:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05991 for ; Tue, 28 Jun 2005 14:02:35 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnKpH-0003zz-1O for Simple@ietf.org; Tue, 28 Jun 2005 14:28:52 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 11:02:26 -0700 Received: from RED-MSG-41.redmond.corp.microsoft.com ([157.54.12.201]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 11:02:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 28 Jun 2005 11:02:25 -0700 Message-ID: Thread-Topic: Sip URI and case sensitivity question Thread-Index: AcV8CpU1qkHq3eHERWW1jcma7zV2VQAAOXMg From: "Adarsh Khare" To: X-OriginalArrivalTime: 28 Jun 2005 18:02:26.0049 (UTC) FILETIME=[8A869F10:01C57C0B] X-Spam-Score: 0.2 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Subject: [Simple] Sip URI and case sensitivity question 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="===============0246073147==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0246073147== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57C0B.8A2D132A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57C0B.8A2D132A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 =20 According to RFC 3261, section 19.1.4, userInfo part of Sip URI should be treated as case sensitive. Does anyone know the background behind it, what I am really wondering is why we have to treat the the user name part as case sensitive, where almost all application consider username as case insensitve. =20 Thanks adarsh =20 ------_=_NextPart_001_01C57C0B.8A2D132A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

 

According to RFC 3261, section 19.1.4, userInfo part = of Sip URI should be treated as case sensitive. Does anyone know the background = behind it, what I am really wondering is why we have to treat the the user name = part as case sensitive, where almost all application consider username as case insensitve.

 

Thanks

adarsh

 

------_=_NextPart_001_01C57C0B.8A2D132A-- --===============0246073147== 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 --===============0246073147==-- From simple-bounces@ietf.org Tue Jun 28 15:40:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnLwA-0005jX-LW; Tue, 28 Jun 2005 15:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnLw8-0005in-Rc for simple@megatron.ietf.org; Tue, 28 Jun 2005 15:40:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11338 for ; Tue, 28 Jun 2005 15:39:58 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnMFj-0001hs-Rn for simple@ietf.org; Tue, 28 Jun 2005 16:00:17 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 12:33:50 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 12:33:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRPrelays extension Date: Tue, 28 Jun 2005 12:33:54 -0700 Message-ID: Thread-Topic: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRPrelays extension Thread-Index: AcV79X3EOymOTOqrTmKGEDqiHcpgdgAHzmXA From: "Orit Levin" To: "Cullen Jennings" , "Avshalom Houri" , X-OriginalArrivalTime: 28 Jun 2005 19:33:49.0694 (UTC) FILETIME=[4F0871E0:01C57C18] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: Aki Niemi 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 strongly support Avshalom's request for including in the specification the ability to negotiate the security method to be used with a particular Relay. We can say that Basic is MUST to implement but we can not prescribe what level of security is going to be used in real deployments. If we want implementations from different vendors interoperate according to this standard - cutting the edges for "simplicity" will lead to opposite results. I don't think that this list is the right place to have a serious security debate but some facts are obvious: the credentials for Basic, being sent in clear inside the hop-by-hop TLS connections, may be different for different Relays and you don't want to expose them to anyone who has an access to the relays in the middle. (And I hope that IETF is not addressing monolithic systems only that will be OK with a single method and a single password.) Orit. > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: Tuesday, June 28, 2005 7:43 AM > To: Avshalom Houri; simple@ietf.org > Cc: Aki Niemi > Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest=20 > authentication in MSRPrelays extension >=20 > On 6/27/05 7:17 AM, "Avshalom Houri" wrote: >=20 > > In order to go ahead can we come with a way to enable a=20 > relay to offer=20 > > basic or digest or other method in its 401 response? This=20 > way servers=20 > > can be configured to use different methods according to the=20 > required=20 > > security level and clients can reject too weak method if they want.=20 > > This will also enable clients that do not have enough=20 > memory/CPU and=20 > > that work in a protected environment to use only basic=20 > authentication. >=20 > Few trivial notes ... >=20 > I don't think there is a very good argument to be made that=20 > there are devices that are capable of TLS but can't do=20 > digest. (I know you are not making this argument but just=20 > tossing in this comment) >=20 > Thought I can live with either basic/digest I would really=20 > prefer one over both. >=20 >=20 >=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 Jun 28 17:29:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnNdx-0001FL-Gi; Tue, 28 Jun 2005 17:29:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnNdv-0001EF-Bk for simple@megatron.ietf.org; Tue, 28 Jun 2005 17:29:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28363 for ; Tue, 28 Jun 2005 17:29:16 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnO3L-00031W-LF for simple@ietf.org; Tue, 28 Jun 2005 17:55:36 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id j5SLS6HP023915; Tue, 28 Jun 2005 21:28:06 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 17:28:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Date: Tue, 28 Jun 2005 17:28:05 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD59701502F7A@stntexch03.cis.neustar.com> Thread-Topic: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Thread-Index: AcV79X3EOymOTOqrTmKGEDqiHcpgdgAHzmXAAARI7hA= From: "Peterson, Jon" To: "Orit Levin" , "Cullen Jennings" , "Avshalom Houri" , X-OriginalArrivalTime: 28 Jun 2005 21:28:06.0140 (UTC) FILETIME=[45CB13C0:01C57C28] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Cc: Aki Niemi 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 This is the crux of the matter. Are we admitting use cases in which = there are intermediary relays that would have the opportunity to inspect = Basic credentials? If so, then Basic over hop-by-hop TLS is not = sufficient. The motivation for these uses cases remains a bit murky to me, to be = honest. I understand the argument that one might have a visited-network = relay and a policy-enforcing relay in one's home network. At a high = level, though, I tend to agree with Rohan that if you are unable to make = a direct connection to a policy-enforcing relay, then the very policies = that might be enforced by such a relay could be compromised by sending = traffic through a visited-network relay. The odds that most sorts of = visited networks are going to block VPNs, or indeed care about MSRP at = all, seem quite slim to me. The sorts of visited networks that do care = are likely to be unsympathetic to the policy needs of your home network. That much said, I am ultimately not persuaded that it is so problematic = to create a Digest system for MSRP. Doing so would certainly invite = additional scrutiny from the Security Area, but that scrutiny is likely = to be constructive. If people want to admit cases where there are = intermediary relays, then I think it is unwise not to address this = scenario in the protocol design. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of Orit Levin > Sent: Tuesday, June 28, 2005 12:34 PM > To: Cullen Jennings; Avshalom Houri; simple@ietf.org > Cc: Aki Niemi > Subject: RE: [Simple] OPEN ISSUE: Basic vs. Digest authentication > inMSRPrelays extension >=20 >=20 > I strongly support Avshalom's request for including in the=20 > specification > the ability to negotiate the security method to be used with a > particular Relay. >=20 > We can say that Basic is MUST to implement but we can not=20 > prescribe what > level of security is going to be used in real deployments. If we want > implementations from different vendors interoperate according to this > standard - cutting the edges for "simplicity" will lead to opposite > results. >=20 > I don't think that this list is the right place to have a serious > security debate but some facts are obvious: the credentials for Basic, > being sent in clear inside the hop-by-hop TLS connections, may be > different for different Relays and you don't want to expose them to > anyone who has an access to the relays in the middle. (And I hope that > IETF is not addressing monolithic systems only that will be OK with a > single method and a single password.) >=20 > Orit. >=20 > > -----Original Message----- > > From: simple-bounces@ietf.org=20 > > [mailto:simple-bounces@ietf.org] On Behalf Of Cullen Jennings > > Sent: Tuesday, June 28, 2005 7:43 AM > > To: Avshalom Houri; simple@ietf.org > > Cc: Aki Niemi > > Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest=20 > > authentication in MSRPrelays extension > >=20 > > On 6/27/05 7:17 AM, "Avshalom Houri" wrote: > >=20 > > > In order to go ahead can we come with a way to enable a=20 > > relay to offer=20 > > > basic or digest or other method in its 401 response? This=20 > > way servers=20 > > > can be configured to use different methods according to the=20 > > required=20 > > > security level and clients can reject too weak method if=20 > they want.=20 > > > This will also enable clients that do not have enough=20 > > memory/CPU and=20 > > > that work in a protected environment to use only basic=20 > > authentication. > >=20 > > Few trivial notes ... > >=20 > > I don't think there is a very good argument to be made that=20 > > there are devices that are capable of TLS but can't do=20 > > digest. (I know you are not making this argument but just=20 > > tossing in this comment) > >=20 > > Thought I can live with either basic/digest I would really=20 > > prefer one over both. > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 29 12:32:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnfU7-0004C8-8V; Wed, 29 Jun 2005 12:32:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnfU5-0004Bx-Tj for simple@megatron.ietf.org; Wed, 29 Jun 2005 12:32:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08284 for ; Wed, 29 Jun 2005 12:32:19 -0400 (EDT) Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnfte-0004az-VM for simple@ietf.org; Wed, 29 Jun 2005 12:58:48 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 1F64E42BD2E for ; Wed, 29 Jun 2005 10:31:43 -0600 (MDT) Message-ID: <42C2CCEE.7050704@jabber.org> Date: Wed, 29 Jun 2005 10:31:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org References: <20050629160628.68D1121A2F1@atlas.jabber.org> In-Reply-To: <20050629160628.68D1121A2F1@atlas.jabber.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: [Simple] Re: Sip URI and case sensitivity question 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="===============0013967470==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0013967470== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000803070205050404000501" This is a cryptographically signed message in MIME format. --------------ms000803070205050404000501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Adarsh Khare wrote: >According to RFC 3261, section 19.1.4, userInfo part of Sip URI should >be treated as case sensitive. Does anyone know the background behind it, >what I am really wondering is why we have to treat the the user name >part as case sensitive, where almost all application consider username >as case insensitve. > > The term "case sensitive" is rather old-fashioned in these days of stringprep (RFC 3454), since it applies only to the US-ASCII range. Is anyone working on fully-internationalized addresses for SIP? Peter --------------ms000803070205050404000501 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ8jCC BPUwggLdoAMCAQICAwEjfTANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTA1 MTcxNzQ2MDBaFw0wNjA1MTcxNzQ2MDBaMEIxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC6QaezyuQyuya0zB98ew+fDDeO6dbkFE1Td2OrePzTOuSMNHH1 kvpAxpC7m9WtSeeQ874XC9qmPxBurEILQYZrA/IJNUR+kWvJzAJLJK/62xOCOuDuNjLXKv5F BJEeg/uDpiq6K7yfsLcwg5wkxmIGsajYR+maGDlqV7aJeMuTcRTeNHNIBliwToPlIRvQfJbP B3D4tCInHxWeg5BmyqXZgpEPdJ1hyoHB+YvA/0YKAb1Fq9Fq2n6ZC0O70ndkx++OXw65kkYi m6N/dHQ9xjtpOOk6cQu+SKoL2BfU8kBp9bSmIUymn+KqUdwTcge4vFieJ1lWmtMsKUTbLbgh 0P9ZAgMBAAGjgbwwgbkwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlv dXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNB Y2VydC5vcmcwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNl cnQub3JnMB0GA1UdEQQWMBSBEnN0cGV0ZXJAamFiYmVyLm9yZzANBgkqhkiG9w0BAQQFAAOC AgEAk+5v9P2B9Zher5QMtmGRSqg+Dkmd2xMoBjPItsR2FFS6waXf3Hv82n4W//9HzM+zAuKv a0kzHY9IHCqcpRVBAqKpN6a6VHb6ZmtwKtj38wmLwMUIqnfvEx4AvP8QJHERLRVn8JL801QT 8Nt1y/6LaOKkFiQUZGvP5m6plXHx2DqL2gfAtZ/VSivSTzkJp3XyDnL04TdKFMY6vPvoT1Ub d48KW+ZA1NE1+h6gxr4jQVUExKeKB25RoxZMXyMqbawnzJZYl2fEkYgQVWVpPZO6NC9u45u4 kyOXNaLjiQwLpCvZj6x87YOQKn1YyiIWXSUFU4ArsaR/BvtVb53IKYE2LE8dPqq/fn1iMCb4 qLesxc+SQWAQB/xiDlVA00eJq+Ulyq4KTFnbARWHgXOqLUo9Uu+GsiK8L6WLf4vr2F8dhDwa tfw7oGjGmGJd0ZO/Yt3Wp7ytutsM+4I3ewlQyRWsXx6zcSHN43FUFZpCJxrfD1k1t9z/MJy/ d2zx7mjjbjcfTykIi8taC2UwdMBAbpNmH4gh+VnrEPgYHOONwBTqL/dfW0Px5pa0Fv/WU/VQ gYep9RLmdDYcwR2bn9XLdVDngMHHTr3Z9LNl1VfQnZg2wi2wvfIrrE0gOtJD7dMPl64Un2Tv L0bvyJrhkiKKdFACad+aOcw1pyWIiDixoYZPJi8wggT1MIIC3aADAgECAgMBI30wDQYJKoZI hvcNAQEEBQAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNl cnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcNMDUwNTE3MTc0NjAwWhcNMDYwNTE3MTc0NjAw WjBCMR0wGwYDVQQDExRKLiBQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3Rw ZXRlckBqYWJiZXIub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAukGns8rk MrsmtMwffHsPnww3junW5BRNU3djq3j80zrkjDRx9ZL6QMaQu5vVrUnnkPO+Fwvapj8QbqxC C0GGawPyCTVEfpFrycwCSySv+tsTgjrg7jYy1yr+RQSRHoP7g6Yquiu8n7C3MIOcJMZiBrGo 2Efpmhg5ale2iXjLk3EU3jRzSAZYsE6D5SEb0HyWzwdw+LQiJx8VnoOQZsql2YKRD3SdYcqB wfmLwP9GCgG9RavRatp+mQtDu9J3ZMfvjl8OuZJGIpujf3R0PcY7aTjpOnELvkiqC9gX1PJA afW0piFMpp/iqlHcE3IHuLxYnidZVprTLClE2y24IdD/WQIDAQABo4G8MIG5MAwGA1UdEwEB /wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3Ig RlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYw JDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzAdBgNVHREEFjAUgRJzdHBl dGVyQGphYmJlci5vcmcwDQYJKoZIhvcNAQEEBQADggIBAJPub/T9gfWYXq+UDLZhkUqoPg5J ndsTKAYzyLbEdhRUusGl39x7/Np+Fv//R8zPswLir2tJMx2PSBwqnKUVQQKiqTemulR2+mZr cCrY9/MJi8DFCKp37xMeALz/ECRxES0VZ/CS/NNUE/Dbdcv+i2jipBYkFGRrz+ZuqZVx8dg6 i9oHwLWf1Uor0k85Cad18g5y9OE3ShTGOrz76E9VG3ePClvmQNTRNfoeoMa+I0FVBMSnigdu UaMWTF8jKm2sJ8yWWJdnxJGIEFVlaT2TujQvbuObuJMjlzWi44kMC6Qr2Y+sfO2DkCp9WMoi Fl0lBVOAK7Gkfwb7VW+dyCmBNixPHT6qv359YjAm+Ki3rMXPkkFgEAf8Yg5VQNNHiavlJcqu CkxZ2wEVh4Fzqi1KPVLvhrIivC+li3+L69hfHYQ8GrX8O6BoxphiXdGTv2Ld1qe8rbrbDPuC N3sJUMkVrF8es3EhzeNxVBWaQica3w9ZNbfc/zCcv3ds8e5o4243H08pCIvLWgtlMHTAQG6T Zh+IIflZ6xD4GBzjjcAU6i/3X1tD8eaWtBb/1lP1UIGHqfUS5nQ2HMEdm5/Vy3VQ54DBx069 2fSzZdVX0J2YNsItsL3yK6xNIDrSQ+3TD5euFJ9k7y9G78ia4ZIiinRQAmnfmjnMNacliIg4 saGGTyYvMYIDhzCCA4MCAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0 cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5 MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwEjfTAJBgUrDgMCGgUAoIIB 2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA2MjkxNjMx NDJaMCMGCSqGSIb3DQEJBDEWBBRJvjYtMGnuux6sSmKirpmFY6wVOjBSBgkqhkiG9w0BCQ8x RTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3Qg Q0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBT aWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMB I30wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMBI30wDQYJKoZIhvcN AQEBBQAEggEApnFZtpvW2OeYHfamZM+YwIcJ94gETzpfBMBpurSNUeL4+fiO6KrAPcUbjnwT fXK0tcpGcXN27ye4wS3+X9e6nU3UxeCxXiPOC/WE/FhqWBROFvp3yAtsuKmb9CiPHhoYKaPt O94bsWJCuCc92CtriE/XYxsmXHqrtsWFZj25HvHlx3M2SP4+OFl/tAT6twAlBPPtmyy9ypk8 wzEPR6j+K/bTqE1fWqPoGLdcgcy7XnoPxyEf7JNDhRmllYYQOhiHbkDjlb+/6nOlPq68Hkl4 NtFcYLkASIPMH0hAH7HYHSni6+JQ6ueV4M96OuLHIv/eufvfYf+E8LuNFd3Nj+H28QAAAAAA AA== --------------ms000803070205050404000501-- --===============0013967470== 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 --===============0013967470==-- From simple-bounces@ietf.org Wed Jun 29 18:34:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnl8B-0004QR-De; Wed, 29 Jun 2005 18:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnl89-0004QH-DD for simple@megatron.ietf.org; Wed, 29 Jun 2005 18:34:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05464 for ; Wed, 29 Jun 2005 18:34:02 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnlXn-0006Hz-1o for simple@ietf.org; Wed, 29 Jun 2005 19:00:35 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Jun 2005 15:33:55 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Jun 2005 15:33:54 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Date: Wed, 29 Jun 2005 15:33:52 -0700 Message-ID: Thread-Topic: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Thread-Index: AcV79X3EOymOTOqrTmKGEDqiHcpgdgAHzmXAAARI7hAAM3qaIA== From: "Orit Levin" To: "Peterson, Jon" , "Cullen Jennings" , "Avshalom Houri" , X-OriginalArrivalTime: 29 Jun 2005 22:33:54.0864 (UTC) FILETIME=[A1D44B00:01C57CFA] X-Spam-Score: 0.8 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: quoted-printable Cc: Aki Niemi 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 It seems to me that our disconnect is around what the purposeS for a Relay to authenticate a certain client ARE. My point is that typically we will need to use BOTH Basic and Digest (and may be others to come) even for the same user for the same MSRP connection: first just for the proper MSRP forwarding (as the lightest means for issuing a token) and second for actually accessing a home network or other valid services network.=20 More inline, Orit. > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 > Sent: Tuesday, June 28, 2005 2:28 PM > To: Orit Levin; Cullen Jennings; Avshalom Houri; simple@ietf.org > Cc: Aki Niemi > Subject: RE: [Simple] OPEN ISSUE: Basic vs. Digest=20 > authentication inMSRPrelays extension >=20 >=20 > This is the crux of the matter. Are we admitting use cases in=20 > which there are intermediary relays that would have the=20 > opportunity to inspect Basic credentials? If so, then Basic=20 > over hop-by-hop TLS is not sufficient. > It is OK for an intermediary MSRP relay to inspect the Basic credentials because: 1. According to the spec every MSRP relay needs to use the "token" mechanism and thus, by definition, it has the lowest transitive level of trust required for secure MSRP forwarding 2. A network protocol specification can not prohibit network entities from implementing internal tracing features (even if available to administrators only :-) BUT it is OK as long as some MSRP Relays (typically the home Relays) have standard means of establishing a stronger level of trust with some clients that they choose to. It is better to be described as "allowing additional (e.g. home) services" rather than enforcing "policies". Obviously, the credentials for this level of trust must not be visible to intermediates (even if trusted for plain MSRP forwarding). =20 > The motivation for these uses cases remains a bit murky to=20 > me, to be honest. I understand the argument that one might=20 > have a visited-network relay and a policy-enforcing relay in=20 > one's home network. At a high level, though, I tend to agree=20 > with Rohan that if you are unable to make a direct connection=20 > to a policy-enforcing relay, then the very policies that=20 > might be enforced by such a relay could be compromised by=20 > sending traffic through a visited-network relay. The odds=20 > that most sorts of visited networks are going to block VPNs,=20 > or indeed care about MSRP at all, seem quite slim to me. The=20 > sorts of visited networks that do care are likely to be=20 > unsympathetic to the policy needs of your home network. >=20 > That much said, I am ultimately not persuaded that it is so=20 > problematic to create a Digest system for MSRP. Doing so=20 > would certainly invite additional scrutiny from the Security=20 > Area, but that scrutiny is likely to be constructive. If=20 > people want to admit cases where there are intermediary=20 > relays, then I think it is unwise not to address this=20 > scenario in the protocol design. >=20 > Jon Peterson > NeuStar, Inc. >=20 > > -----Original Message----- > > From: simple-bounces@ietf.org > > [mailto:simple-bounces@ietf.org]On Behalf Of Orit Levin > > Sent: Tuesday, June 28, 2005 12:34 PM > > To: Cullen Jennings; Avshalom Houri; simple@ietf.org > > Cc: Aki Niemi > > Subject: RE: [Simple] OPEN ISSUE: Basic vs. Digest authentication=20 > > inMSRPrelays extension > >=20 > >=20 > > I strongly support Avshalom's request for including in the=20 > > specification the ability to negotiate the security method=20 > to be used=20 > > with a particular Relay. > >=20 > > We can say that Basic is MUST to implement but we can not prescribe=20 > > what level of security is going to be used in real=20 > deployments. If we=20 > > want implementations from different vendors interoperate=20 > according to=20 > > this standard - cutting the edges for "simplicity" will lead to=20 > > opposite results. > >=20 > > I don't think that this list is the right place to have a serious=20 > > security debate but some facts are obvious: the credentials=20 > for Basic,=20 > > being sent in clear inside the hop-by-hop TLS connections, may be=20 > > different for different Relays and you don't want to expose them to=20 > > anyone who has an access to the relays in the middle. (And=20 > I hope that=20 > > IETF is not addressing monolithic systems only that will be=20 > OK with a=20 > > single method and a single password.) > >=20 > > Orit. > >=20 > > > -----Original Message----- > > > From: simple-bounces@ietf.org > > > [mailto:simple-bounces@ietf.org] On Behalf Of Cullen Jennings > > > Sent: Tuesday, June 28, 2005 7:43 AM > > > To: Avshalom Houri; simple@ietf.org > > > Cc: Aki Niemi > > > Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest=20 > authentication in=20 > > > MSRPrelays extension > > >=20 > > > On 6/27/05 7:17 AM, "Avshalom Houri" wrote: > > >=20 > > > > In order to go ahead can we come with a way to enable a > > > relay to offer > > > > basic or digest or other method in its 401 response? This > > > way servers > > > > can be configured to use different methods according to the > > > required > > > > security level and clients can reject too weak method if > > they want.=20 > > > > This will also enable clients that do not have enough > > > memory/CPU and > > > > that work in a protected environment to use only basic > > > authentication. > > >=20 > > > Few trivial notes ... > > >=20 > > > I don't think there is a very good argument to be made that there=20 > > > are devices that are capable of TLS but can't do digest.=20 > (I know you=20 > > > are not making this argument but just tossing in this comment) > > >=20 > > > Thought I can live with either basic/digest I would really prefer=20 > > > one over both. > > >=20 > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > 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 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 30 10:06:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnzgw-0006ga-UO; Thu, 30 Jun 2005 10:06:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnzgv-0006dZ-8b for simple@megatron.ietf.org; Thu, 30 Jun 2005 10:06:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14731 for ; Thu, 30 Jun 2005 10:06:55 -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 1Do06g-0004un-9u for simple@ietf.org; Thu, 30 Jun 2005 10:33:35 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 30 Jun 2005 07:06:47 -0700 X-IronPort-AV: i="3.93,245,1115017200"; d="scan'208"; a="646521225:sNHT27270528" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5UE6gvO013236; Thu, 30 Jun 2005 07:06:43 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Jun 2005 07:11:02 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 29 Jun 2005 11:35:16 -0700 Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension From: Cullen Jennings To: Hisham Khartabil Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Jun 2005 14:11:02.0515 (UTC) FILETIME=[8C1EF430:01C57D7D] X-Spam-Score: 1.5 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Avshalom Houri , "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 On 6/27/05 6:55 PM, "Hisham Khartabil" wrote: > Why is it harder to specify? As Rohan's original email said - there are some questions on how to map MSRP into HTTP digest - sending some text on that would be good if we are going to do this. Or if we are going to create a new Digest like scheme, send text on that. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 30 10:54:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do0Qr-0007eS-8K; Thu, 30 Jun 2005 10:54:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do0Qq-0007eN-Lf for simple@megatron.ietf.org; Thu, 30 Jun 2005 10:54:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20660 for ; Thu, 30 Jun 2005 10:54:22 -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 1Do0qc-0006NS-0E for simple@ietf.org; Thu, 30 Jun 2005 11:21:03 -0400 Received: from [192.168.1.115] (dsl001-129-066.dfw1.dsl.speakeasy.net [72.1.129.66]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j5UErgtF026723 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 30 Jun 2005 09:53:43 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <7349AA12-8EFA-4950-9823-3B5F9DE15003@cs.columbia.edu> References: <7349AA12-8EFA-4950-9823-3B5F9DE15003@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <883de42067a822f68430258a205fad9c@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Thu, 30 Jun 2005 09:54:37 -0500 To: Simple WG X-Mailer: Apple Mail (2.622) Received-SPF: pass (nostrum.com: 72.1.129.66 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: Henning Schulzrinne Subject: [Simple] WGLC: RPID, CIPID, timed-status (6/30-7/13) 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 These drafts were also recently revised (the iteration before this) so that their schemas align with the extensibility mechanisms agreed to since our most recent visit to Minneapolis. These drafts have been through last calls before, but please look through them carefully again. Last call on these drafts ends 7/13. This gives Henning a few days to integrate any necessary before the -01 deadline. Earlier comments are better than late. Thanks! RjS On Jun 27, 2005, at 11:54 PM, Henning Schulzrinne wrote: > I've gone through the three "rich presence" drafts and cleaned up some > inconsistencies and left-over text. Beyond some textual clean-up, > there were no major changes, with some minor additions: > > - Added place-of-worship and stadium as locations; > > - Added documentation for something; > > - Added 'id' attributes to RPID elements to make referencing via XPath > and similar operations easier (and supporting PIDF/RPID extensions > that need to reference elements); > > - Added attribute extensibility to RPID (not yet done for CIPID; > unclear that there's a need); > > - Dealt with the problems of timing in making time constraints in RPID > less strict (the old ones were rather difficult to implement in > practice); > > - Adjusted RPID IANA considerations to just have namespaces, without > value registries (the latter were left over from the early days of > tokens for activities and moods). > > There will likely be a WGLC for these documents soon, but there is no > reason to wait with your comments until then... > > You can find HTML versions for easy reading at > > http://www.cs.columbia.edu/sip/draft/rpid/draft-ietf-simple-rpid > -07.html > http://www.cs.columbia.edu/sip/draft/cipid/draft-ietf-simple-cipid > -05.html > http://www.cs.columbia.edu/sip/draft/timed-status/draft-ietf-simple- > future-04.html > > Henning > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 30 10:57:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do0Tm-0000Pm-Kb; Thu, 30 Jun 2005 10:57:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do0Tl-0000Ph-1a for simple@megatron.ietf.org; Thu, 30 Jun 2005 10:57:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20903 for ; Thu, 30 Jun 2005 10:57:22 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do0tX-0006hO-5k for simple@ietf.org; Thu, 30 Jun 2005 11:24:03 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 30 Jun 2005 07:57:15 -0700 X-IronPort-AV: i="3.93,246,1115017200"; d="scan'208"; a="195585649:sNHT28154088" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j5UEvB6r005057; Thu, 30 Jun 2005 07:57:13 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Jun 2005 08:01:30 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 30 Jun 2005 07:10:28 -0700 Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension From: Cullen Jennings To: Orit Levin , "simple@ietf.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Jun 2005 15:01:30.0722 (UTC) FILETIME=[9912AC20:01C57D84] X-Spam-Score: 1.9 (+) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit 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 can see the argument for basic does everything we need and is the simplest. I can see the argument for no basic is lacking and we need digest. But I'm not yet understanding why we would want both. On 6/29/05 3:33 PM, "Orit Levin" wrote: > It seems to me that our disconnect is around what the purposeS for a > Relay to authenticate a certain client ARE. > > My point is that typically we will need to use BOTH Basic and Digest > (and may be others to come) even for the same user for the same MSRP > connection: first just for the proper MSRP forwarding (as the lightest > means for issuing a token) and second for actually accessing a home > network or other valid services network. > > More inline, > Orit. > >> -----Original Message----- >> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >> Sent: Tuesday, June 28, 2005 2:28 PM >> To: Orit Levin; Cullen Jennings; Avshalom Houri; simple@ietf.org >> Cc: Aki Niemi >> Subject: RE: [Simple] OPEN ISSUE: Basic vs. Digest >> authentication inMSRPrelays extension >> >> >> This is the crux of the matter. Are we admitting use cases in >> which there are intermediary relays that would have the >> opportunity to inspect Basic credentials? If so, then Basic >> over hop-by-hop TLS is not sufficient. >> > > It is OK for an intermediary MSRP relay to inspect the Basic credentials > because: > 1. According to the spec every MSRP relay needs to use the "token" > mechanism and thus, by definition, it has the lowest transitive level of > trust required for secure MSRP forwarding > 2. A network protocol specification can not prohibit network entities > from implementing internal tracing features (even if available to > administrators only :-) > > BUT it is OK as long as some MSRP Relays (typically the home Relays) > have standard means of establishing a stronger level of trust with some > clients that they choose to. It is better to be described as "allowing > additional (e.g. home) services" rather than enforcing "policies". > Obviously, the credentials for this level of trust must not be visible > to intermediates (even if trusted for plain MSRP forwarding). > >> The motivation for these uses cases remains a bit murky to >> me, to be honest. I understand the argument that one might >> have a visited-network relay and a policy-enforcing relay in >> one's home network. At a high level, though, I tend to agree >> with Rohan that if you are unable to make a direct connection >> to a policy-enforcing relay, then the very policies that >> might be enforced by such a relay could be compromised by >> sending traffic through a visited-network relay. The odds >> that most sorts of visited networks are going to block VPNs, >> or indeed care about MSRP at all, seem quite slim to me. The >> sorts of visited networks that do care are likely to be >> unsympathetic to the policy needs of your home network. >> >> That much said, I am ultimately not persuaded that it is so >> problematic to create a Digest system for MSRP. Doing so >> would certainly invite additional scrutiny from the Security >> Area, but that scrutiny is likely to be constructive. If >> people want to admit cases where there are intermediary >> relays, then I think it is unwise not to address this >> scenario in the protocol design. >> >> Jon Peterson >> NeuStar, Inc. >> >>> -----Original Message----- >>> From: simple-bounces@ietf.org >>> [mailto:simple-bounces@ietf.org]On Behalf Of Orit Levin >>> Sent: Tuesday, June 28, 2005 12:34 PM >>> To: Cullen Jennings; Avshalom Houri; simple@ietf.org >>> Cc: Aki Niemi >>> Subject: RE: [Simple] OPEN ISSUE: Basic vs. Digest authentication >>> inMSRPrelays extension >>> >>> >>> I strongly support Avshalom's request for including in the >>> specification the ability to negotiate the security method >> to be used >>> with a particular Relay. >>> >>> We can say that Basic is MUST to implement but we can not prescribe >>> what level of security is going to be used in real >> deployments. If we >>> want implementations from different vendors interoperate >> according to >>> this standard - cutting the edges for "simplicity" will lead to >>> opposite results. >>> >>> I don't think that this list is the right place to have a serious >>> security debate but some facts are obvious: the credentials >> for Basic, >>> being sent in clear inside the hop-by-hop TLS connections, may be >>> different for different Relays and you don't want to expose them to >>> anyone who has an access to the relays in the middle. (And >> I hope that >>> IETF is not addressing monolithic systems only that will be >> OK with a >>> single method and a single password.) >>> >>> Orit. >>> >>>> -----Original Message----- >>>> From: simple-bounces@ietf.org >>>> [mailto:simple-bounces@ietf.org] On Behalf Of Cullen Jennings >>>> Sent: Tuesday, June 28, 2005 7:43 AM >>>> To: Avshalom Houri; simple@ietf.org >>>> Cc: Aki Niemi >>>> Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest >> authentication in >>>> MSRPrelays extension >>>> >>>> On 6/27/05 7:17 AM, "Avshalom Houri" wrote: >>>> >>>>> In order to go ahead can we come with a way to enable a >>>> relay to offer >>>>> basic or digest or other method in its 401 response? This >>>> way servers >>>>> can be configured to use different methods according to the >>>> required >>>>> security level and clients can reject too weak method if >>> they want. >>>>> This will also enable clients that do not have enough >>>> memory/CPU and >>>>> that work in a protected environment to use only basic >>>> authentication. >>>> >>>> Few trivial notes ... >>>> >>>> I don't think there is a very good argument to be made that there >>>> are devices that are capable of TLS but can't do digest. >> (I know you >>>> are not making this argument but just tossing in this comment) >>>> >>>> Thought I can live with either basic/digest I would really prefer >>>> one over both. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Thu Jun 30 11:03:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do0Zu-0002Ev-Dn; Thu, 30 Jun 2005 11:03:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do0Zt-0002Eg-4m for simple@megatron.ietf.org; Thu, 30 Jun 2005 11:03:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21515 for ; Thu, 30 Jun 2005 11:03:43 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do0zf-0005d5-Q5 for simple@ietf.org; Thu, 30 Jun 2005 11:30:24 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j5UF3fmD011076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 30 Jun 2005 11:03:42 -0400 (EDT) Message-ID: <42C409C8.10005@cs.columbia.edu> Date: Thu, 30 Jun 2005 11:03:36 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Subject: Re: [Simple] WGLC: RPID, CIPID, timed-status (6/30-7/13) References: <7349AA12-8EFA-4950-9823-3B5F9DE15003@cs.columbia.edu> <883de42067a822f68430258a205fad9c@nostrum.com> In-Reply-To: <883de42067a822f68430258a205fad9c@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 There is (at least) one known typo in the schema, in my rush to get this out while traveling: The line has a syntax error. See http://www.cs.columbia.edu/sip/draft/rpid/schema/rpid.xsd for the current stand-alone schema. Robert Sparks wrote: > These drafts were also recently revised (the iteration before this) so > that their > schemas align with the extensibility mechanisms agreed to since our most > recent visit to Minneapolis. > > These drafts have been through last calls before, but please look > through them > carefully again. > > Last call on these drafts ends 7/13. This gives Henning a few days to > integrate > any necessary before the -01 deadline. Earlier comments are better than > late. > > Thanks! _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 30 12:23:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do1pM-0007sh-2e; Thu, 30 Jun 2005 12:23:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do1pK-0007qZ-FC for simple@megatron.ietf.org; Thu, 30 Jun 2005 12:23:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29711 for ; Thu, 30 Jun 2005 12:23:43 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do2F7-0006nJ-Be for simple@ietf.org; Thu, 30 Jun 2005 12:50:26 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jun 2005 09:23:35 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jun 2005 09:23:35 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Date: Thu, 30 Jun 2005 09:23:33 -0700 Message-ID: Thread-Topic: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Thread-Index: AcV9hAHq/no++8uBR3iRXEb7xAF3wAABSwYg From: "Orit Levin" To: "Cullen Jennings" , X-OriginalArrivalTime: 30 Jun 2005 16:23:35.0190 (UTC) FILETIME=[1048DB60:01C57D90] X-Spam-Score: 0.8 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 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 We don't have to have both if we agree that we use Digest as the common denominator for all purposes (including for issuing the token) instead of Basic. That being said, I agree that for issuing the MSRP forwarding tokens - Basic syntax is enough. You could invent any other simple way of exchanging a password forth and a token back - this is not exactly what authentication is. The draft must clarify WHAT the described Basic format is being used for (i.e. for issuing the MSRP forwarding token only) instead of saying that this is THE way for a Relay to authenticate a client. Also the spec must say that in order for a Relay to securely (confidentially) authenticate a client, additional authentication mechanisms MAY be defined to be used with MSRP. The spec must specify NOW how the "issuing a token Basic-based procedure" will coexist with any other real authentication procedures that (most probably) will ALSO use the HTTP methods and formats. (It is really about "co-existence" rather than "negotiation".) Orit. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Thursday, June 30, 2005 7:10 AM > To: Orit Levin; simple@ietf.org > Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication > inMSRPrelays extension >=20 >=20 > I can see the argument for basic does everything we need and is the > simplest. I can see the argument for no basic is lacking and we need > digest. > But I'm not yet understanding why we would want both. >=20 >=20 > On 6/29/05 3:33 PM, "Orit Levin" wrote: >=20 > > It seems to me that our disconnect is around what the purposeS for a > > Relay to authenticate a certain client ARE. > > > > My point is that typically we will need to use BOTH Basic and Digest > > (and may be others to come) even for the same user for the same MSRP > > connection: first just for the proper MSRP forwarding (as the lightest > > means for issuing a token) and second for actually accessing a home > > network or other valid services network. > > > > More inline, > > Orit. > > > >> -----Original Message----- > >> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > >> Sent: Tuesday, June 28, 2005 2:28 PM > >> To: Orit Levin; Cullen Jennings; Avshalom Houri; simple@ietf.org > >> Cc: Aki Niemi > >> Subject: RE: [Simple] OPEN ISSUE: Basic vs. Digest > >> authentication inMSRPrelays extension > >> > >> > >> This is the crux of the matter. Are we admitting use cases in > >> which there are intermediary relays that would have the > >> opportunity to inspect Basic credentials? If so, then Basic > >> over hop-by-hop TLS is not sufficient. > >> > > > > It is OK for an intermediary MSRP relay to inspect the Basic credentials > > because: > > 1. According to the spec every MSRP relay needs to use the "token" > > mechanism and thus, by definition, it has the lowest transitive level of > > trust required for secure MSRP forwarding > > 2. A network protocol specification can not prohibit network entities > > from implementing internal tracing features (even if available to > > administrators only :-) > > > > BUT it is OK as long as some MSRP Relays (typically the home Relays) > > have standard means of establishing a stronger level of trust with some > > clients that they choose to. It is better to be described as "allowing > > additional (e.g. home) services" rather than enforcing "policies". > > Obviously, the credentials for this level of trust must not be visible > > to intermediates (even if trusted for plain MSRP forwarding). > > > >> The motivation for these uses cases remains a bit murky to > >> me, to be honest. I understand the argument that one might > >> have a visited-network relay and a policy-enforcing relay in > >> one's home network. At a high level, though, I tend to agree > >> with Rohan that if you are unable to make a direct connection > >> to a policy-enforcing relay, then the very policies that > >> might be enforced by such a relay could be compromised by > >> sending traffic through a visited-network relay. The odds > >> that most sorts of visited networks are going to block VPNs, > >> or indeed care about MSRP at all, seem quite slim to me. The > >> sorts of visited networks that do care are likely to be > >> unsympathetic to the policy needs of your home network. > >> > >> That much said, I am ultimately not persuaded that it is so > >> problematic to create a Digest system for MSRP. Doing so > >> would certainly invite additional scrutiny from the Security > >> Area, but that scrutiny is likely to be constructive. If > >> people want to admit cases where there are intermediary > >> relays, then I think it is unwise not to address this > >> scenario in the protocol design. > >> > >> Jon Peterson > >> NeuStar, Inc. > >> > >>> -----Original Message----- > >>> From: simple-bounces@ietf.org > >>> [mailto:simple-bounces@ietf.org]On Behalf Of Orit Levin > >>> Sent: Tuesday, June 28, 2005 12:34 PM > >>> To: Cullen Jennings; Avshalom Houri; simple@ietf.org > >>> Cc: Aki Niemi > >>> Subject: RE: [Simple] OPEN ISSUE: Basic vs. Digest authentication > >>> inMSRPrelays extension > >>> > >>> > >>> I strongly support Avshalom's request for including in the > >>> specification the ability to negotiate the security method > >> to be used > >>> with a particular Relay. > >>> > >>> We can say that Basic is MUST to implement but we can not prescribe > >>> what level of security is going to be used in real > >> deployments. If we > >>> want implementations from different vendors interoperate > >> according to > >>> this standard - cutting the edges for "simplicity" will lead to > >>> opposite results. > >>> > >>> I don't think that this list is the right place to have a serious > >>> security debate but some facts are obvious: the credentials > >> for Basic, > >>> being sent in clear inside the hop-by-hop TLS connections, may be > >>> different for different Relays and you don't want to expose them to > >>> anyone who has an access to the relays in the middle. (And > >> I hope that > >>> IETF is not addressing monolithic systems only that will be > >> OK with a > >>> single method and a single password.) > >>> > >>> Orit. > >>> > >>>> -----Original Message----- > >>>> From: simple-bounces@ietf.org > >>>> [mailto:simple-bounces@ietf.org] On Behalf Of Cullen Jennings > >>>> Sent: Tuesday, June 28, 2005 7:43 AM > >>>> To: Avshalom Houri; simple@ietf.org > >>>> Cc: Aki Niemi > >>>> Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest > >> authentication in > >>>> MSRPrelays extension > >>>> > >>>> On 6/27/05 7:17 AM, "Avshalom Houri" wrote: > >>>> > >>>>> In order to go ahead can we come with a way to enable a > >>>> relay to offer > >>>>> basic or digest or other method in its 401 response? This > >>>> way servers > >>>>> can be configured to use different methods according to the > >>>> required > >>>>> security level and clients can reject too weak method if > >>> they want. > >>>>> This will also enable clients that do not have enough > >>>> memory/CPU and > >>>>> that work in a protected environment to use only basic > >>>> authentication. > >>>> > >>>> Few trivial notes ... > >>>> > >>>> I don't think there is a very good argument to be made that there > >>>> are devices that are capable of TLS but can't do digest. > >> (I know you > >>>> are not making this argument but just tossing in this comment) > >>>> > >>>> Thought I can live with either basic/digest I would really prefer > >>>> one over both. > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 Thu Jun 30 16:44:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do5tm-0006kx-9m; Thu, 30 Jun 2005 16:44:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do5th-0006JQ-QG for simple@megatron.ietf.org; Thu, 30 Jun 2005 16:44:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22172 for ; Thu, 30 Jun 2005 16:44:29 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do6JU-0003Qx-GV for simple@ietf.org; Thu, 30 Jun 2005 17:11:13 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j5UKgpu04020; Thu, 30 Jun 2005 16:42:51 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Jun 2005 15:43:59 -0500 Message-ID: Thread-Topic: WGLC comments: draft-ietf-simple-msrp-relays-04 Thread-Index: AcV9tHFhtw3O47bMTrmhSfJW416phA== From: "Mary Barnes" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: [Simple] WGLC comments: draft-ietf-simple-msrp-relays-04 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 Cullen and Rohan, I've reviewed the draft and found only a few nits and editorial comments (I'll respond separately to the thread on the Basic/Digest thread): - Section 2. First paragraph. Third sentence. For someone unfamiliar with SIMPLE WG, this sentence could be confusing as it reads as if you're saying the 1st 2 sentences are describing something other than MSRP, although I believe the intent of the "also" is to describe additionally what MSRP does. I would suggest to change from: "The SIMPLE Working Group has also developed MSRP (the Message Sessions Relay Protocol) [18] to convey sessions of messages directly between two end systems with no intermediaries." to: "The SIMPLE Working Group developed MSRP (the Message Sessions Relay Protocol) [18] to convey sessions of messages directly between two end systems with no intermediaries." - Section 3. Page 9. 2nd full sentence. Change "If the sender set...." to "If the sender sets ...."=20 - Section 5.3. page 15. It might be nice to include a reference to the specific section in the base MSRP spec that corresponds to those identical procedures.=20 - Section 6.4.1. 3rd paragraph, last sentence. Change "...back to original..." to "...back to the original..." - Section 9.2. 1st paragraph, 4th sentence. "A relays must..." -> "A relay must..." - Section 9.3. 2nd paragraph, 2nd sentence. "...certain policy operation..." -> "...certain policy operations..." Regards, Mary. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 30 16:55:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do64U-0004iR-H5; Thu, 30 Jun 2005 16:55:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do64P-0004Qr-AA for simple@megatron.ietf.org; Thu, 30 Jun 2005 16:55:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22810 for ; Thu, 30 Jun 2005 16:55:34 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do6UD-0003cy-AE for simple@ietf.org; Thu, 30 Jun 2005 17:22:18 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j5UKs5u05345; Thu, 30 Jun 2005 16:54:05 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relaysextension Date: Thu, 30 Jun 2005 15:55:14 -0500 Message-ID: Thread-Topic: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relaysextension Thread-Index: AcV2A06lXDzGVROOT+WTj2aKLflTDgHskA3w From: "Mary Barnes" To: "Rohan Mahy" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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 think Basic is fine, as currently specified in the draft. Has there been any discussion with the security ADs/gurus to see where they might stand on this issue (i.e are they okay with Basic)?=20 Mary. -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Rohan Mahy Sent: Monday, June 20, 2005 8:44 PM To: simple@ietf.org WG Cc: Rohan Mahy Subject: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relaysextension Hi Everyone, Despite the thread on the list from late March and early April about=20 Basic vs Digest authentication, I don't feel like we came to consensus=20 on this issue. First I would like to apologize for my lack of attention=20 on this particular issue, and that it has remained open for so long. The arguments in favor of Digest authentication included a number of=20 incorrect assumptions (marked "I") which need to be clarified in the=20 draft. Among them: I: Relays for user B get to see the username and password for user A. A: This never happens. user A only sends AUTH requests to *its*=20 relays, never to the relays used to forward requests on to another=20 user. I: User B sends its password in the clear over the network. A: Use of TLS is mandatory, user B only sends its password inside a=20 TLS-protected channel. I: The Security Area Directors will never allow this. A: Based on preliminary discussions, I believe this will be acceptable=20 to the Security ADs. Again, use of TLS is mandatory. This is exactly=20 like the common usage of SMTP using PLAIN user authentication over a=20 TLS-protected channel, which is a very widely deployed model. I: If I use RADIUS I have to send the username and password in the clear A: The MSRP relay can hash the password before sending to the RADIUS=20 server, or send all RADIUS traffic over a protected channel. There are two other concerns with Basic which are accurate: 1. If example.com has an inner relay and an outer relay, credentials=20 for outer.example.com are revealed to inner.example.com as AUTH=20 requests are forwarded to outer.example.com. This limitation is=20 clearly explained in the Security Considerations section. 2. The other issue that Avshalom brought up is that the relay=20 administrator has access to the password, or an attacker who can gain=20 access to the relay machine. While the administrator could mount a=20 dictionary attack on a Digest protected password, its obviously easier=20 to get access to the password when it isn't hashed at all. When I originally tried to map the draft onto Digest, I was planning to=20 do something like this: - realm is a string provided by the server. it SHOULD be the host name=20 of the relay. - the domains parameter is ignored - note that the nonce algorithm based on ETags doesn't work - do not support auth-int, but always include the qop parameter with=20 auth - the digest-uri parameter is the right-most URI in the To-Path header - the alg parameter is ??? - the cnonce and the nonce-count MUST be sent - the Method from A2 is always AUTH - there is never a body for AUTH so A2 is just AUTH: plus the=20 Request-URI - I have no idea what to do about MD5 vs. MD5-sess. - I have no idea whether the nextnonce parameter is useful here. - I don't think the response authentication parameter is useful at all.=20 However, the security considerations needs to describe what would or=20 would not be protected here. Remember that we have no integrity over=20 the Use-Path header from client to outermost relay even if we use this,=20 unless we redefine the A2 to include the value of the Use-Path header=20 instead of the entity-body. The arguments in favor of Basic authentication are: 1. Basic authentication is much simpler to implement than Digest, and=20 the authors feel that with TLS protection of the channel that its=20 security is good enough. We expect MSRP AUTH to be used within a single=20 administrative domain, and the limitation of the server seeing the=20 plain text password is similar to the way that many email services are=20 deployed with TLS. 2. Digest authentication is not a great fit to MSRP and as a result its=20 not obvious what to specify for all the parameters. What do we do? My proposal is to go with Basic. I have updated the=20 draft leaving Basic in place. I feel this is appropriate given the=20 relative security of the base draft, and given what would be needed to=20 do Digest properly. If the consensus of the group is that we should do=20 Digest instead, then I urge someone to propose specific text answering=20 the questions I discuss above, that would go into the draft. thanks, -rohan _______________________________________________ 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