From simple-admin@ietf.org Tue Jul 1 07:12:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06341; Tue, 1 Jul 2003 07:12:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XJ3a-0002C5-00; Tue, 01 Jul 2003 07:12:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XJ3U-0002Bl-00; Tue, 01 Jul 2003 07:12:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJ3F-0006Ng-Op; Tue, 01 Jul 2003 07:11:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJ2c-0006Mv-3S for simple@optimus.ietf.org; Tue, 01 Jul 2003 07:11:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06323 for ; Tue, 1 Jul 2003 07:11:11 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XJ2V-0002BP-00 for simple@ietf.org; Tue, 01 Jul 2003 07:11:12 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19XJ2L-0002AN-00 for simple@ietf.org; Tue, 01 Jul 2003 07:11:01 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h61B8la26009 for ; Tue, 1 Jul 2003 14:08:47 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 1 Jul 2003 14:08:46 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Jul 2003 14:08:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] MSRP - Ending a Session Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796E7C@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP - Ending a Session Thread-Index: AcM/QCce5bzphwAVSSmJhe6R9jQIagAf80Wg To: , , , Cc: X-OriginalArrivalTime: 01 Jul 2003 11:08:46.0766 (UTC) FILETIME=[245A94E0:01C33FC1] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 1 Jul 2003 14:08:46 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, June 30, 2003 10:44 PM > To: Ben Campbell; Robert Sparks; Jonathan Rosenberg > Cc: simple@ietf.org > Subject: [Simple] MSRP - Ending a Session >=20 >=20 > (We had this discussion a long time ago, but I think it is worth=20 > revisiting in the context of MSRP as it currently stands.) >=20 > I think we can and should specify behavior that results in a graceful=20 > close of an MSRP session, where messages are not lost. Now=20 > that we have=20 > dedicated tcp connections for each session this is easier=20 > than it once=20 > was. Here is what I have in mind: >=20 > - an endpoint SHOULD NOT signal its intent to end the session=20 > while it=20 > has any unconfirmed SEND messages outstanding. >=20 > - if an endpoint receives a request to end the session while it has=20 > unconfirmed SEND messages outstanding, it SHOULD refuse the=20 > request to=20 > end the session. >=20 > A request to end a session via reINVITE can be refused by responding=20 > with an error. (The code 491 is close to the right response,=20 > but I don't=20 > know if it is permitted to use it in this situation.) The=20 > advantage of=20 > this approach is that it doesn't cost any extra in normal cases where=20 > there is no race condition. So, when there is a race condition (SEND and reINVITE cross) A B ---------------- SEND (MRSP) ------> reINVITE (SIP) <----------=20 2 scenarios for B: - It will eventually receive the SEND before it receives the error = response to the reINVITE. In this case it should respond to SEND and = then wait for the error response for the reINVITE before it issues it = again (or should it re-issue the reINVITE before it receives a response = to the first one?) - It will receive the SEND after it receives the error response to the = reINVITE. In this case it should respond to SEND and then re-issue the = reINVITE. The question is, how long to wait for the SEND to arrive? Regards, Hisham >=20 > Some requests to end a session (such as BYE) can't meaningfully be=20 > refused. In those cases the session may not terminate gracefully. >=20 > I see conflicts over the ending of a session quite frequently=20 > with IM. I=20 > say something that I think terminates the conversation and=20 > shut down the=20 > window, only to have the other party respond. Typically (at=20 > least with=20 > Sametime) the window is recovered and the session resumes. I think we=20 > would be ill advised to do something less acceptable. >=20 > Of course all the above needs to be SHOULD strength, because UAs must=20 > have the option of quitting whenenver they feel they must. >=20 > Paul >=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 exim@www1.ietf.org Tue Jul 1 07:12:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06379 for ; Tue, 1 Jul 2003 07:12:46 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61BCJa24807 for simple-archive@odin.ietf.org; Tue, 1 Jul 2003 07:12:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJ3b-0006S2-1y for simple-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 07:12:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06341; Tue, 1 Jul 2003 07:12:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XJ3a-0002C5-00; Tue, 01 Jul 2003 07:12:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XJ3U-0002Bl-00; Tue, 01 Jul 2003 07:12:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJ3F-0006Ng-Op; Tue, 01 Jul 2003 07:11:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJ2c-0006Mv-3S for simple@optimus.ietf.org; Tue, 01 Jul 2003 07:11:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06323 for ; Tue, 1 Jul 2003 07:11:11 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XJ2V-0002BP-00 for simple@ietf.org; Tue, 01 Jul 2003 07:11:12 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19XJ2L-0002AN-00 for simple@ietf.org; Tue, 01 Jul 2003 07:11:01 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h61B8la26009 for ; Tue, 1 Jul 2003 14:08:47 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 1 Jul 2003 14:08:46 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Jul 2003 14:08:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] MSRP - Ending a Session Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796E7C@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP - Ending a Session Thread-Index: AcM/QCce5bzphwAVSSmJhe6R9jQIagAf80Wg To: , , , Cc: X-OriginalArrivalTime: 01 Jul 2003 11:08:46.0766 (UTC) FILETIME=[245A94E0:01C33FC1] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 1 Jul 2003 14:08:46 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, June 30, 2003 10:44 PM > To: Ben Campbell; Robert Sparks; Jonathan Rosenberg > Cc: simple@ietf.org > Subject: [Simple] MSRP - Ending a Session >=20 >=20 > (We had this discussion a long time ago, but I think it is worth=20 > revisiting in the context of MSRP as it currently stands.) >=20 > I think we can and should specify behavior that results in a graceful=20 > close of an MSRP session, where messages are not lost. Now=20 > that we have=20 > dedicated tcp connections for each session this is easier=20 > than it once=20 > was. Here is what I have in mind: >=20 > - an endpoint SHOULD NOT signal its intent to end the session=20 > while it=20 > has any unconfirmed SEND messages outstanding. >=20 > - if an endpoint receives a request to end the session while it has=20 > unconfirmed SEND messages outstanding, it SHOULD refuse the=20 > request to=20 > end the session. >=20 > A request to end a session via reINVITE can be refused by responding=20 > with an error. (The code 491 is close to the right response,=20 > but I don't=20 > know if it is permitted to use it in this situation.) The=20 > advantage of=20 > this approach is that it doesn't cost any extra in normal cases where=20 > there is no race condition. So, when there is a race condition (SEND and reINVITE cross) A B ---------------- SEND (MRSP) ------> reINVITE (SIP) <----------=20 2 scenarios for B: - It will eventually receive the SEND before it receives the error = response to the reINVITE. In this case it should respond to SEND and = then wait for the error response for the reINVITE before it issues it = again (or should it re-issue the reINVITE before it receives a response = to the first one?) - It will receive the SEND after it receives the error response to the = reINVITE. In this case it should respond to SEND and then re-issue the = reINVITE. The question is, how long to wait for the SEND to arrive? Regards, Hisham >=20 > Some requests to end a session (such as BYE) can't meaningfully be=20 > refused. In those cases the session may not terminate gracefully. >=20 > I see conflicts over the ending of a session quite frequently=20 > with IM. I=20 > say something that I think terminates the conversation and=20 > shut down the=20 > window, only to have the other party respond. Typically (at=20 > least with=20 > Sametime) the window is recovered and the session resumes. I think we=20 > would be ill advised to do something less acceptable. >=20 > Of course all the above needs to be SHOULD strength, because UAs must=20 > have the option of quitting whenenver they feel they must. >=20 > Paul >=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-admin@ietf.org Tue Jul 1 07:24:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07464; Tue, 1 Jul 2003 07:24:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XJF5-0002KY-00; Tue, 01 Jul 2003 07:24:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XJF0-0002KV-00; Tue, 01 Jul 2003 07:24:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJEw-0007Re-1v; Tue, 01 Jul 2003 07:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJEs-0007PK-Hw for simple@optimus.ietf.org; Tue, 01 Jul 2003 07:23:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07359; Tue, 1 Jul 2003 07:23:55 -0400 (EDT) Message-Id: <200307011123.HAA07359@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-data-req-03.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 01 Jul 2003 07:23:54 -0400 --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 : Requirements for Manipulation of Data Elements in Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Systems Author(s) : J. Rosenberg, M. Isomaki Filename : draft-ietf-simple-data-req-03.txt Pages : 16 Date : 2003-6-30 In any presence application, it is frequently necessary for the user to configure a number of pieces of information. Users will need to manipulate their presentity list, adding and removing presentities, and manipulate their authorization lists, which specify the set of users that can subscribe to their presence. In this document, we provide a framework and requirements for such data manipulations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-data-req-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-data-req-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: <2003-6-30151601.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-data-req-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-data-req-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151601.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 1 07:24:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07614 for ; Tue, 1 Jul 2003 07:24:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61BODu28962 for simple-archive@odin.ietf.org; Tue, 1 Jul 2003 07:24:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJF7-0007Ws-JH for simple-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 07:24:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07464; Tue, 1 Jul 2003 07:24:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XJF5-0002KY-00; Tue, 01 Jul 2003 07:24:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XJF0-0002KV-00; Tue, 01 Jul 2003 07:24:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJEw-0007Re-1v; Tue, 01 Jul 2003 07:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJEs-0007PK-Hw for simple@optimus.ietf.org; Tue, 01 Jul 2003 07:23:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07359; Tue, 1 Jul 2003 07:23:55 -0400 (EDT) Message-Id: <200307011123.HAA07359@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-data-req-03.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 01 Jul 2003 07:23:54 -0400 --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 : Requirements for Manipulation of Data Elements in Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Systems Author(s) : J. Rosenberg, M. Isomaki Filename : draft-ietf-simple-data-req-03.txt Pages : 16 Date : 2003-6-30 In any presence application, it is frequently necessary for the user to configure a number of pieces of information. Users will need to manipulate their presentity list, adding and removing presentities, and manipulate their authorization lists, which specify the set of users that can subscribe to their presence. In this document, we provide a framework and requirements for such data manipulations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-data-req-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-data-req-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: <2003-6-30151601.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-data-req-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-data-req-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151601.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 1 08:12:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11849; Tue, 1 Jul 2003 08:12:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJzN-0001vV-70; Tue, 01 Jul 2003 08:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJyq-0001uE-S9 for simple@optimus.ietf.org; Tue, 01 Jul 2003 08:11:29 -0400 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11665 for ; Tue, 1 Jul 2003 08:11:24 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA00347; Tue, 1 Jul 2003 08:10:54 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA07999; Tue, 1 Jul 2003 08:10:55 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Jul 2003 08:10:54 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5B7E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , hisham.khartabil@nokia.com Cc: Dirk.Trossen@nokia.com, simple@ietf.org Subject: RE: [Simple] comments on rpids-01 , MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 1 Jul 2003 08:10:54 -0400 Please note that most cell phones would probably never show "closed", because they all forward-no-answer to a voicemail system, thus they will take a call at all times. If the cellphone carrier's presence system got rich enough to show both the voicemail system and the phone itself as separate tuples, then you might see closed on the phone, but you might have a tough time with what you do when you momentarily drop out of range. I think it would be great if they told you what they knew, but I'm not holding my breath. I think is a valuable piece of information, especially for an aggregator. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, June 30, 2003 9:25 PM > To: hisham.khartabil@nokia.com > Cc: Dirk.Trossen@nokia.com; simple@ietf.org > Subject: Re: [Simple] comments on rpids-01 , > > > hisham.khartabil@nokia.com wrote: > > > > > In the case of mobile phone (cellphone), does > not provide > > any hint as to whether I am likely to be near the phone or not. This > > was exactly my point inthe earlier posting. If you use the > > value as an indication of the likelihood of me answering > > my mobile phone, then you may never call me on my mobile unless I > > just got off a phone call (its idle all other times). So we need > > something like OPEN and CLOSED. > > We must be talking past each other. There are three cases: > > - You have your cell phone on and have used it recently (made > a call or > received a call). The indication might indicate "last used 5 > minutes ago". This is a good indication that you will answer > that cell > phone when I call. > > - You have not used your cellphone for a long time, but it is on (= > OPEN). This means that you're not making or receiving a lot of phone > calls or that the phone is silently draining its battery in your > bedroom drawer and is too dumb to notice it. There is no way > to tell one > or the other, short of knowing your location and your cell > phone location. > > - The cell phone is off => Set status to CLOSED if you remember to do > that or if the phone does it automatically. doesn't > help one way > or the other and is not relevant for CLOSED status. > > Thus, for a cell phone, the useful bit of information is a > *short* idle > time. A long idle time says very little, unless I happen to know that > you are a compulsive mobile phone user so that a long idle time might > tell me something is amiss. > > > > > > >> The activity indication (sleeping, driving, etc.) is completely > >> separate. Just to avoid misunderstandings, what exactly are you > >> referring to as activity? > > > > > > I am using the current definition of with values active > > and inactive. But I think we agreed that OPEN and CLOSED where a > > sufficient enough replacement. Did we? > > There was agreement that only (formerly known as > ) is > necessary. As I've tried to explain above, provides additional > information that the basic OPEN and CLOSED status does not. > > 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 exim@www1.ietf.org Tue Jul 1 08:13:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11977 for ; Tue, 1 Jul 2003 08:13:04 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61CCcu07635 for simple-archive@odin.ietf.org; Tue, 1 Jul 2003 08:12:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJzy-0001z4-3R for simple-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 08:12:38 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11849; Tue, 1 Jul 2003 08:12:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJzN-0001vV-70; Tue, 01 Jul 2003 08:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJyq-0001uE-S9 for simple@optimus.ietf.org; Tue, 01 Jul 2003 08:11:29 -0400 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11665 for ; Tue, 1 Jul 2003 08:11:24 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA00347; Tue, 1 Jul 2003 08:10:54 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA07999; Tue, 1 Jul 2003 08:10:55 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Jul 2003 08:10:54 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5B7E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , hisham.khartabil@nokia.com Cc: Dirk.Trossen@nokia.com, simple@ietf.org Subject: RE: [Simple] comments on rpids-01 , MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 1 Jul 2003 08:10:54 -0400 Please note that most cell phones would probably never show "closed", because they all forward-no-answer to a voicemail system, thus they will take a call at all times. If the cellphone carrier's presence system got rich enough to show both the voicemail system and the phone itself as separate tuples, then you might see closed on the phone, but you might have a tough time with what you do when you momentarily drop out of range. I think it would be great if they told you what they knew, but I'm not holding my breath. I think is a valuable piece of information, especially for an aggregator. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, June 30, 2003 9:25 PM > To: hisham.khartabil@nokia.com > Cc: Dirk.Trossen@nokia.com; simple@ietf.org > Subject: Re: [Simple] comments on rpids-01 , > > > hisham.khartabil@nokia.com wrote: > > > > > In the case of mobile phone (cellphone), does > not provide > > any hint as to whether I am likely to be near the phone or not. This > > was exactly my point inthe earlier posting. If you use the > > value as an indication of the likelihood of me answering > > my mobile phone, then you may never call me on my mobile unless I > > just got off a phone call (its idle all other times). So we need > > something like OPEN and CLOSED. > > We must be talking past each other. There are three cases: > > - You have your cell phone on and have used it recently (made > a call or > received a call). The indication might indicate "last used 5 > minutes ago". This is a good indication that you will answer > that cell > phone when I call. > > - You have not used your cellphone for a long time, but it is on (= > OPEN). This means that you're not making or receiving a lot of phone > calls or that the phone is silently draining its battery in your > bedroom drawer and is too dumb to notice it. There is no way > to tell one > or the other, short of knowing your location and your cell > phone location. > > - The cell phone is off => Set status to CLOSED if you remember to do > that or if the phone does it automatically. doesn't > help one way > or the other and is not relevant for CLOSED status. > > Thus, for a cell phone, the useful bit of information is a > *short* idle > time. A long idle time says very little, unless I happen to know that > you are a compulsive mobile phone user so that a long idle time might > tell me something is amiss. > > > > > > >> The activity indication (sleeping, driving, etc.) is completely > >> separate. Just to avoid misunderstandings, what exactly are you > >> referring to as activity? > > > > > > I am using the current definition of with values active > > and inactive. But I think we agreed that OPEN and CLOSED where a > > sufficient enough replacement. Did we? > > There was agreement that only (formerly known as > ) is > necessary. As I've tried to explain above, provides additional > information that the basic OPEN and CLOSED status does not. > > 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 sip-admin@ietf.org Tue Jul 1 09:14:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21780 for ; Tue, 1 Jul 2003 09:14:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKxq-0005ub-Ec for simple-archive@ietf.org; Tue, 01 Jul 2003 09:14:30 -0400 Date: Tue, 01 Jul 2003 09:14:30 -0400 Message-ID: <20030701131430.18162.29006.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: simple-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for simple-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org onahda https://www1.ietf.org/mailman/options/simple/simple-archive%40ietf.org From exim@www1.ietf.org Tue Jul 1 09:39:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27630 for ; Tue, 1 Jul 2003 09:39:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61Dd1204118 for simple-archive@odin.ietf.org; Tue, 1 Jul 2003 09:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLLZ-00014E-3j for simple-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 09:39:01 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27507 for ; Tue, 1 Jul 2003 09:38:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLL4-0000pq-KL for simple-web-archive@ietf.org; Tue, 01 Jul 2003 09:38:30 -0400 Date: Tue, 01 Jul 2003 09:38:30 -0400 Message-ID: <20030701133830.18162.11453.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: simple-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for simple-web-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org fuasex https://www1.ietf.org/mailman/options/simple/simple-web-archive%40ietf.org From simple-admin@ietf.org Tue Jul 1 09:44:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28665; Tue, 1 Jul 2003 09:44:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLQW-00037B-LS; Tue, 01 Jul 2003 09:44:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLQ9-0002xt-Qh for simple@optimus.ietf.org; Tue, 01 Jul 2003 09:43:45 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28517 for ; Tue, 1 Jul 2003 09:43:42 -0400 (EDT) Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h61Dbpg5008491; Tue, 1 Jul 2003 09:37:52 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by cannon.cisco.com (Mirapoint) with ESMTP id ABM88524; Tue, 1 Jul 2003 09:46:49 -0400 (EDT) Message-ID: <3F018EAF.8080208@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: bcampbell@dynamicsoft.com, rsparks@dynamicsoft.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] MSRP - Ending a Session References: <2038BCC78B1AD641891A0D1AE133DBB701796E7C@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 01 Jul 2003 09:37:51 -0400 Content-Transfer-Encoding: 7bit Hisham - comment at end. Paul hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Monday, June 30, 2003 10:44 PM >>To: Ben Campbell; Robert Sparks; Jonathan Rosenberg >>Cc: simple@ietf.org >>Subject: [Simple] MSRP - Ending a Session >> >> >>(We had this discussion a long time ago, but I think it is worth >>revisiting in the context of MSRP as it currently stands.) >> >>I think we can and should specify behavior that results in a graceful >>close of an MSRP session, where messages are not lost. Now >>that we have >>dedicated tcp connections for each session this is easier >>than it once >>was. Here is what I have in mind: >> >>- an endpoint SHOULD NOT signal its intent to end the session >>while it >>has any unconfirmed SEND messages outstanding. >> >>- if an endpoint receives a request to end the session while it has >>unconfirmed SEND messages outstanding, it SHOULD refuse the >>request to >>end the session. >> >>A request to end a session via reINVITE can be refused by responding >>with an error. (The code 491 is close to the right response, >>but I don't >>know if it is permitted to use it in this situation.) The >>advantage of >>this approach is that it doesn't cost any extra in normal cases where >>there is no race condition. > > > So, when there is a race condition (SEND and reINVITE cross) > > A B > ---------------- > > SEND (MRSP) > ------> > reINVITE (SIP) > <---------- > > 2 scenarios for B: > - It will eventually receive the SEND before it receives the > error response to the reINVITE. In this case it should respond > to SEND and then wait for the error response for the reINVITE > before it issues it again (or should it re-issue the reINVITE > before it receives a response to the first one?) There may be no error in this case, depending on timing at A. B should respond to the SEND, and continue to await a response to the reINVITE. > > - It will receive the SEND after it receives the error response > to the reINVITE. In this case it should respond to SEND and then > re-issue the reINVITE. The question is, how long to wait for the > SEND to arrive? That is TBD. Do you have any good ideas? In some sense it doesn't matter, except as a tradeoff between efficiency and promptness of shutting down the session. If B tries again too soon, the error will simply be repeated. From a practical perspective, it will often probably be sufficient for B to check if anything (e.g. a partial message) has been received on the media stream, and if so keep waiting. When it eventually receives a full message, respond to it. Then if there is more in the pipe, repeat. If there is nothing in the pipe then retry the reINVITE, possibly after a brief delay. The ugly case here is where the SEND from a is that fabled 5GB file. Another option is for B to reconsider its attempt to shut down the session. It could simply decide that A still wants to talk, and so continue. But this is an application decision, not protocol. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 1 09:45:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28805 for ; Tue, 1 Jul 2003 09:45:09 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61Difc12956 for simple-archive@odin.ietf.org; Tue, 1 Jul 2003 09:44:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLR3-0003Mr-99 for simple-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 09:44:41 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28665; Tue, 1 Jul 2003 09:44:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLQW-00037B-LS; Tue, 01 Jul 2003 09:44:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLQ9-0002xt-Qh for simple@optimus.ietf.org; Tue, 01 Jul 2003 09:43:45 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28517 for ; Tue, 1 Jul 2003 09:43:42 -0400 (EDT) Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h61Dbpg5008491; Tue, 1 Jul 2003 09:37:52 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by cannon.cisco.com (Mirapoint) with ESMTP id ABM88524; Tue, 1 Jul 2003 09:46:49 -0400 (EDT) Message-ID: <3F018EAF.8080208@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: bcampbell@dynamicsoft.com, rsparks@dynamicsoft.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] MSRP - Ending a Session References: <2038BCC78B1AD641891A0D1AE133DBB701796E7C@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 01 Jul 2003 09:37:51 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hisham - comment at end. Paul hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Monday, June 30, 2003 10:44 PM >>To: Ben Campbell; Robert Sparks; Jonathan Rosenberg >>Cc: simple@ietf.org >>Subject: [Simple] MSRP - Ending a Session >> >> >>(We had this discussion a long time ago, but I think it is worth >>revisiting in the context of MSRP as it currently stands.) >> >>I think we can and should specify behavior that results in a graceful >>close of an MSRP session, where messages are not lost. Now >>that we have >>dedicated tcp connections for each session this is easier >>than it once >>was. Here is what I have in mind: >> >>- an endpoint SHOULD NOT signal its intent to end the session >>while it >>has any unconfirmed SEND messages outstanding. >> >>- if an endpoint receives a request to end the session while it has >>unconfirmed SEND messages outstanding, it SHOULD refuse the >>request to >>end the session. >> >>A request to end a session via reINVITE can be refused by responding >>with an error. (The code 491 is close to the right response, >>but I don't >>know if it is permitted to use it in this situation.) The >>advantage of >>this approach is that it doesn't cost any extra in normal cases where >>there is no race condition. > > > So, when there is a race condition (SEND and reINVITE cross) > > A B > ---------------- > > SEND (MRSP) > ------> > reINVITE (SIP) > <---------- > > 2 scenarios for B: > - It will eventually receive the SEND before it receives the > error response to the reINVITE. In this case it should respond > to SEND and then wait for the error response for the reINVITE > before it issues it again (or should it re-issue the reINVITE > before it receives a response to the first one?) There may be no error in this case, depending on timing at A. B should respond to the SEND, and continue to await a response to the reINVITE. > > - It will receive the SEND after it receives the error response > to the reINVITE. In this case it should respond to SEND and then > re-issue the reINVITE. The question is, how long to wait for the > SEND to arrive? That is TBD. Do you have any good ideas? In some sense it doesn't matter, except as a tradeoff between efficiency and promptness of shutting down the session. If B tries again too soon, the error will simply be repeated. From a practical perspective, it will often probably be sufficient for B to check if anything (e.g. a partial message) has been received on the media stream, and if so keep waiting. When it eventually receives a full message, respond to it. Then if there is more in the pipe, repeat. If there is nothing in the pipe then retry the reINVITE, possibly after a brief delay. The ugly case here is where the SEND from a is that fabled 5GB file. Another option is for B to reconsider its attempt to shut down the session. It could simply decide that A still wants to talk, and so continue. But this is an application decision, not protocol. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 1 11:39:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04804; Tue, 1 Jul 2003 11:39:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XNDn-0005l8-00; Tue, 01 Jul 2003 11:39:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XNDh-0005l5-00; Tue, 01 Jul 2003 11:39:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XNDh-0003Jf-73; Tue, 01 Jul 2003 11:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XNDa-0003JP-5b for simple@optimus.ietf.org; Tue, 01 Jul 2003 11:38:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04801 for ; Tue, 1 Jul 2003 11:38:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XNDX-0005l1-00 for simple@ietf.org; Tue, 01 Jul 2003 11:38:51 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19XNDM-0005kd-00 for simple@ietf.org; Tue, 01 Jul 2003 11:38:40 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h61Fbjs27047; Tue, 1 Jul 2003 10:37:46 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h61FbiP11061; Tue, 1 Jul 2003 10:37:44 -0500 (CDT) Message-ID: <3F01AA96.6030906@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: hisham.khartabil@nokia.com, Dirk.Trossen@nokia.com, simple@ietf.org Subject: Re: [Simple] comments on rpids-01 , References: <2038BCC78B1AD641891A0D1AE133DBB701796E6E@esebe019.ntc.nokia.com> <3F00E2E4.50403@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 01 Jul 2003 10:36:54 -0500 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: [...] > Thus, for a cell phone, the useful bit of information is a *short* idle > time. A long idle time says very little, unless I happen to know that > you are a compulsive mobile phone user so that a long idle time might > tell me something is amiss. Right; is a valuable piece of information that can be leveraged not only for cell phones, but traditional ones as well. One could just as well represent a wired phone as a tuple in a presence document. One of the experiences we gleaned from prototyping the presence/availability of a user using a wireline phone tuple was exactly how long a user may be 'present and available' near a phone once the conversation ended. The element imparts this information succintly to a watcher. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 1 11:39:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04829 for ; Tue, 1 Jul 2003 11:39:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61FdAf12901 for simple-archive@odin.ietf.org; Tue, 1 Jul 2003 11:39:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XNDq-0003M0-JU for simple-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 11:39:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04804; Tue, 1 Jul 2003 11:39:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XNDn-0005l8-00; Tue, 01 Jul 2003 11:39:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XNDh-0005l5-00; Tue, 01 Jul 2003 11:39:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XNDh-0003Jf-73; Tue, 01 Jul 2003 11:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XNDa-0003JP-5b for simple@optimus.ietf.org; Tue, 01 Jul 2003 11:38:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04801 for ; Tue, 1 Jul 2003 11:38:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XNDX-0005l1-00 for simple@ietf.org; Tue, 01 Jul 2003 11:38:51 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19XNDM-0005kd-00 for simple@ietf.org; Tue, 01 Jul 2003 11:38:40 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h61Fbjs27047; Tue, 1 Jul 2003 10:37:46 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h61FbiP11061; Tue, 1 Jul 2003 10:37:44 -0500 (CDT) Message-ID: <3F01AA96.6030906@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: hisham.khartabil@nokia.com, Dirk.Trossen@nokia.com, simple@ietf.org Subject: Re: [Simple] comments on rpids-01 , References: <2038BCC78B1AD641891A0D1AE133DBB701796E6E@esebe019.ntc.nokia.com> <3F00E2E4.50403@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 01 Jul 2003 10:36:54 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: [...] > Thus, for a cell phone, the useful bit of information is a *short* idle > time. A long idle time says very little, unless I happen to know that > you are a compulsive mobile phone user so that a long idle time might > tell me something is amiss. Right; is a valuable piece of information that can be leveraged not only for cell phones, but traditional ones as well. One could just as well represent a wired phone as a tuple in a presence document. One of the experiences we gleaned from prototyping the presence/availability of a user using a wireline phone tuple was exactly how long a user may be 'present and available' near a phone once the conversation ended. The element imparts this information succintly to a watcher. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 1 13:48:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08324 for ; Tue, 1 Jul 2003 13:48:08 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RINfO21962 for simple-archive@odin.ietf.org; Fri, 27 Jun 2003 14:23:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vxso-0005hr-EQ for simple-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:23:38 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09523; Fri, 27 Jun 2003 14:23:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vxrc-00058n-2U; Fri, 27 Jun 2003 14:22:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VuNU-0002NW-KR for simple@optimus.ietf.org; Fri, 27 Jun 2003 10:39:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28566 for ; Fri, 27 Jun 2003 10:13:56 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VtzC-0002ts-00 for simple@ietf.org; Fri, 27 Jun 2003 10:13:58 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19Vtz1-0002to-00 for simple@ietf.org; Fri, 27 Jun 2003 10:13:47 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5REDfa06664 for ; Fri, 27 Jun 2003 17:13:41 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 27 Jun 2003 17:13:40 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 27 Jun 2003 17:13:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796E6A@esebe019.ntc.nokia.com> Thread-Topic: comments on rpids-01 Thread-Index: AcM8tkqz6VLGWb2cSBCJUjtg9keK/w== To: X-OriginalArrivalTime: 27 Jun 2003 14:13:40.0831 (UTC) FILETIME=[4F478EF0:01C33CB6] Content-Transfer-Encoding: quoted-printable Subject: [Simple] comments on rpids-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 27 Jun 2003 17:13:40 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I know this element does not exist, but I was wondering if its useful to = have an element that indicates how far a user is from his/her device. = This might help when, for example, I move any from my device or when I'm = sitting right next to it, but having my lunch. I could indicate if I'm = far from or near to the device. This overlaps a little with the current = element. Just a thought. Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 1 13:48:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08592 for ; Tue, 1 Jul 2003 13:48:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIU6s00947 for simple-archive@odin.ietf.org; Fri, 27 Jun 2003 14:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vxyz-0000Cp-LP for simple-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:30:01 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10341; Fri, 27 Jun 2003 14:29:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VxxN-00087F-GH; Fri, 27 Jun 2003 14:28:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VvRG-00064A-5p for simple@optimus.ietf.org; Fri, 27 Jun 2003 11:47:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04827 for ; Fri, 27 Jun 2003 11:46:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VvR0-0003zD-00 for simple@ietf.org; Fri, 27 Jun 2003 11:46:46 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19VvQj-0003z2-00 for simple@ietf.org; Fri, 27 Jun 2003 11:46:30 -0400 Received: from cs.columbia.edu (dyn-wireless-246-119.dyn.columbia.edu [160.39.246.119]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5RFjeA4003914 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Jun 2003 11:45:40 -0400 (EDT) Message-ID: <3EFC669D.7010708@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - References: <2038BCC78B1AD641891A0D1AE133DBB701796E6C@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796E6C@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 27 Jun 2003 11:45:33 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Let me get things clear here: when the element is > present, its only referring to the information in the . The > rest of the tuple presence information still belongs to the > presentity. What I'm trying to say here is that the presentity is not > publishing presence info about another presentity. Is my > interpretation right? Let me try to answer this indirectly. One view of "what is a tuple" is that it is effectively an extended advertisement of my reachability. I can choose to publish a single Contact and have that contact figure out what is the best person/device/service to reach or I can publish a wider range of devices, services and interfaces and leave more of the decision to the watcher. I think there's value in both approaches; a single presentity may even choose to publish different views to different watchers. Thus, just like my assistant can register under my AOR and receive my phone calls in my absence (subject to authorization, policy, etc.), I should be able to export this information to the watcher if I prefer to give the watcher more information and control. Thus, consider my assistant as an 'extension' of my presentity. This is not fundamentally different than me including my secretary's phone number in my vCard or listing it as a device tuple. The element simply makes a property of that tuple explicit and thus allows better choices. I would imagine that this tuple would have a low q value, unless this is really the first Contact that I want a watcher to communicate with. It is up to the composer and the rules it has to limit the publication of this information; this is no different than limiting the exposure of my cellphone (or somebody else's cellphone...). Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 1 13:48:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08609 for ; Tue, 1 Jul 2003 13:48:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIXjT05494 for simple-archive@odin.ietf.org; Fri, 27 Jun 2003 14:33:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy2b-0001QX-Td for simple-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:33:45 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10940; Fri, 27 Jun 2003 14:33:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy24-00017E-Li; Fri, 27 Jun 2003 14:33:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vvbe-0006YV-BM for simple@optimus.ietf.org; Fri, 27 Jun 2003 11:57:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05361 for ; Fri, 27 Jun 2003 11:57:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vvb3-00047k-00 for simple@ietf.org; Fri, 27 Jun 2003 11:57:09 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.59.238] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19Vvan-00045u-00 for simple@ietf.org; Fri, 27 Jun 2003 11:56:53 -0400 Received: from cs.columbia.edu (dyn-wireless-246-119.dyn.columbia.edu [160.39.246.119]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5RFrLJ7001149 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Jun 2003 11:53:21 -0400 (EDT) Message-ID: <3EFC686B.1030305@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] comments on rpids-01 , References: <2038BCC78B1AD641891A0D1AE133DBB701796E69@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796E69@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 27 Jun 2003 11:53:15 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Not all elements will be appropriate for all types of services or devices. To pick on something outside RPIDS 01: it is unclear that geoloc or media would be appropriate for all kinds of tuples. As noted earlier, the indication does not intend to provide a clue as to whether the device is OPEN or CLOSED - we have this already. It provides additional hints to the watcher as to which device is more likely to be "staffed". Combinations of with both OPEN and CLOSED are quite plausible, I think. My current preference is to have only . For privacy, an empty element meaning indicates device has been idle (unused) for some unspecified time. I think this makes the logic a bit simpler. hisham.khartabil@nokia.com wrote: > I think the current definition of is to represent my > current interaction with a device (if I'm using the device currently > or not). Something like . I think this is the wrong > definition. The examples in the I-D describing the element certainly > elude to this. > > Most of the time, my mobile phone sits by my side. It can be idle for > hours and without any activity. This does not give a true > representation of my ability to receive calls on it. This is > different from me being away from my PC for hours without any > activity. In this case, a true representation of my ability to > receive calls on it is possible. > > What I believe the element should represent is user's > ability to answer calls (or receive any other media, or whatever) on > that device. One could argue that OPEN and CLOSED are sufficient > enough for this. Else, you need an element like > (a better name is needed here, but > couldn't think of one from the top of my head). > > Another issue with that I would like to bring up: It only > talks about a device. I would like to know the meaning on this > element when a tuple does not represent a device (a different > . > > Regards, Hisham > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 1 13:48:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08729 for ; Tue, 1 Jul 2003 13:48:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RINef21958 for simple-archive@odin.ietf.org; Fri, 27 Jun 2003 14:23:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vxso-0005hp-2R for simple-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:23:38 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09518; Fri, 27 Jun 2003 14:23:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VxrQ-0004p1-JH; Fri, 27 Jun 2003 14:22:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VuO1-0002P9-8v for simple@optimus.ietf.org; Fri, 27 Jun 2003 10:40:07 -0400 Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00707 for ; Fri, 27 Jun 2003 10:28:22 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5REP9922511 for ; Fri, 27 Jun 2003 17:25:09 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 27 Jun 2003 17:25:09 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 27 Jun 2003 17:25:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] comments on rpids-01 - Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796E6C@esebe019.ntc.nokia.com> Thread-Topic: [Simple] comments on rpids-01 - Thread-Index: AcM8XFXhh0pBUxQyTYe3aIaTKEq+xAAW0FIQ To: , Cc: X-OriginalArrivalTime: 27 Jun 2003 14:25:09.0050 (UTC) FILETIME=[E97D71A0:01C33CB7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 27 Jun 2003 17:25:08 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Let me get things clear here: when the element is = present, its only referring to the information in the . The = rest of the tuple presence information still belongs to the presentity. = What I'm trying to say here is that the presentity is not publishing = presence info about another presentity. Is my interpretation right? Regards, Hisham > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, June 27, 2003 6:10 AM > To: Peterson, Jon > Cc: Simpletons (E-mail) > Subject: Re: [Simple] comments on rpids-01 - >=20 >=20 > Peterson, Jon wrote: >=20 > > I'm unsure about because it encourages=20 > presentities to > > publish their presence under another entity's AoR (and for=20 > compositors to > > accept such publications) - given that this would include=20 > family members, > > associates, and the like, it seems to give rise to fairly=20 > complicated > > authorization logic in compositors. I wonder, though, if=20 > there aren't other > > solutions to this problem - like, giving out a group alias=20 > as your AoR, or > > something, that includes any other persons whose presence=20 > is 'equivalent' to > > yours as necessary. It seems weird to include presence=20 > information in a > > document that doesn't below to the resource=20 > identified by the > > 'entity' attribute of the document. Most=20 > importantly, I'm not > > sure that this is very backwards-compatible with baseline=20 > PIDF - if you > > don't understand the element, you might be=20 > unpleasantly > > surprised when you IM one of the contact addresses in the associated > > . I agree that something that provides this=20 > capability (associating > > presence from one party with that of another) would be=20 > useful, but I'm not > > sure that it should be done as a PIDF extension. >=20 > The surprise can occur even with the AOR, if you suddenly reach the=20 > secretary. This is quite common in any system that has any form of=20 > redirection of where phones are sometimes picked up by people=20 > other than=20 > the party which advertised that number. Thus, this doesn't=20 > seem to add=20 > any more confusion for 'naive' watchers than hiding the=20 > secretary behind=20 > the same AOR. If anything, the second AOR, with a different name, may=20 > provide a better clue to the non-RPIDS watcher that this is a=20 > different=20 > person, more so than just having the proxy route the MESSAGE=20 > to another=20 > person automatically. >=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 exim@www1.ietf.org Tue Jul 1 13:48:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08854 for ; Tue, 1 Jul 2003 13:48:51 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RINgo22000 for simple-archive@odin.ietf.org; Fri, 27 Jun 2003 14:23:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vxsp-0005ht-73 for simple-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:23:39 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09522; Fri, 27 Jun 2003 14:23:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VxrR-0004p9-0O; Fri, 27 Jun 2003 14:22:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VuOV-0002P9-DQ for simple@optimus.ietf.org; Fri, 27 Jun 2003 10:40:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28103 for ; Fri, 27 Jun 2003 10:02:24 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vto1-0002pe-00 for simple@ietf.org; Fri, 27 Jun 2003 10:02:25 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19Vtnq-0002pO-00 for simple@ietf.org; Fri, 27 Jun 2003 10:02:14 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5RE1Wa26659 for ; Fri, 27 Jun 2003 17:01:32 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 27 Jun 2003 17:01:31 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 27 Jun 2003 17:01:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] comments on rpids-01 , Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796E69@esebe019.ntc.nokia.com> Thread-Topic: [Simple] comments on rpids-01 , Thread-Index: AcM8WGO5EeBb7yrpTRC4uM+FwCvxTQAWVQcQ To: , Cc: X-OriginalArrivalTime: 27 Jun 2003 14:01:31.0904 (UTC) FILETIME=[9CCE2000:01C33CB4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 27 Jun 2003 17:01:31 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I think the current definition of is to represent my current = interaction with a device (if I'm using the device currently or not). = Something like . I think this is the wrong definition. The = examples in the I-D describing the element certainly elude to this. Most of the time, my mobile phone sits by my side. It can be idle for = hours and without any activity. This does not give a true representation = of my ability to receive calls on it. This is different from me being = away from my PC for hours without any activity. In this case, a true = representation of my ability to receive calls on it is possible. What I believe the element should represent is user's ability = to answer calls (or receive any other media, or whatever) on that = device. One could argue that OPEN and CLOSED are sufficient enough for = this. Else, you need an element like (a = better name is needed here, but couldn't think of one from the top of my = head). Another issue with that I would like to bring up: It only = talks about a device. I would like to know the meaning on this element = when a tuple does not represent a device (a different . Regards, Hisham > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, June 27, 2003 5:56 AM > To: Peterson, Jon > Cc: Simpletons (E-mail) > Subject: Re: [Simple] comments on rpids-01 , >=20 >=20 > Peterson, Jon wrote: >=20 >=20 > > Though I like , I'm less sure about .=20 > In response to > > the motivation given in 6.2, if a computer doesn't have a=20 > keyboard or mouse, > > it should be publishing a state of CLOSED; we don't need=20 > to > > supplement this. Similarly, if I see the word 'active' in=20 > presence, I would > > assume that the presentity is around (and thus perhaps=20 > ready to communicate) > > - perhaps not what I should assume if they are on the=20 > phone. If someone is > > totally idle (at a threshold judged by the watcher), they=20 > could derivately > > be considered inactive - that's the quality that we really=20 > need here; the > > only difference that introduces, I think, is=20 > that the presentity > > rather than the watcher makes the judgment call of=20 > activeness based on that > > idleness timer. But then again, the presentity still always=20 > gets to choose > > the threshold at which it starts including an =20 > element. Finally, > > commercial instant messaging systems don't tell me, for=20 > example, that a > > presentity is currently conversing with two other IMers (which would > > presumably be the corollary of for IM), so I'm=20 > not sure I see > > this sort of activity as being something we immediately need for our > > short-term goals. >=20 > The idea is to provide additional, automatically derivable,=20 > indication=20 > of liveness. Current systems (like Windows Messenger) change the=20 > activity indication to 'idle' if you don't use your keyboard=20 > or mouse.=20 > However, that's at best a guess (you might just be talking to a=20 > colleague in your room, so you're hardly "idle"), and overloads an=20 > indicator with two meanings that are not orthogonal. >=20 > A device that is 'idle' can be either OPEN or CLOSED - it=20 > just provides=20 > an additional hint to the watcher as to why nobody writes back when I=20 > type. (MS Messenger puts up some kind of message saying that=20 > the other=20 > side may not respond, I think.) >=20 > If I recall the discussion correctly, was seen as a "less=20 > revealing" form of . Thus, they share the same motivation,=20 > but allows a presentity to indicate lack of=20 > activity without=20 > revealing how long I've not been using the device. >=20 > Maybe a simpler, less confusing, way of coding this is to simply allow > to be empty, indicating that I am indeed 'idle',=20 > but I won't=20 > tell you for how long. Would that be clearer? >=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 exim@www1.ietf.org Tue Jul 1 13:48:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08731 for ; Tue, 1 Jul 2003 13:48:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIU6300946 for simple-archive@odin.ietf.org; Fri, 27 Jun 2003 14:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vxyz-0000Ck-Lv for simple-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:30:01 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10339; Fri, 27 Jun 2003 14:29:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VxxK-000830-Ay; Fri, 27 Jun 2003 14:28:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VvDy-0005Hn-25 for simple@optimus.ietf.org; Fri, 27 Jun 2003 11:33:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04356 for ; Fri, 27 Jun 2003 11:33:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VvDx-0003qz-00 for simple@ietf.org; Fri, 27 Jun 2003 11:33:17 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19VvDh-0003qZ-00 for simple@ietf.org; Fri, 27 Jun 2003 11:33:01 -0400 Received: from cs.columbia.edu (dyn-wireless-246-119.dyn.columbia.edu [160.39.246.119]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5RFWTm4019600 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Jun 2003 11:32:30 -0400 (EDT) Message-ID: <3EFC6387.2060205@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Rosen, Brian'" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C01@stntexch2.va.neustar.com> In-Reply-To: <0449D80A0E9B614A83FA9031B07E8D3B257C01@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 27 Jun 2003 11:32:23 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Peterson, Jon wrote: > Well, I think it's pretty unlikely that, say, geoloc will be able to be > transformed into a anytime soon, and even setting cell-phone > profiles is user entry. It seems to me that these have a realistic > dependency on user provisioning. In addition to the real-life BlueTooth example I gave in an earlier note, the transformation from geoloc into placetype isn't all that difficult, at least for the common cases. All I need is a trivial mapping that says "if geoloc is within polygon X, I'm at home; if in polygon Y (covering the area between 110 and 120th Street and Broadway and Amsterdam), I'm at my office; otherwise, default to public". This doesn't deal with all cases, such as visiting other places, but it will be correct at least 90% of the time, with no central database, new protocols or anything else beyond basic geoloc. > > But my argument above was really that the specific use for which > and were defined in the current document is irrelevant to > automatons - basically, that if all these indicators tell you is what sorts > of communications with the presentity might be appropriate, automatons > aren't going to be able to help you much with that. So sure, if there were > registered values, an automaton might understand them, but then what would > it do, exactly? Probably just render them to you, so you can see what kind > of communication is appropriate. Same thing it would do with a note. We may have somewhat different models of end system behavior. In my model, end systems (watchers) can also have processing logic. (In addition, end systems don't need to be PDAs or PCs running an IM application with smiley buttons.) In that model of end system intelligence, structured information is far more useful than random notes in . For example, my end system logic can prioritize tuples that offer private communications, they can assign suitable icons that allow me to quickly distinguish home from office addresses or they can include appropriate warnings before I make a call. All of these require structured information. In addition, when publishing presence information, this allows to construct easy rules. For example: "only publish office contacts to my co-workers; only publish 'home' contacts to my friends list". Again, a isn't going to do this reliably. > > If we change the motivation for these elements, we might draw a different > conclusion, of course. I'm only speaking to the current motivation in the > draft, not any other usage of these elements. I've added some additional motivational wording for and . _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 1 17:41:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17279; Tue, 1 Jul 2003 17:41:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XSsE-00010y-00; Tue, 01 Jul 2003 17:41:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XSsD-00010v-00; Tue, 01 Jul 2003 17:41:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XSs1-0001BG-RK; Tue, 01 Jul 2003 17:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XSrj-0001An-Jx for simple@optimus.ietf.org; Tue, 01 Jul 2003 17:40:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17249 for ; Tue, 1 Jul 2003 17:40:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XSrh-00010Y-00 for simple@ietf.org; Tue, 01 Jul 2003 17:40:41 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19XSrg-000100-00 for simple@ietf.org; Tue, 01 Jul 2003 17:40:40 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h61Le0O0028332; Tue, 1 Jul 2003 14:40:01 -0700 (PDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-140.cisco.com [64.100.229.140]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFO94799; Tue, 1 Jul 2003 14:39:59 -0700 (PDT) Message-Id: <4.3.2.7.2.20030701172537.00b39cb0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Rosen, Brian" From: Michael Hammer Subject: RE: [Simple] comments on rpids-01 , Cc: "'Henning Schulzrinne'" , hisham.khartabil@nokia.com, Dirk.Trossen@nokia.com, simple@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF070B5B7E@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_30301140==_.ALT" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 01 Jul 2003 17:39:58 -0400 --=====================_30301140==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:10 AM 7/1/2003 -0400, Rosen, Brian wrote: >then you might see closed on the phone, >but you might have a tough time with what you do when you momentarily >drop out of range. I think it would be great if they told you what >they knew, but I'm not holding my breath. > >I think is a valuable piece of information, especially >for an aggregator. Sometimes they don't know. Unless the cell phone has a need to communicate with the network or vice-versa, it is not likely to waste battery power to say "I'm still here!" The network pages (searches) for the phone when it needs to. The phone re-registers when it detects it has moved into a new cell area beyond where it was previously registered. If the phone stays in the same registration area, then the phone won't necessarily send a message unless an application requires it to. If the phone loses radio coverage, then it can't send a message, could be turned off (CLOSED), but who would know unless the network regularly pings it and gets no response. Also, note that some systems de-register users when they shutdown, whereas others may simply overwrite oldest registrations as needed. I see the value in "idlesince". But, would you indicate CLOSED if you lose radio contact (network pings and gets no response), or would you keep the last idlesince value? Or is that network policy? Mike --=====================_30301140==_.ALT Content-Type: text/html; charset="us-ascii" At 08:10 AM 7/1/2003 -0400, Rosen, Brian wrote:
then you might see closed on the phone,
but you might have a tough time with what you do when you momentarily
drop out of range.  I think it would be great if they told you what
they knew, but I'm not holding my breath.

I think <idlesince> is a valuable piece of information, especially
for an aggregator.

Sometimes they don't know.

Unless the cell phone has a need to communicate with the network or vice-versa, it is not likely to waste battery power to say "I'm still here!"  The network pages (searches) for the phone when it needs to.  The phone re-registers when it detects it has moved into a new cell area beyond where it was previously registered.

If the phone stays in the same registration area, then the phone won't necessarily send a message unless an application requires it to.

If the phone loses radio coverage, then it can't send a message, could be turned off (CLOSED), but who would know unless the network regularly pings it and gets no response.  Also, note that some systems de-register users when they shutdown, whereas others may simply overwrite oldest registrations as needed.

I see the value in "idlesince".  But, would you indicate CLOSED if you lose radio contact (network pings and gets no response), or would you keep the last idlesince value?  Or is that network policy?

Mike
 --=====================_30301140==_.ALT-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 1 17:41:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17297 for ; Tue, 1 Jul 2003 17:41:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XSsH-0001C1-AA for simple-archive@odin.ietf.org; Tue, 01 Jul 2003 17:41:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h61LfH4x004581 for simple-archive@odin.ietf.org; Tue, 1 Jul 2003 17:41:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XSsH-0001Bo-7L for simple-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 17:41:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17279; Tue, 1 Jul 2003 17:41:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XSsE-00010y-00; Tue, 01 Jul 2003 17:41:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XSsD-00010v-00; Tue, 01 Jul 2003 17:41:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XSs1-0001BG-RK; Tue, 01 Jul 2003 17:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XSrj-0001An-Jx for simple@optimus.ietf.org; Tue, 01 Jul 2003 17:40:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17249 for ; Tue, 1 Jul 2003 17:40:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XSrh-00010Y-00 for simple@ietf.org; Tue, 01 Jul 2003 17:40:41 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19XSrg-000100-00 for simple@ietf.org; Tue, 01 Jul 2003 17:40:40 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h61Le0O0028332; Tue, 1 Jul 2003 14:40:01 -0700 (PDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-140.cisco.com [64.100.229.140]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFO94799; Tue, 1 Jul 2003 14:39:59 -0700 (PDT) Message-Id: <4.3.2.7.2.20030701172537.00b39cb0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Rosen, Brian" From: Michael Hammer Subject: RE: [Simple] comments on rpids-01 , Cc: "'Henning Schulzrinne'" , hisham.khartabil@nokia.com, Dirk.Trossen@nokia.com, simple@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF070B5B7E@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_30301140==_.ALT" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 01 Jul 2003 17:39:58 -0400 --=====================_30301140==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:10 AM 7/1/2003 -0400, Rosen, Brian wrote: >then you might see closed on the phone, >but you might have a tough time with what you do when you momentarily >drop out of range. I think it would be great if they told you what >they knew, but I'm not holding my breath. > >I think is a valuable piece of information, especially >for an aggregator. Sometimes they don't know. Unless the cell phone has a need to communicate with the network or vice-versa, it is not likely to waste battery power to say "I'm still here!" The network pages (searches) for the phone when it needs to. The phone re-registers when it detects it has moved into a new cell area beyond where it was previously registered. If the phone stays in the same registration area, then the phone won't necessarily send a message unless an application requires it to. If the phone loses radio coverage, then it can't send a message, could be turned off (CLOSED), but who would know unless the network regularly pings it and gets no response. Also, note that some systems de-register users when they shutdown, whereas others may simply overwrite oldest registrations as needed. I see the value in "idlesince". But, would you indicate CLOSED if you lose radio contact (network pings and gets no response), or would you keep the last idlesince value? Or is that network policy? Mike --=====================_30301140==_.ALT Content-Type: text/html; charset="us-ascii" At 08:10 AM 7/1/2003 -0400, Rosen, Brian wrote:
then you might see closed on the phone,
but you might have a tough time with what you do when you momentarily
drop out of range.  I think it would be great if they told you what
they knew, but I'm not holding my breath.

I think <idlesince> is a valuable piece of information, especially
for an aggregator.

Sometimes they don't know.

Unless the cell phone has a need to communicate with the network or vice-versa, it is not likely to waste battery power to say "I'm still here!"  The network pages (searches) for the phone when it needs to.  The phone re-registers when it detects it has moved into a new cell area beyond where it was previously registered.

If the phone stays in the same registration area, then the phone won't necessarily send a message unless an application requires it to.

If the phone loses radio coverage, then it can't send a message, could be turned off (CLOSED), but who would know unless the network regularly pings it and gets no response.  Also, note that some systems de-register users when they shutdown, whereas others may simply overwrite oldest registrations as needed.

I see the value in "idlesince".  But, would you indicate CLOSED if you lose radio contact (network pings and gets no response), or would you keep the last idlesince value?  Or is that network policy?

Mike
 --=====================_30301140==_.ALT-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 2 01:41:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28475; Wed, 2 Jul 2003 01:41:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XaMY-0005xI-00; Wed, 02 Jul 2003 01:41:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XaMX-0005xF-00; Wed, 02 Jul 2003 01:41:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XaMW-0006tb-5J; Wed, 02 Jul 2003 01:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XaLf-0006t8-VF for simple@optimus.ietf.org; Wed, 02 Jul 2003 01:40:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28464 for ; Wed, 2 Jul 2003 01:40:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XaLc-0005wk-00 for simple@ietf.org; Wed, 02 Jul 2003 01:40:04 -0400 Received: from fgwmail7.fujitsu.co.jp ([192.51.44.37]) by ietf-mx with esmtp (Exim 4.12) id 19XaLb-0005wL-00 for simple@ietf.org; Wed, 02 Jul 2003 01:40:04 -0400 Received: from m1.gw.fujitsu.co.jp ([10.0.50.71]) by fgwmail7.fujitsu.co.jp (8.12.9/Fujitsu Gateway) id h625dWM2004164 for ; Wed, 2 Jul 2003 14:39:32 +0900 (envelope-from iwakawa@flab.fujitsu.co.jp) Received: from s4.gw.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.12.9/Fujitsu Domain Master) id h625dVd7014894 for ; Wed, 2 Jul 2003 14:39:31 +0900 (envelope-from iwakawa@flab.fujitsu.co.jp) Received: from dm.akashi.flab.fujitsu.co.jp (dm.akashi.flab.fujitsu.co.jp [10.254.200.11]) by s4.gw.fujitsu.co.jp (8.12.9) id h625dVoh015493 for ; Wed, 2 Jul 2003 14:39:31 +0900 (envelope-from iwakawa@flab.fujitsu.co.jp) Received: from dm.akashi.flab.fujitsu.co.jp by dm.akashi.flab.fujitsu.co.jp (8.9.3p2/3.7W-020129-Fujitsu Labs. Akashi Domain Mail Master) id OAA07299; Wed, 2 Jul 2003 14:39:30 +0900 (JST) Received: from kmailserv.akashi.flab.fujitsu.co.jp ([10.254.200.15]) by dm.akashi.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2003070214393019307 for ; Wed, 02 Jul 2003 14:39:30 +0900 Received: from KATSUO.flab.fujitsu.co.jp (katsuo.pssys.flab.fujitsu.co.jp [10.254.211.38]) by kmailserv.akashi.flab.fujitsu.co.jp (8.11.6+Sun/8.11.6) with SMTP id h625dU028517 for ; Wed, 2 Jul 2003 14:39:30 +0900 (JST) Message-Id: <200307020539.AA00114@KATSUO.flab.fujitsu.co.jp> From: Akinori Iwakawa To: simple@ietf.org MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.13 Content-Type: text/plain; charset=us-ascii Subject: [Simple] Reason-Phrase of 423 error Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 02 Jul 2003 14:39:37 +0900 Hello Folks, Response status code 423 has three different suggested Reason Phrase as summarized below. Does SIP standard specification suggest different Reason Phrase for SUBSCRIBE request? Reason-Phrase Method RFC Section comments ---------------------------------------------------------------------- Interval Too Brief REGISTER 3261 10.3 Registration expiration Interval too small SUBSCRIBE 3265 3.1.6.1 Initial subscription expiration Subscription Too Brief SUBSCRIBE 3265 3.1.6.4 Refreshing subscription expiration It seems "Interval Too Brief" is suggested even for specifying too brief subscription expiration. Is that correct? Regards Akinori Iwakawa Web&IP Service Architecture Labs. FUJITSU LABORATORIES LTD. iwakawa@flab.fujitsu.co.jp _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 2 01:41:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28518 for ; Wed, 2 Jul 2003 01:41:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XaMc-0006v6-2Y for simple-archive@odin.ietf.org; Wed, 02 Jul 2003 01:41:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h625f6Jk026596 for simple-archive@odin.ietf.org; Wed, 2 Jul 2003 01:41:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XaMb-0006ut-Ve for simple-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 01:41:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28475; Wed, 2 Jul 2003 01:41:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XaMY-0005xI-00; Wed, 02 Jul 2003 01:41:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XaMX-0005xF-00; Wed, 02 Jul 2003 01:41:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XaMW-0006tb-5J; Wed, 02 Jul 2003 01:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XaLf-0006t8-VF for simple@optimus.ietf.org; Wed, 02 Jul 2003 01:40:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28464 for ; Wed, 2 Jul 2003 01:40:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XaLc-0005wk-00 for simple@ietf.org; Wed, 02 Jul 2003 01:40:04 -0400 Received: from fgwmail7.fujitsu.co.jp ([192.51.44.37]) by ietf-mx with esmtp (Exim 4.12) id 19XaLb-0005wL-00 for simple@ietf.org; Wed, 02 Jul 2003 01:40:04 -0400 Received: from m1.gw.fujitsu.co.jp ([10.0.50.71]) by fgwmail7.fujitsu.co.jp (8.12.9/Fujitsu Gateway) id h625dWM2004164 for ; Wed, 2 Jul 2003 14:39:32 +0900 (envelope-from iwakawa@flab.fujitsu.co.jp) Received: from s4.gw.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.12.9/Fujitsu Domain Master) id h625dVd7014894 for ; Wed, 2 Jul 2003 14:39:31 +0900 (envelope-from iwakawa@flab.fujitsu.co.jp) Received: from dm.akashi.flab.fujitsu.co.jp (dm.akashi.flab.fujitsu.co.jp [10.254.200.11]) by s4.gw.fujitsu.co.jp (8.12.9) id h625dVoh015493 for ; Wed, 2 Jul 2003 14:39:31 +0900 (envelope-from iwakawa@flab.fujitsu.co.jp) Received: from dm.akashi.flab.fujitsu.co.jp by dm.akashi.flab.fujitsu.co.jp (8.9.3p2/3.7W-020129-Fujitsu Labs. Akashi Domain Mail Master) id OAA07299; Wed, 2 Jul 2003 14:39:30 +0900 (JST) Received: from kmailserv.akashi.flab.fujitsu.co.jp ([10.254.200.15]) by dm.akashi.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2003070214393019307 for ; Wed, 02 Jul 2003 14:39:30 +0900 Received: from KATSUO.flab.fujitsu.co.jp (katsuo.pssys.flab.fujitsu.co.jp [10.254.211.38]) by kmailserv.akashi.flab.fujitsu.co.jp (8.11.6+Sun/8.11.6) with SMTP id h625dU028517 for ; Wed, 2 Jul 2003 14:39:30 +0900 (JST) Message-Id: <200307020539.AA00114@KATSUO.flab.fujitsu.co.jp> From: Akinori Iwakawa To: simple@ietf.org MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.13 Content-Type: text/plain; charset=us-ascii Subject: [Simple] Reason-Phrase of 423 error Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 02 Jul 2003 14:39:37 +0900 Hello Folks, Response status code 423 has three different suggested Reason Phrase as summarized below. Does SIP standard specification suggest different Reason Phrase for SUBSCRIBE request? Reason-Phrase Method RFC Section comments ---------------------------------------------------------------------- Interval Too Brief REGISTER 3261 10.3 Registration expiration Interval too small SUBSCRIBE 3265 3.1.6.1 Initial subscription expiration Subscription Too Brief SUBSCRIBE 3265 3.1.6.4 Refreshing subscription expiration It seems "Interval Too Brief" is suggested even for specifying too brief subscription expiration. Is that correct? Regards Akinori Iwakawa Web&IP Service Architecture Labs. FUJITSU LABORATORIES LTD. iwakawa@flab.fujitsu.co.jp _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 2 02:54:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26215; Wed, 2 Jul 2003 02:54:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XbVE-0006cR-00; Wed, 02 Jul 2003 02:54:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XbVE-0006cO-00; Wed, 02 Jul 2003 02:54:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XbVC-0001Lb-6L; Wed, 02 Jul 2003 02:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XbUW-0001L0-6v for simple@optimus.ietf.org; Wed, 02 Jul 2003 02:53:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26189 for ; Wed, 2 Jul 2003 02:53:16 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XbUS-0006bp-00 for simple@ietf.org; Wed, 02 Jul 2003 02:53:16 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19XbUR-0006bj-00 for simple@ietf.org; Wed, 02 Jul 2003 02:53:15 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h626rF901258 for ; Wed, 2 Jul 2003 09:53:15 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 2 Jul 2003 09:53:09 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 2 Jul 2003 09:53:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] Reason-Phrase of 423 error Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796E88@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Reason-Phrase of 423 error Thread-Index: AcNAXJEvUVqjhnBzRFqT5hRXF4ZngAACYXmg To: , X-OriginalArrivalTime: 02 Jul 2003 06:53:07.0222 (UTC) FILETIME=[97AFAB60:01C34066] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 2 Jul 2003 09:53:06 +0300 Content-Transfer-Encoding: quoted-printable 423 tells the initiator of the request that the expiration value it is = trying to register or subscribe with is too brief and a higher number is = required. Reason phrase has no meaning beyond an indication to the user = of the reasons behind the error response. You could send something like the following if you wish: 423 Your Expiration value in the request is to way too small SIP/2.0 :) Hisham > -----Original Message----- > From: ext Akinori Iwakawa [mailto:iwakawa@flab.fujitsu.co.jp] > Sent: Wednesday, July 02, 2003 8:40 AM > To: simple@ietf.org > Subject: [Simple] Reason-Phrase of 423 error >=20 >=20 > Hello Folks, >=20 > Response status code 423 has three different suggested=20 > Reason Phrase as summarized below.=20 > Does SIP standard specification suggest different Reason=20 > Phrase for SUBSCRIBE request? >=20 > Reason-Phrase Method RFC Section comments > =20 > ---------------------------------------------------------------------- > Interval Too Brief REGISTER 3261 10.3 =20 > Registration expiration > Interval too small SUBSCRIBE 3265 3.1.6.1 =20 > Initial subscription expiration > Subscription Too Brief SUBSCRIBE 3265 3.1.6.4 =20 > Refreshing subscription expiration >=20 > It seems "Interval Too Brief" is suggested even for=20 > specifying too brief subscription=20 > expiration. Is that correct? >=20 > Regards >=20 > Akinori Iwakawa =20 > Web&IP Service Architecture Labs. > FUJITSU LABORATORIES LTD. > iwakawa@flab.fujitsu.co.jp >=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 exim@www1.ietf.org Wed Jul 2 02:54:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26252 for ; Wed, 2 Jul 2003 02:54:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XbVL-0001Ot-5m for simple-archive@odin.ietf.org; Wed, 02 Jul 2003 02:54:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h626sBxG005265 for simple-archive@odin.ietf.org; Wed, 2 Jul 2003 02:54:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XbVI-0001Mq-SW for simple-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 02:54:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26215; Wed, 2 Jul 2003 02:54:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XbVE-0006cR-00; Wed, 02 Jul 2003 02:54:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XbVE-0006cO-00; Wed, 02 Jul 2003 02:54:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XbVC-0001Lb-6L; Wed, 02 Jul 2003 02:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XbUW-0001L0-6v for simple@optimus.ietf.org; Wed, 02 Jul 2003 02:53:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26189 for ; Wed, 2 Jul 2003 02:53:16 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XbUS-0006bp-00 for simple@ietf.org; Wed, 02 Jul 2003 02:53:16 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19XbUR-0006bj-00 for simple@ietf.org; Wed, 02 Jul 2003 02:53:15 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h626rF901258 for ; Wed, 2 Jul 2003 09:53:15 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 2 Jul 2003 09:53:09 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 2 Jul 2003 09:53:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] Reason-Phrase of 423 error Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796E88@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Reason-Phrase of 423 error Thread-Index: AcNAXJEvUVqjhnBzRFqT5hRXF4ZngAACYXmg To: , X-OriginalArrivalTime: 02 Jul 2003 06:53:07.0222 (UTC) FILETIME=[97AFAB60:01C34066] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 2 Jul 2003 09:53:06 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 423 tells the initiator of the request that the expiration value it is = trying to register or subscribe with is too brief and a higher number is = required. Reason phrase has no meaning beyond an indication to the user = of the reasons behind the error response. You could send something like the following if you wish: 423 Your Expiration value in the request is to way too small SIP/2.0 :) Hisham > -----Original Message----- > From: ext Akinori Iwakawa [mailto:iwakawa@flab.fujitsu.co.jp] > Sent: Wednesday, July 02, 2003 8:40 AM > To: simple@ietf.org > Subject: [Simple] Reason-Phrase of 423 error >=20 >=20 > Hello Folks, >=20 > Response status code 423 has three different suggested=20 > Reason Phrase as summarized below.=20 > Does SIP standard specification suggest different Reason=20 > Phrase for SUBSCRIBE request? >=20 > Reason-Phrase Method RFC Section comments > =20 > ---------------------------------------------------------------------- > Interval Too Brief REGISTER 3261 10.3 =20 > Registration expiration > Interval too small SUBSCRIBE 3265 3.1.6.1 =20 > Initial subscription expiration > Subscription Too Brief SUBSCRIBE 3265 3.1.6.4 =20 > Refreshing subscription expiration >=20 > It seems "Interval Too Brief" is suggested even for=20 > specifying too brief subscription=20 > expiration. Is that correct? >=20 > Regards >=20 > Akinori Iwakawa =20 > Web&IP Service Architecture Labs. > FUJITSU LABORATORIES LTD. > iwakawa@flab.fujitsu.co.jp >=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-admin@ietf.org Wed Jul 2 05:55:43 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00066; Wed, 2 Jul 2003 05:55:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XeL1-0000El-00; Wed, 02 Jul 2003 05:55:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XeL1-0000Ei-00; Wed, 02 Jul 2003 05:55:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XeKM-0008VA-1C; Wed, 02 Jul 2003 05:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XeK0-0008UW-Si for simple@optimus.ietf.org; Wed, 02 Jul 2003 05:54:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00057 for ; Wed, 2 Jul 2003 05:54:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XeJx-0000Dw-00 for simple@ietf.org; Wed, 02 Jul 2003 05:54:37 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19XeJw-0000Dt-00 for simple@ietf.org; Wed, 02 Jul 2003 05:54:36 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for [132.151.6.1]) with SMTP; Wed, 2 Jul 2003 10:57:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3407F.EF7A0462" Subject: RE: [Simple] comments on rpids-01 , Message-ID: <45730E094814E44488F789C1CDED27AE0219B012@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] comments on rpids-01 , Thread-Index: AcNAGX+gGn1YIS9YRPaa3WXt5uH0AgAZaSBQ From: "Chris Boulton" To: "Michael Hammer" , "Rosen, Brian" Cc: "Henning Schulzrinne" , , , Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 2 Jul 2003 10:54:31 +0100 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3407F.EF7A0462 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <> =20 -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com]=20 Sent: 01 July 2003 22:40 To: Rosen, Brian Cc: 'Henning Schulzrinne'; hisham.khartabil@nokia.com; Dirk.Trossen@nokia.com; simple@ietf.org Subject: RE: [Simple] comments on rpids-01 , =20 At 08:10 AM 7/1/2003 -0400, Rosen, Brian wrote: then you might see closed on the phone, but you might have a tough time with what you do when you momentarily drop out of range. I think it would be great if they told you what they knew, but I'm not holding my breath. I think is a valuable piece of information, especially for an aggregator. Sometimes they don't know. Unless the cell phone has a need to communicate with the network or vice-versa, it is not likely to waste battery power to say "I'm still here!" The network pages (searches) for the phone when it needs to. The phone re-registers when it detects it has moved into a new cell area beyond where it was previously registered. If the phone stays in the same registration area, then the phone won't necessarily send a message unless an application requires it to. If the phone loses radio coverage, then it can't send a message, could be turned off (CLOSED), but who would know unless the network regularly pings it and gets no response. Also, note that some systems de-register users when they shutdown, whereas others may simply overwrite oldest registrations as needed. I see the value in "idlesince". But, would you indicate CLOSED if you lose radio contact (network pings and gets no response), or would you keep the last idlesince value? Or is that network policy? =20 [Chris Boulton] I also see value in "idlesince" ;-). I'm not sure you could use it's value in conjunction with loss of radio contact. What happens when contact is restored BUT you still do not use your phone for a period of time? I agree with Brian in that for non-rich presence systems the status will never be closed due to voicemail policy.=20 Mike ------_=_NextPart_001_01C3407F.EF7A0462 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<<in-line>>

 

-----Original Message-----
From: Michael Hammer [mailto:mhammer@cisco.com]
Sent: 01 July 2003 = 22:40
To: Rosen, Brian
Cc: 'Henning = Schulzrinne'; hisham.khartabil@nokia.com; Dirk.Trossen@nokia.com; simple@ietf.org
Subject: RE: [Simple] = comments on rpids-01 <activity>, <idlesince>

 

At 08:10 AM 7/1/2003 -0400, Rosen, Brian wrote:

then you might see closed on the phone,
but you might have a tough time with what you do when you = momentarily
drop out of range.  I think it would be great if they told you = what
they knew, but I'm not holding my breath.

I think <idlesince> is a valuable piece of information, = especially
for an aggregator.


Sometimes they don't know.

Unless the cell phone has a need to communicate with the network or = vice-versa, it is not likely to waste battery power to say "I'm still here!"  The network pages (searches) for the phone when it = needs to.  The phone re-registers when it detects it has moved into a new = cell area beyond where it was previously registered.

If the phone stays in the same registration area, then the phone won't necessarily send a message unless an application requires it to.

If the phone loses radio coverage, then it can't send a message, could = be turned off (CLOSED), but who would know unless the network regularly = pings it and gets no response.  Also, note that some systems de-register = users when they shutdown, whereas others may simply overwrite oldest registrations = as needed.

I see the value in "idlesince".  But, would you indicate = CLOSED if you lose radio contact (network pings and gets no response), or would = you keep the last idlesince value?  Or is that network policy?

 

[Chris = Boulton] I also see value in “idlesince” ;-).  I’m not sure = you could use it’s value in conjunction with loss = of radio contact.  What happens when = contact is restored BUT you still do not use your phone for a period of = time?  I agree with Brian in that for = non-rich presence systems the status will never be closed due to voicemail = policy.



Mike

=00 ------_=_NextPart_001_01C3407F.EF7A0462-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 2 05:56:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00089 for ; Wed, 2 Jul 2003 05:56:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XeL6-000072-4t for simple-archive@odin.ietf.org; Wed, 02 Jul 2003 05:55:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h629tmOp000426 for simple-archive@odin.ietf.org; Wed, 2 Jul 2003 05:55:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XeL5-00006n-Uu for simple-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 05:55:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00066; Wed, 2 Jul 2003 05:55:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XeL1-0000El-00; Wed, 02 Jul 2003 05:55:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XeL1-0000Ei-00; Wed, 02 Jul 2003 05:55:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XeKM-0008VA-1C; Wed, 02 Jul 2003 05:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XeK0-0008UW-Si for simple@optimus.ietf.org; Wed, 02 Jul 2003 05:54:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00057 for ; Wed, 2 Jul 2003 05:54:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XeJx-0000Dw-00 for simple@ietf.org; Wed, 02 Jul 2003 05:54:37 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19XeJw-0000Dt-00 for simple@ietf.org; Wed, 02 Jul 2003 05:54:36 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for [132.151.6.1]) with SMTP; Wed, 2 Jul 2003 10:57:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3407F.EF7A0462" Subject: RE: [Simple] comments on rpids-01 , Message-ID: <45730E094814E44488F789C1CDED27AE0219B012@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] comments on rpids-01 , Thread-Index: AcNAGX+gGn1YIS9YRPaa3WXt5uH0AgAZaSBQ From: "Chris Boulton" To: "Michael Hammer" , "Rosen, Brian" Cc: "Henning Schulzrinne" , , , Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 2 Jul 2003 10:54:31 +0100 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3407F.EF7A0462 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <> =20 -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com]=20 Sent: 01 July 2003 22:40 To: Rosen, Brian Cc: 'Henning Schulzrinne'; hisham.khartabil@nokia.com; Dirk.Trossen@nokia.com; simple@ietf.org Subject: RE: [Simple] comments on rpids-01 , =20 At 08:10 AM 7/1/2003 -0400, Rosen, Brian wrote: then you might see closed on the phone, but you might have a tough time with what you do when you momentarily drop out of range. I think it would be great if they told you what they knew, but I'm not holding my breath. I think is a valuable piece of information, especially for an aggregator. Sometimes they don't know. Unless the cell phone has a need to communicate with the network or vice-versa, it is not likely to waste battery power to say "I'm still here!" The network pages (searches) for the phone when it needs to. The phone re-registers when it detects it has moved into a new cell area beyond where it was previously registered. If the phone stays in the same registration area, then the phone won't necessarily send a message unless an application requires it to. If the phone loses radio coverage, then it can't send a message, could be turned off (CLOSED), but who would know unless the network regularly pings it and gets no response. Also, note that some systems de-register users when they shutdown, whereas others may simply overwrite oldest registrations as needed. I see the value in "idlesince". But, would you indicate CLOSED if you lose radio contact (network pings and gets no response), or would you keep the last idlesince value? Or is that network policy? =20 [Chris Boulton] I also see value in "idlesince" ;-). I'm not sure you could use it's value in conjunction with loss of radio contact. What happens when contact is restored BUT you still do not use your phone for a period of time? I agree with Brian in that for non-rich presence systems the status will never be closed due to voicemail policy.=20 Mike ------_=_NextPart_001_01C3407F.EF7A0462 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<<in-line>>

 

-----Original Message-----
From: Michael Hammer [mailto:mhammer@cisco.com]
Sent: 01 July 2003 = 22:40
To: Rosen, Brian
Cc: 'Henning = Schulzrinne'; hisham.khartabil@nokia.com; Dirk.Trossen@nokia.com; simple@ietf.org
Subject: RE: [Simple] = comments on rpids-01 <activity>, <idlesince>

 

At 08:10 AM 7/1/2003 -0400, Rosen, Brian wrote:

then you might see closed on the phone,
but you might have a tough time with what you do when you = momentarily
drop out of range.  I think it would be great if they told you = what
they knew, but I'm not holding my breath.

I think <idlesince> is a valuable piece of information, = especially
for an aggregator.


Sometimes they don't know.

Unless the cell phone has a need to communicate with the network or = vice-versa, it is not likely to waste battery power to say "I'm still here!"  The network pages (searches) for the phone when it = needs to.  The phone re-registers when it detects it has moved into a new = cell area beyond where it was previously registered.

If the phone stays in the same registration area, then the phone won't necessarily send a message unless an application requires it to.

If the phone loses radio coverage, then it can't send a message, could = be turned off (CLOSED), but who would know unless the network regularly = pings it and gets no response.  Also, note that some systems de-register = users when they shutdown, whereas others may simply overwrite oldest registrations = as needed.

I see the value in "idlesince".  But, would you indicate = CLOSED if you lose radio contact (network pings and gets no response), or would = you keep the last idlesince value?  Or is that network policy?

 

[Chris = Boulton] I also see value in “idlesince” ;-).  I’m not sure = you could use it’s value in conjunction with loss = of radio contact.  What happens when = contact is restored BUT you still do not use your phone for a period of = time?  I agree with Brian in that for = non-rich presence systems the status will never be closed due to voicemail = policy.



Mike

=00 ------_=_NextPart_001_01C3407F.EF7A0462-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 2 06:58:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03434; Wed, 2 Jul 2003 06:58:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XfJN-0001Db-00; Wed, 02 Jul 2003 06:58:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XfJM-0001DX-00; Wed, 02 Jul 2003 06:58:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfJO-0003SV-UC; Wed, 02 Jul 2003 06:58:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfIw-0003Lq-0l for simple@optimus.ietf.org; Wed, 02 Jul 2003 06:57:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03332; Wed, 2 Jul 2003 06:57:34 -0400 (EDT) Message-Id: <200307021057.GAA03332@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 02 Jul 2003 06:57:34 -0400 --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 : Instant Message Sessions in SIMPLE Author(s) : B. Campbell et al. Filename : draft-ietf-simple-message-sessions-01.txt Pages : 57 Date : 2003-7-1 This document describes the Message Session Relay Protocol (MSRP), a mechanism for transmitting a series of Instant Messages within a session. MSRP sessions are managed using the SDP offer/answer model carried by a signaling protocol such as SIP. MSRP supports end-to-end Instant Message Sessions, as well as sessions traversing one or two relays. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-message-sessions-01.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-message-sessions-01.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: <2003-7-1135038.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1135038.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 2 06:58:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03554 for ; Wed, 2 Jul 2003 06:58:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfJS-0003Um-8i for simple-archive@odin.ietf.org; Wed, 02 Jul 2003 06:58:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62AwABG013403 for simple-archive@odin.ietf.org; Wed, 2 Jul 2003 06:58:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfJS-0003U0-4C for simple-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 06:58:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03434; Wed, 2 Jul 2003 06:58:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XfJN-0001Db-00; Wed, 02 Jul 2003 06:58:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XfJM-0001DX-00; Wed, 02 Jul 2003 06:58:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfJO-0003SV-UC; Wed, 02 Jul 2003 06:58:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfIw-0003Lq-0l for simple@optimus.ietf.org; Wed, 02 Jul 2003 06:57:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03332; Wed, 2 Jul 2003 06:57:34 -0400 (EDT) Message-Id: <200307021057.GAA03332@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 02 Jul 2003 06:57:34 -0400 --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 : Instant Message Sessions in SIMPLE Author(s) : B. Campbell et al. Filename : draft-ietf-simple-message-sessions-01.txt Pages : 57 Date : 2003-7-1 This document describes the Message Session Relay Protocol (MSRP), a mechanism for transmitting a series of Instant Messages within a session. MSRP sessions are managed using the SDP offer/answer model carried by a signaling protocol such as SIP. MSRP supports end-to-end Instant Message Sessions, as well as sessions traversing one or two relays. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-message-sessions-01.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-message-sessions-01.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: <2003-7-1135038.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1135038.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 2 07:44:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03555 for ; Wed, 2 Jul 2003 06:58:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfJS-0003UX-82 for simple-archive@odin.ietf.org; Wed, 02 Jul 2003 06:58:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62AwANq013398 for simple-archive@odin.ietf.org; Wed, 2 Jul 2003 06:58:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfJS-0003Ty-2U for simple-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 06:58:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03433; Wed, 2 Jul 2003 06:58:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XfJN-0001De-00; Wed, 02 Jul 2003 06:58:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XfJM-0001DY-00; Wed, 02 Jul 2003 06:58:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfJP-0003Sx-BD; Wed, 02 Jul 2003 06:58:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfJ1-0003M3-5D for simple@optimus.ietf.org; Wed, 02 Jul 2003 06:57:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03351; Wed, 2 Jul 2003 06:57:39 -0400 (EDT) Message-Id: <200307021057.GAA03351@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-publish-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 02 Jul 2003 06:57:39 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Session Initiation Protocol (SIP) Extension for Presence Publication Author(s) : A. Niemi Filename : draft-ietf-simple-publish-01.txt Pages : 30 Date : 2003-7-1 This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the framework for SIP Event Notification. The first application of this extension is targeted at the publication of presence information. The mechanism described in this document can be extended to support publication of any event state, for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better suited mechanisms for this purpose (FTP, HTTP, etc.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-publish-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-publish-01.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-publish-01.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: <2003-7-1135048.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-publish-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-publish-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1135048.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 2 07:44:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03433; Wed, 2 Jul 2003 06:58:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XfJN-0001De-00; Wed, 02 Jul 2003 06:58:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XfJM-0001DY-00; Wed, 02 Jul 2003 06:58:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfJP-0003Sx-BD; Wed, 02 Jul 2003 06:58:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfJ1-0003M3-5D for simple@optimus.ietf.org; Wed, 02 Jul 2003 06:57:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03351; Wed, 2 Jul 2003 06:57:39 -0400 (EDT) Message-Id: <200307021057.GAA03351@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-publish-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 02 Jul 2003 06:57:39 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Session Initiation Protocol (SIP) Extension for Presence Publication Author(s) : A. Niemi Filename : draft-ietf-simple-publish-01.txt Pages : 30 Date : 2003-7-1 This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the framework for SIP Event Notification. The first application of this extension is targeted at the publication of presence information. The mechanism described in this document can be extended to support publication of any event state, for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better suited mechanisms for this purpose (FTP, HTTP, etc.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-publish-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-publish-01.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-publish-01.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: <2003-7-1135048.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-publish-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-publish-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1135048.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 2 09:17:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15474; Wed, 2 Jul 2003 09:17:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XhTy-0005cW-00; Wed, 02 Jul 2003 09:17:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XhTx-0005cN-00; Wed, 02 Jul 2003 09:17:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhTp-0000J8-0M; Wed, 02 Jul 2003 09:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhSu-0000F5-Ai for simple@optimus.ietf.org; Wed, 02 Jul 2003 09:16:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15374 for ; Wed, 2 Jul 2003 09:16:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XhSs-0005Zp-00 for simple@ietf.org; Wed, 02 Jul 2003 09:16:02 -0400 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by ietf-mx with esmtp (Exim 4.12) id 19XhSr-0005YN-00 for simple@ietf.org; Wed, 02 Jul 2003 09:16:01 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h62DFSPO094068 for ; Wed, 2 Jul 2003 15:15:28 +0200 Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h62DFLI2069262 for ; Wed, 2 Jul 2003 15:15:22 +0200 To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Avshalom Houri" X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/07/2003 16:15:22, Serialize complete at 02/07/2003 16:15:22 Content-Type: multipart/alternative; boundary="=_alternative 0048D014C2256D57_=" Subject: [Simple] Fw: I-D ACTION:draft-houri-simple-arch-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 2 Jul 2003 16:15:21 +0300 This is a multipart message in MIME format. --=_alternative 0048D014C2256D57_= Content-Type: text/plain; charset="US-ASCII" ----- Forwarded by Avshalom Houri/Haifa/IBM on 02/07/2003 03:55 PM ----- Internet-Drafts@ietf.org Sent by: owner-ietf-announce@ietf.org 02/07/2003 01:53 PM Please respond to Internet-Drafts@ietf.org To IETF-Announce: ; cc Subject I-D ACTION:draft-houri-simple-arch-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP/SIMPLE Based Presence and IM Architecture Author(s) : A. Houri et al. Filename : draft-houri-simple-arch-01.txt Pages : 77 Date : 2003-7-1 This document is a initial attempt in creating a document that will describe the architecture of a presence and instant messaging system. The document collects information required for the creation a complete Presence and IM system using SIMPLE and other IETF protocols. This information has been spread out across numerous other internet drafts and RFCs. The document tries to put everything together, discussing the servers involved, security mechanisms, functional model, call flows, etc. The goal of this document is that someone, who is not an expert in the IETF protocols, can read this document and understand how the IETF protocols can be used for building a complete system and how it should work. The main changes from the previous version of the document is that sections about functional model and basic call flows were added. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-houri-simple-arch-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-houri-simple-arch-01.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-houri-simple-arch-01.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. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-houri-simple-arch-01.txt --=_alternative 0048D014C2256D57_= Content-Type: text/html; charset="US-ASCII"
 
----- Forwarded by Avshalom Houri/Haifa/IBM on 02/07/2003 03:55 PM -----
Internet-Drafts@ietf.org
Sent by: owner-ietf-announce@ietf.org

02/07/2003 01:53 PM
Please respond to
Internet-Drafts@ietf.org
To
IETF-Announce: ;
cc
Subject
I-D ACTION:draft-houri-simple-arch-01.txt





A New Internet-Draft is available from the on-line Internet-Drafts directories.


                Title                                  : SIP/SIMPLE Based Presence and IM Architecture
                Author(s)                 : A. Houri et al.
                Filename                 : draft-houri-simple-arch-01.txt
                Pages                                  : 77
                Date                                  : 2003-7-1
               
This document is a initial attempt in creating a document that will
describe the architecture of a presence and instant messaging system.
The document collects information required for the creation a
complete Presence and IM system using SIMPLE and other IETF
protocols. This information has been spread out across numerous other
internet drafts and RFCs. The document tries to put everything
together, discussing the servers involved, security mechanisms,
functional model, call flows, etc. The goal of this document is that
someone, who is not an expert in the IETF protocols, can read this
document and understand how the IETF protocols can be used for
building a complete system and how it should work. The main changes
from the previous version of the document is that sections about
functional model and basic call flows were added.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-houri-simple-arch-01.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-houri-simple-arch-01.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-houri-simple-arch-01.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.
ftp://anonymous@ftp.ietf.org/internet-drafts/draft-houri-simple-arch-01.txt --=_alternative 0048D014C2256D57_=-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 2 09:17:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15553 for ; Wed, 2 Jul 2003 09:17:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhU0-0000K5-7h for simple-archive@odin.ietf.org; Wed, 02 Jul 2003 09:17:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62DHCpF001235 for simple-archive@odin.ietf.org; Wed, 2 Jul 2003 09:17:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhU0-0000Jq-4c for simple-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 09:17:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15474; Wed, 2 Jul 2003 09:17:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XhTy-0005cW-00; Wed, 02 Jul 2003 09:17:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XhTx-0005cN-00; Wed, 02 Jul 2003 09:17:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhTp-0000J8-0M; Wed, 02 Jul 2003 09:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhSu-0000F5-Ai for simple@optimus.ietf.org; Wed, 02 Jul 2003 09:16:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15374 for ; Wed, 2 Jul 2003 09:16:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XhSs-0005Zp-00 for simple@ietf.org; Wed, 02 Jul 2003 09:16:02 -0400 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by ietf-mx with esmtp (Exim 4.12) id 19XhSr-0005YN-00 for simple@ietf.org; Wed, 02 Jul 2003 09:16:01 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h62DFSPO094068 for ; Wed, 2 Jul 2003 15:15:28 +0200 Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h62DFLI2069262 for ; Wed, 2 Jul 2003 15:15:22 +0200 To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Avshalom Houri" X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/07/2003 16:15:22, Serialize complete at 02/07/2003 16:15:22 Content-Type: multipart/alternative; boundary="=_alternative 0048D014C2256D57_=" Subject: [Simple] Fw: I-D ACTION:draft-houri-simple-arch-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 2 Jul 2003 16:15:21 +0300 This is a multipart message in MIME format. --=_alternative 0048D014C2256D57_= Content-Type: text/plain; charset="US-ASCII" ----- Forwarded by Avshalom Houri/Haifa/IBM on 02/07/2003 03:55 PM ----- Internet-Drafts@ietf.org Sent by: owner-ietf-announce@ietf.org 02/07/2003 01:53 PM Please respond to Internet-Drafts@ietf.org To IETF-Announce: ; cc Subject I-D ACTION:draft-houri-simple-arch-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP/SIMPLE Based Presence and IM Architecture Author(s) : A. Houri et al. Filename : draft-houri-simple-arch-01.txt Pages : 77 Date : 2003-7-1 This document is a initial attempt in creating a document that will describe the architecture of a presence and instant messaging system. The document collects information required for the creation a complete Presence and IM system using SIMPLE and other IETF protocols. This information has been spread out across numerous other internet drafts and RFCs. The document tries to put everything together, discussing the servers involved, security mechanisms, functional model, call flows, etc. The goal of this document is that someone, who is not an expert in the IETF protocols, can read this document and understand how the IETF protocols can be used for building a complete system and how it should work. The main changes from the previous version of the document is that sections about functional model and basic call flows were added. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-houri-simple-arch-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-houri-simple-arch-01.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-houri-simple-arch-01.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. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-houri-simple-arch-01.txt --=_alternative 0048D014C2256D57_= Content-Type: text/html; charset="US-ASCII"
 
----- Forwarded by Avshalom Houri/Haifa/IBM on 02/07/2003 03:55 PM -----
Internet-Drafts@ietf.org
Sent by: owner-ietf-announce@ietf.org

02/07/2003 01:53 PM
Please respond to
Internet-Drafts@ietf.org
To
IETF-Announce: ;
cc
Subject
I-D ACTION:draft-houri-simple-arch-01.txt





A New Internet-Draft is available from the on-line Internet-Drafts directories.


                Title                                  : SIP/SIMPLE Based Presence and IM Architecture
                Author(s)                 : A. Houri et al.
                Filename                 : draft-houri-simple-arch-01.txt
                Pages                                  : 77
                Date                                  : 2003-7-1
               
This document is a initial attempt in creating a document that will
describe the architecture of a presence and instant messaging system.
The document collects information required for the creation a
complete Presence and IM system using SIMPLE and other IETF
protocols. This information has been spread out across numerous other
internet drafts and RFCs. The document tries to put everything
together, discussing the servers involved, security mechanisms,
functional model, call flows, etc. The goal of this document is that
someone, who is not an expert in the IETF protocols, can read this
document and understand how the IETF protocols can be used for
building a complete system and how it should work. The main changes
from the previous version of the document is that sections about
functional model and basic call flows were added.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-houri-simple-arch-01.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-houri-simple-arch-01.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-houri-simple-arch-01.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.
ftp://anonymous@ftp.ietf.org/internet-drafts/draft-houri-simple-arch-01.txt --=_alternative 0048D014C2256D57_=-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 2 16:35:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13878; Wed, 2 Jul 2003 16:35:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoJk-0003Jb-0f; Wed, 02 Jul 2003 16:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoJB-00035a-4l for simple@optimus.ietf.org; Wed, 02 Jul 2003 16:34:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13375; Wed, 2 Jul 2003 16:34:23 -0400 (EDT) Message-Id: <200307022034.QAA13375@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-rpids-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 02 Jul 2003 16:34:23 -0400 --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 : RPIDS -- Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol (SIP) Author(s) : H. Schulzrinne Filename : draft-ietf-simple-rpids-01.txt Pages : 19 Date : 2003-7-2 The Rich Presence Information Data Format for the Session Initiation Protocol (SIP) (RPIDS) adds elements to the Presence Information Data Format (PIDF) that provide additional information about the presentity and its contacts. This information can be translated into call routing behavior or be delivered to watchers. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-rpids-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rpids-01.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-rpids-01.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: <2003-7-2162020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-rpids-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-rpids-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2162020.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 2 16:36:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14104 for ; Wed, 2 Jul 2003 16:36:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoKH-0003Nm-6u for simple-archive@odin.ietf.org; Wed, 02 Jul 2003 16:35:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KZboU012998 for simple-archive@odin.ietf.org; Wed, 2 Jul 2003 16:35:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoKH-0003NZ-3m for simple-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 16:35:37 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13878; Wed, 2 Jul 2003 16:35:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoJk-0003Jb-0f; Wed, 02 Jul 2003 16:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoJB-00035a-4l for simple@optimus.ietf.org; Wed, 02 Jul 2003 16:34:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13375; Wed, 2 Jul 2003 16:34:23 -0400 (EDT) Message-Id: <200307022034.QAA13375@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-rpids-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 02 Jul 2003 16:34:23 -0400 --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 : RPIDS -- Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol (SIP) Author(s) : H. Schulzrinne Filename : draft-ietf-simple-rpids-01.txt Pages : 19 Date : 2003-7-2 The Rich Presence Information Data Format for the Session Initiation Protocol (SIP) (RPIDS) adds elements to the Presence Information Data Format (PIDF) that provide additional information about the presentity and its contacts. This information can be translated into call routing behavior or be delivered to watchers. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-rpids-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rpids-01.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-rpids-01.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: <2003-7-2162020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-rpids-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-rpids-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2162020.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 2 16:41:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15187; Wed, 2 Jul 2003 16:41:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoPW-0004x9-V7; Wed, 02 Jul 2003 16:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoPO-0004wl-9F for simple@optimus.ietf.org; Wed, 02 Jul 2003 16:40:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15120 for ; Wed, 2 Jul 2003 16:40:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XoPK-0007Zy-00 for simple@ietf.org; Wed, 02 Jul 2003 16:40:50 -0400 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 19XoPJ-0007Wu-00 for simple@ietf.org; Wed, 02 Jul 2003 16:40:49 -0400 Received: from chiimc01.npac.com ([10.32.90.4]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id h62KeAN07314; Wed, 2 Jul 2003 20:40:10 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jul 2003 15:42:53 -0500 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257C54@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Henning Schulzrinne'" Cc: "Simpletons (E-mail)" Subject: RE: [Simple] comments on rpids-01 - MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 2 Jul 2003 15:41:02 -0500 > > But I guess this is really secondary to my point - my point is that > > and share the same motivation given rpids-00 today, and that > > Not really; is information about the presentity, as a URI. > rpids-00 does not say that is information about the presentity. From the note of mine to which you are responding: > What I'm concerned about here is that there are two elements - and > - that do the same thing, according to their respective > specifications. As it's written, provides "general information about > the tuple", and in a tuple provides "a comment" "regarding the > particular tuple". So when you have some information about a tuple, do you > put it in a or an ? If you want to change the definition of in rpids-00 such that it provides information about a presentity, then I'm at least a little clearer as to how this is different from (though perhaps not a -level note). But again, in that case or something as a -level attribute would be preferable to (although it is debatably 'presence information' then). [snip] > > Think of this as "this is a link to information describing the tuple". > > The reason for reference instead of value is simply efficiency. > And as I said in my original note, I don't think that by-reference vs. by-value alone is sufficient grounds to break backwards compatibility. I think the text about needs to reflect whether or not it contains the same information that would appear ordinarily in a (except it's by-reference to save bytes or what have you) - and acknowledge that this is an optimization that encourages information to appear exclusively for RPIDS-friendly recipients, not for baseline PIDF recipients - or explain how the information in differs from . But in the absence of such further qualifications, I still think it should be removed. Jon Peterson NeuStar, Inc. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 2 16:42:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15229 for ; Wed, 2 Jul 2003 16:42:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoQ4-00050z-39 for simple-archive@odin.ietf.org; Wed, 02 Jul 2003 16:41:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KfaCr019271 for simple-archive@odin.ietf.org; Wed, 2 Jul 2003 16:41:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoQ3-00050k-VT for simple-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 16:41:35 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15187; Wed, 2 Jul 2003 16:41:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoPW-0004x9-V7; Wed, 02 Jul 2003 16:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoPO-0004wl-9F for simple@optimus.ietf.org; Wed, 02 Jul 2003 16:40:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15120 for ; Wed, 2 Jul 2003 16:40:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XoPK-0007Zy-00 for simple@ietf.org; Wed, 02 Jul 2003 16:40:50 -0400 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 19XoPJ-0007Wu-00 for simple@ietf.org; Wed, 02 Jul 2003 16:40:49 -0400 Received: from chiimc01.npac.com ([10.32.90.4]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id h62KeAN07314; Wed, 2 Jul 2003 20:40:10 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jul 2003 15:42:53 -0500 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257C54@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Henning Schulzrinne'" Cc: "Simpletons (E-mail)" Subject: RE: [Simple] comments on rpids-01 - MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 2 Jul 2003 15:41:02 -0500 > > But I guess this is really secondary to my point - my point is that > > and share the same motivation given rpids-00 today, and that > > Not really; is information about the presentity, as a URI. > rpids-00 does not say that is information about the presentity. From the note of mine to which you are responding: > What I'm concerned about here is that there are two elements - and > - that do the same thing, according to their respective > specifications. As it's written, provides "general information about > the tuple", and in a tuple provides "a comment" "regarding the > particular tuple". So when you have some information about a tuple, do you > put it in a or an ? If you want to change the definition of in rpids-00 such that it provides information about a presentity, then I'm at least a little clearer as to how this is different from (though perhaps not a -level note). But again, in that case or something as a -level attribute would be preferable to (although it is debatably 'presence information' then). [snip] > > Think of this as "this is a link to information describing the tuple". > > The reason for reference instead of value is simply efficiency. > And as I said in my original note, I don't think that by-reference vs. by-value alone is sufficient grounds to break backwards compatibility. I think the text about needs to reflect whether or not it contains the same information that would appear ordinarily in a (except it's by-reference to save bytes or what have you) - and acknowledge that this is an optimization that encourages information to appear exclusively for RPIDS-friendly recipients, not for baseline PIDF recipients - or explain how the information in differs from . But in the absence of such further qualifications, I still think it should be removed. Jon Peterson NeuStar, Inc. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 2 23:06:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12591; Wed, 2 Jul 2003 23:06:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XuQ9-00022U-00; Wed, 02 Jul 2003 23:06:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XuQ9-00022R-00; Wed, 02 Jul 2003 23:06:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XuQ8-0002pQ-Df; Wed, 02 Jul 2003 23:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XuPC-0002oy-3N for simple@optimus.ietf.org; Wed, 02 Jul 2003 23:05:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12563 for ; Wed, 2 Jul 2003 23:05:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XuP7-00021q-00 for simple@ietf.org; Wed, 02 Jul 2003 23:05:01 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19XuP7-00021n-00 for simple@ietf.org; Wed, 02 Jul 2003 23:05:01 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h63352kM019402; Wed, 2 Jul 2003 23:05:02 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6334wN17793; Wed, 2 Jul 2003 23:04:59 -0400 Message-ID: <3F039C6B.3020305@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C54@stntexch2.va.neustar.com> In-Reply-To: <0449D80A0E9B614A83FA9031B07E8D3B257C54@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 02 Jul 2003 23:00:59 -0400 Content-Transfer-Encoding: 7bit I think I now better understand your question. This is indeed meant as more "long-term" information. The name and definition stems from the similarly-named field in the SIP Call-Info header. As usual, I'm not wedded to particular labels. Thus, as you said, this falls into the open issue as to how this more longer-term material should be handled. I will amplify the definition. Peterson, Jon wrote: >>What I'm concerned about here is that there are two elements - and >> - that do the same thing, according to their respective >>specifications. As it's written, provides "general information > > about > >>the tuple", and in a tuple provides "a comment" "regarding the >>particular tuple". So when you have some information about a tuple, do you >>put it in a or an ? > > > If you want to change the definition of in rpids-00 such that it > provides information about a presentity, then I'm at least a little clearer > as to how this is different from (though perhaps not a > -level note). But again, in that case or something as a > -level attribute would be preferable to (although it is > debatably 'presence information' then). > > [snip] > >>Think of this as "this is a link to information describing the tuple". >> >>The reason for reference instead of value is simply efficiency. >> > > > And as I said in my original note, I don't think that by-reference vs. > by-value alone is sufficient grounds to break backwards compatibility. > > I think the text about needs to reflect whether or not it contains > the same information that would appear ordinarily in a (except it's > by-reference to save bytes or what have you) - and acknowledge that this is > an optimization that encourages information to appear exclusively for > RPIDS-friendly recipients, not for baseline PIDF recipients - or explain how > the information in differs from . But in the absence of such > further qualifications, I still think it should be removed. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > 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 exim@www1.ietf.org Wed Jul 2 23:06:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12612 for ; Wed, 2 Jul 2003 23:06:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XuQG-0002sO-9E for simple-archive@odin.ietf.org; Wed, 02 Jul 2003 23:06:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6336CpR010955 for simple-archive@odin.ietf.org; Wed, 2 Jul 2003 23:06:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XuQF-0002qO-ES for simple-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 23:06:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12591; Wed, 2 Jul 2003 23:06:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XuQ9-00022U-00; Wed, 02 Jul 2003 23:06:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XuQ9-00022R-00; Wed, 02 Jul 2003 23:06:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XuQ8-0002pQ-Df; Wed, 02 Jul 2003 23:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XuPC-0002oy-3N for simple@optimus.ietf.org; Wed, 02 Jul 2003 23:05:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12563 for ; Wed, 2 Jul 2003 23:05:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XuP7-00021q-00 for simple@ietf.org; Wed, 02 Jul 2003 23:05:01 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19XuP7-00021n-00 for simple@ietf.org; Wed, 02 Jul 2003 23:05:01 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h63352kM019402; Wed, 2 Jul 2003 23:05:02 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6334wN17793; Wed, 2 Jul 2003 23:04:59 -0400 Message-ID: <3F039C6B.3020305@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C54@stntexch2.va.neustar.com> In-Reply-To: <0449D80A0E9B614A83FA9031B07E8D3B257C54@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 02 Jul 2003 23:00:59 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think I now better understand your question. This is indeed meant as more "long-term" information. The name and definition stems from the similarly-named field in the SIP Call-Info header. As usual, I'm not wedded to particular labels. Thus, as you said, this falls into the open issue as to how this more longer-term material should be handled. I will amplify the definition. Peterson, Jon wrote: >>What I'm concerned about here is that there are two elements - and >> - that do the same thing, according to their respective >>specifications. As it's written, provides "general information > > about > >>the tuple", and in a tuple provides "a comment" "regarding the >>particular tuple". So when you have some information about a tuple, do you >>put it in a or an ? > > > If you want to change the definition of in rpids-00 such that it > provides information about a presentity, then I'm at least a little clearer > as to how this is different from (though perhaps not a > -level note). But again, in that case or something as a > -level attribute would be preferable to (although it is > debatably 'presence information' then). > > [snip] > >>Think of this as "this is a link to information describing the tuple". >> >>The reason for reference instead of value is simply efficiency. >> > > > And as I said in my original note, I don't think that by-reference vs. > by-value alone is sufficient grounds to break backwards compatibility. > > I think the text about needs to reflect whether or not it contains > the same information that would appear ordinarily in a (except it's > by-reference to save bytes or what have you) - and acknowledge that this is > an optimization that encourages information to appear exclusively for > RPIDS-friendly recipients, not for baseline PIDF recipients - or explain how > the information in differs from . But in the absence of such > further qualifications, I still think it should be removed. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > 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-admin@ietf.org Thu Jul 3 03:12:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00791; Thu, 3 Jul 2003 03:12:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XyG9-0003sK-00; Thu, 03 Jul 2003 03:12:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XyG9-0003sH-00; Thu, 03 Jul 2003 03:12:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XyG7-0002E4-6f; Thu, 03 Jul 2003 03:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XyFG-0002DV-Hr for simple@optimus.ietf.org; Thu, 03 Jul 2003 03:11:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00787 for ; Thu, 3 Jul 2003 03:11:03 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XyFC-0003sC-00 for simple@ietf.org; Thu, 03 Jul 2003 03:11:02 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19XyFB-0003s9-00 for simple@ietf.org; Thu, 03 Jul 2003 03:11:01 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h637B0a16136 for ; Thu, 3 Jul 2003 10:11:00 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 3 Jul 2003 10:10:59 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Jul 2003 10:10:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] comments on rpids-01 (general, vCard, predictive) Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8E43@esebe013.ntc.nokia.com> Thread-Topic: [Simple] comments on rpids-01 (general, vCard, predictive) Thread-Index: AcM9U/3Cfxoh+GDrQCifFTmReHbeFgD2kIJg To: , Cc: X-OriginalArrivalTime: 03 Jul 2003 07:10:59.0772 (UTC) FILETIME=[41638FC0:01C34132] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 3 Jul 2003 10:10:59 +0300 Content-Transfer-Encoding: quoted-printable Inline [snip] > Again, I defer to the conversation recorded in Ottawa -=20 > these did not appear > to be trivial or obvious issues, and some proposed solutions were > problematic. Given that, standardization of these things=20 > (such as when > predictive presence is published) seems appropriate, if not=20 > necessary - I > think these are real issues, and generic or no, they need to=20 > be accounted > for. I do not think we encounter these issues if our goals=20 > are only as > modest as, say, defining and as given=20 > in rpids-00.=20 Let me also restate what I said in Ottawa. I don't think there is really = a problem for us to solve here beyond a mechanism which allows a = publisher to get an indication when its state has been overridden by = someone else. My personal presence model only includes PUAs - some of = them may be automatons, some human beings, but all work in real time = independent of whether the data from which they derive the publications = is static or dynamic. Interactions between automatically derived = presence and any other source ultimately need to be resolved by the = system designer. Having said that, I may of course be missing the point = about predictive presence - I just think we may be stepping too deep = into implementation space here. =20 > Finally, let me stress once again I think predictive presence is > interesting, valuable, and something we should take on - I=20 > just think we > should take it on separately from our more modest goals. There is a > reasonable distinction to make, I think, between predictive=20 > presence and > 'regular' presence. I do too, not sure there's much more to standardize though. =20 > > Similarly, as Brian and other have pointed out, any automatic=20 > > information will occasionally be wrong (but they believe,=20 > if I interpret=20 > > them correctly) that the probability of correctness is higher. In=20 > > general, I tend to favor "automatic with override" on all=20 > elements, but=20 > > that's again a policy issue. Others might want "automatic=20 > with mandatory=20 > > approval" or "hey, it's a guess anyway". > >=20 >=20 > I agree with Brian and virtually everyone else that=20 > automatically generated > presence is superior - I'm just not sure I group predictive=20 > presence into > that category, for the reasons given above. If dealing with=20 > predictive > presence is left totally to local policy, then dueling=20 > automatons are a real > possibility, I think. The publish draft has an open issue on this exact point. In a case where = the publisher is a human being, it is possible to ask for further = actions if a collision occurs. But with automatons, this is of course = trickier. However, I'm not sure we need to nail down any one way to = resolve the error scenario. It could be that an automaton always steps = down, but some automatons may also be authoritive on this. It really = depends on the system, IMO. =20 [snip] > > This is an element where I agree this can be considered borderline. > >=20 > > > I don't see why presence has to be the carrier of this reference. > >=20 > > Particularly for complicated presence documents, a=20 > presentity-supplied=20 > > icon may well be the best short-hand for a tuple since it=20 > can capture=20 > > information that is hard to express otherwise. (Well,=20 > beyond the "beach=20 > > with sunset" rubbing in that the presentity is on vacation and the=20 > > watcher is not...) Existing presence systems don't have=20 > multiple tuples=20 > > for each presentity, so this less of an issue. I don't see how a=20 > > message-based icon in messaging helps with rendering=20 > presence status in=20 > > a quick-to-grasp form. > >=20 >=20 > Again, commercial instant messaging systems, in my=20 > experience, don't use > presentity-provided icons to express a presentity's current=20 > state in a > watcher's buddylist screen. Apps might have predefined icons=20 > corresponding > to, say, your state as given in rpids-00, but I=20 > don't think I've > seen user-supplied versions of those icons to date. The=20 > whole value of these > buddylist icons is that they're the same for all users in the same > - if your used-defined icon for 'away' looks=20 > different from > somebody else icon for 'away', then icons aren't making the=20 > buddylist screen > any easier to interpret. The custom icons that are used in=20 > commercial IM&P > products today show up in a different context, afaik. As I've said before, there are commercial systems out there that do use = graphics to describe a presentity's status. The provided icons are not = meant to replace "away" icons on buddylists - I believe they are more = akin to a personalized, graphical . And as long as we're aiming at enabling a SIMPLE application on par with = the market, we might as well look at all commecial systems, not just = some of them. Cheers, Aki >=20 > Jon Peterson > NeuStar, Inc. >=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 exim@www1.ietf.org Thu Jul 3 03:12:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00819 for ; Thu, 3 Jul 2003 03:12:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XyGC-0002Eh-BC for simple-archive@odin.ietf.org; Thu, 03 Jul 2003 03:12:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h637C4bS008591 for simple-archive@odin.ietf.org; Thu, 3 Jul 2003 03:12:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XyGC-0002EU-6g for simple-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 03:12:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00791; Thu, 3 Jul 2003 03:12:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XyG9-0003sK-00; Thu, 03 Jul 2003 03:12:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XyG9-0003sH-00; Thu, 03 Jul 2003 03:12:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XyG7-0002E4-6f; Thu, 03 Jul 2003 03:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XyFG-0002DV-Hr for simple@optimus.ietf.org; Thu, 03 Jul 2003 03:11:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00787 for ; Thu, 3 Jul 2003 03:11:03 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XyFC-0003sC-00 for simple@ietf.org; Thu, 03 Jul 2003 03:11:02 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19XyFB-0003s9-00 for simple@ietf.org; Thu, 03 Jul 2003 03:11:01 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h637B0a16136 for ; Thu, 3 Jul 2003 10:11:00 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 3 Jul 2003 10:10:59 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Jul 2003 10:10:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] comments on rpids-01 (general, vCard, predictive) Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8E43@esebe013.ntc.nokia.com> Thread-Topic: [Simple] comments on rpids-01 (general, vCard, predictive) Thread-Index: AcM9U/3Cfxoh+GDrQCifFTmReHbeFgD2kIJg To: , Cc: X-OriginalArrivalTime: 03 Jul 2003 07:10:59.0772 (UTC) FILETIME=[41638FC0:01C34132] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 3 Jul 2003 10:10:59 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Inline [snip] > Again, I defer to the conversation recorded in Ottawa -=20 > these did not appear > to be trivial or obvious issues, and some proposed solutions were > problematic. Given that, standardization of these things=20 > (such as when > predictive presence is published) seems appropriate, if not=20 > necessary - I > think these are real issues, and generic or no, they need to=20 > be accounted > for. I do not think we encounter these issues if our goals=20 > are only as > modest as, say, defining and as given=20 > in rpids-00.=20 Let me also restate what I said in Ottawa. I don't think there is really = a problem for us to solve here beyond a mechanism which allows a = publisher to get an indication when its state has been overridden by = someone else. My personal presence model only includes PUAs - some of = them may be automatons, some human beings, but all work in real time = independent of whether the data from which they derive the publications = is static or dynamic. Interactions between automatically derived = presence and any other source ultimately need to be resolved by the = system designer. Having said that, I may of course be missing the point = about predictive presence - I just think we may be stepping too deep = into implementation space here. =20 > Finally, let me stress once again I think predictive presence is > interesting, valuable, and something we should take on - I=20 > just think we > should take it on separately from our more modest goals. There is a > reasonable distinction to make, I think, between predictive=20 > presence and > 'regular' presence. I do too, not sure there's much more to standardize though. =20 > > Similarly, as Brian and other have pointed out, any automatic=20 > > information will occasionally be wrong (but they believe,=20 > if I interpret=20 > > them correctly) that the probability of correctness is higher. In=20 > > general, I tend to favor "automatic with override" on all=20 > elements, but=20 > > that's again a policy issue. Others might want "automatic=20 > with mandatory=20 > > approval" or "hey, it's a guess anyway". > >=20 >=20 > I agree with Brian and virtually everyone else that=20 > automatically generated > presence is superior - I'm just not sure I group predictive=20 > presence into > that category, for the reasons given above. If dealing with=20 > predictive > presence is left totally to local policy, then dueling=20 > automatons are a real > possibility, I think. The publish draft has an open issue on this exact point. In a case where = the publisher is a human being, it is possible to ask for further = actions if a collision occurs. But with automatons, this is of course = trickier. However, I'm not sure we need to nail down any one way to = resolve the error scenario. It could be that an automaton always steps = down, but some automatons may also be authoritive on this. It really = depends on the system, IMO. =20 [snip] > > This is an element where I agree this can be considered borderline. > >=20 > > > I don't see why presence has to be the carrier of this reference. > >=20 > > Particularly for complicated presence documents, a=20 > presentity-supplied=20 > > icon may well be the best short-hand for a tuple since it=20 > can capture=20 > > information that is hard to express otherwise. (Well,=20 > beyond the "beach=20 > > with sunset" rubbing in that the presentity is on vacation and the=20 > > watcher is not...) Existing presence systems don't have=20 > multiple tuples=20 > > for each presentity, so this less of an issue. I don't see how a=20 > > message-based icon in messaging helps with rendering=20 > presence status in=20 > > a quick-to-grasp form. > >=20 >=20 > Again, commercial instant messaging systems, in my=20 > experience, don't use > presentity-provided icons to express a presentity's current=20 > state in a > watcher's buddylist screen. Apps might have predefined icons=20 > corresponding > to, say, your state as given in rpids-00, but I=20 > don't think I've > seen user-supplied versions of those icons to date. The=20 > whole value of these > buddylist icons is that they're the same for all users in the same > - if your used-defined icon for 'away' looks=20 > different from > somebody else icon for 'away', then icons aren't making the=20 > buddylist screen > any easier to interpret. The custom icons that are used in=20 > commercial IM&P > products today show up in a different context, afaik. As I've said before, there are commercial systems out there that do use = graphics to describe a presentity's status. The provided icons are not = meant to replace "away" icons on buddylists - I believe they are more = akin to a personalized, graphical . And as long as we're aiming at enabling a SIMPLE application on par with = the market, we might as well look at all commecial systems, not just = some of them. Cheers, Aki >=20 > Jon Peterson > NeuStar, Inc. >=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 mailman-admin@ietf.org Thu Jul 3 19:44:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25330 for ; Thu, 3 Jul 2003 19:27:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YD3S-0000H4-00 for simple-archive@ietf.org; Thu, 03 Jul 2003 18:59:54 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YCrw-00071p-00 for simple-archive@ietf.org; Thu, 03 Jul 2003 18:48:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCfZ-00081P-NN for simple-archive@ietf.org; Thu, 03 Jul 2003 18:35:13 -0400 Date: Thu, 03 Jul 2003 18:35:13 -0400 Message-ID: <20030703223513.4508.45686.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: simple-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk There was an error in the last monthly reminder, in that the NOTE WELL statement (below) was not included. Therefore, the reminder is being sent out again. This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for simple-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org onahda https://www1.ietf.org/mailman/options/simple/simple-archive%40ietf.org From exim@www1.ietf.org Thu Jul 3 19:46:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26882 for ; Thu, 3 Jul 2003 19:46:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDmP-0002YG-KM for simple-archive@odin.ietf.org; Thu, 03 Jul 2003 19:46:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63NkLi5009797 for simple-archive@odin.ietf.org; Thu, 3 Jul 2003 19:46:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDkP-0002Bz-P6 for simple-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 19:44:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23444 for ; Thu, 3 Jul 2003 19:25:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YDFR-0002cW-00 for simple-web-archive@ietf.org; Thu, 03 Jul 2003 19:12:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YCre-0006xn-00 for simple-web-archive@ietf.org; Thu, 03 Jul 2003 18:47:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCiS-0004FP-V9 for simple-web-archive@ietf.org; Thu, 03 Jul 2003 18:38:12 -0400 Date: Thu, 03 Jul 2003 18:38:12 -0400 Message-ID: <20030703223812.4508.97296.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: simple-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk There was an error in the last monthly reminder, in that the NOTE WELL statement (below) was not included. Therefore, the reminder is being sent out again. This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for simple-web-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org fuasex https://www1.ietf.org/mailman/options/simple/simple-web-archive%40ietf.org From simple-admin@ietf.org Fri Jul 4 06:47:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22905; Fri, 4 Jul 2003 06:47:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YO5l-00048k-00; Fri, 04 Jul 2003 06:47:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YO5k-00048h-00; Fri, 04 Jul 2003 06:47:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YO5l-0000gR-09; Fri, 04 Jul 2003 06:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YO52-0000g3-48 for simple@optimus.ietf.org; Fri, 04 Jul 2003 06:46:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22897 for ; Fri, 4 Jul 2003 06:46:11 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YO4y-00048X-00 for simple@ietf.org; Fri, 04 Jul 2003 06:46:12 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19YO4x-00048U-00 for simple@ietf.org; Fri, 04 Jul 2003 06:46:11 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h64AkB927137 for ; Fri, 4 Jul 2003 13:46:11 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 4 Jul 2003 13:46:14 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Jul 2003 13:46:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] comments on rpids-01 (general, vCard, predictive) Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194530E@esebe013.ntc.nokia.com> Thread-Topic: [Simple] comments on rpids-01 (general, vCard, predictive) Thread-Index: AcM9U/3Cfxoh+GDrQCifFTmReHbeFgExBcow To: , Cc: X-OriginalArrivalTime: 04 Jul 2003 10:46:10.0620 (UTC) FILETIME=[7B445FC0:01C34219] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 4 Jul 2003 13:46:09 +0300 Content-Transfer-Encoding: quoted-printable [snip] > And even if it were automatically generated, in my opinion,=20 > the issues with > predictive presence aren't generic to all other forms of=20 > automatically > generated presence. A number of issues arise because there=20 > is a moment in > time (in the past) when a presentity (or someone entitled to=20 > publish on > their behalf) speculates on their future status - this=20 > creates issues with > when presence is published (should it be when the prediction=20 > is made, or > when the predicted time arrives?) how presence is timestamped (when a > publisher publishes, does it generate and timestamp a tuple=20 > then, or is the > tuple generated and timestamped when the prediction is made?), how > precedence is determined (i.e. do timestamps suffice for=20 > precedence of > presence information when comparing two published tuples=20 > that cover the same > resource?) and so on.=20 After looking at this thread a bit more carefully, I agree with this = distinction made about predictive presence, i.e., that publishing a = prediction is different from making a prediction and then publishing the = event as it was actually predicted to occur. I agree that both ways are probably equally valid ways but do have = different properties. When I was saying there is probably nothing more = to standardize, I was only thinking of the latter one. =20 [snip] > Finally, let me stress once again I think predictive presence is > interesting, valuable, and something we should take on - I=20 > just think we > should take it on separately from our more modest goals. There is a > reasonable distinction to make, I think, between predictive=20 > presence and > 'regular' presence. Agreed. Cheers, Aki =20 > > Similarly, as Brian and other have pointed out, any automatic=20 > > information will occasionally be wrong (but they believe,=20 > if I interpret=20 > > them correctly) that the probability of correctness is higher. In=20 > > general, I tend to favor "automatic with override" on all=20 > elements, but=20 > > that's again a policy issue. Others might want "automatic=20 > with mandatory=20 > > approval" or "hey, it's a guess anyway". > >=20 >=20 > I agree with Brian and virtually everyone else that=20 > automatically generated > presence is superior - I'm just not sure I group predictive=20 > presence into > that category, for the reasons given above. If dealing with=20 > predictive > presence is left totally to local policy, then dueling=20 > automatons are a real > possibility, I think. >=20 > > >=20 > > > In other words, the Call-Info method of delivering=20 > vCards and icons > > > shouldn't be ruled out on the grounds that some protocol=20 > other than SIP > > > can't available itself of it. > >=20 > > Agreed; as I noted, with composition, Call-Info won't do=20 > the trick, so=20 > > this is just another reason. > >=20 >=20 > And I noted that Call-Info w/ icon might appear in an=20 > INVITE, not a NOTIFY. > The requirement that the icon needs to be transmitted with=20 > presence data is > what I am questioning. If we grant that the icon should be=20 > transmitted with > presence data, I agree that the tuple is a better location that the > Call-Info header, because of the aforementioned composition issue. >=20 > Since we don't have any reference requirements to fall back,=20 > this may be a > tough issue to resolve (mind you, I'm NOT suggesting that we=20 > start some kind > of requirements phase for this). I suppose I tend to=20 > advocate removing > features much moreso than retaining them when they are borderline, > especially when I'm not sure they are necessary for the=20 > application we're > trying to enable. >=20 > > This is an element where I agree this can be considered borderline. > >=20 > > > I don't see why presence has to be the carrier of this reference. > >=20 > > Particularly for complicated presence documents, a=20 > presentity-supplied=20 > > icon may well be the best short-hand for a tuple since it=20 > can capture=20 > > information that is hard to express otherwise. (Well,=20 > beyond the "beach=20 > > with sunset" rubbing in that the presentity is on vacation and the=20 > > watcher is not...) Existing presence systems don't have=20 > multiple tuples=20 > > for each presentity, so this less of an issue. I don't see how a=20 > > message-based icon in messaging helps with rendering=20 > presence status in=20 > > a quick-to-grasp form. > >=20 >=20 > Again, commercial instant messaging systems, in my=20 > experience, don't use > presentity-provided icons to express a presentity's current=20 > state in a > watcher's buddylist screen. Apps might have predefined icons=20 > corresponding > to, say, your state as given in rpids-00, but I=20 > don't think I've > seen user-supplied versions of those icons to date. The=20 > whole value of these > buddylist icons is that they're the same for all users in the same > - if your used-defined icon for 'away' looks=20 > different from > somebody else icon for 'away', then icons aren't making the=20 > buddylist screen > any easier to interpret. The custom icons that are used in=20 > commercial IM&P > products today show up in a different context, afaik. >=20 > Jon Peterson > NeuStar, Inc. >=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 exim@www1.ietf.org Fri Jul 4 06:47:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22923 for ; Fri, 4 Jul 2003 06:47:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YO5p-0000h9-SM for simple-archive@odin.ietf.org; Fri, 04 Jul 2003 06:47:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64Al5H3002667 for simple-archive@odin.ietf.org; Fri, 4 Jul 2003 06:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YO5p-0000gw-PK for simple-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 06:47:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22905; Fri, 4 Jul 2003 06:47:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YO5l-00048k-00; Fri, 04 Jul 2003 06:47:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YO5k-00048h-00; Fri, 04 Jul 2003 06:47:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YO5l-0000gR-09; Fri, 04 Jul 2003 06:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YO52-0000g3-48 for simple@optimus.ietf.org; Fri, 04 Jul 2003 06:46:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22897 for ; Fri, 4 Jul 2003 06:46:11 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YO4y-00048X-00 for simple@ietf.org; Fri, 04 Jul 2003 06:46:12 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19YO4x-00048U-00 for simple@ietf.org; Fri, 04 Jul 2003 06:46:11 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h64AkB927137 for ; Fri, 4 Jul 2003 13:46:11 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 4 Jul 2003 13:46:14 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Jul 2003 13:46:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] comments on rpids-01 (general, vCard, predictive) Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194530E@esebe013.ntc.nokia.com> Thread-Topic: [Simple] comments on rpids-01 (general, vCard, predictive) Thread-Index: AcM9U/3Cfxoh+GDrQCifFTmReHbeFgExBcow To: , Cc: X-OriginalArrivalTime: 04 Jul 2003 10:46:10.0620 (UTC) FILETIME=[7B445FC0:01C34219] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 4 Jul 2003 13:46:09 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable [snip] > And even if it were automatically generated, in my opinion,=20 > the issues with > predictive presence aren't generic to all other forms of=20 > automatically > generated presence. A number of issues arise because there=20 > is a moment in > time (in the past) when a presentity (or someone entitled to=20 > publish on > their behalf) speculates on their future status - this=20 > creates issues with > when presence is published (should it be when the prediction=20 > is made, or > when the predicted time arrives?) how presence is timestamped (when a > publisher publishes, does it generate and timestamp a tuple=20 > then, or is the > tuple generated and timestamped when the prediction is made?), how > precedence is determined (i.e. do timestamps suffice for=20 > precedence of > presence information when comparing two published tuples=20 > that cover the same > resource?) and so on.=20 After looking at this thread a bit more carefully, I agree with this = distinction made about predictive presence, i.e., that publishing a = prediction is different from making a prediction and then publishing the = event as it was actually predicted to occur. I agree that both ways are probably equally valid ways but do have = different properties. When I was saying there is probably nothing more = to standardize, I was only thinking of the latter one. =20 [snip] > Finally, let me stress once again I think predictive presence is > interesting, valuable, and something we should take on - I=20 > just think we > should take it on separately from our more modest goals. There is a > reasonable distinction to make, I think, between predictive=20 > presence and > 'regular' presence. Agreed. Cheers, Aki =20 > > Similarly, as Brian and other have pointed out, any automatic=20 > > information will occasionally be wrong (but they believe,=20 > if I interpret=20 > > them correctly) that the probability of correctness is higher. In=20 > > general, I tend to favor "automatic with override" on all=20 > elements, but=20 > > that's again a policy issue. Others might want "automatic=20 > with mandatory=20 > > approval" or "hey, it's a guess anyway". > >=20 >=20 > I agree with Brian and virtually everyone else that=20 > automatically generated > presence is superior - I'm just not sure I group predictive=20 > presence into > that category, for the reasons given above. If dealing with=20 > predictive > presence is left totally to local policy, then dueling=20 > automatons are a real > possibility, I think. >=20 > > >=20 > > > In other words, the Call-Info method of delivering=20 > vCards and icons > > > shouldn't be ruled out on the grounds that some protocol=20 > other than SIP > > > can't available itself of it. > >=20 > > Agreed; as I noted, with composition, Call-Info won't do=20 > the trick, so=20 > > this is just another reason. > >=20 >=20 > And I noted that Call-Info w/ icon might appear in an=20 > INVITE, not a NOTIFY. > The requirement that the icon needs to be transmitted with=20 > presence data is > what I am questioning. If we grant that the icon should be=20 > transmitted with > presence data, I agree that the tuple is a better location that the > Call-Info header, because of the aforementioned composition issue. >=20 > Since we don't have any reference requirements to fall back,=20 > this may be a > tough issue to resolve (mind you, I'm NOT suggesting that we=20 > start some kind > of requirements phase for this). I suppose I tend to=20 > advocate removing > features much moreso than retaining them when they are borderline, > especially when I'm not sure they are necessary for the=20 > application we're > trying to enable. >=20 > > This is an element where I agree this can be considered borderline. > >=20 > > > I don't see why presence has to be the carrier of this reference. > >=20 > > Particularly for complicated presence documents, a=20 > presentity-supplied=20 > > icon may well be the best short-hand for a tuple since it=20 > can capture=20 > > information that is hard to express otherwise. (Well,=20 > beyond the "beach=20 > > with sunset" rubbing in that the presentity is on vacation and the=20 > > watcher is not...) Existing presence systems don't have=20 > multiple tuples=20 > > for each presentity, so this less of an issue. I don't see how a=20 > > message-based icon in messaging helps with rendering=20 > presence status in=20 > > a quick-to-grasp form. > >=20 >=20 > Again, commercial instant messaging systems, in my=20 > experience, don't use > presentity-provided icons to express a presentity's current=20 > state in a > watcher's buddylist screen. Apps might have predefined icons=20 > corresponding > to, say, your state as given in rpids-00, but I=20 > don't think I've > seen user-supplied versions of those icons to date. The=20 > whole value of these > buddylist icons is that they're the same for all users in the same > - if your used-defined icon for 'away' looks=20 > different from > somebody else icon for 'away', then icons aren't making the=20 > buddylist screen > any easier to interpret. The custom icons that are used in=20 > commercial IM&P > products today show up in a different context, afaik. >=20 > Jon Peterson > NeuStar, Inc. >=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-admin@ietf.org Fri Jul 4 14:08:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03507; Fri, 4 Jul 2003 14:08:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YUya-0000dm-00; Fri, 04 Jul 2003 14:08:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YUyZ-0000dj-00; Fri, 04 Jul 2003 14:08:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YUyX-0002KF-LU; Fri, 04 Jul 2003 14:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YUy6-0002B6-D9 for simple@optimus.ietf.org; Fri, 04 Jul 2003 14:07:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03476 for ; Fri, 4 Jul 2003 14:07:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YUy4-0000dA-00 for simple@ietf.org; Fri, 04 Jul 2003 14:07:32 -0400 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 19YUy3-0000cV-00 for simple@ietf.org; Fri, 04 Jul 2003 14:07:31 -0400 Received: from chiimc01.npac.com ([10.32.90.4]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id h64I6tN24780; Fri, 4 Jul 2003 18:06:55 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 13:09:37 -0500 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Henning Schulzrinne'" Cc: "Simpletons (E-mail)" Subject: RE: [Simple] comments on rpids-01 - MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 4 Jul 2003 13:07:43 -0500 > > What second AoR? You mean, one in the URI? Is that URI necessarily > > an AoR? If not, then there's no guarantee it will be distinguishable by a > > human from a plausible contact address for the 'primary' presentity. If it > > is necessarily an AoR, that creates some requirements for publishing using > > s in tuples containing a than diverge from ordinary > > behavior. > > Doesn't matter if it is an AOR. Clearly, if it's a tel URI, it will be > hard to tell if its your personal line, your secretary or the front > desk. I was thinking of SIP URIs, as in sip:bob.secretary@example.com > Well, that's why I asked if it's an AoR - if it looks like sip:bobs.secretary@example.com, then there's at least a strong hint that this is not Bob's own address. If it's sip:jio3@192.168.1.75, or some other contact address (even a GRUU), it might not be so obvious. So it isn't clear to me that baseline PIDF implementations will be able to trivially determine > Again, the crucial part is that listing this additional contact > explicitly rather than 'hiding' it behind the presentity's Contact > address is never any worse in terms of surprise for the non-RPIDS > watcher and with the label is always better for the RPIDS > capable watcher. > There are alternatives that might also work, such as having separate documents for the two presentities whose presence is represented. In that instance, it is a surprise to neither the baseline PIDF nor RPIDS watcher that 'related' presence information represents someone else. [snip] > The problem is that there is no easy and intuitive way to let you know > that part of my presence is my assistant (whom the watcher does not know > and has not met). Agreed, which is why receiving two presence for separate entities might be preferable. > In real life, we do treat other people as temporary > 'fill-ins' for ourselves, making an 'is this expected to be useful' > calculus. When I subscribe, I don't get to explicitly ask to "don't send > me all your devices, I only want the ones I care about". The point being that 'fill-ins' have their own devices, which do not belong to or describe the person being filled-in for. > Given how > things work today, what will happen is that people will simply add their > assistant to their presence document with or without the > label since that's probably one of the more useful applications of > having multiple tuples for one presentity. > That's one way things could turn out. Or, we could provide an alternative to that in which things are more explicit and compatible - implementers and users could of course disregard the standard, but at least we did our best. Anyway, I don't think that this is the intended use of multiple tuples for a presentity - I think that originally, multiple tuples were intended to indicate multiple means of contact (URI schemes) for the same presentity, whether that entailed multiple devices, interfaces, or what have you. [snip] > I agree that a callee attribute in draft-ietf-sip-callee-caps might well > be useful. We have the notion of 'attendant', but this simply says that > the call will be answered by some other party, not that this Contact URI > *is* an attendant. > Right. I think it is useful to view this as a general SIP problem: that there can be an AoR that has one or more support AoRs (as opposed to devices) registered behind it, and that consequently it might be useful to supply a parameter that says how the parties behind such support AoRs are related to the primary AoR. It might be useful for a normal user agent to be able to look at a redirection when such callee caps appear and for the user to decide "well, no, I don't want to talk to any of Bob's family members". > > > > The bottom line, from my perspective, is that is essentially > > a selective override of the 'entity' attribute of - not something > > that's likely to be compatible with baseline PIDF. > > I still don't see how this breaks compatibility with baseline PIDF. > Because you have an entity tag saying 'this is presence for Bob' when some tuples underneath provide presence for someone else. There is no requirement that we organize presence documents in such a way that someone else's presence can appear in Bob's document - it is this notion that I think breaks compatibility with baseline PIDF (in which it's a safe assumption that tuples describe the presentity named in the 'entity' tag). If there were such a requirement, it might motivate as it stands, agreed. But I think the real, underlying requirement is just that you can subscribe to someone's presence and receive presence for related parties. That underlying requirement can probably be satisfied for SIP in other ways, including redirecting SUBSCRIBEs to multiple targets. Jon Peterson NeuStar, Inc. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jul 4 14:08:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03566 for ; Fri, 4 Jul 2003 14:08:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YUyd-0002Ly-Dx for simple-archive@odin.ietf.org; Fri, 04 Jul 2003 14:08:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64I87A3009036 for simple-archive@odin.ietf.org; Fri, 4 Jul 2003 14:08:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YUyc-0002Lb-Vh for simple-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 14:08:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03507; Fri, 4 Jul 2003 14:08:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YUya-0000dm-00; Fri, 04 Jul 2003 14:08:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YUyZ-0000dj-00; Fri, 04 Jul 2003 14:08:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YUyX-0002KF-LU; Fri, 04 Jul 2003 14:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YUy6-0002B6-D9 for simple@optimus.ietf.org; Fri, 04 Jul 2003 14:07:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03476 for ; Fri, 4 Jul 2003 14:07:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YUy4-0000dA-00 for simple@ietf.org; Fri, 04 Jul 2003 14:07:32 -0400 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 19YUy3-0000cV-00 for simple@ietf.org; Fri, 04 Jul 2003 14:07:31 -0400 Received: from chiimc01.npac.com ([10.32.90.4]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id h64I6tN24780; Fri, 4 Jul 2003 18:06:55 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 13:09:37 -0500 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Henning Schulzrinne'" Cc: "Simpletons (E-mail)" Subject: RE: [Simple] comments on rpids-01 - MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 4 Jul 2003 13:07:43 -0500 > > What second AoR? You mean, one in the URI? Is that URI necessarily > > an AoR? If not, then there's no guarantee it will be distinguishable by a > > human from a plausible contact address for the 'primary' presentity. If it > > is necessarily an AoR, that creates some requirements for publishing using > > s in tuples containing a than diverge from ordinary > > behavior. > > Doesn't matter if it is an AOR. Clearly, if it's a tel URI, it will be > hard to tell if its your personal line, your secretary or the front > desk. I was thinking of SIP URIs, as in sip:bob.secretary@example.com > Well, that's why I asked if it's an AoR - if it looks like sip:bobs.secretary@example.com, then there's at least a strong hint that this is not Bob's own address. If it's sip:jio3@192.168.1.75, or some other contact address (even a GRUU), it might not be so obvious. So it isn't clear to me that baseline PIDF implementations will be able to trivially determine > Again, the crucial part is that listing this additional contact > explicitly rather than 'hiding' it behind the presentity's Contact > address is never any worse in terms of surprise for the non-RPIDS > watcher and with the label is always better for the RPIDS > capable watcher. > There are alternatives that might also work, such as having separate documents for the two presentities whose presence is represented. In that instance, it is a surprise to neither the baseline PIDF nor RPIDS watcher that 'related' presence information represents someone else. [snip] > The problem is that there is no easy and intuitive way to let you know > that part of my presence is my assistant (whom the watcher does not know > and has not met). Agreed, which is why receiving two presence for separate entities might be preferable. > In real life, we do treat other people as temporary > 'fill-ins' for ourselves, making an 'is this expected to be useful' > calculus. When I subscribe, I don't get to explicitly ask to "don't send > me all your devices, I only want the ones I care about". The point being that 'fill-ins' have their own devices, which do not belong to or describe the person being filled-in for. > Given how > things work today, what will happen is that people will simply add their > assistant to their presence document with or without the > label since that's probably one of the more useful applications of > having multiple tuples for one presentity. > That's one way things could turn out. Or, we could provide an alternative to that in which things are more explicit and compatible - implementers and users could of course disregard the standard, but at least we did our best. Anyway, I don't think that this is the intended use of multiple tuples for a presentity - I think that originally, multiple tuples were intended to indicate multiple means of contact (URI schemes) for the same presentity, whether that entailed multiple devices, interfaces, or what have you. [snip] > I agree that a callee attribute in draft-ietf-sip-callee-caps might well > be useful. We have the notion of 'attendant', but this simply says that > the call will be answered by some other party, not that this Contact URI > *is* an attendant. > Right. I think it is useful to view this as a general SIP problem: that there can be an AoR that has one or more support AoRs (as opposed to devices) registered behind it, and that consequently it might be useful to supply a parameter that says how the parties behind such support AoRs are related to the primary AoR. It might be useful for a normal user agent to be able to look at a redirection when such callee caps appear and for the user to decide "well, no, I don't want to talk to any of Bob's family members". > > > > The bottom line, from my perspective, is that is essentially > > a selective override of the 'entity' attribute of - not something > > that's likely to be compatible with baseline PIDF. > > I still don't see how this breaks compatibility with baseline PIDF. > Because you have an entity tag saying 'this is presence for Bob' when some tuples underneath provide presence for someone else. There is no requirement that we organize presence documents in such a way that someone else's presence can appear in Bob's document - it is this notion that I think breaks compatibility with baseline PIDF (in which it's a safe assumption that tuples describe the presentity named in the 'entity' tag). If there were such a requirement, it might motivate as it stands, agreed. But I think the real, underlying requirement is just that you can subscribe to someone's presence and receive presence for related parties. That underlying requirement can probably be satisfied for SIP in other ways, including redirecting SUBSCRIBEs to multiple targets. Jon Peterson NeuStar, Inc. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 7 11:03:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28802; Mon, 7 Jul 2003 11:03:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZXWD-0005CL-00; Mon, 07 Jul 2003 11:03:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZXWD-0005CG-00; Mon, 07 Jul 2003 11:03:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXW9-0005cR-KH; Mon, 07 Jul 2003 11:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXVP-0005ZI-Nj for simple@optimus.ietf.org; Mon, 07 Jul 2003 11:02:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28776 for ; Mon, 7 Jul 2003 11:02:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZXVN-0005Bi-00 for simple@ietf.org; Mon, 07 Jul 2003 11:02:13 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZXVM-0005BQ-00 for simple@ietf.org; Mon, 07 Jul 2003 11:02:12 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h67F1aB17312 for ; Mon, 7 Jul 2003 10:01:36 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1057590093.931.38.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] WGLC: draft-ietf-simple-message-sessions-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 07 Jul 2003 10:01:34 -0500 Content-Transfer-Encoding: 7bit This is a SIMPLE Working Group Last Call for comments on: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-01.txt This last call will end July 31st. Note that this draft still contains minor open issues. These are expected to be resolved at or before next week's meeting. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 7 11:03:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28831 for ; Mon, 7 Jul 2003 11:03:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXWG-0005dN-P7 for simple-archive@odin.ietf.org; Mon, 07 Jul 2003 11:03:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67F38lP021653 for simple-archive@odin.ietf.org; Mon, 7 Jul 2003 11:03:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXWG-0005dA-L2 for simple-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 11:03:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28802; Mon, 7 Jul 2003 11:03:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZXWD-0005CL-00; Mon, 07 Jul 2003 11:03:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZXWD-0005CG-00; Mon, 07 Jul 2003 11:03:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXW9-0005cR-KH; Mon, 07 Jul 2003 11:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXVP-0005ZI-Nj for simple@optimus.ietf.org; Mon, 07 Jul 2003 11:02:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28776 for ; Mon, 7 Jul 2003 11:02:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZXVN-0005Bi-00 for simple@ietf.org; Mon, 07 Jul 2003 11:02:13 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZXVM-0005BQ-00 for simple@ietf.org; Mon, 07 Jul 2003 11:02:12 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h67F1aB17312 for ; Mon, 7 Jul 2003 10:01:36 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1057590093.931.38.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] WGLC: draft-ietf-simple-message-sessions-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 07 Jul 2003 10:01:34 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is a SIMPLE Working Group Last Call for comments on: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-01.txt This last call will end July 31st. Note that this draft still contains minor open issues. These are expected to be resolved at or before next week's meeting. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 7 11:09:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29062; Mon, 7 Jul 2003 11:09:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZXbz-0005Hf-00; Mon, 07 Jul 2003 11:09:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZXby-0005Hc-00; Mon, 07 Jul 2003 11:09:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXby-0006EV-73; Mon, 07 Jul 2003 11:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXbY-0006Dz-Fi for simple@optimus.ietf.org; Mon, 07 Jul 2003 11:08:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29055 for ; Mon, 7 Jul 2003 11:08:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZXbV-0005HS-00 for simple@ietf.org; Mon, 07 Jul 2003 11:08:33 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZXbV-0005HF-00 for simple@ietf.org; Mon, 07 Jul 2003 11:08:33 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h67F82B17388 for ; Mon, 7 Jul 2003 10:08:02 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1057590480.946.43.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] WGLC: draft-ietf-simple-publish-reqs-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 07 Jul 2003 10:08:00 -0500 Content-Transfer-Encoding: 7bit This is a SIMPLE Working Group Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-simple-publish-reqs-00.txt This Last Call will end July 25. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 7 11:09:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29086 for ; Mon, 7 Jul 2003 11:09:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXc2-0006Hs-FK for simple-archive@odin.ietf.org; Mon, 07 Jul 2003 11:09:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67F96o7024162 for simple-archive@odin.ietf.org; Mon, 7 Jul 2003 11:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXc2-0006Hd-Bm for simple-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 11:09:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29062; Mon, 7 Jul 2003 11:09:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZXbz-0005Hf-00; Mon, 07 Jul 2003 11:09:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZXby-0005Hc-00; Mon, 07 Jul 2003 11:09:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXby-0006EV-73; Mon, 07 Jul 2003 11:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXbY-0006Dz-Fi for simple@optimus.ietf.org; Mon, 07 Jul 2003 11:08:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29055 for ; Mon, 7 Jul 2003 11:08:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZXbV-0005HS-00 for simple@ietf.org; Mon, 07 Jul 2003 11:08:33 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZXbV-0005HF-00 for simple@ietf.org; Mon, 07 Jul 2003 11:08:33 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h67F82B17388 for ; Mon, 7 Jul 2003 10:08:02 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1057590480.946.43.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] WGLC: draft-ietf-simple-publish-reqs-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 07 Jul 2003 10:08:00 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is a SIMPLE Working Group Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-simple-publish-reqs-00.txt This Last Call will end July 25. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 7 13:39:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04811; Mon, 7 Jul 2003 13:39:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZZx9-0007La-00; Mon, 07 Jul 2003 13:39:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZZx9-0007LX-00; Mon, 07 Jul 2003 13:39:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZx7-0007wQ-HD; Mon, 07 Jul 2003 13:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZx5-0007wE-Kw for simple@optimus.ietf.org; Mon, 07 Jul 2003 13:38:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04807 for ; Mon, 7 Jul 2003 13:38:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZZx3-0007LR-00 for simple@ietf.org; Mon, 07 Jul 2003 13:38:57 -0400 Received: from web41508.mail.yahoo.com ([66.218.93.91]) by ietf-mx with smtp (Exim 4.12) id 19ZZx2-0007L1-00 for simple@ietf.org; Mon, 07 Jul 2003 13:38:56 -0400 Message-ID: <20030707173820.21502.qmail@web41508.mail.yahoo.com> Received: from [207.46.228.98] by web41508.mail.yahoo.com via HTTP; Mon, 07 Jul 2003 10:38:20 PDT From: Sean Olson Subject: Re: [Simple] WGLC: draft-ietf-simple-publish-reqs-00.txt To: Robert Sparks , simple@ietf.org In-Reply-To: <1057590480.946.43.camel@RjS.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 10:38:20 -0700 (PDT) Req. 12 refers to "segments" of publication. We should probably define something more crisp here, perhaps using the output of the "What is a tuple?" design team. This should take into account Req. 13 as well, in particular answering the question of whether a segment is identified by a tuple ID or not. Req. 14 does not relate to publication explicitly and should probably be removed. Req. 19 probably deserves some motivating text as this relates to end-to-end integrity protection (and potentially encryption) of the published presence segment. The security considerations section refers to the "PUBLISH" method and this text should probably be moved to the PUBLISH mechanism draft. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 7 13:39:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04853 for ; Mon, 7 Jul 2003 13:39:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZxC-0007x8-94 for simple-archive@odin.ietf.org; Mon, 07 Jul 2003 13:39:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Hd6F0030564 for simple-archive@odin.ietf.org; Mon, 7 Jul 2003 13:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZxC-0007wt-4x for simple-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 13:39:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04811; Mon, 7 Jul 2003 13:39:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZZx9-0007La-00; Mon, 07 Jul 2003 13:39:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZZx9-0007LX-00; Mon, 07 Jul 2003 13:39:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZx7-0007wQ-HD; Mon, 07 Jul 2003 13:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZx5-0007wE-Kw for simple@optimus.ietf.org; Mon, 07 Jul 2003 13:38:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04807 for ; Mon, 7 Jul 2003 13:38:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZZx3-0007LR-00 for simple@ietf.org; Mon, 07 Jul 2003 13:38:57 -0400 Received: from web41508.mail.yahoo.com ([66.218.93.91]) by ietf-mx with smtp (Exim 4.12) id 19ZZx2-0007L1-00 for simple@ietf.org; Mon, 07 Jul 2003 13:38:56 -0400 Message-ID: <20030707173820.21502.qmail@web41508.mail.yahoo.com> Received: from [207.46.228.98] by web41508.mail.yahoo.com via HTTP; Mon, 07 Jul 2003 10:38:20 PDT From: Sean Olson Subject: Re: [Simple] WGLC: draft-ietf-simple-publish-reqs-00.txt To: Robert Sparks , simple@ietf.org In-Reply-To: <1057590480.946.43.camel@RjS.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 10:38:20 -0700 (PDT) Req. 12 refers to "segments" of publication. We should probably define something more crisp here, perhaps using the output of the "What is a tuple?" design team. This should take into account Req. 13 as well, in particular answering the question of whether a segment is identified by a tuple ID or not. Req. 14 does not relate to publication explicitly and should probably be removed. Req. 19 probably deserves some motivating text as this relates to end-to-end integrity protection (and potentially encryption) of the published presence segment. The security considerations section refers to the "PUBLISH" method and this text should probably be moved to the PUBLISH mechanism draft. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 7 15:31:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10658; Mon, 7 Jul 2003 15:31:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zbhc-0001TM-00; Mon, 07 Jul 2003 15:31:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zbhb-0001TI-00; Mon, 07 Jul 2003 15:31:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZbhV-0006sY-Mc; Mon, 07 Jul 2003 15:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YWDs-0000dY-6s for simple@optimus.ietf.org; Fri, 04 Jul 2003 15:27:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06187 for ; Fri, 4 Jul 2003 15:27:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YWDq-0001XR-00 for simple@ietf.org; Fri, 04 Jul 2003 15:27:55 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 19YWDq-0001XA-00 for simple@ietf.org; Fri, 04 Jul 2003 15:27:54 -0400 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h64JROAP014854; Fri, 4 Jul 2003 14:27:24 -0500 (CDT) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 317T8XTC; Fri, 4 Jul 2003 14:27:13 -0500 Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.12.9/8.12.9) with ESMTP id h64JRNwP007638; Fri, 4 Jul 2003 15:27:23 -0400 (EDT) Received: by eammlex034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 4 Jul 2003 15:27:23 -0400 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C9108@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'aki.niemi@nokia.com'" , simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Simple] Refreshing event State - New PUBLISH draft 01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 4 Jul 2003 15:23:48 -0400 Hi, Step 10 in setcion 6 (processing PUBLISH Requests), implies that for all PUBLISH requests, including those related to refreshing existing event states, the ESC shall include an entity tag. Is that the case ? If that is the case, I am unclear as to why that is needed for the refresh case? Cant the UAC assume that the absence of an entity tag in the refresh cases simply imply resuing the same entity tag for future refreshes? Also, if the ESC has to return an enity tag in the response, can the ESC reuse the same entity tag in such a case, or does it have to be a new one? Finally, it would be desirable to expand section 5.3, where the issue is discussed, with these details. Thanks George Foti Ericsson Canada _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 7 15:31:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10685 for ; Mon, 7 Jul 2003 15:31:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbhe-0006u7-Kz for simple-archive@odin.ietf.org; Mon, 07 Jul 2003 15:31:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67JVAVr026533 for simple-archive@odin.ietf.org; Mon, 7 Jul 2003 15:31:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbhe-0006ts-FW for simple-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 15:31:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10658; Mon, 7 Jul 2003 15:31:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zbhc-0001TM-00; Mon, 07 Jul 2003 15:31:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zbhb-0001TI-00; Mon, 07 Jul 2003 15:31:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZbhV-0006sY-Mc; Mon, 07 Jul 2003 15:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YWDs-0000dY-6s for simple@optimus.ietf.org; Fri, 04 Jul 2003 15:27:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06187 for ; Fri, 4 Jul 2003 15:27:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YWDq-0001XR-00 for simple@ietf.org; Fri, 04 Jul 2003 15:27:55 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 19YWDq-0001XA-00 for simple@ietf.org; Fri, 04 Jul 2003 15:27:54 -0400 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h64JROAP014854; Fri, 4 Jul 2003 14:27:24 -0500 (CDT) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 317T8XTC; Fri, 4 Jul 2003 14:27:13 -0500 Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.12.9/8.12.9) with ESMTP id h64JRNwP007638; Fri, 4 Jul 2003 15:27:23 -0400 (EDT) Received: by eammlex034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 4 Jul 2003 15:27:23 -0400 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C9108@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'aki.niemi@nokia.com'" , simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Simple] Refreshing event State - New PUBLISH draft 01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 4 Jul 2003 15:23:48 -0400 Hi, Step 10 in setcion 6 (processing PUBLISH Requests), implies that for all PUBLISH requests, including those related to refreshing existing event states, the ESC shall include an entity tag. Is that the case ? If that is the case, I am unclear as to why that is needed for the refresh case? Cant the UAC assume that the absence of an entity tag in the refresh cases simply imply resuing the same entity tag for future refreshes? Also, if the ESC has to return an enity tag in the response, can the ESC reuse the same entity tag in such a case, or does it have to be a new one? Finally, it would be desirable to expand section 5.3, where the issue is discussed, with these details. Thanks George Foti Ericsson Canada _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 7 16:27:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13489; Mon, 7 Jul 2003 16:27:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZcZm-0002Gh-00; Mon, 07 Jul 2003 16:27:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZcZl-0002Ge-00; Mon, 07 Jul 2003 16:27:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcZi-0002oe-45; Mon, 07 Jul 2003 16:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcZg-0002oR-TS for simple@optimus.ietf.org; Mon, 07 Jul 2003 16:27:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13480 for ; Mon, 7 Jul 2003 16:26:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZcZf-0002GP-00 for simple@ietf.org; Mon, 07 Jul 2003 16:26:59 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZcZe-0002G3-00 for simple@ietf.org; Mon, 07 Jul 2003 16:26:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h67KQRB20392 for ; Mon, 7 Jul 2003 15:26:27 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1057609580.946.63.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Initial Agenda: SIMPLE: IETF57 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 07 Jul 2003 15:26:20 -0500 Content-Transfer-Encoding: 7bit Here is the current plan for the agenda at next week's meeting. Please let me know of any problems as soon as you can. RjS --------------------------------------------------------------- Administrivia/Agenda Bashing - 5 min Architecture draft - 5 min Message Sessions - 15 min Data Manipulation - 25 min Publish - 10 min (plus 10 minutes in SIP) Filtering/Partial Not. Reqs - 10 min Filtering Mechanism - 10 min Partial Notify mechanism - 10 min RPIDS (not capabilities) - 20 min Presence capabilities - 10 min _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 7 16:27:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13518 for ; Mon, 7 Jul 2003 16:27:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcZo-0002qV-LF for simple-archive@odin.ietf.org; Mon, 07 Jul 2003 16:27:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67KR8cR010933 for simple-archive@odin.ietf.org; Mon, 7 Jul 2003 16:27:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcZo-0002qG-HJ for simple-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 16:27:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13489; Mon, 7 Jul 2003 16:27:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZcZm-0002Gh-00; Mon, 07 Jul 2003 16:27:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZcZl-0002Ge-00; Mon, 07 Jul 2003 16:27:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcZi-0002oe-45; Mon, 07 Jul 2003 16:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcZg-0002oR-TS for simple@optimus.ietf.org; Mon, 07 Jul 2003 16:27:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13480 for ; Mon, 7 Jul 2003 16:26:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZcZf-0002GP-00 for simple@ietf.org; Mon, 07 Jul 2003 16:26:59 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZcZe-0002G3-00 for simple@ietf.org; Mon, 07 Jul 2003 16:26:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h67KQRB20392 for ; Mon, 7 Jul 2003 15:26:27 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1057609580.946.63.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Initial Agenda: SIMPLE: IETF57 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 07 Jul 2003 15:26:20 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Here is the current plan for the agenda at next week's meeting. Please let me know of any problems as soon as you can. RjS --------------------------------------------------------------- Administrivia/Agenda Bashing - 5 min Architecture draft - 5 min Message Sessions - 15 min Data Manipulation - 25 min Publish - 10 min (plus 10 minutes in SIP) Filtering/Partial Not. Reqs - 10 min Filtering Mechanism - 10 min Partial Notify mechanism - 10 min RPIDS (not capabilities) - 20 min Presence capabilities - 10 min _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 8 02:43:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11800; Tue, 8 Jul 2003 02:43:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZmBt-0006w3-00; Tue, 08 Jul 2003 02:43:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZmBt-0006w0-00; Tue, 08 Jul 2003 02:43:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmBo-0007X7-Te; Tue, 08 Jul 2003 02:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmBl-0007Wb-E7 for simple@optimus.ietf.org; Tue, 08 Jul 2003 02:42:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11786 for ; Tue, 8 Jul 2003 02:42:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZmBh-0006vl-00 for simple@ietf.org; Tue, 08 Jul 2003 02:42:53 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZmBg-0006vT-00 for simple@ietf.org; Tue, 08 Jul 2003 02:42:52 -0400 Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h686gKiB005488 for ; Tue, 8 Jul 2003 02:42:26 -0400 (EDT) Message-ID: <3F0A67C6.9070004@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 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 Content-Transfer-Encoding: 7bit Subject: [Simple] New I-D on presence states for phones Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 08 Jul 2003 02:42:14 -0400 Content-Transfer-Encoding: 7bit Folks, In case folks havent seen it, I wanted to call your attention to: http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-simple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html This draft, written by Jon and myself, defines some PIDF extensions for describing phones, including traditional "black" phones, wireless phones and enterprise phones. I think these will provide invaluable for a device-centric view of a presentity. Comments and questions welcome. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 8 02:43:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11860 for ; Tue, 8 Jul 2003 02:43:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmBy-0007aQ-18 for simple-archive@odin.ietf.org; Tue, 08 Jul 2003 02:43:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h686hAh0029161 for simple-archive@odin.ietf.org; Tue, 8 Jul 2003 02:43:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmBx-0007aG-R7 for simple-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 02:43:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11800; Tue, 8 Jul 2003 02:43:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZmBt-0006w3-00; Tue, 08 Jul 2003 02:43:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZmBt-0006w0-00; Tue, 08 Jul 2003 02:43:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmBo-0007X7-Te; Tue, 08 Jul 2003 02:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmBl-0007Wb-E7 for simple@optimus.ietf.org; Tue, 08 Jul 2003 02:42:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11786 for ; Tue, 8 Jul 2003 02:42:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZmBh-0006vl-00 for simple@ietf.org; Tue, 08 Jul 2003 02:42:53 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZmBg-0006vT-00 for simple@ietf.org; Tue, 08 Jul 2003 02:42:52 -0400 Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h686gKiB005488 for ; Tue, 8 Jul 2003 02:42:26 -0400 (EDT) Message-ID: <3F0A67C6.9070004@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 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 Content-Transfer-Encoding: 7bit Subject: [Simple] New I-D on presence states for phones Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 08 Jul 2003 02:42:14 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, In case folks havent seen it, I wanted to call your attention to: http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-simple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html This draft, written by Jon and myself, defines some PIDF extensions for describing phones, including traditional "black" phones, wireless phones and enterprise phones. I think these will provide invaluable for a device-centric view of a presentity. Comments and questions welcome. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 8 02:48:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12080; Tue, 8 Jul 2003 02:47:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZmGd-00070h-00; Tue, 08 Jul 2003 02:47:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZmGd-00070e-00; Tue, 08 Jul 2003 02:47:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmGe-00088I-8k; Tue, 08 Jul 2003 02:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmFj-000876-16 for simple@optimus.ietf.org; Tue, 08 Jul 2003 02:47:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12074 for ; Tue, 8 Jul 2003 02:46:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZmFf-00070W-00 for simple@ietf.org; Tue, 08 Jul 2003 02:46:59 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZmFe-00070S-00 for simple@ietf.org; Tue, 08 Jul 2003 02:46:58 -0400 Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h686kLiB005494 for ; Tue, 8 Jul 2003 02:46:22 -0400 (EDT) Message-ID: <3F0A68B8.9070603@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 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 Content-Transfer-Encoding: 7bit Subject: [Simple] XCAP drafts - what changed? Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 08 Jul 2003 02:46:16 -0400 Content-Transfer-Encoding: 7bit Folks, You probably noticed that the xcap drafts were recently posted: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-00.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-package-00.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-00.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-auth-usage-00.txt Of these, the latter is totally new, and I have sent a separate note to the simple list about it. No comments or input yet. Please take a look. For the other three, I simply did not have time to do anything but change the filename to reflect the fact that they are now simple items. I'll be sending some separate notes summarizing where we are and some paths forward. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 8 02:48:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12099 for ; Tue, 8 Jul 2003 02:48:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmGi-0008Bi-MG for simple-archive@odin.ietf.org; Tue, 08 Jul 2003 02:48:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h686m4gf031469 for simple-archive@odin.ietf.org; Tue, 8 Jul 2003 02:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmGh-0008BU-Sg for simple-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 02:48:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12080; Tue, 8 Jul 2003 02:47:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZmGd-00070h-00; Tue, 08 Jul 2003 02:47:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZmGd-00070e-00; Tue, 08 Jul 2003 02:47:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmGe-00088I-8k; Tue, 08 Jul 2003 02:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmFj-000876-16 for simple@optimus.ietf.org; Tue, 08 Jul 2003 02:47:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12074 for ; Tue, 8 Jul 2003 02:46:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZmFf-00070W-00 for simple@ietf.org; Tue, 08 Jul 2003 02:46:59 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZmFe-00070S-00 for simple@ietf.org; Tue, 08 Jul 2003 02:46:58 -0400 Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h686kLiB005494 for ; Tue, 8 Jul 2003 02:46:22 -0400 (EDT) Message-ID: <3F0A68B8.9070603@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 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 Content-Transfer-Encoding: 7bit Subject: [Simple] XCAP drafts - what changed? Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 08 Jul 2003 02:46:16 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, You probably noticed that the xcap drafts were recently posted: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-00.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-package-00.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-00.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-auth-usage-00.txt Of these, the latter is totally new, and I have sent a separate note to the simple list about it. No comments or input yet. Please take a look. For the other three, I simply did not have time to do anything but change the filename to reflect the fact that they are now simple items. I'll be sending some separate notes summarizing where we are and some paths forward. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 8 04:58:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14679; Tue, 8 Jul 2003 04:58:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZoIX-0007hL-00; Tue, 08 Jul 2003 04:58:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZoIX-0007hI-00; Tue, 08 Jul 2003 04:58:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoIU-0005sT-C1; Tue, 08 Jul 2003 04:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoHy-0005q1-Ls for simple@optimus.ietf.org; Tue, 08 Jul 2003 04:57:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14671 for ; Tue, 8 Jul 2003 04:57:27 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZoHv-0007h8-00 for simple@ietf.org; Tue, 08 Jul 2003 04:57:27 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19ZoHu-0007h5-00 for simple@ietf.org; Tue, 08 Jul 2003 04:57:26 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h688vQ902680 for ; Tue, 8 Jul 2003 11:57:26 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 8 Jul 2003 11:57:26 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 8 Jul 2003 11:57:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] Refreshing event State - New PUBLISH draft 01 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945312@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Refreshing event State - New PUBLISH draft 01 Thread-Index: AcNEvlp58CWdfr2vQOK9uU2BpzPH4gAbyYGQ To: , X-OriginalArrivalTime: 08 Jul 2003 08:57:26.0313 (UTC) FILETIME=[F4212190:01C3452E] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 11:57:25 +0300 Content-Transfer-Encoding: quoted-printable Hi George, Inline. > -----Original Message----- > From: ext George Foti (LMC) [mailto:george.foti@ericsson.com] > Sent: 04 July, 2003 22:24 > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: [Simple] Refreshing event State - New PUBLISH draft 01 >=20 >=20 > Hi, >=20 > Step 10 in setcion 6 (processing PUBLISH Requests), implies=20 > that for all PUBLISH requests, including those related to=20 > refreshing existing event states, the ESC shall include an=20 > entity tag. > =20 > Is that the case ? Correct. ETag is also listed as a mandatory header in 2xx responses to = PUBLISH in Table 3. =20 > If that is the case, I am unclear as to why that is needed=20 > for the refresh case?=20 It isn't strictly needed. There wasn't any particular reason to list it = mandatory, except that at least intuitively, it would be good to have = all success responses to PUBLISH look and behave the same. However, I'm = quite OK either way. Should we remove it? > Cant the UAC assume that the absence of an entity tag in the=20 > refresh cases simply imply resuing the same entity tag for=20 > future refreshes? I think this would work equally well. > Also, if the ESC has to return an enity tag in the response,=20 > can the ESC reuse the same entity tag in such a case, or=20 > does it have to be a new one? This was the intention. A refresh simply extends the validity lifetime = of a particular version of event state, so in that sense the entity-tag = shouldn't change. I agree this is not stated very clearly, and I will add text to that = extent. > Finally, it would be desirable to expand section 5.3, where=20 > the issue is discussed, with these details. I will try to strengthen both section 6 and section 5.3. about this. Thanks for the comments. Cheers, Aki >=20 > Thanks > George Foti > Ericsson Canada=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 exim@www1.ietf.org Tue Jul 8 04:58:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14714 for ; Tue, 8 Jul 2003 04:58:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoIb-0005w8-Ed for simple-archive@odin.ietf.org; Tue, 08 Jul 2003 04:58:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h688w9Br022819 for simple-archive@odin.ietf.org; Tue, 8 Jul 2003 04:58:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoIb-0005vy-BZ for simple-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 04:58:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14679; Tue, 8 Jul 2003 04:58:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZoIX-0007hL-00; Tue, 08 Jul 2003 04:58:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZoIX-0007hI-00; Tue, 08 Jul 2003 04:58:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoIU-0005sT-C1; Tue, 08 Jul 2003 04:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoHy-0005q1-Ls for simple@optimus.ietf.org; Tue, 08 Jul 2003 04:57:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14671 for ; Tue, 8 Jul 2003 04:57:27 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZoHv-0007h8-00 for simple@ietf.org; Tue, 08 Jul 2003 04:57:27 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19ZoHu-0007h5-00 for simple@ietf.org; Tue, 08 Jul 2003 04:57:26 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h688vQ902680 for ; Tue, 8 Jul 2003 11:57:26 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 8 Jul 2003 11:57:26 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 8 Jul 2003 11:57:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] Refreshing event State - New PUBLISH draft 01 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945312@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Refreshing event State - New PUBLISH draft 01 Thread-Index: AcNEvlp58CWdfr2vQOK9uU2BpzPH4gAbyYGQ To: , X-OriginalArrivalTime: 08 Jul 2003 08:57:26.0313 (UTC) FILETIME=[F4212190:01C3452E] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 11:57:25 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi George, Inline. > -----Original Message----- > From: ext George Foti (LMC) [mailto:george.foti@ericsson.com] > Sent: 04 July, 2003 22:24 > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: [Simple] Refreshing event State - New PUBLISH draft 01 >=20 >=20 > Hi, >=20 > Step 10 in setcion 6 (processing PUBLISH Requests), implies=20 > that for all PUBLISH requests, including those related to=20 > refreshing existing event states, the ESC shall include an=20 > entity tag. > =20 > Is that the case ? Correct. ETag is also listed as a mandatory header in 2xx responses to = PUBLISH in Table 3. =20 > If that is the case, I am unclear as to why that is needed=20 > for the refresh case?=20 It isn't strictly needed. There wasn't any particular reason to list it = mandatory, except that at least intuitively, it would be good to have = all success responses to PUBLISH look and behave the same. However, I'm = quite OK either way. Should we remove it? > Cant the UAC assume that the absence of an entity tag in the=20 > refresh cases simply imply resuing the same entity tag for=20 > future refreshes? I think this would work equally well. > Also, if the ESC has to return an enity tag in the response,=20 > can the ESC reuse the same entity tag in such a case, or=20 > does it have to be a new one? This was the intention. A refresh simply extends the validity lifetime = of a particular version of event state, so in that sense the entity-tag = shouldn't change. I agree this is not stated very clearly, and I will add text to that = extent. > Finally, it would be desirable to expand section 5.3, where=20 > the issue is discussed, with these details. I will try to strengthen both section 6 and section 5.3. about this. Thanks for the comments. Cheers, Aki >=20 > Thanks > George Foti > Ericsson Canada=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-admin@ietf.org Tue Jul 8 06:46:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17264; Tue, 8 Jul 2003 06:46:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zpz0-0000bW-00; Tue, 08 Jul 2003 06:46:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zpyz-0000bT-00; Tue, 08 Jul 2003 06:46:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zpz0-0002d3-1L; Tue, 08 Jul 2003 06:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZpyL-0002cO-SL for simple@optimus.ietf.org; Tue, 08 Jul 2003 06:45:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17248 for ; Tue, 8 Jul 2003 06:45:16 -0400 (EDT) From: eva-maria.leppanen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZpyH-0000b2-00 for simple@ietf.org; Tue, 08 Jul 2003 06:45:17 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19ZpyG-0000ax-00 for simple@ietf.org; Tue, 08 Jul 2003 06:45:17 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h68AjHa11023 for ; Tue, 8 Jul 2003 13:45:17 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 8 Jul 2003 13:45:17 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 8 Jul 2003 13:45:17 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 8 Jul 2003 13:45:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments Message-ID: <902B96A872B24840B48412649C0E8A4201543D01@trebe003.europe.nokia.com> Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt Thread-Index: AcM7TSkV+E9bZb1YReOBqxTJ6YQFMQDn0Emw To: , X-OriginalArrivalTime: 08 Jul 2003 10:45:17.0141 (UTC) FILETIME=[050B2050:01C3453E] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 13:45:16 +0300 Content-Transfer-Encoding: quoted-printable Hi, I found the draft very versatile. Please find below some comments and = questions: * "Acceptance permissions" include elements where the acceptance can be = based on the filter information. However the security considerations of = the "Presence Filter Requirements" I-D recommends as follows: "The = filter criteria should not be rejected based on the authorization policy = since this would enable the watcher by experimentation with the use of = filter criteria to determine the authorization policy the presentity has = set for him and thus discover what the presentity wants to hide from = him". * "Identifying elements" chapter says: "...that element is used as an = input to the computation of other elements..." -> what if a certain element's value is derived from two published elements = (the other is authorized but the other not)? Does the "raw piece of presence data" mean (in practise) that the = identified element is the same as (raw) published element, but it is = changed by the composer? This could be specified more clearly - it's = somehow too vague for a specification of authorization. * The tuple IDs are used for identifying the whole tuples in the = "content permissions". Is there some reason why only=20 the tuple ID can be used, and not to allow any XML element (e.g., nested = element-name/element-path elements to "show-tuple")?=20 * The "not" condition might be usable for denying a specific XML = element, namespace, value etc (in the content permissions). Using the current premissions it is only possible to make a list of all = allowed items, but not to say that "allow everything else except this information". * One element in transformational permissions is "set-document" which = allows e.g. defining a document including=20 "lies". I was wondering whether the purpose was to use this also for = allowing the presentity to define multiple level of=20 details of the semantically same presence information? Somehow I see the = solution too fixed for that purpose. The presentity might want to define e.g. different notes to different watchers or = different deltails of location information. This kind of=20 information changes more often and is more dynamic compared to the other = authorization related information. The proposal is=20 to handle the different levels of values within publishing, but the = authorization solution should support linking different levels of values = to different watchers or groups of watchers. * A comment about defining "union" for combining multiple "statement" = elements: this is a good approach for many purposes, but=20 depending on how the presence information (and tuples) are structured, = there might be a need to define e.g. that the showed value to = "*@example.com" should be "closed" but it should be "open" to = "john@example.com". The "first" match principle/ or the most specific = address principle would be more suitable in this case. It seems that = both of them would be needed. * What is the relation of the "set-document" to the default and/or hard = state publishing? Is the purpose that there will be an own usage for = hard state publishing? BR, Eva Leppanen -----Original Message----- From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 25 June, 2003 17:55 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.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 : Extensible Markup Language (XML) Configuration Access=20 Protocol (XCAP)Usages for Setting Presence=20 Authorization Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-auth-usage-00.txt Pages : 41 Date : 2003-6-24 =09 This document describes three usages of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) that allow a client to provide authorization decisions regarding watchers of their presence. The first of these usages, called permission-statements, contains statements about what permissions are to be granted to watchers of presence. The second of these usages, called compound-permissions, allows a client to define new permissions as combinations of other defined permissions. The third usage, called supported-permissions, allows a client to determine what permissions are understood by the provider. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-auth-usage-00.= txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. 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-auth-usage-00.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-xcap-auth-usage-00.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. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 8 06:46:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17282 for ; Tue, 8 Jul 2003 06:46:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zpz4-0002dx-MF for simple-archive@odin.ietf.org; Tue, 08 Jul 2003 06:46:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Ak6Ko010156 for simple-archive@odin.ietf.org; Tue, 8 Jul 2003 06:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zpz4-0002dj-JK for simple-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 06:46:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17264; Tue, 8 Jul 2003 06:46:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zpz0-0000bW-00; Tue, 08 Jul 2003 06:46:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zpyz-0000bT-00; Tue, 08 Jul 2003 06:46:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zpz0-0002d3-1L; Tue, 08 Jul 2003 06:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZpyL-0002cO-SL for simple@optimus.ietf.org; Tue, 08 Jul 2003 06:45:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17248 for ; Tue, 8 Jul 2003 06:45:16 -0400 (EDT) From: eva-maria.leppanen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZpyH-0000b2-00 for simple@ietf.org; Tue, 08 Jul 2003 06:45:17 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19ZpyG-0000ax-00 for simple@ietf.org; Tue, 08 Jul 2003 06:45:17 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h68AjHa11023 for ; Tue, 8 Jul 2003 13:45:17 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 8 Jul 2003 13:45:17 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 8 Jul 2003 13:45:17 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 8 Jul 2003 13:45:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments Message-ID: <902B96A872B24840B48412649C0E8A4201543D01@trebe003.europe.nokia.com> Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt Thread-Index: AcM7TSkV+E9bZb1YReOBqxTJ6YQFMQDn0Emw To: , X-OriginalArrivalTime: 08 Jul 2003 10:45:17.0141 (UTC) FILETIME=[050B2050:01C3453E] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 13:45:16 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I found the draft very versatile. Please find below some comments and = questions: * "Acceptance permissions" include elements where the acceptance can be = based on the filter information. However the security considerations of = the "Presence Filter Requirements" I-D recommends as follows: "The = filter criteria should not be rejected based on the authorization policy = since this would enable the watcher by experimentation with the use of = filter criteria to determine the authorization policy the presentity has = set for him and thus discover what the presentity wants to hide from = him". * "Identifying elements" chapter says: "...that element is used as an = input to the computation of other elements..." -> what if a certain element's value is derived from two published elements = (the other is authorized but the other not)? Does the "raw piece of presence data" mean (in practise) that the = identified element is the same as (raw) published element, but it is = changed by the composer? This could be specified more clearly - it's = somehow too vague for a specification of authorization. * The tuple IDs are used for identifying the whole tuples in the = "content permissions". Is there some reason why only=20 the tuple ID can be used, and not to allow any XML element (e.g., nested = element-name/element-path elements to "show-tuple")?=20 * The "not" condition might be usable for denying a specific XML = element, namespace, value etc (in the content permissions). Using the current premissions it is only possible to make a list of all = allowed items, but not to say that "allow everything else except this information". * One element in transformational permissions is "set-document" which = allows e.g. defining a document including=20 "lies". I was wondering whether the purpose was to use this also for = allowing the presentity to define multiple level of=20 details of the semantically same presence information? Somehow I see the = solution too fixed for that purpose. The presentity might want to define e.g. different notes to different watchers or = different deltails of location information. This kind of=20 information changes more often and is more dynamic compared to the other = authorization related information. The proposal is=20 to handle the different levels of values within publishing, but the = authorization solution should support linking different levels of values = to different watchers or groups of watchers. * A comment about defining "union" for combining multiple "statement" = elements: this is a good approach for many purposes, but=20 depending on how the presence information (and tuples) are structured, = there might be a need to define e.g. that the showed value to = "*@example.com" should be "closed" but it should be "open" to = "john@example.com". The "first" match principle/ or the most specific = address principle would be more suitable in this case. It seems that = both of them would be needed. * What is the relation of the "set-document" to the default and/or hard = state publishing? Is the purpose that there will be an own usage for = hard state publishing? BR, Eva Leppanen -----Original Message----- From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 25 June, 2003 17:55 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.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 : Extensible Markup Language (XML) Configuration Access=20 Protocol (XCAP)Usages for Setting Presence=20 Authorization Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-auth-usage-00.txt Pages : 41 Date : 2003-6-24 =09 This document describes three usages of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) that allow a client to provide authorization decisions regarding watchers of their presence. The first of these usages, called permission-statements, contains statements about what permissions are to be granted to watchers of presence. The second of these usages, called compound-permissions, allows a client to define new permissions as combinations of other defined permissions. The third usage, called supported-permissions, allows a client to determine what permissions are understood by the provider. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-auth-usage-00.= txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. 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-auth-usage-00.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-xcap-auth-usage-00.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. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 8 10:08:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22802; Tue, 8 Jul 2003 10:08:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zt8g-0001tS-00; Tue, 08 Jul 2003 10:08:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zt8f-0001tP-00; Tue, 08 Jul 2003 10:08:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zt8T-0004Uz-8g; Tue, 08 Jul 2003 10:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zqx1-0004zl-TL for simple@optimus.ietf.org; Tue, 08 Jul 2003 07:48:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18189 for ; Tue, 8 Jul 2003 07:48:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zqx1-0000ri-00 for simple@ietf.org; Tue, 08 Jul 2003 07:48:03 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 19Zqx0-0000re-00 for simple@ietf.org; Tue, 08 Jul 2003 07:48:02 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h68BlVAP015909; Tue, 8 Jul 2003 06:47:32 -0500 (CDT) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 3172GXXS; Tue, 8 Jul 2003 06:47:18 -0500 Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.12.9/8.12.9) with ESMTP id h68BlVGx023554; Tue, 8 Jul 2003 07:47:31 -0400 (EDT) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id <337NPVN4>; Tue, 8 Jul 2003 07:48:25 -0400 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C9111@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'aki.niemi@nokia.com'" , simple@ietf.org Subject: RE: [Simple] Refreshing event State - New PUBLISH draft 01 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 07:43:55 -0400 Aki, you wrote: >However, I'm quite OK either way. Should we remove it? Lets keep it for consistency. Rgds/gf > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Tuesday, July 08, 2003 4:57 AM > To: George Foti (QC/LMC); simple@ietf.org > Subject: RE: [Simple] Refreshing event State - New PUBLISH draft 01 > > > Hi George, > > Inline. > > > -----Original Message----- > > From: ext George Foti (LMC) [mailto:george.foti@ericsson.com] > > Sent: 04 July, 2003 22:24 > > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > > Subject: [Simple] Refreshing event State - New PUBLISH draft 01 > > > > > > Hi, > > > > Step 10 in setcion 6 (processing PUBLISH Requests), implies > > that for all PUBLISH requests, including those related to > > refreshing existing event states, the ESC shall include an > > entity tag. > > > > Is that the case ? > > Correct. ETag is also listed as a mandatory header in 2xx > responses to PUBLISH in Table 3. > > > If that is the case, I am unclear as to why that is needed > > for the refresh case? > > It isn't strictly needed. There wasn't any particular reason > to list it mandatory, except that at least intuitively, it > would be good to have all success responses to PUBLISH look > and behave the same. However, I'm quite OK either way. Should > we remove it? > > > Cant the UAC assume that the absence of an entity tag in the > > refresh cases simply imply resuing the same entity tag for > > future refreshes? > > I think this would work equally well. > > > Also, if the ESC has to return an enity tag in the response, > > can the ESC reuse the same entity tag in such a case, or > > does it have to be a new one? > > This was the intention. A refresh simply extends the validity > lifetime of a particular version of event state, so in that > sense the entity-tag shouldn't change. > > I agree this is not stated very clearly, and I will add text > to that extent. > > > Finally, it would be desirable to expand section 5.3, where > > the issue is discussed, with these details. > > I will try to strengthen both section 6 and section 5.3. about this. > > Thanks for the comments. > > Cheers, > Aki > > > > > Thanks > > George Foti > > Ericsson Canada > > > > _______________________________________________ > > 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 exim@www1.ietf.org Tue Jul 8 10:08:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22937 for ; Tue, 8 Jul 2003 10:08:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zt8j-0004Ym-46 for simple-archive@odin.ietf.org; Tue, 08 Jul 2003 10:08:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68E8HRD017529 for simple-archive@odin.ietf.org; Tue, 8 Jul 2003 10:08:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zt8i-0004Ye-Ux for simple-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 10:08:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22802; Tue, 8 Jul 2003 10:08:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zt8g-0001tS-00; Tue, 08 Jul 2003 10:08:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zt8f-0001tP-00; Tue, 08 Jul 2003 10:08:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zt8T-0004Uz-8g; Tue, 08 Jul 2003 10:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zqx1-0004zl-TL for simple@optimus.ietf.org; Tue, 08 Jul 2003 07:48:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18189 for ; Tue, 8 Jul 2003 07:48:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zqx1-0000ri-00 for simple@ietf.org; Tue, 08 Jul 2003 07:48:03 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 19Zqx0-0000re-00 for simple@ietf.org; Tue, 08 Jul 2003 07:48:02 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h68BlVAP015909; Tue, 8 Jul 2003 06:47:32 -0500 (CDT) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 3172GXXS; Tue, 8 Jul 2003 06:47:18 -0500 Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.12.9/8.12.9) with ESMTP id h68BlVGx023554; Tue, 8 Jul 2003 07:47:31 -0400 (EDT) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id <337NPVN4>; Tue, 8 Jul 2003 07:48:25 -0400 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C9111@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'aki.niemi@nokia.com'" , simple@ietf.org Subject: RE: [Simple] Refreshing event State - New PUBLISH draft 01 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 07:43:55 -0400 Aki, you wrote: >However, I'm quite OK either way. Should we remove it? Lets keep it for consistency. Rgds/gf > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Tuesday, July 08, 2003 4:57 AM > To: George Foti (QC/LMC); simple@ietf.org > Subject: RE: [Simple] Refreshing event State - New PUBLISH draft 01 > > > Hi George, > > Inline. > > > -----Original Message----- > > From: ext George Foti (LMC) [mailto:george.foti@ericsson.com] > > Sent: 04 July, 2003 22:24 > > To: Niemi Aki (NMP/Helsinki); simple@ietf.org > > Subject: [Simple] Refreshing event State - New PUBLISH draft 01 > > > > > > Hi, > > > > Step 10 in setcion 6 (processing PUBLISH Requests), implies > > that for all PUBLISH requests, including those related to > > refreshing existing event states, the ESC shall include an > > entity tag. > > > > Is that the case ? > > Correct. ETag is also listed as a mandatory header in 2xx > responses to PUBLISH in Table 3. > > > If that is the case, I am unclear as to why that is needed > > for the refresh case? > > It isn't strictly needed. There wasn't any particular reason > to list it mandatory, except that at least intuitively, it > would be good to have all success responses to PUBLISH look > and behave the same. However, I'm quite OK either way. Should > we remove it? > > > Cant the UAC assume that the absence of an entity tag in the > > refresh cases simply imply resuing the same entity tag for > > future refreshes? > > I think this would work equally well. > > > Also, if the ESC has to return an enity tag in the response, > > can the ESC reuse the same entity tag in such a case, or > > does it have to be a new one? > > This was the intention. A refresh simply extends the validity > lifetime of a particular version of event state, so in that > sense the entity-tag shouldn't change. > > I agree this is not stated very clearly, and I will add text > to that extent. > > > Finally, it would be desirable to expand section 5.3, where > > the issue is discussed, with these details. > > I will try to strengthen both section 6 and section 5.3. about this. > > Thanks for the comments. > > Cheers, > Aki > > > > > Thanks > > George Foti > > Ericsson Canada > > > > _______________________________________________ > > 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-admin@ietf.org Tue Jul 8 10:34:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24575; Tue, 8 Jul 2003 10:34:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZtXg-0002Ao-00; Tue, 08 Jul 2003 10:34:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZtXg-0002Al-00; Tue, 08 Jul 2003 10:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZtXd-0005Zv-G7; Tue, 08 Jul 2003 10:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZtXV-0005Zj-GM for simple@optimus.ietf.org; Tue, 08 Jul 2003 10:33:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24569 for ; Tue, 8 Jul 2003 10:33:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZtXT-0002AY-00 for simple@ietf.org; Tue, 08 Jul 2003 10:33:51 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZtXS-0002AT-00 for simple@ietf.org; Tue, 08 Jul 2003 10:33:50 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h68EXKB30161 for ; Tue, 8 Jul 2003 09:33:20 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1057674799.923.30.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Fwd: Agenda - SIMPLE - IETF57 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 Jul 2003 09:33:20 -0500 Content-Transfer-Encoding: 7bit Here is an annotated agenda for next Monday's meeting. As always, this is subject to change-by-bashing. SIMPLE - IETF 57 - Monday 14 July 1530 to 1730 1530 Administrivia/Agenda Bashing - 5 min Robert Sparks/Jon Peterson 1535 Architecture draft - 5 min Avshalom Houri draft-houri-simple-arch-01.txt 1540 Message Sessions - 15 min Ben Campbell draft-ietf-simple-message-sessions-01.txt 1555 Data Manipulation - 25 min Jonathan Rosenberg draft-ietf-simple-data-req-03.txt draft-ietf-simple-xcap-00.txt draft-ietf-simple-xcap-auth-usage-00.txt draft-ietf-simple-xcap-list-usage-00.txt draft-ietf-simple-xcap-package-00.txt 1620 Publish - 10 min Aki Niemi (This topic will also receive 10 minutes in SIP) draft-ietf-simple-publish-reqs-00.txt draft-ietf-simple-publish-01.txt 1630 Filtering/Partial Not. Reqs - 10 min Hisham Khartabil draft-ietf-simple-pres-filter-reqs-01.txt draft-ietf-simple-winfo-filter-reqs-00.txt draft-ietf-simple-presinfo-deliv-reg-00.txt 1640 Filtering Mechanism - 10 min Hisham Khartabil draft-khartabil-simple-filter-format-00.txt draft-khartabil-simple-filter-funct-00.txt draft-khartabil-simple-presence-filter-00.txt draft-khartabil-simple-winfo-filter-00.txt 1650 Partial Notify mechanism - 10 min Mikko Lonnfors draft-lonnfors-simple-partial-notify-02.txt 1700 RPIDS (not capabilities) - 20 min Henning Schulzrinne draft-ietf-simple-rpids-01.txt 1720 Presence capabilities - 10 min Henning Schulzrinne draft-ietf-simple-rpids-01.txt draft-lonnfors-simple-prescaps-ext-01.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 8 10:34:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24611 for ; Tue, 8 Jul 2003 10:34:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZtXj-0005dC-SI for simple-archive@odin.ietf.org; Tue, 08 Jul 2003 10:34:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68EY7Lq021647 for simple-archive@odin.ietf.org; Tue, 8 Jul 2003 10:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZtXj-0005d4-N6 for simple-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 10:34:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24575; Tue, 8 Jul 2003 10:34:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZtXg-0002Ao-00; Tue, 08 Jul 2003 10:34:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZtXg-0002Al-00; Tue, 08 Jul 2003 10:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZtXd-0005Zv-G7; Tue, 08 Jul 2003 10:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZtXV-0005Zj-GM for simple@optimus.ietf.org; Tue, 08 Jul 2003 10:33:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24569 for ; Tue, 8 Jul 2003 10:33:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZtXT-0002AY-00 for simple@ietf.org; Tue, 08 Jul 2003 10:33:51 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZtXS-0002AT-00 for simple@ietf.org; Tue, 08 Jul 2003 10:33:50 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h68EXKB30161 for ; Tue, 8 Jul 2003 09:33:20 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1057674799.923.30.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Fwd: Agenda - SIMPLE - IETF57 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 Jul 2003 09:33:20 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Here is an annotated agenda for next Monday's meeting. As always, this is subject to change-by-bashing. SIMPLE - IETF 57 - Monday 14 July 1530 to 1730 1530 Administrivia/Agenda Bashing - 5 min Robert Sparks/Jon Peterson 1535 Architecture draft - 5 min Avshalom Houri draft-houri-simple-arch-01.txt 1540 Message Sessions - 15 min Ben Campbell draft-ietf-simple-message-sessions-01.txt 1555 Data Manipulation - 25 min Jonathan Rosenberg draft-ietf-simple-data-req-03.txt draft-ietf-simple-xcap-00.txt draft-ietf-simple-xcap-auth-usage-00.txt draft-ietf-simple-xcap-list-usage-00.txt draft-ietf-simple-xcap-package-00.txt 1620 Publish - 10 min Aki Niemi (This topic will also receive 10 minutes in SIP) draft-ietf-simple-publish-reqs-00.txt draft-ietf-simple-publish-01.txt 1630 Filtering/Partial Not. Reqs - 10 min Hisham Khartabil draft-ietf-simple-pres-filter-reqs-01.txt draft-ietf-simple-winfo-filter-reqs-00.txt draft-ietf-simple-presinfo-deliv-reg-00.txt 1640 Filtering Mechanism - 10 min Hisham Khartabil draft-khartabil-simple-filter-format-00.txt draft-khartabil-simple-filter-funct-00.txt draft-khartabil-simple-presence-filter-00.txt draft-khartabil-simple-winfo-filter-00.txt 1650 Partial Notify mechanism - 10 min Mikko Lonnfors draft-lonnfors-simple-partial-notify-02.txt 1700 RPIDS (not capabilities) - 20 min Henning Schulzrinne draft-ietf-simple-rpids-01.txt 1720 Presence capabilities - 10 min Henning Schulzrinne draft-ietf-simple-rpids-01.txt draft-lonnfors-simple-prescaps-ext-01.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 8 11:04:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25515; Tue, 8 Jul 2003 11:04:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zu0o-0002NA-00; Tue, 08 Jul 2003 11:04:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zu0n-0002N5-00; Tue, 08 Jul 2003 11:04:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zu0e-00079J-PL; Tue, 08 Jul 2003 11:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zu0D-00076F-IQ for simple@optimus.ietf.org; Tue, 08 Jul 2003 11:03:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25455 for ; Tue, 8 Jul 2003 11:03:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zu0A-0002Mb-00 for simple@ietf.org; Tue, 08 Jul 2003 11:03:30 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19Zu09-0002MQ-00 for simple@ietf.org; Tue, 08 Jul 2003 11:03:29 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h68F2rA12747; Tue, 8 Jul 2003 10:02:53 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h68F2o411152; Tue, 8 Jul 2003 10:02:51 -0500 (CDT) Message-ID: <3F0ADD16.2010907@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: Simple WG , SPIRITS list Subject: Re: [Simple] New I-D on presence states for phones References: <3F0A67C6.9070004@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 08 Jul 2003 10:02:46 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > In case folks havent seen it, I wanted to call your attention to: > > http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-simple-pidf-phone-00.txt > > http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt > http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html > > This draft, written by Jon and myself, defines some PIDF extensions for > describing phones, including traditional "black" phones, wireless phones > and enterprise phones. I think these will provide invaluable for a > device-centric view of a presentity. > > Comments and questions welcome. Jonathan: Generally, you describe what sort of presence information to offer without going into the details of *how* the presence information is actually generated in the first place. There are strong synergies here in the work we are finishing up in SPIRITS WG. The SPIRITS protocol I-D (http://www.ietf.org/internet-drafts/draft-ietf-spirits-protocol-05.txt), which is now complete, provides the primitives on the how part for wirless and wireline networks. I think a cross reference to this I-D may give the reader a better overall picture. I have published an individual I-D on the implementation of presence information for POTS phones using SPIRITS (http://www.ietf.org/internet-drafts/draft-gurbani-spirits-implementation-00.txt). Your phone-state extensions to PIDF provide a richer set of information. In our initial implementation, we simply used an XML extension to indicate how long a phone user has been in a call. Your I-D can refer to the work in the SPIRITS protocol I-D, especially in Sections 1 (Introduction), 3 (POTS Line State) and 5 (Wireless Phone State). I'd be more than glad to work with you to see how to best tie up the work going on in the SPIRITS WG and SIMPLE for presence on phone lines. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 8 11:04:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25653 for ; Tue, 8 Jul 2003 11:04:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zu0r-0007Aq-OX for simple-archive@odin.ietf.org; Tue, 08 Jul 2003 11:04:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68F4Da4027527 for simple-archive@odin.ietf.org; Tue, 8 Jul 2003 11:04:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zu0r-00079u-JH for simple-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 11:04:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25515; Tue, 8 Jul 2003 11:04:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zu0o-0002NA-00; Tue, 08 Jul 2003 11:04:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zu0n-0002N5-00; Tue, 08 Jul 2003 11:04:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zu0e-00079J-PL; Tue, 08 Jul 2003 11:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zu0D-00076F-IQ for simple@optimus.ietf.org; Tue, 08 Jul 2003 11:03:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25455 for ; Tue, 8 Jul 2003 11:03:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zu0A-0002Mb-00 for simple@ietf.org; Tue, 08 Jul 2003 11:03:30 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19Zu09-0002MQ-00 for simple@ietf.org; Tue, 08 Jul 2003 11:03:29 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h68F2rA12747; Tue, 8 Jul 2003 10:02:53 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h68F2o411152; Tue, 8 Jul 2003 10:02:51 -0500 (CDT) Message-ID: <3F0ADD16.2010907@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: Simple WG , SPIRITS list Subject: Re: [Simple] New I-D on presence states for phones References: <3F0A67C6.9070004@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 08 Jul 2003 10:02:46 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > In case folks havent seen it, I wanted to call your attention to: > > http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-simple-pidf-phone-00.txt > > http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt > http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html > > This draft, written by Jon and myself, defines some PIDF extensions for > describing phones, including traditional "black" phones, wireless phones > and enterprise phones. I think these will provide invaluable for a > device-centric view of a presentity. > > Comments and questions welcome. Jonathan: Generally, you describe what sort of presence information to offer without going into the details of *how* the presence information is actually generated in the first place. There are strong synergies here in the work we are finishing up in SPIRITS WG. The SPIRITS protocol I-D (http://www.ietf.org/internet-drafts/draft-ietf-spirits-protocol-05.txt), which is now complete, provides the primitives on the how part for wirless and wireline networks. I think a cross reference to this I-D may give the reader a better overall picture. I have published an individual I-D on the implementation of presence information for POTS phones using SPIRITS (http://www.ietf.org/internet-drafts/draft-gurbani-spirits-implementation-00.txt). Your phone-state extensions to PIDF provide a richer set of information. In our initial implementation, we simply used an XML extension to indicate how long a phone user has been in a call. Your I-D can refer to the work in the SPIRITS protocol I-D, especially in Sections 1 (Introduction), 3 (POTS Line State) and 5 (Wireless Phone State). I'd be more than glad to work with you to see how to best tie up the work going on in the SPIRITS WG and SIMPLE for presence on phone lines. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 9 03:02:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20751; Wed, 9 Jul 2003 03:02:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a8xr-0004Bo-00; Wed, 09 Jul 2003 03:02:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a8xq-0004Bl-00; Wed, 09 Jul 2003 03:02:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8xl-0007VM-Jx; Wed, 09 Jul 2003 03:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8x3-0007UG-1E for simple@optimus.ietf.org; Wed, 09 Jul 2003 03:01:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20740 for ; Wed, 9 Jul 2003 03:01:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a8wz-0004BT-00 for simple@ietf.org; Wed, 09 Jul 2003 03:01:13 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19a8wy-0004BB-00 for simple@ietf.org; Wed, 09 Jul 2003 03:01:12 -0400 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6970liB006171; Wed, 9 Jul 2003 03:00:47 -0400 (EDT) Message-ID: <3F0BBD99.1090807@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Simple WG , SPIRITS list Subject: Re: [Simple] New I-D on presence states for phones References: <3F0A67C6.9070004@dynamicsoft.com> <3F0ADD16.2010907@lucent.com> In-Reply-To: <3F0ADD16.2010907@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Jul 2003 03:00:41 -0400 Content-Transfer-Encoding: 7bit inline. Vijay K. Gurbani wrote: > Jonathan Rosenberg wrote: > > Generally, you describe what sort of presence information to offer > without going into the details of *how* the presence information > is actually generated in the first place. Right. There are LOTS of ways. SPIRITS is one of them, but definitely not the only one. The information in the presence document exists across a bunch of different PSTN elements, including HLRs, VLRs, MSCs, etc. There are strong > synergies here in the work we are finishing up in SPIRITS WG. The > SPIRITS protocol I-D > (http://www.ietf.org/internet-drafts/draft-ietf-spirits-protocol-05.txt), > which is now complete, provides the primitives on the how part > for wirless and wireline networks. I think a cross reference to > this I-D may give the reader a better overall picture. OK, I will add a reference in the next revision (assuming there is one). > > I have published an individual I-D on the implementation of presence > information for POTS phones using SPIRITS > (http://www.ietf.org/internet-drafts/draft-gurbani-spirits-implementation-00.txt). > > Your phone-state extensions to PIDF provide a richer set of > information. In our initial implementation, we simply used an > XML extension to indicate how long a phone user has been in a > call. I think the rpids "from" element would work well for that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 9 03:02:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20792 for ; Wed, 9 Jul 2003 03:02:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8xv-0007Xs-N9 for simple-archive@odin.ietf.org; Wed, 09 Jul 2003 03:02:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6972BOX029004 for simple-archive@odin.ietf.org; Wed, 9 Jul 2003 03:02:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8xv-0007Xj-EB for simple-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 03:02:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20751; Wed, 9 Jul 2003 03:02:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a8xr-0004Bo-00; Wed, 09 Jul 2003 03:02:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a8xq-0004Bl-00; Wed, 09 Jul 2003 03:02:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8xl-0007VM-Jx; Wed, 09 Jul 2003 03:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8x3-0007UG-1E for simple@optimus.ietf.org; Wed, 09 Jul 2003 03:01:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20740 for ; Wed, 9 Jul 2003 03:01:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a8wz-0004BT-00 for simple@ietf.org; Wed, 09 Jul 2003 03:01:13 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19a8wy-0004BB-00 for simple@ietf.org; Wed, 09 Jul 2003 03:01:12 -0400 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6970liB006171; Wed, 9 Jul 2003 03:00:47 -0400 (EDT) Message-ID: <3F0BBD99.1090807@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Simple WG , SPIRITS list Subject: Re: [Simple] New I-D on presence states for phones References: <3F0A67C6.9070004@dynamicsoft.com> <3F0ADD16.2010907@lucent.com> In-Reply-To: <3F0ADD16.2010907@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Jul 2003 03:00:41 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Vijay K. Gurbani wrote: > Jonathan Rosenberg wrote: > > Generally, you describe what sort of presence information to offer > without going into the details of *how* the presence information > is actually generated in the first place. Right. There are LOTS of ways. SPIRITS is one of them, but definitely not the only one. The information in the presence document exists across a bunch of different PSTN elements, including HLRs, VLRs, MSCs, etc. There are strong > synergies here in the work we are finishing up in SPIRITS WG. The > SPIRITS protocol I-D > (http://www.ietf.org/internet-drafts/draft-ietf-spirits-protocol-05.txt), > which is now complete, provides the primitives on the how part > for wirless and wireline networks. I think a cross reference to > this I-D may give the reader a better overall picture. OK, I will add a reference in the next revision (assuming there is one). > > I have published an individual I-D on the implementation of presence > information for POTS phones using SPIRITS > (http://www.ietf.org/internet-drafts/draft-gurbani-spirits-implementation-00.txt). > > Your phone-state extensions to PIDF provide a richer set of > information. In our initial implementation, we simply used an > XML extension to indicate how long a phone user has been in a > call. I think the rpids "from" element would work well for that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 9 03:39:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22360; Wed, 9 Jul 2003 03:39:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a9Xe-0004hH-00; Wed, 09 Jul 2003 03:39:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a9Xd-0004hE-00; Wed, 09 Jul 2003 03:39:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9XZ-00069b-Hc; Wed, 09 Jul 2003 03:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9XN-000690-OH for simple@optimus.ietf.org; Wed, 09 Jul 2003 03:38:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22355 for ; Wed, 9 Jul 2003 03:38:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a9XL-0004hB-00 for simple@ietf.org; Wed, 09 Jul 2003 03:38:47 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19a9XK-0004h2-00 for simple@ietf.org; Wed, 09 Jul 2003 03:38:46 -0400 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h697cLiB006186; Wed, 9 Jul 2003 03:38:22 -0400 (EDT) Message-ID: <3F0BC668.7030708@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eva-maria.leppanen@nokia.com CC: simple@ietf.org Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments References: <902B96A872B24840B48412649C0E8A4201543D01@trebe003.europe.nokia.com> In-Reply-To: <902B96A872B24840B48412649C0E8A4201543D01@trebe003.europe.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Jul 2003 03:38:16 -0400 Content-Transfer-Encoding: 7bit Thanks for the comments. Responses inline. eva-maria.leppanen@nokia.com wrote: > Hi, > > I found the draft very versatile. Please find below some comments > and questions: > > * "Acceptance permissions" include elements where the acceptance > can be based on the filter information. However the security > considerations of the "Presence Filter Requirements" I-D recommends > as follows: "The filter criteria should not be rejected based on > the authorization policy since this would enable the watcher by > experimentation with the use of filter criteria to determine the > authorization policy the presentity has set for him and thus > discover what the presentity wants to hide from him". I think the requirement in the filter requirements doc is not worded properly. I think the proper wording is that "It should be possible for the server to hide the fact that their filter was not acceptable. In such a case, the subscription would be accepted, but they would not neccesarily get all of the information that was requested.". This means that it is the CHOICE of the presentity about whether the watcher is informed of the rejection, or if their filter is silently ignored. So, if a presentity wanted to reject the subscription based on the filter, they would use the acceptance permissions to do that. If they wanted, instead, to simply limit what the watcher sees, they would use the content permissions and other permissions as needed. > > * "Identifying elements" chapter says: "...that element is used as > an input to the computation of other elements..." -> what if a > certain element's value is derived from two published elements (the > other is authorized but the other not)? Does the "raw piece of > presence data" mean (in practise) that the identified element is > the same as (raw) published element, but it is changed by the > composer? This could be specified more clearly - it's somehow too > vague for a specification of authorization. Yes, I agree its vague. To make it less vague, you need to have a model that defines how the PA computes views of presence, so you can describe the impact of these policies. I think what I had in mind is that you have some raw presence data, denoted by R. Then, there is some transformation T which is applied to R, which determines the presence document to be shown to a watcher. So, if the permission only allows elements X, Y and Z to be known to a watcher, the raw presence document R would be stripped of everything except X, Y and Z, and then the transformation R is applied. > > * The tuple IDs are used for identifying the whole tuples in the > "content permissions". Is there some reason why only the tuple ID > can be used, and not to allow any XML element (e.g., nested > element-name/element-path elements to "show-tuple")? Thats the purpose of the "show-element" permission. * The "not" > condition might be usable for denying a specific XML element, > namespace, value etc (in the content permissions). Using the > current premissions it is only possible to make a list of all > allowed items, but not to say that "allow everything else except > this information". Thats a good idea. I'll add something to do this. > > * One element in transformational permissions is "set-document" > which allows e.g. defining a document including "lies". I was > wondering whether the purpose was to use this also for allowing the > presentity to define multiple level of details of the semantically > same presence information? Not sure I follow what you mean by this. > Somehow I see the solution too fixed for > that purpose. The presentity might want to define e.g. different > notes to different watchers or different deltails of location > information. You could define different notes to different watchers using the set-element permission. Differing details of location information - I think we'll need to nail down a lot more about how location information is represented before we tackle that. geopriv is finally making some progress, so it will be soon I think... > This kind of information changes more often and is > more dynamic compared to the other authorization related > information. The proposal is to handle the different levels of > values within publishing, but the authorization solution should > support linking different levels of values to different watchers or > groups of watchers. Not sure I follow that... > > * A comment about defining "union" for combining multiple > "statement" elements: this is a good approach for many purposes, > but depending on how the presence information (and tuples) are > structured, there might be a need to define e.g. that the showed > value to "*@example.com" should be "closed" but it should be "open" > to "john@example.com". The "first" match principle/ or the most > specific address principle would be more suitable in this case. It > seems that both of them would be needed. Interestingly, your example is about transformational attributes. Those, as I think I comment in the spec, are not really "permissions", and don't compose as well as the others. There, I am inclined to agree that a different combination operation is needed. Defining the match with maximal specificty isnt always easy, though. What happens if a watcher is on a list, and one statement is said to apply to users on a list, and another statement applies to that user specifically? Both have the same level of specificity. That said, with the exception of transformational policies, I think union works well under the assumption that applies-to REALLY says who it applies to. So, if you say that some permission is granted to everyone in the example.com domain, that means everyone. If you want to create an exception, you would need to do it by creating an exception within the applies-to statement. So, how about something like an element, so that you could do this: example.com sip:joe@example.com > > * What is the relation of the "set-document" to the default and/or > hard state publishing? Is the purpose that there will be an own > usage for hard state publishing? Good question. I thought about this a bit. Originally, I had thought they were the same. But, now, I dont think they are. Hard-state state publishing sets one presence document of many that are input to composition. set-document says that composition is not done at all, and that a specific document is to be sent. One solution would be to add a new permission called "add-document" which contains a presence document that is to be placed as input to the composition policy. That would seem to work for hard state publishing. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 9 03:39:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22429 for ; Wed, 9 Jul 2003 03:39:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9Xg-0006Dq-UM for simple-archive@odin.ietf.org; Wed, 09 Jul 2003 03:39:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h697d82I023912 for simple-archive@odin.ietf.org; Wed, 9 Jul 2003 03:39:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9Xg-0006Db-Pp for simple-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 03:39:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22360; Wed, 9 Jul 2003 03:39:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a9Xe-0004hH-00; Wed, 09 Jul 2003 03:39:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a9Xd-0004hE-00; Wed, 09 Jul 2003 03:39:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9XZ-00069b-Hc; Wed, 09 Jul 2003 03:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9XN-000690-OH for simple@optimus.ietf.org; Wed, 09 Jul 2003 03:38:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22355 for ; Wed, 9 Jul 2003 03:38:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a9XL-0004hB-00 for simple@ietf.org; Wed, 09 Jul 2003 03:38:47 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19a9XK-0004h2-00 for simple@ietf.org; Wed, 09 Jul 2003 03:38:46 -0400 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h697cLiB006186; Wed, 9 Jul 2003 03:38:22 -0400 (EDT) Message-ID: <3F0BC668.7030708@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eva-maria.leppanen@nokia.com CC: simple@ietf.org Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments References: <902B96A872B24840B48412649C0E8A4201543D01@trebe003.europe.nokia.com> In-Reply-To: <902B96A872B24840B48412649C0E8A4201543D01@trebe003.europe.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Jul 2003 03:38:16 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for the comments. Responses inline. eva-maria.leppanen@nokia.com wrote: > Hi, > > I found the draft very versatile. Please find below some comments > and questions: > > * "Acceptance permissions" include elements where the acceptance > can be based on the filter information. However the security > considerations of the "Presence Filter Requirements" I-D recommends > as follows: "The filter criteria should not be rejected based on > the authorization policy since this would enable the watcher by > experimentation with the use of filter criteria to determine the > authorization policy the presentity has set for him and thus > discover what the presentity wants to hide from him". I think the requirement in the filter requirements doc is not worded properly. I think the proper wording is that "It should be possible for the server to hide the fact that their filter was not acceptable. In such a case, the subscription would be accepted, but they would not neccesarily get all of the information that was requested.". This means that it is the CHOICE of the presentity about whether the watcher is informed of the rejection, or if their filter is silently ignored. So, if a presentity wanted to reject the subscription based on the filter, they would use the acceptance permissions to do that. If they wanted, instead, to simply limit what the watcher sees, they would use the content permissions and other permissions as needed. > > * "Identifying elements" chapter says: "...that element is used as > an input to the computation of other elements..." -> what if a > certain element's value is derived from two published elements (the > other is authorized but the other not)? Does the "raw piece of > presence data" mean (in practise) that the identified element is > the same as (raw) published element, but it is changed by the > composer? This could be specified more clearly - it's somehow too > vague for a specification of authorization. Yes, I agree its vague. To make it less vague, you need to have a model that defines how the PA computes views of presence, so you can describe the impact of these policies. I think what I had in mind is that you have some raw presence data, denoted by R. Then, there is some transformation T which is applied to R, which determines the presence document to be shown to a watcher. So, if the permission only allows elements X, Y and Z to be known to a watcher, the raw presence document R would be stripped of everything except X, Y and Z, and then the transformation R is applied. > > * The tuple IDs are used for identifying the whole tuples in the > "content permissions". Is there some reason why only the tuple ID > can be used, and not to allow any XML element (e.g., nested > element-name/element-path elements to "show-tuple")? Thats the purpose of the "show-element" permission. * The "not" > condition might be usable for denying a specific XML element, > namespace, value etc (in the content permissions). Using the > current premissions it is only possible to make a list of all > allowed items, but not to say that "allow everything else except > this information". Thats a good idea. I'll add something to do this. > > * One element in transformational permissions is "set-document" > which allows e.g. defining a document including "lies". I was > wondering whether the purpose was to use this also for allowing the > presentity to define multiple level of details of the semantically > same presence information? Not sure I follow what you mean by this. > Somehow I see the solution too fixed for > that purpose. The presentity might want to define e.g. different > notes to different watchers or different deltails of location > information. You could define different notes to different watchers using the set-element permission. Differing details of location information - I think we'll need to nail down a lot more about how location information is represented before we tackle that. geopriv is finally making some progress, so it will be soon I think... > This kind of information changes more often and is > more dynamic compared to the other authorization related > information. The proposal is to handle the different levels of > values within publishing, but the authorization solution should > support linking different levels of values to different watchers or > groups of watchers. Not sure I follow that... > > * A comment about defining "union" for combining multiple > "statement" elements: this is a good approach for many purposes, > but depending on how the presence information (and tuples) are > structured, there might be a need to define e.g. that the showed > value to "*@example.com" should be "closed" but it should be "open" > to "john@example.com". The "first" match principle/ or the most > specific address principle would be more suitable in this case. It > seems that both of them would be needed. Interestingly, your example is about transformational attributes. Those, as I think I comment in the spec, are not really "permissions", and don't compose as well as the others. There, I am inclined to agree that a different combination operation is needed. Defining the match with maximal specificty isnt always easy, though. What happens if a watcher is on a list, and one statement is said to apply to users on a list, and another statement applies to that user specifically? Both have the same level of specificity. That said, with the exception of transformational policies, I think union works well under the assumption that applies-to REALLY says who it applies to. So, if you say that some permission is granted to everyone in the example.com domain, that means everyone. If you want to create an exception, you would need to do it by creating an exception within the applies-to statement. So, how about something like an element, so that you could do this: example.com sip:joe@example.com > > * What is the relation of the "set-document" to the default and/or > hard state publishing? Is the purpose that there will be an own > usage for hard state publishing? Good question. I thought about this a bit. Originally, I had thought they were the same. But, now, I dont think they are. Hard-state state publishing sets one presence document of many that are input to composition. set-document says that composition is not done at all, and that a specific document is to be sent. One solution would be to add a new permission called "add-document" which contains a presence document that is to be placed as input to the composition policy. That would seem to work for hard state publishing. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 9 15:02:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14823; Wed, 9 Jul 2003 15:02:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aKCZ-00020g-00; Wed, 09 Jul 2003 15:02:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aKCZ-00020Y-00; Wed, 09 Jul 2003 15:02:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKCX-0003zZ-2O; Wed, 09 Jul 2003 15:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKCK-0003zB-BB for simple@optimus.ietf.org; Wed, 09 Jul 2003 15:01:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14811; Wed, 9 Jul 2003 15:01:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aKCH-00020T-00; Wed, 09 Jul 2003 15:01:45 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19aKCG-00020O-00; Wed, 09 Jul 2003 15:01:44 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h69IxxB14240; Wed, 9 Jul 2003 13:59:59 -0500 From: Robert Sparks To: sip-implementors@cs.columbia.edu Cc: sip@ietf.org, simple@ietf.org In-Reply-To: <1056657212.1916.82.camel@RjS.localdomain> References: <1056657212.1916.82.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1057777197.940.42.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Sip-implementors] SIPIT 13 Registration Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Jul 2003 13:59:57 -0500 Content-Transfer-Encoding: 7bit Registration for SIPIT 13 closes next week. If you have not already registered, please do so now. Thanks, RjS On Thu, 2003-06-26 at 14:53, Robert Sparks wrote: > Registration for SIPIT 13 is open. > > The event will be hosted by Mitel in the brand-new > Brookstreet Hotel and Conference Center in Ottawa > August 18-24th. > > Information about the event and facilities as well > as online registration can be found at: > http://www.mitel.com/sipit/index.cfm > > Registration through the website will close on July 18th. > > See you there, > RjS > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 9 15:02:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14887 for ; Wed, 9 Jul 2003 15:02:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKCd-00040k-By for simple-archive@odin.ietf.org; Wed, 09 Jul 2003 15:02:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69J27vW015414 for simple-archive@odin.ietf.org; Wed, 9 Jul 2003 15:02:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKCd-00040X-7u for simple-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 15:02:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14823; Wed, 9 Jul 2003 15:02:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aKCZ-00020g-00; Wed, 09 Jul 2003 15:02:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aKCZ-00020Y-00; Wed, 09 Jul 2003 15:02:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKCX-0003zZ-2O; Wed, 09 Jul 2003 15:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKCK-0003zB-BB for simple@optimus.ietf.org; Wed, 09 Jul 2003 15:01:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14811; Wed, 9 Jul 2003 15:01:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aKCH-00020T-00; Wed, 09 Jul 2003 15:01:45 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19aKCG-00020O-00; Wed, 09 Jul 2003 15:01:44 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h69IxxB14240; Wed, 9 Jul 2003 13:59:59 -0500 From: Robert Sparks To: sip-implementors@cs.columbia.edu Cc: sip@ietf.org, simple@ietf.org In-Reply-To: <1056657212.1916.82.camel@RjS.localdomain> References: <1056657212.1916.82.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1057777197.940.42.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Sip-implementors] SIPIT 13 Registration Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Jul 2003 13:59:57 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Registration for SIPIT 13 closes next week. If you have not already registered, please do so now. Thanks, RjS On Thu, 2003-06-26 at 14:53, Robert Sparks wrote: > Registration for SIPIT 13 is open. > > The event will be hosted by Mitel in the brand-new > Brookstreet Hotel and Conference Center in Ottawa > August 18-24th. > > Information about the event and facilities as well > as online registration can be found at: > http://www.mitel.com/sipit/index.cfm > > Registration through the website will close on July 18th. > > See you there, > RjS > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 9 16:42:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20952; Wed, 9 Jul 2003 16:42:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aLlR-0003Af-00; Wed, 09 Jul 2003 16:42:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aLlR-0003Aa-00; Wed, 09 Jul 2003 16:42:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLlJ-0002H8-Ft; Wed, 09 Jul 2003 16:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLkc-00026u-LK for simple@optimus.ietf.org; Wed, 09 Jul 2003 16:41:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20931 for ; Wed, 9 Jul 2003 16:41:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aLka-00039i-00 for simple@ietf.org; Wed, 09 Jul 2003 16:41:16 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19aLkZ-000391-00 for simple@ietf.org; Wed, 09 Jul 2003 16:41:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h69KejB15377 for ; Wed, 9 Jul 2003 15:40:45 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1057783242.940.103.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Correction : Agenda - SIMPLE - IETF57 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Jul 2003 15:40:42 -0500 Content-Transfer-Encoding: 7bit The draft list for the filtering mechanism agenda item had some older entries. It should only contain: > 1640 Filtering Mechanism - 10 min > Hisham Khartabil > draft-khartabil-simple-filter-format-00.txt > draft-khartabil-simple-filter-funct-00.txt Sorry for any inconvenience. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 9 16:42:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21033 for ; Wed, 9 Jul 2003 16:42:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLlU-0002I6-BF for simple-archive@odin.ietf.org; Wed, 09 Jul 2003 16:42:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69KgCdR008800 for simple-archive@odin.ietf.org; Wed, 9 Jul 2003 16:42:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLlU-0002Hr-27 for simple-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 16:42:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20952; Wed, 9 Jul 2003 16:42:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aLlR-0003Af-00; Wed, 09 Jul 2003 16:42:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aLlR-0003Aa-00; Wed, 09 Jul 2003 16:42:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLlJ-0002H8-Ft; Wed, 09 Jul 2003 16:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLkc-00026u-LK for simple@optimus.ietf.org; Wed, 09 Jul 2003 16:41:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20931 for ; Wed, 9 Jul 2003 16:41:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aLka-00039i-00 for simple@ietf.org; Wed, 09 Jul 2003 16:41:16 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19aLkZ-000391-00 for simple@ietf.org; Wed, 09 Jul 2003 16:41:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h69KejB15377 for ; Wed, 9 Jul 2003 15:40:45 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1057783242.940.103.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Correction : Agenda - SIMPLE - IETF57 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Jul 2003 15:40:42 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The draft list for the filtering mechanism agenda item had some older entries. It should only contain: > 1640 Filtering Mechanism - 10 min > Hisham Khartabil > draft-khartabil-simple-filter-format-00.txt > draft-khartabil-simple-filter-funct-00.txt Sorry for any inconvenience. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 10 04:36:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22535; Thu, 10 Jul 2003 04:36:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aWuM-0000aM-00; Thu, 10 Jul 2003 04:36:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aWuL-0000aJ-00; Thu, 10 Jul 2003 04:36:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWuI-0002ou-3A; Thu, 10 Jul 2003 04:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWtN-0002aH-23 for simple@optimus.ietf.org; Thu, 10 Jul 2003 04:35:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22472 for ; Thu, 10 Jul 2003 04:35:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aWtJ-0000ZT-00 for simple@ietf.org; Thu, 10 Jul 2003 04:35:01 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19aWtI-0000ZQ-00 for simple@ietf.org; Thu, 10 Jul 2003 04:35:00 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 10 Jul 2003 09:37:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C346BE.185DFE98" Message-ID: <45730E094814E44488F789C1CDED27AE0219B01E@gbnewp0758m.eu.ubiquity.net> Thread-Topic: Message Sessions Thread-Index: AcNGvhc1NjB1dmUFTbSYSRLh2LXESA== From: "Chris Boulton" To: Cc: Subject: [Simple] Message Sessions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 09:34:36 +0100 This is a multi-part message in MIME format. ------_=_NextPart_001_01C346BE.185DFE98 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ben, =20 I've just had time to have a detailed look at the 'sessions' draft. This draft seems to answer a lot of the outstanding questions associated with Instant Messaging within SIP. I have a couple of comments, apologies for being late:- =20 - I understand the need for a separate data connection when transferring large files - I was just wondering how a client would associate the new data session with the original, textual one (I could be missing something here so please SHOUT ;-). I was wondering if this could be done at the MSRP level by including a session style parameter on the S-URL (e.g. S-URL:msrp://relay.atlanta.com:7777/iau39;foo=3Dabc123). This way, if a new session arrives with a matching session parameter, the MSRP client knows which chat to prompt e.g. 'Do you want to accept a file transfer from........'. =20 - I was also considering the 'keystroke' functionality that we have all come to know and love. I realize that this may not be an issue for the base messaging spec but I'll mention it anyway. I was thinking of maybe an optional MSRP header which signifies that activity (e.g. keyboard) has taken place. This could then be sent in an MSRP SEND request, usually a refresh without a content. So if I start typing a message, a blank SEND is sent with the 'activity' header set to true. This would notify the recipient that the far-end is responding. This header would require an 'expires' parameter, to invalidate the activity (e.g. 10 seconds). This expires would be set both locally and on the receiving endpoint. If a client types a message, the activity refresh is sent, and the other end is informed BUT if the expiry fires, this information should be withdrawn. The generating client would not re-send an activity SEND if the timer has not expired. This would increase the size of an MSRP message :-( BUT would be an optional header. =20 That's my observations, feel free to ignore ;-) =20 Chris. =20 =20 ------------------------------------------------ Chris Boulton Ubiquity Software =20 Tel : +44 (0) 1633765600 Fax : +44 (0) 1633765601=20 ------------------------------------------------ =20 =20 ------_=_NextPart_001_01C346BE.185DFE98 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ben,

 

        = ;    I’ve just had time to have a detailed look at the ‘sessions’ = draft.  This draft seems to answer a = lot of the outstanding questions associated with Instant Messaging within SIP.  I have a couple of comments, = apologies for being late:-

 

-          I understand the need for a = separate data connection when transferring large files – I was just = wondering how a client would associate the new data session with the original, textual = one (I could be missing something here so please SHOUT ;-).  I was wondering if this could = be done at the MSRP level by including a session style parameter on the S-URL (e.g. = S-URL:msrp://relay.atlanta.com:7777/iau39;foo=3Dabc123).  This way, if a new session = arrives with a matching session parameter, the MSRP client knows which chat to prompt = e.g. ‘Do you want to accept a file transfer = from……..’.

 

-          I was also considering the = ‘keystroke’ functionality that we have all come to know and love.  I realize that this may not be = an issue for the base messaging spec but I’ll mention it anyway.  I was thinking of maybe an = optional MSRP header which signifies that activity (e.g. keyboard) has taken = place.  This could then be sent in an = MSRP SEND request, usually a refresh without a content.  So if I start typing a message, = a blank SEND is sent with the ’activity’ header set to true.  This would notify the recipient = that the far-end is responding.  = This header would require an ‘expires’ parameter, to invalidate the = activity (e.g. 10 seconds).  This = expires would be set both locally and on the receiving endpoint.  If a client types a message, = the activity refresh is sent, and the other end is informed BUT if the = expiry fires, this information should be withdrawn.  The generating client would not re-send an activity SEND if the = timer has not expired.  This = would increase the size of an MSRP message L BUT would be an optional = header.

 

That’s my observations, feel free to ignore = ;-)

 

Chris.

 

 

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

Chris Boulton=

Ubiquity = Software

 =

Tel : +44 = (0) 1633765600

Fax : +44 = (0) 1633765601

------------------------------------------------=

 

 

=00 ------_=_NextPart_001_01C346BE.185DFE98-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 10 04:36:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22569 for ; Thu, 10 Jul 2003 04:36:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWuP-0002rX-Rh for simple-archive@odin.ietf.org; Thu, 10 Jul 2003 04:36:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A8a9jj011003 for simple-archive@odin.ietf.org; Thu, 10 Jul 2003 04:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWuP-0002rO-ND for simple-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 04:36:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22535; Thu, 10 Jul 2003 04:36:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aWuM-0000aM-00; Thu, 10 Jul 2003 04:36:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aWuL-0000aJ-00; Thu, 10 Jul 2003 04:36:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWuI-0002ou-3A; Thu, 10 Jul 2003 04:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWtN-0002aH-23 for simple@optimus.ietf.org; Thu, 10 Jul 2003 04:35:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22472 for ; Thu, 10 Jul 2003 04:35:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aWtJ-0000ZT-00 for simple@ietf.org; Thu, 10 Jul 2003 04:35:01 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19aWtI-0000ZQ-00 for simple@ietf.org; Thu, 10 Jul 2003 04:35:00 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 10 Jul 2003 09:37:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C346BE.185DFE98" Message-ID: <45730E094814E44488F789C1CDED27AE0219B01E@gbnewp0758m.eu.ubiquity.net> Thread-Topic: Message Sessions Thread-Index: AcNGvhc1NjB1dmUFTbSYSRLh2LXESA== From: "Chris Boulton" To: Cc: Subject: [Simple] Message Sessions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 09:34:36 +0100 This is a multi-part message in MIME format. ------_=_NextPart_001_01C346BE.185DFE98 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ben, =20 I've just had time to have a detailed look at the 'sessions' draft. This draft seems to answer a lot of the outstanding questions associated with Instant Messaging within SIP. I have a couple of comments, apologies for being late:- =20 - I understand the need for a separate data connection when transferring large files - I was just wondering how a client would associate the new data session with the original, textual one (I could be missing something here so please SHOUT ;-). I was wondering if this could be done at the MSRP level by including a session style parameter on the S-URL (e.g. S-URL:msrp://relay.atlanta.com:7777/iau39;foo=3Dabc123). This way, if a new session arrives with a matching session parameter, the MSRP client knows which chat to prompt e.g. 'Do you want to accept a file transfer from........'. =20 - I was also considering the 'keystroke' functionality that we have all come to know and love. I realize that this may not be an issue for the base messaging spec but I'll mention it anyway. I was thinking of maybe an optional MSRP header which signifies that activity (e.g. keyboard) has taken place. This could then be sent in an MSRP SEND request, usually a refresh without a content. So if I start typing a message, a blank SEND is sent with the 'activity' header set to true. This would notify the recipient that the far-end is responding. This header would require an 'expires' parameter, to invalidate the activity (e.g. 10 seconds). This expires would be set both locally and on the receiving endpoint. If a client types a message, the activity refresh is sent, and the other end is informed BUT if the expiry fires, this information should be withdrawn. The generating client would not re-send an activity SEND if the timer has not expired. This would increase the size of an MSRP message :-( BUT would be an optional header. =20 That's my observations, feel free to ignore ;-) =20 Chris. =20 =20 ------------------------------------------------ Chris Boulton Ubiquity Software =20 Tel : +44 (0) 1633765600 Fax : +44 (0) 1633765601=20 ------------------------------------------------ =20 =20 ------_=_NextPart_001_01C346BE.185DFE98 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ben,

 

        = ;    I’ve just had time to have a detailed look at the ‘sessions’ = draft.  This draft seems to answer a = lot of the outstanding questions associated with Instant Messaging within SIP.  I have a couple of comments, = apologies for being late:-

 

-          I understand the need for a = separate data connection when transferring large files – I was just = wondering how a client would associate the new data session with the original, textual = one (I could be missing something here so please SHOUT ;-).  I was wondering if this could = be done at the MSRP level by including a session style parameter on the S-URL (e.g. = S-URL:msrp://relay.atlanta.com:7777/iau39;foo=3Dabc123).  This way, if a new session = arrives with a matching session parameter, the MSRP client knows which chat to prompt = e.g. ‘Do you want to accept a file transfer = from……..’.

 

-          I was also considering the = ‘keystroke’ functionality that we have all come to know and love.  I realize that this may not be = an issue for the base messaging spec but I’ll mention it anyway.  I was thinking of maybe an = optional MSRP header which signifies that activity (e.g. keyboard) has taken = place.  This could then be sent in an = MSRP SEND request, usually a refresh without a content.  So if I start typing a message, = a blank SEND is sent with the ’activity’ header set to true.  This would notify the recipient = that the far-end is responding.  = This header would require an ‘expires’ parameter, to invalidate the = activity (e.g. 10 seconds).  This = expires would be set both locally and on the receiving endpoint.  If a client types a message, = the activity refresh is sent, and the other end is informed BUT if the = expiry fires, this information should be withdrawn.  The generating client would not re-send an activity SEND if the = timer has not expired.  This = would increase the size of an MSRP message L BUT would be an optional = header.

 

That’s my observations, feel free to ignore = ;-)

 

Chris.

 

 

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

Chris Boulton=

Ubiquity = Software

 =

Tel : +44 = (0) 1633765600

Fax : +44 = (0) 1633765601

------------------------------------------------=

 

 

=00 ------_=_NextPart_001_01C346BE.185DFE98-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 10 05:18:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23443; Thu, 10 Jul 2003 05:18:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aXYw-0000p7-00; Thu, 10 Jul 2003 05:18:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aXYv-0000p4-00; Thu, 10 Jul 2003 05:18:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aXYu-0005tF-RI; Thu, 10 Jul 2003 05:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aXYp-0005su-A3 for simple@optimus.ietf.org; Thu, 10 Jul 2003 05:17:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23437 for ; Thu, 10 Jul 2003 05:17:50 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aXYl-0000ou-00 for simple@ietf.org; Thu, 10 Jul 2003 05:17:51 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19aXYk-0000or-00 for simple@ietf.org; Thu, 10 Jul 2003 05:17:51 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6A9Hoa18695 for ; Thu, 10 Jul 2003 12:17:50 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 10 Jul 2003 12:17:48 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 12:17:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796EE6@esebe019.ntc.nokia.com> Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments Thread-Index: AcNF7TZnrYlMBRxsSamepTxPdICnUgA0yAiQ To: , Cc: X-OriginalArrivalTime: 10 Jul 2003 09:17:49.0248 (UTC) FILETIME=[21E1B400:01C346C4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 12:17:48 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, July 09, 2003 10:38 AM > To: Leppanen Eva-Maria (NET/Tampere) > Cc: simple@ietf.org > Subject: Re: [Simple] I-D > ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments >=20 >=20 > Thanks for the comments. Responses inline. >=20 > eva-maria.leppanen@nokia.com wrote: >=20 > > Hi, > >=20 > > I found the draft very versatile. Please find below some comments > > and questions: > >=20 > > * "Acceptance permissions" include elements where the acceptance > > can be based on the filter information. However the security > > considerations of the "Presence Filter Requirements" I-D recommends > > as follows: "The filter criteria should not be rejected based on > > the authorization policy since this would enable the watcher by > > experimentation with the use of filter criteria to determine the > > authorization policy the presentity has set for him and thus > > discover what the presentity wants to hide from him". >=20 > I think the requirement in the filter requirements doc is not worded=20 > properly. I think the proper wording is that "It should be possible=20 > for the server to hide the fact that their filter was not acceptable.=20 > In such a case, the subscription would be accepted, but they=20 > would not=20 > neccesarily get all of the information that was requested.". This=20 > means that it is the CHOICE of the presentity about whether the=20 > watcher is informed of the rejection, or if their filter is silently=20 > ignored. >=20 > So, if a presentity wanted to reject the subscription based on the=20 > filter, they would use the acceptance permissions to do that. If they=20 > wanted, instead, to simply limit what the watcher sees, they=20 > would use=20 > the content permissions and other permissions as needed. I'll expand this a little You have an acceptance permission statement that looks like this: sip:joe@example.com pidf:contact Now, the filter that arrives asks explicitly for pidf element = for be put in the NOTIFY. This evaluates to false using the acceptance = permission statement above and results in the subscription being = rejected. What we want is for this subscription to be accepted and the filter to = be accepted, but not necessarily honoured. So, in the auth usage draft, = there needs to be mentioned that if an acceptance permission statement = evaluates to true, a permission may still be granted (polite blocking), = but the presentity must add a corresponding content permission that = removes element from the PIDF document (using the = element as Eva suggested below). The other and probably better alternative (which I think is that = Jonathan is suggesting, will you document?) is to document that if a = presentity wants polite blocking, then it sets acceptance permissions to = and uses the content-permissions to block sending of un = authorised info. So the example above becomes: sip:joe@example.com pidf:contact Regards, Hisham >=20 > >=20 > > * "Identifying elements" chapter says: "...that element is used as > > an input to the computation of other elements..." -> what if a > > certain element's value is derived from two published elements (the > > other is authorized but the other not)? Does the "raw piece of > > presence data" mean (in practise) that the identified element is > > the same as (raw) published element, but it is changed by the > > composer? This could be specified more clearly - it's somehow too > > vague for a specification of authorization. >=20 > Yes, I agree its vague. To make it less vague, you need to have a=20 > model that defines how the PA computes views of presence, so you can=20 > describe the impact of these policies. I think what I had in mind is=20 > that you have some raw presence data, denoted by R. Then, there is=20 > some transformation T which is applied to R, which determines the=20 > presence document to be shown to a watcher. >=20 > So, if the permission only allows elements X, Y and Z to be=20 > known to a=20 > watcher, the raw presence document R would be stripped of everything=20 > except X, Y and Z, and then the transformation R is applied. >=20 >=20 > >=20 > > * The tuple IDs are used for identifying the whole tuples in the > > "content permissions". Is there some reason why only the tuple ID > > can be used, and not to allow any XML element (e.g., nested > > element-name/element-path elements to "show-tuple")?=20 >=20 > Thats the purpose of the "show-element" permission. >=20 > * The "not" > > condition might be usable for denying a specific XML element, > > namespace, value etc (in the content permissions). Using the > > current premissions it is only possible to make a list of all > > allowed items, but not to say that "allow everything else except > > this information". >=20 > Thats a good idea. I'll add something to do this. >=20 >=20 > >=20 > > * One element in transformational permissions is "set-document" > > which allows e.g. defining a document including "lies". I was > > wondering whether the purpose was to use this also for allowing the > > presentity to define multiple level of details of the semantically > > same presence information?=20 >=20 > Not sure I follow what you mean by this. >=20 > > Somehow I see the solution too fixed for > > that purpose. The presentity might want to define e.g. different > > notes to different watchers or different deltails of location > > information.=20 >=20 > You could define different notes to different watchers using the=20 > set-element permission. Differing details of location information - I=20 > think we'll need to nail down a lot more about how location=20 > information is represented before we tackle that. geopriv is finally=20 > making some progress, so it will be soon I think... >=20 >=20 > > This kind of information changes more often and is > > more dynamic compared to the other authorization related > > information. The proposal is to handle the different levels of > > values within publishing, but the authorization solution should > > support linking different levels of values to different watchers or > > groups of watchers. >=20 > Not sure I follow that... >=20 > >=20 > > * A comment about defining "union" for combining multiple > > "statement" elements: this is a good approach for many purposes, > > but depending on how the presence information (and tuples) are > > structured, there might be a need to define e.g. that the showed > > value to "*@example.com" should be "closed" but it should be "open" > > to "john@example.com". The "first" match principle/ or the most > > specific address principle would be more suitable in this case. It > > seems that both of them would be needed. >=20 > Interestingly, your example is about transformational attributes.=20 > Those, as I think I comment in the spec, are not really=20 > "permissions",=20 > and don't compose as well as the others. There, I am inclined=20 > to agree=20 > that a different combination operation is needed. Defining the match=20 > with maximal specificty isnt always easy, though. What happens if a=20 > watcher is on a list, and one statement is said to apply to=20 > users on a=20 > list, and another statement applies to that user specifically? Both=20 > have the same level of specificity. >=20 > That said, with the exception of transformational policies, I think=20 > union works well under the assumption that applies-to REALLY says who=20 > it applies to. So, if you say that some permission is granted to=20 > everyone in the example.com domain, that means everyone. If you want=20 > to create an exception, you would need to do it by creating an=20 > exception within the applies-to statement. >=20 > So, how about something like an element, so that you=20 > could do=20 > this: >=20 > > example.com > sip:joe@example.com > >=20 >=20 > >=20 > > * What is the relation of the "set-document" to the default and/or > > hard state publishing? Is the purpose that there will be an own > > usage for hard state publishing? >=20 > Good question. I thought about this a bit. Originally, I had thought=20 > they were the same. But, now, I dont think they are. Hard-state state=20 > publishing sets one presence document of many that are input to=20 > composition. set-document says that composition is not done at all,=20 > and that a specific document is to be sent. >=20 > One solution would be to add a new permission called "add-document"=20 > which contains a presence document that is to be placed as input to=20 > the composition policy. That would seem to work for hard=20 > state publishing. >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 10 05:18:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23460 for ; Thu, 10 Jul 2003 05:18:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aXZ0-0005tv-3g for simple-archive@odin.ietf.org; Thu, 10 Jul 2003 05:18:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A9I63b022683 for simple-archive@odin.ietf.org; Thu, 10 Jul 2003 05:18:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aXYz-0005tm-VX for simple-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 05:18:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23443; Thu, 10 Jul 2003 05:18:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aXYw-0000p7-00; Thu, 10 Jul 2003 05:18:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aXYv-0000p4-00; Thu, 10 Jul 2003 05:18:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aXYu-0005tF-RI; Thu, 10 Jul 2003 05:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aXYp-0005su-A3 for simple@optimus.ietf.org; Thu, 10 Jul 2003 05:17:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23437 for ; Thu, 10 Jul 2003 05:17:50 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aXYl-0000ou-00 for simple@ietf.org; Thu, 10 Jul 2003 05:17:51 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19aXYk-0000or-00 for simple@ietf.org; Thu, 10 Jul 2003 05:17:51 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6A9Hoa18695 for ; Thu, 10 Jul 2003 12:17:50 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 10 Jul 2003 12:17:48 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 12:17:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796EE6@esebe019.ntc.nokia.com> Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments Thread-Index: AcNF7TZnrYlMBRxsSamepTxPdICnUgA0yAiQ To: , Cc: X-OriginalArrivalTime: 10 Jul 2003 09:17:49.0248 (UTC) FILETIME=[21E1B400:01C346C4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 12:17:48 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, July 09, 2003 10:38 AM > To: Leppanen Eva-Maria (NET/Tampere) > Cc: simple@ietf.org > Subject: Re: [Simple] I-D > ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments >=20 >=20 > Thanks for the comments. Responses inline. >=20 > eva-maria.leppanen@nokia.com wrote: >=20 > > Hi, > >=20 > > I found the draft very versatile. Please find below some comments > > and questions: > >=20 > > * "Acceptance permissions" include elements where the acceptance > > can be based on the filter information. However the security > > considerations of the "Presence Filter Requirements" I-D recommends > > as follows: "The filter criteria should not be rejected based on > > the authorization policy since this would enable the watcher by > > experimentation with the use of filter criteria to determine the > > authorization policy the presentity has set for him and thus > > discover what the presentity wants to hide from him". >=20 > I think the requirement in the filter requirements doc is not worded=20 > properly. I think the proper wording is that "It should be possible=20 > for the server to hide the fact that their filter was not acceptable.=20 > In such a case, the subscription would be accepted, but they=20 > would not=20 > neccesarily get all of the information that was requested.". This=20 > means that it is the CHOICE of the presentity about whether the=20 > watcher is informed of the rejection, or if their filter is silently=20 > ignored. >=20 > So, if a presentity wanted to reject the subscription based on the=20 > filter, they would use the acceptance permissions to do that. If they=20 > wanted, instead, to simply limit what the watcher sees, they=20 > would use=20 > the content permissions and other permissions as needed. I'll expand this a little You have an acceptance permission statement that looks like this: sip:joe@example.com pidf:contact Now, the filter that arrives asks explicitly for pidf element = for be put in the NOTIFY. This evaluates to false using the acceptance = permission statement above and results in the subscription being = rejected. What we want is for this subscription to be accepted and the filter to = be accepted, but not necessarily honoured. So, in the auth usage draft, = there needs to be mentioned that if an acceptance permission statement = evaluates to true, a permission may still be granted (polite blocking), = but the presentity must add a corresponding content permission that = removes element from the PIDF document (using the = element as Eva suggested below). The other and probably better alternative (which I think is that = Jonathan is suggesting, will you document?) is to document that if a = presentity wants polite blocking, then it sets acceptance permissions to = and uses the content-permissions to block sending of un = authorised info. So the example above becomes: sip:joe@example.com pidf:contact Regards, Hisham >=20 > >=20 > > * "Identifying elements" chapter says: "...that element is used as > > an input to the computation of other elements..." -> what if a > > certain element's value is derived from two published elements (the > > other is authorized but the other not)? Does the "raw piece of > > presence data" mean (in practise) that the identified element is > > the same as (raw) published element, but it is changed by the > > composer? This could be specified more clearly - it's somehow too > > vague for a specification of authorization. >=20 > Yes, I agree its vague. To make it less vague, you need to have a=20 > model that defines how the PA computes views of presence, so you can=20 > describe the impact of these policies. I think what I had in mind is=20 > that you have some raw presence data, denoted by R. Then, there is=20 > some transformation T which is applied to R, which determines the=20 > presence document to be shown to a watcher. >=20 > So, if the permission only allows elements X, Y and Z to be=20 > known to a=20 > watcher, the raw presence document R would be stripped of everything=20 > except X, Y and Z, and then the transformation R is applied. >=20 >=20 > >=20 > > * The tuple IDs are used for identifying the whole tuples in the > > "content permissions". Is there some reason why only the tuple ID > > can be used, and not to allow any XML element (e.g., nested > > element-name/element-path elements to "show-tuple")?=20 >=20 > Thats the purpose of the "show-element" permission. >=20 > * The "not" > > condition might be usable for denying a specific XML element, > > namespace, value etc (in the content permissions). Using the > > current premissions it is only possible to make a list of all > > allowed items, but not to say that "allow everything else except > > this information". >=20 > Thats a good idea. I'll add something to do this. >=20 >=20 > >=20 > > * One element in transformational permissions is "set-document" > > which allows e.g. defining a document including "lies". I was > > wondering whether the purpose was to use this also for allowing the > > presentity to define multiple level of details of the semantically > > same presence information?=20 >=20 > Not sure I follow what you mean by this. >=20 > > Somehow I see the solution too fixed for > > that purpose. The presentity might want to define e.g. different > > notes to different watchers or different deltails of location > > information.=20 >=20 > You could define different notes to different watchers using the=20 > set-element permission. Differing details of location information - I=20 > think we'll need to nail down a lot more about how location=20 > information is represented before we tackle that. geopriv is finally=20 > making some progress, so it will be soon I think... >=20 >=20 > > This kind of information changes more often and is > > more dynamic compared to the other authorization related > > information. The proposal is to handle the different levels of > > values within publishing, but the authorization solution should > > support linking different levels of values to different watchers or > > groups of watchers. >=20 > Not sure I follow that... >=20 > >=20 > > * A comment about defining "union" for combining multiple > > "statement" elements: this is a good approach for many purposes, > > but depending on how the presence information (and tuples) are > > structured, there might be a need to define e.g. that the showed > > value to "*@example.com" should be "closed" but it should be "open" > > to "john@example.com". The "first" match principle/ or the most > > specific address principle would be more suitable in this case. It > > seems that both of them would be needed. >=20 > Interestingly, your example is about transformational attributes.=20 > Those, as I think I comment in the spec, are not really=20 > "permissions",=20 > and don't compose as well as the others. There, I am inclined=20 > to agree=20 > that a different combination operation is needed. Defining the match=20 > with maximal specificty isnt always easy, though. What happens if a=20 > watcher is on a list, and one statement is said to apply to=20 > users on a=20 > list, and another statement applies to that user specifically? Both=20 > have the same level of specificity. >=20 > That said, with the exception of transformational policies, I think=20 > union works well under the assumption that applies-to REALLY says who=20 > it applies to. So, if you say that some permission is granted to=20 > everyone in the example.com domain, that means everyone. If you want=20 > to create an exception, you would need to do it by creating an=20 > exception within the applies-to statement. >=20 > So, how about something like an element, so that you=20 > could do=20 > this: >=20 > > example.com > sip:joe@example.com > >=20 >=20 > >=20 > > * What is the relation of the "set-document" to the default and/or > > hard state publishing? Is the purpose that there will be an own > > usage for hard state publishing? >=20 > Good question. I thought about this a bit. Originally, I had thought=20 > they were the same. But, now, I dont think they are. Hard-state state=20 > publishing sets one presence document of many that are input to=20 > composition. set-document says that composition is not done at all,=20 > and that a specific document is to be sent. >=20 > One solution would be to add a new permission called "add-document"=20 > which contains a presence document that is to be placed as input to=20 > the composition policy. That would seem to work for hard=20 > state publishing. >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 10 11:18:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07027; Thu, 10 Jul 2003 11:18:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19adBM-0003uN-00; Thu, 10 Jul 2003 11:18:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19adBM-0003uK-00; Thu, 10 Jul 2003 11:18:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19adBJ-0001B1-As; Thu, 10 Jul 2003 11:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19adAK-00017X-TO for simple@optimus.ietf.org; Thu, 10 Jul 2003 11:17:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06968 for ; Thu, 10 Jul 2003 11:16:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19adAK-0003t6-00 for simple@ietf.org; Thu, 10 Jul 2003 11:17:00 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19adAJ-0003sh-00 for simple@ietf.org; Thu, 10 Jul 2003 11:16:59 -0400 Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6AFGWiB007579; Thu, 10 Jul 2003 11:16:32 -0400 (EDT) Message-ID: <3F0D834A.2060908@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: eva-maria.leppanen@nokia.com, simple@ietf.org Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments References: <2038BCC78B1AD641891A0D1AE133DBB701796EE6@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796EE6@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 11:16:26 -0400 Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > Now, the filter that arrives asks explicitly for pidf > element for be put in the NOTIFY. This evaluates to false using the > acceptance permission statement above and results in the > subscription being rejected. Right. > > What we want is for this subscription to be accepted and the filter > to be accepted, but not necessarily honoured. So, in the auth usage > draft, there needs to be mentioned that if an acceptance permission > statement evaluates to true, a permission may still be granted > (polite blocking), but the presentity must add a corresponding > content permission that removes element from the PIDF > document (using the element as Eva suggested below). Right. > > The other and probably better alternative (which I think is that > Jonathan is suggesting, will you document?) is to document that if > a presentity wants polite blocking, then it sets acceptance > permissions to and uses the content-permissions to block > sending of un authorised info. Right. Isn't that what you just suggested in the paragraph above? I do think its useful to document this, and to make specific metnion of how polite blocking is done. Probably what the document needs is both explanatory text and some good examples that show things like this. I will do for the next rev. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 10 11:18:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07094 for ; Thu, 10 Jul 2003 11:18:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19adBO-0001Bi-4M for simple-archive@odin.ietf.org; Thu, 10 Jul 2003 11:18:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AFI6U4004562 for simple-archive@odin.ietf.org; Thu, 10 Jul 2003 11:18:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19adBO-0001BV-1O for simple-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 11:18:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07027; Thu, 10 Jul 2003 11:18:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19adBM-0003uN-00; Thu, 10 Jul 2003 11:18:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19adBM-0003uK-00; Thu, 10 Jul 2003 11:18:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19adBJ-0001B1-As; Thu, 10 Jul 2003 11:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19adAK-00017X-TO for simple@optimus.ietf.org; Thu, 10 Jul 2003 11:17:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06968 for ; Thu, 10 Jul 2003 11:16:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19adAK-0003t6-00 for simple@ietf.org; Thu, 10 Jul 2003 11:17:00 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19adAJ-0003sh-00 for simple@ietf.org; Thu, 10 Jul 2003 11:16:59 -0400 Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6AFGWiB007579; Thu, 10 Jul 2003 11:16:32 -0400 (EDT) Message-ID: <3F0D834A.2060908@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: eva-maria.leppanen@nokia.com, simple@ietf.org Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments References: <2038BCC78B1AD641891A0D1AE133DBB701796EE6@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796EE6@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 11:16:26 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > Now, the filter that arrives asks explicitly for pidf > element for be put in the NOTIFY. This evaluates to false using the > acceptance permission statement above and results in the > subscription being rejected. Right. > > What we want is for this subscription to be accepted and the filter > to be accepted, but not necessarily honoured. So, in the auth usage > draft, there needs to be mentioned that if an acceptance permission > statement evaluates to true, a permission may still be granted > (polite blocking), but the presentity must add a corresponding > content permission that removes element from the PIDF > document (using the element as Eva suggested below). Right. > > The other and probably better alternative (which I think is that > Jonathan is suggesting, will you document?) is to document that if > a presentity wants polite blocking, then it sets acceptance > permissions to and uses the content-permissions to block > sending of un authorised info. Right. Isn't that what you just suggested in the paragraph above? I do think its useful to document this, and to make specific metnion of how polite blocking is done. Probably what the document needs is both explanatory text and some good examples that show things like this. I will do for the next rev. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 10 17:42:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23227; Thu, 10 Jul 2003 17:42:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ajB2-0007f9-00; Thu, 10 Jul 2003 17:42:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ajB1-0007f4-00; Thu, 10 Jul 2003 17:42:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ajAv-0003xy-Ak; Thu, 10 Jul 2003 17:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ajA1-0003se-Gc for simple@optimus.ietf.org; Thu, 10 Jul 2003 17:41:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23205 for ; Thu, 10 Jul 2003 17:40:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aj9y-0007eq-00 for simple@ietf.org; Thu, 10 Jul 2003 17:41:03 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aj9x-0007eZ-00 for simple@ietf.org; Thu, 10 Jul 2003 17:41:02 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h6ALekbl049935; Thu, 10 Jul 2003 16:40:48 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) From: Ben Campbell To: Chris Boulton Cc: Simple WG In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B01E@gbnewp0758m.eu.ubiquity.net> References: <45730E094814E44488F789C1CDED27AE0219B01E@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=windows-1251 Message-Id: <1057873206.6686.44.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by magus.nostrum.com id h6ALekbl049935 Content-Transfer-Encoding: quoted-printable Subject: [Simple] Re: Message Sessions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Jul 2003 16:40:06 -0500 Content-Transfer-Encoding: quoted-printable On Thu, 2003-07-10 at 03:34, Chris Boulton wrote: > Ben, >=20 > =20 >=20 > I=92ve just had time to have a detailed look at the > =91sessions=92 draft. This draft seems to answer a lot of the outstand= ing > questions associated with Instant Messaging within SIP. I have a > couple of comments, apologies for being late:- No problem. >=20 > =20 >=20 > - I understand the need for a separate data connection when > transferring large files =96 I was just wondering how a client would > associate the new data session with the original, textual one (I could > be missing something here so please SHOUT ;-). I was wondering if > this could be done at the MSRP level by including a session style > parameter on the S-URL (e.g. > S-URL:msrp://relay.atlanta.com:7777/iau39;foo=3Dabc123). This way, if = a > new session arrives with a matching session parameter, the MSRP client > knows which chat to prompt e.g. =91Do you want to accept a file transfe= r > from=85=85..=92. >=20 Hmm. I don't think we really have talked much about associating the two. If that is in fact a requirement, I would lean toward creating the association on the signaling side rather than in the URI. It is not clear to me if associating file transfer with text sessions is as much of a requirement as simply understanding what sort of data is being sent, and acting appropriately. In the case of transferring large content, the client can make some determinations based on the size and content-type. > =20 >=20 > - I was also considering the =91keystroke=92 functionality that= we > have all come to know and love. I realize that this may not be an > issue for the base messaging spec but I=92ll mention it anyway. I was > thinking of maybe an optional MSRP header which signifies that > activity (e.g. keyboard) has taken place. This could then be sent in > an MSRP SEND request, usually a refresh without a content. So if I > start typing a message, a blank SEND is sent with the =92activity=92 > header set to true. This would notify the recipient that the far-end > is responding. This header would require an =91expires=92 parameter, t= o > invalidate the activity (e.g. 10 seconds). This expires would be set > both locally and on the receiving endpoint. If a client types a > message, the activity refresh is sent, and the other end is informed > BUT if the expiry fires, this information should be withdrawn. The > generating client would not re-send an activity SEND if the timer has > not expired. This would increase the size of an MSRP message L BUT > would be an optional header. >=20 I wonder if it would make sense to use the same technique for this as is being discussed for page-mode messaging; that is, send a message with a particular MIME type. A client can indicate support by including that type in the format list. =20 >=20 > That=92s my observations, feel free to ignore ;-) >=20 > =20 >=20 > Chris. >=20 > =20 >=20 > =20 >=20 > ------------------------------------------------ >=20 > Chris Boulton >=20 > Ubiquity Software >=20 > =20 >=20 > Tel : +44 (0) 1633765600 >=20 > Fax : +44 (0) 1633765601=20 >=20 > ------------------------------------------------ >=20 > =20 >=20 > =20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 10 17:42:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23247 for ; Thu, 10 Jul 2003 17:42:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ajB6-0003yg-Eq for simple-archive@odin.ietf.org; Thu, 10 Jul 2003 17:42:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ALgCXL015286 for simple-archive@odin.ietf.org; Thu, 10 Jul 2003 17:42:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ajB6-0003yT-BP for simple-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 17:42:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23227; Thu, 10 Jul 2003 17:42:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ajB2-0007f9-00; Thu, 10 Jul 2003 17:42:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ajB1-0007f4-00; Thu, 10 Jul 2003 17:42:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ajAv-0003xy-Ak; Thu, 10 Jul 2003 17:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ajA1-0003se-Gc for simple@optimus.ietf.org; Thu, 10 Jul 2003 17:41:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23205 for ; Thu, 10 Jul 2003 17:40:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aj9y-0007eq-00 for simple@ietf.org; Thu, 10 Jul 2003 17:41:03 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aj9x-0007eZ-00 for simple@ietf.org; Thu, 10 Jul 2003 17:41:02 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h6ALekbl049935; Thu, 10 Jul 2003 16:40:48 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) From: Ben Campbell To: Chris Boulton Cc: Simple WG In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B01E@gbnewp0758m.eu.ubiquity.net> References: <45730E094814E44488F789C1CDED27AE0219B01E@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=windows-1251 Message-Id: <1057873206.6686.44.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by magus.nostrum.com id h6ALekbl049935 Content-Transfer-Encoding: quoted-printable Subject: [Simple] Re: Message Sessions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Jul 2003 16:40:06 -0500 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Thu, 2003-07-10 at 03:34, Chris Boulton wrote: > Ben, >=20 > =20 >=20 > I=92ve just had time to have a detailed look at the > =91sessions=92 draft. This draft seems to answer a lot of the outstand= ing > questions associated with Instant Messaging within SIP. I have a > couple of comments, apologies for being late:- No problem. >=20 > =20 >=20 > - I understand the need for a separate data connection when > transferring large files =96 I was just wondering how a client would > associate the new data session with the original, textual one (I could > be missing something here so please SHOUT ;-). I was wondering if > this could be done at the MSRP level by including a session style > parameter on the S-URL (e.g. > S-URL:msrp://relay.atlanta.com:7777/iau39;foo=3Dabc123). This way, if = a > new session arrives with a matching session parameter, the MSRP client > knows which chat to prompt e.g. =91Do you want to accept a file transfe= r > from=85=85..=92. >=20 Hmm. I don't think we really have talked much about associating the two. If that is in fact a requirement, I would lean toward creating the association on the signaling side rather than in the URI. It is not clear to me if associating file transfer with text sessions is as much of a requirement as simply understanding what sort of data is being sent, and acting appropriately. In the case of transferring large content, the client can make some determinations based on the size and content-type. > =20 >=20 > - I was also considering the =91keystroke=92 functionality that= we > have all come to know and love. I realize that this may not be an > issue for the base messaging spec but I=92ll mention it anyway. I was > thinking of maybe an optional MSRP header which signifies that > activity (e.g. keyboard) has taken place. This could then be sent in > an MSRP SEND request, usually a refresh without a content. So if I > start typing a message, a blank SEND is sent with the =92activity=92 > header set to true. This would notify the recipient that the far-end > is responding. This header would require an =91expires=92 parameter, t= o > invalidate the activity (e.g. 10 seconds). This expires would be set > both locally and on the receiving endpoint. If a client types a > message, the activity refresh is sent, and the other end is informed > BUT if the expiry fires, this information should be withdrawn. The > generating client would not re-send an activity SEND if the timer has > not expired. This would increase the size of an MSRP message L BUT > would be an optional header. >=20 I wonder if it would make sense to use the same technique for this as is being discussed for page-mode messaging; that is, send a message with a particular MIME type. A client can indicate support by including that type in the format list. =20 >=20 > That=92s my observations, feel free to ignore ;-) >=20 > =20 >=20 > Chris. >=20 > =20 >=20 > =20 >=20 > ------------------------------------------------ >=20 > Chris Boulton >=20 > Ubiquity Software >=20 > =20 >=20 > Tel : +44 (0) 1633765600 >=20 > Fax : +44 (0) 1633765601=20 >=20 > ------------------------------------------------ >=20 > =20 >=20 > =20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jul 11 03:18:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19134; Fri, 11 Jul 2003 03:18:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19asAP-00034n-00; Fri, 11 Jul 2003 03:18:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19asAP-00034k-00; Fri, 11 Jul 2003 03:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19asAK-0005i4-To; Fri, 11 Jul 2003 03:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19as9e-0005h0-9W for simple@optimus.ietf.org; Fri, 11 Jul 2003 03:17:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19128 for ; Fri, 11 Jul 2003 03:17:15 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19as9c-00034h-00 for simple@ietf.org; Fri, 11 Jul 2003 03:17:16 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19as9b-00034e-00 for simple@ietf.org; Fri, 11 Jul 2003 03:17:15 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6B7HEa22388 for ; Fri, 11 Jul 2003 10:17:15 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 11 Jul 2003 10:17:12 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Jul 2003 10:17:13 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Jul 2003 10:17:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796EF8@esebe019.ntc.nokia.com> Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments Thread-Index: AcNG9lhMmPFybUpLRweB5Rte562z1wAhZiCw To: Cc: , X-OriginalArrivalTime: 11 Jul 2003 07:17:13.0476 (UTC) FILETIME=[73704440:01C3477C] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 10:17:12 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, July 10, 2003 6:16 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: Leppanen Eva-Maria (NET/Tampere); simple@ietf.org > Subject: Re: [Simple] I-D > ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments >=20 >=20 > inline. >=20 > hisham.khartabil@nokia.com wrote: >=20 >=20 > > Now, the filter that arrives asks explicitly for pidf > > element for be put in the NOTIFY. This evaluates to false using the > > acceptance permission statement above and results in the > > subscription being rejected. >=20 > Right. >=20 > >=20 > > What we want is for this subscription to be accepted and the filter > > to be accepted, but not necessarily honoured. So, in the auth usage > > draft, there needs to be mentioned that if an acceptance permission > > statement evaluates to true, a permission may still be granted > > (polite blocking), but the presentity must add a corresponding > > content permission that removes element from the PIDF > > document (using the element as Eva suggested below). >=20 > Right. >=20 > >=20 > > The other and probably better alternative (which I think is that > > Jonathan is suggesting, will you document?) is to document that if > > a presentity wants polite blocking, then it sets acceptance > > permissions to and uses the content-permissions to block > > sending of un authorised info.=20 >=20 >=20 > Right. Isn't that what you just suggested in the paragraph above? Yes, my mistake. Apologies for the confusion. In the former case, I = meant to say that if the acceptance permission evaluates to false, a = permission may still be granted (polite blocking), but ...=20 I guess we will agree that this is a bad idea. /Hisham >=20 > I do think its useful to document this, and to make specific metnion=20 > of how polite blocking is done. Probably what the document needs is=20 > both explanatory text and some good examples that show things like=20 > this. I will do for the next rev. >=20 > -Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jul 11 03:18:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19166 for ; Fri, 11 Jul 2003 03:18:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19asAS-0005jV-DY for simple-archive@odin.ietf.org; Fri, 11 Jul 2003 03:18:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6B7I80s022037 for simple-archive@odin.ietf.org; Fri, 11 Jul 2003 03:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19asAS-0005jM-6U for simple-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 03:18:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19134; Fri, 11 Jul 2003 03:18:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19asAP-00034n-00; Fri, 11 Jul 2003 03:18:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19asAP-00034k-00; Fri, 11 Jul 2003 03:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19asAK-0005i4-To; Fri, 11 Jul 2003 03:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19as9e-0005h0-9W for simple@optimus.ietf.org; Fri, 11 Jul 2003 03:17:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19128 for ; Fri, 11 Jul 2003 03:17:15 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19as9c-00034h-00 for simple@ietf.org; Fri, 11 Jul 2003 03:17:16 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19as9b-00034e-00 for simple@ietf.org; Fri, 11 Jul 2003 03:17:15 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6B7HEa22388 for ; Fri, 11 Jul 2003 10:17:15 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 11 Jul 2003 10:17:12 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Jul 2003 10:17:13 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Jul 2003 10:17:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796EF8@esebe019.ntc.nokia.com> Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments Thread-Index: AcNG9lhMmPFybUpLRweB5Rte562z1wAhZiCw To: Cc: , X-OriginalArrivalTime: 11 Jul 2003 07:17:13.0476 (UTC) FILETIME=[73704440:01C3477C] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 10:17:12 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, July 10, 2003 6:16 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: Leppanen Eva-Maria (NET/Tampere); simple@ietf.org > Subject: Re: [Simple] I-D > ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments >=20 >=20 > inline. >=20 > hisham.khartabil@nokia.com wrote: >=20 >=20 > > Now, the filter that arrives asks explicitly for pidf > > element for be put in the NOTIFY. This evaluates to false using the > > acceptance permission statement above and results in the > > subscription being rejected. >=20 > Right. >=20 > >=20 > > What we want is for this subscription to be accepted and the filter > > to be accepted, but not necessarily honoured. So, in the auth usage > > draft, there needs to be mentioned that if an acceptance permission > > statement evaluates to true, a permission may still be granted > > (polite blocking), but the presentity must add a corresponding > > content permission that removes element from the PIDF > > document (using the element as Eva suggested below). >=20 > Right. >=20 > >=20 > > The other and probably better alternative (which I think is that > > Jonathan is suggesting, will you document?) is to document that if > > a presentity wants polite blocking, then it sets acceptance > > permissions to and uses the content-permissions to block > > sending of un authorised info.=20 >=20 >=20 > Right. Isn't that what you just suggested in the paragraph above? Yes, my mistake. Apologies for the confusion. In the former case, I = meant to say that if the acceptance permission evaluates to false, a = permission may still be granted (polite blocking), but ...=20 I guess we will agree that this is a bad idea. /Hisham >=20 > I do think its useful to document this, and to make specific metnion=20 > of how polite blocking is done. Probably what the document needs is=20 > both explanatory text and some good examples that show things like=20 > this. I will do for the next rev. >=20 > -Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jul 11 04:24:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20553; Fri, 11 Jul 2003 04:24:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19atCG-0003Sj-00; Fri, 11 Jul 2003 04:24:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19atCG-0003Sg-00; Fri, 11 Jul 2003 04:24:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19atCD-0002Xt-TC; Fri, 11 Jul 2003 04:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19atC2-0002XW-IX for simple@optimus.ietf.org; Fri, 11 Jul 2003 04:23:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20548 for ; Fri, 11 Jul 2003 04:23:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19atBz-0003Sb-00 for simple@ietf.org; Fri, 11 Jul 2003 04:23:47 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19atBz-0003SY-00 for simple@ietf.org; Fri, 11 Jul 2003 04:23:47 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Fri, 11 Jul 2003 09:26:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <45730E094814E44488F789C1CDED27AE0219B020@gbnewp0758m.eu.ubiquity.net> Thread-Topic: Message Sessions Thread-Index: AcNHK+T8nMttMzl7SXCYcsRN/vUH9AAVdnEw From: "Chris Boulton" To: "Ben Campbell" Cc: "Simple WG" Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: Message Sessions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 09:23:44 +0100 Content-Transfer-Encoding: quoted-printable Comments in-line. >-----Original Message----- >From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >Sent: 10 July 2003 22:40 >To: Chris Boulton >Cc: Simple WG >Subject: Re: Message Sessions > >On Thu, 2003-07-10 at 03:34, Chris Boulton wrote: >> Ben, >> >> >> >> I've just had time to have a detailed look at the >> 'sessions' draft. This draft seems to answer a lot of the outstanding >> questions associated with Instant Messaging within SIP. I have a >> couple of comments, apologies for being late:- > >No problem. >> >> >> >> - I understand the need for a separate data connection when >> transferring large files - I was just wondering how a client would >> associate the new data session with the original, textual one (I could >> be missing something here so please SHOUT ;-). I was wondering if >> this could be done at the MSRP level by including a session style >> parameter on the S-URL (e.g. >> S-URL:msrp://relay.atlanta.com:7777/iau39;foo=3Dabc123). This way, = if a >> new session arrives with a matching session parameter, the MSRP client >> knows which chat to prompt e.g. 'Do you want to accept a file transfer >> from........'. >> > >Hmm. I don't think we really have talked much about associating the two. >If that is in fact a requirement, I would lean toward creating the >association on the signaling side rather than in the URI. It is not >clear to me if associating file transfer with text sessions is as much >of a requirement as simply understanding what sort of data is being >sent, and acting appropriately. In the case of transferring large >content, the client can make some determinations based on the size and >content-type. > >> [Chris Boulton] I agree. This would be sufficient. I was just brainstorming scenarios where a client might have multiple sessions established using the same base session URL. How does it choose which session to associate the data transfer (new session)? For security reasons, a receiving client should have the ability to decline a data transfer + know from which session it is being sent. E.g. Chris has two sessions open with Alex and James using a relay uri of S-URL: msrp://relay.atlanta.com:7777/xxxx. Both wish to transfer a file but I decide to decline the file from Alex and accept the file from James. >> >> - I was also considering the 'keystroke' functionality that we >> have all come to know and love. I realize that this may not be an >> issue for the base messaging spec but I'll mention it anyway. I was >> thinking of maybe an optional MSRP header which signifies that >> activity (e.g. keyboard) has taken place. This could then be sent in >> an MSRP SEND request, usually a refresh without a content. So if I >> start typing a message, a blank SEND is sent with the 'activity' >> header set to true. This would notify the recipient that the far-end >> is responding. This header would require an 'expires' parameter, to >> invalidate the activity (e.g. 10 seconds). This expires would be set >> both locally and on the receiving endpoint. If a client types a >> message, the activity refresh is sent, and the other end is informed >> BUT if the expiry fires, this information should be withdrawn. The >> generating client would not re-send an activity SEND if the timer has >> not expired. This would increase the size of an MSRP message L BUT >> would be an optional header. >> > >I wonder if it would make sense to use the same technique for this as is >being discussed for page-mode messaging; that is, send a message with a >particular MIME type. A client can indicate support by including that >type in the format list. > [Chris Boulton] Sorry - I wasn't aware of the current proposed method for 'pager-mode' messaging. Would be grateful if you could point me to the appropriate material. I just saw this solution as quite dynamic + didn't have a major burden on message size, which is in-keeping with the MSRP philosophy. =20 Chris. >> >> That's my observations, feel free to ignore ;-) >> >> >> >> Chris. >> >> >> >> >> >> ------------------------------------------------ >> >> Chris Boulton >> >> Ubiquity Software >> >> >> >> Tel : +44 (0) 1633765600 >> >> Fax : +44 (0) 1633765601 >> >> ------------------------------------------------ >> >> >> >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jul 11 04:24:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20580 for ; Fri, 11 Jul 2003 04:24:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19atCK-0002bU-AW for simple-archive@odin.ietf.org; Fri, 11 Jul 2003 04:24:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6B8O8D7010002 for simple-archive@odin.ietf.org; Fri, 11 Jul 2003 04:24:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19atCK-0002bF-4J for simple-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 04:24:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20553; Fri, 11 Jul 2003 04:24:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19atCG-0003Sj-00; Fri, 11 Jul 2003 04:24:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19atCG-0003Sg-00; Fri, 11 Jul 2003 04:24:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19atCD-0002Xt-TC; Fri, 11 Jul 2003 04:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19atC2-0002XW-IX for simple@optimus.ietf.org; Fri, 11 Jul 2003 04:23:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20548 for ; Fri, 11 Jul 2003 04:23:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19atBz-0003Sb-00 for simple@ietf.org; Fri, 11 Jul 2003 04:23:47 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19atBz-0003SY-00 for simple@ietf.org; Fri, 11 Jul 2003 04:23:47 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Fri, 11 Jul 2003 09:26:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <45730E094814E44488F789C1CDED27AE0219B020@gbnewp0758m.eu.ubiquity.net> Thread-Topic: Message Sessions Thread-Index: AcNHK+T8nMttMzl7SXCYcsRN/vUH9AAVdnEw From: "Chris Boulton" To: "Ben Campbell" Cc: "Simple WG" Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: Message Sessions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 09:23:44 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Comments in-line. >-----Original Message----- >From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >Sent: 10 July 2003 22:40 >To: Chris Boulton >Cc: Simple WG >Subject: Re: Message Sessions > >On Thu, 2003-07-10 at 03:34, Chris Boulton wrote: >> Ben, >> >> >> >> I've just had time to have a detailed look at the >> 'sessions' draft. This draft seems to answer a lot of the outstanding >> questions associated with Instant Messaging within SIP. I have a >> couple of comments, apologies for being late:- > >No problem. >> >> >> >> - I understand the need for a separate data connection when >> transferring large files - I was just wondering how a client would >> associate the new data session with the original, textual one (I could >> be missing something here so please SHOUT ;-). I was wondering if >> this could be done at the MSRP level by including a session style >> parameter on the S-URL (e.g. >> S-URL:msrp://relay.atlanta.com:7777/iau39;foo=3Dabc123). This way, = if a >> new session arrives with a matching session parameter, the MSRP client >> knows which chat to prompt e.g. 'Do you want to accept a file transfer >> from........'. >> > >Hmm. I don't think we really have talked much about associating the two. >If that is in fact a requirement, I would lean toward creating the >association on the signaling side rather than in the URI. It is not >clear to me if associating file transfer with text sessions is as much >of a requirement as simply understanding what sort of data is being >sent, and acting appropriately. In the case of transferring large >content, the client can make some determinations based on the size and >content-type. > >> [Chris Boulton] I agree. This would be sufficient. I was just brainstorming scenarios where a client might have multiple sessions established using the same base session URL. How does it choose which session to associate the data transfer (new session)? For security reasons, a receiving client should have the ability to decline a data transfer + know from which session it is being sent. E.g. Chris has two sessions open with Alex and James using a relay uri of S-URL: msrp://relay.atlanta.com:7777/xxxx. Both wish to transfer a file but I decide to decline the file from Alex and accept the file from James. >> >> - I was also considering the 'keystroke' functionality that we >> have all come to know and love. I realize that this may not be an >> issue for the base messaging spec but I'll mention it anyway. I was >> thinking of maybe an optional MSRP header which signifies that >> activity (e.g. keyboard) has taken place. This could then be sent in >> an MSRP SEND request, usually a refresh without a content. So if I >> start typing a message, a blank SEND is sent with the 'activity' >> header set to true. This would notify the recipient that the far-end >> is responding. This header would require an 'expires' parameter, to >> invalidate the activity (e.g. 10 seconds). This expires would be set >> both locally and on the receiving endpoint. If a client types a >> message, the activity refresh is sent, and the other end is informed >> BUT if the expiry fires, this information should be withdrawn. The >> generating client would not re-send an activity SEND if the timer has >> not expired. This would increase the size of an MSRP message L BUT >> would be an optional header. >> > >I wonder if it would make sense to use the same technique for this as is >being discussed for page-mode messaging; that is, send a message with a >particular MIME type. A client can indicate support by including that >type in the format list. > [Chris Boulton] Sorry - I wasn't aware of the current proposed method for 'pager-mode' messaging. Would be grateful if you could point me to the appropriate material. I just saw this solution as quite dynamic + didn't have a major burden on message size, which is in-keeping with the MSRP philosophy. =20 Chris. >> >> That's my observations, feel free to ignore ;-) >> >> >> >> Chris. >> >> >> >> >> >> ------------------------------------------------ >> >> Chris Boulton >> >> Ubiquity Software >> >> >> >> Tel : +44 (0) 1633765600 >> >> Fax : +44 (0) 1633765601 >> >> ------------------------------------------------ >> >> >> >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jul 11 09:34:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28931; Fri, 11 Jul 2003 09:34:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ay2I-0005ip-00; Fri, 11 Jul 2003 09:34:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ay2I-0005im-00; Fri, 11 Jul 2003 09:34:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ay2C-00024v-SJ; Fri, 11 Jul 2003 09:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ay1P-00024S-F7 for simple@optimus.ietf.org; Fri, 11 Jul 2003 09:33:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28904 for ; Fri, 11 Jul 2003 09:33:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ay1N-0005iF-00 for simple@ietf.org; Fri, 11 Jul 2003 09:33:09 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19ay1M-0005i4-00 for simple@ietf.org; Fri, 11 Jul 2003 09:33:09 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h6BDWnbl022143; Fri, 11 Jul 2003 08:32:51 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) From: Ben Campbell To: Chris Boulton Cc: Simple WG In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B020@gbnewp0758m.eu.ubiquity.net> References: <45730E094814E44488F789C1CDED27AE0219B020@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain Message-Id: <1057930355.8717.9.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] RE: Message Sessions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 11 Jul 2003 08:32:35 -0500 Content-Transfer-Encoding: 7bit On Fri, 2003-07-11 at 03:23, Chris Boulton wrote: > Comments in-line. > [...] > [Chris Boulton] I agree. This would be sufficient. I was just > brainstorming scenarios where a client might have multiple sessions > established using the same base session URL. How does it choose which > session to associate the data transfer (new session)? For security > reasons, a receiving client should have the ability to decline a data > transfer + know from which session it is being sent. E.g. Chris has two > sessions open with Alex and James using a relay uri of S-URL: > msrp://relay.atlanta.com:7777/xxxx. Both wish to transfer a file but I > decide to decline the file from Alex and accept the file from James. > > Chris knows which user the additional session is coming from the same way he knew who originated the _original_ sessions; that is, he authenticates the SIP requests (or whatever the signaling protocol happens to be.) > > [Chris Boulton] Sorry - I wasn't aware of the current proposed method > for 'pager-mode' messaging. Would be grateful if you could point me to > the appropriate material. I just saw this solution as quite dynamic + > didn't have a major burden on message size, which is in-keeping with the > MSRP philosophy. http://www.softarmor.com/simple/drafts/draft-schulzrinne-simple-iscomposing-00.txt Your proposal is certainly lighter weight than in the draft, but I think Henning's approach is not all that heavyweight, and brings a lot more flexibility. I would be interested in hearing other opinions, here, though. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jul 11 09:34:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28957 for ; Fri, 11 Jul 2003 09:34:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ay2L-00026V-17 for simple-archive@odin.ietf.org; Fri, 11 Jul 2003 09:34:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BDY9gP008085 for simple-archive@odin.ietf.org; Fri, 11 Jul 2003 09:34:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ay2K-00026K-Ti for simple-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 09:34:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28931; Fri, 11 Jul 2003 09:34:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ay2I-0005ip-00; Fri, 11 Jul 2003 09:34:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ay2I-0005im-00; Fri, 11 Jul 2003 09:34:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ay2C-00024v-SJ; Fri, 11 Jul 2003 09:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ay1P-00024S-F7 for simple@optimus.ietf.org; Fri, 11 Jul 2003 09:33:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28904 for ; Fri, 11 Jul 2003 09:33:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ay1N-0005iF-00 for simple@ietf.org; Fri, 11 Jul 2003 09:33:09 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19ay1M-0005i4-00 for simple@ietf.org; Fri, 11 Jul 2003 09:33:09 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h6BDWnbl022143; Fri, 11 Jul 2003 08:32:51 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) From: Ben Campbell To: Chris Boulton Cc: Simple WG In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B020@gbnewp0758m.eu.ubiquity.net> References: <45730E094814E44488F789C1CDED27AE0219B020@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain Message-Id: <1057930355.8717.9.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] RE: Message Sessions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 11 Jul 2003 08:32:35 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2003-07-11 at 03:23, Chris Boulton wrote: > Comments in-line. > [...] > [Chris Boulton] I agree. This would be sufficient. I was just > brainstorming scenarios where a client might have multiple sessions > established using the same base session URL. How does it choose which > session to associate the data transfer (new session)? For security > reasons, a receiving client should have the ability to decline a data > transfer + know from which session it is being sent. E.g. Chris has two > sessions open with Alex and James using a relay uri of S-URL: > msrp://relay.atlanta.com:7777/xxxx. Both wish to transfer a file but I > decide to decline the file from Alex and accept the file from James. > > Chris knows which user the additional session is coming from the same way he knew who originated the _original_ sessions; that is, he authenticates the SIP requests (or whatever the signaling protocol happens to be.) > > [Chris Boulton] Sorry - I wasn't aware of the current proposed method > for 'pager-mode' messaging. Would be grateful if you could point me to > the appropriate material. I just saw this solution as quite dynamic + > didn't have a major burden on message size, which is in-keeping with the > MSRP philosophy. http://www.softarmor.com/simple/drafts/draft-schulzrinne-simple-iscomposing-00.txt Your proposal is certainly lighter weight than in the draft, but I think Henning's approach is not all that heavyweight, and brings a lot more flexibility. I would be interested in hearing other opinions, here, though. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jul 11 16:28:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15399; Fri, 11 Jul 2003 16:28:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b4Ux-0001sG-00; Fri, 11 Jul 2003 16:28:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b4Uw-0001sD-00; Fri, 11 Jul 2003 16:28:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4Uq-0000TI-VK; Fri, 11 Jul 2003 16:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4UN-0000Su-SX for simple@optimus.ietf.org; Fri, 11 Jul 2003 16:27:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15374 for ; Fri, 11 Jul 2003 16:27:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b4UH-0001rg-00 for simple@ietf.org; Fri, 11 Jul 2003 16:27:25 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19b4UF-0001rQ-00 for simple@ietf.org; Fri, 11 Jul 2003 16:27:24 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h6BKQhB08850 for ; Fri, 11 Jul 2003 15:26:43 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1057955200.925.69.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Hyperlinked agenda for the SIMPLE meeting Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 11 Jul 2003 15:26:41 -0500 Content-Transfer-Encoding: 7bit A hyperlinked copy of the SIMPLE agenda is available at http://www.softarmor.com/simple/meets/ietf57/agenda.html RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jul 11 16:28:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15435 for ; Fri, 11 Jul 2003 16:28:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4V0-0000Y3-4Z for simple-archive@odin.ietf.org; Fri, 11 Jul 2003 16:28:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BKSAsd002101 for simple-archive@odin.ietf.org; Fri, 11 Jul 2003 16:28:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4V0-0000Xo-0Y for simple-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 16:28:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15399; Fri, 11 Jul 2003 16:28:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b4Ux-0001sG-00; Fri, 11 Jul 2003 16:28:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b4Uw-0001sD-00; Fri, 11 Jul 2003 16:28:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4Uq-0000TI-VK; Fri, 11 Jul 2003 16:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4UN-0000Su-SX for simple@optimus.ietf.org; Fri, 11 Jul 2003 16:27:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15374 for ; Fri, 11 Jul 2003 16:27:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b4UH-0001rg-00 for simple@ietf.org; Fri, 11 Jul 2003 16:27:25 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19b4UF-0001rQ-00 for simple@ietf.org; Fri, 11 Jul 2003 16:27:24 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h6BKQhB08850 for ; Fri, 11 Jul 2003 15:26:43 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1057955200.925.69.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Hyperlinked agenda for the SIMPLE meeting Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 11 Jul 2003 15:26:41 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A hyperlinked copy of the SIMPLE agenda is available at http://www.softarmor.com/simple/meets/ietf57/agenda.html RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jul 13 06:13:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08703; Sun, 13 Jul 2003 06:13:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bdqs-0001Lf-00; Sun, 13 Jul 2003 06:13:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bdqr-0001La-00; Sun, 13 Jul 2003 06:13:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bdqm-0001ei-PA; Sun, 13 Jul 2003 06:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bdqC-0001eQ-FA for simple@optimus.ietf.org; Sun, 13 Jul 2003 06:12:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08659 for ; Sun, 13 Jul 2003 06:12:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bdq8-0001Kt-00 for simple@ietf.org; Sun, 13 Jul 2003 06:12:20 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bdq8-0001KR-00 for simple@ietf.org; Sun, 13 Jul 2003 06:12:20 -0400 Received: from dynamicsoft.com ([63.113.46.32]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6DABtiB009143 for ; Sun, 13 Jul 2003 06:11:56 -0400 (EDT) Message-ID: <3F10B7DD.9030402@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 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 Content-Transfer-Encoding: 7bit Subject: [Simple] Comments on draft-ietf-simple-publish Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 12 Jul 2003 21:37:33 -0400 Content-Transfer-Encoding: 7bit Some comments: * Section 4 sounds like it is trying to impose guidelines for some kind of registration procedure that event packages need to follow. But, it doesn't explicitly state that. If the intent is to do that (and I think it is), you should follow the basic structure of rfc3265 in terms of how its done. * Section 4 introduces requirements that an event package has to satisfy in order to make use of publish. In some places, it does that by referencing the publish requirements doc. That doc is informational, but you effectively promoting those requirements to normative in your usage. That will be a problem. I recommend that you instead include the specific requirements from the publish requirements doc into publish that define things an event package has to declare. * section 5 - subscribing to the AOR will not likely give you the same information that was published. * section 5 says: > Expires: PUBLISH requests SHOULD contain a single Expires header > field. This value indicates the lifetime of the event state being > published by this request. A special value of "0" indicates the > removal of any prior soft state established by a prior PUBLISH > request from this EPA. I don't think its "any prior soft state" - its the specific soft-state identified by an etag, no? Section 5.5 doesnt say anything about this either. For deletion, when there is not body (and thus no tuple id), there needs to be a way to identify the tuple being deleted. * The numbered steps in section 6 repeat the UA processing in rfc3261. They shouldn't be there. You should just reference rfc3261, and augment the steps there with publish-specific operations. * Bullet 9 of section 6: > the source of the publication (From > URI), and the version of the publication. why is the From needed? * also in step 9: > For new publications, i.e., publications without a version > precondition, the ESC MUST generate a locally unique > entity-tag, and store it, replacing any existing entity-tags > stored for that particular event state. The new entity-tag I don't like this usage of "new". To me, new means that there is no published data for this tuple. But, you are using new to mean that the publication doesnt' have a precondition. That doesnt seem to fit the meaning of "new". * Table 3 - need to indiate its applicability to other methods. * security considerations section: you should discuss specific threats that PUBLISH introduces, and then from these make recommendations (such as SHOULD authenticate). YOu probably want to talk about sensitivity of published data, and say something about sips. On this open issue: > o Atomicity of publication. Should the segments of event state > (presence tuples) be sent in separate PUBLISH requests or is it > enough to treat these as implicitly separate publication requests? I vaguely recall at the interim meeting that the idea was floated that for presence, there were two separate things one could publish. One was a full presence document, in which case there is no "partial publication". The other was just a tuple, representing the partial publication case. In the case where just a tuple is published, I think that each PUBLISH should contain just one tuple. If you want to publish an entire document (in which case you are saying "this is the whole presence state for user X"), you can do that too. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Jul 13 06:13:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08743 for ; Sun, 13 Jul 2003 06:13:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bdqw-0001fa-GY for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 06:13:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DADAZw006414 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 06:13:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bdqw-0001fN-Dn for simple-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 06:13:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08703; Sun, 13 Jul 2003 06:13:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bdqs-0001Lf-00; Sun, 13 Jul 2003 06:13:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bdqr-0001La-00; Sun, 13 Jul 2003 06:13:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bdqm-0001ei-PA; Sun, 13 Jul 2003 06:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bdqC-0001eQ-FA for simple@optimus.ietf.org; Sun, 13 Jul 2003 06:12:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08659 for ; Sun, 13 Jul 2003 06:12:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bdq8-0001Kt-00 for simple@ietf.org; Sun, 13 Jul 2003 06:12:20 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bdq8-0001KR-00 for simple@ietf.org; Sun, 13 Jul 2003 06:12:20 -0400 Received: from dynamicsoft.com ([63.113.46.32]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6DABtiB009143 for ; Sun, 13 Jul 2003 06:11:56 -0400 (EDT) Message-ID: <3F10B7DD.9030402@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 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 Content-Transfer-Encoding: 7bit Subject: [Simple] Comments on draft-ietf-simple-publish Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 12 Jul 2003 21:37:33 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Some comments: * Section 4 sounds like it is trying to impose guidelines for some kind of registration procedure that event packages need to follow. But, it doesn't explicitly state that. If the intent is to do that (and I think it is), you should follow the basic structure of rfc3265 in terms of how its done. * Section 4 introduces requirements that an event package has to satisfy in order to make use of publish. In some places, it does that by referencing the publish requirements doc. That doc is informational, but you effectively promoting those requirements to normative in your usage. That will be a problem. I recommend that you instead include the specific requirements from the publish requirements doc into publish that define things an event package has to declare. * section 5 - subscribing to the AOR will not likely give you the same information that was published. * section 5 says: > Expires: PUBLISH requests SHOULD contain a single Expires header > field. This value indicates the lifetime of the event state being > published by this request. A special value of "0" indicates the > removal of any prior soft state established by a prior PUBLISH > request from this EPA. I don't think its "any prior soft state" - its the specific soft-state identified by an etag, no? Section 5.5 doesnt say anything about this either. For deletion, when there is not body (and thus no tuple id), there needs to be a way to identify the tuple being deleted. * The numbered steps in section 6 repeat the UA processing in rfc3261. They shouldn't be there. You should just reference rfc3261, and augment the steps there with publish-specific operations. * Bullet 9 of section 6: > the source of the publication (From > URI), and the version of the publication. why is the From needed? * also in step 9: > For new publications, i.e., publications without a version > precondition, the ESC MUST generate a locally unique > entity-tag, and store it, replacing any existing entity-tags > stored for that particular event state. The new entity-tag I don't like this usage of "new". To me, new means that there is no published data for this tuple. But, you are using new to mean that the publication doesnt' have a precondition. That doesnt seem to fit the meaning of "new". * Table 3 - need to indiate its applicability to other methods. * security considerations section: you should discuss specific threats that PUBLISH introduces, and then from these make recommendations (such as SHOULD authenticate). YOu probably want to talk about sensitivity of published data, and say something about sips. On this open issue: > o Atomicity of publication. Should the segments of event state > (presence tuples) be sent in separate PUBLISH requests or is it > enough to treat these as implicitly separate publication requests? I vaguely recall at the interim meeting that the idea was floated that for presence, there were two separate things one could publish. One was a full presence document, in which case there is no "partial publication". The other was just a tuple, representing the partial publication case. In the case where just a tuple is published, I think that each PUBLISH should contain just one tuple. If you want to publish an entire document (in which case you are saying "this is the whole presence state for user X"), you can do that too. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jul 13 08:02:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14813; Sun, 13 Jul 2003 08:02:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bfYM-0002rl-00; Sun, 13 Jul 2003 08:02:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bfYM-0002ri-00; Sun, 13 Jul 2003 08:02:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bfYH-0004EB-OL; Sun, 13 Jul 2003 08:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bfXJ-00047g-3E for simple@optimus.ietf.org; Sun, 13 Jul 2003 08:01:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14734 for ; Sun, 13 Jul 2003 08:00:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bfXG-0002qj-00 for simple@ietf.org; Sun, 13 Jul 2003 08:00:58 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bfXF-0002q5-00 for simple@ietf.org; Sun, 13 Jul 2003 08:00:58 -0400 Received: from dynamicsoft.com ([63.113.46.119]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6DC0UiB009171; Sun, 13 Jul 2003 08:00:31 -0400 (EDT) Message-ID: <3F1149D9.20009@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: simple@ietf.org Subject: Re: [Simple] Tuple design team discussion summary References: <1056655976.1917.62.camel@RjS.localdomain> In-Reply-To: <1056655976.1917.62.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 08:00:25 -0400 Content-Transfer-Encoding: 7bit I agree with all of this. However, I think the cost of the flexibility in this model is that we need some additional features from RPIDS to help the watcher determine what is meant by a tuple. The essence of the problem is that, for small displays (and maybe even for more capable ones), you want to be able to present the user with a single icon, or a label, that says something about each tuple. The important characteristic of this icon is that the icons for each tuple are sufficiently different from each other to convey what the differences in the tuples are. THat allows the user to quickly and easily make a choice. As an example - if I have a presence document with two tuples, one of which is a wireless phone, and one of which is a landline phone, the display might have icons representing the two different phone types. Now, the big question is: can a watcher agent look at the tuples, and based on their attributes, come up with an iconic representation of them? Or, does the PA need to provide the watcher with some kind of categorization which can be directly mapped to an icon? Its not obvious to me that an algorithm can be written to look at the tuples and come up with a meaningful classification for each. In some cases, its definitely easy. When you have a bunch of tuples, each of which differ in a single attribute, then the value of that attribute becomes the primary categorization. So, in this case open fixed quite sip:wireline-phone@example.com open mobile quite sip:wireless@example.com A piece of software can easily know that the only difference between these two is the mobility attribute, and so it can have a set of icons representing different values of mobility. Things are more complex when each tuple has multiple attributes, each of which differs. In that case, its not clear how to come up with a meaningful icon to represent the tuple without assistance from the PA. Using one of Brian's examples: AOR contact media status geoloc br@example.com 54ea@example.com aud open x1,y1:x2,y2 br@example.com b56c@example.com aud,vid open x1,y1 br@example.com 32a1@example.com im open x1,y1:x3,y3 What icon would a watcher agent use to represent each of these? Hard to say. So, I think there is value in having an RPIDS attribute which conveys some kind of information about what the tuple represents. We can start with a basic set of types: "cell phone" "PDA" "wireline phone" "IM service" etc., and support extensibility down the road. -Jonathan R. Robert Sparks wrote: > Folks - > > The tuple design team has been working since the interim meeting > to build a clearer picture of how we can make the best use of tuples. > > This team was able to reach consensus on the following points: > > - A tuple with contact advertises a handle that can be used for > communication with the presentity. This is the foundation of > what a tuple "means". > > - Tuples may expose supplemental status information that > a watcher can use to distinguish between them. > > - Presence agents can generate documents with many different > policies for constructing tuples and we don't want to prevent that. > > Some example policies discussed include: > o always building a document with a single tuple > representing a unified view of the presentity determined > by the presence agent. > o building documents where each tuple represents a unified > view of communicating with the presentity using a particular > type of media > o building documents where each available communication endpoint > is advertised as a separate tuple. > > - We do not want to grant preferential status to any particular policy > for constructing tuples. > > This point was intensely debated. The central point was > whether or not generic clients would be able to sensibly > render (or make automated decisions using) documents > constructed with different policies. We achieved rough > consensus that this was possible. > > > At the interim, we agreed that PUBLISH should identify the tuple > it is operating on using the id parameter. That approach is > consistent with the above conclusions, and Aki is proceeding with > the PUBLISH draft using it. (This has some ramifications which will be > discussed in a separate message.) > > This is good progress - enough, I believe, that we can move forward > with it and finish the fundamental versions of many of our deliverables. > > There are still questions around the use of tuples to be discussed. > The one this design team was circling around whether a PA needs to > expose the policy it used to create tuples to the watcher and whether > a watcher needs to be able to request a certain policy. This discussion > will move back to the SIMPLE list. > > There are other positive by-products of this teams efforts, including > a model that Henning has started developing for describing operations > over a set of tuples that will be helpful as we address composition. > > The tuple design team consisted of: > > Adam Roach > Aki Niemi > Aziz Mohammed > Ben Campbell > Brian Rosen > Henning Schulzrinne > Jon Peterson > Jonathan Rosenberg > Keith Drage > Paul Kyzivat > Robert Sparks > Thanos Diacakis > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Jul 13 08:02:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14870 for ; Sun, 13 Jul 2003 08:02:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bfYO-0004Eu-P9 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 08:02:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DC28Qn016290 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 08:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bfYO-0004Ef-Kc for simple-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 08:02:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14813; Sun, 13 Jul 2003 08:02:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bfYM-0002rl-00; Sun, 13 Jul 2003 08:02:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bfYM-0002ri-00; Sun, 13 Jul 2003 08:02:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bfYH-0004EB-OL; Sun, 13 Jul 2003 08:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bfXJ-00047g-3E for simple@optimus.ietf.org; Sun, 13 Jul 2003 08:01:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14734 for ; Sun, 13 Jul 2003 08:00:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bfXG-0002qj-00 for simple@ietf.org; Sun, 13 Jul 2003 08:00:58 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bfXF-0002q5-00 for simple@ietf.org; Sun, 13 Jul 2003 08:00:58 -0400 Received: from dynamicsoft.com ([63.113.46.119]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6DC0UiB009171; Sun, 13 Jul 2003 08:00:31 -0400 (EDT) Message-ID: <3F1149D9.20009@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: simple@ietf.org Subject: Re: [Simple] Tuple design team discussion summary References: <1056655976.1917.62.camel@RjS.localdomain> In-Reply-To: <1056655976.1917.62.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 08:00:25 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with all of this. However, I think the cost of the flexibility in this model is that we need some additional features from RPIDS to help the watcher determine what is meant by a tuple. The essence of the problem is that, for small displays (and maybe even for more capable ones), you want to be able to present the user with a single icon, or a label, that says something about each tuple. The important characteristic of this icon is that the icons for each tuple are sufficiently different from each other to convey what the differences in the tuples are. THat allows the user to quickly and easily make a choice. As an example - if I have a presence document with two tuples, one of which is a wireless phone, and one of which is a landline phone, the display might have icons representing the two different phone types. Now, the big question is: can a watcher agent look at the tuples, and based on their attributes, come up with an iconic representation of them? Or, does the PA need to provide the watcher with some kind of categorization which can be directly mapped to an icon? Its not obvious to me that an algorithm can be written to look at the tuples and come up with a meaningful classification for each. In some cases, its definitely easy. When you have a bunch of tuples, each of which differ in a single attribute, then the value of that attribute becomes the primary categorization. So, in this case open fixed quite sip:wireline-phone@example.com open mobile quite sip:wireless@example.com A piece of software can easily know that the only difference between these two is the mobility attribute, and so it can have a set of icons representing different values of mobility. Things are more complex when each tuple has multiple attributes, each of which differs. In that case, its not clear how to come up with a meaningful icon to represent the tuple without assistance from the PA. Using one of Brian's examples: AOR contact media status geoloc br@example.com 54ea@example.com aud open x1,y1:x2,y2 br@example.com b56c@example.com aud,vid open x1,y1 br@example.com 32a1@example.com im open x1,y1:x3,y3 What icon would a watcher agent use to represent each of these? Hard to say. So, I think there is value in having an RPIDS attribute which conveys some kind of information about what the tuple represents. We can start with a basic set of types: "cell phone" "PDA" "wireline phone" "IM service" etc., and support extensibility down the road. -Jonathan R. Robert Sparks wrote: > Folks - > > The tuple design team has been working since the interim meeting > to build a clearer picture of how we can make the best use of tuples. > > This team was able to reach consensus on the following points: > > - A tuple with contact advertises a handle that can be used for > communication with the presentity. This is the foundation of > what a tuple "means". > > - Tuples may expose supplemental status information that > a watcher can use to distinguish between them. > > - Presence agents can generate documents with many different > policies for constructing tuples and we don't want to prevent that. > > Some example policies discussed include: > o always building a document with a single tuple > representing a unified view of the presentity determined > by the presence agent. > o building documents where each tuple represents a unified > view of communicating with the presentity using a particular > type of media > o building documents where each available communication endpoint > is advertised as a separate tuple. > > - We do not want to grant preferential status to any particular policy > for constructing tuples. > > This point was intensely debated. The central point was > whether or not generic clients would be able to sensibly > render (or make automated decisions using) documents > constructed with different policies. We achieved rough > consensus that this was possible. > > > At the interim, we agreed that PUBLISH should identify the tuple > it is operating on using the id parameter. That approach is > consistent with the above conclusions, and Aki is proceeding with > the PUBLISH draft using it. (This has some ramifications which will be > discussed in a separate message.) > > This is good progress - enough, I believe, that we can move forward > with it and finish the fundamental versions of many of our deliverables. > > There are still questions around the use of tuples to be discussed. > The one this design team was circling around whether a PA needs to > expose the policy it used to create tuples to the watcher and whether > a watcher needs to be able to request a certain policy. This discussion > will move back to the SIMPLE list. > > There are other positive by-products of this teams efforts, including > a model that Henning has started developing for describing operations > over a set of tuples that will be helpful as we address composition. > > The tuple design team consisted of: > > Adam Roach > Aki Niemi > Aziz Mohammed > Ben Campbell > Brian Rosen > Henning Schulzrinne > Jon Peterson > Jonathan Rosenberg > Keith Drage > Paul Kyzivat > Robert Sparks > Thanos Diacakis > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jul 13 08:05:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15033; Sun, 13 Jul 2003 08:05:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bfbE-0002uc-00; Sun, 13 Jul 2003 08:05:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bfbE-0002uZ-00; Sun, 13 Jul 2003 08:05:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bfbA-0004Kv-QQ; Sun, 13 Jul 2003 08:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bfb5-0004Kc-TG for simple@optimus.ietf.org; Sun, 13 Jul 2003 08:04:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15024 for ; Sun, 13 Jul 2003 08:04:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bfb4-0002uL-00 for simple@ietf.org; Sun, 13 Jul 2003 08:04:54 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bfb4-0002tq-00 for simple@ietf.org; Sun, 13 Jul 2003 08:04:54 -0400 Received: from dynamicsoft.com ([63.113.46.119]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6DC4RiB009175 for ; Sun, 13 Jul 2003 08:04:28 -0400 (EDT) Message-ID: <3F114AC6.1070002@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 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 Content-Transfer-Encoding: 7bit Subject: [Simple] asking for a specific view Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 08:04:22 -0400 Content-Transfer-Encoding: 7bit Folks, One of the conclusions of the tuple design team was that we want to allow a PA the flexibility to have tuples represent anything they want. This means that a PA can compose, aggregate, and otherwise discard information as it sees fit. However, in some cases, a watcher is interested in a specific type of information, and furthermore, a specific type of information within the context of a specific view. As an example, a watcher application that wants to send an SMS to a phone when it finds its not in a call, will want to see a device-centric view of a user, so that it can check the call state of the device. It is possible that, by default, the PA would not provide information to the watcher in a device-centric view. Rather, its policy is to send a single tuple with summary information. If this happens, the watcher doesnt get the information they need, since its been aggregated away. To remedy this, I think we need to enhance the filter work to allow a watcher to ask for a specific view of the presence data. We have some work to do to define a view, but we have a couple of good candidates to work from. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Jul 13 08:05:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15071 for ; Sun, 13 Jul 2003 08:05:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bfbG-0004OK-EC for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 08:05:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DC56Ux016875 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 08:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bfbG-0004O6-BM for simple-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 08:05:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15033; Sun, 13 Jul 2003 08:05:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bfbE-0002uc-00; Sun, 13 Jul 2003 08:05:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bfbE-0002uZ-00; Sun, 13 Jul 2003 08:05:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bfbA-0004Kv-QQ; Sun, 13 Jul 2003 08:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bfb5-0004Kc-TG for simple@optimus.ietf.org; Sun, 13 Jul 2003 08:04:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15024 for ; Sun, 13 Jul 2003 08:04:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bfb4-0002uL-00 for simple@ietf.org; Sun, 13 Jul 2003 08:04:54 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bfb4-0002tq-00 for simple@ietf.org; Sun, 13 Jul 2003 08:04:54 -0400 Received: from dynamicsoft.com ([63.113.46.119]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6DC4RiB009175 for ; Sun, 13 Jul 2003 08:04:28 -0400 (EDT) Message-ID: <3F114AC6.1070002@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 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 Content-Transfer-Encoding: 7bit Subject: [Simple] asking for a specific view Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 08:04:22 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, One of the conclusions of the tuple design team was that we want to allow a PA the flexibility to have tuples represent anything they want. This means that a PA can compose, aggregate, and otherwise discard information as it sees fit. However, in some cases, a watcher is interested in a specific type of information, and furthermore, a specific type of information within the context of a specific view. As an example, a watcher application that wants to send an SMS to a phone when it finds its not in a call, will want to see a device-centric view of a user, so that it can check the call state of the device. It is possible that, by default, the PA would not provide information to the watcher in a device-centric view. Rather, its policy is to send a single tuple with summary information. If this happens, the watcher doesnt get the information they need, since its been aggregated away. To remedy this, I think we need to enhance the filter work to allow a watcher to ask for a specific view of the presence data. We have some work to do to define a view, but we have a couple of good candidates to work from. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jul 13 09:37:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20825; Sun, 13 Jul 2003 09:37:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bh2H-0004OU-00; Sun, 13 Jul 2003 09:37:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bh2G-0004OR-00; Sun, 13 Jul 2003 09:37:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bh2D-0007NG-CQ; Sun, 13 Jul 2003 09:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bh20-0007M3-Ic for simple@optimus.ietf.org; Sun, 13 Jul 2003 09:36:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20795 for ; Sun, 13 Jul 2003 09:36:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bh1y-0004OC-00 for simple@ietf.org; Sun, 13 Jul 2003 09:36:46 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bh1y-0004Nf-00 for simple@ietf.org; Sun, 13 Jul 2003 09:36:46 -0400 Received: from dynamicsoft.com ([63.113.46.119]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6DDaCiB009196; Sun, 13 Jul 2003 09:36:13 -0400 (EDT) Message-ID: <3F116046.3040707@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C54@stntexch2.va.neustar.com> <3F039C6B.3020305@cs.columbia.edu> In-Reply-To: <3F039C6B.3020305@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 09:36:06 -0400 Content-Transfer-Encoding: 7bit I agree with Jon that something like is far more preferable than . Not only does this clearly delineate it from note, it makes it easier for an automata to do something useful with it (for example, add it to the "Homepages of My Friends" bookmark folder in my browser). says nothing about whats in there. -Jonathan R. Henning Schulzrinne wrote: > I think I now better understand your question. This is indeed meant as > more "long-term" information. The name and definition stems from the > similarly-named field in the SIP Call-Info header. As usual, I'm not > wedded to particular labels. > > Thus, as you said, this falls into the open issue as to how this more > longer-term material should be handled. > > I will amplify the definition. > > Peterson, Jon wrote: > >>> What I'm concerned about here is that there are two elements - >>> and >>> - that do the same thing, according to their respective >>> specifications. As it's written, provides "general information >> >> >> about >> >>> the tuple", and in a tuple provides "a comment" "regarding the >>> particular tuple". So when you have some information about a tuple, >>> do you >>> put it in a or an ? >> >> >> >> If you want to change the definition of in rpids-00 such that it >> provides information about a presentity, then I'm at least a little >> clearer >> as to how this is different from (though perhaps not a >> -level note). But again, in that case or >> something as a >> -level attribute would be preferable to (although it is >> debatably 'presence information' then). >> >> [snip] >> >>> Think of this as "this is a link to information describing the tuple". >>> >>> The reason for reference instead of value is simply efficiency. >>> >> >> >> And as I said in my original note, I don't think that by-reference vs. >> by-value alone is sufficient grounds to break backwards compatibility. >> >> I think the text about needs to reflect whether or not it contains >> the same information that would appear ordinarily in a (except >> it's >> by-reference to save bytes or what have you) - and acknowledge that >> this is >> an optimization that encourages information to appear exclusively for >> RPIDS-friendly recipients, not for baseline PIDF recipients - or >> explain how >> the information in differs from . But in the absence of such >> further qualifications, I still think it should be removed. >> >> Jon Peterson >> NeuStar, Inc. >> >> _______________________________________________ >> 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 Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Jul 13 09:37:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20894 for ; Sun, 13 Jul 2003 09:37:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bh2J-0007SV-Er for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 09:37:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DDb79s028669 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 09:37:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bh2J-0007SC-By for simple-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 09:37:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20825; Sun, 13 Jul 2003 09:37:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bh2H-0004OU-00; Sun, 13 Jul 2003 09:37:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bh2G-0004OR-00; Sun, 13 Jul 2003 09:37:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bh2D-0007NG-CQ; Sun, 13 Jul 2003 09:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bh20-0007M3-Ic for simple@optimus.ietf.org; Sun, 13 Jul 2003 09:36:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20795 for ; Sun, 13 Jul 2003 09:36:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bh1y-0004OC-00 for simple@ietf.org; Sun, 13 Jul 2003 09:36:46 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bh1y-0004Nf-00 for simple@ietf.org; Sun, 13 Jul 2003 09:36:46 -0400 Received: from dynamicsoft.com ([63.113.46.119]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6DDaCiB009196; Sun, 13 Jul 2003 09:36:13 -0400 (EDT) Message-ID: <3F116046.3040707@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C54@stntexch2.va.neustar.com> <3F039C6B.3020305@cs.columbia.edu> In-Reply-To: <3F039C6B.3020305@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 09:36:06 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Jon that something like is far more preferable than . Not only does this clearly delineate it from note, it makes it easier for an automata to do something useful with it (for example, add it to the "Homepages of My Friends" bookmark folder in my browser). says nothing about whats in there. -Jonathan R. Henning Schulzrinne wrote: > I think I now better understand your question. This is indeed meant as > more "long-term" information. The name and definition stems from the > similarly-named field in the SIP Call-Info header. As usual, I'm not > wedded to particular labels. > > Thus, as you said, this falls into the open issue as to how this more > longer-term material should be handled. > > I will amplify the definition. > > Peterson, Jon wrote: > >>> What I'm concerned about here is that there are two elements - >>> and >>> - that do the same thing, according to their respective >>> specifications. As it's written, provides "general information >> >> >> about >> >>> the tuple", and in a tuple provides "a comment" "regarding the >>> particular tuple". So when you have some information about a tuple, >>> do you >>> put it in a or an ? >> >> >> >> If you want to change the definition of in rpids-00 such that it >> provides information about a presentity, then I'm at least a little >> clearer >> as to how this is different from (though perhaps not a >> -level note). But again, in that case or >> something as a >> -level attribute would be preferable to (although it is >> debatably 'presence information' then). >> >> [snip] >> >>> Think of this as "this is a link to information describing the tuple". >>> >>> The reason for reference instead of value is simply efficiency. >>> >> >> >> And as I said in my original note, I don't think that by-reference vs. >> by-value alone is sufficient grounds to break backwards compatibility. >> >> I think the text about needs to reflect whether or not it contains >> the same information that would appear ordinarily in a (except >> it's >> by-reference to save bytes or what have you) - and acknowledge that >> this is >> an optimization that encourages information to appear exclusively for >> RPIDS-friendly recipients, not for baseline PIDF recipients - or >> explain how >> the information in differs from . But in the absence of such >> further qualifications, I still think it should be removed. >> >> Jon Peterson >> NeuStar, Inc. >> >> _______________________________________________ >> 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 Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jul 13 09:38:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20930; Sun, 13 Jul 2003 09:38:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bh3C-0004Pn-00; Sun, 13 Jul 2003 09:38:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bh3C-0004Pk-00; Sun, 13 Jul 2003 09:38:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bh3A-0007iv-IX; Sun, 13 Jul 2003 09:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bh31-0007hv-LQ for simple@optimus.ietf.org; Sun, 13 Jul 2003 09:37:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20918 for ; Sun, 13 Jul 2003 09:37:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bh2z-0004PP-00 for simple@ietf.org; Sun, 13 Jul 2003 09:37:49 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bh2z-0004Oo-00 for simple@ietf.org; Sun, 13 Jul 2003 09:37:49 -0400 Received: from dynamicsoft.com ([63.113.46.119]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6DDbHiB009199; Sun, 13 Jul 2003 09:37:17 -0400 (EDT) Message-ID: <3F116087.5020701@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Peterson, Jon" , simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - face-to-face References: <0449D80A0E9B614A83FA9031B07E8D3B257C1D@stntexch2.va.neustar.com> <3EFDB74A.7040707@cs.columbia.edu> In-Reply-To: <3EFDB74A.7040707@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 09:37:11 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Agreed; tentatively added as 'mediated' parameter in to-be-revised > capabilities element, as in > > Does this mean it also becomes a callee-caps parameter as well? Not sure what it means in that context... -Jonathan R. > > Peterson, Jon wrote: > > >> In this case, I'd personally prefer an explicit indicator for >> 'available for >> face-to-face' - I don't think this is something that should be derived >> implicitly from the absence of a network-bound means of >> communications. Off >> the top of my head, I think this should be deferred to the capability >> work >> that had already been broken out of RPIDS (which seems to get more >> into the >> "how"s of communication). >> >> Jon Peterson >> NeuStar, Inc. > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Jul 13 09:38:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20979 for ; Sun, 13 Jul 2003 09:38:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bh3F-0007mm-0V for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 09:38:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DDc4H2029922 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 09:38:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bh3E-0007mX-TL for simple-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 09:38:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20930; Sun, 13 Jul 2003 09:38:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bh3C-0004Pn-00; Sun, 13 Jul 2003 09:38:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bh3C-0004Pk-00; Sun, 13 Jul 2003 09:38:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bh3A-0007iv-IX; Sun, 13 Jul 2003 09:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bh31-0007hv-LQ for simple@optimus.ietf.org; Sun, 13 Jul 2003 09:37:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20918 for ; Sun, 13 Jul 2003 09:37:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bh2z-0004PP-00 for simple@ietf.org; Sun, 13 Jul 2003 09:37:49 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bh2z-0004Oo-00 for simple@ietf.org; Sun, 13 Jul 2003 09:37:49 -0400 Received: from dynamicsoft.com ([63.113.46.119]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6DDbHiB009199; Sun, 13 Jul 2003 09:37:17 -0400 (EDT) Message-ID: <3F116087.5020701@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Peterson, Jon" , simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - face-to-face References: <0449D80A0E9B614A83FA9031B07E8D3B257C1D@stntexch2.va.neustar.com> <3EFDB74A.7040707@cs.columbia.edu> In-Reply-To: <3EFDB74A.7040707@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 09:37:11 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Agreed; tentatively added as 'mediated' parameter in to-be-revised > capabilities element, as in > > Does this mean it also becomes a callee-caps parameter as well? Not sure what it means in that context... -Jonathan R. > > Peterson, Jon wrote: > > >> In this case, I'd personally prefer an explicit indicator for >> 'available for >> face-to-face' - I don't think this is something that should be derived >> implicitly from the absence of a network-bound means of >> communications. Off >> the top of my head, I think this should be deferred to the capability >> work >> that had already been broken out of RPIDS (which seems to get more >> into the >> "how"s of communication). >> >> Jon Peterson >> NeuStar, Inc. > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jul 13 09:55:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21851; Sun, 13 Jul 2003 09:55:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhJq-0004eZ-00; Sun, 13 Jul 2003 09:55:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bhJp-0004eW-00; Sun, 13 Jul 2003 09:55:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhJd-00085K-3D; Sun, 13 Jul 2003 09:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhJP-00084x-T9 for simple@optimus.ietf.org; Sun, 13 Jul 2003 09:54:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21836 for ; Sun, 13 Jul 2003 09:54:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhJN-0004dz-00 for simple@ietf.org; Sun, 13 Jul 2003 09:54:46 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bhJN-0004dw-00 for simple@ietf.org; Sun, 13 Jul 2003 09:54:45 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6DDsikM028337; Sun, 13 Jul 2003 09:54:44 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6DDsgk00364; Sun, 13 Jul 2003 09:54:43 -0400 Message-ID: <3F1163AC.4090402@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Robert Sparks , simple@ietf.org Subject: Re: [Simple] Tuple design team discussion summary References: <1056655976.1917.62.camel@RjS.localdomain> <3F1149D9.20009@dynamicsoft.com> In-Reply-To: <3F1149D9.20009@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 09:50:36 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > So, I think there is value in having an RPIDS attribute which conveys > some kind of information about what the tuple represents. We can start > with a basic set of types: > > "cell phone" > "PDA" > "wireline phone" > "IM service" > > etc., and support extensibility down the road. I generally agree; to further divvy up the problem, there are really four ways to do this: (1) the presentity (or composer) suggests an icon that it believes represents the tuple; the latest RPIDS drafts has a facility for that () (2) the presentity (or composer) suggests a general classifying label, but without pre-defined or standardized meanings. This doesn't allow general iconization without some out-of-band cooperation, but does allow the watcher to group similar tuples. The RPIDS 'class' attribute offers this facility. (3) a cross-product of two common attributes, such as media and mobility, is sufficient to characterize most devices and services. This does not allow to distinguish a cell phone from a PDA, but devices like a Treo or Blackberry-with-cellphone may make that rather tricky in any event. (It is not clear to me that a PDA is a useful distinction, beyond the notion of mobility.) This seems to cover the examples you offered in the snippet above. (4) we define a new attribute or element that represents a standardized description of the elements that represents common devices. I think before we go down that path it might be helpful to see if such a list can be defined and whether this is substantially different from (3). Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Jul 13 09:55:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21894 for ; Sun, 13 Jul 2003 09:55:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhJs-00088m-I0 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 09:55:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DDtGDP031288 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 09:55:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhJs-00088Z-EN for simple-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 09:55:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21851; Sun, 13 Jul 2003 09:55:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhJq-0004eZ-00; Sun, 13 Jul 2003 09:55:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bhJp-0004eW-00; Sun, 13 Jul 2003 09:55:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhJd-00085K-3D; Sun, 13 Jul 2003 09:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhJP-00084x-T9 for simple@optimus.ietf.org; Sun, 13 Jul 2003 09:54:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21836 for ; Sun, 13 Jul 2003 09:54:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhJN-0004dz-00 for simple@ietf.org; Sun, 13 Jul 2003 09:54:46 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bhJN-0004dw-00 for simple@ietf.org; Sun, 13 Jul 2003 09:54:45 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6DDsikM028337; Sun, 13 Jul 2003 09:54:44 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6DDsgk00364; Sun, 13 Jul 2003 09:54:43 -0400 Message-ID: <3F1163AC.4090402@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Robert Sparks , simple@ietf.org Subject: Re: [Simple] Tuple design team discussion summary References: <1056655976.1917.62.camel@RjS.localdomain> <3F1149D9.20009@dynamicsoft.com> In-Reply-To: <3F1149D9.20009@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 09:50:36 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > So, I think there is value in having an RPIDS attribute which conveys > some kind of information about what the tuple represents. We can start > with a basic set of types: > > "cell phone" > "PDA" > "wireline phone" > "IM service" > > etc., and support extensibility down the road. I generally agree; to further divvy up the problem, there are really four ways to do this: (1) the presentity (or composer) suggests an icon that it believes represents the tuple; the latest RPIDS drafts has a facility for that () (2) the presentity (or composer) suggests a general classifying label, but without pre-defined or standardized meanings. This doesn't allow general iconization without some out-of-band cooperation, but does allow the watcher to group similar tuples. The RPIDS 'class' attribute offers this facility. (3) a cross-product of two common attributes, such as media and mobility, is sufficient to characterize most devices and services. This does not allow to distinguish a cell phone from a PDA, but devices like a Treo or Blackberry-with-cellphone may make that rather tricky in any event. (It is not clear to me that a PDA is a useful distinction, beyond the notion of mobility.) This seems to cover the examples you offered in the snippet above. (4) we define a new attribute or element that represents a standardized description of the elements that represents common devices. I think before we go down that path it might be helpful to see if such a list can be defined and whether this is substantially different from (3). Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jul 13 10:01:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22268; Sun, 13 Jul 2003 10:01:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhPa-0004lW-00; Sun, 13 Jul 2003 10:01:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bhPZ-0004lT-00; Sun, 13 Jul 2003 10:01:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhPR-0008Gn-Cu; Sun, 13 Jul 2003 10:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhOY-0008Fg-7x for simple@optimus.ietf.org; Sun, 13 Jul 2003 10:00:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22178 for ; Sun, 13 Jul 2003 10:00:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhOW-0004kJ-00 for simple@ietf.org; Sun, 13 Jul 2003 10:00:04 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bhOV-0004j7-00 for simple@ietf.org; Sun, 13 Jul 2003 10:00:03 -0400 Received: from dynamicsoft.com ([63.113.46.119]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6DDxViB009203; Sun, 13 Jul 2003 09:59:32 -0400 (EDT) Message-ID: <3F1165BD.8010406@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Henning Schulzrinne'" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> In-Reply-To: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 09:59:25 -0400 Content-Transfer-Encoding: 7bit Peterson, Jon wrote: >>I agree that a callee attribute in draft-ietf-sip-callee-caps might well >>be useful. We have the notion of 'attendant', but this simply says that >>the call will be answered by some other party, not that this Contact URI >>*is* an attendant. >> > > > Right. I think it is useful to view this as a general SIP problem: that > there can be an AoR that has one or more support AoRs (as opposed to > devices) registered behind it, and that consequently it might be useful to > supply a parameter that says how the parties behind such support AoRs are > related to the primary AoR. > > It might be useful for a normal user agent to be able to look at a > redirection when such callee caps appear and for the user to decide "well, > no, I don't want to talk to any of Bob's family members". I'm not sure that works for presence, though. That is, I don't think you could generate a SUBSCRIBE with appropriate caller preferences parameters to just get the presence of the executive and not their support staff. I'm in agreement with Jon that we don't want to populate Joe's presence document with tuples that really describe Bob, just because Bob is Joe's assistant. But, Bob does represent a point of contact for Joe, and I think that information itself is useful presence. So, how about this. We could mandate that when a contact contains the element, the tuple has no other information except for open/closed. The element can have an attribute which says where to go to get the acutal presence for that user: open sip:secretary@example.com assistant My secretary This way, there is never actual presence information for the secretary - only a reference to obtain it. But, the secretary is listed as a contact point. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Jul 13 10:01:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22323 for ; Sun, 13 Jul 2003 10:01:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhPc-0008KG-Vf for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 10:01:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DE1CAd031999 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 10:01:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhPc-0008K2-Sf for simple-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 10:01:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22268; Sun, 13 Jul 2003 10:01:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhPa-0004lW-00; Sun, 13 Jul 2003 10:01:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bhPZ-0004lT-00; Sun, 13 Jul 2003 10:01:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhPR-0008Gn-Cu; Sun, 13 Jul 2003 10:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhOY-0008Fg-7x for simple@optimus.ietf.org; Sun, 13 Jul 2003 10:00:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22178 for ; Sun, 13 Jul 2003 10:00:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhOW-0004kJ-00 for simple@ietf.org; Sun, 13 Jul 2003 10:00:04 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bhOV-0004j7-00 for simple@ietf.org; Sun, 13 Jul 2003 10:00:03 -0400 Received: from dynamicsoft.com ([63.113.46.119]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6DDxViB009203; Sun, 13 Jul 2003 09:59:32 -0400 (EDT) Message-ID: <3F1165BD.8010406@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Henning Schulzrinne'" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> In-Reply-To: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 09:59:25 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Peterson, Jon wrote: >>I agree that a callee attribute in draft-ietf-sip-callee-caps might well >>be useful. We have the notion of 'attendant', but this simply says that >>the call will be answered by some other party, not that this Contact URI >>*is* an attendant. >> > > > Right. I think it is useful to view this as a general SIP problem: that > there can be an AoR that has one or more support AoRs (as opposed to > devices) registered behind it, and that consequently it might be useful to > supply a parameter that says how the parties behind such support AoRs are > related to the primary AoR. > > It might be useful for a normal user agent to be able to look at a > redirection when such callee caps appear and for the user to decide "well, > no, I don't want to talk to any of Bob's family members". I'm not sure that works for presence, though. That is, I don't think you could generate a SUBSCRIBE with appropriate caller preferences parameters to just get the presence of the executive and not their support staff. I'm in agreement with Jon that we don't want to populate Joe's presence document with tuples that really describe Bob, just because Bob is Joe's assistant. But, Bob does represent a point of contact for Joe, and I think that information itself is useful presence. So, how about this. We could mandate that when a contact contains the element, the tuple has no other information except for open/closed. The element can have an attribute which says where to go to get the acutal presence for that user: open sip:secretary@example.com assistant My secretary This way, there is never actual presence information for the secretary - only a reference to obtain it. But, the secretary is listed as a contact point. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jul 13 10:09:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23222; Sun, 13 Jul 2003 10:09:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhXE-0004sY-00; Sun, 13 Jul 2003 10:09:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bhXD-0004sV-00; Sun, 13 Jul 2003 10:09:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhXB-0000En-ES; Sun, 13 Jul 2003 10:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhWI-0000EL-Up for simple@optimus.ietf.org; Sun, 13 Jul 2003 10:08:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23082 for ; Sun, 13 Jul 2003 10:08:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhWG-0004rZ-00 for simple@ietf.org; Sun, 13 Jul 2003 10:08:04 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bhWG-0004rC-00 for simple@ietf.org; Sun, 13 Jul 2003 10:08:04 -0400 Received: from dynamicsoft.com ([63.113.46.119]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6DE7UiB009207; Sun, 13 Jul 2003 10:07:31 -0400 (EDT) Message-ID: <3F11679C.8010004@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: jon.peterson@neustar.biz, hgs@cs.columbia.edu, simple@ietf.org Subject: Re: [Simple] comments on rpids-01 (general, vCard, predictive) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8E43@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8E43@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 10:07:24 -0400 Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: >> >> Again, commercial instant messaging systems, in my experience, >> don't use presentity-provided icons to express a presentity's >> current state in a watcher's buddylist screen. Apps might have >> predefined icons corresponding to, say, your state as >> given in rpids-00, but I don't think I've seen user-supplied >> versions of those icons to date. The whole value of these >> buddylist icons is that they're the same for all users in the >> same - if your used-defined icon for 'away' looks >> different from somebody else icon for 'away', then icons aren't >> making the buddylist screen any easier to interpret. The custom >> icons that are used in commercial IM&P products today show up in >> a different context, afaik. > > As I've said before, there are commercial systems out there that do > use graphics to describe a presentity's status. The provided icons > are not meant to replace "away" icons on buddylists - I believe > they are more akin to a personalized, graphical . > > And as long as we're aiming at enabling a SIMPLE application on par > with the market, we might as well look at all commecial systems, > not just some of them. I agree that icon is useful, but I think we need to say a lot more about it. In particular, the assumption is, I think, that these icons will be used as part of a user interface. In that case, its not just merely rendered in a browser, but rather would assumed to meet some constraints in order to be used as part of an application UI. Certainly size is the most important one. At the very least, a certain aspect ration may need to exist, and perhaps a specific size, if the UI can't resize images. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Jul 13 10:09:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23312 for ; Sun, 13 Jul 2003 10:09:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhXH-0000He-DO for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 10:09:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DE975E001067 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 10:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhXH-0000GZ-AJ for simple-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 10:09:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23222; Sun, 13 Jul 2003 10:09:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhXE-0004sY-00; Sun, 13 Jul 2003 10:09:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bhXD-0004sV-00; Sun, 13 Jul 2003 10:09:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhXB-0000En-ES; Sun, 13 Jul 2003 10:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhWI-0000EL-Up for simple@optimus.ietf.org; Sun, 13 Jul 2003 10:08:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23082 for ; Sun, 13 Jul 2003 10:08:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhWG-0004rZ-00 for simple@ietf.org; Sun, 13 Jul 2003 10:08:04 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bhWG-0004rC-00 for simple@ietf.org; Sun, 13 Jul 2003 10:08:04 -0400 Received: from dynamicsoft.com ([63.113.46.119]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6DE7UiB009207; Sun, 13 Jul 2003 10:07:31 -0400 (EDT) Message-ID: <3F11679C.8010004@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: jon.peterson@neustar.biz, hgs@cs.columbia.edu, simple@ietf.org Subject: Re: [Simple] comments on rpids-01 (general, vCard, predictive) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8E43@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8E43@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 10:07:24 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: >> >> Again, commercial instant messaging systems, in my experience, >> don't use presentity-provided icons to express a presentity's >> current state in a watcher's buddylist screen. Apps might have >> predefined icons corresponding to, say, your state as >> given in rpids-00, but I don't think I've seen user-supplied >> versions of those icons to date. The whole value of these >> buddylist icons is that they're the same for all users in the >> same - if your used-defined icon for 'away' looks >> different from somebody else icon for 'away', then icons aren't >> making the buddylist screen any easier to interpret. The custom >> icons that are used in commercial IM&P products today show up in >> a different context, afaik. > > As I've said before, there are commercial systems out there that do > use graphics to describe a presentity's status. The provided icons > are not meant to replace "away" icons on buddylists - I believe > they are more akin to a personalized, graphical . > > And as long as we're aiming at enabling a SIMPLE application on par > with the market, we might as well look at all commecial systems, > not just some of them. I agree that icon is useful, but I think we need to say a lot more about it. In particular, the assumption is, I think, that these icons will be used as part of a user interface. In that case, its not just merely rendered in a browser, but rather would assumed to meet some constraints in order to be used as part of an application UI. Certainly size is the most important one. At the very least, a certain aspect ration may need to exist, and perhaps a specific size, if the UI can't resize images. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jul 13 10:12:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23622; Sun, 13 Jul 2003 10:12:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhaA-0004vA-00; Sun, 13 Jul 2003 10:12:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bha9-0004v4-00; Sun, 13 Jul 2003 10:12:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bha5-0000Ks-8G; Sun, 13 Jul 2003 10:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhZR-0000K2-Vr for simple@optimus.ietf.org; Sun, 13 Jul 2003 10:11:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23522 for ; Sun, 13 Jul 2003 10:11:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhZP-0004uN-00 for simple@ietf.org; Sun, 13 Jul 2003 10:11:19 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bhZP-0004tu-00 for simple@ietf.org; Sun, 13 Jul 2003 10:11:19 -0400 Received: from dynamicsoft.com ([63.113.46.119]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6DEAriB009210 for ; Sun, 13 Jul 2003 10:10:53 -0400 (EDT) Message-ID: <3F116866.1090908@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 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 Content-Transfer-Encoding: 7bit Subject: [Simple] comments on rpids-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 10:10:46 -0400 Content-Transfer-Encoding: 7bit From the abstract: > presentity and its contacts. This information can be translated into > call routing behavior or be delivered to watchers. You might want to add "for example" to the end. It makes it sounds like those are the only two things you can do with presence. section 6.1: > [7], using the namespace identifier 'ietf' defined by [8] and > extended by [9]: > > > urn:ietf:params:xml:ns:sip-rpids I think it makes sense to define these within the pidf namespace. Thats what I did in the phone state draft. So, it would be: urn:ietf:params:xml:ns:pidf:sip-rpids However, as Jon had mentioned in his notes to the list, I think it makes more sense to perhaps break these up into groups of attributes, with differing namespaces for each. Namespaces are a very convenient way to group attributes, and to use for specifying filter and authorization policies. In xcap, we have permissions which allow for a watcher to see specific namespaces. section 6.2: > Sleeping: This activity category can often be generated > automatically from a calendar or local time information. or from the pressure of ones face on the keyboard when you fall asleep when working :) > In-transit: The presentity is riding in a vehicle, such as a > car, but not steering. I think we might want more granularity here. I think there are useful distinctions between riding in a car and a plane, for example. So, I'd prefer to have a few vehicle-specific versions of this (obviously you need to draw the line somewhere, and I wouldnt include things like hovercraft or UFO...) Also, there is "headset" which says that the user is wearing their headset on their wireless phone. Its also a common wireless handset style that can be automatically derived. > 6.3 Card > > The element provides a URI pointing to a business card, e.g., > in LDIF or vCard format. Don't we need to mandate a particular format? > 6.5 From Element > > The element indicates how long the current status has been > valid, expressed as an absolute time. Wouldnt it make sense to apply this to a particular attribute (placetype, activity, etc.) rather than to the status element as a whole? > 6.9 Type of Place Element > > The element describes the type of place the presentity is > currently at. This offers the watcher an indication what kind of > communication is likely to be appropriate. We define an initial set > of values below: Another one that appears on wireless handsets as a "style" is "Outdoors", which says that you are out and walking around. I think thats a useful one to add. In the IANA registration for the sip-rpids namespace, the XML says: > >

Namespace for SIMPLE rich presence extension

>

application/cpim-pidf+xml

should contain the URN, not a content-type. This bug has been present in all of my XML-registering drafts for some time, and seems to have propagated. You should register the schemas as well. This allows IANA to assign a stable URI that can be used in the schemaLocation attribute of import statements in schema declarations. And one last nit: > Jonathan Rosenberg > dynamicsoft > 72 Eagle Rock Avenue > First Floor > East Hanover, NJ 07936 > USA > Email: jdrosen@dynamicsoft.com my address has changed, see sig below for updated info. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Jul 13 10:12:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23729 for ; Sun, 13 Jul 2003 10:12:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhaD-0000RU-Mf for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 10:12:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DEC9g0001700 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 10:12:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhaD-0000RL-GU for simple-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 10:12:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23622; Sun, 13 Jul 2003 10:12:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhaA-0004vA-00; Sun, 13 Jul 2003 10:12:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bha9-0004v4-00; Sun, 13 Jul 2003 10:12:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bha5-0000Ks-8G; Sun, 13 Jul 2003 10:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhZR-0000K2-Vr for simple@optimus.ietf.org; Sun, 13 Jul 2003 10:11:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23522 for ; Sun, 13 Jul 2003 10:11:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhZP-0004uN-00 for simple@ietf.org; Sun, 13 Jul 2003 10:11:19 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bhZP-0004tu-00 for simple@ietf.org; Sun, 13 Jul 2003 10:11:19 -0400 Received: from dynamicsoft.com ([63.113.46.119]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6DEAriB009210 for ; Sun, 13 Jul 2003 10:10:53 -0400 (EDT) Message-ID: <3F116866.1090908@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 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 Content-Transfer-Encoding: 7bit Subject: [Simple] comments on rpids-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 10:10:46 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit From the abstract: > presentity and its contacts. This information can be translated into > call routing behavior or be delivered to watchers. You might want to add "for example" to the end. It makes it sounds like those are the only two things you can do with presence. section 6.1: > [7], using the namespace identifier 'ietf' defined by [8] and > extended by [9]: > > > urn:ietf:params:xml:ns:sip-rpids I think it makes sense to define these within the pidf namespace. Thats what I did in the phone state draft. So, it would be: urn:ietf:params:xml:ns:pidf:sip-rpids However, as Jon had mentioned in his notes to the list, I think it makes more sense to perhaps break these up into groups of attributes, with differing namespaces for each. Namespaces are a very convenient way to group attributes, and to use for specifying filter and authorization policies. In xcap, we have permissions which allow for a watcher to see specific namespaces. section 6.2: > Sleeping: This activity category can often be generated > automatically from a calendar or local time information. or from the pressure of ones face on the keyboard when you fall asleep when working :) > In-transit: The presentity is riding in a vehicle, such as a > car, but not steering. I think we might want more granularity here. I think there are useful distinctions between riding in a car and a plane, for example. So, I'd prefer to have a few vehicle-specific versions of this (obviously you need to draw the line somewhere, and I wouldnt include things like hovercraft or UFO...) Also, there is "headset" which says that the user is wearing their headset on their wireless phone. Its also a common wireless handset style that can be automatically derived. > 6.3 Card > > The element provides a URI pointing to a business card, e.g., > in LDIF or vCard format. Don't we need to mandate a particular format? > 6.5 From Element > > The element indicates how long the current status has been > valid, expressed as an absolute time. Wouldnt it make sense to apply this to a particular attribute (placetype, activity, etc.) rather than to the status element as a whole? > 6.9 Type of Place Element > > The element describes the type of place the presentity is > currently at. This offers the watcher an indication what kind of > communication is likely to be appropriate. We define an initial set > of values below: Another one that appears on wireless handsets as a "style" is "Outdoors", which says that you are out and walking around. I think thats a useful one to add. In the IANA registration for the sip-rpids namespace, the XML says: > >

Namespace for SIMPLE rich presence extension

>

application/cpim-pidf+xml

should contain the URN, not a content-type. This bug has been present in all of my XML-registering drafts for some time, and seems to have propagated. You should register the schemas as well. This allows IANA to assign a stable URI that can be used in the schemaLocation attribute of import statements in schema declarations. And one last nit: > Jonathan Rosenberg > dynamicsoft > 72 Eagle Rock Avenue > First Floor > East Hanover, NJ 07936 > USA > Email: jdrosen@dynamicsoft.com my address has changed, see sig below for updated info. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Jul 13 10:12:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23744 for ; Sun, 13 Jul 2003 10:12:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhaE-0000Rs-Rp for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 10:12:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DECADR001718 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 10:12:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhaD-0000RK-Bb for simple-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 10:12:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23621; Sun, 13 Jul 2003 10:12:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhaA-0004v7-00; Sun, 13 Jul 2003 10:12:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bha9-0004v3-00; Sun, 13 Jul 2003 10:12:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bha5-0000L8-JB; Sun, 13 Jul 2003 10:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhZs-0000KS-Cr for simple@optimus.ietf.org; Sun, 13 Jul 2003 10:11:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23584 for ; Sun, 13 Jul 2003 10:11:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhZq-0004uj-00 for simple@ietf.org; Sun, 13 Jul 2003 10:11:46 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bhZp-0004ug-00 for simple@ietf.org; Sun, 13 Jul 2003 10:11:45 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6DEBikM029442; Sun, 13 Jul 2003 10:11:44 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6DEBhk00428; Sun, 13 Jul 2003 10:11:43 -0400 Message-ID: <3F1167A8.3020203@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C54@stntexch2.va.neustar.com> <3F039C6B.3020305@cs.columbia.edu> <3F116046.3040707@dynamicsoft.com> In-Reply-To: <3F116046.3040707@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 10:07:36 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I agree with Jon that something like is far more preferable > than . Not only does this clearly delineate it from note, it makes > it easier for an automata to do something useful with it (for example, > add it to the "Homepages of My Friends" bookmark folder in my browser). > says nothing about whats in there. > I agree that anything with the word 'info' or INFO is probably suspect. My hesitation with naming it 'homepage' is that other URI types that don't point to a web page with your vacation pictures are also appropriate there, such as an LDAP URI or whois URI. or something like that might work. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jul 13 10:14:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23971; Sun, 13 Jul 2003 10:14:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhcC-0004xU-00; Sun, 13 Jul 2003 10:14:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bhcB-0004xR-00; Sun, 13 Jul 2003 10:14:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhc1-0000TI-A6; Sun, 13 Jul 2003 10:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhbm-0000T3-Do for simple@optimus.ietf.org; Sun, 13 Jul 2003 10:13:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23916 for ; Sun, 13 Jul 2003 10:13:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhbk-0004wt-00 for simple@ietf.org; Sun, 13 Jul 2003 10:13:44 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bhbj-0004wq-00 for simple@ietf.org; Sun, 13 Jul 2003 10:13:43 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6DEDgkM029689; Sun, 13 Jul 2003 10:13:42 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6DEDek00442; Sun, 13 Jul 2003 10:13:41 -0400 Message-ID: <3F11681E.5000908@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Peterson, Jon" , simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - face-to-face References: <0449D80A0E9B614A83FA9031B07E8D3B257C1D@stntexch2.va.neustar.com> <3EFDB74A.7040707@cs.columbia.edu> <3F116087.5020701@dynamicsoft.com> In-Reply-To: <3F116087.5020701@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 10:09:34 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > Henning Schulzrinne wrote: > >> Agreed; tentatively added as 'mediated' parameter in to-be-revised >> capabilities element, as in >> >> > > > Does this mean it also becomes a callee-caps parameter as well? Not sure > what it means in that context... I don't think inheritance has to be mutual; this seems like an example of something that makes sense in a tuple, but makes little sense in a callee caps case. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Jul 13 10:14:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24057 for ; Sun, 13 Jul 2003 10:14:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhcF-0000Wj-Fm for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 10:14:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DEEF7e002019 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 10:14:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhcF-0000WU-BN for simple-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 10:14:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23971; Sun, 13 Jul 2003 10:14:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhcC-0004xU-00; Sun, 13 Jul 2003 10:14:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bhcB-0004xR-00; Sun, 13 Jul 2003 10:14:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhc1-0000TI-A6; Sun, 13 Jul 2003 10:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhbm-0000T3-Do for simple@optimus.ietf.org; Sun, 13 Jul 2003 10:13:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23916 for ; Sun, 13 Jul 2003 10:13:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhbk-0004wt-00 for simple@ietf.org; Sun, 13 Jul 2003 10:13:44 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bhbj-0004wq-00 for simple@ietf.org; Sun, 13 Jul 2003 10:13:43 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6DEDgkM029689; Sun, 13 Jul 2003 10:13:42 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6DEDek00442; Sun, 13 Jul 2003 10:13:41 -0400 Message-ID: <3F11681E.5000908@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Peterson, Jon" , simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - face-to-face References: <0449D80A0E9B614A83FA9031B07E8D3B257C1D@stntexch2.va.neustar.com> <3EFDB74A.7040707@cs.columbia.edu> <3F116087.5020701@dynamicsoft.com> In-Reply-To: <3F116087.5020701@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 10:09:34 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > Henning Schulzrinne wrote: > >> Agreed; tentatively added as 'mediated' parameter in to-be-revised >> capabilities element, as in >> >> > > > Does this mean it also becomes a callee-caps parameter as well? Not sure > what it means in that context... I don't think inheritance has to be mutual; this seems like an example of something that makes sense in a tuple, but makes little sense in a callee caps case. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jul 13 10:26:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24973; Sun, 13 Jul 2003 10:26:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhnh-00057v-00; Sun, 13 Jul 2003 10:26:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bhng-00057s-00; Sun, 13 Jul 2003 10:26:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhnc-0000r4-Jf; Sun, 13 Jul 2003 10:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhmt-0000qX-6e for simple@optimus.ietf.org; Sun, 13 Jul 2003 10:25:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24934 for ; Sun, 13 Jul 2003 10:25:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhmq-00057C-00 for simple@ietf.org; Sun, 13 Jul 2003 10:25:13 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bhmq-000579-00 for simple@ietf.org; Sun, 13 Jul 2003 10:25:12 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6DEPBkM000452; Sun, 13 Jul 2003 10:25:11 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6DEP9k00460; Sun, 13 Jul 2003 10:25:10 -0400 Message-ID: <3F116ACF.60503@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> <3F1165BD.8010406@dynamicsoft.com> In-Reply-To: <3F1165BD.8010406@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 10:21:03 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I'm not sure that works for presence, though. That is, I don't think you > could generate a SUBSCRIBE with appropriate caller preferences > parameters to just get the presence of the executive and not their > support staff. Also, the authentication issues can get rather messy. It's one thing to find the secretary, it's another to convey "this random person who you have never met isn't a stalker but somebody where your boss has asked you allow subscription (but only for as long as the boss is willing to be watched and no longer)". It's a lot easier if a single trusted entity subscribes to the party. In my model, the boss (or her composer) subscribes to the secretary, who might limit that subscription to working hours. If the secretary stays late, he might then allow the boss later access. This all works pretty naturally, without the elaborate machinery that you'd need otherwise. (You don't want the boss to be able to override all subscription decisions, for example, so you can't just give her access to the authorization database.) > > I'm in agreement with Jon that we don't want to populate Joe's presence > document with tuples that really describe Bob, just because Bob is Joe's > assistant. But, Bob does represent a point of contact for Joe, and I > think that information itself is useful presence. I think this is somewhere in-between. We have other entities, such as voicemail systems, that are valid contacts and tuples. What is the principal difference between my voicemail box and the executive version, with a live human being answering it? > > So, how about this. We could mandate that when a contact contains the > element, the tuple has no other information except for > open/closed. The element can have an attribute which says > where to go to get the acutal presence for that user: > > > > open > sip:secretary@example.com > pres="pres:secretary@example.com">assistant > > My secretary > > > This way, there is never actual presence information for the secretary - > only a reference to obtain it. But, the secretary is listed as a contact > point. This seems useful in some circumstances, but I'm afraid it doesn't solve the authorization problem I mentioned above. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Jul 13 10:26:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25021 for ; Sun, 13 Jul 2003 10:26:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhnk-0000uL-H1 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 10:26:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DEQ8Xu003489 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 10:26:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhnk-0000tZ-Ct for simple-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 10:26:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24973; Sun, 13 Jul 2003 10:26:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhnh-00057v-00; Sun, 13 Jul 2003 10:26:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bhng-00057s-00; Sun, 13 Jul 2003 10:26:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhnc-0000r4-Jf; Sun, 13 Jul 2003 10:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhmt-0000qX-6e for simple@optimus.ietf.org; Sun, 13 Jul 2003 10:25:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24934 for ; Sun, 13 Jul 2003 10:25:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhmq-00057C-00 for simple@ietf.org; Sun, 13 Jul 2003 10:25:13 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bhmq-000579-00 for simple@ietf.org; Sun, 13 Jul 2003 10:25:12 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6DEPBkM000452; Sun, 13 Jul 2003 10:25:11 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6DEP9k00460; Sun, 13 Jul 2003 10:25:10 -0400 Message-ID: <3F116ACF.60503@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> <3F1165BD.8010406@dynamicsoft.com> In-Reply-To: <3F1165BD.8010406@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 10:21:03 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I'm not sure that works for presence, though. That is, I don't think you > could generate a SUBSCRIBE with appropriate caller preferences > parameters to just get the presence of the executive and not their > support staff. Also, the authentication issues can get rather messy. It's one thing to find the secretary, it's another to convey "this random person who you have never met isn't a stalker but somebody where your boss has asked you allow subscription (but only for as long as the boss is willing to be watched and no longer)". It's a lot easier if a single trusted entity subscribes to the party. In my model, the boss (or her composer) subscribes to the secretary, who might limit that subscription to working hours. If the secretary stays late, he might then allow the boss later access. This all works pretty naturally, without the elaborate machinery that you'd need otherwise. (You don't want the boss to be able to override all subscription decisions, for example, so you can't just give her access to the authorization database.) > > I'm in agreement with Jon that we don't want to populate Joe's presence > document with tuples that really describe Bob, just because Bob is Joe's > assistant. But, Bob does represent a point of contact for Joe, and I > think that information itself is useful presence. I think this is somewhere in-between. We have other entities, such as voicemail systems, that are valid contacts and tuples. What is the principal difference between my voicemail box and the executive version, with a live human being answering it? > > So, how about this. We could mandate that when a contact contains the > element, the tuple has no other information except for > open/closed. The element can have an attribute which says > where to go to get the acutal presence for that user: > > > > open > sip:secretary@example.com > pres="pres:secretary@example.com">assistant > > My secretary > > > This way, there is never actual presence information for the secretary - > only a reference to obtain it. But, the secretary is listed as a contact > point. This seems useful in some circumstances, but I'm afraid it doesn't solve the authorization problem I mentioned above. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jul 13 11:01:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23621; Sun, 13 Jul 2003 10:12:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhaA-0004v7-00; Sun, 13 Jul 2003 10:12:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bha9-0004v3-00; Sun, 13 Jul 2003 10:12:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bha5-0000L8-JB; Sun, 13 Jul 2003 10:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bhZs-0000KS-Cr for simple@optimus.ietf.org; Sun, 13 Jul 2003 10:11:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23584 for ; Sun, 13 Jul 2003 10:11:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bhZq-0004uj-00 for simple@ietf.org; Sun, 13 Jul 2003 10:11:46 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bhZp-0004ug-00 for simple@ietf.org; Sun, 13 Jul 2003 10:11:45 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6DEBikM029442; Sun, 13 Jul 2003 10:11:44 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6DEBhk00428; Sun, 13 Jul 2003 10:11:43 -0400 Message-ID: <3F1167A8.3020203@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C54@stntexch2.va.neustar.com> <3F039C6B.3020305@cs.columbia.edu> <3F116046.3040707@dynamicsoft.com> In-Reply-To: <3F116046.3040707@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 10:07:36 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I agree with Jon that something like is far more preferable > than . Not only does this clearly delineate it from note, it makes > it easier for an automata to do something useful with it (for example, > add it to the "Homepages of My Friends" bookmark folder in my browser). > says nothing about whats in there. > I agree that anything with the word 'info' or INFO is probably suspect. My hesitation with naming it 'homepage' is that other URI types that don't point to a web page with your vacation pictures are also appropriate there, such as an LDAP URI or whois URI. or something like that might work. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jul 13 11:06:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27012; Sun, 13 Jul 2003 11:06:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19biQP-0005cS-00; Sun, 13 Jul 2003 11:06:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19biQN-0005cN-00; Sun, 13 Jul 2003 11:06:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19biQL-00020X-4x; Sun, 13 Jul 2003 11:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19biPw-00020F-DB for simple@optimus.ietf.org; Sun, 13 Jul 2003 11:05:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26983 for ; Sun, 13 Jul 2003 11:05:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19biPt-0005bw-00 for simple@ietf.org; Sun, 13 Jul 2003 11:05:33 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19biPt-0005bt-00 for simple@ietf.org; Sun, 13 Jul 2003 11:05:33 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6DF5WkM004805; Sun, 13 Jul 2003 11:05:32 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6DF5Vk00573; Sun, 13 Jul 2003 11:05:31 -0400 Message-ID: <3F117445.5080506@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] comments on rpids-01 References: <3F116866.1090908@dynamicsoft.com> In-Reply-To: <3F116866.1090908@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 11:01:25 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I think it makes sense to define these within the pidf namespace. Thats > what I did in the phone state draft. So, it would be: > > urn:ietf:params:xml:ns:pidf:sip-rpids > > However, as Jon had mentioned in his notes to the list, I think it makes > more sense to perhaps break these up into groups of attributes, with > differing namespaces for each. Namespaces are a very convenient way to > group attributes, and to use for specifying filter and authorization > policies. In xcap, we have permissions which allow for a watcher to see > specific namespaces. Agreed; but then you're contradicting yourself, i.e., they can't all be in PIDF, yet be in separate namespaces. Which do people prefer? (The schema currently keeps PIDF.) > > section 6.2: > >> Sleeping: This activity category can often be generated >> automatically from a calendar or local time information. > > > or from the pressure of ones face on the keyboard when you fall asleep > when working :) Should I mention a detector attached to the microphone input, too? :-) > >> In-transit: The presentity is riding in a vehicle, such as a >> car, but not steering. > > > I think we might want more granularity here. I think there are useful > distinctions between riding in a car and a plane, for example. So, I'd > prefer to have a few vehicle-specific versions of this (obviously you > need to draw the line somewhere, and I wouldnt include things like > hovercraft or UFO...) I've kept in-transit, as it allows generation by entities that don't know (e.g., a GPS that just monitors speed) or for presentities who prefer to keep their use of travel method private, but I'll add In-transit-ship, -motorvehicle, -aircraft, -train, -spacecraft. (By the time this draft gets to Full Standard, the latter will be a common mode of transportation. Plus, it explains those long delays...) > > > > Also, there is "headset" which says that the user is wearing their > headset on their wireless phone. Its also a common wireless handset > style that can be automatically derived. Wouldn't this be an orthogonal item, as in "in-transit-motorvehicle,headset"? > >> 6.3 Card >> >> The element provides a URI pointing to a business card, e.g., >> in LDIF or vCard format. > > > Don't we need to mandate a particular format? Why? The URI tells you how to retrieve it, the Content-Type what format it is and content-negotiation lets the watcher and owner of the information negotiate which format they both can deal with. After all, a single (HTTP) URI can point to objects of many different content types, languages, etc. > >> 6.5 From Element >> >> The element indicates how long the current status has been >> valid, expressed as an absolute time. > > > Wouldnt it make sense to apply this to a particular attribute > (placetype, activity, etc.) rather than to the status element as a whole? I agree that this is maybe better phrased as an attribute. In some cases, the whole tuple has been replaced at the time, so there seems little point in marking each element with the same time. Is there sufficient value in allowing different times for different elements? I'm probably in favor, but this seems to get close to the line of adding complexity with little practical benefit to the watcher, but significant additional display complexity. > > >> 6.9 Type of Place Element >> >> The element describes the type of place the presentity is >> currently at. This offers the watcher an indication what kind of >> communication is likely to be appropriate. We define an initial set >> of values below: > > > > Another one that appears on wireless handsets as a "style" is > "Outdoors", which says that you are out and walking around. I think > thats a useful one to add. How does this differ from a 'public' place like a mall or park? We already have public+quiet for the subset of public places where ringing cell phones or chatting are inappropriate. > > > In the IANA registration for the sip-rpids namespace, the XML says: > >> >>

Namespace for SIMPLE rich presence extension

>>

application/cpim-pidf+xml

> > >

should contain the URN, not a content-type. This bug has been > present in all of my XML-registering drafts for some time, and seems to > have propagated. > > You should register the schemas as well. This allows IANA to assign a > stable URI that can be used in the schemaLocation attribute of import > statements in schema declarations. What's the operative format for registering schemas? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Jul 13 11:06:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27057 for ; Sun, 13 Jul 2003 11:06:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19biQS-00021y-Rm for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 11:06:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DF68ph007805 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 11:06:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19biQS-00021o-Of for simple-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 11:06:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27012; Sun, 13 Jul 2003 11:06:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19biQP-0005cS-00; Sun, 13 Jul 2003 11:06:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19biQN-0005cN-00; Sun, 13 Jul 2003 11:06:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19biQL-00020X-4x; Sun, 13 Jul 2003 11:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19biPw-00020F-DB for simple@optimus.ietf.org; Sun, 13 Jul 2003 11:05:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26983 for ; Sun, 13 Jul 2003 11:05:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19biPt-0005bw-00 for simple@ietf.org; Sun, 13 Jul 2003 11:05:33 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19biPt-0005bt-00 for simple@ietf.org; Sun, 13 Jul 2003 11:05:33 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6DF5WkM004805; Sun, 13 Jul 2003 11:05:32 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6DF5Vk00573; Sun, 13 Jul 2003 11:05:31 -0400 Message-ID: <3F117445.5080506@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] comments on rpids-01 References: <3F116866.1090908@dynamicsoft.com> In-Reply-To: <3F116866.1090908@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 11:01:25 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I think it makes sense to define these within the pidf namespace. Thats > what I did in the phone state draft. So, it would be: > > urn:ietf:params:xml:ns:pidf:sip-rpids > > However, as Jon had mentioned in his notes to the list, I think it makes > more sense to perhaps break these up into groups of attributes, with > differing namespaces for each. Namespaces are a very convenient way to > group attributes, and to use for specifying filter and authorization > policies. In xcap, we have permissions which allow for a watcher to see > specific namespaces. Agreed; but then you're contradicting yourself, i.e., they can't all be in PIDF, yet be in separate namespaces. Which do people prefer? (The schema currently keeps PIDF.) > > section 6.2: > >> Sleeping: This activity category can often be generated >> automatically from a calendar or local time information. > > > or from the pressure of ones face on the keyboard when you fall asleep > when working :) Should I mention a detector attached to the microphone input, too? :-) > >> In-transit: The presentity is riding in a vehicle, such as a >> car, but not steering. > > > I think we might want more granularity here. I think there are useful > distinctions between riding in a car and a plane, for example. So, I'd > prefer to have a few vehicle-specific versions of this (obviously you > need to draw the line somewhere, and I wouldnt include things like > hovercraft or UFO...) I've kept in-transit, as it allows generation by entities that don't know (e.g., a GPS that just monitors speed) or for presentities who prefer to keep their use of travel method private, but I'll add In-transit-ship, -motorvehicle, -aircraft, -train, -spacecraft. (By the time this draft gets to Full Standard, the latter will be a common mode of transportation. Plus, it explains those long delays...) > > > > Also, there is "headset" which says that the user is wearing their > headset on their wireless phone. Its also a common wireless handset > style that can be automatically derived. Wouldn't this be an orthogonal item, as in "in-transit-motorvehicle,headset"? > >> 6.3 Card >> >> The element provides a URI pointing to a business card, e.g., >> in LDIF or vCard format. > > > Don't we need to mandate a particular format? Why? The URI tells you how to retrieve it, the Content-Type what format it is and content-negotiation lets the watcher and owner of the information negotiate which format they both can deal with. After all, a single (HTTP) URI can point to objects of many different content types, languages, etc. > >> 6.5 From Element >> >> The element indicates how long the current status has been >> valid, expressed as an absolute time. > > > Wouldnt it make sense to apply this to a particular attribute > (placetype, activity, etc.) rather than to the status element as a whole? I agree that this is maybe better phrased as an attribute. In some cases, the whole tuple has been replaced at the time, so there seems little point in marking each element with the same time. Is there sufficient value in allowing different times for different elements? I'm probably in favor, but this seems to get close to the line of adding complexity with little practical benefit to the watcher, but significant additional display complexity. > > >> 6.9 Type of Place Element >> >> The element describes the type of place the presentity is >> currently at. This offers the watcher an indication what kind of >> communication is likely to be appropriate. We define an initial set >> of values below: > > > > Another one that appears on wireless handsets as a "style" is > "Outdoors", which says that you are out and walking around. I think > thats a useful one to add. How does this differ from a 'public' place like a mall or park? We already have public+quiet for the subset of public places where ringing cell phones or chatting are inappropriate. > > > In the IANA registration for the sip-rpids namespace, the XML says: > >> >>

Namespace for SIMPLE rich presence extension

>>

application/cpim-pidf+xml

> > >

should contain the URN, not a content-type. This bug has been > present in all of my XML-registering drafts for some time, and seems to > have propagated. > > You should register the schemas as well. This allows IANA to assign a > stable URI that can be used in the schemaLocation attribute of import > statements in schema declarations. What's the operative format for registering schemas? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jul 13 11:16:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27543; Sun, 13 Jul 2003 11:16:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bia3-0005kd-00; Sun, 13 Jul 2003 11:16:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bia3-0005ka-00; Sun, 13 Jul 2003 11:16:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bia1-0002Qg-GQ; Sun, 13 Jul 2003 11:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19biZ6-0002Pd-O1 for simple@optimus.ietf.org; Sun, 13 Jul 2003 11:15:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27508 for ; Sun, 13 Jul 2003 11:15:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19biZ5-0005jq-00 for simple@ietf.org; Sun, 13 Jul 2003 11:15:03 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19biZ5-0005jn-00 for simple@ietf.org; Sun, 13 Jul 2003 11:15:03 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6DFF2kM005412; Sun, 13 Jul 2003 11:15:02 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6DFF0k00604; Sun, 13 Jul 2003 11:15:01 -0400 Message-ID: <3F11767E.1050902@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: aki.niemi@nokia.com, jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] comments on rpids-01 (general, vCard, predictive) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8E43@esebe013.ntc.nokia.com> <3F11679C.8010004@dynamicsoft.com> In-Reply-To: <3F11679C.8010004@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 11:10:54 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I agree that icon is useful, but I think we need to say a lot more about > it. In particular, the assumption is, I think, that these icons will be > used as part of a user interface. In that case, its not just merely > rendered in a browser, but rather would assumed to meet some constraints > in order to be used as part of an application UI. Certainly size is the > most important one. At the very least, a certain aspect ration may need > to exist, and perhaps a specific size, if the UI can't resize images. Almost all web-browser based systems can resize images, from what I can tell. (I know there are certain Java-based desk phones which can/could not.) I will add a note as to its use, but I'm not sure that we should fix a pixel dimension or aspect ratio. In particular, with content-negotiation in HTTP, it might become feasible to have several different versions, from the high-res photo showing the cell phone to the 20x20 GIF. > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Jul 13 11:16:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27604 for ; Sun, 13 Jul 2003 11:16:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bia5-0002SE-1k for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 11:16:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DFG5T9009430 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 11:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bia4-0002S1-Ul for simple-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 11:16:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27543; Sun, 13 Jul 2003 11:16:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bia3-0005kd-00; Sun, 13 Jul 2003 11:16:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bia3-0005ka-00; Sun, 13 Jul 2003 11:16:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bia1-0002Qg-GQ; Sun, 13 Jul 2003 11:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19biZ6-0002Pd-O1 for simple@optimus.ietf.org; Sun, 13 Jul 2003 11:15:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27508 for ; Sun, 13 Jul 2003 11:15:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19biZ5-0005jq-00 for simple@ietf.org; Sun, 13 Jul 2003 11:15:03 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19biZ5-0005jn-00 for simple@ietf.org; Sun, 13 Jul 2003 11:15:03 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6DFF2kM005412; Sun, 13 Jul 2003 11:15:02 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6DFF0k00604; Sun, 13 Jul 2003 11:15:01 -0400 Message-ID: <3F11767E.1050902@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: aki.niemi@nokia.com, jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] comments on rpids-01 (general, vCard, predictive) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8E43@esebe013.ntc.nokia.com> <3F11679C.8010004@dynamicsoft.com> In-Reply-To: <3F11679C.8010004@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 11:10:54 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I agree that icon is useful, but I think we need to say a lot more about > it. In particular, the assumption is, I think, that these icons will be > used as part of a user interface. In that case, its not just merely > rendered in a browser, but rather would assumed to meet some constraints > in order to be used as part of an application UI. Certainly size is the > most important one. At the very least, a certain aspect ration may need > to exist, and perhaps a specific size, if the UI can't resize images. Almost all web-browser based systems can resize images, from what I can tell. (I know there are certain Java-based desk phones which can/could not.) I will add a note as to its use, but I'm not sure that we should fix a pixel dimension or aspect ratio. In particular, with content-negotiation in HTTP, it might become feasible to have several different versions, from the high-res photo showing the cell phone to the 20x20 GIF. > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Jul 13 11:24:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28041; Sun, 13 Jul 2003 11:24:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bihn-0005rx-00; Sun, 13 Jul 2003 11:24:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bihn-0005ru-00; Sun, 13 Jul 2003 11:24:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bihl-0002gM-IN; Sun, 13 Jul 2003 11:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bihb-0002fz-7E for simple@optimus.ietf.org; Sun, 13 Jul 2003 11:23:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28005 for ; Sun, 13 Jul 2003 11:23:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19biha-0005rQ-00 for simple@ietf.org; Sun, 13 Jul 2003 11:23:50 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bihZ-0005rN-00 for simple@ietf.org; Sun, 13 Jul 2003 11:23:49 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6DFNlkM006016; Sun, 13 Jul 2003 11:23:47 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6DFNkk00630; Sun, 13 Jul 2003 11:23:46 -0400 Message-ID: <3F11788B.2020308@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] asking for a specific view References: <3F114AC6.1070002@dynamicsoft.com> In-Reply-To: <3F114AC6.1070002@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 11:19:39 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > It is possible that, by default, the PA would not provide information to > the watcher in a device-centric view. Rather, its policy is to send a > single tuple with summary information. If this happens, the watcher > doesnt get the information they need, since its been aggregated away. To > remedy this, I think we need to enhance the filter work to allow a > watcher to ask for a specific view of the presence data. We have some > work to do to define a view, but we have a couple of good candidates to > work from. Would this be as simple as being able to request certain columns (in my database view of the world)? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Jul 13 11:24:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28081 for ; Sun, 13 Jul 2003 11:24:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bihp-0002i2-CH for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 11:24:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DFO5Pl010408 for simple-archive@odin.ietf.org; Sun, 13 Jul 2003 11:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bihp-0002hn-7i for simple-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 11:24:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28041; Sun, 13 Jul 2003 11:24:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bihn-0005rx-00; Sun, 13 Jul 2003 11:24:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bihn-0005ru-00; Sun, 13 Jul 2003 11:24:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bihl-0002gM-IN; Sun, 13 Jul 2003 11:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bihb-0002fz-7E for simple@optimus.ietf.org; Sun, 13 Jul 2003 11:23:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28005 for ; Sun, 13 Jul 2003 11:23:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19biha-0005rQ-00 for simple@ietf.org; Sun, 13 Jul 2003 11:23:50 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bihZ-0005rN-00 for simple@ietf.org; Sun, 13 Jul 2003 11:23:49 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6DFNlkM006016; Sun, 13 Jul 2003 11:23:47 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6DFNkk00630; Sun, 13 Jul 2003 11:23:46 -0400 Message-ID: <3F11788B.2020308@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] asking for a specific view References: <3F114AC6.1070002@dynamicsoft.com> In-Reply-To: <3F114AC6.1070002@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 11:19:39 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > It is possible that, by default, the PA would not provide information to > the watcher in a device-centric view. Rather, its policy is to send a > single tuple with summary information. If this happens, the watcher > doesnt get the information they need, since its been aggregated away. To > remedy this, I think we need to enhance the filter work to allow a > watcher to ask for a specific view of the presence data. We have some > work to do to define a view, but we have a couple of good candidates to > work from. Would this be as simple as being able to request certain columns (in my database view of the world)? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 04:44:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02221; Mon, 14 Jul 2003 04:44:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bywK-0002wW-00; Mon, 14 Jul 2003 04:44:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bywJ-0002wT-00; Mon, 14 Jul 2003 04:44:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bywD-0003l0-4N; Mon, 14 Jul 2003 04:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byw7-0003ki-A9 for simple@optimus.ietf.org; Mon, 14 Jul 2003 04:43:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02211 for ; Mon, 14 Jul 2003 04:43:51 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19byw3-0002w7-00 for simple@ietf.org; Mon, 14 Jul 2003 04:43:51 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19byw2-0002w4-00 for simple@ietf.org; Mon, 14 Jul 2003 04:43:51 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6E8hok03795 for ; Mon, 14 Jul 2003 11:43:50 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Jul 2003 11:43:48 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 11:43:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] asking for a specific view Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796EFC@esebe019.ntc.nokia.com> Thread-Topic: [Simple] asking for a specific view Thread-Index: AcNJNwdXxh1Es5ywQ4CR+LomXqOKpwArMS9Q To: , X-OriginalArrivalTime: 14 Jul 2003 08:43:48.0482 (UTC) FILETIME=[0B248620:01C349E4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 11:43:47 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sunday, July 13, 2003 3:04 PM > To: Simple WG > Subject: [Simple] asking for a specific view >=20 >=20 > Folks, >=20 > One of the conclusions of the tuple design team was that we want to=20 > allow a PA the flexibility to have tuples represent anything they=20 > want. This means that a PA can compose, aggregate, and otherwise=20 > discard information as it sees fit. >=20 > However, in some cases, a watcher is interested in a specific type of=20 > information, and furthermore, a specific type of information within=20 > the context of a specific view. As an example, a watcher application=20 > that wants to send an SMS to a phone when it finds its not in a call,=20 > will want to see a device-centric view of a user, so that it=20 > can check=20 > the call state of the device. >=20 > It is possible that, by default, the PA would not provide information=20 > to the watcher in a device-centric view. Rather, its policy=20 > is to send=20 > a single tuple with summary information. If this happens, the watcher=20 > doesnt get the information they need, since its been aggregated away.=20 > To remedy this, I think we need to enhance the filter work to allow a=20 > watcher to ask for a specific view of the presence data. We have some=20 > work to do to define a view, but we have a couple of good candidates=20 > to work from. Is this possible with a generic filtering solution as we have today? In = the last IETF meeting, we agreed that filtering will be a generic = solution. Regards, Hisham >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=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 exim@www1.ietf.org Mon Jul 14 04:44:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02273 for ; Mon, 14 Jul 2003 04:44:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bywQ-0003mc-7z for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 04:44:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E8iERt014541 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 04:44:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bywN-0003mS-Oh for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 04:44:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02221; Mon, 14 Jul 2003 04:44:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bywK-0002wW-00; Mon, 14 Jul 2003 04:44:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bywJ-0002wT-00; Mon, 14 Jul 2003 04:44:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bywD-0003l0-4N; Mon, 14 Jul 2003 04:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byw7-0003ki-A9 for simple@optimus.ietf.org; Mon, 14 Jul 2003 04:43:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02211 for ; Mon, 14 Jul 2003 04:43:51 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19byw3-0002w7-00 for simple@ietf.org; Mon, 14 Jul 2003 04:43:51 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19byw2-0002w4-00 for simple@ietf.org; Mon, 14 Jul 2003 04:43:51 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6E8hok03795 for ; Mon, 14 Jul 2003 11:43:50 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Jul 2003 11:43:48 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 11:43:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] asking for a specific view Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796EFC@esebe019.ntc.nokia.com> Thread-Topic: [Simple] asking for a specific view Thread-Index: AcNJNwdXxh1Es5ywQ4CR+LomXqOKpwArMS9Q To: , X-OriginalArrivalTime: 14 Jul 2003 08:43:48.0482 (UTC) FILETIME=[0B248620:01C349E4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 11:43:47 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sunday, July 13, 2003 3:04 PM > To: Simple WG > Subject: [Simple] asking for a specific view >=20 >=20 > Folks, >=20 > One of the conclusions of the tuple design team was that we want to=20 > allow a PA the flexibility to have tuples represent anything they=20 > want. This means that a PA can compose, aggregate, and otherwise=20 > discard information as it sees fit. >=20 > However, in some cases, a watcher is interested in a specific type of=20 > information, and furthermore, a specific type of information within=20 > the context of a specific view. As an example, a watcher application=20 > that wants to send an SMS to a phone when it finds its not in a call,=20 > will want to see a device-centric view of a user, so that it=20 > can check=20 > the call state of the device. >=20 > It is possible that, by default, the PA would not provide information=20 > to the watcher in a device-centric view. Rather, its policy=20 > is to send=20 > a single tuple with summary information. If this happens, the watcher=20 > doesnt get the information they need, since its been aggregated away.=20 > To remedy this, I think we need to enhance the filter work to allow a=20 > watcher to ask for a specific view of the presence data. We have some=20 > work to do to define a view, but we have a couple of good candidates=20 > to work from. Is this possible with a generic filtering solution as we have today? In = the last IETF meeting, we agreed that filtering will be a generic = solution. Regards, Hisham >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=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-admin@ietf.org Mon Jul 14 04:47:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02363; Mon, 14 Jul 2003 04:47:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19byzB-0002yY-00; Mon, 14 Jul 2003 04:47:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19byzA-0002yV-00; Mon, 14 Jul 2003 04:47:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byz6-0003u7-MY; Mon, 14 Jul 2003 04:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byyb-0003rw-5b for simple@optimus.ietf.org; Mon, 14 Jul 2003 04:46:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02327 for ; Mon, 14 Jul 2003 04:46:26 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19byyY-0002y3-00 for simple@ietf.org; Mon, 14 Jul 2003 04:46:26 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19byyT-0002xd-00 for simple@ietf.org; Mon, 14 Jul 2003 04:46:25 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6E8kLk06005 for ; Mon, 14 Jul 2003 11:46:21 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Jul 2003 11:46:21 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 11:46:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] comments on rpids-01 - Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> Thread-Topic: [Simple] comments on rpids-01 - Thread-Index: AcNJSrhEwCsHunbmQ4u4FX1MWHvQOAAmXq4A To: , Cc: , X-OriginalArrivalTime: 14 Jul 2003 08:46:21.0087 (UTC) FILETIME=[661A32F0:01C349E4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 11:46:20 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, July 13, 2003 5:21 PM > To: Jonathan Rosenberg > Cc: Peterson, Jon; Simpletons (E-mail) > Subject: Re: [Simple] comments on rpids-01 - >=20 >=20 > Jonathan Rosenberg wrote: >=20 >=20 > > I'm not sure that works for presence, though. That is, I=20 > don't think you=20 > > could generate a SUBSCRIBE with appropriate caller preferences=20 > > parameters to just get the presence of the executive and not their=20 > > support staff. >=20 > Also, the authentication issues can get rather messy. It's=20 > one thing to=20 > find the secretary, it's another to convey "this random=20 > person who you=20 > have never met isn't a stalker but somebody where your boss has asked=20 > you allow subscription (but only for as long as the boss is=20 > willing to=20 > be watched and no longer)". It's a lot easier if a single=20 > trusted entity=20 > subscribes to the party. Can't this be done by sharing an authorisation list between the = secretary and her boss? /Hisham >=20 > In my model, the boss (or her composer) subscribes to the=20 > secretary, who=20 > might limit that subscription to working hours. If the=20 > secretary stays=20 > late, he might then allow the boss later access. This all=20 > works pretty=20 > naturally, without the elaborate machinery that you'd need otherwise.=20 > (You don't want the boss to be able to override all subscription=20 > decisions, for example, so you can't just give her access to the=20 > authorization database.) >=20 >=20 > >=20 > > I'm in agreement with Jon that we don't want to populate=20 > Joe's presence=20 > > document with tuples that really describe Bob, just because=20 > Bob is Joe's=20 > > assistant. But, Bob does represent a point of contact for=20 > Joe, and I=20 > > think that information itself is useful presence. >=20 > I think this is somewhere in-between. We have other entities, such as=20 > voicemail systems, that are valid contacts and tuples. What is the=20 > principal difference between my voicemail box and the=20 > executive version,=20 > with a live human being answering it? >=20 >=20 > >=20 > > So, how about this. We could mandate that when a contact=20 > contains the=20 > > element, the tuple has no other information=20 > except for=20 > > open/closed. The element can have an=20 > attribute which says=20 > > where to go to get the acutal presence for that user: > >=20 > > > > > > open > > sip:secretary@example.com > > > =20 > pres=3D"pres:secretary@example.com">assistant > > > > My secretary > > > >=20 > > This way, there is never actual presence information for=20 > the secretary -=20 > > only a reference to obtain it. But, the secretary is listed=20 > as a contact=20 > > point. >=20 > This seems useful in some circumstances, but I'm afraid it=20 > doesn't solve=20 > the authorization problem I mentioned above. >=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 exim@www1.ietf.org Mon Jul 14 04:47:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02383 for ; Mon, 14 Jul 2003 04:47:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byzE-0003xs-OK for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 04:47:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E8l8HA015234 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 04:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byzE-0003xd-KB for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 04:47:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02363; Mon, 14 Jul 2003 04:47:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19byzB-0002yY-00; Mon, 14 Jul 2003 04:47:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19byzA-0002yV-00; Mon, 14 Jul 2003 04:47:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byz6-0003u7-MY; Mon, 14 Jul 2003 04:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byyb-0003rw-5b for simple@optimus.ietf.org; Mon, 14 Jul 2003 04:46:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02327 for ; Mon, 14 Jul 2003 04:46:26 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19byyY-0002y3-00 for simple@ietf.org; Mon, 14 Jul 2003 04:46:26 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19byyT-0002xd-00 for simple@ietf.org; Mon, 14 Jul 2003 04:46:25 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6E8kLk06005 for ; Mon, 14 Jul 2003 11:46:21 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Jul 2003 11:46:21 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 11:46:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] comments on rpids-01 - Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> Thread-Topic: [Simple] comments on rpids-01 - Thread-Index: AcNJSrhEwCsHunbmQ4u4FX1MWHvQOAAmXq4A To: , Cc: , X-OriginalArrivalTime: 14 Jul 2003 08:46:21.0087 (UTC) FILETIME=[661A32F0:01C349E4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 11:46:20 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, July 13, 2003 5:21 PM > To: Jonathan Rosenberg > Cc: Peterson, Jon; Simpletons (E-mail) > Subject: Re: [Simple] comments on rpids-01 - >=20 >=20 > Jonathan Rosenberg wrote: >=20 >=20 > > I'm not sure that works for presence, though. That is, I=20 > don't think you=20 > > could generate a SUBSCRIBE with appropriate caller preferences=20 > > parameters to just get the presence of the executive and not their=20 > > support staff. >=20 > Also, the authentication issues can get rather messy. It's=20 > one thing to=20 > find the secretary, it's another to convey "this random=20 > person who you=20 > have never met isn't a stalker but somebody where your boss has asked=20 > you allow subscription (but only for as long as the boss is=20 > willing to=20 > be watched and no longer)". It's a lot easier if a single=20 > trusted entity=20 > subscribes to the party. Can't this be done by sharing an authorisation list between the = secretary and her boss? /Hisham >=20 > In my model, the boss (or her composer) subscribes to the=20 > secretary, who=20 > might limit that subscription to working hours. If the=20 > secretary stays=20 > late, he might then allow the boss later access. This all=20 > works pretty=20 > naturally, without the elaborate machinery that you'd need otherwise.=20 > (You don't want the boss to be able to override all subscription=20 > decisions, for example, so you can't just give her access to the=20 > authorization database.) >=20 >=20 > >=20 > > I'm in agreement with Jon that we don't want to populate=20 > Joe's presence=20 > > document with tuples that really describe Bob, just because=20 > Bob is Joe's=20 > > assistant. But, Bob does represent a point of contact for=20 > Joe, and I=20 > > think that information itself is useful presence. >=20 > I think this is somewhere in-between. We have other entities, such as=20 > voicemail systems, that are valid contacts and tuples. What is the=20 > principal difference between my voicemail box and the=20 > executive version,=20 > with a live human being answering it? >=20 >=20 > >=20 > > So, how about this. We could mandate that when a contact=20 > contains the=20 > > element, the tuple has no other information=20 > except for=20 > > open/closed. The element can have an=20 > attribute which says=20 > > where to go to get the acutal presence for that user: > >=20 > > > > > > open > > sip:secretary@example.com > > > =20 > pres=3D"pres:secretary@example.com">assistant > > > > My secretary > > > >=20 > > This way, there is never actual presence information for=20 > the secretary -=20 > > only a reference to obtain it. But, the secretary is listed=20 > as a contact=20 > > point. >=20 > This seems useful in some circumstances, but I'm afraid it=20 > doesn't solve=20 > the authorization problem I mentioned above. >=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-admin@ietf.org Mon Jul 14 04:53:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02460; Mon, 14 Jul 2003 04:53:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bz4v-00030E-00; Mon, 14 Jul 2003 04:53:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bz4v-00030B-00; Mon, 14 Jul 2003 04:53:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bz4v-00045z-Hi; Mon, 14 Jul 2003 04:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bz4Q-00045c-6H for simple@optimus.ietf.org; Mon, 14 Jul 2003 04:52:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02454 for ; Mon, 14 Jul 2003 04:52:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bz4N-0002zz-00 for simple@ietf.org; Mon, 14 Jul 2003 04:52:27 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bz4M-0002zw-00 for simple@ietf.org; Mon, 14 Jul 2003 04:52:26 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6E8qPkM020134; Mon, 14 Jul 2003 04:52:25 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6E8qMk03520; Mon, 14 Jul 2003 04:52:23 -0400 Message-ID: <3F126E4F.3040808@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] asking for a specific view References: <2038BCC78B1AD641891A0D1AE133DBB701796EFC@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796EFC@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 04:48:15 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > Is this possible with a generic filtering solution as we have today? In the last IETF meeting, we agreed that filtering will be a generic solution. That's why I suggested that expressing this as a list of fields ("columns") to be included and non-merged, presumably as XPath statements. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 04:53:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02478 for ; Mon, 14 Jul 2003 04:53:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bz4z-00047b-Cu for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 04:53:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E8r5nC015837 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 04:53:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bz4z-00047M-7b for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 04:53:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02460; Mon, 14 Jul 2003 04:53:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bz4v-00030E-00; Mon, 14 Jul 2003 04:53:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bz4v-00030B-00; Mon, 14 Jul 2003 04:53:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bz4v-00045z-Hi; Mon, 14 Jul 2003 04:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bz4Q-00045c-6H for simple@optimus.ietf.org; Mon, 14 Jul 2003 04:52:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02454 for ; Mon, 14 Jul 2003 04:52:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bz4N-0002zz-00 for simple@ietf.org; Mon, 14 Jul 2003 04:52:27 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bz4M-0002zw-00 for simple@ietf.org; Mon, 14 Jul 2003 04:52:26 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6E8qPkM020134; Mon, 14 Jul 2003 04:52:25 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6E8qMk03520; Mon, 14 Jul 2003 04:52:23 -0400 Message-ID: <3F126E4F.3040808@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] asking for a specific view References: <2038BCC78B1AD641891A0D1AE133DBB701796EFC@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796EFC@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 04:48:15 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > Is this possible with a generic filtering solution as we have today? In the last IETF meeting, we agreed that filtering will be a generic solution. That's why I suggested that expressing this as a list of fields ("columns") to be included and non-merged, presumably as XPath statements. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 05:04:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02784; Mon, 14 Jul 2003 05:04:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bzFf-000351-00; Mon, 14 Jul 2003 05:04:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bzFe-00034y-00; Mon, 14 Jul 2003 05:04:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzFY-0004Su-Q7; Mon, 14 Jul 2003 05:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzEp-0004Pu-CZ for simple@optimus.ietf.org; Mon, 14 Jul 2003 05:03:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02748 for ; Mon, 14 Jul 2003 05:03:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bzEm-00034f-00 for simple@ietf.org; Mon, 14 Jul 2003 05:03:12 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bzEl-00034c-00 for simple@ietf.org; Mon, 14 Jul 2003 05:03:11 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6E93BkM020992; Mon, 14 Jul 2003 05:03:11 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6E93Ak03831; Mon, 14 Jul 2003 05:03:10 -0400 Message-ID: <3F1270D7.70302@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 04:59:03 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Can't this be done by sharing an authorisation list between the secretary and her boss? Not generally. I'm not sure how sharing would work in practice (given lack of deployment of such mechanisms), but you would either have authorization lists with multiple-user access rights (not likely to be common, judging how typical 'accounts' work in other systems) or share a key. Even assuming this could work, this doesn't have the same functionality. For example, the secretary may only want to be visible to boss-permitted contacts from 9 to 5, but can't easily tell which contacts were authorized by the boss (so that the secretary can drop them at 5 and re-admit them at 9 the next day). If we can make these requirements for the authorization work, I'd be less concerned and Jonathan's suggestion would work well. The requirements are basically (1) allow multiple parties to edit the authorization list (2) the origin of each entry needs to be clear (who added it to the list) (3) updates and relationship for the same watcher by different updaters need to be clear (example: Secretary has Alice in her "good" list, but boss adds Alice as well; Alice shouldn't disappear from that list after 5 pm; whwat happens if there is a conflict?). Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 05:04:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02834 for ; Mon, 14 Jul 2003 05:04:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzFj-0004Ue-1a for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 05:04:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E94BDZ017268 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 05:04:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzFi-0004UR-V1 for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 05:04:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02784; Mon, 14 Jul 2003 05:04:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bzFf-000351-00; Mon, 14 Jul 2003 05:04:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bzFe-00034y-00; Mon, 14 Jul 2003 05:04:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzFY-0004Su-Q7; Mon, 14 Jul 2003 05:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzEp-0004Pu-CZ for simple@optimus.ietf.org; Mon, 14 Jul 2003 05:03:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02748 for ; Mon, 14 Jul 2003 05:03:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bzEm-00034f-00 for simple@ietf.org; Mon, 14 Jul 2003 05:03:12 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bzEl-00034c-00 for simple@ietf.org; Mon, 14 Jul 2003 05:03:11 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6E93BkM020992; Mon, 14 Jul 2003 05:03:11 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6E93Ak03831; Mon, 14 Jul 2003 05:03:10 -0400 Message-ID: <3F1270D7.70302@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 04:59:03 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Can't this be done by sharing an authorisation list between the secretary and her boss? Not generally. I'm not sure how sharing would work in practice (given lack of deployment of such mechanisms), but you would either have authorization lists with multiple-user access rights (not likely to be common, judging how typical 'accounts' work in other systems) or share a key. Even assuming this could work, this doesn't have the same functionality. For example, the secretary may only want to be visible to boss-permitted contacts from 9 to 5, but can't easily tell which contacts were authorized by the boss (so that the secretary can drop them at 5 and re-admit them at 9 the next day). If we can make these requirements for the authorization work, I'd be less concerned and Jonathan's suggestion would work well. The requirements are basically (1) allow multiple parties to edit the authorization list (2) the origin of each entry needs to be clear (who added it to the list) (3) updates and relationship for the same watcher by different updaters need to be clear (example: Secretary has Alice in her "good" list, but boss adds Alice as well; Alice shouldn't disappear from that list after 5 pm; whwat happens if there is a conflict?). Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 08:25:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14848; Mon, 14 Jul 2003 08:25:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c2OG-0006KY-00; Mon, 14 Jul 2003 08:25:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c2OF-0006KT-00; Mon, 14 Jul 2003 08:25:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2O4-0001q7-Ug; Mon, 14 Jul 2003 08:25:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2Nx-0001pf-Qm for simple@optimus.ietf.org; Mon, 14 Jul 2003 08:24:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14821 for ; Mon, 14 Jul 2003 08:24:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c2Nw-0006KE-00 for simple@ietf.org; Mon, 14 Jul 2003 08:24:52 -0400 Received: from [80.74.106.10] (helo=nt-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 19c2Nv-0006KB-00 for simple@ietf.org; Mon, 14 Jul 2003 08:24:52 -0400 Received: from nt-mail.radvision.com [172.20.2.100] by nt-mail.radvision.com with XWall v3.26 ; Mon, 14 Jul 2003 15:23:24 +0300 Received: by nt-mail.radvision.com with Internet Mail Service (5.5.2653.19) id <3SH3HM0G>; Mon, 14 Jul 2003 15:23:24 +0300 Message-ID: From: Orly Rosenberg To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Simple] A few questions about Winfo Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 15:23:23 +0300 Hi. I have a few questions about the winfo-package draft: 1) The draft defines a default policy for sending watcherinfo notifications in case the body of the Subscribe request does not define a filter for notifications. The default behavior, as I understand it, is: a. Send a full winfo document when sending a winfo notification as a result of an incoming winfo Subscribe request (initial winfo Subscribe request or refresh requests). b. Send a partial winfo document when a watcher changes its state, about this watcher only. It is also recommended by the draft, that "the watcherinfo notifications sent to B only contain the state of B's own subscriptions". My question is - should the default behavior be sending a full winfo document as a result of an incoming Subscribe, only when B subscribes to its own watcher information? 2) According to the 3265 RFC, when a pending subscription is expired, a Notify(terminated) should be sent by the Notifier to the Subscriber. According to the winfo-package, when a Pending subscription is expired, it should change its state to Waiting. When this happens, should the Notifier still send a Notify(terminated) message to the Subscriber? If not, when should this message be sent? If yes, then how is it possible to change the state back to Pending when receiving a refresh request, after a Notify(terminated) message was already sent? 3) When handling a fetch Subscribe request, should the Notifier send a Notify(terminated) after sending the Notify(active) message with the winfo document? What happens if there is no policy defined for the fetch request and the state changes to Waiting? Should the Notifier send any Notify messages? Thanks, Orly Rosenberg. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 08:25:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14887 for ; Mon, 14 Jul 2003 08:25:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2OI-0001rj-5G for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 08:25:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ECPEZm007171 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 08:25:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2OI-0001ra-1L for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 08:25:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14848; Mon, 14 Jul 2003 08:25:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c2OG-0006KY-00; Mon, 14 Jul 2003 08:25:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c2OF-0006KT-00; Mon, 14 Jul 2003 08:25:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2O4-0001q7-Ug; Mon, 14 Jul 2003 08:25:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2Nx-0001pf-Qm for simple@optimus.ietf.org; Mon, 14 Jul 2003 08:24:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14821 for ; Mon, 14 Jul 2003 08:24:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c2Nw-0006KE-00 for simple@ietf.org; Mon, 14 Jul 2003 08:24:52 -0400 Received: from [80.74.106.10] (helo=nt-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 19c2Nv-0006KB-00 for simple@ietf.org; Mon, 14 Jul 2003 08:24:52 -0400 Received: from nt-mail.radvision.com [172.20.2.100] by nt-mail.radvision.com with XWall v3.26 ; Mon, 14 Jul 2003 15:23:24 +0300 Received: by nt-mail.radvision.com with Internet Mail Service (5.5.2653.19) id <3SH3HM0G>; Mon, 14 Jul 2003 15:23:24 +0300 Message-ID: From: Orly Rosenberg To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Simple] A few questions about Winfo Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 15:23:23 +0300 Hi. I have a few questions about the winfo-package draft: 1) The draft defines a default policy for sending watcherinfo notifications in case the body of the Subscribe request does not define a filter for notifications. The default behavior, as I understand it, is: a. Send a full winfo document when sending a winfo notification as a result of an incoming winfo Subscribe request (initial winfo Subscribe request or refresh requests). b. Send a partial winfo document when a watcher changes its state, about this watcher only. It is also recommended by the draft, that "the watcherinfo notifications sent to B only contain the state of B's own subscriptions". My question is - should the default behavior be sending a full winfo document as a result of an incoming Subscribe, only when B subscribes to its own watcher information? 2) According to the 3265 RFC, when a pending subscription is expired, a Notify(terminated) should be sent by the Notifier to the Subscriber. According to the winfo-package, when a Pending subscription is expired, it should change its state to Waiting. When this happens, should the Notifier still send a Notify(terminated) message to the Subscriber? If not, when should this message be sent? If yes, then how is it possible to change the state back to Pending when receiving a refresh request, after a Notify(terminated) message was already sent? 3) When handling a fetch Subscribe request, should the Notifier send a Notify(terminated) after sending the Notify(active) message with the winfo document? What happens if there is no policy defined for the fetch request and the state changes to Waiting? Should the Notifier send any Notify messages? Thanks, Orly Rosenberg. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 09:48:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20879; Mon, 14 Jul 2003 09:48:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3gW-0007mY-00; Mon, 14 Jul 2003 09:48:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c3gU-0007mU-00; Mon, 14 Jul 2003 09:48:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gP-0005f1-9I; Mon, 14 Jul 2003 09:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gJ-0005e4-LO for simple@optimus.ietf.org; Mon, 14 Jul 2003 09:47:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20840 for ; Mon, 14 Jul 2003 09:47:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3gH-0007li-00 for simple@ietf.org; Mon, 14 Jul 2003 09:47:53 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19c3gF-0007kb-00 for simple@ietf.org; Mon, 14 Jul 2003 09:47:52 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EDlKE5006380; Mon, 14 Jul 2003 09:47:20 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jul 2003 08:47:19 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Robert Sparks Cc: simple@ietf.org Subject: RE: [Simple] Tuple design team discussion summary MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 08:47:10 -0500 Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > So, I think there is value in having an RPIDS attribute which conveys > some kind of information about what the tuple represents. We > can start > with a basic set of types: > > "cell phone" > "PDA" > "wireline phone" > "IM service" It's not clear that tuples can always be classified as something this concrete, though. What if I want to publish a single tuple that represents an amalgamation of my presence status, for example? Two tuples, with one representing my "work" devices, and one representing my "personal" devices? I think one of the important drivers behind not mandating a particular binding of a tuple to something like a device is that doing so provides infinite flexibility in publishing information. It seems that having a canonical (even if expandable) set of blessed "types" of tuples will restrict this flexibility unnecessarily. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 09:48:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20880; Mon, 14 Jul 2003 09:48:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3gW-0007mf-00; Mon, 14 Jul 2003 09:48:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c3gV-0007mc-00; Mon, 14 Jul 2003 09:48:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gQ-0005fa-Az; Mon, 14 Jul 2003 09:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gL-0005eJ-3X for simple@optimus.ietf.org; Mon, 14 Jul 2003 09:47:57 -0400 Received: from mail4.dynamicsoft.com (mail4.dynamicsoft.com [63.110.3.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20846 for ; Mon, 14 Jul 2003 09:47:53 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EDlKE5006364 for ; Mon, 14 Jul 2003 09:47:20 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jul 2003 08:47:19 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE9@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Simple WG Subject: RE: [Simple] asking for a specific view MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 08:47:10 -0500 Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > To remedy this, I think we need to enhance the filter work to allow a > watcher to ask for a specific view of the presence data. We have some > work to do to define a view, but we have a couple of good candidates > to work from. I'm pretty certain that you're going to run into a lot of situations in which presence cannot be broken down along specific lines (like device or service views). For example, presence information may arrive at a PA already partially (or even fully) composed of information about multiple devices. You'll also often run into situations in which composition is performed as a means of intentional obscurity. I'm not saying that your suggestion is bad, but I suspect that we'll discover that the cases in which requests for certain types of views make sense will be the exception rather than the norm. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 09:48:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21003 for ; Mon, 14 Jul 2003 09:48:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gZ-0005m5-Da for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 09:48:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EDmBfI022190 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 09:48:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gZ-0005lb-8i for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 09:48:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20879; Mon, 14 Jul 2003 09:48:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3gW-0007mY-00; Mon, 14 Jul 2003 09:48:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c3gU-0007mU-00; Mon, 14 Jul 2003 09:48:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gP-0005f1-9I; Mon, 14 Jul 2003 09:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gJ-0005e4-LO for simple@optimus.ietf.org; Mon, 14 Jul 2003 09:47:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20840 for ; Mon, 14 Jul 2003 09:47:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3gH-0007li-00 for simple@ietf.org; Mon, 14 Jul 2003 09:47:53 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19c3gF-0007kb-00 for simple@ietf.org; Mon, 14 Jul 2003 09:47:52 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EDlKE5006380; Mon, 14 Jul 2003 09:47:20 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jul 2003 08:47:19 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Robert Sparks Cc: simple@ietf.org Subject: RE: [Simple] Tuple design team discussion summary MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 08:47:10 -0500 Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > So, I think there is value in having an RPIDS attribute which conveys > some kind of information about what the tuple represents. We > can start > with a basic set of types: > > "cell phone" > "PDA" > "wireline phone" > "IM service" It's not clear that tuples can always be classified as something this concrete, though. What if I want to publish a single tuple that represents an amalgamation of my presence status, for example? Two tuples, with one representing my "work" devices, and one representing my "personal" devices? I think one of the important drivers behind not mandating a particular binding of a tuple to something like a device is that doing so provides infinite flexibility in publishing information. It seems that having a canonical (even if expandable) set of blessed "types" of tuples will restrict this flexibility unnecessarily. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 09:48:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21008 for ; Mon, 14 Jul 2003 09:48:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gZ-0005mP-NV for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 09:48:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EDmBx7022211 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 09:48:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gZ-0005mA-JN for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 09:48:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20880; Mon, 14 Jul 2003 09:48:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3gW-0007mf-00; Mon, 14 Jul 2003 09:48:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c3gV-0007mc-00; Mon, 14 Jul 2003 09:48:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gQ-0005fa-Az; Mon, 14 Jul 2003 09:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gL-0005eJ-3X for simple@optimus.ietf.org; Mon, 14 Jul 2003 09:47:57 -0400 Received: from mail4.dynamicsoft.com (mail4.dynamicsoft.com [63.110.3.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20846 for ; Mon, 14 Jul 2003 09:47:53 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EDlKE5006364 for ; Mon, 14 Jul 2003 09:47:20 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jul 2003 08:47:19 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE9@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Simple WG Subject: RE: [Simple] asking for a specific view MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 08:47:10 -0500 Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > To remedy this, I think we need to enhance the filter work to allow a > watcher to ask for a specific view of the presence data. We have some > work to do to define a view, but we have a couple of good candidates > to work from. I'm pretty certain that you're going to run into a lot of situations in which presence cannot be broken down along specific lines (like device or service views). For example, presence information may arrive at a PA already partially (or even fully) composed of information about multiple devices. You'll also often run into situations in which composition is performed as a means of intentional obscurity. I'm not saying that your suggestion is bad, but I suspect that we'll discover that the cases in which requests for certain types of views make sense will be the exception rather than the norm. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 09:48:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21084; Mon, 14 Jul 2003 09:48:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3hN-000013-00; Mon, 14 Jul 2003 09:49:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c3hL-000010-00; Mon, 14 Jul 2003 09:48:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3hM-00067v-T9; Mon, 14 Jul 2003 09:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gX-0005lA-Ko for simple@optimus.ietf.org; Mon, 14 Jul 2003 09:48:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20869 for ; Mon, 14 Jul 2003 09:48:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3gV-0007mS-00 for simple@ietf.org; Mon, 14 Jul 2003 09:48:07 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19c3gT-0007l9-00 for simple@ietf.org; Mon, 14 Jul 2003 09:48:05 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EDlKE5006365; Mon, 14 Jul 2003 09:47:20 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jul 2003 08:47:19 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEB@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Henning Schulzrinne , "Peterson, Jon" Cc: "Simpletons (E-mail)" Subject: RE: [Simple] comments on rpids-01 (general, vCard, predictive) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 08:47:11 -0500 > > Again, commercial instant messaging systems, in my > experience, don't use > > presentity-provided icons to express a presentity's current > state in a > > watcher's buddylist screen. Apps might have predefined > icons corresponding > > to, say, your state as given in rpids-00, but I > don't think I've > > seen user-supplied versions of those icons to date. The > whole value of these > > See GAIM above, albeit provided by the watcher, given the lack of > protocol support. I'm really going to have to agree strongly with Jon here. Allowing the presentity to provide icons to represent any kind of state -- and especially presence state -- is going to result in nothing but an inscrutable mish-mash of angry fruit salad in your buddy-list window. It would be a real black eye if all or even most SIMPLE-based IM systems ended up being thematically similar to the typical poorly-designed amateur web page that consists primarily of jarringly mismatched graphics found elsewhere on the web. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 09:49:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21147 for ; Mon, 14 Jul 2003 09:49:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3hP-00069b-TN for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 09:49:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EDn3xS023649 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 09:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3hP-00069M-MW for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 09:49:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21084; Mon, 14 Jul 2003 09:48:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3hN-000013-00; Mon, 14 Jul 2003 09:49:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c3hL-000010-00; Mon, 14 Jul 2003 09:48:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3hM-00067v-T9; Mon, 14 Jul 2003 09:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gX-0005lA-Ko for simple@optimus.ietf.org; Mon, 14 Jul 2003 09:48:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20869 for ; Mon, 14 Jul 2003 09:48:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3gV-0007mS-00 for simple@ietf.org; Mon, 14 Jul 2003 09:48:07 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19c3gT-0007l9-00 for simple@ietf.org; Mon, 14 Jul 2003 09:48:05 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EDlKE5006365; Mon, 14 Jul 2003 09:47:20 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jul 2003 08:47:19 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEB@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Henning Schulzrinne , "Peterson, Jon" Cc: "Simpletons (E-mail)" Subject: RE: [Simple] comments on rpids-01 (general, vCard, predictive) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 08:47:11 -0500 > > Again, commercial instant messaging systems, in my > experience, don't use > > presentity-provided icons to express a presentity's current > state in a > > watcher's buddylist screen. Apps might have predefined > icons corresponding > > to, say, your state as given in rpids-00, but I > don't think I've > > seen user-supplied versions of those icons to date. The > whole value of these > > See GAIM above, albeit provided by the watcher, given the lack of > protocol support. I'm really going to have to agree strongly with Jon here. Allowing the presentity to provide icons to represent any kind of state -- and especially presence state -- is going to result in nothing but an inscrutable mish-mash of angry fruit salad in your buddy-list window. It would be a real black eye if all or even most SIMPLE-based IM systems ended up being thematically similar to the typical poorly-designed amateur web page that consists primarily of jarringly mismatched graphics found elsewhere on the web. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 10:00:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21479; Mon, 14 Jul 2003 10:00:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3s5-00007S-00; Mon, 14 Jul 2003 10:00:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c3s4-00007P-00; Mon, 14 Jul 2003 10:00:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3s1-0006Tn-1r; Mon, 14 Jul 2003 10:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3rh-0006Sk-Hf for simple@optimus.ietf.org; Mon, 14 Jul 2003 09:59:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21457 for ; Mon, 14 Jul 2003 09:59:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3rf-00007J-00 for simple@ietf.org; Mon, 14 Jul 2003 09:59:39 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19c3re-000079-00 for simple@ietf.org; Mon, 14 Jul 2003 09:59:38 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6EDx2518846; Mon, 14 Jul 2003 08:59:02 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h6EDx0r24558; Mon, 14 Jul 2003 08:59:01 -0500 (CDT) Message-ID: <3F12B71E.4000702@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: "Peterson, Jon" , "'Henning Schulzrinne'" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> <3F1165BD.8010406@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 08:58:54 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [...] > I'm not sure that works for presence, though. That is, I don't think you > could generate a SUBSCRIBE with appropriate caller preferences > parameters to just get the presence of the executive and not their > support staff. Right; when we first came up with the notion of the element, our thoughts were along the lines of the primary presentity being busy (present, but busy and not-interruptible), and having a different person act as a temporary surrogate. The canonical example Dr. Schulzrinne provided was a professor being in an oral, and thus not interruptable for the duration of the exam except by the holder of the element. No mention was made about the presence status of the AoR in the element. And I believe this suffices, and even mirrors the real- world (boss away, secretary takes phone calls, but may be out to lunch). > I'm in agreement with Jon that we don't want to populate Joe's presence > document with tuples that really describe Bob, just because Bob is Joe's > assistant. But, Bob does represent a point of contact for Joe, and I > think that information itself is useful presence. Agree. > So, how about this. We could mandate that when a contact contains the > element, the tuple has no other information except for > open/closed. The element can have an attribute which says > where to go to get the acutal presence for that user: [...] > This way, there is never actual presence information for the secretary - > only a reference to obtain it. But, the secretary is listed as a contact > point. Concur. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 10:00:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21501 for ; Mon, 14 Jul 2003 10:00:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3s8-0006VW-GO for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 10:00:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EE08jq025014 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 10:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3s8-0006VN-Da for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 10:00:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21479; Mon, 14 Jul 2003 10:00:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3s5-00007S-00; Mon, 14 Jul 2003 10:00:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c3s4-00007P-00; Mon, 14 Jul 2003 10:00:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3s1-0006Tn-1r; Mon, 14 Jul 2003 10:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3rh-0006Sk-Hf for simple@optimus.ietf.org; Mon, 14 Jul 2003 09:59:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21457 for ; Mon, 14 Jul 2003 09:59:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3rf-00007J-00 for simple@ietf.org; Mon, 14 Jul 2003 09:59:39 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19c3re-000079-00 for simple@ietf.org; Mon, 14 Jul 2003 09:59:38 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6EDx2518846; Mon, 14 Jul 2003 08:59:02 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h6EDx0r24558; Mon, 14 Jul 2003 08:59:01 -0500 (CDT) Message-ID: <3F12B71E.4000702@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: "Peterson, Jon" , "'Henning Schulzrinne'" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> <3F1165BD.8010406@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 08:58:54 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [...] > I'm not sure that works for presence, though. That is, I don't think you > could generate a SUBSCRIBE with appropriate caller preferences > parameters to just get the presence of the executive and not their > support staff. Right; when we first came up with the notion of the element, our thoughts were along the lines of the primary presentity being busy (present, but busy and not-interruptible), and having a different person act as a temporary surrogate. The canonical example Dr. Schulzrinne provided was a professor being in an oral, and thus not interruptable for the duration of the exam except by the holder of the element. No mention was made about the presence status of the AoR in the element. And I believe this suffices, and even mirrors the real- world (boss away, secretary takes phone calls, but may be out to lunch). > I'm in agreement with Jon that we don't want to populate Joe's presence > document with tuples that really describe Bob, just because Bob is Joe's > assistant. But, Bob does represent a point of contact for Joe, and I > think that information itself is useful presence. Agree. > So, how about this. We could mandate that when a contact contains the > element, the tuple has no other information except for > open/closed. The element can have an attribute which says > where to go to get the acutal presence for that user: [...] > This way, there is never actual presence information for the secretary - > only a reference to obtain it. But, the secretary is listed as a contact > point. Concur. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 10:17:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23027; Mon, 14 Jul 2003 10:17:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c48W-0000FB-00; Mon, 14 Jul 2003 10:17:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c48W-0000F8-00; Mon, 14 Jul 2003 10:17:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c48S-0007ao-Qn; Mon, 14 Jul 2003 10:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c47a-0007a8-U2 for simple@optimus.ietf.org; Mon, 14 Jul 2003 10:16:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22959 for ; Mon, 14 Jul 2003 10:16:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c47Y-0000F3-00 for simple@ietf.org; Mon, 14 Jul 2003 10:16:04 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19c47X-0000F0-00 for simple@ietf.org; Mon, 14 Jul 2003 10:16:03 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6EEFR526966; Mon, 14 Jul 2003 09:15:28 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h6EEFQr11688; Mon, 14 Jul 2003 09:15:26 -0500 (CDT) Message-ID: <3F12BAD8.2040908@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: Jonathan Rosenberg , "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> <3F1165BD.8010406@dynamicsoft.com> <3F116ACF.60503@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 09:14:48 -0500 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: [...] >> I'm in agreement with Jon that we don't want to populate Joe's >> presence document with tuples that really describe Bob, just because >> Bob is Joe's assistant. But, Bob does represent a point of contact for >> Joe, and I think that information itself is useful presence. > > I think this is somewhere in-between. We have other entities, such as > voicemail systems, that are valid contacts and tuples. What is the > principal difference between my voicemail box and the executive version, > with a live human being answering it? The latter can actually assess a situation and decide if it is worth interrupting the presentity. My wife calling my secretary in a harried tone is apt more to get a favorable response from my secretary then she is from a voicemail box which will impassively ask it to press "2" for an emergency. Likewise, anyone calling my voice mailbox is given the opportunity to interrupt me under the guise of an emergency; folks calling my secretary won't be so fradulent in their purpose (one hopes). Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 10:17:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23100 for ; Mon, 14 Jul 2003 10:17:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c48Z-0007cK-Vf for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 10:17:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EEH7RJ029276 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 10:17:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c48Z-0007c7-Rz for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 10:17:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23027; Mon, 14 Jul 2003 10:17:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c48W-0000FB-00; Mon, 14 Jul 2003 10:17:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c48W-0000F8-00; Mon, 14 Jul 2003 10:17:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c48S-0007ao-Qn; Mon, 14 Jul 2003 10:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c47a-0007a8-U2 for simple@optimus.ietf.org; Mon, 14 Jul 2003 10:16:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22959 for ; Mon, 14 Jul 2003 10:16:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c47Y-0000F3-00 for simple@ietf.org; Mon, 14 Jul 2003 10:16:04 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19c47X-0000F0-00 for simple@ietf.org; Mon, 14 Jul 2003 10:16:03 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6EEFR526966; Mon, 14 Jul 2003 09:15:28 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h6EEFQr11688; Mon, 14 Jul 2003 09:15:26 -0500 (CDT) Message-ID: <3F12BAD8.2040908@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: Jonathan Rosenberg , "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> <3F1165BD.8010406@dynamicsoft.com> <3F116ACF.60503@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 09:14:48 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: [...] >> I'm in agreement with Jon that we don't want to populate Joe's >> presence document with tuples that really describe Bob, just because >> Bob is Joe's assistant. But, Bob does represent a point of contact for >> Joe, and I think that information itself is useful presence. > > I think this is somewhere in-between. We have other entities, such as > voicemail systems, that are valid contacts and tuples. What is the > principal difference between my voicemail box and the executive version, > with a live human being answering it? The latter can actually assess a situation and decide if it is worth interrupting the presentity. My wife calling my secretary in a harried tone is apt more to get a favorable response from my secretary then she is from a voicemail box which will impassively ask it to press "2" for an emergency. Likewise, anyone calling my voice mailbox is given the opportunity to interrupt me under the guise of an emergency; folks calling my secretary won't be so fradulent in their purpose (one hopes). Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 10:35:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24676; Mon, 14 Jul 2003 10:35:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4Q2-0000cX-00; Mon, 14 Jul 2003 10:35:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c4Q1-0000cU-00; Mon, 14 Jul 2003 10:35:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Pt-0008T4-Hm; Mon, 14 Jul 2003 10:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4PM-0008Pl-Bw for simple@optimus.ietf.org; Mon, 14 Jul 2003 10:34:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24606 for ; Mon, 14 Jul 2003 10:34:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4PK-0000ay-00 for simple@ietf.org; Mon, 14 Jul 2003 10:34:26 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19c4PI-0000aq-00 for simple@ietf.org; Mon, 14 Jul 2003 10:34:25 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6EEYBkM025359; Mon, 14 Jul 2003 10:34:11 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6EEY6g02640; Mon, 14 Jul 2003 10:34:06 -0400 Message-ID: <3F12BE68.6010506@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Jonathan Rosenberg , "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> <3F1165BD.8010406@dynamicsoft.com> <3F116ACF.60503@cs.columbia.edu> <3F12BAD8.2040908@lucent.com> In-Reply-To: <3F12BAD8.2040908@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 10:30:00 -0400 Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: You nicely describe the properties of a good secretary and how it improves upon the inanimate version, but how does this relate to the "can't be part of another presence document" question? > The latter can actually assess a situation and decide if it is > worth interrupting the presentity. My wife calling my secretary > in a harried tone is apt more to get a favorable response from > my secretary then she is from a voicemail box which will impassively > ask it to press "2" for an emergency. Likewise, anyone calling > my voice mailbox is given the opportunity to interrupt me under > the guise of an emergency; folks calling my secretary won't be > so fradulent in their purpose (one hopes). > > Regards, > > - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 10:35:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24800 for ; Mon, 14 Jul 2003 10:35:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Q9-00009Y-MF for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 10:35:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EEZHAf000584 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 10:35:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Q9-00009L-JG for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 10:35:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24676; Mon, 14 Jul 2003 10:35:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4Q2-0000cX-00; Mon, 14 Jul 2003 10:35:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c4Q1-0000cU-00; Mon, 14 Jul 2003 10:35:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Pt-0008T4-Hm; Mon, 14 Jul 2003 10:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4PM-0008Pl-Bw for simple@optimus.ietf.org; Mon, 14 Jul 2003 10:34:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24606 for ; Mon, 14 Jul 2003 10:34:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4PK-0000ay-00 for simple@ietf.org; Mon, 14 Jul 2003 10:34:26 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19c4PI-0000aq-00 for simple@ietf.org; Mon, 14 Jul 2003 10:34:25 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6EEYBkM025359; Mon, 14 Jul 2003 10:34:11 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6EEY6g02640; Mon, 14 Jul 2003 10:34:06 -0400 Message-ID: <3F12BE68.6010506@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Jonathan Rosenberg , "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> <3F1165BD.8010406@dynamicsoft.com> <3F116ACF.60503@cs.columbia.edu> <3F12BAD8.2040908@lucent.com> In-Reply-To: <3F12BAD8.2040908@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 10:30:00 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: You nicely describe the properties of a good secretary and how it improves upon the inanimate version, but how does this relate to the "can't be part of another presence document" question? > The latter can actually assess a situation and decide if it is > worth interrupting the presentity. My wife calling my secretary > in a harried tone is apt more to get a favorable response from > my secretary then she is from a voicemail box which will impassively > ask it to press "2" for an emergency. Likewise, anyone calling > my voice mailbox is given the opportunity to interrupt me under > the guise of an emergency; folks calling my secretary won't be > so fradulent in their purpose (one hopes). > > Regards, > > - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 10:36:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21004 for ; Mon, 14 Jul 2003 09:48:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gZ-0005m4-Db for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 09:48:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EDmBeM022176 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 09:48:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gZ-0005la-7x for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 09:48:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20875; Mon, 14 Jul 2003 09:48:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3gW-0007mb-00; Mon, 14 Jul 2003 09:48:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c3gU-0007mW-00; Mon, 14 Jul 2003 09:48:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gO-0005ej-VR; Mon, 14 Jul 2003 09:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gJ-0005dz-HO for simple@optimus.ietf.org; Mon, 14 Jul 2003 09:47:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20837 for ; Mon, 14 Jul 2003 09:47:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3gH-0007lg-00 for simple@ietf.org; Mon, 14 Jul 2003 09:47:53 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19c3gF-0007kY-00 for simple@ietf.org; Mon, 14 Jul 2003 09:47:52 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EDlKE5006368 for ; Mon, 14 Jul 2003 09:47:20 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jul 2003 08:47:19 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEA@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Date Formats Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 08:47:11 -0500 RPIDS uses dates like PIDF: 2003-01-27T19:30:00Z While the XCAP event package uses HTTP dates: version="Mon, 26 May 2003 19:43:31 GMT" (presumably always expressed as GMT? It doesn't say as much, and specifically cites HTTP instead of SIP as its source; HTTP allows arbitrary time zones). Frankly, I don't relish having to keep straight which format to use where. Would it be possible for us, as a working group, to pick one format that we use for bodies of new protocols going forward and stick with it? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 10:36:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20875; Mon, 14 Jul 2003 09:48:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3gW-0007mb-00; Mon, 14 Jul 2003 09:48:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c3gU-0007mW-00; Mon, 14 Jul 2003 09:48:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gO-0005ej-VR; Mon, 14 Jul 2003 09:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gJ-0005dz-HO for simple@optimus.ietf.org; Mon, 14 Jul 2003 09:47:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20837 for ; Mon, 14 Jul 2003 09:47:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3gH-0007lg-00 for simple@ietf.org; Mon, 14 Jul 2003 09:47:53 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19c3gF-0007kY-00 for simple@ietf.org; Mon, 14 Jul 2003 09:47:52 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EDlKE5006368 for ; Mon, 14 Jul 2003 09:47:20 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jul 2003 08:47:19 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEA@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Date Formats Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 08:47:11 -0500 RPIDS uses dates like PIDF: 2003-01-27T19:30:00Z While the XCAP event package uses HTTP dates: version="Mon, 26 May 2003 19:43:31 GMT" (presumably always expressed as GMT? It doesn't say as much, and specifically cites HTTP instead of SIP as its source; HTTP allows arbitrary time zones). Frankly, I don't relish having to keep straight which format to use where. Would it be possible for us, as a working group, to pick one format that we use for bodies of new protocols going forward and stick with it? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 11:10:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27431; Mon, 14 Jul 2003 11:10:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4xq-0001GU-00; Mon, 14 Jul 2003 11:10:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c4xp-0001GR-00; Mon, 14 Jul 2003 11:10:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4xl-0002ZR-K6; Mon, 14 Jul 2003 11:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4wy-0002Yn-Sh for simple@optimus.ietf.org; Mon, 14 Jul 2003 11:09:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27418 for ; Mon, 14 Jul 2003 11:09:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4ww-0001GK-00 for simple@ietf.org; Mon, 14 Jul 2003 11:09:10 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19c4wu-0001G6-00 for simple@ietf.org; Mon, 14 Jul 2003 11:09:08 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6EF8eP13221; Mon, 14 Jul 2003 10:08:41 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h6EF8Rr08417; Mon, 14 Jul 2003 10:08:27 -0500 (CDT) Message-ID: <3F12C769.10601@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: Jonathan Rosenberg , "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> <3F1165BD.8010406@dynamicsoft.com> <3F116ACF.60503@cs.columbia.edu> <3F12BAD8.2040908@lucent.com> <3F12BE68.6010506@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 10:08:25 -0500 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Vijay K. Gurbani wrote: > > > You nicely describe the properties of a good secretary and how it > improves upon the inanimate version, but how does this relate to the > "can't be part of another presence document" question? Unless I got my threads mixed, I believe we were discussing if we should put presence status of secondary AoRs in a presentity's document. Jonathan proposed a means of including a reference to obtain the secretary's presence so we don't populate the presentity's document with presence status of alternative contacts (http://www1.ietf.org/mail-archive/working-groups/simple/current/msg01151.html), which I think is reasonable (modulo the security aspects). - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 11:10:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27478 for ; Mon, 14 Jul 2003 11:10:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4xt-0002b4-Ok for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 11:10:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EFA9jG009979 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 11:10:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4xt-0002as-Fu for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 11:10:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27431; Mon, 14 Jul 2003 11:10:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4xq-0001GU-00; Mon, 14 Jul 2003 11:10:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c4xp-0001GR-00; Mon, 14 Jul 2003 11:10:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4xl-0002ZR-K6; Mon, 14 Jul 2003 11:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4wy-0002Yn-Sh for simple@optimus.ietf.org; Mon, 14 Jul 2003 11:09:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27418 for ; Mon, 14 Jul 2003 11:09:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4ww-0001GK-00 for simple@ietf.org; Mon, 14 Jul 2003 11:09:10 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19c4wu-0001G6-00 for simple@ietf.org; Mon, 14 Jul 2003 11:09:08 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6EF8eP13221; Mon, 14 Jul 2003 10:08:41 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h6EF8Rr08417; Mon, 14 Jul 2003 10:08:27 -0500 (CDT) Message-ID: <3F12C769.10601@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: Jonathan Rosenberg , "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> <3F1165BD.8010406@dynamicsoft.com> <3F116ACF.60503@cs.columbia.edu> <3F12BAD8.2040908@lucent.com> <3F12BE68.6010506@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 10:08:25 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Vijay K. Gurbani wrote: > > > You nicely describe the properties of a good secretary and how it > improves upon the inanimate version, but how does this relate to the > "can't be part of another presence document" question? Unless I got my threads mixed, I believe we were discussing if we should put presence status of secondary AoRs in a presentity's document. Jonathan proposed a means of including a reference to obtain the secretary's presence so we don't populate the presentity's document with presence status of alternative contacts (http://www1.ietf.org/mail-archive/working-groups/simple/current/msg01151.html), which I think is reasonable (modulo the security aspects). - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 11:27:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28198; Mon, 14 Jul 2003 11:27:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c5EJ-0001TF-00; Mon, 14 Jul 2003 11:27:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c5EJ-0001TC-00; Mon, 14 Jul 2003 11:27:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5ED-0003iA-HJ; Mon, 14 Jul 2003 11:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5Dp-0003hu-Mq for simple@optimus.ietf.org; Mon, 14 Jul 2003 11:26:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28162 for ; Mon, 14 Jul 2003 11:26:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c5Do-0001Sa-00 for simple@ietf.org; Mon, 14 Jul 2003 11:26:36 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19c5Dn-0001Rm-00 for simple@ietf.org; Mon, 14 Jul 2003 11:26:36 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6EFQ0s23957; Mon, 14 Jul 2003 10:26:00 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h6EFPxr27232; Mon, 14 Jul 2003 10:25:59 -0500 (CDT) Message-ID: <3F12CB84.7000902@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, jon.peterson@neustar.biz, simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] rpids-01 - security and Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 10:25:56 -0500 Content-Transfer-Encoding: 7bit [Renamed this thread to "rpids-01 security and " Henning Schulzrinne wrote: > hisham.khartabil@nokia.com wrote: > >> Can't this be done by sharing an authorisation list between the >> secretary and her boss? > > Not generally. I'm not sure how sharing would work in practice (given > lack of deployment of such mechanisms), but you would either have > authorization lists with multiple-user access rights (not likely to be > common, judging how typical 'accounts' work in other systems) or share a > key. Is it possible to use URI leasing here and not worry about sharing authorization lists? Example: Assume that Jane subscribe to Joe's presence and is duly authorized to do so. Joe has a secretary, Bob, whose tuple is in Joe's presence document. Bob's URI is a leased URI, temporally scoped and dynamically generated. Only Jane who is authorized to know Joe's presence can be privy to this leased URI. The leased URI can be constructed in such a way as to make it hard to replicate by accident (UUID?). > Even assuming this could work, this doesn't have the same functionality. > For example, the secretary may only want to be visible to boss-permitted > contacts from 9 to 5, but can't easily tell which contacts were > authorized by the boss (so that the secretary can drop them at 5 and > re-admit them at 9 the next day). Contacts coming to the secretary through the leased URI will be automatically accepted...? Is it worth pursuing this line of thought? Does it makes authorization lists unneccessary? Just as I do not have a secretary, I am not a security expert either :-) > If we can make these requirements for the authorization work, I'd be > less concerned and Jonathan's suggestion would work well. > > The requirements are basically > (1) allow multiple parties to edit the authorization list > (2) the origin of each entry needs to be clear (who added it to the list) > (3) updates and relationship for the same watcher by different updaters > need to be clear (example: Secretary has Alice in her "good" list, but > boss adds Alice as well; Alice shouldn't disappear from that list after > 5 pm; whwat happens if there is a conflict?). Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 11:27:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28269 for ; Mon, 14 Jul 2003 11:27:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5EL-0003ip-Lm for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 11:27:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EFR9dV014305 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 11:27:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5EL-0003ie-Gd for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 11:27:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28198; Mon, 14 Jul 2003 11:27:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c5EJ-0001TF-00; Mon, 14 Jul 2003 11:27:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c5EJ-0001TC-00; Mon, 14 Jul 2003 11:27:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5ED-0003iA-HJ; Mon, 14 Jul 2003 11:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5Dp-0003hu-Mq for simple@optimus.ietf.org; Mon, 14 Jul 2003 11:26:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28162 for ; Mon, 14 Jul 2003 11:26:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c5Do-0001Sa-00 for simple@ietf.org; Mon, 14 Jul 2003 11:26:36 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19c5Dn-0001Rm-00 for simple@ietf.org; Mon, 14 Jul 2003 11:26:36 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6EFQ0s23957; Mon, 14 Jul 2003 10:26:00 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h6EFPxr27232; Mon, 14 Jul 2003 10:25:59 -0500 (CDT) Message-ID: <3F12CB84.7000902@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, jon.peterson@neustar.biz, simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] rpids-01 - security and Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 10:25:56 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Renamed this thread to "rpids-01 security and " Henning Schulzrinne wrote: > hisham.khartabil@nokia.com wrote: > >> Can't this be done by sharing an authorisation list between the >> secretary and her boss? > > Not generally. I'm not sure how sharing would work in practice (given > lack of deployment of such mechanisms), but you would either have > authorization lists with multiple-user access rights (not likely to be > common, judging how typical 'accounts' work in other systems) or share a > key. Is it possible to use URI leasing here and not worry about sharing authorization lists? Example: Assume that Jane subscribe to Joe's presence and is duly authorized to do so. Joe has a secretary, Bob, whose tuple is in Joe's presence document. Bob's URI is a leased URI, temporally scoped and dynamically generated. Only Jane who is authorized to know Joe's presence can be privy to this leased URI. The leased URI can be constructed in such a way as to make it hard to replicate by accident (UUID?). > Even assuming this could work, this doesn't have the same functionality. > For example, the secretary may only want to be visible to boss-permitted > contacts from 9 to 5, but can't easily tell which contacts were > authorized by the boss (so that the secretary can drop them at 5 and > re-admit them at 9 the next day). Contacts coming to the secretary through the leased URI will be automatically accepted...? Is it worth pursuing this line of thought? Does it makes authorization lists unneccessary? Just as I do not have a secretary, I am not a security expert either :-) > If we can make these requirements for the authorization work, I'd be > less concerned and Jonathan's suggestion would work well. > > The requirements are basically > (1) allow multiple parties to edit the authorization list > (2) the origin of each entry needs to be clear (who added it to the list) > (3) updates and relationship for the same watcher by different updaters > need to be clear (example: Secretary has Alice in her "good" list, but > boss adds Alice as well; Alice shouldn't disappear from that list after > 5 pm; whwat happens if there is a conflict?). Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 11:55:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00276; Mon, 14 Jul 2003 11:55:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c5fR-0001z5-00; Mon, 14 Jul 2003 11:55:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c5fR-0001z2-00; Mon, 14 Jul 2003 11:55:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5fJ-0006Dz-Oh; Mon, 14 Jul 2003 11:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5eh-0006DS-NJ for simple@optimus.ietf.org; Mon, 14 Jul 2003 11:54:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00252 for ; Mon, 14 Jul 2003 11:54:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c5eg-0001yX-00 for simple@ietf.org; Mon, 14 Jul 2003 11:54:22 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19c5ef-0001yU-00 for simple@ietf.org; Mon, 14 Jul 2003 11:54:21 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 14 Jul 2003 16:57:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Simple] comments on rpids-01 (general, vCard, predictive) Message-ID: <45730E094814E44488F789C1CDED27AE0219B026@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] comments on rpids-01 (general, vCard, predictive) Thread-Index: AcNKDqZ22z7PM7HUQuiAi/OdEihJ6QAEM2Br From: "Chris Boulton" To: "Adam Roach" , "Henning Schulzrinne" , "Peterson, Jon" Cc: "Simpletons (E-mail)" Content-Transfer-Encoding: base64 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 16:53:58 +0100 Content-Transfer-Encoding: base64 SXQgcmVhbGx5IGRvZXMgc2VlbSBzZW5zaWJsZSB0byBtZSB0byBtYXliZSBpbmNsdWRlIG9wdGlv bmFsIGF0dHJpYnV0ZXMgZm9yIHRlaCBzaXplIG9mIGFuIGljb24uICBCeSBtYWtpbmcgaXQgb3B0 aW9uYWwsIHlvdSBnaXZlIGxpY2VuY2UgdG8gY2xpZW50cyB0byAnZG8gYXMgdGhleSB3aXNoJyBC VVQgeW91IGRvIGdpdmUgdGhlbSB0aGUgb3BwZXJ0dW5pdHkgdG8gcmVuZGVyIGNvcnJlY3RseS4N CiANCkNocmlzLg0KIA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCglGcm9tOiBBZGFt IFJvYWNoIFttYWlsdG86YWRhbUBkeW5hbWljc29mdC5jb21dIA0KCVNlbnQ6IE1vbiAxNC8wNy8y MDAzIDE0OjQ3IA0KCVRvOiBIZW5uaW5nIFNjaHVsenJpbm5lOyBQZXRlcnNvbiwgSm9uIA0KCUNj OiBTaW1wbGV0b25zIChFLW1haWwpIA0KCVN1YmplY3Q6IFJFOiBbU2ltcGxlXSBjb21tZW50cyBv biBycGlkcy0wMSAoZ2VuZXJhbCwgdkNhcmQsIHByZWRpY3RpdmUpDQoJDQoJDQoNCgk+ID4gQWdh aW4sIGNvbW1lcmNpYWwgaW5zdGFudCBtZXNzYWdpbmcgc3lzdGVtcywgaW4gbXkNCgk+IGV4cGVy aWVuY2UsIGRvbid0IHVzZQ0KCT4gPiBwcmVzZW50aXR5LXByb3ZpZGVkIGljb25zIHRvIGV4cHJl c3MgYSBwcmVzZW50aXR5J3MgY3VycmVudA0KCT4gc3RhdGUgaW4gYQ0KCT4gPiB3YXRjaGVyJ3Mg YnVkZHlsaXN0IHNjcmVlbi4gQXBwcyBtaWdodCBoYXZlIHByZWRlZmluZWQNCgk+IGljb25zIGNv cnJlc3BvbmRpbmcNCgk+ID4gdG8sIHNheSwgeW91ciA8Y2F0ZWdvcnk+IHN0YXRlIGFzIGdpdmVu IGluIHJwaWRzLTAwLCBidXQgSQ0KCT4gZG9uJ3QgdGhpbmsgSSd2ZQ0KCT4gPiBzZWVuIHVzZXIt c3VwcGxpZWQgdmVyc2lvbnMgb2YgdGhvc2UgaWNvbnMgdG8gZGF0ZS4gVGhlDQoJPiB3aG9sZSB2 YWx1ZSBvZiB0aGVzZQ0KCT4NCgk+IFNlZSBHQUlNIGFib3ZlLCBhbGJlaXQgcHJvdmlkZWQgYnkg dGhlIHdhdGNoZXIsIGdpdmVuIHRoZSBsYWNrIG9mDQoJPiBwcm90b2NvbCBzdXBwb3J0Lg0KCQ0K CUknbSByZWFsbHkgZ29pbmcgdG8gaGF2ZSB0byBhZ3JlZSBzdHJvbmdseSB3aXRoIEpvbiBoZXJl Lg0KCUFsbG93aW5nIHRoZSBwcmVzZW50aXR5IHRvIHByb3ZpZGUgaWNvbnMgdG8gcmVwcmVzZW50 IGFueQ0KCWtpbmQgb2Ygc3RhdGUgLS0gYW5kIGVzcGVjaWFsbHkgcHJlc2VuY2Ugc3RhdGUgLS0g aXMgZ29pbmcNCgl0byByZXN1bHQgaW4gbm90aGluZyBidXQgYW4gaW5zY3J1dGFibGUgbWlzaC1t YXNoIG9mIGFuZ3J5DQoJZnJ1aXQgc2FsYWQgaW4geW91ciBidWRkeS1saXN0IHdpbmRvdy4NCgkN CglJdCB3b3VsZCBiZSBhIHJlYWwgYmxhY2sgZXllIGlmIGFsbCBvciBldmVuIG1vc3QgU0lNUExF LWJhc2VkDQoJSU0gc3lzdGVtcyBlbmRlZCB1cCBiZWluZyB0aGVtYXRpY2FsbHkgc2ltaWxhciB0 byB0aGUgdHlwaWNhbA0KCXBvb3JseS1kZXNpZ25lZCBhbWF0ZXVyIHdlYiBwYWdlIHRoYXQgY29u c2lzdHMgcHJpbWFyaWx5IG9mDQoJamFycmluZ2x5IG1pc21hdGNoZWQgZ3JhcGhpY3MgZm91bmQg ZWxzZXdoZXJlIG9uIHRoZSB3ZWIuDQoJDQoJL2ENCgkNCglfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KCVNpbXBsZSBtYWlsaW5nIGxpc3QNCglTaW1wbGVA aWV0Zi5vcmcNCglodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUN CgkNCg0K _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 11:55:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00292 for ; Mon, 14 Jul 2003 11:55:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5fT-0006Ej-NU for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 11:55:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EFtBAO023969 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 11:55:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5fT-0006EW-Kh for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 11:55:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00276; Mon, 14 Jul 2003 11:55:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c5fR-0001z5-00; Mon, 14 Jul 2003 11:55:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c5fR-0001z2-00; Mon, 14 Jul 2003 11:55:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5fJ-0006Dz-Oh; Mon, 14 Jul 2003 11:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5eh-0006DS-NJ for simple@optimus.ietf.org; Mon, 14 Jul 2003 11:54:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00252 for ; Mon, 14 Jul 2003 11:54:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c5eg-0001yX-00 for simple@ietf.org; Mon, 14 Jul 2003 11:54:22 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19c5ef-0001yU-00 for simple@ietf.org; Mon, 14 Jul 2003 11:54:21 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 14 Jul 2003 16:57:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Simple] comments on rpids-01 (general, vCard, predictive) Message-ID: <45730E094814E44488F789C1CDED27AE0219B026@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] comments on rpids-01 (general, vCard, predictive) Thread-Index: AcNKDqZ22z7PM7HUQuiAi/OdEihJ6QAEM2Br From: "Chris Boulton" To: "Adam Roach" , "Henning Schulzrinne" , "Peterson, Jon" Cc: "Simpletons (E-mail)" Content-Transfer-Encoding: base64 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 16:53:58 +0100 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SXQgcmVhbGx5IGRvZXMgc2VlbSBzZW5zaWJsZSB0byBtZSB0byBtYXliZSBpbmNsdWRlIG9wdGlv bmFsIGF0dHJpYnV0ZXMgZm9yIHRlaCBzaXplIG9mIGFuIGljb24uICBCeSBtYWtpbmcgaXQgb3B0 aW9uYWwsIHlvdSBnaXZlIGxpY2VuY2UgdG8gY2xpZW50cyB0byAnZG8gYXMgdGhleSB3aXNoJyBC VVQgeW91IGRvIGdpdmUgdGhlbSB0aGUgb3BwZXJ0dW5pdHkgdG8gcmVuZGVyIGNvcnJlY3RseS4N CiANCkNocmlzLg0KIA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCglGcm9tOiBBZGFt IFJvYWNoIFttYWlsdG86YWRhbUBkeW5hbWljc29mdC5jb21dIA0KCVNlbnQ6IE1vbiAxNC8wNy8y MDAzIDE0OjQ3IA0KCVRvOiBIZW5uaW5nIFNjaHVsenJpbm5lOyBQZXRlcnNvbiwgSm9uIA0KCUNj OiBTaW1wbGV0b25zIChFLW1haWwpIA0KCVN1YmplY3Q6IFJFOiBbU2ltcGxlXSBjb21tZW50cyBv biBycGlkcy0wMSAoZ2VuZXJhbCwgdkNhcmQsIHByZWRpY3RpdmUpDQoJDQoJDQoNCgk+ID4gQWdh aW4sIGNvbW1lcmNpYWwgaW5zdGFudCBtZXNzYWdpbmcgc3lzdGVtcywgaW4gbXkNCgk+IGV4cGVy aWVuY2UsIGRvbid0IHVzZQ0KCT4gPiBwcmVzZW50aXR5LXByb3ZpZGVkIGljb25zIHRvIGV4cHJl c3MgYSBwcmVzZW50aXR5J3MgY3VycmVudA0KCT4gc3RhdGUgaW4gYQ0KCT4gPiB3YXRjaGVyJ3Mg YnVkZHlsaXN0IHNjcmVlbi4gQXBwcyBtaWdodCBoYXZlIHByZWRlZmluZWQNCgk+IGljb25zIGNv cnJlc3BvbmRpbmcNCgk+ID4gdG8sIHNheSwgeW91ciA8Y2F0ZWdvcnk+IHN0YXRlIGFzIGdpdmVu IGluIHJwaWRzLTAwLCBidXQgSQ0KCT4gZG9uJ3QgdGhpbmsgSSd2ZQ0KCT4gPiBzZWVuIHVzZXIt c3VwcGxpZWQgdmVyc2lvbnMgb2YgdGhvc2UgaWNvbnMgdG8gZGF0ZS4gVGhlDQoJPiB3aG9sZSB2 YWx1ZSBvZiB0aGVzZQ0KCT4NCgk+IFNlZSBHQUlNIGFib3ZlLCBhbGJlaXQgcHJvdmlkZWQgYnkg dGhlIHdhdGNoZXIsIGdpdmVuIHRoZSBsYWNrIG9mDQoJPiBwcm90b2NvbCBzdXBwb3J0Lg0KCQ0K CUknbSByZWFsbHkgZ29pbmcgdG8gaGF2ZSB0byBhZ3JlZSBzdHJvbmdseSB3aXRoIEpvbiBoZXJl Lg0KCUFsbG93aW5nIHRoZSBwcmVzZW50aXR5IHRvIHByb3ZpZGUgaWNvbnMgdG8gcmVwcmVzZW50 IGFueQ0KCWtpbmQgb2Ygc3RhdGUgLS0gYW5kIGVzcGVjaWFsbHkgcHJlc2VuY2Ugc3RhdGUgLS0g aXMgZ29pbmcNCgl0byByZXN1bHQgaW4gbm90aGluZyBidXQgYW4gaW5zY3J1dGFibGUgbWlzaC1t YXNoIG9mIGFuZ3J5DQoJZnJ1aXQgc2FsYWQgaW4geW91ciBidWRkeS1saXN0IHdpbmRvdy4NCgkN CglJdCB3b3VsZCBiZSBhIHJlYWwgYmxhY2sgZXllIGlmIGFsbCBvciBldmVuIG1vc3QgU0lNUExF LWJhc2VkDQoJSU0gc3lzdGVtcyBlbmRlZCB1cCBiZWluZyB0aGVtYXRpY2FsbHkgc2ltaWxhciB0 byB0aGUgdHlwaWNhbA0KCXBvb3JseS1kZXNpZ25lZCBhbWF0ZXVyIHdlYiBwYWdlIHRoYXQgY29u c2lzdHMgcHJpbWFyaWx5IG9mDQoJamFycmluZ2x5IG1pc21hdGNoZWQgZ3JhcGhpY3MgZm91bmQg ZWxzZXdoZXJlIG9uIHRoZSB3ZWIuDQoJDQoJL2ENCgkNCglfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KCVNpbXBsZSBtYWlsaW5nIGxpc3QNCglTaW1wbGVA aWV0Zi5vcmcNCglodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUN CgkNCg0K _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 13:55:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08945; Mon, 14 Jul 2003 13:55:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7XV-000490-00; Mon, 14 Jul 2003 13:55:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c7XV-00048x-00; Mon, 14 Jul 2003 13:55:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7XQ-0005DG-W0; Mon, 14 Jul 2003 13:55:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Ws-0005CE-Tv for simple@optimus.ietf.org; Mon, 14 Jul 2003 13:54:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08875 for ; Mon, 14 Jul 2003 13:54:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7Wq-00047j-00 for simple@ietf.org; Mon, 14 Jul 2003 13:54:24 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19c7Wp-00047g-00 for simple@ietf.org; Mon, 14 Jul 2003 13:54:23 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6EHsFkM019152; Mon, 14 Jul 2003 13:54:16 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6EHsEg22280; Mon, 14 Jul 2003 13:54:15 -0400 Message-ID: <3F12ED50.5010908@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Jonathan Rosenberg , "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> <3F1165BD.8010406@dynamicsoft.com> <3F116ACF.60503@cs.columbia.edu> <3F12BAD8.2040908@lucent.com> <3F12BE68.6010506@cs.columbia.edu> <3F12C769.10601@lucent.com> In-Reply-To: <3F12C769.10601@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 13:50:08 -0400 Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > > which I think is reasonable (modulo the security aspects). Are you agreeing or disagreeing with my authorization concerns? I don't think they are just 'modulo' concern. > > - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 13:55:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09017 for ; Mon, 14 Jul 2003 13:55:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7XY-0005Dv-QA for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 13:55:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EHt8P9020078 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 13:55:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7XY-0005Dl-Lr for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 13:55:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08945; Mon, 14 Jul 2003 13:55:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7XV-000490-00; Mon, 14 Jul 2003 13:55:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c7XV-00048x-00; Mon, 14 Jul 2003 13:55:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7XQ-0005DG-W0; Mon, 14 Jul 2003 13:55:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Ws-0005CE-Tv for simple@optimus.ietf.org; Mon, 14 Jul 2003 13:54:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08875 for ; Mon, 14 Jul 2003 13:54:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7Wq-00047j-00 for simple@ietf.org; Mon, 14 Jul 2003 13:54:24 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19c7Wp-00047g-00 for simple@ietf.org; Mon, 14 Jul 2003 13:54:23 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6EHsFkM019152; Mon, 14 Jul 2003 13:54:16 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6EHsEg22280; Mon, 14 Jul 2003 13:54:15 -0400 Message-ID: <3F12ED50.5010908@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Jonathan Rosenberg , "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> <3F1165BD.8010406@dynamicsoft.com> <3F116ACF.60503@cs.columbia.edu> <3F12BAD8.2040908@lucent.com> <3F12BE68.6010506@cs.columbia.edu> <3F12C769.10601@lucent.com> In-Reply-To: <3F12C769.10601@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 13:50:08 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > > which I think is reasonable (modulo the security aspects). Are you agreeing or disagreeing with my authorization concerns? I don't think they are just 'modulo' concern. > > - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 14:00:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09265; Mon, 14 Jul 2003 14:00:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7cJ-0004DJ-00; Mon, 14 Jul 2003 14:00:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c7cI-0004DG-00; Mon, 14 Jul 2003 14:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7cG-0005db-Et; Mon, 14 Jul 2003 14:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7bJ-0005aa-VQ for simple@optimus.ietf.org; Mon, 14 Jul 2003 13:59:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09206 for ; Mon, 14 Jul 2003 13:58:59 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7bH-0004Ca-00 for simple@ietf.org; Mon, 14 Jul 2003 13:58:59 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19c7bG-0004CV-00 for simple@ietf.org; Mon, 14 Jul 2003 13:58:59 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6EHwvk00790 for ; Mon, 14 Jul 2003 20:58:58 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 14 Jul 2003 20:58:57 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 20:58:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB0@esebe013.ntc.nokia.com> Thread-Topic: PUBLISH: atomicity problem Thread-Index: AcNKMZon8GMIwDCyTZmVEXvRJFhb/A== To: X-OriginalArrivalTime: 14 Jul 2003 17:58:57.0682 (UTC) FILETIME=[98F91720:01C34A31] Content-Transfer-Encoding: quoted-printable Subject: [Simple] PUBLISH: atomicity problem Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:58:57 +0300 Content-Transfer-Encoding: quoted-printable All, I'll try to summarize the issues w.r.t. the atomicity of publication = here in an attempt to converge the discussion towards a solution to this = problem. BTW, I realized that my slides in the SIMPLE session were = perhaps not crystal clear on what the problem at hand really was, so my = apologies for that. The core problem is this:=20 EPA X sends a PUBLISH with {a, b, c}, after which EPA Y publishes {a, = b}. When EPA X tries to refresh its publication of {a, b, c}, the = request fails because of a collision, resulting in the EPA X quitting. = EPA Y still refreshes its publication of {a, b}, which means {c} expires = and goes away. As a result, the publication process has lost information = of {c}. This is unacceptable, and with the current versioning mechanism, = this can't be remedied by composer policy, for example. Instead, to get around the above problem, what you send in a PUBLISH = needs to match the atomic element of the published information. So each = PUBLISH needs to contain a single tuple, because the versioning and = expiration all work on the single atomic element level anyway. This has the apparent drawback in that the PUA has to wait for a 200 OK = after each PUBLISHed tuple before it can PUBLISH the next one. This = occurs upon every refresh cycle, and in systems with high latency, may = become a major issue in terms of performance. Ways to get around this inefficiency: - Remove the restriction on overlapping requests, i.e., allow = "pipelining" of PUBLISH requests - Treat the publisher of each tuple as a separate EPA, and therefore = not subject to this restriction in the first place (seems like = cheating...)=20 In conclusion, my proposal is to go with having always a single tuple in = a PUBLISH, and allow overlapping PUBLISH requests. To my knowledge, this = would fulfill all the related requirements and solve the issue. Thoughts? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 14:00:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09301 for ; Mon, 14 Jul 2003 14:00:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7cM-0005hw-Sy for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 14:00:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EI06LG021934 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 14:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7cM-0005hh-BM for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 14:00:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09265; Mon, 14 Jul 2003 14:00:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7cJ-0004DJ-00; Mon, 14 Jul 2003 14:00:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c7cI-0004DG-00; Mon, 14 Jul 2003 14:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7cG-0005db-Et; Mon, 14 Jul 2003 14:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7bJ-0005aa-VQ for simple@optimus.ietf.org; Mon, 14 Jul 2003 13:59:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09206 for ; Mon, 14 Jul 2003 13:58:59 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7bH-0004Ca-00 for simple@ietf.org; Mon, 14 Jul 2003 13:58:59 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19c7bG-0004CV-00 for simple@ietf.org; Mon, 14 Jul 2003 13:58:59 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6EHwvk00790 for ; Mon, 14 Jul 2003 20:58:58 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 14 Jul 2003 20:58:57 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 20:58:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB0@esebe013.ntc.nokia.com> Thread-Topic: PUBLISH: atomicity problem Thread-Index: AcNKMZon8GMIwDCyTZmVEXvRJFhb/A== To: X-OriginalArrivalTime: 14 Jul 2003 17:58:57.0682 (UTC) FILETIME=[98F91720:01C34A31] Content-Transfer-Encoding: quoted-printable Subject: [Simple] PUBLISH: atomicity problem Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:58:57 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable All, I'll try to summarize the issues w.r.t. the atomicity of publication = here in an attempt to converge the discussion towards a solution to this = problem. BTW, I realized that my slides in the SIMPLE session were = perhaps not crystal clear on what the problem at hand really was, so my = apologies for that. The core problem is this:=20 EPA X sends a PUBLISH with {a, b, c}, after which EPA Y publishes {a, = b}. When EPA X tries to refresh its publication of {a, b, c}, the = request fails because of a collision, resulting in the EPA X quitting. = EPA Y still refreshes its publication of {a, b}, which means {c} expires = and goes away. As a result, the publication process has lost information = of {c}. This is unacceptable, and with the current versioning mechanism, = this can't be remedied by composer policy, for example. Instead, to get around the above problem, what you send in a PUBLISH = needs to match the atomic element of the published information. So each = PUBLISH needs to contain a single tuple, because the versioning and = expiration all work on the single atomic element level anyway. This has the apparent drawback in that the PUA has to wait for a 200 OK = after each PUBLISHed tuple before it can PUBLISH the next one. This = occurs upon every refresh cycle, and in systems with high latency, may = become a major issue in terms of performance. Ways to get around this inefficiency: - Remove the restriction on overlapping requests, i.e., allow = "pipelining" of PUBLISH requests - Treat the publisher of each tuple as a separate EPA, and therefore = not subject to this restriction in the first place (seems like = cheating...)=20 In conclusion, my proposal is to go with having always a single tuple in = a PUBLISH, and allow overlapping PUBLISH requests. To my knowledge, this = would fulfill all the related requirements and solve the issue. Thoughts? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 14:03:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09388; Mon, 14 Jul 2003 14:03:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7fD-0004EV-00; Mon, 14 Jul 2003 14:03:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c7fD-0004ES-00; Mon, 14 Jul 2003 14:03:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7fB-0005pM-Bz; Mon, 14 Jul 2003 14:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7eg-0005p6-2b for simple@optimus.ietf.org; Mon, 14 Jul 2003 14:02:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09353 for ; Mon, 14 Jul 2003 14:02:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7ed-0004E9-00 for simple@ietf.org; Mon, 14 Jul 2003 14:02:27 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19c7ec-0004E6-00 for simple@ietf.org; Mon, 14 Jul 2003 14:02:26 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6EI1qw19861; Mon, 14 Jul 2003 13:01:52 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h6EI1pr14241; Mon, 14 Jul 2003 13:01:51 -0500 (CDT) Message-ID: <3F12F00F.8070404@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> <3F1165BD.8010406@dynamicsoft.com> <3F116ACF.60503@cs.columbia.edu> <3F12BAD8.2040908@lucent.com> <3F12BE68.6010506@cs.columbia.edu> <3F12C769.10601@lucent.com> <3F12ED50.5010908@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 13:01:51 -0500 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Vijay K. Gurbani wrote: > >> >> which I think is reasonable (modulo the security aspects). > > Are you agreeing or disagreeing with my authorization concerns? I don't > think they are just 'modulo' concern. No, they are not. And yes, I do agree with your authorization concerns. In a separate email thread, I propose using URI leasing to address some of the authorization concerns. I think we will need more discussion on that aspect to see if it is feasible or not. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 14:03:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09428 for ; Mon, 14 Jul 2003 14:03:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7fG-0005so-Op for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 14:03:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EI36Up022608 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 14:03:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7fG-0005sY-LX for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 14:03:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09388; Mon, 14 Jul 2003 14:03:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7fD-0004EV-00; Mon, 14 Jul 2003 14:03:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c7fD-0004ES-00; Mon, 14 Jul 2003 14:03:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7fB-0005pM-Bz; Mon, 14 Jul 2003 14:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7eg-0005p6-2b for simple@optimus.ietf.org; Mon, 14 Jul 2003 14:02:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09353 for ; Mon, 14 Jul 2003 14:02:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7ed-0004E9-00 for simple@ietf.org; Mon, 14 Jul 2003 14:02:27 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19c7ec-0004E6-00 for simple@ietf.org; Mon, 14 Jul 2003 14:02:26 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6EI1qw19861; Mon, 14 Jul 2003 13:01:52 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h6EI1pr14241; Mon, 14 Jul 2003 13:01:51 -0500 (CDT) Message-ID: <3F12F00F.8070404@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C6A@stntexch2.va.neustar.com> <3F1165BD.8010406@dynamicsoft.com> <3F116ACF.60503@cs.columbia.edu> <3F12BAD8.2040908@lucent.com> <3F12BE68.6010506@cs.columbia.edu> <3F12C769.10601@lucent.com> <3F12ED50.5010908@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 13:01:51 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Vijay K. Gurbani wrote: > >> >> which I think is reasonable (modulo the security aspects). > > Are you agreeing or disagreeing with my authorization concerns? I don't > think they are just 'modulo' concern. No, they are not. And yes, I do agree with your authorization concerns. In a separate email thread, I propose using URI leasing to address some of the authorization concerns. I think we will need more discussion on that aspect to see if it is feasible or not. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 15:49:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20363; Mon, 14 Jul 2003 15:49:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c9Jn-0006f7-00; Mon, 14 Jul 2003 15:49:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c9Jm-0006f4-00; Mon, 14 Jul 2003 15:49:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9Jk-0005zY-OL; Mon, 14 Jul 2003 15:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9JF-0005z9-Ae for simple@optimus.ietf.org; Mon, 14 Jul 2003 15:48:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20301 for ; Mon, 14 Jul 2003 15:48:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c9JA-0006eT-00 for simple@ietf.org; Mon, 14 Jul 2003 15:48:24 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19c9J9-0006eN-00 for simple@ietf.org; Mon, 14 Jul 2003 15:48:23 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6EJmMkM003392; Mon, 14 Jul 2003 15:48:22 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6EJmLg01437; Mon, 14 Jul 2003 15:48:22 -0400 Message-ID: <3F13080F.4060706@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> In-Reply-To: <3F12CB84.7000902@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: rpids-01 - security and Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 15:44:15 -0400 Content-Transfer-Encoding: 7bit I think you are proposing effectively a 'ticket' (to use Kerberos terminology) where the ticket-granting agent (here, the boss Bob) grants access to the secretary Sam. I think this mostly works, particularly if this is encoded as a password, as in sam:848zcc85@example.com. The two drawbacks I can think of are - needs special support in secretary user agent; unless this is standardized, this isn't going to work in any usable way, while the "import" mechanism uses standard components that we already have. - extending permissions becomes an issue. If the secretary stays late, it is not really clear what should happen. The secretary will drop the external party since the permission expired, which is not what you want. The second is probably a smaller problem. The first one may be an example of a more general issue that might be usable elsewhere. (I can forward a call to a third party who will take the call since I "signed" it.) Vijay K. Gurbani wrote: > Is it possible to use URI leasing here and not worry about sharing > authorization lists? Example: Assume that Jane subscribe to Joe's > presence and is duly authorized to do so. Joe has a secretary, Bob, > whose tuple is in Joe's presence document. Bob's URI is a leased URI, > temporally scoped and dynamically generated. Only Jane who is > authorized to know Joe's presence can be privy to this leased URI. > The leased URI can be constructed in such a way as to make it hard > to replicate by accident (UUID?). > >> Even assuming this could work, this doesn't have the same >> functionality. For example, the secretary may only want to be visible >> to boss-permitted contacts from 9 to 5, but can't easily tell which >> contacts were authorized by the boss (so that the secretary can drop >> them at 5 and re-admit them at 9 the next day). > > > Contacts coming to the secretary through the leased URI will be > automatically accepted...? > > Is it worth pursuing this line of thought? Does it makes authorization > lists unneccessary? Just as I do not have a secretary, I am not a > security expert either :-) > >> If we can make these requirements for the authorization work, I'd be >> less concerned and Jonathan's suggestion would work well. >> >> The requirements are basically >> (1) allow multiple parties to edit the authorization list >> (2) the origin of each entry needs to be clear (who added it to the list) >> (3) updates and relationship for the same watcher by different >> updaters need to be clear (example: Secretary has Alice in her "good" >> list, but boss adds Alice as well; Alice shouldn't disappear from that >> list after 5 pm; whwat happens if there is a conflict?). > > > Thanks, > > - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 15:49:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20415 for ; Mon, 14 Jul 2003 15:49:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9Jr-000614-LN for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 15:49:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EJn7rZ023122 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 15:49:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9Jq-00060r-CR for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 15:49:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20363; Mon, 14 Jul 2003 15:49:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c9Jn-0006f7-00; Mon, 14 Jul 2003 15:49:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c9Jm-0006f4-00; Mon, 14 Jul 2003 15:49:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9Jk-0005zY-OL; Mon, 14 Jul 2003 15:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9JF-0005z9-Ae for simple@optimus.ietf.org; Mon, 14 Jul 2003 15:48:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20301 for ; Mon, 14 Jul 2003 15:48:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c9JA-0006eT-00 for simple@ietf.org; Mon, 14 Jul 2003 15:48:24 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19c9J9-0006eN-00 for simple@ietf.org; Mon, 14 Jul 2003 15:48:23 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6EJmMkM003392; Mon, 14 Jul 2003 15:48:22 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6EJmLg01437; Mon, 14 Jul 2003 15:48:22 -0400 Message-ID: <3F13080F.4060706@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> In-Reply-To: <3F12CB84.7000902@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: rpids-01 - security and Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 15:44:15 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think you are proposing effectively a 'ticket' (to use Kerberos terminology) where the ticket-granting agent (here, the boss Bob) grants access to the secretary Sam. I think this mostly works, particularly if this is encoded as a password, as in sam:848zcc85@example.com. The two drawbacks I can think of are - needs special support in secretary user agent; unless this is standardized, this isn't going to work in any usable way, while the "import" mechanism uses standard components that we already have. - extending permissions becomes an issue. If the secretary stays late, it is not really clear what should happen. The secretary will drop the external party since the permission expired, which is not what you want. The second is probably a smaller problem. The first one may be an example of a more general issue that might be usable elsewhere. (I can forward a call to a third party who will take the call since I "signed" it.) Vijay K. Gurbani wrote: > Is it possible to use URI leasing here and not worry about sharing > authorization lists? Example: Assume that Jane subscribe to Joe's > presence and is duly authorized to do so. Joe has a secretary, Bob, > whose tuple is in Joe's presence document. Bob's URI is a leased URI, > temporally scoped and dynamically generated. Only Jane who is > authorized to know Joe's presence can be privy to this leased URI. > The leased URI can be constructed in such a way as to make it hard > to replicate by accident (UUID?). > >> Even assuming this could work, this doesn't have the same >> functionality. For example, the secretary may only want to be visible >> to boss-permitted contacts from 9 to 5, but can't easily tell which >> contacts were authorized by the boss (so that the secretary can drop >> them at 5 and re-admit them at 9 the next day). > > > Contacts coming to the secretary through the leased URI will be > automatically accepted...? > > Is it worth pursuing this line of thought? Does it makes authorization > lists unneccessary? Just as I do not have a secretary, I am not a > security expert either :-) > >> If we can make these requirements for the authorization work, I'd be >> less concerned and Jonathan's suggestion would work well. >> >> The requirements are basically >> (1) allow multiple parties to edit the authorization list >> (2) the origin of each entry needs to be clear (who added it to the list) >> (3) updates and relationship for the same watcher by different >> updaters need to be clear (example: Secretary has Alice in her "good" >> list, but boss adds Alice as well; Alice shouldn't disappear from that >> list after 5 pm; whwat happens if there is a conflict?). > > > Thanks, > > - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 18:40:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02742; Mon, 14 Jul 2003 18:40:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cBzF-0000HZ-MT; Mon, 14 Jul 2003 18:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cByQ-0000Ga-Qs for simple@optimus.ietf.org; Mon, 14 Jul 2003 18:39:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02587 for ; Mon, 14 Jul 2003 18:39:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cByN-0001Xu-00 for simple@ietf.org; Mon, 14 Jul 2003 18:39:07 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19cByN-0001X5-00 for simple@ietf.org; Mon, 14 Jul 2003 18:39:07 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6EMcWw26238; Mon, 14 Jul 2003 17:38:32 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h6EMcVr10225; Mon, 14 Jul 2003 17:38:31 -0500 (CDT) Message-ID: <3F1330E3.8070407@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> <3F13080F.4060706@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 17:38:27 -0500 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > I think you are proposing effectively a 'ticket' (to use Kerberos > terminology) where the ticket-granting agent (here, the boss Bob) grants > access to the secretary Sam. Yes. > I think this mostly works, particularly if > this is encoded as a password, as in sam:848zcc85@example.com. > > The two drawbacks I can think of are > - needs special support in secretary user agent; unless this is > standardized, this isn't going to work in any usable way, while the > "import" mechanism uses standard components that we already have. I was afraid of the first drawback, and at least now don't have any more ideas besides standardizing something. Just to be sure, by "import" above you mean including the secretary's presence as a reference in the boss' presence document, right? If so, then we still have the authorization problem, no? > - extending permissions becomes an issue. If the secretary stays late, > it is not really clear what should happen. The secretary will drop the > external party since the permission expired, which is not what you > want. The second one, as you note is a smaller problem and can boil down to policy/business decisions. Even in real-world boss/secretary relationship, there will be a discrete set of calls deflected from the boss to the secretary that go unanswered (secretary gone for the day, on lunch, already on phone, ...) > The first one may be an example of a more general issue that might be > usable elsewhere. (I can forward a call to a third party who will take > the call since I "signed" it.) Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 18:41:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02806 for ; Mon, 14 Jul 2003 18:41:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cBzp-0000QR-CB for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 18:40:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EMebpP001631 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 18:40:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cBzp-0000QE-9N for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 18:40:37 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02742; Mon, 14 Jul 2003 18:40:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cBzF-0000HZ-MT; Mon, 14 Jul 2003 18:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cByQ-0000Ga-Qs for simple@optimus.ietf.org; Mon, 14 Jul 2003 18:39:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02587 for ; Mon, 14 Jul 2003 18:39:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cByN-0001Xu-00 for simple@ietf.org; Mon, 14 Jul 2003 18:39:07 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19cByN-0001X5-00 for simple@ietf.org; Mon, 14 Jul 2003 18:39:07 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6EMcWw26238; Mon, 14 Jul 2003 17:38:32 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h6EMcVr10225; Mon, 14 Jul 2003 17:38:31 -0500 (CDT) Message-ID: <3F1330E3.8070407@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> <3F13080F.4060706@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 17:38:27 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > I think you are proposing effectively a 'ticket' (to use Kerberos > terminology) where the ticket-granting agent (here, the boss Bob) grants > access to the secretary Sam. Yes. > I think this mostly works, particularly if > this is encoded as a password, as in sam:848zcc85@example.com. > > The two drawbacks I can think of are > - needs special support in secretary user agent; unless this is > standardized, this isn't going to work in any usable way, while the > "import" mechanism uses standard components that we already have. I was afraid of the first drawback, and at least now don't have any more ideas besides standardizing something. Just to be sure, by "import" above you mean including the secretary's presence as a reference in the boss' presence document, right? If so, then we still have the authorization problem, no? > - extending permissions becomes an issue. If the secretary stays late, > it is not really clear what should happen. The secretary will drop the > external party since the permission expired, which is not what you > want. The second one, as you note is a smaller problem and can boil down to policy/business decisions. Even in real-world boss/secretary relationship, there will be a discrete set of calls deflected from the boss to the secretary that go unanswered (secretary gone for the day, on lunch, already on phone, ...) > The first one may be an example of a more general issue that might be > usable elsewhere. (I can forward a call to a third party who will take > the call since I "signed" it.) Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 20:12:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08847; Mon, 14 Jul 2003 20:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDQK-0003A5-00; Mon, 14 Jul 2003 20:12:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cDQJ-0003A2-00; Mon, 14 Jul 2003 20:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDQH-0006SX-3I; Mon, 14 Jul 2003 20:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDPY-0006RI-RU for simple@optimus.ietf.org; Mon, 14 Jul 2003 20:11:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08835 for ; Mon, 14 Jul 2003 20:11:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDPW-00039T-00 for simple@ietf.org; Mon, 14 Jul 2003 20:11:14 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cDPV-000398-00 for simple@ietf.org; Mon, 14 Jul 2003 20:11:14 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6F0AliB009768; Mon, 14 Jul 2003 20:10:47 -0400 (EDT) Message-ID: <3F134682.80602@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: simple@ietf.org Subject: Re: [Simple] Date Formats References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEA@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEA@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:10:42 -0400 Content-Transfer-Encoding: 7bit Seems like it should be the SIP format. -Jonathan R. Adam Roach wrote: > RPIDS uses dates like PIDF: > > 2003-01-27T19:30:00Z > > While the XCAP event package uses HTTP dates: > > version="Mon, 26 May 2003 19:43:31 GMT" > > (presumably always expressed as GMT? It doesn't say > as much, and specifically cites HTTP instead of > SIP as its source; HTTP allows arbitrary time zones). > > Frankly, I don't relish having to keep straight > which format to use where. Would it be possible for > us, as a working group, to pick one format that > we use for bodies of new protocols going forward > and stick with it? > > /a > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 20:12:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08913 for ; Mon, 14 Jul 2003 20:12:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDQM-0006TA-Jc for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 20:12:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F0C6HO024865 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 20:12:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDQM-0006Sy-FQ for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 20:12:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08847; Mon, 14 Jul 2003 20:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDQK-0003A5-00; Mon, 14 Jul 2003 20:12:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cDQJ-0003A2-00; Mon, 14 Jul 2003 20:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDQH-0006SX-3I; Mon, 14 Jul 2003 20:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDPY-0006RI-RU for simple@optimus.ietf.org; Mon, 14 Jul 2003 20:11:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08835 for ; Mon, 14 Jul 2003 20:11:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDPW-00039T-00 for simple@ietf.org; Mon, 14 Jul 2003 20:11:14 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cDPV-000398-00 for simple@ietf.org; Mon, 14 Jul 2003 20:11:14 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6F0AliB009768; Mon, 14 Jul 2003 20:10:47 -0400 (EDT) Message-ID: <3F134682.80602@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: simple@ietf.org Subject: Re: [Simple] Date Formats References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEA@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEA@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:10:42 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Seems like it should be the SIP format. -Jonathan R. Adam Roach wrote: > RPIDS uses dates like PIDF: > > 2003-01-27T19:30:00Z > > While the XCAP event package uses HTTP dates: > > version="Mon, 26 May 2003 19:43:31 GMT" > > (presumably always expressed as GMT? It doesn't say > as much, and specifically cites HTTP instead of > SIP as its source; HTTP allows arbitrary time zones). > > Frankly, I don't relish having to keep straight > which format to use where. Would it be possible for > us, as a working group, to pick one format that > we use for bodies of new protocols going forward > and stick with it? > > /a > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 20:26:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10255; Mon, 14 Jul 2003 20:26:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDdr-0003Xo-00; Mon, 14 Jul 2003 20:26:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cDdq-0003Xl-00; Mon, 14 Jul 2003 20:26:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDdp-0007RQ-UT; Mon, 14 Jul 2003 20:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDcu-0007Qy-8b for simple@optimus.ietf.org; Mon, 14 Jul 2003 20:25:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10118 for ; Mon, 14 Jul 2003 20:25:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDcs-0003Vd-00 for simple@ietf.org; Mon, 14 Jul 2003 20:25:02 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cDcr-0003Ur-00 for simple@ietf.org; Mon, 14 Jul 2003 20:25:01 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6F0NfiB009778; Mon, 14 Jul 2003 20:23:43 -0400 (EDT) Message-ID: <3F134988.2080108@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Simple WG Subject: Re: [Simple] asking for a specific view References: <3F114AC6.1070002@dynamicsoft.com> <3F11788B.2020308@cs.columbia.edu> In-Reply-To: <3F11788B.2020308@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:23:36 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> It is possible that, by default, the PA would not provide information >> to the watcher in a device-centric view. Rather, its policy is to send >> a single tuple with summary information. If this happens, the watcher >> doesnt get the information they need, since its been aggregated away. >> To remedy this, I think we need to enhance the filter work to allow a >> watcher to ask for a specific view of the presence data. We have some >> work to do to define a view, but we have a couple of good candidates >> to work from. > > > Would this be as simple as being able to request certain columns (in my > database view of the world)? No. Its closer to what you were calling the pivot operation. But more importantly, it means that the attributes have values (and indeed exist) which are relevant for that particular view. For example, in a "device centric" view, things like whether the device is on or off, the placetype, geoloc, etc., make sense and have a well defined meaning. For other views, such as Brian's one-tuple view, there could also be a placetype and geoloc, but they might represent where the user is (based, perhaps, on a device which is almost always on the body of the person in question), as opposed to one of his devices. Adam writes: >> To remedy this, I think we need to enhance the filter work to allow a >> watcher to ask for a specific view of the presence data. We have some >> work to do to define a view, but we have a couple of good candidates >> to work from. > > I'm pretty certain that you're going to run into a lot of > situations in which presence cannot be broken down along > specific lines (like device or service views). For example, > presence information may arrive at a PA already partially (or even > fully) composed of information about multiple devices. You'll > also often run into situations in which composition is performed > as a means of intentional obscurity. Sure. You can't always deliver what the watcher wants. But at least we should be able to know what they want, and deliver it if possible, or we are permitted to. > > I'm not saying that your suggestion is bad, but I suspect > that we'll discover that the cases in which requests > for certain types of views make sense will be the exception > rather than the norm. Well, that remains to be seen. We don't have a lot of deployment experience to see how these things will get used. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 20:26:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10324 for ; Mon, 14 Jul 2003 20:26:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDdt-0007TB-QS for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 20:26:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F0Q5kW028707 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 20:26:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDdt-0007Sv-LM for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 20:26:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10255; Mon, 14 Jul 2003 20:26:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDdr-0003Xo-00; Mon, 14 Jul 2003 20:26:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cDdq-0003Xl-00; Mon, 14 Jul 2003 20:26:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDdp-0007RQ-UT; Mon, 14 Jul 2003 20:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDcu-0007Qy-8b for simple@optimus.ietf.org; Mon, 14 Jul 2003 20:25:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10118 for ; Mon, 14 Jul 2003 20:25:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDcs-0003Vd-00 for simple@ietf.org; Mon, 14 Jul 2003 20:25:02 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cDcr-0003Ur-00 for simple@ietf.org; Mon, 14 Jul 2003 20:25:01 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6F0NfiB009778; Mon, 14 Jul 2003 20:23:43 -0400 (EDT) Message-ID: <3F134988.2080108@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Simple WG Subject: Re: [Simple] asking for a specific view References: <3F114AC6.1070002@dynamicsoft.com> <3F11788B.2020308@cs.columbia.edu> In-Reply-To: <3F11788B.2020308@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:23:36 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> It is possible that, by default, the PA would not provide information >> to the watcher in a device-centric view. Rather, its policy is to send >> a single tuple with summary information. If this happens, the watcher >> doesnt get the information they need, since its been aggregated away. >> To remedy this, I think we need to enhance the filter work to allow a >> watcher to ask for a specific view of the presence data. We have some >> work to do to define a view, but we have a couple of good candidates >> to work from. > > > Would this be as simple as being able to request certain columns (in my > database view of the world)? No. Its closer to what you were calling the pivot operation. But more importantly, it means that the attributes have values (and indeed exist) which are relevant for that particular view. For example, in a "device centric" view, things like whether the device is on or off, the placetype, geoloc, etc., make sense and have a well defined meaning. For other views, such as Brian's one-tuple view, there could also be a placetype and geoloc, but they might represent where the user is (based, perhaps, on a device which is almost always on the body of the person in question), as opposed to one of his devices. Adam writes: >> To remedy this, I think we need to enhance the filter work to allow a >> watcher to ask for a specific view of the presence data. We have some >> work to do to define a view, but we have a couple of good candidates >> to work from. > > I'm pretty certain that you're going to run into a lot of > situations in which presence cannot be broken down along > specific lines (like device or service views). For example, > presence information may arrive at a PA already partially (or even > fully) composed of information about multiple devices. You'll > also often run into situations in which composition is performed > as a means of intentional obscurity. Sure. You can't always deliver what the watcher wants. But at least we should be able to know what they want, and deliver it if possible, or we are permitted to. > > I'm not saying that your suggestion is bad, but I suspect > that we'll discover that the cases in which requests > for certain types of views make sense will be the exception > rather than the norm. Well, that remains to be seen. We don't have a lot of deployment experience to see how these things will get used. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 20:28:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10477; Mon, 14 Jul 2003 20:28:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDfn-0003ax-00; Mon, 14 Jul 2003 20:28:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cDfm-0003au-00; Mon, 14 Jul 2003 20:28:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDfl-0007W6-0e; Mon, 14 Jul 2003 20:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDew-0007VJ-K8 for simple@optimus.ietf.org; Mon, 14 Jul 2003 20:27:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10387 for ; Mon, 14 Jul 2003 20:27:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDeu-0003ZK-00 for simple@ietf.org; Mon, 14 Jul 2003 20:27:08 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cDet-0003Yg-00 for simple@ietf.org; Mon, 14 Jul 2003 20:27:07 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6F0QQiB009781; Mon, 14 Jul 2003 20:26:27 -0400 (EDT) Message-ID: <3F134A2C.1050307@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Henning Schulzrinne , "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 (general, vCard, predictive) References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEB@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEB@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:26:20 -0400 Content-Transfer-Encoding: 7bit Adam Roach wrote: >>See GAIM above, albeit provided by the watcher, given the lack of >>protocol support. > > > I'm really going to have to agree strongly with Jon here. > Allowing the presentity to provide icons to represent any > kind of state -- and especially presence state -- is going > to result in nothing but an inscrutable mish-mash of angry > fruit salad in your buddy-list window. > > It would be a real black eye if all or even most SIMPLE-based > IM systems ended up being thematically similar to the typical > poorly-designed amateur web page that consists primarily of > jarringly mismatched graphics found elsewhere on the web. Why is a presentity supplied image fundamentally bad when a presentity supplied note is not? Both can be inaccurate, both can be too long, both can have garbage (one person I know routinely inserts seemingly random URIs to web pages he thinks are funny....). How is the media fundamentally changing things? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 20:28:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10545 for ; Mon, 14 Jul 2003 20:28:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDfq-0007ZY-3R for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 20:28:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F0S6PH029102 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 20:28:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDfq-0007ZJ-0E for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 20:28:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10477; Mon, 14 Jul 2003 20:28:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDfn-0003ax-00; Mon, 14 Jul 2003 20:28:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cDfm-0003au-00; Mon, 14 Jul 2003 20:28:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDfl-0007W6-0e; Mon, 14 Jul 2003 20:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDew-0007VJ-K8 for simple@optimus.ietf.org; Mon, 14 Jul 2003 20:27:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10387 for ; Mon, 14 Jul 2003 20:27:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDeu-0003ZK-00 for simple@ietf.org; Mon, 14 Jul 2003 20:27:08 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cDet-0003Yg-00 for simple@ietf.org; Mon, 14 Jul 2003 20:27:07 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6F0QQiB009781; Mon, 14 Jul 2003 20:26:27 -0400 (EDT) Message-ID: <3F134A2C.1050307@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Henning Schulzrinne , "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 (general, vCard, predictive) References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEB@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEB@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:26:20 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Adam Roach wrote: >>See GAIM above, albeit provided by the watcher, given the lack of >>protocol support. > > > I'm really going to have to agree strongly with Jon here. > Allowing the presentity to provide icons to represent any > kind of state -- and especially presence state -- is going > to result in nothing but an inscrutable mish-mash of angry > fruit salad in your buddy-list window. > > It would be a real black eye if all or even most SIMPLE-based > IM systems ended up being thematically similar to the typical > poorly-designed amateur web page that consists primarily of > jarringly mismatched graphics found elsewhere on the web. Why is a presentity supplied image fundamentally bad when a presentity supplied note is not? Both can be inaccurate, both can be too long, both can have garbage (one person I know routinely inserts seemingly random URIs to web pages he thinks are funny....). How is the media fundamentally changing things? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 20:37:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11454; Mon, 14 Jul 2003 20:37:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDoU-0003pI-00; Mon, 14 Jul 2003 20:37:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cDoT-0003pF-00; Mon, 14 Jul 2003 20:37:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDoS-00084g-Dn; Mon, 14 Jul 2003 20:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDne-000841-Rg for simple@optimus.ietf.org; Mon, 14 Jul 2003 20:36:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11376 for ; Mon, 14 Jul 2003 20:36:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDnc-0003nv-00 for simple@ietf.org; Mon, 14 Jul 2003 20:36:08 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cDnb-0003nC-00 for simple@ietf.org; Mon, 14 Jul 2003 20:36:07 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6F0ZYiB009785; Mon, 14 Jul 2003 20:35:35 -0400 (EDT) Message-ID: <3F134C50.7080603@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Simple WG Subject: Re: [Simple] comments on rpids-01 References: <3F116866.1090908@dynamicsoft.com> <3F117445.5080506@cs.columbia.edu> In-Reply-To: <3F117445.5080506@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:35:28 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > > >> I think it makes sense to define these within the pidf namespace. >> Thats what I did in the phone state draft. So, it would be: >> >> urn:ietf:params:xml:ns:pidf:sip-rpids >> >> However, as Jon had mentioned in his notes to the list, I think it >> makes more sense to perhaps break these up into groups of attributes, >> with differing namespaces for each. Namespaces are a very convenient >> way to group attributes, and to use for specifying filter and >> authorization policies. In xcap, we have permissions which allow for a >> watcher to see specific namespaces. > > > Agreed; but then you're contradicting yourself, i.e., they can't all be > in PIDF, yet be in separate namespaces. Which do people prefer? (The > schema currently keeps PIDF.) Sorry I am not being clear here. What I mean is, these namespaces should be within the pidf umbrella. The suggestion above is: urn:ietf:params:xml:ns:pidf:sip-rpids i.e., its an additional namespace component below pidf. Thus, they are all within different namespaces (..pidf:predictive, ..pidf:capabilities, etc.). >> >>> In-transit: The presentity is riding in a vehicle, such as a >>> car, but not steering. >> >> >> >> I think we might want more granularity here. I think there are useful >> distinctions between riding in a car and a plane, for example. So, I'd >> prefer to have a few vehicle-specific versions of this (obviously you >> need to draw the line somewhere, and I wouldnt include things like >> hovercraft or UFO...) > > > I've kept in-transit, as it allows generation by entities that don't > know (e.g., a GPS that just monitors speed) or for presentities who > prefer to keep their use of travel method private, but I'll add > In-transit-ship, -motorvehicle, -aircraft, -train, -spacecraft. (By the > time this draft gets to Full Standard, the latter will be a common mode > of transportation. Plus, it explains those long delays...) I'm not sure whether this was meant to be humorous or not... I do think its reasonable to have auto and plane, but clearly spaceship is a joke... > > >> >> >> >> Also, there is "headset" which says that the user is wearing their >> headset on their wireless phone. Its also a common wireless handset >> style that can be automatically derived. > > > Wouldn't this be an orthogonal item, as in > "in-transit-motorvehicle,headset"? Yes. I hadnt meant it to be part of the previous comment, sorry. > >> >>> 6.3 Card >>> >>> The element provides a URI pointing to a business card, e.g., >>> in LDIF or vCard format. >> >> >> >> Don't we need to mandate a particular format? > > > Why? The URI tells you how to retrieve it, the Content-Type what format > it is and content-negotiation lets the watcher and owner of the > information negotiate which format they both can deal with. After all, a > single (HTTP) URI can point to objects of many different content types, > languages, etc. OK, then I think we need to add mention that we are using http content negotiation (though I dont know if this exists in practice in web servers). More importantly, do we need a baseline mandatory-to-implement type? > > >> >>> 6.5 From Element >>> >>> The element indicates how long the current status has been >>> valid, expressed as an absolute time. >> >> >> >> Wouldnt it make sense to apply this to a particular attribute >> (placetype, activity, etc.) rather than to the status element as a whole? > > > I agree that this is maybe better phrased as an attribute. In some > cases, the whole tuple has been replaced at the time, so there > seems little point in marking each element with the same time. Is there > sufficient value in allowing different times for different elements? I'm > probably in favor, but this seems to get close to the line of adding > complexity with little practical benefit to the watcher, but significant > additional display complexity. To me, the time that the tuple changed is not interesting at all. I don't want to know that "something changes 2 minutes ago". Its much more useful for me to know that "you got on airplace 2 minutes ago" or, "you got home two minutes ago". > >> >> >>> 6.9 Type of Place Element >>> >>> The element describes the type of place the presentity is >>> currently at. This offers the watcher an indication what kind of >>> communication is likely to be appropriate. We define an initial set >>> of values below: >> >> >> >> >> Another one that appears on wireless handsets as a "style" is >> "Outdoors", which says that you are out and walking around. I think >> thats a useful one to add. > > > How does this differ from a 'public' place like a mall or park? We > already have public+quiet for the subset of public places where ringing > cell phones or chatting are inappropriate. It conveys some amount of information on the range of where a user might be. "public" and "mall" means you are within the physical boundaries of the mall, and perhaps I can look for you. "public" and "outdoors" means you could be on the streets of manhattan, a much different size place. I dont feel that strongly on this one. I suggested it primarily because it actually exists on phones I am aware of, and it would be nice to have a standard way of representing what exists today. -Jonathan R. >> You should register the schemas as well. This allows IANA to assign a >> stable URI that can be used in the schemaLocation attribute of import >> statements in schema declarations. > > > What's the operative format for registering schemas? > > > See the pidf-phone draft, which does it. Its really easy. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 20:37:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11514 for ; Mon, 14 Jul 2003 20:37:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDoX-00087f-8H for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 20:37:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F0b5YC031217 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 20:37:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDoX-00087Q-4B for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 20:37:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11454; Mon, 14 Jul 2003 20:37:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDoU-0003pI-00; Mon, 14 Jul 2003 20:37:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cDoT-0003pF-00; Mon, 14 Jul 2003 20:37:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDoS-00084g-Dn; Mon, 14 Jul 2003 20:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDne-000841-Rg for simple@optimus.ietf.org; Mon, 14 Jul 2003 20:36:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11376 for ; Mon, 14 Jul 2003 20:36:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDnc-0003nv-00 for simple@ietf.org; Mon, 14 Jul 2003 20:36:08 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cDnb-0003nC-00 for simple@ietf.org; Mon, 14 Jul 2003 20:36:07 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6F0ZYiB009785; Mon, 14 Jul 2003 20:35:35 -0400 (EDT) Message-ID: <3F134C50.7080603@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Simple WG Subject: Re: [Simple] comments on rpids-01 References: <3F116866.1090908@dynamicsoft.com> <3F117445.5080506@cs.columbia.edu> In-Reply-To: <3F117445.5080506@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:35:28 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > > >> I think it makes sense to define these within the pidf namespace. >> Thats what I did in the phone state draft. So, it would be: >> >> urn:ietf:params:xml:ns:pidf:sip-rpids >> >> However, as Jon had mentioned in his notes to the list, I think it >> makes more sense to perhaps break these up into groups of attributes, >> with differing namespaces for each. Namespaces are a very convenient >> way to group attributes, and to use for specifying filter and >> authorization policies. In xcap, we have permissions which allow for a >> watcher to see specific namespaces. > > > Agreed; but then you're contradicting yourself, i.e., they can't all be > in PIDF, yet be in separate namespaces. Which do people prefer? (The > schema currently keeps PIDF.) Sorry I am not being clear here. What I mean is, these namespaces should be within the pidf umbrella. The suggestion above is: urn:ietf:params:xml:ns:pidf:sip-rpids i.e., its an additional namespace component below pidf. Thus, they are all within different namespaces (..pidf:predictive, ..pidf:capabilities, etc.). >> >>> In-transit: The presentity is riding in a vehicle, such as a >>> car, but not steering. >> >> >> >> I think we might want more granularity here. I think there are useful >> distinctions between riding in a car and a plane, for example. So, I'd >> prefer to have a few vehicle-specific versions of this (obviously you >> need to draw the line somewhere, and I wouldnt include things like >> hovercraft or UFO...) > > > I've kept in-transit, as it allows generation by entities that don't > know (e.g., a GPS that just monitors speed) or for presentities who > prefer to keep their use of travel method private, but I'll add > In-transit-ship, -motorvehicle, -aircraft, -train, -spacecraft. (By the > time this draft gets to Full Standard, the latter will be a common mode > of transportation. Plus, it explains those long delays...) I'm not sure whether this was meant to be humorous or not... I do think its reasonable to have auto and plane, but clearly spaceship is a joke... > > >> >> >> >> Also, there is "headset" which says that the user is wearing their >> headset on their wireless phone. Its also a common wireless handset >> style that can be automatically derived. > > > Wouldn't this be an orthogonal item, as in > "in-transit-motorvehicle,headset"? Yes. I hadnt meant it to be part of the previous comment, sorry. > >> >>> 6.3 Card >>> >>> The element provides a URI pointing to a business card, e.g., >>> in LDIF or vCard format. >> >> >> >> Don't we need to mandate a particular format? > > > Why? The URI tells you how to retrieve it, the Content-Type what format > it is and content-negotiation lets the watcher and owner of the > information negotiate which format they both can deal with. After all, a > single (HTTP) URI can point to objects of many different content types, > languages, etc. OK, then I think we need to add mention that we are using http content negotiation (though I dont know if this exists in practice in web servers). More importantly, do we need a baseline mandatory-to-implement type? > > >> >>> 6.5 From Element >>> >>> The element indicates how long the current status has been >>> valid, expressed as an absolute time. >> >> >> >> Wouldnt it make sense to apply this to a particular attribute >> (placetype, activity, etc.) rather than to the status element as a whole? > > > I agree that this is maybe better phrased as an attribute. In some > cases, the whole tuple has been replaced at the time, so there > seems little point in marking each element with the same time. Is there > sufficient value in allowing different times for different elements? I'm > probably in favor, but this seems to get close to the line of adding > complexity with little practical benefit to the watcher, but significant > additional display complexity. To me, the time that the tuple changed is not interesting at all. I don't want to know that "something changes 2 minutes ago". Its much more useful for me to know that "you got on airplace 2 minutes ago" or, "you got home two minutes ago". > >> >> >>> 6.9 Type of Place Element >>> >>> The element describes the type of place the presentity is >>> currently at. This offers the watcher an indication what kind of >>> communication is likely to be appropriate. We define an initial set >>> of values below: >> >> >> >> >> Another one that appears on wireless handsets as a "style" is >> "Outdoors", which says that you are out and walking around. I think >> thats a useful one to add. > > > How does this differ from a 'public' place like a mall or park? We > already have public+quiet for the subset of public places where ringing > cell phones or chatting are inappropriate. It conveys some amount of information on the range of where a user might be. "public" and "mall" means you are within the physical boundaries of the mall, and perhaps I can look for you. "public" and "outdoors" means you could be on the streets of manhattan, a much different size place. I dont feel that strongly on this one. I suggested it primarily because it actually exists on phones I am aware of, and it would be nice to have a standard way of representing what exists today. -Jonathan R. >> You should register the schemas as well. This allows IANA to assign a >> stable URI that can be used in the schemaLocation attribute of import >> statements in schema declarations. > > > What's the operative format for registering schemas? > > > See the pidf-phone draft, which does it. Its really easy. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 20:46:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12316; Mon, 14 Jul 2003 20:46:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDxH-00042u-00; Mon, 14 Jul 2003 20:46:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cDxH-00042r-00; Mon, 14 Jul 2003 20:46:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDxC-0000Mj-2w; Mon, 14 Jul 2003 20:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDwl-0000MQ-2C for simple@optimus.ietf.org; Mon, 14 Jul 2003 20:45:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12241 for ; Mon, 14 Jul 2003 20:45:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDwi-00041i-00 for simple@ietf.org; Mon, 14 Jul 2003 20:45:32 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cDwg-00040p-00 for simple@ietf.org; Mon, 14 Jul 2003 20:45:30 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6F0iqiB009794; Mon, 14 Jul 2003 20:44:53 -0400 (EDT) Message-ID: <3F134E7E.7020409@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> <3F13080F.4060706@cs.columbia.edu> <3F1330E3.8070407@lucent.com> In-Reply-To: <3F1330E3.8070407@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:44:46 -0400 Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Henning Schulzrinne wrote: > >> I think you are proposing effectively a 'ticket' (to use Kerberos >> terminology) where the ticket-granting agent (here, the boss Bob) >> grants access to the secretary Sam. > > > Yes. > >> I think this mostly works, particularly if this is encoded as a >> password, as in sam:848zcc85@example.com. I like this approach alot. I had the same thought upon reading Henning's note, but Vijay beat me to posting the idea. >> >> The two drawbacks I can think of are > > > - needs special support in secretary user agent; unless this is > > standardized, this isn't going to work in any usable way, while the > > "import" mechanism uses standard components that we already have. > > I was afraid of the first drawback, and at least now don't > have any more ideas besides standardizing something. I don't quite follow Henning's concern. I don't see why the secretary's user agent per se cares. Presumably all of this is handled in the presence server. What it DOES require is that the presence server have a way to derive a composed document that properly includes this ticket/gruu, and has established authorization policies that are appropriate. I suspect that those policies would be adminstratively determined, so that the secretary in general would not need to do anything for this to work. BTW, this is a really good example of a complex presence transformation that is far beyond anything you can do with a SELECT kind of database operation. > > Just to be sure, by "import" above you mean including the > secretary's presence as a reference in the boss' presence document, > right? If so, then we still have the authorization problem, no? > > > - extending permissions becomes an issue. If the secretary stays late, > > it is not really clear what should happen. The secretary will drop the > > external party since the permission expired, which is not what you > > want. > > The second one, as you note is a smaller problem and can boil down > to policy/business decisions. Even in real-world boss/secretary > relationship, there will be a discrete set of calls deflected > from the boss to the secretary that go unanswered (secretary > gone for the day, on lunch, already on phone, ...) As I mention above, I suspect that there would be some basic policy that applies here. In fact, the "import" appraoch you have proposed, Henning, is identical to using a GRUU whose policy is: "the boss's authorization policy gets applied" to subscriptions to the gruu. The benefit of the gruu approach is that you CAN have other policies if someone desires. Doing so seems much easier than in the import case. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 20:46:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12377 for ; Mon, 14 Jul 2003 20:46:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDxK-0000OF-FS for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 20:46:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F0kAef001495 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 20:46:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDxK-0000O2-CU for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 20:46:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12316; Mon, 14 Jul 2003 20:46:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDxH-00042u-00; Mon, 14 Jul 2003 20:46:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cDxH-00042r-00; Mon, 14 Jul 2003 20:46:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDxC-0000Mj-2w; Mon, 14 Jul 2003 20:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDwl-0000MQ-2C for simple@optimus.ietf.org; Mon, 14 Jul 2003 20:45:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12241 for ; Mon, 14 Jul 2003 20:45:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDwi-00041i-00 for simple@ietf.org; Mon, 14 Jul 2003 20:45:32 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cDwg-00040p-00 for simple@ietf.org; Mon, 14 Jul 2003 20:45:30 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6F0iqiB009794; Mon, 14 Jul 2003 20:44:53 -0400 (EDT) Message-ID: <3F134E7E.7020409@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> <3F13080F.4060706@cs.columbia.edu> <3F1330E3.8070407@lucent.com> In-Reply-To: <3F1330E3.8070407@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:44:46 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Henning Schulzrinne wrote: > >> I think you are proposing effectively a 'ticket' (to use Kerberos >> terminology) where the ticket-granting agent (here, the boss Bob) >> grants access to the secretary Sam. > > > Yes. > >> I think this mostly works, particularly if this is encoded as a >> password, as in sam:848zcc85@example.com. I like this approach alot. I had the same thought upon reading Henning's note, but Vijay beat me to posting the idea. >> >> The two drawbacks I can think of are > > > - needs special support in secretary user agent; unless this is > > standardized, this isn't going to work in any usable way, while the > > "import" mechanism uses standard components that we already have. > > I was afraid of the first drawback, and at least now don't > have any more ideas besides standardizing something. I don't quite follow Henning's concern. I don't see why the secretary's user agent per se cares. Presumably all of this is handled in the presence server. What it DOES require is that the presence server have a way to derive a composed document that properly includes this ticket/gruu, and has established authorization policies that are appropriate. I suspect that those policies would be adminstratively determined, so that the secretary in general would not need to do anything for this to work. BTW, this is a really good example of a complex presence transformation that is far beyond anything you can do with a SELECT kind of database operation. > > Just to be sure, by "import" above you mean including the > secretary's presence as a reference in the boss' presence document, > right? If so, then we still have the authorization problem, no? > > > - extending permissions becomes an issue. If the secretary stays late, > > it is not really clear what should happen. The secretary will drop the > > external party since the permission expired, which is not what you > > want. > > The second one, as you note is a smaller problem and can boil down > to policy/business decisions. Even in real-world boss/secretary > relationship, there will be a discrete set of calls deflected > from the boss to the secretary that go unanswered (secretary > gone for the day, on lunch, already on phone, ...) As I mention above, I suspect that there would be some basic policy that applies here. In fact, the "import" appraoch you have proposed, Henning, is identical to using a GRUU whose policy is: "the boss's authorization policy gets applied" to subscriptions to the gruu. The benefit of the gruu approach is that you CAN have other policies if someone desires. Doing so seems much easier than in the import case. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 20:47:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12420; Mon, 14 Jul 2003 20:47:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDy8-00044L-00; Mon, 14 Jul 2003 20:47:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cDy7-00044I-00; Mon, 14 Jul 2003 20:46:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDy9-0000Qe-Md; Mon, 14 Jul 2003 20:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDxr-0000QD-Lz for simple@optimus.ietf.org; Mon, 14 Jul 2003 20:46:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12395 for ; Mon, 14 Jul 2003 20:46:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDxp-00043d-00 for simple@ietf.org; Mon, 14 Jul 2003 20:46:41 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cDxj-00042q-00 for simple@ietf.org; Mon, 14 Jul 2003 20:46:36 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6F0k3iB009797; Mon, 14 Jul 2003 20:46:03 -0400 (EDT) Message-ID: <3F134EC5.6050803@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Peterson, Jon" , simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - face-to-face References: <0449D80A0E9B614A83FA9031B07E8D3B257C1D@stntexch2.va.neustar.com> <3EFDB74A.7040707@cs.columbia.edu> <3F116087.5020701@dynamicsoft.com> <3F11681E.5000908@cs.columbia.edu> In-Reply-To: <3F11681E.5000908@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:45:57 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> >> >> Henning Schulzrinne wrote: >> >>> Agreed; tentatively added as 'mediated' parameter in to-be-revised >>> capabilities element, as in >>> >>> >> >> >> >> Does this mean it also becomes a callee-caps parameter as well? Not >> sure what it means in that context... > > > I don't think inheritance has to be mutual; this seems like an example > of something that makes sense in a tuple, but makes little sense in a > callee caps case. So, then why is it a capability at all? A capability is a capability, no matter whether its represented in a presence doc or in a URI parameter. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 20:47:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12484 for ; Mon, 14 Jul 2003 20:47:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDyC-0000UJ-Q7 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 20:47:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F0l49s001871 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 20:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDyB-0000SG-A2 for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 20:47:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12420; Mon, 14 Jul 2003 20:47:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDy8-00044L-00; Mon, 14 Jul 2003 20:47:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cDy7-00044I-00; Mon, 14 Jul 2003 20:46:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDy9-0000Qe-Md; Mon, 14 Jul 2003 20:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDxr-0000QD-Lz for simple@optimus.ietf.org; Mon, 14 Jul 2003 20:46:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12395 for ; Mon, 14 Jul 2003 20:46:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDxp-00043d-00 for simple@ietf.org; Mon, 14 Jul 2003 20:46:41 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cDxj-00042q-00 for simple@ietf.org; Mon, 14 Jul 2003 20:46:36 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6F0k3iB009797; Mon, 14 Jul 2003 20:46:03 -0400 (EDT) Message-ID: <3F134EC5.6050803@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Peterson, Jon" , simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - face-to-face References: <0449D80A0E9B614A83FA9031B07E8D3B257C1D@stntexch2.va.neustar.com> <3EFDB74A.7040707@cs.columbia.edu> <3F116087.5020701@dynamicsoft.com> <3F11681E.5000908@cs.columbia.edu> In-Reply-To: <3F11681E.5000908@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:45:57 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> >> >> Henning Schulzrinne wrote: >> >>> Agreed; tentatively added as 'mediated' parameter in to-be-revised >>> capabilities element, as in >>> >>> >> >> >> >> Does this mean it also becomes a callee-caps parameter as well? Not >> sure what it means in that context... > > > I don't think inheritance has to be mutual; this seems like an example > of something that makes sense in a tuple, but makes little sense in a > callee caps case. So, then why is it a capability at all? A capability is a capability, no matter whether its represented in a presence doc or in a URI parameter. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 20:49:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12649; Mon, 14 Jul 2003 20:49:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cE09-00047l-00; Mon, 14 Jul 2003 20:49:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cE08-00047i-00; Mon, 14 Jul 2003 20:49:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cE05-0000g6-KF; Mon, 14 Jul 2003 20:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDzP-0000fj-BL for simple@optimus.ietf.org; Mon, 14 Jul 2003 20:48:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12580 for ; Mon, 14 Jul 2003 20:48:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDzN-00046K-00 for simple@ietf.org; Mon, 14 Jul 2003 20:48:17 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cDzL-00045L-00 for simple@ietf.org; Mon, 14 Jul 2003 20:48:15 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6F0ldiB009800; Mon, 14 Jul 2003 20:47:40 -0400 (EDT) Message-ID: <3F134F25.9080304@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C54@stntexch2.va.neustar.com> <3F039C6B.3020305@cs.columbia.edu> <3F116046.3040707@dynamicsoft.com> <3F1167A8.3020203@cs.columbia.edu> In-Reply-To: <3F1167A8.3020203@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:47:33 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> I agree with Jon that something like is far more preferable >> than . Not only does this clearly delineate it from note, it >> makes it easier for an automata to do something useful with it (for >> example, add it to the "Homepages of My Friends" bookmark folder in my >> browser). says nothing about whats in there. >> > > I agree that anything with the word 'info' or INFO is probably suspect. > My hesitation with naming it 'homepage' is that other URI types that > don't point to a web page with your vacation pictures are also > appropriate there, such as an LDAP URI or whois URI. Well, those would be different. This is for homepages. I'm not saying that other things arent useful, I'm just saying that, since this information will be consumed by automata and not just rendered, we need to be as precise as possible about what it means. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 20:49:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12711 for ; Mon, 14 Jul 2003 20:49:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cE0C-0000jY-1p for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 20:49:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F0n8Lp002814 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 20:49:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cE0B-0000jJ-Uw for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 20:49:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12649; Mon, 14 Jul 2003 20:49:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cE09-00047l-00; Mon, 14 Jul 2003 20:49:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cE08-00047i-00; Mon, 14 Jul 2003 20:49:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cE05-0000g6-KF; Mon, 14 Jul 2003 20:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cDzP-0000fj-BL for simple@optimus.ietf.org; Mon, 14 Jul 2003 20:48:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12580 for ; Mon, 14 Jul 2003 20:48:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cDzN-00046K-00 for simple@ietf.org; Mon, 14 Jul 2003 20:48:17 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cDzL-00045L-00 for simple@ietf.org; Mon, 14 Jul 2003 20:48:15 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6F0ldiB009800; Mon, 14 Jul 2003 20:47:40 -0400 (EDT) Message-ID: <3F134F25.9080304@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C54@stntexch2.va.neustar.com> <3F039C6B.3020305@cs.columbia.edu> <3F116046.3040707@dynamicsoft.com> <3F1167A8.3020203@cs.columbia.edu> In-Reply-To: <3F1167A8.3020203@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:47:33 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> I agree with Jon that something like is far more preferable >> than . Not only does this clearly delineate it from note, it >> makes it easier for an automata to do something useful with it (for >> example, add it to the "Homepages of My Friends" bookmark folder in my >> browser). says nothing about whats in there. >> > > I agree that anything with the word 'info' or INFO is probably suspect. > My hesitation with naming it 'homepage' is that other URI types that > don't point to a web page with your vacation pictures are also > appropriate there, such as an LDAP URI or whois URI. Well, those would be different. This is for homepages. I'm not saying that other things arent useful, I'm just saying that, since this information will be consumed by automata and not just rendered, we need to be as precise as possible about what it means. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 14 20:52:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12926; Mon, 14 Jul 2003 20:52:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cE30-0004BZ-00; Mon, 14 Jul 2003 20:52:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cE30-0004BW-00; Mon, 14 Jul 2003 20:52:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cE2z-0000mS-Hg; Mon, 14 Jul 2003 20:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cE2n-0000mH-QN for simple@optimus.ietf.org; Mon, 14 Jul 2003 20:51:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12914 for ; Mon, 14 Jul 2003 20:51:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cE2l-0004BP-00 for simple@ietf.org; Mon, 14 Jul 2003 20:51:47 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cE2k-0004Aq-00 for simple@ietf.org; Mon, 14 Jul 2003 20:51:46 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6F0pIiB009804; Mon, 14 Jul 2003 20:51:19 -0400 (EDT) Message-ID: <3F135001.9040206@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Robert Sparks , simple@ietf.org Subject: Re: [Simple] Tuple design team discussion summary References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:51:13 -0400 Content-Transfer-Encoding: 7bit inline. Adam Roach wrote: > Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > > > So, I think there is value in having an RPIDS attribute which conveys > > some kind of information about what the tuple represents. We > > can start > > with a basic set of types: > > > > "cell phone" > > "PDA" > > "wireline phone" > > "IM service" > > It's not clear that tuples can always be classified as > something this concrete, though. What if I want to publish > a single tuple that represents an amalgamation of my presence > status, for example? Two tuples, with one representing my > "work" devices, and one representing my "personal" devices? We can either add that to the list of labels now, or it gets added through a registry. > > I think one of the important drivers behind not mandating > a particular binding of a tuple to something like a device > is that doing so provides infinite flexibility in publishing > information. It seems that having a canonical (even if > expandable) set of blessed "types" of tuples will restrict > this flexibility unnecessarily. Unlimited flexibility can also lead to interoperability problems, and this is the essence of what Brian has been complaining about, I think. Its not all or nothing. There is a reasonable point of compromise where we allow some flexibility but introduce some constraints. Finding that right point is what engineering is all about. I think that we can standardize a bunch of labels which cover a lot of common cases. If someone wants to send a presence document with a tuple outside of one of those categories - fine. Don't use the label. But, it may not be handled well on a device that can't display anything to the user except an iconic representation of that label. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 14 20:52:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12950 for ; Mon, 14 Jul 2003 20:52:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cE33-0000pr-Cs for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 20:52:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F0q51J003208 for simple-archive@odin.ietf.org; Mon, 14 Jul 2003 20:52:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cE33-0000pf-A9 for simple-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 20:52:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12926; Mon, 14 Jul 2003 20:52:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cE30-0004BZ-00; Mon, 14 Jul 2003 20:52:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cE30-0004BW-00; Mon, 14 Jul 2003 20:52:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cE2z-0000mS-Hg; Mon, 14 Jul 2003 20:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cE2n-0000mH-QN for simple@optimus.ietf.org; Mon, 14 Jul 2003 20:51:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12914 for ; Mon, 14 Jul 2003 20:51:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cE2l-0004BP-00 for simple@ietf.org; Mon, 14 Jul 2003 20:51:47 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cE2k-0004Aq-00 for simple@ietf.org; Mon, 14 Jul 2003 20:51:46 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6F0pIiB009804; Mon, 14 Jul 2003 20:51:19 -0400 (EDT) Message-ID: <3F135001.9040206@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Robert Sparks , simple@ietf.org Subject: Re: [Simple] Tuple design team discussion summary References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 14 Jul 2003 20:51:13 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Adam Roach wrote: > Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > > > So, I think there is value in having an RPIDS attribute which conveys > > some kind of information about what the tuple represents. We > > can start > > with a basic set of types: > > > > "cell phone" > > "PDA" > > "wireline phone" > > "IM service" > > It's not clear that tuples can always be classified as > something this concrete, though. What if I want to publish > a single tuple that represents an amalgamation of my presence > status, for example? Two tuples, with one representing my > "work" devices, and one representing my "personal" devices? We can either add that to the list of labels now, or it gets added through a registry. > > I think one of the important drivers behind not mandating > a particular binding of a tuple to something like a device > is that doing so provides infinite flexibility in publishing > information. It seems that having a canonical (even if > expandable) set of blessed "types" of tuples will restrict > this flexibility unnecessarily. Unlimited flexibility can also lead to interoperability problems, and this is the essence of what Brian has been complaining about, I think. Its not all or nothing. There is a reasonable point of compromise where we allow some flexibility but introduce some constraints. Finding that right point is what engineering is all about. I think that we can standardize a bunch of labels which cover a lot of common cases. If someone wants to send a presence document with a tuple outside of one of those categories - fine. Don't use the label. But, it may not be handled well on a device that can't display anything to the user except an iconic representation of that label. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 03:12:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27799; Tue, 15 Jul 2003 03:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cJyn-0004nX-00; Tue, 15 Jul 2003 03:12:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cJym-0004nU-00; Tue, 15 Jul 2003 03:12:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cJyi-00021v-MU; Tue, 15 Jul 2003 03:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cJxl-0001v8-Qm for simple@optimus.ietf.org; Tue, 15 Jul 2003 03:11:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27771 for ; Tue, 15 Jul 2003 03:10:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cJxh-0004mz-00 for simple@ietf.org; Tue, 15 Jul 2003 03:10:57 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19cJxh-0004ml-00 for simple@ietf.org; Tue, 15 Jul 2003 03:10:57 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA28184; Tue, 15 Jul 2003 03:10:27 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA09876; Tue, 15 Jul 2003 03:10:27 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MTFQ3>; Tue, 15 Jul 2003 03:10:27 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5BEF@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , Adam Roach Cc: Robert Sparks , simple@ietf.org Subject: RE: [Simple] Tuple design team discussion summary MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 03:10:18 -0400 > Unlimited flexibility can also lead to interoperability problems, and > this is the essence of what Brian has been complaining about, > I think. > Its not all or nothing. There is a reasonable point of compromise > where we allow some flexibility but introduce some constraints. > Finding that right point is what engineering is all about. > > I think that we can standardize a bunch of labels which cover > a lot of > common cases. If someone wants to send a presence document with a > tuple outside of one of those categories - fine. Don't use the label. > But, it may not be handled well on a device that can't display > anything to the user except an iconic representation of that label. Yes! It also works for an aggregator, who may be able to take, say both device and "service" labeled views and produce a meaningful composite view. For example, it could (assuming a reasonable definition of "service", provide a composite service view, or my user view. If the aggregator was asked to provide a device view, it would not be able to fully comply because it doesn't have the device views from the service view source. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 03:12:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27868 for ; Tue, 15 Jul 2003 03:12:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cJyq-00022h-Pz for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 03:12:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F7C8ie007849 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 03:12:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cJyq-00022W-Ap for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 03:12:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27799; Tue, 15 Jul 2003 03:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cJyn-0004nX-00; Tue, 15 Jul 2003 03:12:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cJym-0004nU-00; Tue, 15 Jul 2003 03:12:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cJyi-00021v-MU; Tue, 15 Jul 2003 03:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cJxl-0001v8-Qm for simple@optimus.ietf.org; Tue, 15 Jul 2003 03:11:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27771 for ; Tue, 15 Jul 2003 03:10:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cJxh-0004mz-00 for simple@ietf.org; Tue, 15 Jul 2003 03:10:57 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19cJxh-0004ml-00 for simple@ietf.org; Tue, 15 Jul 2003 03:10:57 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA28184; Tue, 15 Jul 2003 03:10:27 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA09876; Tue, 15 Jul 2003 03:10:27 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MTFQ3>; Tue, 15 Jul 2003 03:10:27 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5BEF@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , Adam Roach Cc: Robert Sparks , simple@ietf.org Subject: RE: [Simple] Tuple design team discussion summary MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 03:10:18 -0400 > Unlimited flexibility can also lead to interoperability problems, and > this is the essence of what Brian has been complaining about, > I think. > Its not all or nothing. There is a reasonable point of compromise > where we allow some flexibility but introduce some constraints. > Finding that right point is what engineering is all about. > > I think that we can standardize a bunch of labels which cover > a lot of > common cases. If someone wants to send a presence document with a > tuple outside of one of those categories - fine. Don't use the label. > But, it may not be handled well on a device that can't display > anything to the user except an iconic representation of that label. Yes! It also works for an aggregator, who may be able to take, say both device and "service" labeled views and produce a meaningful composite view. For example, it could (assuming a reasonable definition of "service", provide a composite service view, or my user view. If the aggregator was asked to provide a device view, it would not be able to fully comply because it doesn't have the device views from the service view source. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 04:30:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04170; Tue, 15 Jul 2003 04:30:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLCI-0006Mr-00; Tue, 15 Jul 2003 04:30:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLCH-0006Mn-00; Tue, 15 Jul 2003 04:30:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLCD-0006x1-Gj; Tue, 15 Jul 2003 04:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLBb-0006vr-Nb for simple@optimus.ietf.org; Tue, 15 Jul 2003 04:29:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04097 for ; Tue, 15 Jul 2003 04:29:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLBY-0006LA-00 for simple@ietf.org; Tue, 15 Jul 2003 04:29:20 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19cLBX-0006Ki-00 for simple@ietf.org; Tue, 15 Jul 2003 04:29:19 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h6F8T1bl041121; Tue, 15 Jul 2003 03:29:07 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] Tuple design team discussion summary From: Ben Campbell To: Jonathan Rosenberg Cc: Adam Roach , Robert Sparks , Simple WG In-Reply-To: <3F135001.9040206@dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> <3F135001.9040206@dynamicsoft.com> Content-Type: text/plain Message-Id: <1058257541.2536.7.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Jul 2003 03:25:42 -0500 Content-Transfer-Encoding: 7bit On Mon, 2003-07-14 at 19:51, Jonathan Rosenberg wrote: [...] > I think that we can standardize a bunch of labels which cover a lot of > common cases. If someone wants to send a presence document with a > tuple outside of one of those categories - fine. Don't use the label. > But, it may not be handled well on a device that can't display > anything to the user except an iconic representation of that label. > I think even that can be handled cleanly. Such a device just displays some default icon that indicates it does not know what type of tuple it has. That is no different from common usage in many other applications. For example, email attachments when your browser does not recognize the mime type, or gets something completely generic like application/octet-stream without any other qualifiers. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 04:30:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04272 for ; Tue, 15 Jul 2003 04:30:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLCM-00073q-LE for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 04:30:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F8UAG6027141 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 04:30:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLCM-00073g-Gv for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 04:30:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04170; Tue, 15 Jul 2003 04:30:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLCI-0006Mr-00; Tue, 15 Jul 2003 04:30:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLCH-0006Mn-00; Tue, 15 Jul 2003 04:30:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLCD-0006x1-Gj; Tue, 15 Jul 2003 04:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLBb-0006vr-Nb for simple@optimus.ietf.org; Tue, 15 Jul 2003 04:29:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04097 for ; Tue, 15 Jul 2003 04:29:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLBY-0006LA-00 for simple@ietf.org; Tue, 15 Jul 2003 04:29:20 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19cLBX-0006Ki-00 for simple@ietf.org; Tue, 15 Jul 2003 04:29:19 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h6F8T1bl041121; Tue, 15 Jul 2003 03:29:07 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] Tuple design team discussion summary From: Ben Campbell To: Jonathan Rosenberg Cc: Adam Roach , Robert Sparks , Simple WG In-Reply-To: <3F135001.9040206@dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> <3F135001.9040206@dynamicsoft.com> Content-Type: text/plain Message-Id: <1058257541.2536.7.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Jul 2003 03:25:42 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2003-07-14 at 19:51, Jonathan Rosenberg wrote: [...] > I think that we can standardize a bunch of labels which cover a lot of > common cases. If someone wants to send a presence document with a > tuple outside of one of those categories - fine. Don't use the label. > But, it may not be handled well on a device that can't display > anything to the user except an iconic representation of that label. > I think even that can be handled cleanly. Such a device just displays some default icon that indicates it does not know what type of tuple it has. That is no different from common usage in many other applications. For example, email attachments when your browser does not recognize the mime type, or gets something completely generic like application/octet-stream without any other qualifiers. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 04:36:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04836; Tue, 15 Jul 2003 04:36:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLI6-0006XV-00; Tue, 15 Jul 2003 04:36:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLI5-0006XS-00; Tue, 15 Jul 2003 04:36:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLI1-0007Yg-Bv; Tue, 15 Jul 2003 04:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLH5-0007WC-OK for simple@optimus.ietf.org; Tue, 15 Jul 2003 04:35:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04729 for ; Tue, 15 Jul 2003 04:34:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLH2-0006VV-00 for simple@ietf.org; Tue, 15 Jul 2003 04:35:00 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cLH2-0006VR-00 for simple@ietf.org; Tue, 15 Jul 2003 04:35:00 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6F8Z0kM020495; Tue, 15 Jul 2003 04:35:00 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6F8Yxg07630; Tue, 15 Jul 2003 04:34:59 -0400 Message-ID: <3F13BBBB.7020701@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Adam Roach , simple@ietf.org Subject: Re: [Simple] Date Formats References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEA@dyn-tx-exch-001.dynamicsoft.com> <3F134682.80602@dynamicsoft.com> In-Reply-To: <3F134682.80602@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 04:30:51 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Seems like it should be the SIP format. Except in XML, where it really can't be, if you would like to use schemas. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 04:36:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04890 for ; Tue, 15 Jul 2003 04:36:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLIA-0007eR-8b for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 04:36:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F8aAtw029405 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 04:36:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLIA-0007eC-1C for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 04:36:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04836; Tue, 15 Jul 2003 04:36:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLI6-0006XV-00; Tue, 15 Jul 2003 04:36:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLI5-0006XS-00; Tue, 15 Jul 2003 04:36:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLI1-0007Yg-Bv; Tue, 15 Jul 2003 04:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLH5-0007WC-OK for simple@optimus.ietf.org; Tue, 15 Jul 2003 04:35:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04729 for ; Tue, 15 Jul 2003 04:34:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLH2-0006VV-00 for simple@ietf.org; Tue, 15 Jul 2003 04:35:00 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cLH2-0006VR-00 for simple@ietf.org; Tue, 15 Jul 2003 04:35:00 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6F8Z0kM020495; Tue, 15 Jul 2003 04:35:00 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6F8Yxg07630; Tue, 15 Jul 2003 04:34:59 -0400 Message-ID: <3F13BBBB.7020701@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Adam Roach , simple@ietf.org Subject: Re: [Simple] Date Formats References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEA@dyn-tx-exch-001.dynamicsoft.com> <3F134682.80602@dynamicsoft.com> In-Reply-To: <3F134682.80602@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 04:30:51 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Seems like it should be the SIP format. Except in XML, where it really can't be, if you would like to use schemas. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 04:43:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05403; Tue, 15 Jul 2003 04:43:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLOw-0006gB-00; Tue, 15 Jul 2003 04:43:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLOv-0006g8-00; Tue, 15 Jul 2003 04:43:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLOo-0008AD-CA; Tue, 15 Jul 2003 04:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLOK-00089n-QM for simple@optimus.ietf.org; Tue, 15 Jul 2003 04:42:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05329 for ; Tue, 15 Jul 2003 04:42:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLOH-0006f8-00 for simple@ietf.org; Tue, 15 Jul 2003 04:42:29 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cLOH-0006f5-00 for simple@ietf.org; Tue, 15 Jul 2003 04:42:29 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6F8gTkM020915; Tue, 15 Jul 2003 04:42:29 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6F8gTg08713; Tue, 15 Jul 2003 04:42:29 -0400 Message-ID: <3F13BD7D.409@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] Tuple design team discussion summary References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> <3F135001.9040206@dynamicsoft.com> <1058257541.2536.7.camel@verite.localdomain> In-Reply-To: <1058257541.2536.7.camel@verite.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 04:38:21 -0400 Content-Transfer-Encoding: 7bit Almost none of the labels in RPIDS are exhaustive or claim to be, so a list is better than nothing. To make progress, I would like to call for nominations for such labels. The obvious ones are device-oriented ones cell phone PC landline phone text device (BlackBerry, SMS, TTY, ...) other suggestions? Ben Campbell wrote: > > I think even that can be handled cleanly. Such a device just displays > some default icon that indicates it does not know what type of tuple it > has. That is no different from common usage in many other applications. > For example, email attachments when your browser does not recognize the > mime type, or gets something completely generic like > application/octet-stream without any other qualifiers. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 04:43:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05472 for ; Tue, 15 Jul 2003 04:43:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLP0-0008EB-I1 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 04:43:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F8hEnr031626 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 04:43:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLP0-0008E1-7h for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 04:43:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05403; Tue, 15 Jul 2003 04:43:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLOw-0006gB-00; Tue, 15 Jul 2003 04:43:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLOv-0006g8-00; Tue, 15 Jul 2003 04:43:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLOo-0008AD-CA; Tue, 15 Jul 2003 04:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLOK-00089n-QM for simple@optimus.ietf.org; Tue, 15 Jul 2003 04:42:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05329 for ; Tue, 15 Jul 2003 04:42:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLOH-0006f8-00 for simple@ietf.org; Tue, 15 Jul 2003 04:42:29 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cLOH-0006f5-00 for simple@ietf.org; Tue, 15 Jul 2003 04:42:29 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6F8gTkM020915; Tue, 15 Jul 2003 04:42:29 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6F8gTg08713; Tue, 15 Jul 2003 04:42:29 -0400 Message-ID: <3F13BD7D.409@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] Tuple design team discussion summary References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> <3F135001.9040206@dynamicsoft.com> <1058257541.2536.7.camel@verite.localdomain> In-Reply-To: <1058257541.2536.7.camel@verite.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 04:38:21 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Almost none of the labels in RPIDS are exhaustive or claim to be, so a list is better than nothing. To make progress, I would like to call for nominations for such labels. The obvious ones are device-oriented ones cell phone PC landline phone text device (BlackBerry, SMS, TTY, ...) other suggestions? Ben Campbell wrote: > > I think even that can be handled cleanly. Such a device just displays > some default icon that indicates it does not know what type of tuple it > has. That is no different from common usage in many other applications. > For example, email attachments when your browser does not recognize the > mime type, or gets something completely generic like > application/octet-stream without any other qualifiers. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 04:46:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05821; Tue, 15 Jul 2003 04:46:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLRy-0006mU-00; Tue, 15 Jul 2003 04:46:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLRx-0006mR-00; Tue, 15 Jul 2003 04:46:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLRh-0008OU-Ti; Tue, 15 Jul 2003 04:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLRK-0008Ng-7r for simple@optimus.ietf.org; Tue, 15 Jul 2003 04:45:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05714 for ; Tue, 15 Jul 2003 04:45:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLRH-0006kp-00 for simple@ietf.org; Tue, 15 Jul 2003 04:45:35 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19cLRG-0006km-00 for simple@ietf.org; Tue, 15 Jul 2003 04:45:34 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h6F8jDbl042274; Tue, 15 Jul 2003 03:45:14 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] asking for a specific view From: Ben Campbell To: Jonathan Rosenberg Cc: Henning Schulzrinne , Simple WG In-Reply-To: <3F134988.2080108@dynamicsoft.com> References: <3F114AC6.1070002@dynamicsoft.com> <3F11788B.2020308@cs.columbia.edu> <3F134988.2080108@dynamicsoft.com> Content-Type: text/plain Message-Id: <1058258501.2536.14.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Jul 2003 03:41:41 -0500 Content-Transfer-Encoding: 7bit On Mon, 2003-07-14 at 19:23, Jonathan Rosenberg wrote: > Henning Schulzrinne wrote: > > > Jonathan Rosenberg wrote: > > > >> It is possible that, by default, the PA would not provide information > >> to the watcher in a device-centric view. Rather, its policy is to send > >> a single tuple with summary information. If this happens, the watcher > >> doesnt get the information they need, since its been aggregated away. > >> To remedy this, I think we need to enhance the filter work to allow a > >> watcher to ask for a specific view of the presence data. We have some > >> work to do to define a view, but we have a couple of good candidates > >> to work from. > > > > > > Would this be as simple as being able to request certain columns (in my > > database view of the world)? > > No. Its closer to what you were calling the pivot operation. But more > importantly, it means that the attributes have values (and indeed > exist) which are relevant for that particular view. For example, in a > "device centric" view, things like whether the device is on or off, > the placetype, geoloc, etc., make sense and have a well defined > meaning. For other views, such as Brian's one-tuple view, there could > also be a placetype and geoloc, but they might represent where the > user is (based, perhaps, on a device which is almost always on the > body of the person in question), as opposed to one of his devices. > > Adam writes: > >> To remedy this, I think we need to enhance the filter work to allow a > >> watcher to ask for a specific view of the presence data. We have some > >> work to do to define a view, but we have a couple of good candidates > >> to work from. > > > > I'm pretty certain that you're going to run into a lot of > > situations in which presence cannot be broken down along > > specific lines (like device or service views). For example, > > presence information may arrive at a PA already partially (or even > > fully) composed of information about multiple devices. You'll > > also often run into situations in which composition is performed > > as a means of intentional obscurity. > > Sure. You can't always deliver what the watcher wants. But at least we > should be able to know what they want, and deliver it if possible, or > we are permitted to. I would state this more strongly, in that the PA has complete control over what it delivers. Such a request is at best a hint of watcher preference. But in general, the PA is an agent of the presentity, and is not obligated to care about the preferences of a watcher. Anything beyond that is in conflict with one of the most useful attributes of SIP, that is, the owner of a resource has controls how and where calls are delivered. Or in more practical terms, a watcher implementation MUST NOT assume its preferences will be honored. > > > > > I'm not saying that your suggestion is bad, but I suspect > > that we'll discover that the cases in which requests > > for certain types of views make sense will be the exception > > rather than the norm. > > Well, that remains to be seen. We don't have a lot of deployment > experience to see how these things will get used. > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 04:46:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05869 for ; Tue, 15 Jul 2003 04:46:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLS2-0008S4-QL for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 04:46:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F8kMPD032487 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 04:46:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLS1-0008Ru-R2 for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 04:46:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05821; Tue, 15 Jul 2003 04:46:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLRy-0006mU-00; Tue, 15 Jul 2003 04:46:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLRx-0006mR-00; Tue, 15 Jul 2003 04:46:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLRh-0008OU-Ti; Tue, 15 Jul 2003 04:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLRK-0008Ng-7r for simple@optimus.ietf.org; Tue, 15 Jul 2003 04:45:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05714 for ; Tue, 15 Jul 2003 04:45:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLRH-0006kp-00 for simple@ietf.org; Tue, 15 Jul 2003 04:45:35 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19cLRG-0006km-00 for simple@ietf.org; Tue, 15 Jul 2003 04:45:34 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h6F8jDbl042274; Tue, 15 Jul 2003 03:45:14 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] asking for a specific view From: Ben Campbell To: Jonathan Rosenberg Cc: Henning Schulzrinne , Simple WG In-Reply-To: <3F134988.2080108@dynamicsoft.com> References: <3F114AC6.1070002@dynamicsoft.com> <3F11788B.2020308@cs.columbia.edu> <3F134988.2080108@dynamicsoft.com> Content-Type: text/plain Message-Id: <1058258501.2536.14.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Jul 2003 03:41:41 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2003-07-14 at 19:23, Jonathan Rosenberg wrote: > Henning Schulzrinne wrote: > > > Jonathan Rosenberg wrote: > > > >> It is possible that, by default, the PA would not provide information > >> to the watcher in a device-centric view. Rather, its policy is to send > >> a single tuple with summary information. If this happens, the watcher > >> doesnt get the information they need, since its been aggregated away. > >> To remedy this, I think we need to enhance the filter work to allow a > >> watcher to ask for a specific view of the presence data. We have some > >> work to do to define a view, but we have a couple of good candidates > >> to work from. > > > > > > Would this be as simple as being able to request certain columns (in my > > database view of the world)? > > No. Its closer to what you were calling the pivot operation. But more > importantly, it means that the attributes have values (and indeed > exist) which are relevant for that particular view. For example, in a > "device centric" view, things like whether the device is on or off, > the placetype, geoloc, etc., make sense and have a well defined > meaning. For other views, such as Brian's one-tuple view, there could > also be a placetype and geoloc, but they might represent where the > user is (based, perhaps, on a device which is almost always on the > body of the person in question), as opposed to one of his devices. > > Adam writes: > >> To remedy this, I think we need to enhance the filter work to allow a > >> watcher to ask for a specific view of the presence data. We have some > >> work to do to define a view, but we have a couple of good candidates > >> to work from. > > > > I'm pretty certain that you're going to run into a lot of > > situations in which presence cannot be broken down along > > specific lines (like device or service views). For example, > > presence information may arrive at a PA already partially (or even > > fully) composed of information about multiple devices. You'll > > also often run into situations in which composition is performed > > as a means of intentional obscurity. > > Sure. You can't always deliver what the watcher wants. But at least we > should be able to know what they want, and deliver it if possible, or > we are permitted to. I would state this more strongly, in that the PA has complete control over what it delivers. Such a request is at best a hint of watcher preference. But in general, the PA is an agent of the presentity, and is not obligated to care about the preferences of a watcher. Anything beyond that is in conflict with one of the most useful attributes of SIP, that is, the owner of a resource has controls how and where calls are delivered. Or in more practical terms, a watcher implementation MUST NOT assume its preferences will be honored. > > > > > I'm not saying that your suggestion is bad, but I suspect > > that we'll discover that the cases in which requests > > for certain types of views make sense will be the exception > > rather than the norm. > > Well, that remains to be seen. We don't have a lot of deployment > experience to see how these things will get used. > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 04:58:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06699; Tue, 15 Jul 2003 04:58:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLdL-000715-00; Tue, 15 Jul 2003 04:58:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLdL-000712-00; Tue, 15 Jul 2003 04:58:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLdJ-0000FD-02; Tue, 15 Jul 2003 04:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLd3-0000Ej-4P for simple@optimus.ietf.org; Tue, 15 Jul 2003 04:57:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06661 for ; Tue, 15 Jul 2003 04:57:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLd0-00070N-00 for simple@ietf.org; Tue, 15 Jul 2003 04:57:42 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19cLcy-000708-00 for simple@ietf.org; Tue, 15 Jul 2003 04:57:41 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h6F8vabl043350; Tue, 15 Jul 2003 03:57:38 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] Tuple design team discussion summary From: Ben Campbell To: Henning Schulzrinne Cc: Simple WG In-Reply-To: <3F13BD7D.409@cs.columbia.edu> References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> <3F135001.9040206@dynamicsoft.com> <1058257541.2536.7.camel@verite.localdomain> <3F13BD7D.409@cs.columbia.edu> Content-Type: text/plain Message-Id: <1058259234.2536.27.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Jul 2003 03:53:55 -0500 Content-Transfer-Encoding: 7bit Hopefully we can generalize these a bit. For example: voice device Mobile voice device Fixed voice device Workstation (or some sort of rich media device) text device short text device (i.e. don't send me big stuff) This list seems to me to break down to a few dimensions: Mobility Media stream/message orientation Size limits Which sound a lot like capabilities to me. On Tue, 2003-07-15 at 03:38, Henning Schulzrinne wrote: > Almost none of the labels in RPIDS are exhaustive or claim to be, so a > list is better than nothing. To make progress, I would like to call for > nominations for such labels. The obvious ones are device-oriented ones > cell phone > PC > landline phone > text device (BlackBerry, SMS, TTY, ...) > other suggestions? > > Ben Campbell wrote: > > > > > I think even that can be handled cleanly. Such a device just displays > > some default icon that indicates it does not know what type of tuple it > > has. That is no different from common usage in many other applications. > > For example, email attachments when your browser does not recognize the > > mime type, or gets something completely generic like > > application/octet-stream without any other qualifiers. > > > > > > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Jul 15 04:58:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06769 for ; Tue, 15 Jul 2003 04:58:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLdQ-0000HT-04 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 04:58:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F8w7ZU001077 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 04:58:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLdP-0000HI-M7 for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 04:58:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06699; Tue, 15 Jul 2003 04:58:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLdL-000715-00; Tue, 15 Jul 2003 04:58:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLdL-000712-00; Tue, 15 Jul 2003 04:58:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLdJ-0000FD-02; Tue, 15 Jul 2003 04:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLd3-0000Ej-4P for simple@optimus.ietf.org; Tue, 15 Jul 2003 04:57:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06661 for ; Tue, 15 Jul 2003 04:57:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLd0-00070N-00 for simple@ietf.org; Tue, 15 Jul 2003 04:57:42 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19cLcy-000708-00 for simple@ietf.org; Tue, 15 Jul 2003 04:57:41 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h6F8vabl043350; Tue, 15 Jul 2003 03:57:38 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] Tuple design team discussion summary From: Ben Campbell To: Henning Schulzrinne Cc: Simple WG In-Reply-To: <3F13BD7D.409@cs.columbia.edu> References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> <3F135001.9040206@dynamicsoft.com> <1058257541.2536.7.camel@verite.localdomain> <3F13BD7D.409@cs.columbia.edu> Content-Type: text/plain Message-Id: <1058259234.2536.27.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Jul 2003 03:53:55 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hopefully we can generalize these a bit. For example: voice device Mobile voice device Fixed voice device Workstation (or some sort of rich media device) text device short text device (i.e. don't send me big stuff) This list seems to me to break down to a few dimensions: Mobility Media stream/message orientation Size limits Which sound a lot like capabilities to me. On Tue, 2003-07-15 at 03:38, Henning Schulzrinne wrote: > Almost none of the labels in RPIDS are exhaustive or claim to be, so a > list is better than nothing. To make progress, I would like to call for > nominations for such labels. The obvious ones are device-oriented ones > cell phone > PC > landline phone > text device (BlackBerry, SMS, TTY, ...) > other suggestions? > > Ben Campbell wrote: > > > > > I think even that can be handled cleanly. Such a device just displays > > some default icon that indicates it does not know what type of tuple it > > has. That is no different from common usage in many other applications. > > For example, email attachments when your browser does not recognize the > > mime type, or gets something completely generic like > > application/octet-stream without any other qualifiers. > > > > > > > > _______________________________________________ > 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-admin@ietf.org Tue Jul 15 05:11:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07860; Tue, 15 Jul 2003 05:11:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLq1-0007HF-00; Tue, 15 Jul 2003 05:11:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLq1-0007HC-00; Tue, 15 Jul 2003 05:11:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLpt-0001GV-R5; Tue, 15 Jul 2003 05:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLpP-0001Fm-MF for simple@optimus.ietf.org; Tue, 15 Jul 2003 05:10:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07806 for ; Tue, 15 Jul 2003 05:10:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLpM-0007GZ-00 for simple@ietf.org; Tue, 15 Jul 2003 05:10:28 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cLpL-0007GC-00 for simple@ietf.org; Tue, 15 Jul 2003 05:10:27 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h6F99rB29020; Tue, 15 Jul 2003 04:09:55 -0500 Subject: Re: [Simple] PUBLISH: atomicity problem From: Robert Sparks To: Aki Niemi Cc: simple@ietf.org In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB0@esebe013.ntc.nokia.com> References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB0@esebe013.ntc.nokia.com> Content-Type: text/plain Message-Id: <1058260190.934.23.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Jul 2003 11:09:51 +0200 Content-Transfer-Encoding: 7bit Another way to state this conclusion is that we need to report success or failure of publishing each atomic element in an independent fashion. One quick and easy way to achieve that property is to allow only one atomic element per PUBLISH request. I think I heard another way to do this mentioned during the meeting, where we move reporting the success/failure and any feedback from the attempt to publish each tuple into the message instead of trying to capture it all on the status line. For example (I think this is what I heard suggested during the meeting), for presence, we could publish an entire pidf document with several tuples and in the presence response return an xml document with one element per tuple discussing the disposition of attempting to publish that tuple. Something along the lines of the following (an example to convey the concept, not a proposal of a syntax) If we were to pursue such an optimization, it might make sense to look at how to specify a separate etag value in the publish (currently what we put in an If-Match header) for each atom in the published document. RjS On Mon, 2003-07-14 at 19:58, aki.niemi@nokia.com wrote: > All, > > I'll try to summarize the issues w.r.t. the atomicity of publication here in an attempt to converge the discussion towards a solution to this problem. BTW, I realized that my slides in the SIMPLE session were perhaps not crystal clear on what the problem at hand really was, so my apologies for that. > > The core problem is this: > > EPA X sends a PUBLISH with {a, b, c}, after which EPA Y publishes {a, b}. When EPA X tries to refresh its publication of {a, b, c}, the request fails because of a collision, resulting in the EPA X quitting. EPA Y still refreshes its publication of {a, b}, which means {c} expires and goes away. As a result, the publication process has lost information of {c}. This is unacceptable, and with the current versioning mechanism, this can't be remedied by composer policy, for example. > > Instead, to get around the above problem, what you send in a PUBLISH needs to match the atomic element of the published information. So each PUBLISH needs to contain a single tuple, because the versioning and expiration all work on the single atomic element level anyway. > > This has the apparent drawback in that the PUA has to wait for a 200 OK after each PUBLISHed tuple before it can PUBLISH the next one. This occurs upon every refresh cycle, and in systems with high latency, may become a major issue in terms of performance. > > Ways to get around this inefficiency: > - Remove the restriction on overlapping requests, i.e., allow "pipelining" > of PUBLISH requests > - Treat the publisher of each tuple as a separate EPA, and therefore not > subject to this restriction in the first place (seems like cheating...) > > In conclusion, my proposal is to go with having always a single tuple in a PUBLISH, and allow overlapping PUBLISH requests. To my knowledge, this would fulfill all the related requirements and solve the issue. > > Thoughts? > > Cheers, > Aki > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 05:11:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07883 for ; Tue, 15 Jul 2003 05:11:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLq5-0001KH-L1 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 05:11:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9BDUw005093 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 05:11:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLq5-0001K4-ID for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 05:11:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07860; Tue, 15 Jul 2003 05:11:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLq1-0007HF-00; Tue, 15 Jul 2003 05:11:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLq1-0007HC-00; Tue, 15 Jul 2003 05:11:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLpt-0001GV-R5; Tue, 15 Jul 2003 05:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLpP-0001Fm-MF for simple@optimus.ietf.org; Tue, 15 Jul 2003 05:10:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07806 for ; Tue, 15 Jul 2003 05:10:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLpM-0007GZ-00 for simple@ietf.org; Tue, 15 Jul 2003 05:10:28 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cLpL-0007GC-00 for simple@ietf.org; Tue, 15 Jul 2003 05:10:27 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h6F99rB29020; Tue, 15 Jul 2003 04:09:55 -0500 Subject: Re: [Simple] PUBLISH: atomicity problem From: Robert Sparks To: Aki Niemi Cc: simple@ietf.org In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB0@esebe013.ntc.nokia.com> References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB0@esebe013.ntc.nokia.com> Content-Type: text/plain Message-Id: <1058260190.934.23.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Jul 2003 11:09:51 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Another way to state this conclusion is that we need to report success or failure of publishing each atomic element in an independent fashion. One quick and easy way to achieve that property is to allow only one atomic element per PUBLISH request. I think I heard another way to do this mentioned during the meeting, where we move reporting the success/failure and any feedback from the attempt to publish each tuple into the message instead of trying to capture it all on the status line. For example (I think this is what I heard suggested during the meeting), for presence, we could publish an entire pidf document with several tuples and in the presence response return an xml document with one element per tuple discussing the disposition of attempting to publish that tuple. Something along the lines of the following (an example to convey the concept, not a proposal of a syntax) If we were to pursue such an optimization, it might make sense to look at how to specify a separate etag value in the publish (currently what we put in an If-Match header) for each atom in the published document. RjS On Mon, 2003-07-14 at 19:58, aki.niemi@nokia.com wrote: > All, > > I'll try to summarize the issues w.r.t. the atomicity of publication here in an attempt to converge the discussion towards a solution to this problem. BTW, I realized that my slides in the SIMPLE session were perhaps not crystal clear on what the problem at hand really was, so my apologies for that. > > The core problem is this: > > EPA X sends a PUBLISH with {a, b, c}, after which EPA Y publishes {a, b}. When EPA X tries to refresh its publication of {a, b, c}, the request fails because of a collision, resulting in the EPA X quitting. EPA Y still refreshes its publication of {a, b}, which means {c} expires and goes away. As a result, the publication process has lost information of {c}. This is unacceptable, and with the current versioning mechanism, this can't be remedied by composer policy, for example. > > Instead, to get around the above problem, what you send in a PUBLISH needs to match the atomic element of the published information. So each PUBLISH needs to contain a single tuple, because the versioning and expiration all work on the single atomic element level anyway. > > This has the apparent drawback in that the PUA has to wait for a 200 OK after each PUBLISHed tuple before it can PUBLISH the next one. This occurs upon every refresh cycle, and in systems with high latency, may become a major issue in terms of performance. > > Ways to get around this inefficiency: > - Remove the restriction on overlapping requests, i.e., allow "pipelining" > of PUBLISH requests > - Treat the publisher of each tuple as a separate EPA, and therefore not > subject to this restriction in the first place (seems like cheating...) > > In conclusion, my proposal is to go with having always a single tuple in a PUBLISH, and allow overlapping PUBLISH requests. To my knowledge, this would fulfill all the related requirements and solve the issue. > > Thoughts? > > Cheers, > Aki > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 05:13:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07992; Tue, 15 Jul 2003 05:13:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLrq-0007J7-00; Tue, 15 Jul 2003 05:13:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLrq-0007J4-00; Tue, 15 Jul 2003 05:13:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLro-0001OI-PK; Tue, 15 Jul 2003 05:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLrD-0001Nd-GW for simple@optimus.ietf.org; Tue, 15 Jul 2003 05:12:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07933 for ; Tue, 15 Jul 2003 05:12:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLrA-0007ID-00 for simple@ietf.org; Tue, 15 Jul 2003 05:12:20 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19cLr9-0007I9-00 for simple@ietf.org; Tue, 15 Jul 2003 05:12:19 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h6F9CEbl044430; Tue, 15 Jul 2003 04:12:15 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: RE: [Simple] comments on rpids-01 (general, vCard, predictive) From: Ben Campbell To: Adam Roach Cc: Henning Schulzrinne , Jon Peterson , "Simpletons (E-mail)" In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEB@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEB@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Message-Id: <1058260102.2536.41.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Jul 2003 04:08:22 -0500 Content-Transfer-Encoding: 7bit On Mon, 2003-07-14 at 08:47, Adam Roach wrote: > > > Again, commercial instant messaging systems, in my > > experience, don't use > > > presentity-provided icons to express a presentity's current > > state in a > > > watcher's buddylist screen. Apps might have predefined > > icons corresponding > > > to, say, your state as given in rpids-00, but I > > don't think I've > > > seen user-supplied versions of those icons to date. The > > whole value of these > > > > See GAIM above, albeit provided by the watcher, given the lack of > > protocol support. > > I'm really going to have to agree strongly with Jon here. > Allowing the presentity to provide icons to represent any > kind of state -- and especially presence state -- is going > to result in nothing but an inscrutable mish-mash of angry > fruit salad in your buddy-list window. > > It would be a real black eye if all or even most SIMPLE-based > IM systems ended up being thematically similar to the typical > poorly-designed amateur web page that consists primarily of > jarringly mismatched graphics found elsewhere on the web. > >From a user interface perspective, I have to concur. The whole point of icons representing state is to give me a quick visual way to determine that state. This only works if the icons are consistent. If every presentity I watch uses a different set of icons, then they are useless to me for that purpose. They become nothing but vanity plates for the presentities, or worse, a form of advertising. (In the same sense, I consider HTML favicons to be evil.) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 05:13:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08042 for ; Tue, 15 Jul 2003 05:13:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLru-0001Rk-Po for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 05:13:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9D6f2005555 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 05:13:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLru-0001RW-Mp for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 05:13:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07992; Tue, 15 Jul 2003 05:13:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLrq-0007J7-00; Tue, 15 Jul 2003 05:13:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLrq-0007J4-00; Tue, 15 Jul 2003 05:13:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLro-0001OI-PK; Tue, 15 Jul 2003 05:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLrD-0001Nd-GW for simple@optimus.ietf.org; Tue, 15 Jul 2003 05:12:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07933 for ; Tue, 15 Jul 2003 05:12:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLrA-0007ID-00 for simple@ietf.org; Tue, 15 Jul 2003 05:12:20 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19cLr9-0007I9-00 for simple@ietf.org; Tue, 15 Jul 2003 05:12:19 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h6F9CEbl044430; Tue, 15 Jul 2003 04:12:15 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: RE: [Simple] comments on rpids-01 (general, vCard, predictive) From: Ben Campbell To: Adam Roach Cc: Henning Schulzrinne , Jon Peterson , "Simpletons (E-mail)" In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEB@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEB@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Message-Id: <1058260102.2536.41.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Jul 2003 04:08:22 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2003-07-14 at 08:47, Adam Roach wrote: > > > Again, commercial instant messaging systems, in my > > experience, don't use > > > presentity-provided icons to express a presentity's current > > state in a > > > watcher's buddylist screen. Apps might have predefined > > icons corresponding > > > to, say, your state as given in rpids-00, but I > > don't think I've > > > seen user-supplied versions of those icons to date. The > > whole value of these > > > > See GAIM above, albeit provided by the watcher, given the lack of > > protocol support. > > I'm really going to have to agree strongly with Jon here. > Allowing the presentity to provide icons to represent any > kind of state -- and especially presence state -- is going > to result in nothing but an inscrutable mish-mash of angry > fruit salad in your buddy-list window. > > It would be a real black eye if all or even most SIMPLE-based > IM systems ended up being thematically similar to the typical > poorly-designed amateur web page that consists primarily of > jarringly mismatched graphics found elsewhere on the web. > >From a user interface perspective, I have to concur. The whole point of icons representing state is to give me a quick visual way to determine that state. This only works if the icons are consistent. If every presentity I watch uses a different set of icons, then they are useless to me for that purpose. They become nothing but vanity plates for the presentities, or worse, a form of advertising. (In the same sense, I consider HTML favicons to be evil.) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 05:18:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08568; Tue, 15 Jul 2003 05:18:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLwg-0007Rk-00; Tue, 15 Jul 2003 05:18:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLwg-0007Rg-00; Tue, 15 Jul 2003 05:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLwe-0001ik-WF; Tue, 15 Jul 2003 05:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLvs-0001du-7w for simple@optimus.ietf.org; Tue, 15 Jul 2003 05:17:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08432 for ; Tue, 15 Jul 2003 05:17:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLvp-0007Pu-00 for simple@ietf.org; Tue, 15 Jul 2003 05:17:09 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cLvo-0007Pr-00 for simple@ietf.org; Tue, 15 Jul 2003 05:17:08 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6F9H9kM023684; Tue, 15 Jul 2003 05:17:09 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6F9H8g12033; Tue, 15 Jul 2003 05:17:08 -0400 Message-ID: <3F13C59C.5090105@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> <3F13080F.4060706@cs.columbia.edu> <3F1330E3.8070407@lucent.com> In-Reply-To: <3F1330E3.8070407@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 05:13:00 -0400 Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Just to be sure, by "import" above you mean including the > secretary's presence as a reference in the boss' presence document, > right? If so, then we still have the authorization problem, no? No, that simply means that the presentity or composer takes a tuple summarizing the status of the entity and delivers it to its subscribers. > The second one, as you note is a smaller problem and can boil down > to policy/business decisions. Even in real-world boss/secretary > relationship, there will be a discrete set of calls deflected > from the boss to the secretary that go unanswered (secretary > gone for the day, on lunch, already on phone, ...) I'm primarily concerned about difficult-to-explain failure cases that can't be readily fixed, particularly for people that don't understand the underlying mechanics. Call-by-reference is always more brittle than call by value. With inclusion, if the boss-to-secretary subscription fails, the boss can deal with it, with local knowledge. If the ticket/reference fails, the boss won't know and will, at best, get some vague "your secretary refuses to be subscribed to" explanation. Given the trade-offs, I see no reason to allow this trade-off be made locally rather than forcing one design or another. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 05:18:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08631 for ; Tue, 15 Jul 2003 05:18:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLwl-0001mG-1a for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 05:18:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9I7DO006826 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 05:18:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLwk-0001m1-UX for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 05:18:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08568; Tue, 15 Jul 2003 05:18:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLwg-0007Rk-00; Tue, 15 Jul 2003 05:18:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLwg-0007Rg-00; Tue, 15 Jul 2003 05:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLwe-0001ik-WF; Tue, 15 Jul 2003 05:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLvs-0001du-7w for simple@optimus.ietf.org; Tue, 15 Jul 2003 05:17:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08432 for ; Tue, 15 Jul 2003 05:17:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLvp-0007Pu-00 for simple@ietf.org; Tue, 15 Jul 2003 05:17:09 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cLvo-0007Pr-00 for simple@ietf.org; Tue, 15 Jul 2003 05:17:08 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6F9H9kM023684; Tue, 15 Jul 2003 05:17:09 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6F9H8g12033; Tue, 15 Jul 2003 05:17:08 -0400 Message-ID: <3F13C59C.5090105@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> <3F13080F.4060706@cs.columbia.edu> <3F1330E3.8070407@lucent.com> In-Reply-To: <3F1330E3.8070407@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 05:13:00 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Just to be sure, by "import" above you mean including the > secretary's presence as a reference in the boss' presence document, > right? If so, then we still have the authorization problem, no? No, that simply means that the presentity or composer takes a tuple summarizing the status of the entity and delivers it to its subscribers. > The second one, as you note is a smaller problem and can boil down > to policy/business decisions. Even in real-world boss/secretary > relationship, there will be a discrete set of calls deflected > from the boss to the secretary that go unanswered (secretary > gone for the day, on lunch, already on phone, ...) I'm primarily concerned about difficult-to-explain failure cases that can't be readily fixed, particularly for people that don't understand the underlying mechanics. Call-by-reference is always more brittle than call by value. With inclusion, if the boss-to-secretary subscription fails, the boss can deal with it, with local knowledge. If the ticket/reference fails, the boss won't know and will, at best, get some vague "your secretary refuses to be subscribed to" explanation. Given the trade-offs, I see no reason to allow this trade-off be made locally rather than forcing one design or another. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 05:19:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08772; Tue, 15 Jul 2003 05:19:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLyZ-0007Un-00; Tue, 15 Jul 2003 05:20:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLyZ-0007Uk-00; Tue, 15 Jul 2003 05:19:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLya-0001ob-Ef; Tue, 15 Jul 2003 05:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLyM-0001o6-Fj for simple@optimus.ietf.org; Tue, 15 Jul 2003 05:19:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08742 for ; Tue, 15 Jul 2003 05:19:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLyJ-0007US-00 for simple@ietf.org; Tue, 15 Jul 2003 05:19:43 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cLyI-0007UN-00 for simple@ietf.org; Tue, 15 Jul 2003 05:19:42 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6F9JgkM023947; Tue, 15 Jul 2003 05:19:42 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6F9Jfg12395; Tue, 15 Jul 2003 05:19:42 -0400 Message-ID: <3F13C636.60808@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 (general, vCard, predictive) References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEB@dyn-tx-exch-001.dynamicsoft.com> <1058260102.2536.41.camel@verite.localdomain> In-Reply-To: <1058260102.2536.41.camel@verite.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 05:15:34 -0400 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >>From a user interface perspective, I have to concur. The whole point of > icons representing state is to give me a quick visual way to determine > that state. This only works if the icons are consistent. If every > presentity I watch uses a different set of icons, then they are useless > to me for that purpose. They become nothing but vanity plates for the > presentities, or worse, a form of advertising. (In the same sense, I > consider HTML favicons to be evil.) I don't see why we need to mandate UI preferences. Sure, you should have the possibility of turning off favicons (or RPIDS icons), but they work well enough to be considered useful by people who build browsers that didn't have to implement them. I think noting that UA UIs should allow turning them off is a reasonable statements. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 05:20:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08833 for ; Tue, 15 Jul 2003 05:20:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLyf-0001s7-Ec for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 05:20:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9K5jK007193 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 05:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLye-0001rw-5f for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 05:20:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08772; Tue, 15 Jul 2003 05:19:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLyZ-0007Un-00; Tue, 15 Jul 2003 05:20:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLyZ-0007Uk-00; Tue, 15 Jul 2003 05:19:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLya-0001ob-Ef; Tue, 15 Jul 2003 05:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLyM-0001o6-Fj for simple@optimus.ietf.org; Tue, 15 Jul 2003 05:19:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08742 for ; Tue, 15 Jul 2003 05:19:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLyJ-0007US-00 for simple@ietf.org; Tue, 15 Jul 2003 05:19:43 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cLyI-0007UN-00 for simple@ietf.org; Tue, 15 Jul 2003 05:19:42 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6F9JgkM023947; Tue, 15 Jul 2003 05:19:42 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6F9Jfg12395; Tue, 15 Jul 2003 05:19:42 -0400 Message-ID: <3F13C636.60808@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 (general, vCard, predictive) References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEB@dyn-tx-exch-001.dynamicsoft.com> <1058260102.2536.41.camel@verite.localdomain> In-Reply-To: <1058260102.2536.41.camel@verite.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 05:15:34 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >>From a user interface perspective, I have to concur. The whole point of > icons representing state is to give me a quick visual way to determine > that state. This only works if the icons are consistent. If every > presentity I watch uses a different set of icons, then they are useless > to me for that purpose. They become nothing but vanity plates for the > presentities, or worse, a form of advertising. (In the same sense, I > consider HTML favicons to be evil.) I don't see why we need to mandate UI preferences. Sure, you should have the possibility of turning off favicons (or RPIDS icons), but they work well enough to be considered useful by people who build browsers that didn't have to implement them. I think noting that UA UIs should allow turning them off is a reasonable statements. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 05:20:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08887; Tue, 15 Jul 2003 05:20:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLzY-0007WW-00; Tue, 15 Jul 2003 05:21:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLzX-0007WT-00; Tue, 15 Jul 2003 05:20:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLzZ-0001tI-BN; Tue, 15 Jul 2003 05:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLzD-0001sf-HS for simple@optimus.ietf.org; Tue, 15 Jul 2003 05:20:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08869 for ; Tue, 15 Jul 2003 05:20:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLzA-0007Vx-00 for simple@ietf.org; Tue, 15 Jul 2003 05:20:36 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19cLz9-0007Vr-00 for simple@ietf.org; Tue, 15 Jul 2003 05:20:35 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h6F9KQbl044924; Tue, 15 Jul 2003 04:20:30 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] Tuple design team discussion summary From: Ben Campbell To: Henning Schulzrinne Cc: Simple WG In-Reply-To: <1058259234.2536.27.camel@verite.localdomain> References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> <3F135001.9040206@dynamicsoft.com> <1058257541.2536.7.camel@verite.localdomain> <3F13BD7D.409@cs.columbia.edu> <1058259234.2536.27.camel@verite.localdomain> Content-Type: text/plain Message-Id: <1058260587.2536.44.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Jul 2003 04:16:28 -0500 Content-Transfer-Encoding: 7bit (Replying to self) Ah, I see Henning already mentioned this in a previous note. Apologies for creating meme loops by reading out of order. On Tue, 2003-07-15 at 03:53, Ben Campbell wrote: > Hopefully we can generalize these a bit. For example: > > voice device > Mobile voice device > Fixed voice device > Workstation (or some sort of rich media device) > text device > short text device (i.e. don't send me big stuff) > > This list seems to me to break down to a few dimensions: > > Mobility > Media > stream/message orientation > Size limits > > Which sound a lot like capabilities to me. > > On Tue, 2003-07-15 at 03:38, Henning Schulzrinne wrote: > > Almost none of the labels in RPIDS are exhaustive or claim to be, so a > > list is better than nothing. To make progress, I would like to call for > > nominations for such labels. The obvious ones are device-oriented ones > > cell phone > > PC > > landline phone > > text device (BlackBerry, SMS, TTY, ...) > > other suggestions? > > > > Ben Campbell wrote: > > > > > > > > I think even that can be handled cleanly. Such a device just displays > > > some default icon that indicates it does not know what type of tuple it > > > has. That is no different from common usage in many other applications. > > > For example, email attachments when your browser does not recognize the > > > mime type, or gets something completely generic like > > > application/octet-stream without any other qualifiers. > > > > > > > > > > > > > > > _______________________________________________ > > 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 exim@www1.ietf.org Tue Jul 15 05:21:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08932 for ; Tue, 15 Jul 2003 05:21:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLzc-0001wj-Cc for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 05:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9L4Cj007475 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 05:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLzc-0001wU-9U for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 05:21:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08887; Tue, 15 Jul 2003 05:20:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLzY-0007WW-00; Tue, 15 Jul 2003 05:21:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cLzX-0007WT-00; Tue, 15 Jul 2003 05:20:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLzZ-0001tI-BN; Tue, 15 Jul 2003 05:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cLzD-0001sf-HS for simple@optimus.ietf.org; Tue, 15 Jul 2003 05:20:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08869 for ; Tue, 15 Jul 2003 05:20:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cLzA-0007Vx-00 for simple@ietf.org; Tue, 15 Jul 2003 05:20:36 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19cLz9-0007Vr-00 for simple@ietf.org; Tue, 15 Jul 2003 05:20:35 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h6F9KQbl044924; Tue, 15 Jul 2003 04:20:30 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] Tuple design team discussion summary From: Ben Campbell To: Henning Schulzrinne Cc: Simple WG In-Reply-To: <1058259234.2536.27.camel@verite.localdomain> References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> <3F135001.9040206@dynamicsoft.com> <1058257541.2536.7.camel@verite.localdomain> <3F13BD7D.409@cs.columbia.edu> <1058259234.2536.27.camel@verite.localdomain> Content-Type: text/plain Message-Id: <1058260587.2536.44.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Jul 2003 04:16:28 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (Replying to self) Ah, I see Henning already mentioned this in a previous note. Apologies for creating meme loops by reading out of order. On Tue, 2003-07-15 at 03:53, Ben Campbell wrote: > Hopefully we can generalize these a bit. For example: > > voice device > Mobile voice device > Fixed voice device > Workstation (or some sort of rich media device) > text device > short text device (i.e. don't send me big stuff) > > This list seems to me to break down to a few dimensions: > > Mobility > Media > stream/message orientation > Size limits > > Which sound a lot like capabilities to me. > > On Tue, 2003-07-15 at 03:38, Henning Schulzrinne wrote: > > Almost none of the labels in RPIDS are exhaustive or claim to be, so a > > list is better than nothing. To make progress, I would like to call for > > nominations for such labels. The obvious ones are device-oriented ones > > cell phone > > PC > > landline phone > > text device (BlackBerry, SMS, TTY, ...) > > other suggestions? > > > > Ben Campbell wrote: > > > > > > > > I think even that can be handled cleanly. Such a device just displays > > > some default icon that indicates it does not know what type of tuple it > > > has. That is no different from common usage in many other applications. > > > For example, email attachments when your browser does not recognize the > > > mime type, or gets something completely generic like > > > application/octet-stream without any other qualifiers. > > > > > > > > > > > > > > > _______________________________________________ > > 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-admin@ietf.org Tue Jul 15 05:27:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09506; Tue, 15 Jul 2003 05:27:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cM5o-0007em-00; Tue, 15 Jul 2003 05:27:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cM5l-0007eZ-00; Tue, 15 Jul 2003 05:27:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM5M-0002ET-EV; Tue, 15 Jul 2003 05:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM4h-0002DF-83 for simple@optimus.ietf.org; Tue, 15 Jul 2003 05:26:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09437 for ; Tue, 15 Jul 2003 05:26:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cM4d-0007eB-00 for simple@ietf.org; Tue, 15 Jul 2003 05:26:15 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cM4d-0007e7-00 for simple@ietf.org; Tue, 15 Jul 2003 05:26:15 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6F9QFkM024354; Tue, 15 Jul 2003 05:26:15 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6F9QEg12875; Tue, 15 Jul 2003 05:26:14 -0400 Message-ID: <3F13C7BE.90107@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] Tuple design team discussion summary References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> <3F135001.9040206@dynamicsoft.com> <1058257541.2536.7.camel@verite.localdomain> <3F13BD7D.409@cs.columbia.edu> <1058259234.2536.27.camel@verite.localdomain> In-Reply-To: <1058259234.2536.27.camel@verite.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 05:22:06 -0400 Content-Transfer-Encoding: 7bit As I noted earlier, I see no point in having a label that is simply the combinations of existing RPIDS fields that the receiver can also combine into a label. Ben Campbell wrote: > Hopefully we can generalize these a bit. For example: > > voice device capability = audio, mobility undefined > Mobile voice device mobile, audio > Fixed voice device fixed, audio > Workstation (or some sort of rich media device) fixed, audio, video, text > text device *, text > short text device (i.e. don't send me big stuff) shouldn't that be a capability addition? (I'm not sure if this should be a qualitative or quantitive capability.) > > This list seems to me to break down to a few dimensions: > > Mobility > Media > stream/message orientation > Size limits > > Which sound a lot like capabilities to me. I'm not sure if you're agreeing that the proposed labels are merely re-stating information that's already available or if they are useful. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 05:27:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09603 for ; Tue, 15 Jul 2003 05:27:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM5s-0002OE-Oe for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 05:27:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9RWIA009182 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 05:27:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM5s-0002O1-Lg for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 05:27:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09506; Tue, 15 Jul 2003 05:27:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cM5o-0007em-00; Tue, 15 Jul 2003 05:27:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cM5l-0007eZ-00; Tue, 15 Jul 2003 05:27:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM5M-0002ET-EV; Tue, 15 Jul 2003 05:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM4h-0002DF-83 for simple@optimus.ietf.org; Tue, 15 Jul 2003 05:26:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09437 for ; Tue, 15 Jul 2003 05:26:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cM4d-0007eB-00 for simple@ietf.org; Tue, 15 Jul 2003 05:26:15 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cM4d-0007e7-00 for simple@ietf.org; Tue, 15 Jul 2003 05:26:15 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6F9QFkM024354; Tue, 15 Jul 2003 05:26:15 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6F9QEg12875; Tue, 15 Jul 2003 05:26:14 -0400 Message-ID: <3F13C7BE.90107@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] Tuple design team discussion summary References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> <3F135001.9040206@dynamicsoft.com> <1058257541.2536.7.camel@verite.localdomain> <3F13BD7D.409@cs.columbia.edu> <1058259234.2536.27.camel@verite.localdomain> In-Reply-To: <1058259234.2536.27.camel@verite.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 05:22:06 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As I noted earlier, I see no point in having a label that is simply the combinations of existing RPIDS fields that the receiver can also combine into a label. Ben Campbell wrote: > Hopefully we can generalize these a bit. For example: > > voice device capability = audio, mobility undefined > Mobile voice device mobile, audio > Fixed voice device fixed, audio > Workstation (or some sort of rich media device) fixed, audio, video, text > text device *, text > short text device (i.e. don't send me big stuff) shouldn't that be a capability addition? (I'm not sure if this should be a qualitative or quantitive capability.) > > This list seems to me to break down to a few dimensions: > > Mobility > Media > stream/message orientation > Size limits > > Which sound a lot like capabilities to me. I'm not sure if you're agreeing that the proposed labels are merely re-stating information that's already available or if they are useful. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 05:32:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10066; Tue, 15 Jul 2003 05:32:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMAE-0002iM-1x; Tue, 15 Jul 2003 05:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM9u-0002hq-Lr for simple@optimus.ietf.org; Tue, 15 Jul 2003 05:31:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10032 for ; Tue, 15 Jul 2003 05:31:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cM9r-0007ll-00 for simple@ietf.org; Tue, 15 Jul 2003 05:31:39 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19cM9q-0007le-00 for simple@ietf.org; Tue, 15 Jul 2003 05:31:38 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h6F9VObl045735; Tue, 15 Jul 2003 04:31:29 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] Tuple design team discussion summary From: Ben Campbell To: Henning Schulzrinne Cc: Simple WG In-Reply-To: <3F13C7BE.90107@cs.columbia.edu> References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> <3F135001.9040206@dynamicsoft.com> <1058257541.2536.7.camel@verite.localdomain> <3F13BD7D.409@cs.columbia.edu> <1058259234.2536.27.camel@verite.localdomain> <3F13C7BE.90107@cs.columbia.edu> Content-Type: text/plain Message-Id: <1058261237.2536.46.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Jul 2003 04:27:17 -0500 Content-Transfer-Encoding: 7bit On Tue, 2003-07-15 at 04:22, Henning Schulzrinne wrote: > As I noted earlier, I see no point in having a label that is simply the > combinations of existing RPIDS fields that the receiver can also combine > into a label. Yes. I was badly attempting to agree with that point. > > Ben Campbell wrote: > > > Hopefully we can generalize these a bit. For example: > > > > voice device > > capability = audio, mobility undefined > > > Mobile voice device > > mobile, audio > > > Fixed voice device > > fixed, audio > > > Workstation (or some sort of rich media device) > > fixed, audio, video, text > > > text device > > *, text > > > short text device (i.e. don't send me big stuff) > > shouldn't that be a capability addition? (I'm not sure if this should be > a qualitative or quantitive capability.) > > > > > This list seems to me to break down to a few dimensions: > > > > Mobility > > Media > > stream/message orientation > > Size limits > > > > Which sound a lot like capabilities to me. > > I'm not sure if you're agreeing that the proposed labels are merely > re-stating information that's already available or if they are useful. > I am agreeing with the former. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 05:33:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10130 for ; Tue, 15 Jul 2003 05:33:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMAl-0002pj-F6 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 05:32:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9WZAw010885 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 05:32:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMAl-0002pU-Ak for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 05:32:35 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10066; Tue, 15 Jul 2003 05:32:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMAE-0002iM-1x; Tue, 15 Jul 2003 05:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM9u-0002hq-Lr for simple@optimus.ietf.org; Tue, 15 Jul 2003 05:31:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10032 for ; Tue, 15 Jul 2003 05:31:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cM9r-0007ll-00 for simple@ietf.org; Tue, 15 Jul 2003 05:31:39 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19cM9q-0007le-00 for simple@ietf.org; Tue, 15 Jul 2003 05:31:38 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h6F9VObl045735; Tue, 15 Jul 2003 04:31:29 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] Tuple design team discussion summary From: Ben Campbell To: Henning Schulzrinne Cc: Simple WG In-Reply-To: <3F13C7BE.90107@cs.columbia.edu> References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> <3F135001.9040206@dynamicsoft.com> <1058257541.2536.7.camel@verite.localdomain> <3F13BD7D.409@cs.columbia.edu> <1058259234.2536.27.camel@verite.localdomain> <3F13C7BE.90107@cs.columbia.edu> Content-Type: text/plain Message-Id: <1058261237.2536.46.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Jul 2003 04:27:17 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2003-07-15 at 04:22, Henning Schulzrinne wrote: > As I noted earlier, I see no point in having a label that is simply the > combinations of existing RPIDS fields that the receiver can also combine > into a label. Yes. I was badly attempting to agree with that point. > > Ben Campbell wrote: > > > Hopefully we can generalize these a bit. For example: > > > > voice device > > capability = audio, mobility undefined > > > Mobile voice device > > mobile, audio > > > Fixed voice device > > fixed, audio > > > Workstation (or some sort of rich media device) > > fixed, audio, video, text > > > text device > > *, text > > > short text device (i.e. don't send me big stuff) > > shouldn't that be a capability addition? (I'm not sure if this should be > a qualitative or quantitive capability.) > > > > > This list seems to me to break down to a few dimensions: > > > > Mobility > > Media > > stream/message orientation > > Size limits > > > > Which sound a lot like capabilities to me. > > I'm not sure if you're agreeing that the proposed labels are merely > re-stating information that's already available or if they are useful. > I am agreeing with the former. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 06:16:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12415; Tue, 15 Jul 2003 06:16:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cMrb-0000Lf-00; Tue, 15 Jul 2003 06:16:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cMr1-0000LN-00; Tue, 15 Jul 2003 06:16:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMqo-00052V-7j; Tue, 15 Jul 2003 06:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMqA-00050u-73 for simple@optimus.ietf.org; Tue, 15 Jul 2003 06:15:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12319 for ; Tue, 15 Jul 2003 06:15:16 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cMq1-0000Kl-00 for simple@ietf.org; Tue, 15 Jul 2003 06:15:13 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19cMpb-0000Kb-00 for simple@ietf.org; Tue, 15 Jul 2003 06:14:47 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6FAEck25539 for ; Tue, 15 Jul 2003 13:14:38 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 13:14:38 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 13:14:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] asking for a specific view Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F0A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] asking for a specific view Thread-Index: AcNKrY1P08dGV2WRTGetwXz2/xCKkAADABpg To: , Cc: , X-OriginalArrivalTime: 15 Jul 2003 10:14:36.0956 (UTC) FILETIME=[E5196DC0:01C34AB9] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 13:14:36 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Tuesday, July 15, 2003 11:42 AM > To: Jonathan Rosenberg > Cc: Henning Schulzrinne; Simple WG > Subject: Re: [Simple] asking for a specific view >=20 >=20 > On Mon, 2003-07-14 at 19:23, Jonathan Rosenberg wrote: > > Henning Schulzrinne wrote: > >=20 > > > Jonathan Rosenberg wrote: > > >=20 > > >> It is possible that, by default, the PA would not=20 > provide information=20 > > >> to the watcher in a device-centric view. Rather, its=20 > policy is to send=20 > > >> a single tuple with summary information. If this=20 > happens, the watcher=20 > > >> doesnt get the information they need, since its been=20 > aggregated away.=20 > > >> To remedy this, I think we need to enhance the filter=20 > work to allow a=20 > > >> watcher to ask for a specific view of the presence data.=20 > We have some=20 > > >> work to do to define a view, but we have a couple of=20 > good candidates=20 > > >> to work from. > > >=20 > > >=20 > > > Would this be as simple as being able to request certain=20 > columns (in my=20 > > > database view of the world)? > >=20 > > No. Its closer to what you were calling the pivot=20 > operation. But more=20 > > importantly, it means that the attributes have values (and indeed=20 > > exist) which are relevant for that particular view. For=20 > example, in a=20 > > "device centric" view, things like whether the device is on or off,=20 > > the placetype, geoloc, etc., make sense and have a well defined=20 > > meaning. For other views, such as Brian's one-tuple view,=20 > there could=20 > > also be a placetype and geoloc, but they might represent where the=20 > > user is (based, perhaps, on a device which is almost always on the=20 > > body of the person in question), as opposed to one of his devices. > >=20 > > Adam writes: > > >> To remedy this, I think we need to enhance the filter=20 > work to allow a > > >> watcher to ask for a specific view of the presence data.=20 > We have some > > >> work to do to define a view, but we have a couple of=20 > good candidates > > >> to work from. > > >=20 > > > I'm pretty certain that you're going to run into a lot of > > > situations in which presence cannot be broken down along > > > specific lines (like device or service views). For example, > > > presence information may arrive at a PA already partially (or even > > > fully) composed of information about multiple devices. You'll > > > also often run into situations in which composition is performed > > > as a means of intentional obscurity. > >=20 > > Sure. You can't always deliver what the watcher wants. But=20 > at least we=20 > > should be able to know what they want, and deliver it if=20 > possible, or=20 > > we are permitted to. >=20 > I would state this more strongly, in that the PA has complete control > over what it delivers. Such a request is at best a hint of watcher > preference. But in general, the PA is an agent of the=20 > presentity, and is > not obligated to care about the preferences of a watcher. Anything > beyond that is in conflict with one of the most useful attributes of > SIP, that is, the owner of a resource has controls how and where calls > are delivered. >=20 > Or in more practical terms, a watcher implementation MUST NOT=20 > assume its > preferences will be honored. I sgree with Jonathan's "deliver it if possible", but I don't agree to = deliver something in a view that the watcher does not want. The watcher = needs to know how to render or automata needs to know how to react. Regards, Hisham >=20 >=20 > >=20 > > >=20 > > > I'm not saying that your suggestion is bad, but I suspect > > > that we'll discover that the cases in which requests > > > for certain types of views make sense will be the exception > > > rather than the norm.=20 > >=20 > > Well, that remains to be seen. We don't have a lot of deployment=20 > > experience to see how these things will get used. > >=20 > > -Jonathan R. > >=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 exim@www1.ietf.org Tue Jul 15 06:17:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12442 for ; Tue, 15 Jul 2003 06:17:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMrq-00056s-1j for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 06:17:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FAH6ol019636 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 06:17:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMrp-00056d-Ul for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 06:17:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12415; Tue, 15 Jul 2003 06:16:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cMrb-0000Lf-00; Tue, 15 Jul 2003 06:16:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cMr1-0000LN-00; Tue, 15 Jul 2003 06:16:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMqo-00052V-7j; Tue, 15 Jul 2003 06:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMqA-00050u-73 for simple@optimus.ietf.org; Tue, 15 Jul 2003 06:15:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12319 for ; Tue, 15 Jul 2003 06:15:16 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cMq1-0000Kl-00 for simple@ietf.org; Tue, 15 Jul 2003 06:15:13 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19cMpb-0000Kb-00 for simple@ietf.org; Tue, 15 Jul 2003 06:14:47 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6FAEck25539 for ; Tue, 15 Jul 2003 13:14:38 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 13:14:38 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 13:14:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] asking for a specific view Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F0A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] asking for a specific view Thread-Index: AcNKrY1P08dGV2WRTGetwXz2/xCKkAADABpg To: , Cc: , X-OriginalArrivalTime: 15 Jul 2003 10:14:36.0956 (UTC) FILETIME=[E5196DC0:01C34AB9] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 13:14:36 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Tuesday, July 15, 2003 11:42 AM > To: Jonathan Rosenberg > Cc: Henning Schulzrinne; Simple WG > Subject: Re: [Simple] asking for a specific view >=20 >=20 > On Mon, 2003-07-14 at 19:23, Jonathan Rosenberg wrote: > > Henning Schulzrinne wrote: > >=20 > > > Jonathan Rosenberg wrote: > > >=20 > > >> It is possible that, by default, the PA would not=20 > provide information=20 > > >> to the watcher in a device-centric view. Rather, its=20 > policy is to send=20 > > >> a single tuple with summary information. If this=20 > happens, the watcher=20 > > >> doesnt get the information they need, since its been=20 > aggregated away.=20 > > >> To remedy this, I think we need to enhance the filter=20 > work to allow a=20 > > >> watcher to ask for a specific view of the presence data.=20 > We have some=20 > > >> work to do to define a view, but we have a couple of=20 > good candidates=20 > > >> to work from. > > >=20 > > >=20 > > > Would this be as simple as being able to request certain=20 > columns (in my=20 > > > database view of the world)? > >=20 > > No. Its closer to what you were calling the pivot=20 > operation. But more=20 > > importantly, it means that the attributes have values (and indeed=20 > > exist) which are relevant for that particular view. For=20 > example, in a=20 > > "device centric" view, things like whether the device is on or off,=20 > > the placetype, geoloc, etc., make sense and have a well defined=20 > > meaning. For other views, such as Brian's one-tuple view,=20 > there could=20 > > also be a placetype and geoloc, but they might represent where the=20 > > user is (based, perhaps, on a device which is almost always on the=20 > > body of the person in question), as opposed to one of his devices. > >=20 > > Adam writes: > > >> To remedy this, I think we need to enhance the filter=20 > work to allow a > > >> watcher to ask for a specific view of the presence data.=20 > We have some > > >> work to do to define a view, but we have a couple of=20 > good candidates > > >> to work from. > > >=20 > > > I'm pretty certain that you're going to run into a lot of > > > situations in which presence cannot be broken down along > > > specific lines (like device or service views). For example, > > > presence information may arrive at a PA already partially (or even > > > fully) composed of information about multiple devices. You'll > > > also often run into situations in which composition is performed > > > as a means of intentional obscurity. > >=20 > > Sure. You can't always deliver what the watcher wants. But=20 > at least we=20 > > should be able to know what they want, and deliver it if=20 > possible, or=20 > > we are permitted to. >=20 > I would state this more strongly, in that the PA has complete control > over what it delivers. Such a request is at best a hint of watcher > preference. But in general, the PA is an agent of the=20 > presentity, and is > not obligated to care about the preferences of a watcher. Anything > beyond that is in conflict with one of the most useful attributes of > SIP, that is, the owner of a resource has controls how and where calls > are delivered. >=20 > Or in more practical terms, a watcher implementation MUST NOT=20 > assume its > preferences will be honored. I sgree with Jonathan's "deliver it if possible", but I don't agree to = deliver something in a view that the watcher does not want. The watcher = needs to know how to render or automata needs to know how to react. Regards, Hisham >=20 >=20 > >=20 > > >=20 > > > I'm not saying that your suggestion is bad, but I suspect > > > that we'll discover that the cases in which requests > > > for certain types of views make sense will be the exception > > > rather than the norm.=20 > >=20 > > Well, that remains to be seen. We don't have a lot of deployment=20 > > experience to see how these things will get used. > >=20 > > -Jonathan R. > >=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-admin@ietf.org Tue Jul 15 06:26:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12845; Tue, 15 Jul 2003 06:26:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cN0U-0005Ow-AF; Tue, 15 Jul 2003 06:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cN04-0005O5-Vi for simple@optimus.ietf.org; Tue, 15 Jul 2003 06:25:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12777 for ; Tue, 15 Jul 2003 06:25:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cMzu-0000QI-00 for simple@ietf.org; Tue, 15 Jul 2003 06:25:26 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19cMzV-0000OA-00 for simple@ietf.org; Tue, 15 Jul 2003 06:25:01 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA00821; Tue, 15 Jul 2003 06:21:31 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA22259; Tue, 15 Jul 2003 06:21:31 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MTHQJ>; Tue, 15 Jul 2003 06:21:31 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5BF3@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , Ben Campbell Cc: Simple WG Subject: RE: [Simple] Tuple design team discussion summary MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 06:21:30 -0400 frankly, I think all you need is a device called phone, the rest is capabilities. It is the fact that the tuple is a phone that you can't deduce. It may actually be possible to just label it "device". I would not object to differentiating PC from phone, and text devices. There is the PDA, the problem there is the TREO-like devices, are they phones or PDAs? The others are "service" and I know we need a definition "user" (or "presentity, if you prefer) Both of these imply some sort of aggregation. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, July 15, 2003 4:38 AM > To: Ben Campbell > Cc: Simple WG > Subject: Re: [Simple] Tuple design team discussion summary > > > Almost none of the labels in RPIDS are exhaustive or claim to > be, so a > list is better than nothing. To make progress, I would like > to call for > nominations for such labels. The obvious ones are device-oriented ones > cell phone > PC > landline phone > text device (BlackBerry, SMS, TTY, ...) > other suggestions? > > Ben Campbell wrote: > > > > > I think even that can be handled cleanly. Such a device > just displays > > some default icon that indicates it does not know what type > of tuple it > > has. That is no different from common usage in many other > applications. > > For example, email attachments when your browser does not > recognize the > > mime type, or gets something completely generic like > > application/octet-stream without any other qualifiers. > > > > > > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Jul 15 06:27:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12885 for ; Tue, 15 Jul 2003 06:26:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cN11-0005Z3-3z for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 06:26:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FAQZo0021386 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 06:26:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cN10-0005Yr-Ub for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 06:26:34 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12845; Tue, 15 Jul 2003 06:26:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cN0U-0005Ow-AF; Tue, 15 Jul 2003 06:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cN04-0005O5-Vi for simple@optimus.ietf.org; Tue, 15 Jul 2003 06:25:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12777 for ; Tue, 15 Jul 2003 06:25:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cMzu-0000QI-00 for simple@ietf.org; Tue, 15 Jul 2003 06:25:26 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19cMzV-0000OA-00 for simple@ietf.org; Tue, 15 Jul 2003 06:25:01 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA00821; Tue, 15 Jul 2003 06:21:31 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA22259; Tue, 15 Jul 2003 06:21:31 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MTHQJ>; Tue, 15 Jul 2003 06:21:31 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5BF3@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , Ben Campbell Cc: Simple WG Subject: RE: [Simple] Tuple design team discussion summary MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 06:21:30 -0400 frankly, I think all you need is a device called phone, the rest is capabilities. It is the fact that the tuple is a phone that you can't deduce. It may actually be possible to just label it "device". I would not object to differentiating PC from phone, and text devices. There is the PDA, the problem there is the TREO-like devices, are they phones or PDAs? The others are "service" and I know we need a definition "user" (or "presentity, if you prefer) Both of these imply some sort of aggregation. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, July 15, 2003 4:38 AM > To: Ben Campbell > Cc: Simple WG > Subject: Re: [Simple] Tuple design team discussion summary > > > Almost none of the labels in RPIDS are exhaustive or claim to > be, so a > list is better than nothing. To make progress, I would like > to call for > nominations for such labels. The obvious ones are device-oriented ones > cell phone > PC > landline phone > text device (BlackBerry, SMS, TTY, ...) > other suggestions? > > Ben Campbell wrote: > > > > > I think even that can be handled cleanly. Such a device > just displays > > some default icon that indicates it does not know what type > of tuple it > > has. That is no different from common usage in many other > applications. > > For example, email attachments when your browser does not > recognize the > > mime type, or gets something completely generic like > > application/octet-stream without any other qualifiers. > > > > > > > > _______________________________________________ > 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-admin@ietf.org Tue Jul 15 06:30:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13075; Tue, 15 Jul 2003 06:30:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cN4L-0005no-9D; Tue, 15 Jul 2003 06:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cN3m-0005nP-JT for simple@optimus.ietf.org; Tue, 15 Jul 2003 06:29:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13007 for ; Tue, 15 Jul 2003 06:29:20 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cN3d-0000S2-00 for simple@ietf.org; Tue, 15 Jul 2003 06:29:17 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19cN3D-0000Qm-00 for simple@ietf.org; Tue, 15 Jul 2003 06:28:51 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6FAQek06766 for ; Tue, 15 Jul 2003 13:26:40 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 13:26:40 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 13:26:40 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 13:26:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] comments on rpids-01 (general, vCard, predictive) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F0B@esebe019.ntc.nokia.com> Thread-Topic: [Simple] comments on rpids-01 (general, vCard, predictive) Thread-Index: AcNKskpb7nT+osJCSQGdxas+lJrVQQACOcnw To: , Cc: X-OriginalArrivalTime: 15 Jul 2003 10:26:39.0796 (UTC) FILETIME=[93F20F40:01C34ABB] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 13:26:39 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, July 15, 2003 12:16 PM > To: Ben Campbell > Cc: Simpletons (E-mail) > Subject: Re: [Simple] comments on rpids-01 (general, vCard,=20 > predictive) >=20 >=20 > Ben Campbell wrote: >=20 > >=20 > >>From a user interface perspective, I have to concur. The=20 > whole point of > > icons representing state is to give me a quick visual way=20 > to determine > > that state. This only works if the icons are consistent. If every > > presentity I watch uses a different set of icons, then they=20 > are useless > > to me for that purpose. They become nothing but vanity=20 > plates for the > > presentities, or worse, a form of advertising. (In the same sense, I > > consider HTML favicons to be evil.) >=20 > I don't see why we need to mandate UI preferences. Sure, you=20 > should have=20 > the possibility of turning off favicons (or RPIDS icons), but=20 > they work=20 > well enough to be considered useful by people who build browsers that=20 > didn't have to implement them. I think noting that UA UIs=20 > should allow=20 > turning them off is a reasonable statements. The watcher can also filter them out. With mobile phones having cameras these days, sending a picture of the = bar I'm at is a much more fun and probably quicker and more accurate way = of describing where I am at this instance. A picture says a 1000 words. /Hisham >=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 exim@www1.ietf.org Tue Jul 15 06:30:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13104 for ; Tue, 15 Jul 2003 06:30:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cN4s-0005sj-7Z for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 06:30:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FAUYFu022595 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 06:30:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cN4s-0005sH-3X for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 06:30:34 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13075; Tue, 15 Jul 2003 06:30:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cN4L-0005no-9D; Tue, 15 Jul 2003 06:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cN3m-0005nP-JT for simple@optimus.ietf.org; Tue, 15 Jul 2003 06:29:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13007 for ; Tue, 15 Jul 2003 06:29:20 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cN3d-0000S2-00 for simple@ietf.org; Tue, 15 Jul 2003 06:29:17 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19cN3D-0000Qm-00 for simple@ietf.org; Tue, 15 Jul 2003 06:28:51 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6FAQek06766 for ; Tue, 15 Jul 2003 13:26:40 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 13:26:40 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 13:26:40 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 13:26:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] comments on rpids-01 (general, vCard, predictive) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F0B@esebe019.ntc.nokia.com> Thread-Topic: [Simple] comments on rpids-01 (general, vCard, predictive) Thread-Index: AcNKskpb7nT+osJCSQGdxas+lJrVQQACOcnw To: , Cc: X-OriginalArrivalTime: 15 Jul 2003 10:26:39.0796 (UTC) FILETIME=[93F20F40:01C34ABB] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 13:26:39 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, July 15, 2003 12:16 PM > To: Ben Campbell > Cc: Simpletons (E-mail) > Subject: Re: [Simple] comments on rpids-01 (general, vCard,=20 > predictive) >=20 >=20 > Ben Campbell wrote: >=20 > >=20 > >>From a user interface perspective, I have to concur. The=20 > whole point of > > icons representing state is to give me a quick visual way=20 > to determine > > that state. This only works if the icons are consistent. If every > > presentity I watch uses a different set of icons, then they=20 > are useless > > to me for that purpose. They become nothing but vanity=20 > plates for the > > presentities, or worse, a form of advertising. (In the same sense, I > > consider HTML favicons to be evil.) >=20 > I don't see why we need to mandate UI preferences. Sure, you=20 > should have=20 > the possibility of turning off favicons (or RPIDS icons), but=20 > they work=20 > well enough to be considered useful by people who build browsers that=20 > didn't have to implement them. I think noting that UA UIs=20 > should allow=20 > turning them off is a reasonable statements. The watcher can also filter them out. With mobile phones having cameras these days, sending a picture of the = bar I'm at is a much more fun and probably quicker and more accurate way = of describing where I am at this instance. A picture says a 1000 words. /Hisham >=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-admin@ietf.org Tue Jul 15 06:42:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13433; Tue, 15 Jul 2003 06:42:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cNGk-0000X4-00; Tue, 15 Jul 2003 06:42:50 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cNGA-0000Wc-00; Tue, 15 Jul 2003 06:42:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNFx-0006hQ-Ok; Tue, 15 Jul 2003 06:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNFd-0006h6-Jk for simple@optimus.ietf.org; Tue, 15 Jul 2003 06:41:41 -0400 Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13395 for ; Tue, 15 Jul 2003 06:41:34 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6FAfbk20500 for ; Tue, 15 Jul 2003 13:41:38 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 13:41:37 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 13:41:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] Tuple design team discussion summary Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F0C@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Tuple design team discussion summary Thread-Index: AcNKu5f0zGDE6hkmQNeNql9mwwBJhwAATucQ To: , , Cc: X-OriginalArrivalTime: 15 Jul 2003 10:41:37.0675 (UTC) FILETIME=[AB1F85B0:01C34ABD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 13:41:37 +0300 Content-Transfer-Encoding: quoted-printable I agree with Brian. I think we only ever discussed those 3: device, = service and user. We don't need to be very explicit, information in the = tuple give away the finer details about that thing that the tuple = represents.=20 Other than those 3, I haven't heard of other things that a tuple can = represent, unless we allow a combination of the 3 above (which I believe = we don't). Regards, Hisham > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, July 15, 2003 1:22 PM > To: 'Henning Schulzrinne'; Ben Campbell > Cc: Simple WG > Subject: RE: [Simple] Tuple design team discussion summary >=20 >=20 > frankly, I think all you need is a device called phone, > the rest is capabilities. It is the fact that the tuple is a phone > that you can't deduce. It may actually be possible to just > label it "device". I would not object to differentiating > PC from phone, and text devices. There is the PDA, > the problem there is the TREO-like devices, are they > phones or PDAs? >=20 > The others are > "service" and I know we need a definition > "user" (or "presentity, if you prefer) > Both of these imply some sort of aggregation. >=20 >=20 >=20 > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, July 15, 2003 4:38 AM > > To: Ben Campbell > > Cc: Simple WG > > Subject: Re: [Simple] Tuple design team discussion summary > >=20 > >=20 > > Almost none of the labels in RPIDS are exhaustive or claim to=20 > > be, so a=20 > > list is better than nothing. To make progress, I would like=20 > > to call for=20 > > nominations for such labels. The obvious ones are=20 > device-oriented ones > > cell phone > > PC > > landline phone > > text device (BlackBerry, SMS, TTY, ...) > > other suggestions? > >=20 > > Ben Campbell wrote: > >=20 > > >=20 > > > I think even that can be handled cleanly. Such a device=20 > > just displays=20 > > > some default icon that indicates it does not know what type=20 > > of tuple it > > > has. That is no different from common usage in many other=20 > > applications. > > > For example, email attachments when your browser does not=20 > > recognize the > > > mime type, or gets something completely generic like > > > application/octet-stream without any other qualifiers. > > >=20 > >=20 > >=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 exim@www1.ietf.org Tue Jul 15 06:43:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13457 for ; Tue, 15 Jul 2003 06:43:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNGz-0006m9-4s for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 06:43:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FAh5vD026039 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 06:43:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNGz-0006lu-1Z for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 06:43:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13433; Tue, 15 Jul 2003 06:42:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cNGk-0000X4-00; Tue, 15 Jul 2003 06:42:50 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cNGA-0000Wc-00; Tue, 15 Jul 2003 06:42:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNFx-0006hQ-Ok; Tue, 15 Jul 2003 06:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNFd-0006h6-Jk for simple@optimus.ietf.org; Tue, 15 Jul 2003 06:41:41 -0400 Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13395 for ; Tue, 15 Jul 2003 06:41:34 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6FAfbk20500 for ; Tue, 15 Jul 2003 13:41:38 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 13:41:37 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 13:41:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] Tuple design team discussion summary Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F0C@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Tuple design team discussion summary Thread-Index: AcNKu5f0zGDE6hkmQNeNql9mwwBJhwAATucQ To: , , Cc: X-OriginalArrivalTime: 15 Jul 2003 10:41:37.0675 (UTC) FILETIME=[AB1F85B0:01C34ABD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 13:41:37 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree with Brian. I think we only ever discussed those 3: device, = service and user. We don't need to be very explicit, information in the = tuple give away the finer details about that thing that the tuple = represents.=20 Other than those 3, I haven't heard of other things that a tuple can = represent, unless we allow a combination of the 3 above (which I believe = we don't). Regards, Hisham > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, July 15, 2003 1:22 PM > To: 'Henning Schulzrinne'; Ben Campbell > Cc: Simple WG > Subject: RE: [Simple] Tuple design team discussion summary >=20 >=20 > frankly, I think all you need is a device called phone, > the rest is capabilities. It is the fact that the tuple is a phone > that you can't deduce. It may actually be possible to just > label it "device". I would not object to differentiating > PC from phone, and text devices. There is the PDA, > the problem there is the TREO-like devices, are they > phones or PDAs? >=20 > The others are > "service" and I know we need a definition > "user" (or "presentity, if you prefer) > Both of these imply some sort of aggregation. >=20 >=20 >=20 > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, July 15, 2003 4:38 AM > > To: Ben Campbell > > Cc: Simple WG > > Subject: Re: [Simple] Tuple design team discussion summary > >=20 > >=20 > > Almost none of the labels in RPIDS are exhaustive or claim to=20 > > be, so a=20 > > list is better than nothing. To make progress, I would like=20 > > to call for=20 > > nominations for such labels. The obvious ones are=20 > device-oriented ones > > cell phone > > PC > > landline phone > > text device (BlackBerry, SMS, TTY, ...) > > other suggestions? > >=20 > > Ben Campbell wrote: > >=20 > > >=20 > > > I think even that can be handled cleanly. Such a device=20 > > just displays=20 > > > some default icon that indicates it does not know what type=20 > > of tuple it > > > has. That is no different from common usage in many other=20 > > applications. > > > For example, email attachments when your browser does not=20 > > recognize the > > > mime type, or gets something completely generic like > > > application/octet-stream without any other qualifiers. > > >=20 > >=20 > >=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-admin@ietf.org Tue Jul 15 07:13:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14134; Tue, 15 Jul 2003 07:13:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cNjs-0000iv-00; Tue, 15 Jul 2003 07:12:56 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cNjJ-0000iT-00; Tue, 15 Jul 2003 07:12:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNiz-0007r2-6e; Tue, 15 Jul 2003 07:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNib-0007qg-M9 for simple@optimus.ietf.org; Tue, 15 Jul 2003 07:11:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14089 for ; Tue, 15 Jul 2003 07:11:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cNiS-0000i1-00 for simple@ietf.org; Tue, 15 Jul 2003 07:11:28 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cNhx-0000hT-00 for simple@ietf.org; Tue, 15 Jul 2003 07:10:57 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6FB9HkM005506; Tue, 15 Jul 2003 07:09:17 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6FB9Gg22333; Tue, 15 Jul 2003 07:09:16 -0400 Message-ID: <3F13DFE5.7050708@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: Brian.Rosen@marconi.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Tuple design team discussion summary References: <2038BCC78B1AD641891A0D1AE133DBB701796F0C@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796F0C@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 07:05:09 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > I agree with Brian. I think we only ever discussed those 3: device, > service and user. We don't need to be very explicit, information in > the tuple give away the finer details about that thing that the tuple > represents. > > Other than those 3, I haven't heard of other things that a tuple can > represent, unless we allow a combination of the 3 above (which I > believe we don't). To beat a horse carcass: While device and 'user' has reasonable definitions, nobody, after a year+, has provided an operational definition of service. Since this label needs to be understandable by people who have not participated in the Tuple Theory 745 class (this is graduate-level stuff...), I don't think an elaborate definition helps. 'device', 'user' and 'other' seem to work ok, which seems to be close enough. (Earlier versions of RPIDS had an approximation to such an element, with the addition of 'group'.) For those, there are reasonable pictograms, too - phone, stick person and ?. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 07:13:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14153 for ; Tue, 15 Jul 2003 07:13:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNk4-0007ul-1S for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 07:13:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FBD8p4030417 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 07:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNk3-0007uW-Tq for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 07:13:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14134; Tue, 15 Jul 2003 07:13:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cNjs-0000iv-00; Tue, 15 Jul 2003 07:12:56 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cNjJ-0000iT-00; Tue, 15 Jul 2003 07:12:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNiz-0007r2-6e; Tue, 15 Jul 2003 07:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNib-0007qg-M9 for simple@optimus.ietf.org; Tue, 15 Jul 2003 07:11:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14089 for ; Tue, 15 Jul 2003 07:11:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cNiS-0000i1-00 for simple@ietf.org; Tue, 15 Jul 2003 07:11:28 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cNhx-0000hT-00 for simple@ietf.org; Tue, 15 Jul 2003 07:10:57 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6FB9HkM005506; Tue, 15 Jul 2003 07:09:17 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6FB9Gg22333; Tue, 15 Jul 2003 07:09:16 -0400 Message-ID: <3F13DFE5.7050708@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: Brian.Rosen@marconi.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Tuple design team discussion summary References: <2038BCC78B1AD641891A0D1AE133DBB701796F0C@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796F0C@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 07:05:09 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > I agree with Brian. I think we only ever discussed those 3: device, > service and user. We don't need to be very explicit, information in > the tuple give away the finer details about that thing that the tuple > represents. > > Other than those 3, I haven't heard of other things that a tuple can > represent, unless we allow a combination of the 3 above (which I > believe we don't). To beat a horse carcass: While device and 'user' has reasonable definitions, nobody, after a year+, has provided an operational definition of service. Since this label needs to be understandable by people who have not participated in the Tuple Theory 745 class (this is graduate-level stuff...), I don't think an elaborate definition helps. 'device', 'user' and 'other' seem to work ok, which seems to be close enough. (Earlier versions of RPIDS had an approximation to such an element, with the addition of 'group'.) For those, there are reasonable pictograms, too - phone, stick person and ?. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 07:27:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14457; Tue, 15 Jul 2003 07:27:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cNxN-0000mO-00; Tue, 15 Jul 2003 07:26:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cNwo-0000mA-00; Tue, 15 Jul 2003 07:26:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNwX-0008Fi-6v; Tue, 15 Jul 2003 07:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNvc-0008FD-Hm for simple@optimus.ietf.org; Tue, 15 Jul 2003 07:25:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14367 for ; Tue, 15 Jul 2003 07:25:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cNvW-0000ll-00 for simple@ietf.org; Tue, 15 Jul 2003 07:24:59 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cNv2-0000lZ-00 for simple@ietf.org; Tue, 15 Jul 2003 07:24:28 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6FBNtkM006607; Tue, 15 Jul 2003 07:23:55 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6FBNpg23509; Tue, 15 Jul 2003 07:23:52 -0400 Message-ID: <3F13E34E.9040706@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C54@stntexch2.va.neustar.com> <3F039C6B.3020305@cs.columbia.edu> <3F116046.3040707@dynamicsoft.com> <3F1167A8.3020203@cs.columbia.edu> <3F134F25.9080304@dynamicsoft.com> In-Reply-To: <3F134F25.9080304@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 07:19:42 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Well, those would be different. This is for homepages. I'm not saying > that other things arent useful, I'm just saying that, since this > information will be consumed by automata and not just rendered, we need > to be as precise as possible about what it means. I view an ldap: reference as a structured homepage, given that most homepages contain information on how to contact a person and that most browsers render LDAP URI as an HTML page. However, I doubt that it's worth making this a major issue, if we can describe the content appropriately. I gather you want to limit this "web home page". _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 07:27:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14477 for ; Tue, 15 Jul 2003 07:27:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNxZ-0008LO-Im for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 07:27:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FBR5tL032072 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 07:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNxZ-0008LC-EX for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 07:27:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14457; Tue, 15 Jul 2003 07:27:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cNxN-0000mO-00; Tue, 15 Jul 2003 07:26:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cNwo-0000mA-00; Tue, 15 Jul 2003 07:26:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNwX-0008Fi-6v; Tue, 15 Jul 2003 07:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNvc-0008FD-Hm for simple@optimus.ietf.org; Tue, 15 Jul 2003 07:25:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14367 for ; Tue, 15 Jul 2003 07:25:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cNvW-0000ll-00 for simple@ietf.org; Tue, 15 Jul 2003 07:24:59 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cNv2-0000lZ-00 for simple@ietf.org; Tue, 15 Jul 2003 07:24:28 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6FBNtkM006607; Tue, 15 Jul 2003 07:23:55 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6FBNpg23509; Tue, 15 Jul 2003 07:23:52 -0400 Message-ID: <3F13E34E.9040706@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C54@stntexch2.va.neustar.com> <3F039C6B.3020305@cs.columbia.edu> <3F116046.3040707@dynamicsoft.com> <3F1167A8.3020203@cs.columbia.edu> <3F134F25.9080304@dynamicsoft.com> In-Reply-To: <3F134F25.9080304@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 07:19:42 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Well, those would be different. This is for homepages. I'm not saying > that other things arent useful, I'm just saying that, since this > information will be consumed by automata and not just rendered, we need > to be as precise as possible about what it means. I view an ldap: reference as a structured homepage, given that most homepages contain information on how to contact a person and that most browsers render LDAP URI as an HTML page. However, I doubt that it's worth making this a major issue, if we can describe the content appropriately. I gather you want to limit this "web home page". _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 07:31:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14787; Tue, 15 Jul 2003 07:31:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cO1O-000071-7f; Tue, 15 Jul 2003 07:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cO0W-00004s-4K for simple@optimus.ietf.org; Tue, 15 Jul 2003 07:30:08 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14657 for ; Tue, 15 Jul 2003 07:30:04 -0400 (EDT) Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6FBU5kM009026; Tue, 15 Jul 2003 07:30:05 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6FBU2g23993; Tue, 15 Jul 2003 07:30:02 -0400 Message-ID: <3F13E4C2.5030107@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Peterson, Jon" , simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - face-to-face References: <0449D80A0E9B614A83FA9031B07E8D3B257C1D@stntexch2.va.neustar.com> <3EFDB74A.7040707@cs.columbia.edu> <3F116087.5020701@dynamicsoft.com> <3F11681E.5000908@cs.columbia.edu> <3F134EC5.6050803@dynamicsoft.com> In-Reply-To: <3F134EC5.6050803@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 07:25:54 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > So, then why is it a capability at all? A capability is a capability, no > matter whether its represented in a presence doc or in a URI parameter. I agree that this can easily be elsewhere; it's probably a tuple-level parameter. Might this be a fourth label, next to 'device', 'presentity' and 'other'? After all, it would probably not be nice to humans to qualify a face-to-face contact as a 'device'. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 07:32:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14807 for ; Tue, 15 Jul 2003 07:32:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cO1w-0000Fm-6c for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 07:31:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FBVagK000959 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 07:31:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cO1w-0000FO-1o for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 07:31:36 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14787; Tue, 15 Jul 2003 07:31:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cO1O-000071-7f; Tue, 15 Jul 2003 07:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cO0W-00004s-4K for simple@optimus.ietf.org; Tue, 15 Jul 2003 07:30:08 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14657 for ; Tue, 15 Jul 2003 07:30:04 -0400 (EDT) Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6FBU5kM009026; Tue, 15 Jul 2003 07:30:05 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6FBU2g23993; Tue, 15 Jul 2003 07:30:02 -0400 Message-ID: <3F13E4C2.5030107@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Peterson, Jon" , simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - face-to-face References: <0449D80A0E9B614A83FA9031B07E8D3B257C1D@stntexch2.va.neustar.com> <3EFDB74A.7040707@cs.columbia.edu> <3F116087.5020701@dynamicsoft.com> <3F11681E.5000908@cs.columbia.edu> <3F134EC5.6050803@dynamicsoft.com> In-Reply-To: <3F134EC5.6050803@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 07:25:54 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > So, then why is it a capability at all? A capability is a capability, no > matter whether its represented in a presence doc or in a URI parameter. I agree that this can easily be elsewhere; it's probably a tuple-level parameter. Might this be a fourth label, next to 'device', 'presentity' and 'other'? After all, it would probably not be nice to humans to qualify a face-to-face contact as a 'device'. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 07:41:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15199; Tue, 15 Jul 2003 07:41:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cOB3-0000qI-Bx; Tue, 15 Jul 2003 07:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cOB0-0000pv-DX for simple@optimus.ietf.org; Tue, 15 Jul 2003 07:40:58 -0400 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15185 for ; Tue, 15 Jul 2003 07:40:54 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA01977; Tue, 15 Jul 2003 07:40:25 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA27746; Tue, 15 Jul 2003 07:40:22 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MT2QX>; Tue, 15 Jul 2003 07:40:22 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5BF5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , hisham.khartabil@nokia.com Cc: bcampbell@dynamicsoft.com, simple@ietf.org Subject: RE: [Simple] Tuple design team discussion summary MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 07:40:21 -0400 For this purpose, a service is a tuple representing a communications path to a set of devices that have some common characteristics. The tuple contains the URI to the service, and the characteristics (capabilities) of the service. The service endeavors to deliver a request for communication to an appropriate device from the set of devices it controls. The presence information presented by the service is represents that of the service as a whole, rather than that of one of its constituent devices. It is NOT necessarily a simple pivot of device presence information. The service may have additional information, and it may combine information in ways not expressible as a pivot of the device data. A service is differentiated from a device in that the URI explicitly represents the services, requests for communication will be forwarded to one of the devices the service controls. A service is differentiated from a user in that a user may have multiple services, each of which may have separate presence tuples. Normally, a user has a single tuple representing the presence of the user as a person. You can think of this as a hierarchy, where a user has a set of services each of which has a set of devices. Nothing limits the hierarchy to two levels (a service could aggregate multiple services, although I can't think of an example that makes a lot of sense). It's also possible to have a user who doesn't have services. In that case he has a set of devices that are aggregated directly to form the user tuple. The service is equal to device. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, July 15, 2003 7:05 AM > To: hisham.khartabil@nokia.com > Cc: Brian.Rosen@marconi.com; bcampbell@dynamicsoft.com; > simple@ietf.org > Subject: Re: [Simple] Tuple design team discussion summary > > > hisham.khartabil@nokia.com wrote: > > > I agree with Brian. I think we only ever discussed those 3: device, > > service and user. We don't need to be very explicit, information in > > the tuple give away the finer details about that thing that > the tuple > > represents. > > > > Other than those 3, I haven't heard of other things that a tuple can > > represent, unless we allow a combination of the 3 above (which I > > believe we don't). > > To beat a horse carcass: While device and 'user' has reasonable > definitions, nobody, after a year+, has provided an operational > definition of service. Since this label needs to be understandable by > people who have not participated in the Tuple Theory 745 > class (this is > graduate-level stuff...), I don't think an elaborate definition helps. > > 'device', 'user' and 'other' seem to work ok, which seems to be close > enough. (Earlier versions of RPIDS had an approximation to such an > element, with the addition of 'group'.) For those, there are > reasonable > pictograms, too - phone, stick person and ?. > > 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 exim@www1.ietf.org Tue Jul 15 07:42:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15228 for ; Tue, 15 Jul 2003 07:42:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cOBa-0000vR-KL for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 07:41:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FBfYpb003553 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 07:41:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cOBa-0000vE-FI for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 07:41:34 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15199; Tue, 15 Jul 2003 07:41:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cOB3-0000qI-Bx; Tue, 15 Jul 2003 07:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cOB0-0000pv-DX for simple@optimus.ietf.org; Tue, 15 Jul 2003 07:40:58 -0400 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15185 for ; Tue, 15 Jul 2003 07:40:54 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA01977; Tue, 15 Jul 2003 07:40:25 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA27746; Tue, 15 Jul 2003 07:40:22 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MT2QX>; Tue, 15 Jul 2003 07:40:22 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5BF5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , hisham.khartabil@nokia.com Cc: bcampbell@dynamicsoft.com, simple@ietf.org Subject: RE: [Simple] Tuple design team discussion summary MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 07:40:21 -0400 For this purpose, a service is a tuple representing a communications path to a set of devices that have some common characteristics. The tuple contains the URI to the service, and the characteristics (capabilities) of the service. The service endeavors to deliver a request for communication to an appropriate device from the set of devices it controls. The presence information presented by the service is represents that of the service as a whole, rather than that of one of its constituent devices. It is NOT necessarily a simple pivot of device presence information. The service may have additional information, and it may combine information in ways not expressible as a pivot of the device data. A service is differentiated from a device in that the URI explicitly represents the services, requests for communication will be forwarded to one of the devices the service controls. A service is differentiated from a user in that a user may have multiple services, each of which may have separate presence tuples. Normally, a user has a single tuple representing the presence of the user as a person. You can think of this as a hierarchy, where a user has a set of services each of which has a set of devices. Nothing limits the hierarchy to two levels (a service could aggregate multiple services, although I can't think of an example that makes a lot of sense). It's also possible to have a user who doesn't have services. In that case he has a set of devices that are aggregated directly to form the user tuple. The service is equal to device. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, July 15, 2003 7:05 AM > To: hisham.khartabil@nokia.com > Cc: Brian.Rosen@marconi.com; bcampbell@dynamicsoft.com; > simple@ietf.org > Subject: Re: [Simple] Tuple design team discussion summary > > > hisham.khartabil@nokia.com wrote: > > > I agree with Brian. I think we only ever discussed those 3: device, > > service and user. We don't need to be very explicit, information in > > the tuple give away the finer details about that thing that > the tuple > > represents. > > > > Other than those 3, I haven't heard of other things that a tuple can > > represent, unless we allow a combination of the 3 above (which I > > believe we don't). > > To beat a horse carcass: While device and 'user' has reasonable > definitions, nobody, after a year+, has provided an operational > definition of service. Since this label needs to be understandable by > people who have not participated in the Tuple Theory 745 > class (this is > graduate-level stuff...), I don't think an elaborate definition helps. > > 'device', 'user' and 'other' seem to work ok, which seems to be close > enough. (Earlier versions of RPIDS had an approximation to such an > element, with the addition of 'group'.) For those, there are > reasonable > pictograms, too - phone, stick person and ?. > > 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-admin@ietf.org Tue Jul 15 08:35:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16323; Tue, 15 Jul 2003 08:35:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cP1V-0001UB-00; Tue, 15 Jul 2003 08:35:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cP0v-0001Tu-00; Tue, 15 Jul 2003 08:34:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cP0K-0002wh-PW; Tue, 15 Jul 2003 08:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cOzW-0002uz-Vt for simple@optimus.ietf.org; Tue, 15 Jul 2003 08:33:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16297 for ; Tue, 15 Jul 2003 08:33:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cOzQ-0001Ta-00 for simple@ietf.org; Tue, 15 Jul 2003 08:33:04 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19cOyz-0001TE-00 for simple@ietf.org; Tue, 15 Jul 2003 08:32:37 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Tue, 15 Jul 2003 13:35:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Simple] Tuple design team discussion summary Message-ID: <45730E094814E44488F789C1CDED27AE0219B029@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Tuple design team discussion summary Thread-Index: AcNKxeqWQNZOKlYZT0uwoOWG/DhKQgABk8l7 From: "Chris Boulton" To: "Rosen, Brian" , "Henning Schulzrinne" , Cc: , Content-Transfer-Encoding: base64 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 13:31:35 +0100 Content-Transfer-Encoding: base64 QnJpYW4sDQpUaGlzIHN0cnVjdHVyZSBzZWVtcyByZWFzb25hYmxlIHRvIG1lIC0gT25lIHF1ZXN0 aW9uLCBJIHVuZGVyc3RhbmQgdGhhdCBhIHVzZXIgVHVwbGUgd291bGQgYmUgcHJlc2VudCB3aXRo IG11bHRpcGxlIHNlcnZpY2UgdHVwbGVzLiAgSG93IGFyZSB0aGUgZGV2aWNlIHR1cGxlcyBhc3Nv Y2lhdGVkIHdpdGggdGhlIGNvcnJlY3Qgc2VydmljZSB0dXBsZXMgKG1heWJlIHRoaXMgaXMgY2xl YXIgYW5kIEkgYW0gbWlzc2luZyBzb21ldGhpbmcpIC0gY291bGQgdGhlIGNsYXNzIGF0dHJpYnV0 ZSBiZSB1c2VkPw0KIA0KQ2hyaXMuDQogDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSAN CglGcm9tOiBSb3NlbiwgQnJpYW4gW21haWx0bzpCcmlhbi5Sb3NlbkBtYXJjb25pLmNvbV0gDQoJ U2VudDogVHVlIDE1LzA3LzIwMDMgMTI6NDAgDQoJVG86ICdIZW5uaW5nIFNjaHVsenJpbm5lJzsg aGlzaGFtLmtoYXJ0YWJpbEBub2tpYS5jb20gDQoJQ2M6IGJjYW1wYmVsbEBkeW5hbWljc29mdC5j b207IHNpbXBsZUBpZXRmLm9yZyANCglTdWJqZWN0OiBSRTogW1NpbXBsZV0gVHVwbGUgZGVzaWdu IHRlYW0gZGlzY3Vzc2lvbiBzdW1tYXJ5DQoJDQoJDQoNCglGb3IgdGhpcyBwdXJwb3NlLCBhIHNl cnZpY2UgaXMgYSB0dXBsZSByZXByZXNlbnRpbmcgYSBjb21tdW5pY2F0aW9ucw0KCXBhdGggdG8g YSBzZXQgb2YgZGV2aWNlcyB0aGF0IGhhdmUgc29tZSBjb21tb24gY2hhcmFjdGVyaXN0aWNzLg0K CVRoZSB0dXBsZSBjb250YWlucyB0aGUgVVJJIHRvIHRoZSBzZXJ2aWNlLCBhbmQgdGhlIGNoYXJh Y3RlcmlzdGljcw0KCShjYXBhYmlsaXRpZXMpDQoJb2YgdGhlIHNlcnZpY2UuDQoJDQoJVGhlIHNl cnZpY2UgZW5kZWF2b3JzIHRvIGRlbGl2ZXIgYSByZXF1ZXN0IGZvciBjb21tdW5pY2F0aW9uIHRv IGFuDQoJYXBwcm9wcmlhdGUNCglkZXZpY2UgZnJvbSB0aGUgc2V0IG9mIGRldmljZXMgaXQgY29u dHJvbHMuICBUaGUgcHJlc2VuY2UgaW5mb3JtYXRpb24NCglwcmVzZW50ZWQgYnkgdGhlIHNlcnZp Y2UgaXMgcmVwcmVzZW50cyB0aGF0IG9mIHRoZSBzZXJ2aWNlIGFzIGEgd2hvbGUsDQoJcmF0aGVy IHRoYW4gdGhhdCBvZiBvbmUgb2YgaXRzIGNvbnN0aXR1ZW50IGRldmljZXMuICBJdCBpcyBOT1QN CgluZWNlc3NhcmlseSBhIHNpbXBsZSBwaXZvdCBvZiBkZXZpY2UgcHJlc2VuY2UgaW5mb3JtYXRp b24uICBUaGUgc2VydmljZQ0KCW1heSBoYXZlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sIGFuZCBp dCBtYXkgY29tYmluZSBpbmZvcm1hdGlvbiBpbg0KCXdheXMgbm90IGV4cHJlc3NpYmxlIGFzIGEg cGl2b3Qgb2YgdGhlIGRldmljZSBkYXRhLg0KCQ0KCUEgc2VydmljZSBpcyBkaWZmZXJlbnRpYXRl ZCBmcm9tIGEgZGV2aWNlIGluIHRoYXQgdGhlIFVSSSBleHBsaWNpdGx5DQoJcmVwcmVzZW50cyB0 aGUgc2VydmljZXMsIHJlcXVlc3RzIGZvciBjb21tdW5pY2F0aW9uIHdpbGwgYmUgZm9yd2FyZGVk DQoJdG8gb25lIG9mIHRoZSBkZXZpY2VzIHRoZSBzZXJ2aWNlIGNvbnRyb2xzLg0KCQ0KCUEgc2Vy dmljZSBpcyBkaWZmZXJlbnRpYXRlZCBmcm9tIGEgdXNlciBpbiB0aGF0IGEgdXNlciBtYXkgaGF2 ZQ0KCW11bHRpcGxlIHNlcnZpY2VzLCBlYWNoIG9mIHdoaWNoIG1heSBoYXZlIHNlcGFyYXRlIHBy ZXNlbmNlIHR1cGxlcy4NCglOb3JtYWxseSwgYSB1c2VyIGhhcyBhIHNpbmdsZSB0dXBsZSByZXBy ZXNlbnRpbmcgdGhlIHByZXNlbmNlIG9mDQoJdGhlIHVzZXIgYXMgYSBwZXJzb24uDQoJDQoJWW91 IGNhbiB0aGluayBvZiB0aGlzIGFzIGEgaGllcmFyY2h5LCB3aGVyZSBhIHVzZXIgaGFzIGEgc2V0 IG9mDQoJc2VydmljZXMgZWFjaCBvZiB3aGljaCBoYXMgYSBzZXQgb2YgZGV2aWNlcy4gIE5vdGhp bmcgbGltaXRzDQoJdGhlIGhpZXJhcmNoeSB0byB0d28gbGV2ZWxzIChhIHNlcnZpY2UgY291bGQg YWdncmVnYXRlIG11bHRpcGxlDQoJc2VydmljZXMsIGFsdGhvdWdoIEkgY2FuJ3QgdGhpbmsgb2Yg YW4gZXhhbXBsZSB0aGF0IG1ha2VzIGEgbG90DQoJb2Ygc2Vuc2UpLiAgSXQncyBhbHNvIHBvc3Np YmxlIHRvIGhhdmUgYSB1c2VyIHdobyBkb2Vzbid0IGhhdmUNCglzZXJ2aWNlcy4gIEluIHRoYXQg Y2FzZSBoZSBoYXMgYSBzZXQgb2YgZGV2aWNlcyB0aGF0IGFyZSBhZ2dyZWdhdGVkDQoJZGlyZWN0 bHkgdG8gZm9ybSB0aGUgdXNlciB0dXBsZS4gIFRoZSBzZXJ2aWNlIGlzIGVxdWFsIHRvIGRldmlj ZS4NCgkNCglCcmlhbg0KCQ0KCT4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgk+IEZyb206 IEhlbm5pbmcgU2NodWx6cmlubmUgW21haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1XQ0KCT4gU2Vu dDogVHVlc2RheSwgSnVseSAxNSwgMjAwMyA3OjA1IEFNDQoJPiBUbzogaGlzaGFtLmtoYXJ0YWJp bEBub2tpYS5jb20NCgk+IENjOiBCcmlhbi5Sb3NlbkBtYXJjb25pLmNvbTsgYmNhbXBiZWxsQGR5 bmFtaWNzb2Z0LmNvbTsNCgk+IHNpbXBsZUBpZXRmLm9yZw0KCT4gU3ViamVjdDogUmU6IFtTaW1w bGVdIFR1cGxlIGRlc2lnbiB0ZWFtIGRpc2N1c3Npb24gc3VtbWFyeQ0KCT4NCgk+DQoJPiBoaXNo YW0ua2hhcnRhYmlsQG5va2lhLmNvbSB3cm90ZToNCgk+DQoJPiA+IEkgYWdyZWUgd2l0aCBCcmlh bi4gSSB0aGluayB3ZSBvbmx5IGV2ZXIgZGlzY3Vzc2VkIHRob3NlIDM6IGRldmljZSwNCgk+ID4g c2VydmljZSBhbmQgdXNlci4gV2UgZG9uJ3QgbmVlZCB0byBiZSB2ZXJ5IGV4cGxpY2l0LCBpbmZv cm1hdGlvbiBpbg0KCT4gPiB0aGUgdHVwbGUgZ2l2ZSBhd2F5IHRoZSBmaW5lciBkZXRhaWxzIGFi b3V0IHRoYXQgdGhpbmcgdGhhdA0KCT4gdGhlIHR1cGxlDQoJPiA+IHJlcHJlc2VudHMuDQoJPiA+ DQoJPiA+IE90aGVyIHRoYW4gdGhvc2UgMywgSSBoYXZlbid0IGhlYXJkIG9mIG90aGVyIHRoaW5n cyB0aGF0IGEgdHVwbGUgY2FuDQoJPiA+IHJlcHJlc2VudCwgdW5sZXNzIHdlIGFsbG93IGEgY29t YmluYXRpb24gb2YgdGhlIDMgYWJvdmUgKHdoaWNoIEkNCgk+ID4gYmVsaWV2ZSB3ZSBkb24ndCku DQoJPg0KCT4gVG8gYmVhdCBhIGhvcnNlIGNhcmNhc3M6IFdoaWxlIGRldmljZSBhbmQgJ3VzZXIn IGhhcyByZWFzb25hYmxlDQoJPiBkZWZpbml0aW9ucywgbm9ib2R5LCBhZnRlciBhIHllYXIrLCBo YXMgcHJvdmlkZWQgYW4gb3BlcmF0aW9uYWwNCgk+IGRlZmluaXRpb24gb2Ygc2VydmljZS4gU2lu Y2UgdGhpcyBsYWJlbCBuZWVkcyB0byBiZSB1bmRlcnN0YW5kYWJsZSBieQ0KCT4gcGVvcGxlIHdo byBoYXZlIG5vdCBwYXJ0aWNpcGF0ZWQgaW4gdGhlIFR1cGxlIFRoZW9yeSA3NDUNCgk+IGNsYXNz ICh0aGlzIGlzDQoJPiBncmFkdWF0ZS1sZXZlbCBzdHVmZi4uLiksIEkgZG9uJ3QgdGhpbmsgYW4g ZWxhYm9yYXRlIGRlZmluaXRpb24gaGVscHMuDQoJPg0KCT4gJ2RldmljZScsICd1c2VyJyBhbmQg J290aGVyJyBzZWVtIHRvIHdvcmsgb2ssIHdoaWNoIHNlZW1zIHRvIGJlIGNsb3NlDQoJPiBlbm91 Z2guIChFYXJsaWVyIHZlcnNpb25zIG9mIFJQSURTIGhhZCBhbiBhcHByb3hpbWF0aW9uIHRvIHN1 Y2ggYW4NCgk+IGVsZW1lbnQsIHdpdGggdGhlIGFkZGl0aW9uIG9mICdncm91cCcuKSBGb3IgdGhv c2UsIHRoZXJlIGFyZQ0KCT4gcmVhc29uYWJsZQ0KCT4gcGljdG9ncmFtcywgdG9vIC0gcGhvbmUs IHN0aWNrIHBlcnNvbiBhbmQgPy4NCgk+DQoJPiBIZW5uaW5nDQoJPg0KCT4NCgk+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJPiBTaW1wbGUgbWFpbGlu ZyBsaXN0DQoJPiBTaW1wbGVAaWV0Zi5vcmcNCgk+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpbXBsZQ0KCT4NCgkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KCVNpbXBsZSBtYWlsaW5nIGxpc3QNCglTaW1wbGVAaWV0Zi5v cmcNCglodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUNCgkNCg0K _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 08:35:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16349 for ; Tue, 15 Jul 2003 08:35:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cP1i-00033p-DL for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 08:35:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FCZQgj011764 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 08:35:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cP1i-00033f-6I for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 08:35:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16323; Tue, 15 Jul 2003 08:35:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cP1V-0001UB-00; Tue, 15 Jul 2003 08:35:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cP0v-0001Tu-00; Tue, 15 Jul 2003 08:34:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cP0K-0002wh-PW; Tue, 15 Jul 2003 08:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cOzW-0002uz-Vt for simple@optimus.ietf.org; Tue, 15 Jul 2003 08:33:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16297 for ; Tue, 15 Jul 2003 08:33:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cOzQ-0001Ta-00 for simple@ietf.org; Tue, 15 Jul 2003 08:33:04 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19cOyz-0001TE-00 for simple@ietf.org; Tue, 15 Jul 2003 08:32:37 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Tue, 15 Jul 2003 13:35:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Simple] Tuple design team discussion summary Message-ID: <45730E094814E44488F789C1CDED27AE0219B029@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Tuple design team discussion summary Thread-Index: AcNKxeqWQNZOKlYZT0uwoOWG/DhKQgABk8l7 From: "Chris Boulton" To: "Rosen, Brian" , "Henning Schulzrinne" , Cc: , Content-Transfer-Encoding: base64 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 13:31:35 +0100 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QnJpYW4sDQpUaGlzIHN0cnVjdHVyZSBzZWVtcyByZWFzb25hYmxlIHRvIG1lIC0gT25lIHF1ZXN0 aW9uLCBJIHVuZGVyc3RhbmQgdGhhdCBhIHVzZXIgVHVwbGUgd291bGQgYmUgcHJlc2VudCB3aXRo IG11bHRpcGxlIHNlcnZpY2UgdHVwbGVzLiAgSG93IGFyZSB0aGUgZGV2aWNlIHR1cGxlcyBhc3Nv Y2lhdGVkIHdpdGggdGhlIGNvcnJlY3Qgc2VydmljZSB0dXBsZXMgKG1heWJlIHRoaXMgaXMgY2xl YXIgYW5kIEkgYW0gbWlzc2luZyBzb21ldGhpbmcpIC0gY291bGQgdGhlIGNsYXNzIGF0dHJpYnV0 ZSBiZSB1c2VkPw0KIA0KQ2hyaXMuDQogDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSAN CglGcm9tOiBSb3NlbiwgQnJpYW4gW21haWx0bzpCcmlhbi5Sb3NlbkBtYXJjb25pLmNvbV0gDQoJ U2VudDogVHVlIDE1LzA3LzIwMDMgMTI6NDAgDQoJVG86ICdIZW5uaW5nIFNjaHVsenJpbm5lJzsg aGlzaGFtLmtoYXJ0YWJpbEBub2tpYS5jb20gDQoJQ2M6IGJjYW1wYmVsbEBkeW5hbWljc29mdC5j b207IHNpbXBsZUBpZXRmLm9yZyANCglTdWJqZWN0OiBSRTogW1NpbXBsZV0gVHVwbGUgZGVzaWdu IHRlYW0gZGlzY3Vzc2lvbiBzdW1tYXJ5DQoJDQoJDQoNCglGb3IgdGhpcyBwdXJwb3NlLCBhIHNl cnZpY2UgaXMgYSB0dXBsZSByZXByZXNlbnRpbmcgYSBjb21tdW5pY2F0aW9ucw0KCXBhdGggdG8g YSBzZXQgb2YgZGV2aWNlcyB0aGF0IGhhdmUgc29tZSBjb21tb24gY2hhcmFjdGVyaXN0aWNzLg0K CVRoZSB0dXBsZSBjb250YWlucyB0aGUgVVJJIHRvIHRoZSBzZXJ2aWNlLCBhbmQgdGhlIGNoYXJh Y3RlcmlzdGljcw0KCShjYXBhYmlsaXRpZXMpDQoJb2YgdGhlIHNlcnZpY2UuDQoJDQoJVGhlIHNl cnZpY2UgZW5kZWF2b3JzIHRvIGRlbGl2ZXIgYSByZXF1ZXN0IGZvciBjb21tdW5pY2F0aW9uIHRv IGFuDQoJYXBwcm9wcmlhdGUNCglkZXZpY2UgZnJvbSB0aGUgc2V0IG9mIGRldmljZXMgaXQgY29u dHJvbHMuICBUaGUgcHJlc2VuY2UgaW5mb3JtYXRpb24NCglwcmVzZW50ZWQgYnkgdGhlIHNlcnZp Y2UgaXMgcmVwcmVzZW50cyB0aGF0IG9mIHRoZSBzZXJ2aWNlIGFzIGEgd2hvbGUsDQoJcmF0aGVy IHRoYW4gdGhhdCBvZiBvbmUgb2YgaXRzIGNvbnN0aXR1ZW50IGRldmljZXMuICBJdCBpcyBOT1QN CgluZWNlc3NhcmlseSBhIHNpbXBsZSBwaXZvdCBvZiBkZXZpY2UgcHJlc2VuY2UgaW5mb3JtYXRp b24uICBUaGUgc2VydmljZQ0KCW1heSBoYXZlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sIGFuZCBp dCBtYXkgY29tYmluZSBpbmZvcm1hdGlvbiBpbg0KCXdheXMgbm90IGV4cHJlc3NpYmxlIGFzIGEg cGl2b3Qgb2YgdGhlIGRldmljZSBkYXRhLg0KCQ0KCUEgc2VydmljZSBpcyBkaWZmZXJlbnRpYXRl ZCBmcm9tIGEgZGV2aWNlIGluIHRoYXQgdGhlIFVSSSBleHBsaWNpdGx5DQoJcmVwcmVzZW50cyB0 aGUgc2VydmljZXMsIHJlcXVlc3RzIGZvciBjb21tdW5pY2F0aW9uIHdpbGwgYmUgZm9yd2FyZGVk DQoJdG8gb25lIG9mIHRoZSBkZXZpY2VzIHRoZSBzZXJ2aWNlIGNvbnRyb2xzLg0KCQ0KCUEgc2Vy dmljZSBpcyBkaWZmZXJlbnRpYXRlZCBmcm9tIGEgdXNlciBpbiB0aGF0IGEgdXNlciBtYXkgaGF2 ZQ0KCW11bHRpcGxlIHNlcnZpY2VzLCBlYWNoIG9mIHdoaWNoIG1heSBoYXZlIHNlcGFyYXRlIHBy ZXNlbmNlIHR1cGxlcy4NCglOb3JtYWxseSwgYSB1c2VyIGhhcyBhIHNpbmdsZSB0dXBsZSByZXBy ZXNlbnRpbmcgdGhlIHByZXNlbmNlIG9mDQoJdGhlIHVzZXIgYXMgYSBwZXJzb24uDQoJDQoJWW91 IGNhbiB0aGluayBvZiB0aGlzIGFzIGEgaGllcmFyY2h5LCB3aGVyZSBhIHVzZXIgaGFzIGEgc2V0 IG9mDQoJc2VydmljZXMgZWFjaCBvZiB3aGljaCBoYXMgYSBzZXQgb2YgZGV2aWNlcy4gIE5vdGhp bmcgbGltaXRzDQoJdGhlIGhpZXJhcmNoeSB0byB0d28gbGV2ZWxzIChhIHNlcnZpY2UgY291bGQg YWdncmVnYXRlIG11bHRpcGxlDQoJc2VydmljZXMsIGFsdGhvdWdoIEkgY2FuJ3QgdGhpbmsgb2Yg YW4gZXhhbXBsZSB0aGF0IG1ha2VzIGEgbG90DQoJb2Ygc2Vuc2UpLiAgSXQncyBhbHNvIHBvc3Np YmxlIHRvIGhhdmUgYSB1c2VyIHdobyBkb2Vzbid0IGhhdmUNCglzZXJ2aWNlcy4gIEluIHRoYXQg Y2FzZSBoZSBoYXMgYSBzZXQgb2YgZGV2aWNlcyB0aGF0IGFyZSBhZ2dyZWdhdGVkDQoJZGlyZWN0 bHkgdG8gZm9ybSB0aGUgdXNlciB0dXBsZS4gIFRoZSBzZXJ2aWNlIGlzIGVxdWFsIHRvIGRldmlj ZS4NCgkNCglCcmlhbg0KCQ0KCT4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgk+IEZyb206 IEhlbm5pbmcgU2NodWx6cmlubmUgW21haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1XQ0KCT4gU2Vu dDogVHVlc2RheSwgSnVseSAxNSwgMjAwMyA3OjA1IEFNDQoJPiBUbzogaGlzaGFtLmtoYXJ0YWJp bEBub2tpYS5jb20NCgk+IENjOiBCcmlhbi5Sb3NlbkBtYXJjb25pLmNvbTsgYmNhbXBiZWxsQGR5 bmFtaWNzb2Z0LmNvbTsNCgk+IHNpbXBsZUBpZXRmLm9yZw0KCT4gU3ViamVjdDogUmU6IFtTaW1w bGVdIFR1cGxlIGRlc2lnbiB0ZWFtIGRpc2N1c3Npb24gc3VtbWFyeQ0KCT4NCgk+DQoJPiBoaXNo YW0ua2hhcnRhYmlsQG5va2lhLmNvbSB3cm90ZToNCgk+DQoJPiA+IEkgYWdyZWUgd2l0aCBCcmlh bi4gSSB0aGluayB3ZSBvbmx5IGV2ZXIgZGlzY3Vzc2VkIHRob3NlIDM6IGRldmljZSwNCgk+ID4g c2VydmljZSBhbmQgdXNlci4gV2UgZG9uJ3QgbmVlZCB0byBiZSB2ZXJ5IGV4cGxpY2l0LCBpbmZv cm1hdGlvbiBpbg0KCT4gPiB0aGUgdHVwbGUgZ2l2ZSBhd2F5IHRoZSBmaW5lciBkZXRhaWxzIGFi b3V0IHRoYXQgdGhpbmcgdGhhdA0KCT4gdGhlIHR1cGxlDQoJPiA+IHJlcHJlc2VudHMuDQoJPiA+ DQoJPiA+IE90aGVyIHRoYW4gdGhvc2UgMywgSSBoYXZlbid0IGhlYXJkIG9mIG90aGVyIHRoaW5n cyB0aGF0IGEgdHVwbGUgY2FuDQoJPiA+IHJlcHJlc2VudCwgdW5sZXNzIHdlIGFsbG93IGEgY29t YmluYXRpb24gb2YgdGhlIDMgYWJvdmUgKHdoaWNoIEkNCgk+ID4gYmVsaWV2ZSB3ZSBkb24ndCku DQoJPg0KCT4gVG8gYmVhdCBhIGhvcnNlIGNhcmNhc3M6IFdoaWxlIGRldmljZSBhbmQgJ3VzZXIn IGhhcyByZWFzb25hYmxlDQoJPiBkZWZpbml0aW9ucywgbm9ib2R5LCBhZnRlciBhIHllYXIrLCBo YXMgcHJvdmlkZWQgYW4gb3BlcmF0aW9uYWwNCgk+IGRlZmluaXRpb24gb2Ygc2VydmljZS4gU2lu Y2UgdGhpcyBsYWJlbCBuZWVkcyB0byBiZSB1bmRlcnN0YW5kYWJsZSBieQ0KCT4gcGVvcGxlIHdo byBoYXZlIG5vdCBwYXJ0aWNpcGF0ZWQgaW4gdGhlIFR1cGxlIFRoZW9yeSA3NDUNCgk+IGNsYXNz ICh0aGlzIGlzDQoJPiBncmFkdWF0ZS1sZXZlbCBzdHVmZi4uLiksIEkgZG9uJ3QgdGhpbmsgYW4g ZWxhYm9yYXRlIGRlZmluaXRpb24gaGVscHMuDQoJPg0KCT4gJ2RldmljZScsICd1c2VyJyBhbmQg J290aGVyJyBzZWVtIHRvIHdvcmsgb2ssIHdoaWNoIHNlZW1zIHRvIGJlIGNsb3NlDQoJPiBlbm91 Z2guIChFYXJsaWVyIHZlcnNpb25zIG9mIFJQSURTIGhhZCBhbiBhcHByb3hpbWF0aW9uIHRvIHN1 Y2ggYW4NCgk+IGVsZW1lbnQsIHdpdGggdGhlIGFkZGl0aW9uIG9mICdncm91cCcuKSBGb3IgdGhv c2UsIHRoZXJlIGFyZQ0KCT4gcmVhc29uYWJsZQ0KCT4gcGljdG9ncmFtcywgdG9vIC0gcGhvbmUs IHN0aWNrIHBlcnNvbiBhbmQgPy4NCgk+DQoJPiBIZW5uaW5nDQoJPg0KCT4NCgk+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJPiBTaW1wbGUgbWFpbGlu ZyBsaXN0DQoJPiBTaW1wbGVAaWV0Zi5vcmcNCgk+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpbXBsZQ0KCT4NCgkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KCVNpbXBsZSBtYWlsaW5nIGxpc3QNCglTaW1wbGVAaWV0Zi5v cmcNCglodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUNCgkNCg0K _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 08:39:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16460; Tue, 15 Jul 2003 08:39:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cP5N-0001W8-00; Tue, 15 Jul 2003 08:39:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cP4n-0001Vb-00; Tue, 15 Jul 2003 08:38:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cP4D-0003Ur-Tf; Tue, 15 Jul 2003 08:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cP3l-0003Mf-KK for simple@optimus.ietf.org; Tue, 15 Jul 2003 08:37:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16400 for ; Tue, 15 Jul 2003 08:37:29 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cP3f-0001V3-00 for simple@ietf.org; Tue, 15 Jul 2003 08:37:27 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19cP3E-0001UZ-00 for simple@ietf.org; Tue, 15 Jul 2003 08:37:00 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6FCaDa18624 for ; Tue, 15 Jul 2003 15:36:13 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 15:36:12 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 15:36:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] Tuple design team discussion summary Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F0E@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Tuple design team discussion summary Thread-Index: AcNKwc95hdNs0rj9Sj2XKw0VLqFI/gACrAqA To: Cc: , , X-OriginalArrivalTime: 15 Jul 2003 12:36:11.0862 (UTC) FILETIME=[AC753760:01C34ACD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 15:36:11 +0300 Content-Transfer-Encoding: quoted-printable I think I mentioned something like this before: Service to me means = something that an operator can offer (as part of a package) and charge = for. IM, presence and geoloc are some examples. This is probably not the definition you are looking for since its not = technical, but probably its good enough to warrant the inclusion of the = term 'service' in the list of what a tuple represents. I don't think = having the term 'other' is a good idea since it might confuse = implementers in the sense that they would not know what goes into such a = tuple. Brian started some discussion about service definition, perhaps we need = to discuss further a technical definition of what a service is. I = believe this is better than just saying that we have a 'other' tuple = that represents things that are not devices or are not users. Regards, Hisham > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, July 15, 2003 2:05 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: Brian.Rosen@marconi.com; bcampbell@dynamicsoft.com;=20 > simple@ietf.org > Subject: Re: [Simple] Tuple design team discussion summary >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > I agree with Brian. I think we only ever discussed those 3: device, > > service and user. We don't need to be very explicit, information in > > the tuple give away the finer details about that thing that=20 > the tuple > > represents. > >=20 > > Other than those 3, I haven't heard of other things that a tuple can > > represent, unless we allow a combination of the 3 above (which I > > believe we don't). >=20 > To beat a horse carcass: While device and 'user' has reasonable=20 > definitions, nobody, after a year+, has provided an operational=20 > definition of service. Since this label needs to be understandable by=20 > people who have not participated in the Tuple Theory 745=20 > class (this is=20 > graduate-level stuff...), I don't think an elaborate definition helps. >=20 > 'device', 'user' and 'other' seem to work ok, which seems to be close=20 > enough. (Earlier versions of RPIDS had an approximation to such an=20 > element, with the addition of 'group'.) For those, there are=20 > reasonable=20 > pictograms, too - phone, stick person and ?. >=20 > Henning >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 08:39:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16484 for ; Tue, 15 Jul 2003 08:39:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cP5b-0003kw-GZ for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 08:39:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FCdRjA014432 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 08:39:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cP5Z-0003jt-VV for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 08:39:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16460; Tue, 15 Jul 2003 08:39:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cP5N-0001W8-00; Tue, 15 Jul 2003 08:39:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cP4n-0001Vb-00; Tue, 15 Jul 2003 08:38:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cP4D-0003Ur-Tf; Tue, 15 Jul 2003 08:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cP3l-0003Mf-KK for simple@optimus.ietf.org; Tue, 15 Jul 2003 08:37:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16400 for ; Tue, 15 Jul 2003 08:37:29 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cP3f-0001V3-00 for simple@ietf.org; Tue, 15 Jul 2003 08:37:27 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19cP3E-0001UZ-00 for simple@ietf.org; Tue, 15 Jul 2003 08:37:00 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6FCaDa18624 for ; Tue, 15 Jul 2003 15:36:13 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 15:36:12 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 15:36:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] Tuple design team discussion summary Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F0E@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Tuple design team discussion summary Thread-Index: AcNKwc95hdNs0rj9Sj2XKw0VLqFI/gACrAqA To: Cc: , , X-OriginalArrivalTime: 15 Jul 2003 12:36:11.0862 (UTC) FILETIME=[AC753760:01C34ACD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 15:36:11 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I think I mentioned something like this before: Service to me means = something that an operator can offer (as part of a package) and charge = for. IM, presence and geoloc are some examples. This is probably not the definition you are looking for since its not = technical, but probably its good enough to warrant the inclusion of the = term 'service' in the list of what a tuple represents. I don't think = having the term 'other' is a good idea since it might confuse = implementers in the sense that they would not know what goes into such a = tuple. Brian started some discussion about service definition, perhaps we need = to discuss further a technical definition of what a service is. I = believe this is better than just saying that we have a 'other' tuple = that represents things that are not devices or are not users. Regards, Hisham > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, July 15, 2003 2:05 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: Brian.Rosen@marconi.com; bcampbell@dynamicsoft.com;=20 > simple@ietf.org > Subject: Re: [Simple] Tuple design team discussion summary >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > I agree with Brian. I think we only ever discussed those 3: device, > > service and user. We don't need to be very explicit, information in > > the tuple give away the finer details about that thing that=20 > the tuple > > represents. > >=20 > > Other than those 3, I haven't heard of other things that a tuple can > > represent, unless we allow a combination of the 3 above (which I > > believe we don't). >=20 > To beat a horse carcass: While device and 'user' has reasonable=20 > definitions, nobody, after a year+, has provided an operational=20 > definition of service. Since this label needs to be understandable by=20 > people who have not participated in the Tuple Theory 745=20 > class (this is=20 > graduate-level stuff...), I don't think an elaborate definition helps. >=20 > 'device', 'user' and 'other' seem to work ok, which seems to be close=20 > enough. (Earlier versions of RPIDS had an approximation to such an=20 > element, with the addition of 'group'.) For those, there are=20 > reasonable=20 > pictograms, too - phone, stick person and ?. >=20 > Henning >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 08:42:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16553; Tue, 15 Jul 2003 08:42:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cP84-0003nz-Qo; Tue, 15 Jul 2003 08:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cP7z-0003nW-VY for simple@optimus.ietf.org; Tue, 15 Jul 2003 08:41:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16537 for ; Tue, 15 Jul 2003 08:41:51 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cP7t-0001XF-00 for simple@ietf.org; Tue, 15 Jul 2003 08:41:49 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19cP7T-0001Wr-00 for simple@ietf.org; Tue, 15 Jul 2003 08:41:23 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6FCdik05927 for ; Tue, 15 Jul 2003 15:39:44 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 15:39:44 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 15:39:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Simple] Tuple design team discussion summary Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F0F@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Tuple design team discussion summary Thread-Index: AcNKxeqWQNZOKlYZT0uwoOWG/DhKQgABk8l7AABlfXA= To: , , Cc: , X-OriginalArrivalTime: 15 Jul 2003 12:39:44.0057 (UTC) FILETIME=[2AEF9A90:01C34ACE] Content-Transfer-Encoding: base64 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 15:39:43 +0300 Content-Transfer-Encoding: base64 SWYgeW91IGhhdmUgc2VydmljZSB0dXBsZXMgYW5kIGRldmljZSB0dXBsZXMsIHRoZW4geW91IHBy b2JhYmx5IGhhdmUgc29tZSBvdmVybGFwIGluIHRoZSBpbmZvcm1hdGlvbiB0aGV5IHByb3ZpZGUu IEkgd291bGQgc2F5IGVpdGhlciB5b3UgaGF2ZSBkZXZpY2UgdHVwbGVzIG9mIHNlcnZpY2UgdHVw bGVzIGJ1dCBub3QgYm90aCBjb25jdXJyZW50bHkuDQoNClJlZ2FyZHMsDQpIaXNoYW0NCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBleHQgQ2hyaXMgQm91bHRvbiBbbWFp bHRvOmNib3VsdG9uQHViaXF1aXR5Lm5ldF0NCj4gU2VudDogVHVlc2RheSwgSnVseSAxNSwgMjAw MyAzOjMyIFBNDQo+IFRvOiBSb3NlbiwgQnJpYW47IEhlbm5pbmcgU2NodWx6cmlubmU7IEtoYXJ0 YWJpbCBIaXNoYW0gKE5NUC9IZWxzaW5raSkNCj4gQ2M6IGJjYW1wYmVsbEBkeW5hbWljc29mdC5j b207IHNpbXBsZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW1NpbXBsZV0gVHVwbGUgZGVzaWdu IHRlYW0gZGlzY3Vzc2lvbiBzdW1tYXJ5DQo+IA0KPiANCj4gQnJpYW4sDQo+IFRoaXMgc3RydWN0 dXJlIHNlZW1zIHJlYXNvbmFibGUgdG8gbWUgLSBPbmUgcXVlc3Rpb24sIEkgDQo+IHVuZGVyc3Rh bmQgdGhhdCBhIHVzZXIgVHVwbGUgd291bGQgYmUgcHJlc2VudCB3aXRoIG11bHRpcGxlIA0KPiBz ZXJ2aWNlIHR1cGxlcy4gIEhvdyBhcmUgdGhlIGRldmljZSB0dXBsZXMgYXNzb2NpYXRlZCB3aXRo IA0KPiB0aGUgY29ycmVjdCBzZXJ2aWNlIHR1cGxlcyAobWF5YmUgdGhpcyBpcyBjbGVhciBhbmQg SSBhbSANCj4gbWlzc2luZyBzb21ldGhpbmcpIC0gY291bGQgdGhlIGNsYXNzIGF0dHJpYnV0ZSBi ZSB1c2VkPw0KPiAgDQo+IENocmlzLg0KPiAgDQo+IA0KPiAJLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0gDQo+IAlGcm9tOiBSb3NlbiwgQnJpYW4gW21haWx0bzpCcmlhbi5Sb3NlbkBtYXJjb25p LmNvbV0gDQo+IAlTZW50OiBUdWUgMTUvMDcvMjAwMyAxMjo0MCANCj4gCVRvOiAnSGVubmluZyBT Y2h1bHpyaW5uZSc7IGhpc2hhbS5raGFydGFiaWxAbm9raWEuY29tIA0KPiAJQ2M6IGJjYW1wYmVs bEBkeW5hbWljc29mdC5jb207IHNpbXBsZUBpZXRmLm9yZyANCj4gCVN1YmplY3Q6IFJFOiBbU2lt cGxlXSBUdXBsZSBkZXNpZ24gdGVhbSBkaXNjdXNzaW9uIHN1bW1hcnkNCj4gCQ0KPiAJDQo+IA0K PiAJRm9yIHRoaXMgcHVycG9zZSwgYSBzZXJ2aWNlIGlzIGEgdHVwbGUgcmVwcmVzZW50aW5nIGEg DQo+IGNvbW11bmljYXRpb25zDQo+IAlwYXRoIHRvIGEgc2V0IG9mIGRldmljZXMgdGhhdCBoYXZl IHNvbWUgY29tbW9uIGNoYXJhY3RlcmlzdGljcy4NCj4gCVRoZSB0dXBsZSBjb250YWlucyB0aGUg VVJJIHRvIHRoZSBzZXJ2aWNlLCBhbmQgdGhlIA0KPiBjaGFyYWN0ZXJpc3RpY3MNCj4gCShjYXBh YmlsaXRpZXMpDQo+IAlvZiB0aGUgc2VydmljZS4NCj4gCQ0KPiAJVGhlIHNlcnZpY2UgZW5kZWF2 b3JzIHRvIGRlbGl2ZXIgYSByZXF1ZXN0IGZvciANCj4gY29tbXVuaWNhdGlvbiB0byBhbg0KPiAJ YXBwcm9wcmlhdGUNCj4gCWRldmljZSBmcm9tIHRoZSBzZXQgb2YgZGV2aWNlcyBpdCBjb250cm9s cy4gIFRoZSANCj4gcHJlc2VuY2UgaW5mb3JtYXRpb24NCj4gCXByZXNlbnRlZCBieSB0aGUgc2Vy dmljZSBpcyByZXByZXNlbnRzIHRoYXQgb2YgdGhlIA0KPiBzZXJ2aWNlIGFzIGEgd2hvbGUsDQo+ IAlyYXRoZXIgdGhhbiB0aGF0IG9mIG9uZSBvZiBpdHMgY29uc3RpdHVlbnQgZGV2aWNlcy4gIEl0 IGlzIE5PVA0KPiAJbmVjZXNzYXJpbHkgYSBzaW1wbGUgcGl2b3Qgb2YgZGV2aWNlIHByZXNlbmNl IA0KPiBpbmZvcm1hdGlvbi4gIFRoZSBzZXJ2aWNlDQo+IAltYXkgaGF2ZSBhZGRpdGlvbmFsIGlu Zm9ybWF0aW9uLCBhbmQgaXQgbWF5IGNvbWJpbmUgDQo+IGluZm9ybWF0aW9uIGluDQo+IAl3YXlz IG5vdCBleHByZXNzaWJsZSBhcyBhIHBpdm90IG9mIHRoZSBkZXZpY2UgZGF0YS4NCj4gCQ0KPiAJ QSBzZXJ2aWNlIGlzIGRpZmZlcmVudGlhdGVkIGZyb20gYSBkZXZpY2UgaW4gdGhhdCB0aGUgDQo+ IFVSSSBleHBsaWNpdGx5DQo+IAlyZXByZXNlbnRzIHRoZSBzZXJ2aWNlcywgcmVxdWVzdHMgZm9y IGNvbW11bmljYXRpb24gDQo+IHdpbGwgYmUgZm9yd2FyZGVkDQo+IAl0byBvbmUgb2YgdGhlIGRl dmljZXMgdGhlIHNlcnZpY2UgY29udHJvbHMuDQo+IAkNCj4gCUEgc2VydmljZSBpcyBkaWZmZXJl bnRpYXRlZCBmcm9tIGEgdXNlciBpbiB0aGF0IGEgdXNlciBtYXkgaGF2ZQ0KPiAJbXVsdGlwbGUg c2VydmljZXMsIGVhY2ggb2Ygd2hpY2ggbWF5IGhhdmUgc2VwYXJhdGUgDQo+IHByZXNlbmNlIHR1 cGxlcy4NCj4gCU5vcm1hbGx5LCBhIHVzZXIgaGFzIGEgc2luZ2xlIHR1cGxlIHJlcHJlc2VudGlu ZyB0aGUgcHJlc2VuY2Ugb2YNCj4gCXRoZSB1c2VyIGFzIGEgcGVyc29uLg0KPiAJDQo+IAlZb3Ug Y2FuIHRoaW5rIG9mIHRoaXMgYXMgYSBoaWVyYXJjaHksIHdoZXJlIGEgdXNlciBoYXMgYSBzZXQg b2YNCj4gCXNlcnZpY2VzIGVhY2ggb2Ygd2hpY2ggaGFzIGEgc2V0IG9mIGRldmljZXMuICBOb3Ro aW5nIGxpbWl0cw0KPiAJdGhlIGhpZXJhcmNoeSB0byB0d28gbGV2ZWxzIChhIHNlcnZpY2UgY291 bGQgYWdncmVnYXRlIG11bHRpcGxlDQo+IAlzZXJ2aWNlcywgYWx0aG91Z2ggSSBjYW4ndCB0aGlu ayBvZiBhbiBleGFtcGxlIHRoYXQgbWFrZXMgYSBsb3QNCj4gCW9mIHNlbnNlKS4gIEl0J3MgYWxz byBwb3NzaWJsZSB0byBoYXZlIGEgdXNlciB3aG8gZG9lc24ndCBoYXZlDQo+IAlzZXJ2aWNlcy4g IEluIHRoYXQgY2FzZSBoZSBoYXMgYSBzZXQgb2YgZGV2aWNlcyB0aGF0IA0KPiBhcmUgYWdncmVn YXRlZA0KPiAJZGlyZWN0bHkgdG8gZm9ybSB0aGUgdXNlciB0dXBsZS4gIFRoZSBzZXJ2aWNlIGlz IGVxdWFsIA0KPiB0byBkZXZpY2UuDQo+IAkNCj4gCUJyaWFuDQo+IAkNCj4gCT4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gCT4gRnJvbTogSGVubmluZyBTY2h1bHpyaW5uZSBbbWFpbHRv Omhnc0Bjcy5jb2x1bWJpYS5lZHVdDQo+IAk+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTUsIDIwMDMg NzowNSBBTQ0KPiAJPiBUbzogaGlzaGFtLmtoYXJ0YWJpbEBub2tpYS5jb20NCj4gCT4gQ2M6IEJy aWFuLlJvc2VuQG1hcmNvbmkuY29tOyBiY2FtcGJlbGxAZHluYW1pY3NvZnQuY29tOw0KPiAJPiBz aW1wbGVAaWV0Zi5vcmcNCj4gCT4gU3ViamVjdDogUmU6IFtTaW1wbGVdIFR1cGxlIGRlc2lnbiB0 ZWFtIGRpc2N1c3Npb24gc3VtbWFyeQ0KPiAJPg0KPiAJPg0KPiAJPiBoaXNoYW0ua2hhcnRhYmls QG5va2lhLmNvbSB3cm90ZToNCj4gCT4NCj4gCT4gPiBJIGFncmVlIHdpdGggQnJpYW4uIEkgdGhp bmsgd2Ugb25seSBldmVyIGRpc2N1c3NlZCANCj4gdGhvc2UgMzogZGV2aWNlLA0KPiAJPiA+IHNl cnZpY2UgYW5kIHVzZXIuIFdlIGRvbid0IG5lZWQgdG8gYmUgdmVyeSANCj4gZXhwbGljaXQsIGlu Zm9ybWF0aW9uIGluDQo+IAk+ID4gdGhlIHR1cGxlIGdpdmUgYXdheSB0aGUgZmluZXIgZGV0YWls cyBhYm91dCB0aGF0IHRoaW5nIHRoYXQNCj4gCT4gdGhlIHR1cGxlDQo+IAk+ID4gcmVwcmVzZW50 cy4NCj4gCT4gPg0KPiAJPiA+IE90aGVyIHRoYW4gdGhvc2UgMywgSSBoYXZlbid0IGhlYXJkIG9m IG90aGVyIHRoaW5ncyANCj4gdGhhdCBhIHR1cGxlIGNhbg0KPiAJPiA+IHJlcHJlc2VudCwgdW5s ZXNzIHdlIGFsbG93IGEgY29tYmluYXRpb24gb2YgdGhlIDMgDQo+IGFib3ZlICh3aGljaCBJDQo+ IAk+ID4gYmVsaWV2ZSB3ZSBkb24ndCkuDQo+IAk+DQo+IAk+IFRvIGJlYXQgYSBob3JzZSBjYXJj YXNzOiBXaGlsZSBkZXZpY2UgYW5kICd1c2VyJyBoYXMgDQo+IHJlYXNvbmFibGUNCj4gCT4gZGVm aW5pdGlvbnMsIG5vYm9keSwgYWZ0ZXIgYSB5ZWFyKywgaGFzIHByb3ZpZGVkIGFuIA0KPiBvcGVy YXRpb25hbA0KPiAJPiBkZWZpbml0aW9uIG9mIHNlcnZpY2UuIFNpbmNlIHRoaXMgbGFiZWwgbmVl ZHMgdG8gYmUgDQo+IHVuZGVyc3RhbmRhYmxlIGJ5DQo+IAk+IHBlb3BsZSB3aG8gaGF2ZSBub3Qg cGFydGljaXBhdGVkIGluIHRoZSBUdXBsZSBUaGVvcnkgNzQ1DQo+IAk+IGNsYXNzICh0aGlzIGlz DQo+IAk+IGdyYWR1YXRlLWxldmVsIHN0dWZmLi4uKSwgSSBkb24ndCB0aGluayBhbiBlbGFib3Jh dGUgDQo+IGRlZmluaXRpb24gaGVscHMuDQo+IAk+DQo+IAk+ICdkZXZpY2UnLCAndXNlcicgYW5k ICdvdGhlcicgc2VlbSB0byB3b3JrIG9rLCB3aGljaCANCj4gc2VlbXMgdG8gYmUgY2xvc2UNCj4g CT4gZW5vdWdoLiAoRWFybGllciB2ZXJzaW9ucyBvZiBSUElEUyBoYWQgYW4gDQo+IGFwcHJveGlt YXRpb24gdG8gc3VjaCBhbg0KPiAJPiBlbGVtZW50LCB3aXRoIHRoZSBhZGRpdGlvbiBvZiAnZ3Jv dXAnLikgRm9yIHRob3NlLCB0aGVyZSBhcmUNCj4gCT4gcmVhc29uYWJsZQ0KPiAJPiBwaWN0b2dy YW1zLCB0b28gLSBwaG9uZSwgc3RpY2sgcGVyc29uIGFuZCA/Lg0KPiAJPg0KPiAJPiBIZW5uaW5n DQo+IAk+DQo+IAk+DQo+IAk+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IAk+IFNpbXBsZSBtYWlsaW5nIGxpc3QNCj4gCT4gU2ltcGxlQGlldGYub3Jn DQo+IAk+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZQ0KPiAJ Pg0KPiAJDQo+IAlfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiAJU2ltcGxlIG1haWxpbmcgbGlzdA0KPiAJU2ltcGxlQGlldGYub3JnDQo+IAlodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUNCj4gCQ0KPiANCj4gDQo= _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 08:43:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16593 for ; Tue, 15 Jul 2003 08:43:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cP8c-0003rf-Ih for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 08:42:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FCgYfu014850 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 08:42:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cP8c-0003rR-Ew for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 08:42:34 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16553; Tue, 15 Jul 2003 08:42:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cP84-0003nz-Qo; Tue, 15 Jul 2003 08:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cP7z-0003nW-VY for simple@optimus.ietf.org; Tue, 15 Jul 2003 08:41:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16537 for ; Tue, 15 Jul 2003 08:41:51 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cP7t-0001XF-00 for simple@ietf.org; Tue, 15 Jul 2003 08:41:49 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19cP7T-0001Wr-00 for simple@ietf.org; Tue, 15 Jul 2003 08:41:23 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6FCdik05927 for ; Tue, 15 Jul 2003 15:39:44 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 15:39:44 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 15:39:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Simple] Tuple design team discussion summary Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F0F@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Tuple design team discussion summary Thread-Index: AcNKxeqWQNZOKlYZT0uwoOWG/DhKQgABk8l7AABlfXA= To: , , Cc: , X-OriginalArrivalTime: 15 Jul 2003 12:39:44.0057 (UTC) FILETIME=[2AEF9A90:01C34ACE] Content-Transfer-Encoding: base64 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 15:39:43 +0300 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SWYgeW91IGhhdmUgc2VydmljZSB0dXBsZXMgYW5kIGRldmljZSB0dXBsZXMsIHRoZW4geW91IHBy b2JhYmx5IGhhdmUgc29tZSBvdmVybGFwIGluIHRoZSBpbmZvcm1hdGlvbiB0aGV5IHByb3ZpZGUu IEkgd291bGQgc2F5IGVpdGhlciB5b3UgaGF2ZSBkZXZpY2UgdHVwbGVzIG9mIHNlcnZpY2UgdHVw bGVzIGJ1dCBub3QgYm90aCBjb25jdXJyZW50bHkuDQoNClJlZ2FyZHMsDQpIaXNoYW0NCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBleHQgQ2hyaXMgQm91bHRvbiBbbWFp bHRvOmNib3VsdG9uQHViaXF1aXR5Lm5ldF0NCj4gU2VudDogVHVlc2RheSwgSnVseSAxNSwgMjAw MyAzOjMyIFBNDQo+IFRvOiBSb3NlbiwgQnJpYW47IEhlbm5pbmcgU2NodWx6cmlubmU7IEtoYXJ0 YWJpbCBIaXNoYW0gKE5NUC9IZWxzaW5raSkNCj4gQ2M6IGJjYW1wYmVsbEBkeW5hbWljc29mdC5j b207IHNpbXBsZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW1NpbXBsZV0gVHVwbGUgZGVzaWdu IHRlYW0gZGlzY3Vzc2lvbiBzdW1tYXJ5DQo+IA0KPiANCj4gQnJpYW4sDQo+IFRoaXMgc3RydWN0 dXJlIHNlZW1zIHJlYXNvbmFibGUgdG8gbWUgLSBPbmUgcXVlc3Rpb24sIEkgDQo+IHVuZGVyc3Rh bmQgdGhhdCBhIHVzZXIgVHVwbGUgd291bGQgYmUgcHJlc2VudCB3aXRoIG11bHRpcGxlIA0KPiBz ZXJ2aWNlIHR1cGxlcy4gIEhvdyBhcmUgdGhlIGRldmljZSB0dXBsZXMgYXNzb2NpYXRlZCB3aXRo IA0KPiB0aGUgY29ycmVjdCBzZXJ2aWNlIHR1cGxlcyAobWF5YmUgdGhpcyBpcyBjbGVhciBhbmQg SSBhbSANCj4gbWlzc2luZyBzb21ldGhpbmcpIC0gY291bGQgdGhlIGNsYXNzIGF0dHJpYnV0ZSBi ZSB1c2VkPw0KPiAgDQo+IENocmlzLg0KPiAgDQo+IA0KPiAJLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0gDQo+IAlGcm9tOiBSb3NlbiwgQnJpYW4gW21haWx0bzpCcmlhbi5Sb3NlbkBtYXJjb25p LmNvbV0gDQo+IAlTZW50OiBUdWUgMTUvMDcvMjAwMyAxMjo0MCANCj4gCVRvOiAnSGVubmluZyBT Y2h1bHpyaW5uZSc7IGhpc2hhbS5raGFydGFiaWxAbm9raWEuY29tIA0KPiAJQ2M6IGJjYW1wYmVs bEBkeW5hbWljc29mdC5jb207IHNpbXBsZUBpZXRmLm9yZyANCj4gCVN1YmplY3Q6IFJFOiBbU2lt cGxlXSBUdXBsZSBkZXNpZ24gdGVhbSBkaXNjdXNzaW9uIHN1bW1hcnkNCj4gCQ0KPiAJDQo+IA0K PiAJRm9yIHRoaXMgcHVycG9zZSwgYSBzZXJ2aWNlIGlzIGEgdHVwbGUgcmVwcmVzZW50aW5nIGEg DQo+IGNvbW11bmljYXRpb25zDQo+IAlwYXRoIHRvIGEgc2V0IG9mIGRldmljZXMgdGhhdCBoYXZl IHNvbWUgY29tbW9uIGNoYXJhY3RlcmlzdGljcy4NCj4gCVRoZSB0dXBsZSBjb250YWlucyB0aGUg VVJJIHRvIHRoZSBzZXJ2aWNlLCBhbmQgdGhlIA0KPiBjaGFyYWN0ZXJpc3RpY3MNCj4gCShjYXBh YmlsaXRpZXMpDQo+IAlvZiB0aGUgc2VydmljZS4NCj4gCQ0KPiAJVGhlIHNlcnZpY2UgZW5kZWF2 b3JzIHRvIGRlbGl2ZXIgYSByZXF1ZXN0IGZvciANCj4gY29tbXVuaWNhdGlvbiB0byBhbg0KPiAJ YXBwcm9wcmlhdGUNCj4gCWRldmljZSBmcm9tIHRoZSBzZXQgb2YgZGV2aWNlcyBpdCBjb250cm9s cy4gIFRoZSANCj4gcHJlc2VuY2UgaW5mb3JtYXRpb24NCj4gCXByZXNlbnRlZCBieSB0aGUgc2Vy dmljZSBpcyByZXByZXNlbnRzIHRoYXQgb2YgdGhlIA0KPiBzZXJ2aWNlIGFzIGEgd2hvbGUsDQo+ IAlyYXRoZXIgdGhhbiB0aGF0IG9mIG9uZSBvZiBpdHMgY29uc3RpdHVlbnQgZGV2aWNlcy4gIEl0 IGlzIE5PVA0KPiAJbmVjZXNzYXJpbHkgYSBzaW1wbGUgcGl2b3Qgb2YgZGV2aWNlIHByZXNlbmNl IA0KPiBpbmZvcm1hdGlvbi4gIFRoZSBzZXJ2aWNlDQo+IAltYXkgaGF2ZSBhZGRpdGlvbmFsIGlu Zm9ybWF0aW9uLCBhbmQgaXQgbWF5IGNvbWJpbmUgDQo+IGluZm9ybWF0aW9uIGluDQo+IAl3YXlz IG5vdCBleHByZXNzaWJsZSBhcyBhIHBpdm90IG9mIHRoZSBkZXZpY2UgZGF0YS4NCj4gCQ0KPiAJ QSBzZXJ2aWNlIGlzIGRpZmZlcmVudGlhdGVkIGZyb20gYSBkZXZpY2UgaW4gdGhhdCB0aGUgDQo+ IFVSSSBleHBsaWNpdGx5DQo+IAlyZXByZXNlbnRzIHRoZSBzZXJ2aWNlcywgcmVxdWVzdHMgZm9y IGNvbW11bmljYXRpb24gDQo+IHdpbGwgYmUgZm9yd2FyZGVkDQo+IAl0byBvbmUgb2YgdGhlIGRl dmljZXMgdGhlIHNlcnZpY2UgY29udHJvbHMuDQo+IAkNCj4gCUEgc2VydmljZSBpcyBkaWZmZXJl bnRpYXRlZCBmcm9tIGEgdXNlciBpbiB0aGF0IGEgdXNlciBtYXkgaGF2ZQ0KPiAJbXVsdGlwbGUg c2VydmljZXMsIGVhY2ggb2Ygd2hpY2ggbWF5IGhhdmUgc2VwYXJhdGUgDQo+IHByZXNlbmNlIHR1 cGxlcy4NCj4gCU5vcm1hbGx5LCBhIHVzZXIgaGFzIGEgc2luZ2xlIHR1cGxlIHJlcHJlc2VudGlu ZyB0aGUgcHJlc2VuY2Ugb2YNCj4gCXRoZSB1c2VyIGFzIGEgcGVyc29uLg0KPiAJDQo+IAlZb3Ug Y2FuIHRoaW5rIG9mIHRoaXMgYXMgYSBoaWVyYXJjaHksIHdoZXJlIGEgdXNlciBoYXMgYSBzZXQg b2YNCj4gCXNlcnZpY2VzIGVhY2ggb2Ygd2hpY2ggaGFzIGEgc2V0IG9mIGRldmljZXMuICBOb3Ro aW5nIGxpbWl0cw0KPiAJdGhlIGhpZXJhcmNoeSB0byB0d28gbGV2ZWxzIChhIHNlcnZpY2UgY291 bGQgYWdncmVnYXRlIG11bHRpcGxlDQo+IAlzZXJ2aWNlcywgYWx0aG91Z2ggSSBjYW4ndCB0aGlu ayBvZiBhbiBleGFtcGxlIHRoYXQgbWFrZXMgYSBsb3QNCj4gCW9mIHNlbnNlKS4gIEl0J3MgYWxz byBwb3NzaWJsZSB0byBoYXZlIGEgdXNlciB3aG8gZG9lc24ndCBoYXZlDQo+IAlzZXJ2aWNlcy4g IEluIHRoYXQgY2FzZSBoZSBoYXMgYSBzZXQgb2YgZGV2aWNlcyB0aGF0IA0KPiBhcmUgYWdncmVn YXRlZA0KPiAJZGlyZWN0bHkgdG8gZm9ybSB0aGUgdXNlciB0dXBsZS4gIFRoZSBzZXJ2aWNlIGlz IGVxdWFsIA0KPiB0byBkZXZpY2UuDQo+IAkNCj4gCUJyaWFuDQo+IAkNCj4gCT4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gCT4gRnJvbTogSGVubmluZyBTY2h1bHpyaW5uZSBbbWFpbHRv Omhnc0Bjcy5jb2x1bWJpYS5lZHVdDQo+IAk+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTUsIDIwMDMg NzowNSBBTQ0KPiAJPiBUbzogaGlzaGFtLmtoYXJ0YWJpbEBub2tpYS5jb20NCj4gCT4gQ2M6IEJy aWFuLlJvc2VuQG1hcmNvbmkuY29tOyBiY2FtcGJlbGxAZHluYW1pY3NvZnQuY29tOw0KPiAJPiBz aW1wbGVAaWV0Zi5vcmcNCj4gCT4gU3ViamVjdDogUmU6IFtTaW1wbGVdIFR1cGxlIGRlc2lnbiB0 ZWFtIGRpc2N1c3Npb24gc3VtbWFyeQ0KPiAJPg0KPiAJPg0KPiAJPiBoaXNoYW0ua2hhcnRhYmls QG5va2lhLmNvbSB3cm90ZToNCj4gCT4NCj4gCT4gPiBJIGFncmVlIHdpdGggQnJpYW4uIEkgdGhp bmsgd2Ugb25seSBldmVyIGRpc2N1c3NlZCANCj4gdGhvc2UgMzogZGV2aWNlLA0KPiAJPiA+IHNl cnZpY2UgYW5kIHVzZXIuIFdlIGRvbid0IG5lZWQgdG8gYmUgdmVyeSANCj4gZXhwbGljaXQsIGlu Zm9ybWF0aW9uIGluDQo+IAk+ID4gdGhlIHR1cGxlIGdpdmUgYXdheSB0aGUgZmluZXIgZGV0YWls cyBhYm91dCB0aGF0IHRoaW5nIHRoYXQNCj4gCT4gdGhlIHR1cGxlDQo+IAk+ID4gcmVwcmVzZW50 cy4NCj4gCT4gPg0KPiAJPiA+IE90aGVyIHRoYW4gdGhvc2UgMywgSSBoYXZlbid0IGhlYXJkIG9m IG90aGVyIHRoaW5ncyANCj4gdGhhdCBhIHR1cGxlIGNhbg0KPiAJPiA+IHJlcHJlc2VudCwgdW5s ZXNzIHdlIGFsbG93IGEgY29tYmluYXRpb24gb2YgdGhlIDMgDQo+IGFib3ZlICh3aGljaCBJDQo+ IAk+ID4gYmVsaWV2ZSB3ZSBkb24ndCkuDQo+IAk+DQo+IAk+IFRvIGJlYXQgYSBob3JzZSBjYXJj YXNzOiBXaGlsZSBkZXZpY2UgYW5kICd1c2VyJyBoYXMgDQo+IHJlYXNvbmFibGUNCj4gCT4gZGVm aW5pdGlvbnMsIG5vYm9keSwgYWZ0ZXIgYSB5ZWFyKywgaGFzIHByb3ZpZGVkIGFuIA0KPiBvcGVy YXRpb25hbA0KPiAJPiBkZWZpbml0aW9uIG9mIHNlcnZpY2UuIFNpbmNlIHRoaXMgbGFiZWwgbmVl ZHMgdG8gYmUgDQo+IHVuZGVyc3RhbmRhYmxlIGJ5DQo+IAk+IHBlb3BsZSB3aG8gaGF2ZSBub3Qg cGFydGljaXBhdGVkIGluIHRoZSBUdXBsZSBUaGVvcnkgNzQ1DQo+IAk+IGNsYXNzICh0aGlzIGlz DQo+IAk+IGdyYWR1YXRlLWxldmVsIHN0dWZmLi4uKSwgSSBkb24ndCB0aGluayBhbiBlbGFib3Jh dGUgDQo+IGRlZmluaXRpb24gaGVscHMuDQo+IAk+DQo+IAk+ICdkZXZpY2UnLCAndXNlcicgYW5k ICdvdGhlcicgc2VlbSB0byB3b3JrIG9rLCB3aGljaCANCj4gc2VlbXMgdG8gYmUgY2xvc2UNCj4g CT4gZW5vdWdoLiAoRWFybGllciB2ZXJzaW9ucyBvZiBSUElEUyBoYWQgYW4gDQo+IGFwcHJveGlt YXRpb24gdG8gc3VjaCBhbg0KPiAJPiBlbGVtZW50LCB3aXRoIHRoZSBhZGRpdGlvbiBvZiAnZ3Jv dXAnLikgRm9yIHRob3NlLCB0aGVyZSBhcmUNCj4gCT4gcmVhc29uYWJsZQ0KPiAJPiBwaWN0b2dy YW1zLCB0b28gLSBwaG9uZSwgc3RpY2sgcGVyc29uIGFuZCA/Lg0KPiAJPg0KPiAJPiBIZW5uaW5n DQo+IAk+DQo+IAk+DQo+IAk+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IAk+IFNpbXBsZSBtYWlsaW5nIGxpc3QNCj4gCT4gU2ltcGxlQGlldGYub3Jn DQo+IAk+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZQ0KPiAJ Pg0KPiAJDQo+IAlfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiAJU2ltcGxlIG1haWxpbmcgbGlzdA0KPiAJU2ltcGxlQGlldGYub3JnDQo+IAlodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUNCj4gCQ0KPiANCj4gDQo= _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 10:27:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21549; Tue, 15 Jul 2003 10:27:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQly-0002QC-00; Tue, 15 Jul 2003 10:27:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cQlt-0002Q3-00; Tue, 15 Jul 2003 10:27:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQlh-0000Tw-8O; Tue, 15 Jul 2003 10:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQlI-0000Ta-Qd for simple@optimus.ietf.org; Tue, 15 Jul 2003 10:26:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21518 for ; Tue, 15 Jul 2003 10:26:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQlG-0002Ph-00 for simple@ietf.org; Tue, 15 Jul 2003 10:26:34 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cQl0-0002Or-00 for simple@ietf.org; Tue, 15 Jul 2003 10:26:19 -0400 Received: from dynamicsoft.com ([63.113.46.32]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6FEOuiB010071; Tue, 15 Jul 2003 10:24:56 -0400 (EDT) Message-ID: <3F140EB1.3090704@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C54@stntexch2.va.neustar.com> <3F039C6B.3020305@cs.columbia.edu> <3F116046.3040707@dynamicsoft.com> <3F1167A8.3020203@cs.columbia.edu> <3F134F25.9080304@dynamicsoft.com> <3F13E34E.9040706@cs.columbia.edu> In-Reply-To: <3F13E34E.9040706@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 10:24:49 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> Well, those would be different. This is for homepages. I'm not saying >> that other things arent useful, I'm just saying that, since this >> information will be consumed by automata and not just rendered, we >> need to be as precise as possible about what it means. > > > I view an ldap: reference as a structured homepage, given that most > homepages contain information on how to contact a person and that most > browsers render LDAP URI as an HTML page. However, I doubt that it's > worth making this a major issue, if we can describe the content > appropriately. I gather you want to limit this "web home page". > Yes. Again, the premise is that an automata has to know enough to do something with it. I think "web homepage" is sufficiently concrete to do useful things with (i.e., add it to bookmarks). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 10:27:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21567 for ; Tue, 15 Jul 2003 10:27:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQm2-0000XX-CE for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 10:27:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FERMcr002071 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 10:27:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQm2-0000XK-7W for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 10:27:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21549; Tue, 15 Jul 2003 10:27:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQly-0002QC-00; Tue, 15 Jul 2003 10:27:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cQlt-0002Q3-00; Tue, 15 Jul 2003 10:27:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQlh-0000Tw-8O; Tue, 15 Jul 2003 10:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQlI-0000Ta-Qd for simple@optimus.ietf.org; Tue, 15 Jul 2003 10:26:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21518 for ; Tue, 15 Jul 2003 10:26:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQlG-0002Ph-00 for simple@ietf.org; Tue, 15 Jul 2003 10:26:34 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cQl0-0002Or-00 for simple@ietf.org; Tue, 15 Jul 2003 10:26:19 -0400 Received: from dynamicsoft.com ([63.113.46.32]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6FEOuiB010071; Tue, 15 Jul 2003 10:24:56 -0400 (EDT) Message-ID: <3F140EB1.3090704@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Peterson, Jon" , "Simpletons (E-mail)" Subject: Re: [Simple] comments on rpids-01 - References: <0449D80A0E9B614A83FA9031B07E8D3B257C54@stntexch2.va.neustar.com> <3F039C6B.3020305@cs.columbia.edu> <3F116046.3040707@dynamicsoft.com> <3F1167A8.3020203@cs.columbia.edu> <3F134F25.9080304@dynamicsoft.com> <3F13E34E.9040706@cs.columbia.edu> In-Reply-To: <3F13E34E.9040706@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 10:24:49 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> Well, those would be different. This is for homepages. I'm not saying >> that other things arent useful, I'm just saying that, since this >> information will be consumed by automata and not just rendered, we >> need to be as precise as possible about what it means. > > > I view an ldap: reference as a structured homepage, given that most > homepages contain information on how to contact a person and that most > browsers render LDAP URI as an HTML page. However, I doubt that it's > worth making this a major issue, if we can describe the content > appropriately. I gather you want to limit this "web home page". > Yes. Again, the premise is that an automata has to know enough to do something with it. I think "web homepage" is sufficiently concrete to do useful things with (i.e., add it to bookmarks). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 10:32:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21753; Tue, 15 Jul 2003 10:32:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQqd-0002UB-00; Tue, 15 Jul 2003 10:32:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cQqX-0002U8-00; Tue, 15 Jul 2003 10:32:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQqX-0000iB-Dz; Tue, 15 Jul 2003 10:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQpw-0000hW-9r for simple@optimus.ietf.org; Tue, 15 Jul 2003 10:31:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21707 for ; Tue, 15 Jul 2003 10:31:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQph-0002TC-00 for simple@ietf.org; Tue, 15 Jul 2003 10:31:09 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19cQpW-0002SU-00 for simple@ietf.org; Tue, 15 Jul 2003 10:30:58 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2003 07:28:44 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6FETNuD022248; Tue, 15 Jul 2003 07:29:23 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4148.cisco.com [10.61.80.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR13605; Tue, 15 Jul 2003 10:29:20 -0400 (EDT) Message-ID: <3F140FC0.2060202@cisco.com> 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 CC: hisham.khartabil@nokia.com, Brian.Rosen@marconi.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Tuple design team discussion summary References: <2038BCC78B1AD641891A0D1AE133DBB701796F0C@esebe019.ntc.nokia.com> <3F13DFE5.7050708@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 10:29:20 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > hisham.khartabil@nokia.com wrote: > >> I agree with Brian. I think we only ever discussed those 3: device, >> service and user. We don't need to be very explicit, information in >> the tuple give away the finer details about that thing that the tuple >> represents. >> >> Other than those 3, I haven't heard of other things that a tuple can >> represent, unless we allow a combination of the 3 above (which I >> believe we don't). > > > To beat a horse carcass: While device and 'user' has reasonable > definitions, nobody, after a year+, has provided an operational > definition of service. Since this label needs to be understandable by > people who have not participated in the Tuple Theory 745 class (this is > graduate-level stuff...), I don't think an elaborate definition helps. > > 'device', 'user' and 'other' seem to work ok, which seems to be close > enough. (Earlier versions of RPIDS had an approximation to such an > element, with the addition of 'group'.) For those, there are reasonable > pictograms, too - phone, stick person and ?. Works for me. I have kept asking people who use the term "service" to define it for me, assuming I was just ignorant of the definition everyone was using. But I have yet to hear one. So I think the choice is either that there are only two reasonable views, or else "other" covers the rest. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 10:32:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21842 for ; Tue, 15 Jul 2003 10:32:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQqg-0000ld-Py for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 10:32:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FEWAF7002943 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 10:32:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQqg-0000lO-MW for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 10:32:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21753; Tue, 15 Jul 2003 10:32:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQqd-0002UB-00; Tue, 15 Jul 2003 10:32:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cQqX-0002U8-00; Tue, 15 Jul 2003 10:32:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQqX-0000iB-Dz; Tue, 15 Jul 2003 10:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQpw-0000hW-9r for simple@optimus.ietf.org; Tue, 15 Jul 2003 10:31:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21707 for ; Tue, 15 Jul 2003 10:31:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQph-0002TC-00 for simple@ietf.org; Tue, 15 Jul 2003 10:31:09 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19cQpW-0002SU-00 for simple@ietf.org; Tue, 15 Jul 2003 10:30:58 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2003 07:28:44 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6FETNuD022248; Tue, 15 Jul 2003 07:29:23 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4148.cisco.com [10.61.80.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR13605; Tue, 15 Jul 2003 10:29:20 -0400 (EDT) Message-ID: <3F140FC0.2060202@cisco.com> 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 CC: hisham.khartabil@nokia.com, Brian.Rosen@marconi.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Tuple design team discussion summary References: <2038BCC78B1AD641891A0D1AE133DBB701796F0C@esebe019.ntc.nokia.com> <3F13DFE5.7050708@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 10:29:20 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > hisham.khartabil@nokia.com wrote: > >> I agree with Brian. I think we only ever discussed those 3: device, >> service and user. We don't need to be very explicit, information in >> the tuple give away the finer details about that thing that the tuple >> represents. >> >> Other than those 3, I haven't heard of other things that a tuple can >> represent, unless we allow a combination of the 3 above (which I >> believe we don't). > > > To beat a horse carcass: While device and 'user' has reasonable > definitions, nobody, after a year+, has provided an operational > definition of service. Since this label needs to be understandable by > people who have not participated in the Tuple Theory 745 class (this is > graduate-level stuff...), I don't think an elaborate definition helps. > > 'device', 'user' and 'other' seem to work ok, which seems to be close > enough. (Earlier versions of RPIDS had an approximation to such an > element, with the addition of 'group'.) For those, there are reasonable > pictograms, too - phone, stick person and ?. Works for me. I have kept asking people who use the term "service" to define it for me, assuming I was just ignorant of the definition everyone was using. But I have yet to hear one. So I think the choice is either that there are only two reasonable views, or else "other" covers the rest. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 10:33:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21873; Tue, 15 Jul 2003 10:33:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQrY-0002Uj-00; Tue, 15 Jul 2003 10:33:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cQrT-0002Ug-00; Tue, 15 Jul 2003 10:32:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQrU-0000mD-T8; Tue, 15 Jul 2003 10:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQrC-0000lk-6D for simple@optimus.ietf.org; Tue, 15 Jul 2003 10:32:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21850 for ; Tue, 15 Jul 2003 10:32:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQr6-0002UT-00 for simple@ietf.org; Tue, 15 Jul 2003 10:32:36 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cQqv-0002T5-00 for simple@ietf.org; Tue, 15 Jul 2003 10:32:25 -0400 Received: from dynamicsoft.com ([63.113.46.32]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6FEUkiB010074; Tue, 15 Jul 2003 10:30:46 -0400 (EDT) Message-ID: <3F14100C.2050103@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Adam Roach , simple@ietf.org Subject: Re: [Simple] Date Formats References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEA@dyn-tx-exch-001.dynamicsoft.com> <3F134682.80602@dynamicsoft.com> <3F13BBBB.7020701@cs.columbia.edu> In-Reply-To: <3F13BBBB.7020701@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 10:30:36 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> Seems like it should be the SIP format. > > > Except in XML, where it really can't be, if you would like to use schemas. > > Yeah, this occurred to me after I sent my response. Well, there is no obvious win. I would tend to think that implementations would use third party XML libraries which would have their own code for date parsing, separate from the SIP code. As such, its not clear how much opportunity there is for code reuse really. Of course, thats based on assumptions, and perhaps some devices (i.e., wireless phones) don't use any standard libraries or anything. So, maybe the answer is to have both? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 10:33:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21893 for ; Tue, 15 Jul 2003 10:33:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQrc-0000pk-9E for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 10:33:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FEX8eo003198 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 10:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQrc-0000pV-4z for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 10:33:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21873; Tue, 15 Jul 2003 10:33:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQrY-0002Uj-00; Tue, 15 Jul 2003 10:33:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cQrT-0002Ug-00; Tue, 15 Jul 2003 10:32:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQrU-0000mD-T8; Tue, 15 Jul 2003 10:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQrC-0000lk-6D for simple@optimus.ietf.org; Tue, 15 Jul 2003 10:32:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21850 for ; Tue, 15 Jul 2003 10:32:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cQr6-0002UT-00 for simple@ietf.org; Tue, 15 Jul 2003 10:32:36 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cQqv-0002T5-00 for simple@ietf.org; Tue, 15 Jul 2003 10:32:25 -0400 Received: from dynamicsoft.com ([63.113.46.32]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6FEUkiB010074; Tue, 15 Jul 2003 10:30:46 -0400 (EDT) Message-ID: <3F14100C.2050103@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Adam Roach , simple@ietf.org Subject: Re: [Simple] Date Formats References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEA@dyn-tx-exch-001.dynamicsoft.com> <3F134682.80602@dynamicsoft.com> <3F13BBBB.7020701@cs.columbia.edu> In-Reply-To: <3F13BBBB.7020701@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 10:30:36 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> Seems like it should be the SIP format. > > > Except in XML, where it really can't be, if you would like to use schemas. > > Yeah, this occurred to me after I sent my response. Well, there is no obvious win. I would tend to think that implementations would use third party XML libraries which would have their own code for date parsing, separate from the SIP code. As such, its not clear how much opportunity there is for code reuse really. Of course, thats based on assumptions, and perhaps some devices (i.e., wireless phones) don't use any standard libraries or anything. So, maybe the answer is to have both? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 10:50:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22563; Tue, 15 Jul 2003 10:50:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cR83-0002dM-00; Tue, 15 Jul 2003 10:50:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cR7x-0002dJ-00; Tue, 15 Jul 2003 10:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cR7w-0001lw-Qy; Tue, 15 Jul 2003 10:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cR7M-0001lI-3M for simple@optimus.ietf.org; Tue, 15 Jul 2003 10:49:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22558 for ; Tue, 15 Jul 2003 10:49:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cR7J-0002dA-00 for simple@ietf.org; Tue, 15 Jul 2003 10:49:21 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19cR79-0002d7-00 for simple@ietf.org; Tue, 15 Jul 2003 10:49:11 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6FEmSuL026549; Tue, 15 Jul 2003 07:48:33 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4148.cisco.com [10.61.80.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR15613; Tue, 15 Jul 2003 10:48:26 -0400 (EDT) Message-ID: <3F141439.7020000@cisco.com> 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 CC: Ben Campbell , Simple WG Subject: Re: [Simple] Tuple design team discussion summary References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> <3F135001.9040206@dynamicsoft.com> <1058257541.2536.7.camel@verite.localdomain> <3F13BD7D.409@cs.columbia.edu> <1058259234.2536.27.camel@verite.localdomain> <3F13C7BE.90107@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 10:48:25 -0400 Content-Transfer-Encoding: 7bit I find it attractive to expect client devices to synthesize icons (if they want them at all) from combinations of capabilities that they find interesting. Devices with limited capabilities will only be interested in a few capabilities of the tuple, and can probably synthesize them into a unique icon that fits the geometry of the device. More powerful devices (e.g. pc) may be interested in a wider variety of capabilities of the tuple. This makes it problematic to combine all into a single useful tuple. But in that case there is probably room to render multiple icons, for individual capabilities, or for interesting subsets of capabilities. Paul Henning Schulzrinne wrote: > As I noted earlier, I see no point in having a label that is simply the > combinations of existing RPIDS fields that the receiver can also combine > into a label. > > Ben Campbell wrote: > >> Hopefully we can generalize these a bit. For example: >> >> voice device > > > capability = audio, mobility undefined > >> Mobile voice device > > > mobile, audio > >> Fixed voice device > > > fixed, audio > >> Workstation (or some sort of rich media device) > > > fixed, audio, video, text > >> text device > > > *, text > >> short text device (i.e. don't send me big stuff) > > > shouldn't that be a capability addition? (I'm not sure if this should be > a qualitative or quantitive capability.) > >> >> This list seems to me to break down to a few dimensions: >> >> Mobility >> Media >> stream/message orientation >> Size limits >> >> Which sound a lot like capabilities to me. > > > I'm not sure if you're agreeing that the proposed labels are merely > re-stating information that's already available or if they are useful. > > > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Jul 15 10:50:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22608 for ; Tue, 15 Jul 2003 10:50:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cR87-0001oU-Av for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 10:50:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FEoB8U006964 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 10:50:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cR86-0001oF-NF for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 10:50:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22563; Tue, 15 Jul 2003 10:50:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cR83-0002dM-00; Tue, 15 Jul 2003 10:50:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cR7x-0002dJ-00; Tue, 15 Jul 2003 10:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cR7w-0001lw-Qy; Tue, 15 Jul 2003 10:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cR7M-0001lI-3M for simple@optimus.ietf.org; Tue, 15 Jul 2003 10:49:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22558 for ; Tue, 15 Jul 2003 10:49:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cR7J-0002dA-00 for simple@ietf.org; Tue, 15 Jul 2003 10:49:21 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19cR79-0002d7-00 for simple@ietf.org; Tue, 15 Jul 2003 10:49:11 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6FEmSuL026549; Tue, 15 Jul 2003 07:48:33 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4148.cisco.com [10.61.80.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR15613; Tue, 15 Jul 2003 10:48:26 -0400 (EDT) Message-ID: <3F141439.7020000@cisco.com> 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 CC: Ben Campbell , Simple WG Subject: Re: [Simple] Tuple design team discussion summary References: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> <3F135001.9040206@dynamicsoft.com> <1058257541.2536.7.camel@verite.localdomain> <3F13BD7D.409@cs.columbia.edu> <1058259234.2536.27.camel@verite.localdomain> <3F13C7BE.90107@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 10:48:25 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I find it attractive to expect client devices to synthesize icons (if they want them at all) from combinations of capabilities that they find interesting. Devices with limited capabilities will only be interested in a few capabilities of the tuple, and can probably synthesize them into a unique icon that fits the geometry of the device. More powerful devices (e.g. pc) may be interested in a wider variety of capabilities of the tuple. This makes it problematic to combine all into a single useful tuple. But in that case there is probably room to render multiple icons, for individual capabilities, or for interesting subsets of capabilities. Paul Henning Schulzrinne wrote: > As I noted earlier, I see no point in having a label that is simply the > combinations of existing RPIDS fields that the receiver can also combine > into a label. > > Ben Campbell wrote: > >> Hopefully we can generalize these a bit. For example: >> >> voice device > > > capability = audio, mobility undefined > >> Mobile voice device > > > mobile, audio > >> Fixed voice device > > > fixed, audio > >> Workstation (or some sort of rich media device) > > > fixed, audio, video, text > >> text device > > > *, text > >> short text device (i.e. don't send me big stuff) > > > shouldn't that be a capability addition? (I'm not sure if this should be > a qualitative or quantitive capability.) > >> >> This list seems to me to break down to a few dimensions: >> >> Mobility >> Media >> stream/message orientation >> Size limits >> >> Which sound a lot like capabilities to me. > > > I'm not sure if you're agreeing that the proposed labels are merely > re-stating information that's already available or if they are useful. > > > > > _______________________________________________ > 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-admin@ietf.org Tue Jul 15 11:00:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23030; Tue, 15 Jul 2003 11:00:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cRHj-0002jF-00; Tue, 15 Jul 2003 11:00:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cRHe-0002jC-00; Tue, 15 Jul 2003 11:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRHd-0002CY-L4; Tue, 15 Jul 2003 11:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRH2-0002Bm-Mg for simple@optimus.ietf.org; Tue, 15 Jul 2003 10:59:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23004 for ; Tue, 15 Jul 2003 10:59:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cRH0-0002id-00 for simple@ietf.org; Tue, 15 Jul 2003 10:59:22 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19cRGp-0002fj-00 for simple@ietf.org; Tue, 15 Jul 2003 10:59:11 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6FEvKpp024368; Tue, 15 Jul 2003 07:57:21 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4148.cisco.com [10.61.80.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR16505; Tue, 15 Jul 2003 10:57:18 -0400 (EDT) Message-ID: <3F14164E.60404@cisco.com> 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: Robert Sparks CC: Aki Niemi , simple@ietf.org Subject: Re: [Simple] PUBLISH: atomicity problem References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB0@esebe013.ntc.nokia.com> <1058260190.934.23.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 10:57:18 -0400 Content-Transfer-Encoding: 7bit Another way to approach this is to make it a problem for the publisher to deal with. If the publisher wants, it can publish each tuple separately, with the positive and negative consequences you mention. As an optimization, the publisher can batch up a bunch of tuples and hope to publish them together. If this fails, it should fall back to publishing them independently. Once it discovers which ones can be successfully published, it can batch those up in future updates, omitting the ones that failed. Paul Robert Sparks wrote: > Another way to state this conclusion is that we need to report > success or failure of publishing each atomic element in an independent > fashion. One quick and easy way to achieve that property is to allow > only one atomic element per PUBLISH request. > > I think I heard another way to do this mentioned during the meeting, > where we move reporting the success/failure and any feedback from > the attempt to publish each tuple into the message instead of trying > to capture it all on the status line. For example (I think this is > what I heard suggested during the meeting), for presence, we could > publish an entire pidf document with several tuples and in the presence > response return an xml document with one element per tuple discussing > the disposition of attempting to publish that tuple. > > Something along the lines of the following (an example to convey the > concept, not a proposal of a syntax) > > > > > > > > > > If we were to pursue such an optimization, it might make sense to > look at how to specify a separate etag value in the publish (currently > what we put in an If-Match header) for each atom in the published > document. > > RjS > > On Mon, 2003-07-14 at 19:58, aki.niemi@nokia.com wrote: > >>All, >> >>I'll try to summarize the issues w.r.t. the atomicity of publication here in an attempt to converge the discussion towards a solution to this problem. BTW, I realized that my slides in the SIMPLE session were perhaps not crystal clear on what the problem at hand really was, so my apologies for that. >> >>The core problem is this: >> >>EPA X sends a PUBLISH with {a, b, c}, after which EPA Y publishes {a, b}. When EPA X tries to refresh its publication of {a, b, c}, the request fails because of a collision, resulting in the EPA X quitting. EPA Y still refreshes its publication of {a, b}, which means {c} expires and goes away. As a result, the publication process has lost information of {c}. This is unacceptable, and with the current versioning mechanism, this can't be remedied by composer policy, for example. >> >>Instead, to get around the above problem, what you send in a PUBLISH needs to match the atomic element of the published information. So each PUBLISH needs to contain a single tuple, because the versioning and expiration all work on the single atomic element level anyway. >> >>This has the apparent drawback in that the PUA has to wait for a 200 OK after each PUBLISHed tuple before it can PUBLISH the next one. This occurs upon every refresh cycle, and in systems with high latency, may become a major issue in terms of performance. >> >>Ways to get around this inefficiency: >> - Remove the restriction on overlapping requests, i.e., allow "pipelining" >> of PUBLISH requests >> - Treat the publisher of each tuple as a separate EPA, and therefore not >> subject to this restriction in the first place (seems like cheating...) >> >>In conclusion, my proposal is to go with having always a single tuple in a PUBLISH, and allow overlapping PUBLISH requests. To my knowledge, this would fulfill all the related requirements and solve the issue. >> >>Thoughts? >> >>Cheers, >>Aki >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 11:00:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23050 for ; Tue, 15 Jul 2003 11:00:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRHo-0002G3-4D for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 11:00:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FF0B2o008678 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 11:00:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRHn-0002Ft-3x for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 11:00:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23030; Tue, 15 Jul 2003 11:00:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cRHj-0002jF-00; Tue, 15 Jul 2003 11:00:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cRHe-0002jC-00; Tue, 15 Jul 2003 11:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRHd-0002CY-L4; Tue, 15 Jul 2003 11:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRH2-0002Bm-Mg for simple@optimus.ietf.org; Tue, 15 Jul 2003 10:59:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23004 for ; Tue, 15 Jul 2003 10:59:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cRH0-0002id-00 for simple@ietf.org; Tue, 15 Jul 2003 10:59:22 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19cRGp-0002fj-00 for simple@ietf.org; Tue, 15 Jul 2003 10:59:11 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6FEvKpp024368; Tue, 15 Jul 2003 07:57:21 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4148.cisco.com [10.61.80.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR16505; Tue, 15 Jul 2003 10:57:18 -0400 (EDT) Message-ID: <3F14164E.60404@cisco.com> 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: Robert Sparks CC: Aki Niemi , simple@ietf.org Subject: Re: [Simple] PUBLISH: atomicity problem References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB0@esebe013.ntc.nokia.com> <1058260190.934.23.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 10:57:18 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Another way to approach this is to make it a problem for the publisher to deal with. If the publisher wants, it can publish each tuple separately, with the positive and negative consequences you mention. As an optimization, the publisher can batch up a bunch of tuples and hope to publish them together. If this fails, it should fall back to publishing them independently. Once it discovers which ones can be successfully published, it can batch those up in future updates, omitting the ones that failed. Paul Robert Sparks wrote: > Another way to state this conclusion is that we need to report > success or failure of publishing each atomic element in an independent > fashion. One quick and easy way to achieve that property is to allow > only one atomic element per PUBLISH request. > > I think I heard another way to do this mentioned during the meeting, > where we move reporting the success/failure and any feedback from > the attempt to publish each tuple into the message instead of trying > to capture it all on the status line. For example (I think this is > what I heard suggested during the meeting), for presence, we could > publish an entire pidf document with several tuples and in the presence > response return an xml document with one element per tuple discussing > the disposition of attempting to publish that tuple. > > Something along the lines of the following (an example to convey the > concept, not a proposal of a syntax) > > > > > > > > > > If we were to pursue such an optimization, it might make sense to > look at how to specify a separate etag value in the publish (currently > what we put in an If-Match header) for each atom in the published > document. > > RjS > > On Mon, 2003-07-14 at 19:58, aki.niemi@nokia.com wrote: > >>All, >> >>I'll try to summarize the issues w.r.t. the atomicity of publication here in an attempt to converge the discussion towards a solution to this problem. BTW, I realized that my slides in the SIMPLE session were perhaps not crystal clear on what the problem at hand really was, so my apologies for that. >> >>The core problem is this: >> >>EPA X sends a PUBLISH with {a, b, c}, after which EPA Y publishes {a, b}. When EPA X tries to refresh its publication of {a, b, c}, the request fails because of a collision, resulting in the EPA X quitting. EPA Y still refreshes its publication of {a, b}, which means {c} expires and goes away. As a result, the publication process has lost information of {c}. This is unacceptable, and with the current versioning mechanism, this can't be remedied by composer policy, for example. >> >>Instead, to get around the above problem, what you send in a PUBLISH needs to match the atomic element of the published information. So each PUBLISH needs to contain a single tuple, because the versioning and expiration all work on the single atomic element level anyway. >> >>This has the apparent drawback in that the PUA has to wait for a 200 OK after each PUBLISHed tuple before it can PUBLISH the next one. This occurs upon every refresh cycle, and in systems with high latency, may become a major issue in terms of performance. >> >>Ways to get around this inefficiency: >> - Remove the restriction on overlapping requests, i.e., allow "pipelining" >> of PUBLISH requests >> - Treat the publisher of each tuple as a separate EPA, and therefore not >> subject to this restriction in the first place (seems like cheating...) >> >>In conclusion, my proposal is to go with having always a single tuple in a PUBLISH, and allow overlapping PUBLISH requests. To my knowledge, this would fulfill all the related requirements and solve the issue. >> >>Thoughts? >> >>Cheers, >>Aki >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 11:09:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23394; Tue, 15 Jul 2003 11:09:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cRQQ-0002mG-00; Tue, 15 Jul 2003 11:09:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cRQL-0002mD-00; Tue, 15 Jul 2003 11:09:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRQL-0002fm-81; Tue, 15 Jul 2003 11:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRQF-0002fT-J9 for simple@optimus.ietf.org; Tue, 15 Jul 2003 11:08:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23390 for ; Tue, 15 Jul 2003 11:08:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cRQC-0002m9-00 for simple@ietf.org; Tue, 15 Jul 2003 11:08:52 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19cRQ2-0002lu-00 for simple@ietf.org; Tue, 15 Jul 2003 11:08:42 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA09776; Tue, 15 Jul 2003 11:07:45 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25670; Tue, 15 Jul 2003 11:07:46 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MT3L3>; Tue, 15 Jul 2003 11:07:46 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5BF7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Chris Boulton'" , Henning Schulzrinne , hisham.khartabil@nokia.com Cc: bcampbell@dynamicsoft.com, simple@ietf.org Subject: RE: [Simple] Tuple design team discussion summary MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 11:07:43 -0400 I think it will be unusual to have both device and service tuples in a single presence document, but it could happen. Rather, I see a service provider aggregating a number of separate device presence documents to produce a single service tuple. I also then could see another aggregator (a presence aggregator) aggregating a number of service tuple into a single user tuple. In all of these cases, it could be an option for the aggregator to accept a request to provide lower level information. Given permissions were available, that could happen. I actually expect in most cases, permission will NOT be forthcoming. If for some reason, you got both device and service tuples in one document, I don't think there is, in general, any way to group them, and I don't think that matters. Brian > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: Tuesday, July 15, 2003 8:32 AM > To: Rosen, Brian; Henning Schulzrinne; hisham.khartabil@nokia.com > Cc: bcampbell@dynamicsoft.com; simple@ietf.org > Subject: RE: [Simple] Tuple design team discussion summary > > > Brian, > This structure seems reasonable to me - One question, I > understand that a user Tuple would be present with multiple > service tuples. How are the device tuples associated with > the correct service tuples (maybe this is clear and I am > missing something) - could the class attribute be used? > > Chris. > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tue 15/07/2003 12:40 > To: 'Henning Schulzrinne'; hisham.khartabil@nokia.com > Cc: bcampbell@dynamicsoft.com; simple@ietf.org > Subject: RE: [Simple] Tuple design team discussion summary > > > > For this purpose, a service is a tuple representing a > communications > path to a set of devices that have some common characteristics. > The tuple contains the URI to the service, and the > characteristics > (capabilities) > of the service. > > The service endeavors to deliver a request for > communication to an > appropriate > device from the set of devices it controls. The > presence information > presented by the service is represents that of the > service as a whole, > rather than that of one of its constituent devices. It is NOT > necessarily a simple pivot of device presence > information. The service > may have additional information, and it may combine > information in > ways not expressible as a pivot of the device data. > > A service is differentiated from a device in that the > URI explicitly > represents the services, requests for communication > will be forwarded > to one of the devices the service controls. > > A service is differentiated from a user in that a user may have > multiple services, each of which may have separate > presence tuples. > Normally, a user has a single tuple representing the presence of > the user as a person. > > You can think of this as a hierarchy, where a user has a set of > services each of which has a set of devices. Nothing limits > the hierarchy to two levels (a service could aggregate multiple > services, although I can't think of an example that makes a lot > of sense). It's also possible to have a user who doesn't have > services. In that case he has a set of devices that > are aggregated > directly to form the user tuple. The service is equal > to device. > > Brian > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, July 15, 2003 7:05 AM > > To: hisham.khartabil@nokia.com > > Cc: Brian.Rosen@marconi.com; bcampbell@dynamicsoft.com; > > simple@ietf.org > > Subject: Re: [Simple] Tuple design team discussion summary > > > > > > hisham.khartabil@nokia.com wrote: > > > > > I agree with Brian. I think we only ever discussed > those 3: device, > > > service and user. We don't need to be very > explicit, information in > > > the tuple give away the finer details about that thing that > > the tuple > > > represents. > > > > > > Other than those 3, I haven't heard of other things > that a tuple can > > > represent, unless we allow a combination of the 3 > above (which I > > > believe we don't). > > > > To beat a horse carcass: While device and 'user' has > reasonable > > definitions, nobody, after a year+, has provided an > operational > > definition of service. Since this label needs to be > understandable by > > people who have not participated in the Tuple Theory 745 > > class (this is > > graduate-level stuff...), I don't think an elaborate > definition helps. > > > > 'device', 'user' and 'other' seem to work ok, which > seems to be close > > enough. (Earlier versions of RPIDS had an > approximation to such an > > element, with the addition of 'group'.) For those, there are > > reasonable > > pictograms, too - phone, stick person and ?. > > > > 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 > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 11:09:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23434 for ; Tue, 15 Jul 2003 11:09:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRQU-0002jE-Cm for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 11:09:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FF9AQA010482 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 11:09:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRQU-0002iz-9E for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 11:09:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23394; Tue, 15 Jul 2003 11:09:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cRQQ-0002mG-00; Tue, 15 Jul 2003 11:09:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cRQL-0002mD-00; Tue, 15 Jul 2003 11:09:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRQL-0002fm-81; Tue, 15 Jul 2003 11:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRQF-0002fT-J9 for simple@optimus.ietf.org; Tue, 15 Jul 2003 11:08:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23390 for ; Tue, 15 Jul 2003 11:08:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cRQC-0002m9-00 for simple@ietf.org; Tue, 15 Jul 2003 11:08:52 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19cRQ2-0002lu-00 for simple@ietf.org; Tue, 15 Jul 2003 11:08:42 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA09776; Tue, 15 Jul 2003 11:07:45 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25670; Tue, 15 Jul 2003 11:07:46 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MT3L3>; Tue, 15 Jul 2003 11:07:46 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5BF7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Chris Boulton'" , Henning Schulzrinne , hisham.khartabil@nokia.com Cc: bcampbell@dynamicsoft.com, simple@ietf.org Subject: RE: [Simple] Tuple design team discussion summary MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 11:07:43 -0400 I think it will be unusual to have both device and service tuples in a single presence document, but it could happen. Rather, I see a service provider aggregating a number of separate device presence documents to produce a single service tuple. I also then could see another aggregator (a presence aggregator) aggregating a number of service tuple into a single user tuple. In all of these cases, it could be an option for the aggregator to accept a request to provide lower level information. Given permissions were available, that could happen. I actually expect in most cases, permission will NOT be forthcoming. If for some reason, you got both device and service tuples in one document, I don't think there is, in general, any way to group them, and I don't think that matters. Brian > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: Tuesday, July 15, 2003 8:32 AM > To: Rosen, Brian; Henning Schulzrinne; hisham.khartabil@nokia.com > Cc: bcampbell@dynamicsoft.com; simple@ietf.org > Subject: RE: [Simple] Tuple design team discussion summary > > > Brian, > This structure seems reasonable to me - One question, I > understand that a user Tuple would be present with multiple > service tuples. How are the device tuples associated with > the correct service tuples (maybe this is clear and I am > missing something) - could the class attribute be used? > > Chris. > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tue 15/07/2003 12:40 > To: 'Henning Schulzrinne'; hisham.khartabil@nokia.com > Cc: bcampbell@dynamicsoft.com; simple@ietf.org > Subject: RE: [Simple] Tuple design team discussion summary > > > > For this purpose, a service is a tuple representing a > communications > path to a set of devices that have some common characteristics. > The tuple contains the URI to the service, and the > characteristics > (capabilities) > of the service. > > The service endeavors to deliver a request for > communication to an > appropriate > device from the set of devices it controls. The > presence information > presented by the service is represents that of the > service as a whole, > rather than that of one of its constituent devices. It is NOT > necessarily a simple pivot of device presence > information. The service > may have additional information, and it may combine > information in > ways not expressible as a pivot of the device data. > > A service is differentiated from a device in that the > URI explicitly > represents the services, requests for communication > will be forwarded > to one of the devices the service controls. > > A service is differentiated from a user in that a user may have > multiple services, each of which may have separate > presence tuples. > Normally, a user has a single tuple representing the presence of > the user as a person. > > You can think of this as a hierarchy, where a user has a set of > services each of which has a set of devices. Nothing limits > the hierarchy to two levels (a service could aggregate multiple > services, although I can't think of an example that makes a lot > of sense). It's also possible to have a user who doesn't have > services. In that case he has a set of devices that > are aggregated > directly to form the user tuple. The service is equal > to device. > > Brian > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, July 15, 2003 7:05 AM > > To: hisham.khartabil@nokia.com > > Cc: Brian.Rosen@marconi.com; bcampbell@dynamicsoft.com; > > simple@ietf.org > > Subject: Re: [Simple] Tuple design team discussion summary > > > > > > hisham.khartabil@nokia.com wrote: > > > > > I agree with Brian. I think we only ever discussed > those 3: device, > > > service and user. We don't need to be very > explicit, information in > > > the tuple give away the finer details about that thing that > > the tuple > > > represents. > > > > > > Other than those 3, I haven't heard of other things > that a tuple can > > > represent, unless we allow a combination of the 3 > above (which I > > > believe we don't). > > > > To beat a horse carcass: While device and 'user' has > reasonable > > definitions, nobody, after a year+, has provided an > operational > > definition of service. Since this label needs to be > understandable by > > people who have not participated in the Tuple Theory 745 > > class (this is > > graduate-level stuff...), I don't think an elaborate > definition helps. > > > > 'device', 'user' and 'other' seem to work ok, which > seems to be close > > enough. (Earlier versions of RPIDS had an > approximation to such an > > element, with the addition of 'group'.) For those, there are > > reasonable > > pictograms, too - phone, stick person and ?. > > > > 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 > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 11:22:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23937; Tue, 15 Jul 2003 11:22:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cRd2-0002tq-00; Tue, 15 Jul 2003 11:22:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cRcw-0002tn-00; Tue, 15 Jul 2003 11:22:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRcu-0003RJ-IM; Tue, 15 Jul 2003 11:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRcL-0003Qo-37 for simple@optimus.ietf.org; Tue, 15 Jul 2003 11:21:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23898 for ; Tue, 15 Jul 2003 11:21:20 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cRcK-0002tJ-00 for simple@ietf.org; Tue, 15 Jul 2003 11:21:24 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19cRc9-0002si-00 for simple@ietf.org; Tue, 15 Jul 2003 11:21:13 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6FFKma01602 for ; Tue, 15 Jul 2003 18:20:48 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 18:20:47 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 18:20:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] comments on rpids-01 (general, vCard, predictive) Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945329@esebe013.ntc.nokia.com> Thread-Topic: [Simple] comments on rpids-01 (general, vCard, predictive) Thread-Index: AcNKsU/TSUk6eJ22TPyWF89hP/a9ZgAMbQ4g To: , Cc: , , X-OriginalArrivalTime: 15 Jul 2003 15:20:46.0554 (UTC) FILETIME=[AA3BA3A0:01C34AE4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 18:20:45 +0300 Content-Transfer-Encoding: quoted-printable Inline. > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 15 July, 2003 12:08 > To: Adam Roach > Cc: Henning Schulzrinne; Jon Peterson; Simpletons (E-mail) > Subject: RE: [Simple] comments on rpids-01 (general, vCard,=20 > predictive) >=20 >=20 > On Mon, 2003-07-14 at 08:47, Adam Roach wrote: > > > > Again, commercial instant messaging systems, in my=20 > > > experience, don't use > > > > presentity-provided icons to express a presentity's current=20 > > > state in a > > > > watcher's buddylist screen. Apps might have predefined=20 > > > icons corresponding > > > > to, say, your state as given in rpids-00, but I=20 > > > don't think I've > > > > seen user-supplied versions of those icons to date. The=20 > > > whole value of these > > >=20 > > > See GAIM above, albeit provided by the watcher, given=20 > the lack of=20 > > > protocol support. > >=20 > > I'm really going to have to agree strongly with Jon here. > > Allowing the presentity to provide icons to represent any > > kind of state -- and especially presence state -- is going > > to result in nothing but an inscrutable mish-mash of angry > > fruit salad in your buddy-list window. > >=20 > > It would be a real black eye if all or even most SIMPLE-based > > IM systems ended up being thematically similar to the typical > > poorly-designed amateur web page that consists primarily of > > jarringly mismatched graphics found elsewhere on the web. > >=20 >=20 > >From a user interface perspective, I have to concur. The=20 > whole point of > icons representing state is to give me a quick visual way to=20 > determine > that state. This only works if the icons are consistent. If every > presentity I watch uses a different set of icons, then they=20 > are useless > to me for that purpose. They become nothing but vanity plates for the > presentities, or worse, a form of advertising. (In the same sense, I > consider HTML favicons to be evil.) Even with an element present, you can still map whatever status = the tuple carries into a local icon. An is really a graphical = . The fact that watchers will probably have a wide variety of = different graphics to describe their tuples in different situations is a = feature, not a bug. This information isn't meant to be mapped to a = finite set of local icons, much like the note isn't. Also, I don't think the current description in RPIDS even = suggests that it be used to iconify a buddy in a buddy list window, so = maybe this really boils down to the name of the element. So perhaps a = describes this type of element better? Cheers, Aki >=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 exim@www1.ietf.org Tue Jul 15 11:22:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23979 for ; Tue, 15 Jul 2003 11:22:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRd4-0003Uq-GX for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 11:22:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FFMA0U013438 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 11:22:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRd4-0003Uf-Cl for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 11:22:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23937; Tue, 15 Jul 2003 11:22:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cRd2-0002tq-00; Tue, 15 Jul 2003 11:22:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cRcw-0002tn-00; Tue, 15 Jul 2003 11:22:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRcu-0003RJ-IM; Tue, 15 Jul 2003 11:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cRcL-0003Qo-37 for simple@optimus.ietf.org; Tue, 15 Jul 2003 11:21:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23898 for ; Tue, 15 Jul 2003 11:21:20 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cRcK-0002tJ-00 for simple@ietf.org; Tue, 15 Jul 2003 11:21:24 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19cRc9-0002si-00 for simple@ietf.org; Tue, 15 Jul 2003 11:21:13 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6FFKma01602 for ; Tue, 15 Jul 2003 18:20:48 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 18:20:47 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 18:20:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] comments on rpids-01 (general, vCard, predictive) Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945329@esebe013.ntc.nokia.com> Thread-Topic: [Simple] comments on rpids-01 (general, vCard, predictive) Thread-Index: AcNKsU/TSUk6eJ22TPyWF89hP/a9ZgAMbQ4g To: , Cc: , , X-OriginalArrivalTime: 15 Jul 2003 15:20:46.0554 (UTC) FILETIME=[AA3BA3A0:01C34AE4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 18:20:45 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Inline. > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 15 July, 2003 12:08 > To: Adam Roach > Cc: Henning Schulzrinne; Jon Peterson; Simpletons (E-mail) > Subject: RE: [Simple] comments on rpids-01 (general, vCard,=20 > predictive) >=20 >=20 > On Mon, 2003-07-14 at 08:47, Adam Roach wrote: > > > > Again, commercial instant messaging systems, in my=20 > > > experience, don't use > > > > presentity-provided icons to express a presentity's current=20 > > > state in a > > > > watcher's buddylist screen. Apps might have predefined=20 > > > icons corresponding > > > > to, say, your state as given in rpids-00, but I=20 > > > don't think I've > > > > seen user-supplied versions of those icons to date. The=20 > > > whole value of these > > >=20 > > > See GAIM above, albeit provided by the watcher, given=20 > the lack of=20 > > > protocol support. > >=20 > > I'm really going to have to agree strongly with Jon here. > > Allowing the presentity to provide icons to represent any > > kind of state -- and especially presence state -- is going > > to result in nothing but an inscrutable mish-mash of angry > > fruit salad in your buddy-list window. > >=20 > > It would be a real black eye if all or even most SIMPLE-based > > IM systems ended up being thematically similar to the typical > > poorly-designed amateur web page that consists primarily of > > jarringly mismatched graphics found elsewhere on the web. > >=20 >=20 > >From a user interface perspective, I have to concur. The=20 > whole point of > icons representing state is to give me a quick visual way to=20 > determine > that state. This only works if the icons are consistent. If every > presentity I watch uses a different set of icons, then they=20 > are useless > to me for that purpose. They become nothing but vanity plates for the > presentities, or worse, a form of advertising. (In the same sense, I > consider HTML favicons to be evil.) Even with an element present, you can still map whatever status = the tuple carries into a local icon. An is really a graphical = . The fact that watchers will probably have a wide variety of = different graphics to describe their tuples in different situations is a = feature, not a bug. This information isn't meant to be mapped to a = finite set of local icons, much like the note isn't. Also, I don't think the current description in RPIDS even = suggests that it be used to iconify a buddy in a buddy list window, so = maybe this really boils down to the name of the element. So perhaps a = describes this type of element better? Cheers, Aki >=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-admin@ietf.org Tue Jul 15 14:27:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28663; Tue, 15 Jul 2003 14:27:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cUW2-0004Mv-00; Tue, 15 Jul 2003 14:27:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cUVx-0004Ms-00; Tue, 15 Jul 2003 14:27:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cUVw-0003Pw-Dj; Tue, 15 Jul 2003 14:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cUVG-0003LQ-FV for simple@optimus.ietf.org; Tue, 15 Jul 2003 14:26:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28651 for ; Tue, 15 Jul 2003 14:26:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cUVD-0004Mc-00 for simple@ietf.org; Tue, 15 Jul 2003 14:26:16 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cUUx-0004M4-00 for simple@ietf.org; Tue, 15 Jul 2003 14:25:59 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6FIOxkM010348; Tue, 15 Jul 2003 14:24:59 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6FIOwg30711; Tue, 15 Jul 2003 14:24:58 -0400 Message-ID: <3F144603.4010401@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Tuple design team discussion summary References: <313680C9A886D511A06000204840E1CF070B5BF5@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B5BF5@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 14:20:51 -0400 Content-Transfer-Encoding: 7bit In short, service = collection of devices The 'common characteristic' is sufficiently vague that I'm not sure it is helpful. After all, you could presumably have a service that is simply the enumeration of all characteristics (say, if you combine all your Microsoft-supplied devices). With this definition, I think this labeling is at least conceptually complete: (1) one tuple (or relationship with multiple) = presentity, (2) several tuples fronting for more than one device each = service, (3) any number of devices that are not divisible. Presumably, labeling a single tuple as a presentity rather than a service implies that the presentity is complete - all devices are reachable through that. A presence document with just one 'service' tuple implies that there might be others which got filtered along the way. I'll add it to the draft. Rosen, Brian wrote: > For this purpose, a service is a tuple representing a communications > path to a set of devices that have some common characteristics. > The tuple contains the URI to the service, and the characteristics > (capabilities) > of the service. > > The service endeavors to deliver a request for communication to an > appropriate > device from the set of devices it controls. The presence information > presented by the service is represents that of the service as a whole, > rather than that of one of its constituent devices. It is NOT > necessarily a simple pivot of device presence information. The service > may have additional information, and it may combine information in > ways not expressible as a pivot of the device data. > > A service is differentiated from a device in that the URI explicitly > represents the services, requests for communication will be forwarded > to one of the devices the service controls. > > A service is differentiated from a user in that a user may have > multiple services, each of which may have separate presence tuples. > Normally, a user has a single tuple representing the presence of > the user as a person. > > You can think of this as a hierarchy, where a user has a set of > services each of which has a set of devices. Nothing limits > the hierarchy to two levels (a service could aggregate multiple > services, although I can't think of an example that makes a lot > of sense). It's also possible to have a user who doesn't have > services. In that case he has a set of devices that are aggregated > directly to form the user tuple. The service is equal to device. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 14:27:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28697 for ; Tue, 15 Jul 2003 14:27:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cUW6-0003RP-Do for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 14:27:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FIRAVj013227 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 14:27:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cUW6-0003RG-94 for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 14:27:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28663; Tue, 15 Jul 2003 14:27:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cUW2-0004Mv-00; Tue, 15 Jul 2003 14:27:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cUVx-0004Ms-00; Tue, 15 Jul 2003 14:27:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cUVw-0003Pw-Dj; Tue, 15 Jul 2003 14:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cUVG-0003LQ-FV for simple@optimus.ietf.org; Tue, 15 Jul 2003 14:26:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28651 for ; Tue, 15 Jul 2003 14:26:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cUVD-0004Mc-00 for simple@ietf.org; Tue, 15 Jul 2003 14:26:16 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cUUx-0004M4-00 for simple@ietf.org; Tue, 15 Jul 2003 14:25:59 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6FIOxkM010348; Tue, 15 Jul 2003 14:24:59 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6FIOwg30711; Tue, 15 Jul 2003 14:24:58 -0400 Message-ID: <3F144603.4010401@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Tuple design team discussion summary References: <313680C9A886D511A06000204840E1CF070B5BF5@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B5BF5@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 14:20:51 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In short, service = collection of devices The 'common characteristic' is sufficiently vague that I'm not sure it is helpful. After all, you could presumably have a service that is simply the enumeration of all characteristics (say, if you combine all your Microsoft-supplied devices). With this definition, I think this labeling is at least conceptually complete: (1) one tuple (or relationship with multiple) = presentity, (2) several tuples fronting for more than one device each = service, (3) any number of devices that are not divisible. Presumably, labeling a single tuple as a presentity rather than a service implies that the presentity is complete - all devices are reachable through that. A presence document with just one 'service' tuple implies that there might be others which got filtered along the way. I'll add it to the draft. Rosen, Brian wrote: > For this purpose, a service is a tuple representing a communications > path to a set of devices that have some common characteristics. > The tuple contains the URI to the service, and the characteristics > (capabilities) > of the service. > > The service endeavors to deliver a request for communication to an > appropriate > device from the set of devices it controls. The presence information > presented by the service is represents that of the service as a whole, > rather than that of one of its constituent devices. It is NOT > necessarily a simple pivot of device presence information. The service > may have additional information, and it may combine information in > ways not expressible as a pivot of the device data. > > A service is differentiated from a device in that the URI explicitly > represents the services, requests for communication will be forwarded > to one of the devices the service controls. > > A service is differentiated from a user in that a user may have > multiple services, each of which may have separate presence tuples. > Normally, a user has a single tuple representing the presence of > the user as a person. > > You can think of this as a hierarchy, where a user has a set of > services each of which has a set of devices. Nothing limits > the hierarchy to two levels (a service could aggregate multiple > services, although I can't think of an example that makes a lot > of sense). It's also possible to have a user who doesn't have > services. In that case he has a set of devices that are aggregated > directly to form the user tuple. The service is equal to device. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 15:02:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29437; Tue, 15 Jul 2003 15:02:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cV3v-0004bV-00; Tue, 15 Jul 2003 15:02:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cV3q-0004bS-00; Tue, 15 Jul 2003 15:02:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cV3p-0004p9-1P; Tue, 15 Jul 2003 15:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cV3U-0004kO-Nd for simple@optimus.ietf.org; Tue, 15 Jul 2003 15:01:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29432 for ; Tue, 15 Jul 2003 15:01:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cV3R-0004bO-00 for simple@ietf.org; Tue, 15 Jul 2003 15:01:37 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cV3G-0004bF-00 for simple@ietf.org; Tue, 15 Jul 2003 15:01:26 -0400 Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6FJ0ciB010262; Tue, 15 Jul 2003 15:00:39 -0400 (EDT) Message-ID: <3F144F49.8080706@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Peterson, Jon" , simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - face-to-face References: <0449D80A0E9B614A83FA9031B07E8D3B257C1D@stntexch2.va.neustar.com> <3EFDB74A.7040707@cs.columbia.edu> <3F116087.5020701@dynamicsoft.com> <3F11681E.5000908@cs.columbia.edu> <3F134EC5.6050803@dynamicsoft.com> <3F13E4C2.5030107@cs.columbia.edu> In-Reply-To: <3F13E4C2.5030107@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 15:00:25 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> >> > >> So, then why is it a capability at all? A capability is a capability, >> no matter whether its represented in a presence doc or in a URI >> parameter. > > > I agree that this can easily be elsewhere; it's probably a tuple-level > parameter. Might this be a fourth label, next to 'device', 'presentity' > and 'other'? After all, it would probably not be nice to humans to > qualify a face-to-face contact as a 'device'. > Sounds like the best suggestion so far. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 15:02:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29456 for ; Tue, 15 Jul 2003 15:02:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cV3z-0004ql-Hw for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 15:02:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FJ2BjZ018639 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 15:02:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cV3z-0004qY-DW for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 15:02:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29437; Tue, 15 Jul 2003 15:02:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cV3v-0004bV-00; Tue, 15 Jul 2003 15:02:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cV3q-0004bS-00; Tue, 15 Jul 2003 15:02:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cV3p-0004p9-1P; Tue, 15 Jul 2003 15:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cV3U-0004kO-Nd for simple@optimus.ietf.org; Tue, 15 Jul 2003 15:01:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29432 for ; Tue, 15 Jul 2003 15:01:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cV3R-0004bO-00 for simple@ietf.org; Tue, 15 Jul 2003 15:01:37 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cV3G-0004bF-00 for simple@ietf.org; Tue, 15 Jul 2003 15:01:26 -0400 Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6FJ0ciB010262; Tue, 15 Jul 2003 15:00:39 -0400 (EDT) Message-ID: <3F144F49.8080706@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Peterson, Jon" , simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - face-to-face References: <0449D80A0E9B614A83FA9031B07E8D3B257C1D@stntexch2.va.neustar.com> <3EFDB74A.7040707@cs.columbia.edu> <3F116087.5020701@dynamicsoft.com> <3F11681E.5000908@cs.columbia.edu> <3F134EC5.6050803@dynamicsoft.com> <3F13E4C2.5030107@cs.columbia.edu> In-Reply-To: <3F13E4C2.5030107@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 15:00:25 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> >> > >> So, then why is it a capability at all? A capability is a capability, >> no matter whether its represented in a presence doc or in a URI >> parameter. > > > I agree that this can easily be elsewhere; it's probably a tuple-level > parameter. Might this be a fourth label, next to 'device', 'presentity' > and 'other'? After all, it would probably not be nice to humans to > qualify a face-to-face contact as a 'device'. > Sounds like the best suggestion so far. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 15:44:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01598; Tue, 15 Jul 2003 15:44:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cVia-0004qr-00; Tue, 15 Jul 2003 15:44:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cViV-0004qo-00; Tue, 15 Jul 2003 15:44:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cViT-0006xH-0S; Tue, 15 Jul 2003 15:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVhb-0006rI-Df for simple@optimus.ietf.org; Tue, 15 Jul 2003 15:43:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01587 for ; Tue, 15 Jul 2003 15:43:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cVhZ-0004qa-00 for simple@ietf.org; Tue, 15 Jul 2003 15:43:05 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cVhO-0004qT-00 for simple@ietf.org; Tue, 15 Jul 2003 15:42:54 -0400 Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6FJgDiB010355; Tue, 15 Jul 2003 15:42:14 -0400 (EDT) Message-ID: <3F14590E.10901@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Aki Niemi , simple@ietf.org Subject: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB0@esebe013.ntc.nokia.com> <1058260190.934.23.camel@RjS.localdomain> In-Reply-To: <1058260190.934.23.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 15:42:06 -0400 Content-Transfer-Encoding: 7bit I was about to post a note on agreeing with Aki. I was also going to say that we might want the body to also be the atomic unit, so that when you publish a tuple, the body is an XML fragment for the tuple. Then, it ocurred to me that we were really far down the complexity ramp here. So, I thought about what we could do to really back out of this mess entirely. Here is my idea. In the beginning, PUBLISH was easy. Each PUA published its own view of the presence of the presentity. It had no knowledge of other PUA. It published a complete presence document which represented what it thought was the full presence of the presentity. Indeed, if there was only one PUA, it would be the full presence of the presentity. There was no way for one PUA to overwrite the published data from another. The tuple IDs didn't need to have cross-PUA scope. No naming conventions or anything. The compositor could combine these and modify them as it chose. Each represented a unique and different piece of info about the presentity. A useful bit of information was this "Pstream-ID", which uniquely identified the publisher. You can think of the Pstream-ID as a way of scoping the tuple IDs. Each tuple ID is defined only within the scope of a Pstream-ID, and each publisher has to have a unique PStream-ID. It all got complicated when we decided to try and solve a bigger problem, where PUA could override information about other PUA. That introduced all kinds of problems. We needed to define the atomic information of published presence. We need to resolve tuple naming. We need to worry about this issue about whether a publish has one or more tuples. We needed to add Etags and If-Modified-Since. We need to worry about how to figure out what it means for the system to "wait for human input" in cases where thats not possible. We don't know how to do that yet. Perhaps we should reconsider whether we want to solve this problem this way. We have only one use case - when I leave my PC at the office with a presence state that is wrong, and I want to fix it at home. Well, this is a nice feature, but is it worth all of the complexity at this point? There are other ways to deal with it. In fact, I can think of two alternatives: 1. You could use the auth policy to simply disable the PC's data from being placed in notifications, and then publish a separate tuple (i.e., new piece of independent information) from home. Thats not as good (PC still refreshes useless state), but its lots simpler than the route we are on. 2. You could design a system which only allowed one PUA at a time (akin to the current model in AIM and YIM). This would manifest itself as composition policy. The compositor would only use the published document from the PUA which started publishing most recently - that is, when its Pstream-ID first appeared. This would also achieve the effect of disabling the work PC's state when you arrive at home. So, to be concrete, I would propose the following: 1. Publications carry complete presence documents, representing the complete presence state of the PUA as far as it knows. 2. Publishers are identified by a unique PStream-ID, chosen by the publisher. Copying someone elses Pstream-ID is not allowed, and behavior in this case is not defined. 3. There is no ability to overwrite someone elses presence document or their tuples. Each publisher publishes independent information. 4. We eliminate the Etag, If-Modified-Since, and atomicity/segment discussions from Publish. 5. Compositors can combine the publsihed information however they like. There is no need to carry through tuple IDs from publication to notifications. 6. If you want to block a tuple from getting into a notify, you identify it by a distinguishing property rather than by tuple ID. I believe this approach works nicely for other things too. In the case of winfo, where you have lots of presence servers, each publishing winfo for the subscriptions they have, its the same. Each publisher (a presence server), publishes the complete view of the state - its own subscriptions. There is no overlap between servers. The compositor combines these together using a basic policy (combine subscriptions together that are for the same presentity), and thats it. I believe it works for mwi too. I really feel that it is important that we make some simplifications so that we can make rapid progress here. I don't think we lose much since we can still get the desired feature; we just get it in a different way. Thoughts? -Jonathan R. Robert Sparks wrote: > Another way to state this conclusion is that we need to report > success or failure of publishing each atomic element in an independent > fashion. One quick and easy way to achieve that property is to allow > only one atomic element per PUBLISH request. > > I think I heard another way to do this mentioned during the meeting, > where we move reporting the success/failure and any feedback from > the attempt to publish each tuple into the message instead of trying > to capture it all on the status line. For example (I think this is > what I heard suggested during the meeting), for presence, we could > publish an entire pidf document with several tuples and in the presence > response return an xml document with one element per tuple discussing > the disposition of attempting to publish that tuple. > > Something along the lines of the following (an example to convey the > concept, not a proposal of a syntax) > > > > > > > > > > If we were to pursue such an optimization, it might make sense to > look at how to specify a separate etag value in the publish (currently > what we put in an If-Match header) for each atom in the published > document. > > RjS > > On Mon, 2003-07-14 at 19:58, aki.niemi@nokia.com wrote: > >>All, >> >>I'll try to summarize the issues w.r.t. the atomicity of publication here in an attempt to converge the discussion towards a solution to this problem. BTW, I realized that my slides in the SIMPLE session were perhaps not crystal clear on what the problem at hand really was, so my apologies for that. >> >>The core problem is this: >> >>EPA X sends a PUBLISH with {a, b, c}, after which EPA Y publishes {a, b}. When EPA X tries to refresh its publication of {a, b, c}, the request fails because of a collision, resulting in the EPA X quitting. EPA Y still refreshes its publication of {a, b}, which means {c} expires and goes away. As a result, the publication process has lost information of {c}. This is unacceptable, and with the current versioning mechanism, this can't be remedied by composer policy, for example. >> >>Instead, to get around the above problem, what you send in a PUBLISH needs to match the atomic element of the published information. So each PUBLISH needs to contain a single tuple, because the versioning and expiration all work on the single atomic element level anyway. >> >>This has the apparent drawback in that the PUA has to wait for a 200 OK after each PUBLISHed tuple before it can PUBLISH the next one. This occurs upon every refresh cycle, and in systems with high latency, may become a major issue in terms of performance. >> >>Ways to get around this inefficiency: >> - Remove the restriction on overlapping requests, i.e., allow "pipelining" >> of PUBLISH requests >> - Treat the publisher of each tuple as a separate EPA, and therefore not >> subject to this restriction in the first place (seems like cheating...) >> >>In conclusion, my proposal is to go with having always a single tuple in a PUBLISH, and allow overlapping PUBLISH requests. To my knowledge, this would fulfill all the related requirements and solve the issue. >> >>Thoughts? >> >>Cheers, >>Aki >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 15:44:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01625 for ; Tue, 15 Jul 2003 15:44:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVif-0006yo-0W for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 15:44:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FJiCWn026826 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 15:44:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVie-0006yb-RT for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 15:44:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01598; Tue, 15 Jul 2003 15:44:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cVia-0004qr-00; Tue, 15 Jul 2003 15:44:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cViV-0004qo-00; Tue, 15 Jul 2003 15:44:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cViT-0006xH-0S; Tue, 15 Jul 2003 15:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVhb-0006rI-Df for simple@optimus.ietf.org; Tue, 15 Jul 2003 15:43:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01587 for ; Tue, 15 Jul 2003 15:43:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cVhZ-0004qa-00 for simple@ietf.org; Tue, 15 Jul 2003 15:43:05 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cVhO-0004qT-00 for simple@ietf.org; Tue, 15 Jul 2003 15:42:54 -0400 Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6FJgDiB010355; Tue, 15 Jul 2003 15:42:14 -0400 (EDT) Message-ID: <3F14590E.10901@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Aki Niemi , simple@ietf.org Subject: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB0@esebe013.ntc.nokia.com> <1058260190.934.23.camel@RjS.localdomain> In-Reply-To: <1058260190.934.23.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 15:42:06 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I was about to post a note on agreeing with Aki. I was also going to say that we might want the body to also be the atomic unit, so that when you publish a tuple, the body is an XML fragment for the tuple. Then, it ocurred to me that we were really far down the complexity ramp here. So, I thought about what we could do to really back out of this mess entirely. Here is my idea. In the beginning, PUBLISH was easy. Each PUA published its own view of the presence of the presentity. It had no knowledge of other PUA. It published a complete presence document which represented what it thought was the full presence of the presentity. Indeed, if there was only one PUA, it would be the full presence of the presentity. There was no way for one PUA to overwrite the published data from another. The tuple IDs didn't need to have cross-PUA scope. No naming conventions or anything. The compositor could combine these and modify them as it chose. Each represented a unique and different piece of info about the presentity. A useful bit of information was this "Pstream-ID", which uniquely identified the publisher. You can think of the Pstream-ID as a way of scoping the tuple IDs. Each tuple ID is defined only within the scope of a Pstream-ID, and each publisher has to have a unique PStream-ID. It all got complicated when we decided to try and solve a bigger problem, where PUA could override information about other PUA. That introduced all kinds of problems. We needed to define the atomic information of published presence. We need to resolve tuple naming. We need to worry about this issue about whether a publish has one or more tuples. We needed to add Etags and If-Modified-Since. We need to worry about how to figure out what it means for the system to "wait for human input" in cases where thats not possible. We don't know how to do that yet. Perhaps we should reconsider whether we want to solve this problem this way. We have only one use case - when I leave my PC at the office with a presence state that is wrong, and I want to fix it at home. Well, this is a nice feature, but is it worth all of the complexity at this point? There are other ways to deal with it. In fact, I can think of two alternatives: 1. You could use the auth policy to simply disable the PC's data from being placed in notifications, and then publish a separate tuple (i.e., new piece of independent information) from home. Thats not as good (PC still refreshes useless state), but its lots simpler than the route we are on. 2. You could design a system which only allowed one PUA at a time (akin to the current model in AIM and YIM). This would manifest itself as composition policy. The compositor would only use the published document from the PUA which started publishing most recently - that is, when its Pstream-ID first appeared. This would also achieve the effect of disabling the work PC's state when you arrive at home. So, to be concrete, I would propose the following: 1. Publications carry complete presence documents, representing the complete presence state of the PUA as far as it knows. 2. Publishers are identified by a unique PStream-ID, chosen by the publisher. Copying someone elses Pstream-ID is not allowed, and behavior in this case is not defined. 3. There is no ability to overwrite someone elses presence document or their tuples. Each publisher publishes independent information. 4. We eliminate the Etag, If-Modified-Since, and atomicity/segment discussions from Publish. 5. Compositors can combine the publsihed information however they like. There is no need to carry through tuple IDs from publication to notifications. 6. If you want to block a tuple from getting into a notify, you identify it by a distinguishing property rather than by tuple ID. I believe this approach works nicely for other things too. In the case of winfo, where you have lots of presence servers, each publishing winfo for the subscriptions they have, its the same. Each publisher (a presence server), publishes the complete view of the state - its own subscriptions. There is no overlap between servers. The compositor combines these together using a basic policy (combine subscriptions together that are for the same presentity), and thats it. I believe it works for mwi too. I really feel that it is important that we make some simplifications so that we can make rapid progress here. I don't think we lose much since we can still get the desired feature; we just get it in a different way. Thoughts? -Jonathan R. Robert Sparks wrote: > Another way to state this conclusion is that we need to report > success or failure of publishing each atomic element in an independent > fashion. One quick and easy way to achieve that property is to allow > only one atomic element per PUBLISH request. > > I think I heard another way to do this mentioned during the meeting, > where we move reporting the success/failure and any feedback from > the attempt to publish each tuple into the message instead of trying > to capture it all on the status line. For example (I think this is > what I heard suggested during the meeting), for presence, we could > publish an entire pidf document with several tuples and in the presence > response return an xml document with one element per tuple discussing > the disposition of attempting to publish that tuple. > > Something along the lines of the following (an example to convey the > concept, not a proposal of a syntax) > > > > > > > > > > If we were to pursue such an optimization, it might make sense to > look at how to specify a separate etag value in the publish (currently > what we put in an If-Match header) for each atom in the published > document. > > RjS > > On Mon, 2003-07-14 at 19:58, aki.niemi@nokia.com wrote: > >>All, >> >>I'll try to summarize the issues w.r.t. the atomicity of publication here in an attempt to converge the discussion towards a solution to this problem. BTW, I realized that my slides in the SIMPLE session were perhaps not crystal clear on what the problem at hand really was, so my apologies for that. >> >>The core problem is this: >> >>EPA X sends a PUBLISH with {a, b, c}, after which EPA Y publishes {a, b}. When EPA X tries to refresh its publication of {a, b, c}, the request fails because of a collision, resulting in the EPA X quitting. EPA Y still refreshes its publication of {a, b}, which means {c} expires and goes away. As a result, the publication process has lost information of {c}. This is unacceptable, and with the current versioning mechanism, this can't be remedied by composer policy, for example. >> >>Instead, to get around the above problem, what you send in a PUBLISH needs to match the atomic element of the published information. So each PUBLISH needs to contain a single tuple, because the versioning and expiration all work on the single atomic element level anyway. >> >>This has the apparent drawback in that the PUA has to wait for a 200 OK after each PUBLISHed tuple before it can PUBLISH the next one. This occurs upon every refresh cycle, and in systems with high latency, may become a major issue in terms of performance. >> >>Ways to get around this inefficiency: >> - Remove the restriction on overlapping requests, i.e., allow "pipelining" >> of PUBLISH requests >> - Treat the publisher of each tuple as a separate EPA, and therefore not >> subject to this restriction in the first place (seems like cheating...) >> >>In conclusion, my proposal is to go with having always a single tuple in a PUBLISH, and allow overlapping PUBLISH requests. To my knowledge, this would fulfill all the related requirements and solve the issue. >> >>Thoughts? >> >>Cheers, >>Aki >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 15:55:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02024; Tue, 15 Jul 2003 15:55:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVt7-0007IH-Kx; Tue, 15 Jul 2003 15:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVsF-0007HP-UV for simple@optimus.ietf.org; Tue, 15 Jul 2003 15:54:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01971 for ; Tue, 15 Jul 2003 15:54:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cVsE-0004wt-00 for simple@ietf.org; Tue, 15 Jul 2003 15:54:06 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cVry-0004w2-00 for simple@ietf.org; Tue, 15 Jul 2003 15:53:50 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6FJqikM022058; Tue, 15 Jul 2003 15:52:44 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6FJqeg06581; Tue, 15 Jul 2003 15:52:40 -0400 Message-ID: <3F145A91.8000006@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> <3F13080F.4060706@cs.columbia.edu> <3F1330E3.8070407@lucent.com> <3F134E7E.7020409@dynamicsoft.com> In-Reply-To: <3F134E7E.7020409@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 15:48:33 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: >>> I think this mostly works, particularly if this is encoded as a >>> password, as in sam:848zcc85@example.com. > > > I like this approach alot. I had the same thought upon reading Henning's > note, but Vijay beat me to posting the idea. > I don't quite follow Henning's concern. I don't see why the secretary's > user agent per se cares. Presumably all of this is handled in the > presence server. What it DOES require is that the presence server have a Note that I'm not assuming that the boss and secretary presence server have anything to do with each other - they can be in different domains. I don't see how a GRUU helps here. The secretary isn't creating it; the URI can't be public (as otherwise the third party could just hand it out to everyone else.) In the 'password' model that Vijay implicitly proposed, the boss can create a specific URI, such as E_k(customer,expiration,salt), which is then handed to the customer who wants to subscribe to the boss (and the boss' secretary) as a contact. Without further consultation, the secretary can verify that the boss has "signed" the subscription until the expiration time. This requires the secretary's presence server to be able to decode the password and verify it. Can you explain the chain of events as you see them in a bit more detail? > way to derive a composed document that properly includes this > ticket/gruu, and has established authorization policies that are > appropriate. I suspect that those policies would be adminstratively > determined, so that the secretary in general would not need to do > anything for this to work. > > BTW, this is a really good example of a complex presence transformation > that is far beyond anything you can do with a SELECT kind of database > operation. This is a simple compose operation; the select operation only addresses merging and filtering, not composition. > As I mention above, I suspect that there would be some basic policy that > applies here. In fact, the "import" appraoch you have proposed, Henning, > is identical to using a GRUU whose policy is: "the boss's authorization > policy gets applied" to subscriptions to the gruu. In the cases of distinct presence servers, I don't see how the boss' presence policy can apply. > > The benefit of the gruu approach is that you CAN have other policies if > someone desires. Doing so seems much easier than in the import case. > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 15:56:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02062 for ; Tue, 15 Jul 2003 15:56:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVtg-0007Mm-4x for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 15:55:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FJtafG028310 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 15:55:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVte-0007MX-Kp for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 15:55:34 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02024; Tue, 15 Jul 2003 15:55:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVt7-0007IH-Kx; Tue, 15 Jul 2003 15:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVsF-0007HP-UV for simple@optimus.ietf.org; Tue, 15 Jul 2003 15:54:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01971 for ; Tue, 15 Jul 2003 15:54:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cVsE-0004wt-00 for simple@ietf.org; Tue, 15 Jul 2003 15:54:06 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cVry-0004w2-00 for simple@ietf.org; Tue, 15 Jul 2003 15:53:50 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6FJqikM022058; Tue, 15 Jul 2003 15:52:44 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6FJqeg06581; Tue, 15 Jul 2003 15:52:40 -0400 Message-ID: <3F145A91.8000006@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> <3F13080F.4060706@cs.columbia.edu> <3F1330E3.8070407@lucent.com> <3F134E7E.7020409@dynamicsoft.com> In-Reply-To: <3F134E7E.7020409@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 15:48:33 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: >>> I think this mostly works, particularly if this is encoded as a >>> password, as in sam:848zcc85@example.com. > > > I like this approach alot. I had the same thought upon reading Henning's > note, but Vijay beat me to posting the idea. > I don't quite follow Henning's concern. I don't see why the secretary's > user agent per se cares. Presumably all of this is handled in the > presence server. What it DOES require is that the presence server have a Note that I'm not assuming that the boss and secretary presence server have anything to do with each other - they can be in different domains. I don't see how a GRUU helps here. The secretary isn't creating it; the URI can't be public (as otherwise the third party could just hand it out to everyone else.) In the 'password' model that Vijay implicitly proposed, the boss can create a specific URI, such as E_k(customer,expiration,salt), which is then handed to the customer who wants to subscribe to the boss (and the boss' secretary) as a contact. Without further consultation, the secretary can verify that the boss has "signed" the subscription until the expiration time. This requires the secretary's presence server to be able to decode the password and verify it. Can you explain the chain of events as you see them in a bit more detail? > way to derive a composed document that properly includes this > ticket/gruu, and has established authorization policies that are > appropriate. I suspect that those policies would be adminstratively > determined, so that the secretary in general would not need to do > anything for this to work. > > BTW, this is a really good example of a complex presence transformation > that is far beyond anything you can do with a SELECT kind of database > operation. This is a simple compose operation; the select operation only addresses merging and filtering, not composition. > As I mention above, I suspect that there would be some basic policy that > applies here. In fact, the "import" appraoch you have proposed, Henning, > is identical to using a GRUU whose policy is: "the boss's authorization > policy gets applied" to subscriptions to the gruu. In the cases of distinct presence servers, I don't see how the boss' presence policy can apply. > > The benefit of the gruu approach is that you CAN have other policies if > someone desires. Doing so seems much easier than in the import case. > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 16:00:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02293; Tue, 15 Jul 2003 16:00:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVxx-0007iD-Uf; Tue, 15 Jul 2003 16:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVxq-0007hf-Hw for simple@optimus.ietf.org; Tue, 15 Jul 2003 15:59:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02238 for ; Tue, 15 Jul 2003 15:59:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cVxo-000521-00 for simple@ietf.org; Tue, 15 Jul 2003 15:59:52 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cVxZ-00051q-00 for simple@ietf.org; Tue, 15 Jul 2003 15:59:37 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6FJxMkM022643; Tue, 15 Jul 2003 15:59:22 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6FJxLg07459; Tue, 15 Jul 2003 15:59:21 -0400 Message-ID: <3F145C22.9070106@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@ietf.org Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB0@esebe013.ntc.nokia.com> <1058260190.934.23.camel@RjS.localdomain> <3F14590E.10901@dynamicsoft.com> In-Reply-To: <3F14590E.10901@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 15:55:14 -0400 Content-Transfer-Encoding: 7bit This does seem much simpler. I wonder if combining this with an explicit remove operation - "drop this Pstream/tuple-id tuple" - would avoid the rather round-about way of cleaning up dead state noted below, without having to worry about atomicity, last-modified-issues and unique naming. Jonathan Rosenberg wrote: > I was about to post a note on agreeing with Aki. I was also going to > say that we might want the body to also be the atomic unit, so that when > you publish a tuple, the body is an XML fragment for the tuple. Then, it > ocurred to me that we were really far down the complexity ramp here. So, > I thought about what we could do to really back out of this mess > entirely. Here is my idea. > > In the beginning, PUBLISH was easy. Each PUA published its own view of > the presence of the presentity. It had no knowledge of other PUA. It > published a complete presence document which represented what it thought > was the full presence of the presentity. Indeed, if there was only one > PUA, it would be the full presence of the presentity. There was no way > for one PUA to overwrite the published data from another. The tuple IDs > didn't need to have cross-PUA scope. No naming conventions or anything. > The compositor could combine these and modify them as it chose. Each > represented a unique and different piece of info about the presentity. A > useful bit of information was this "Pstream-ID", which uniquely > identified the publisher. You can think of the Pstream-ID as a way of > scoping the tuple IDs. Each tuple ID is defined only within the scope of > a Pstream-ID, and each publisher has to have a unique PStream-ID. > > It all got complicated when we decided to try and solve a bigger > problem, where PUA could override information about other PUA. That > introduced all kinds of problems. We needed to define the atomic > information of published presence. We need to resolve tuple naming. We > need to worry about this issue about whether a publish has one or more > tuples. We needed to add Etags and If-Modified-Since. We need to worry > about how to figure out what it means for the system to "wait for human > input" in cases where thats not possible. We don't know how to do that yet. > > Perhaps we should reconsider whether we want to solve this problem this > way. We have only one use case - when I leave my PC at the office with a > presence state that is wrong, and I want to fix it at home. Well, this > is a nice feature, but is it worth all of the complexity at this point? > There are other ways to deal with it. In fact, I can think of two > alternatives: > > 1. You could use the auth policy to simply disable the PC's data from > being placed in notifications, and then publish a separate tuple (i.e., > new piece of independent information) from home. Thats not as good (PC > still refreshes useless state), but its lots simpler than the route we > are on. > > 2. You could design a system which only allowed one PUA at a time (akin > to the current model in AIM and YIM). This would manifest itself as > composition policy. The compositor would only use the published document > from the PUA which started publishing most recently - that is, when its > Pstream-ID first appeared. This would also achieve the effect of > disabling the work PC's state when you arrive at home. > > > So, to be concrete, I would propose the following: > > > 1. Publications carry complete presence documents, representing the > complete presence state of the PUA as far as it knows. > > 2. Publishers are identified by a unique PStream-ID, chosen by the > publisher. Copying someone elses Pstream-ID is not allowed, and behavior > in this case is not defined. > > 3. There is no ability to overwrite someone elses presence document or > their tuples. Each publisher publishes independent information. > > 4. We eliminate the Etag, If-Modified-Since, and atomicity/segment > discussions from Publish. > > 5. Compositors can combine the publsihed information however they like. > There is no need to carry through tuple IDs from publication to > notifications. > > 6. If you want to block a tuple from getting into a notify, you identify > it by a distinguishing property rather than by tuple ID. > > > I believe this approach works nicely for other things too. In the case > of winfo, where you have lots of presence servers, each publishing winfo > for the subscriptions they have, its the same. Each publisher (a > presence server), publishes the complete view of the state - its own > subscriptions. There is no overlap between servers. The compositor > combines these together using a basic policy (combine subscriptions > together that are for the same presentity), and thats it. > > I believe it works for mwi too. > > I really feel that it is important that we make some simplifications so > that we can make rapid progress here. I don't think we lose much since > we can still get the desired feature; we just get it in a different way. > > Thoughts? > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 16:01:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02335 for ; Tue, 15 Jul 2003 16:01:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVyX-0007lv-ET for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 16:00:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FK0btP029869 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 16:00:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVyV-0007lg-Ff for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 16:00:35 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02293; Tue, 15 Jul 2003 16:00:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVxx-0007iD-Uf; Tue, 15 Jul 2003 16:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVxq-0007hf-Hw for simple@optimus.ietf.org; Tue, 15 Jul 2003 15:59:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02238 for ; Tue, 15 Jul 2003 15:59:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cVxo-000521-00 for simple@ietf.org; Tue, 15 Jul 2003 15:59:52 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19cVxZ-00051q-00 for simple@ietf.org; Tue, 15 Jul 2003 15:59:37 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6FJxMkM022643; Tue, 15 Jul 2003 15:59:22 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6FJxLg07459; Tue, 15 Jul 2003 15:59:21 -0400 Message-ID: <3F145C22.9070106@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@ietf.org Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB0@esebe013.ntc.nokia.com> <1058260190.934.23.camel@RjS.localdomain> <3F14590E.10901@dynamicsoft.com> In-Reply-To: <3F14590E.10901@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 15:55:14 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This does seem much simpler. I wonder if combining this with an explicit remove operation - "drop this Pstream/tuple-id tuple" - would avoid the rather round-about way of cleaning up dead state noted below, without having to worry about atomicity, last-modified-issues and unique naming. Jonathan Rosenberg wrote: > I was about to post a note on agreeing with Aki. I was also going to > say that we might want the body to also be the atomic unit, so that when > you publish a tuple, the body is an XML fragment for the tuple. Then, it > ocurred to me that we were really far down the complexity ramp here. So, > I thought about what we could do to really back out of this mess > entirely. Here is my idea. > > In the beginning, PUBLISH was easy. Each PUA published its own view of > the presence of the presentity. It had no knowledge of other PUA. It > published a complete presence document which represented what it thought > was the full presence of the presentity. Indeed, if there was only one > PUA, it would be the full presence of the presentity. There was no way > for one PUA to overwrite the published data from another. The tuple IDs > didn't need to have cross-PUA scope. No naming conventions or anything. > The compositor could combine these and modify them as it chose. Each > represented a unique and different piece of info about the presentity. A > useful bit of information was this "Pstream-ID", which uniquely > identified the publisher. You can think of the Pstream-ID as a way of > scoping the tuple IDs. Each tuple ID is defined only within the scope of > a Pstream-ID, and each publisher has to have a unique PStream-ID. > > It all got complicated when we decided to try and solve a bigger > problem, where PUA could override information about other PUA. That > introduced all kinds of problems. We needed to define the atomic > information of published presence. We need to resolve tuple naming. We > need to worry about this issue about whether a publish has one or more > tuples. We needed to add Etags and If-Modified-Since. We need to worry > about how to figure out what it means for the system to "wait for human > input" in cases where thats not possible. We don't know how to do that yet. > > Perhaps we should reconsider whether we want to solve this problem this > way. We have only one use case - when I leave my PC at the office with a > presence state that is wrong, and I want to fix it at home. Well, this > is a nice feature, but is it worth all of the complexity at this point? > There are other ways to deal with it. In fact, I can think of two > alternatives: > > 1. You could use the auth policy to simply disable the PC's data from > being placed in notifications, and then publish a separate tuple (i.e., > new piece of independent information) from home. Thats not as good (PC > still refreshes useless state), but its lots simpler than the route we > are on. > > 2. You could design a system which only allowed one PUA at a time (akin > to the current model in AIM and YIM). This would manifest itself as > composition policy. The compositor would only use the published document > from the PUA which started publishing most recently - that is, when its > Pstream-ID first appeared. This would also achieve the effect of > disabling the work PC's state when you arrive at home. > > > So, to be concrete, I would propose the following: > > > 1. Publications carry complete presence documents, representing the > complete presence state of the PUA as far as it knows. > > 2. Publishers are identified by a unique PStream-ID, chosen by the > publisher. Copying someone elses Pstream-ID is not allowed, and behavior > in this case is not defined. > > 3. There is no ability to overwrite someone elses presence document or > their tuples. Each publisher publishes independent information. > > 4. We eliminate the Etag, If-Modified-Since, and atomicity/segment > discussions from Publish. > > 5. Compositors can combine the publsihed information however they like. > There is no need to carry through tuple IDs from publication to > notifications. > > 6. If you want to block a tuple from getting into a notify, you identify > it by a distinguishing property rather than by tuple ID. > > > I believe this approach works nicely for other things too. In the case > of winfo, where you have lots of presence servers, each publishing winfo > for the subscriptions they have, its the same. Each publisher (a > presence server), publishes the complete view of the state - its own > subscriptions. There is no overlap between servers. The compositor > combines these together using a basic policy (combine subscriptions > together that are for the same presentity), and thats it. > > I believe it works for mwi too. > > I really feel that it is important that we make some simplifications so > that we can make rapid progress here. I don't think we lose much since > we can still get the desired feature; we just get it in a different way. > > Thoughts? > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 16:09:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02718; Tue, 15 Jul 2003 16:09:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cW6k-00056h-00; Tue, 15 Jul 2003 16:09:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cW6f-00056e-00; Tue, 15 Jul 2003 16:09:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cW6e-0008Vc-JO; Tue, 15 Jul 2003 16:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cW5r-0008VM-Ue for simple@optimus.ietf.org; Tue, 15 Jul 2003 16:08:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02599 for ; Tue, 15 Jul 2003 16:08:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cW5n-00056J-00 for simple@ietf.org; Tue, 15 Jul 2003 16:08:07 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cW5c-00055r-00 for simple@ietf.org; Tue, 15 Jul 2003 16:07:56 -0400 Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6FK6tiB010387; Tue, 15 Jul 2003 16:06:57 -0400 (EDT) Message-ID: <3F145ED8.6070005@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orly Rosenberg CC: "'simple@ietf.org'" Subject: Re: [Simple] A few questions about Winfo References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 16:06:48 -0400 Content-Transfer-Encoding: 7bit inline. Orly Rosenberg wrote: > Hi. > I have a few questions about the winfo-package draft: > > 1) The draft defines a default policy for sending watcherinfo > notifications in case > the body of the Subscribe request does not define a filter for > notifications. > The default behavior, as I understand it, is: > a. Send a full winfo document when sending a winfo notification as a > result of an incoming > winfo Subscribe request (initial winfo Subscribe request or refresh > requests). > b. Send a partial winfo document when a watcher changes its state, > about this watcher only. > It is also recommended by the draft, that "the watcherinfo > notifications sent to B only contain > the state of B's own subscriptions". > My question is - should the default behavior be sending a full winfo > document as a result of an > incoming Subscribe, only when B subscribes to its own watcher > information? The result of an incoming subscribe. > > 2) According to the 3265 RFC, when a pending subscription is expired, a > Notify(terminated) should > be sent by the Notifier to the Subscriber. According to the > winfo-package, when a Pending > subscription is expired, it should change its state to Waiting. When > this happens, should the > Notifier still send a Notify(terminated) message to the Subscriber? Yes. Waiting is really an internal state. > If not, when should this message > be sent? If yes, then how is it possible to change the state back to > Pending when receiving a refresh > request, after a Notify(terminated) message was already sent? There is no refresh. The subscription has terminated. A new SUBSCRIBE request would create a new subscription. > > 3) When handling a fetch Subscribe request, should the Notifier send a > Notify(terminated) after sending the > Notify(active) message with the winfo document? Thats a good question. Generally speaking, sending notifications for transient states is not such a great idea. In the case of a fetch, you should probably only get one notify, with the state of terminated. The subscription duration of 0 will tell the winfo subscriber that this was a fetch. Thats not clear in the doc. I will see if such a clarification is possible during authors 48. What happens if > there is no policy defined for > the fetch request and the state changes to Waiting? A winfo is sent indicating that the state is waiting. > Should the > Notifier send any Notify messages? The subscription from the watcher is terminated, so there would be no notify messages. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 16:09:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02783 for ; Tue, 15 Jul 2003 16:09:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cW6n-00007O-2D for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 16:09:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FK99P2000448 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 16:09:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cW6m-000079-VT for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 16:09:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02718; Tue, 15 Jul 2003 16:09:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cW6k-00056h-00; Tue, 15 Jul 2003 16:09:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cW6f-00056e-00; Tue, 15 Jul 2003 16:09:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cW6e-0008Vc-JO; Tue, 15 Jul 2003 16:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cW5r-0008VM-Ue for simple@optimus.ietf.org; Tue, 15 Jul 2003 16:08:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02599 for ; Tue, 15 Jul 2003 16:08:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cW5n-00056J-00 for simple@ietf.org; Tue, 15 Jul 2003 16:08:07 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cW5c-00055r-00 for simple@ietf.org; Tue, 15 Jul 2003 16:07:56 -0400 Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6FK6tiB010387; Tue, 15 Jul 2003 16:06:57 -0400 (EDT) Message-ID: <3F145ED8.6070005@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orly Rosenberg CC: "'simple@ietf.org'" Subject: Re: [Simple] A few questions about Winfo References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 16:06:48 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Orly Rosenberg wrote: > Hi. > I have a few questions about the winfo-package draft: > > 1) The draft defines a default policy for sending watcherinfo > notifications in case > the body of the Subscribe request does not define a filter for > notifications. > The default behavior, as I understand it, is: > a. Send a full winfo document when sending a winfo notification as a > result of an incoming > winfo Subscribe request (initial winfo Subscribe request or refresh > requests). > b. Send a partial winfo document when a watcher changes its state, > about this watcher only. > It is also recommended by the draft, that "the watcherinfo > notifications sent to B only contain > the state of B's own subscriptions". > My question is - should the default behavior be sending a full winfo > document as a result of an > incoming Subscribe, only when B subscribes to its own watcher > information? The result of an incoming subscribe. > > 2) According to the 3265 RFC, when a pending subscription is expired, a > Notify(terminated) should > be sent by the Notifier to the Subscriber. According to the > winfo-package, when a Pending > subscription is expired, it should change its state to Waiting. When > this happens, should the > Notifier still send a Notify(terminated) message to the Subscriber? Yes. Waiting is really an internal state. > If not, when should this message > be sent? If yes, then how is it possible to change the state back to > Pending when receiving a refresh > request, after a Notify(terminated) message was already sent? There is no refresh. The subscription has terminated. A new SUBSCRIBE request would create a new subscription. > > 3) When handling a fetch Subscribe request, should the Notifier send a > Notify(terminated) after sending the > Notify(active) message with the winfo document? Thats a good question. Generally speaking, sending notifications for transient states is not such a great idea. In the case of a fetch, you should probably only get one notify, with the state of terminated. The subscription duration of 0 will tell the winfo subscriber that this was a fetch. Thats not clear in the doc. I will see if such a clarification is possible during authors 48. What happens if > there is no policy defined for > the fetch request and the state changes to Waiting? A winfo is sent indicating that the state is waiting. > Should the > Notifier send any Notify messages? The subscription from the watcher is terminated, so there would be no notify messages. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 16:26:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03507; Tue, 15 Jul 2003 16:26:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cWNE-0005HY-00; Tue, 15 Jul 2003 16:26:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cWN8-0005HV-00; Tue, 15 Jul 2003 16:26:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWN7-0000QD-Ux; Tue, 15 Jul 2003 16:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWMu-0000Pt-Iq for simple@optimus.ietf.org; Tue, 15 Jul 2003 16:25:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03498 for ; Tue, 15 Jul 2003 16:25:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cWMs-0005HL-00 for simple@ietf.org; Tue, 15 Jul 2003 16:25:46 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19cWMi-0005Gr-00 for simple@ietf.org; Tue, 15 Jul 2003 16:25:36 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6FKOUpp026424; Tue, 15 Jul 2003 13:24:30 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp203.cisco.com [10.61.64.203]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR52923; Tue, 15 Jul 2003 16:24:26 -0400 (EDT) Message-ID: <3F1462FA.10000@cisco.com> 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: "Rosen, Brian" CC: "'Chris Boulton'" , Henning Schulzrinne , hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Tuple design team discussion summary References: <313680C9A886D511A06000204840E1CF070B5BF7@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 16:24:26 -0400 Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > I think it will be unusual to have both device and service tuples in > a single presence document, but it could happen. > > Rather, I see a service provider aggregating a number of separate > device presence documents to produce a single service tuple. > I also then could see another aggregator (a presence aggregator) > aggregating a number of service tuple into a single > user tuple. How do you see that happening? AFAIK, we are talking about a scenario where tuples are PUBLISHed to and AOR, received by an aggregator working on behalf of that AOR, which produces aggregated presence documents which are delivered to subscribers to that same AOR. How do you fit another component (a service provider) into this picture? I think you must introduce another AOR for the service, that has its own presence. If you do that, you are introducing something closer to Henning's group presentity. I would still assert that you can treat the AOR that corresponds to the service as a device while doing no harm to the ultimate watcher. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 16:26:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03556 for ; Tue, 15 Jul 2003 16:26:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWNJ-0000Tb-0j for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 16:26:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FKQCFM001828 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 16:26:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWNI-0000TP-GS for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 16:26:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03507; Tue, 15 Jul 2003 16:26:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cWNE-0005HY-00; Tue, 15 Jul 2003 16:26:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cWN8-0005HV-00; Tue, 15 Jul 2003 16:26:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWN7-0000QD-Ux; Tue, 15 Jul 2003 16:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWMu-0000Pt-Iq for simple@optimus.ietf.org; Tue, 15 Jul 2003 16:25:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03498 for ; Tue, 15 Jul 2003 16:25:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cWMs-0005HL-00 for simple@ietf.org; Tue, 15 Jul 2003 16:25:46 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19cWMi-0005Gr-00 for simple@ietf.org; Tue, 15 Jul 2003 16:25:36 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6FKOUpp026424; Tue, 15 Jul 2003 13:24:30 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp203.cisco.com [10.61.64.203]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR52923; Tue, 15 Jul 2003 16:24:26 -0400 (EDT) Message-ID: <3F1462FA.10000@cisco.com> 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: "Rosen, Brian" CC: "'Chris Boulton'" , Henning Schulzrinne , hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Tuple design team discussion summary References: <313680C9A886D511A06000204840E1CF070B5BF7@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 16:24:26 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > I think it will be unusual to have both device and service tuples in > a single presence document, but it could happen. > > Rather, I see a service provider aggregating a number of separate > device presence documents to produce a single service tuple. > I also then could see another aggregator (a presence aggregator) > aggregating a number of service tuple into a single > user tuple. How do you see that happening? AFAIK, we are talking about a scenario where tuples are PUBLISHed to and AOR, received by an aggregator working on behalf of that AOR, which produces aggregated presence documents which are delivered to subscribers to that same AOR. How do you fit another component (a service provider) into this picture? I think you must introduce another AOR for the service, that has its own presence. If you do that, you are introducing something closer to Henning's group presentity. I would still assert that you can treat the AOR that corresponds to the service as a device while doing no harm to the ultimate watcher. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 16:34:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03870; Tue, 15 Jul 2003 16:34:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cWUx-0005Nr-00; Tue, 15 Jul 2003 16:34:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cWUr-0005No-00; Tue, 15 Jul 2003 16:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWUq-0000yz-V6; Tue, 15 Jul 2003 16:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWUK-0000yY-9Y for simple@optimus.ietf.org; Tue, 15 Jul 2003 16:33:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03851 for ; Tue, 15 Jul 2003 16:33:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cWUI-0005NO-00 for simple@ietf.org; Tue, 15 Jul 2003 16:33:26 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19cWU7-0005NA-00 for simple@ietf.org; Tue, 15 Jul 2003 16:33:15 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6FKWPpp003031; Tue, 15 Jul 2003 13:32:26 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp203.cisco.com [10.61.64.203]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR53738; Tue, 15 Jul 2003 16:32:24 -0400 (EDT) Message-ID: <3F1464D7.9040805@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: hgs@cs.columbia.edu, Brian.Rosen@marconi.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Tuple design team discussion summary References: <2038BCC78B1AD641891A0D1AE133DBB701796F0E@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 16:32:23 -0400 Content-Transfer-Encoding: 7bit This is very different from the definition Brian is homing in on. We can't have both definitions using the same name. If we need both definitions then we need separate names for them. I'm still not convinced we need either defintion. paul hisham.khartabil@nokia.com wrote: > I think I mentioned something like this before: Service to me means something that an operator can offer (as part of a package) and charge for. IM, presence and geoloc are some examples. > > This is probably not the definition you are looking for since its not technical, but probably its good enough to warrant the inclusion of the term 'service' in the list of what a tuple represents. I don't think having the term 'other' is a good idea since it might confuse implementers in the sense that they would not know what goes into such a tuple. > > Brian started some discussion about service definition, perhaps we need to discuss further a technical definition of what a service is. I believe this is better than just saying that we have a 'other' tuple that represents things that are not devices or are not users. > > Regards, > Hisham > > >>-----Original Message----- >>From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>Sent: Tuesday, July 15, 2003 2:05 PM >>To: Khartabil Hisham (NMP/Helsinki) >>Cc: Brian.Rosen@marconi.com; bcampbell@dynamicsoft.com; >>simple@ietf.org >>Subject: Re: [Simple] Tuple design team discussion summary >> >> >>hisham.khartabil@nokia.com wrote: >> >> >>>I agree with Brian. I think we only ever discussed those 3: device, >>>service and user. We don't need to be very explicit, information in >>>the tuple give away the finer details about that thing that >> >>the tuple >> >>>represents. >>> >>>Other than those 3, I haven't heard of other things that a tuple can >>>represent, unless we allow a combination of the 3 above (which I >>>believe we don't). >> >>To beat a horse carcass: While device and 'user' has reasonable >>definitions, nobody, after a year+, has provided an operational >>definition of service. Since this label needs to be understandable by >>people who have not participated in the Tuple Theory 745 >>class (this is >>graduate-level stuff...), I don't think an elaborate definition helps. >> >>'device', 'user' and 'other' seem to work ok, which seems to be close >>enough. (Earlier versions of RPIDS had an approximation to such an >>element, with the addition of 'group'.) For those, there are >>reasonable >>pictograms, too - phone, stick person and ?. >> >>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 exim@www1.ietf.org Tue Jul 15 16:34:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03913 for ; Tue, 15 Jul 2003 16:34:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWUz-00012c-S9 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 16:34:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FKY9OM003997 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 16:34:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWUz-00012O-PD for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 16:34:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03870; Tue, 15 Jul 2003 16:34:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cWUx-0005Nr-00; Tue, 15 Jul 2003 16:34:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cWUr-0005No-00; Tue, 15 Jul 2003 16:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWUq-0000yz-V6; Tue, 15 Jul 2003 16:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWUK-0000yY-9Y for simple@optimus.ietf.org; Tue, 15 Jul 2003 16:33:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03851 for ; Tue, 15 Jul 2003 16:33:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cWUI-0005NO-00 for simple@ietf.org; Tue, 15 Jul 2003 16:33:26 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19cWU7-0005NA-00 for simple@ietf.org; Tue, 15 Jul 2003 16:33:15 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6FKWPpp003031; Tue, 15 Jul 2003 13:32:26 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp203.cisco.com [10.61.64.203]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR53738; Tue, 15 Jul 2003 16:32:24 -0400 (EDT) Message-ID: <3F1464D7.9040805@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: hgs@cs.columbia.edu, Brian.Rosen@marconi.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Tuple design team discussion summary References: <2038BCC78B1AD641891A0D1AE133DBB701796F0E@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 16:32:23 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is very different from the definition Brian is homing in on. We can't have both definitions using the same name. If we need both definitions then we need separate names for them. I'm still not convinced we need either defintion. paul hisham.khartabil@nokia.com wrote: > I think I mentioned something like this before: Service to me means something that an operator can offer (as part of a package) and charge for. IM, presence and geoloc are some examples. > > This is probably not the definition you are looking for since its not technical, but probably its good enough to warrant the inclusion of the term 'service' in the list of what a tuple represents. I don't think having the term 'other' is a good idea since it might confuse implementers in the sense that they would not know what goes into such a tuple. > > Brian started some discussion about service definition, perhaps we need to discuss further a technical definition of what a service is. I believe this is better than just saying that we have a 'other' tuple that represents things that are not devices or are not users. > > Regards, > Hisham > > >>-----Original Message----- >>From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>Sent: Tuesday, July 15, 2003 2:05 PM >>To: Khartabil Hisham (NMP/Helsinki) >>Cc: Brian.Rosen@marconi.com; bcampbell@dynamicsoft.com; >>simple@ietf.org >>Subject: Re: [Simple] Tuple design team discussion summary >> >> >>hisham.khartabil@nokia.com wrote: >> >> >>>I agree with Brian. I think we only ever discussed those 3: device, >>>service and user. We don't need to be very explicit, information in >>>the tuple give away the finer details about that thing that >> >>the tuple >> >>>represents. >>> >>>Other than those 3, I haven't heard of other things that a tuple can >>>represent, unless we allow a combination of the 3 above (which I >>>believe we don't). >> >>To beat a horse carcass: While device and 'user' has reasonable >>definitions, nobody, after a year+, has provided an operational >>definition of service. Since this label needs to be understandable by >>people who have not participated in the Tuple Theory 745 >>class (this is >>graduate-level stuff...), I don't think an elaborate definition helps. >> >>'device', 'user' and 'other' seem to work ok, which seems to be close >>enough. (Earlier versions of RPIDS had an approximation to such an >>element, with the addition of 'group'.) For those, there are >>reasonable >>pictograms, too - phone, stick person and ?. >> >>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-admin@ietf.org Tue Jul 15 16:40:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04114; Tue, 15 Jul 2003 16:40:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cWal-0005Qj-00; Tue, 15 Jul 2003 16:40:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cWaf-0005Qg-00; Tue, 15 Jul 2003 16:40:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWaf-0001Sc-L0; Tue, 15 Jul 2003 16:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWZn-0001LX-UW for simple@optimus.ietf.org; Tue, 15 Jul 2003 16:39:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04071 for ; Tue, 15 Jul 2003 16:39:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cWZl-0005Q4-00 for simple@ietf.org; Tue, 15 Jul 2003 16:39:05 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cWZb-0005Pi-00 for simple@ietf.org; Tue, 15 Jul 2003 16:38:55 -0400 Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6FKbliB010425; Tue, 15 Jul 2003 16:37:47 -0400 (EDT) Message-ID: <3F146614.6060406@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: simple@ietf.org Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB0@esebe013.ntc.nokia.com> <1058260190.934.23.camel@RjS.localdomain> <3F14590E.10901@dynamicsoft.com> <3F145C22.9070106@cs.columbia.edu> In-Reply-To: <3F145C22.9070106@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 16:37:40 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > This does seem much simpler. I wonder if combining this with an explicit > remove operation - "drop this Pstream/tuple-id tuple" - would avoid the > rather round-about way of cleaning up dead state noted below, without > having to worry about atomicity, last-modified-issues and unique naming. I don't follow. Thats exactly what we were doing before. The home PC will send your "drop this pstream/tuple-id" in a publish (I assume that is what you mean), and then the work PC refreshes, and now we have the conflict all over again. One other point on my proposal. One unresolved issue which we had was, if you want to delete a tuple using Expires:0, what information in the publish identified the tuple? In the proposal I am making, its easy. The Publish has an Expires:0 and a Pstream-ID header. The published document from that pstream is deleted. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 16:40:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04148 for ; Tue, 15 Jul 2003 16:40:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWaq-0001WL-13 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 16:40:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FKeBjP005839 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 16:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWap-0001W6-QC for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 16:40:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04114; Tue, 15 Jul 2003 16:40:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cWal-0005Qj-00; Tue, 15 Jul 2003 16:40:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cWaf-0005Qg-00; Tue, 15 Jul 2003 16:40:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWaf-0001Sc-L0; Tue, 15 Jul 2003 16:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cWZn-0001LX-UW for simple@optimus.ietf.org; Tue, 15 Jul 2003 16:39:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04071 for ; Tue, 15 Jul 2003 16:39:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cWZl-0005Q4-00 for simple@ietf.org; Tue, 15 Jul 2003 16:39:05 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cWZb-0005Pi-00 for simple@ietf.org; Tue, 15 Jul 2003 16:38:55 -0400 Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6FKbliB010425; Tue, 15 Jul 2003 16:37:47 -0400 (EDT) Message-ID: <3F146614.6060406@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: simple@ietf.org Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB0@esebe013.ntc.nokia.com> <1058260190.934.23.camel@RjS.localdomain> <3F14590E.10901@dynamicsoft.com> <3F145C22.9070106@cs.columbia.edu> In-Reply-To: <3F145C22.9070106@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 16:37:40 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > This does seem much simpler. I wonder if combining this with an explicit > remove operation - "drop this Pstream/tuple-id tuple" - would avoid the > rather round-about way of cleaning up dead state noted below, without > having to worry about atomicity, last-modified-issues and unique naming. I don't follow. Thats exactly what we were doing before. The home PC will send your "drop this pstream/tuple-id" in a publish (I assume that is what you mean), and then the work PC refreshes, and now we have the conflict all over again. One other point on my proposal. One unresolved issue which we had was, if you want to delete a tuple using Expires:0, what information in the publish identified the tuple? In the proposal I am making, its easy. The Publish has an Expires:0 and a Pstream-ID header. The published document from that pstream is deleted. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 15 18:08:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07280; Tue, 15 Jul 2003 18:08:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cXxu-0006Fr-00; Tue, 15 Jul 2003 18:08:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cXxp-0006Fo-00; Tue, 15 Jul 2003 18:08:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cXxp-0005Ak-5v; Tue, 15 Jul 2003 18:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cXxf-0005AQ-2J for simple@optimus.ietf.org; Tue, 15 Jul 2003 18:07:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07235 for ; Tue, 15 Jul 2003 18:07:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cXxc-0006Fa-00 for simple@ietf.org; Tue, 15 Jul 2003 18:07:48 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19cXxR-0006Eb-00 for simple@ietf.org; Tue, 15 Jul 2003 18:07:37 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA23292; Tue, 15 Jul 2003 18:05:35 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA24534; Tue, 15 Jul 2003 18:05:36 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MT53F>; Tue, 15 Jul 2003 18:05:36 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5BFD@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" Cc: "'Chris Boulton'" , Henning Schulzrinne , hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: RE: [Simple] Tuple design team discussion summary MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 18:05:34 -0400 I think service providers will not allow publishing presence to anyone but their PA. How many mobile operators allow you to' select your own voicemail provider? I think the only way to provide comprehensive presence will be to have a 3rd party presence provider that subscribes as a watcher to all of your service provider's PAs. I hope that the SP will allow you to construct rules that allow you to say that ONLY your presence service can get your device's presence from each of your service provider's presence services. Your presence service can then publish your "real" presence as a composite of all of your service provider's presence data. I think it will be quite rare to have two devices served by the same service provider, and I don't think service providers will make it very easy for other service providers to get PUBLISH data. Among other things, the security implications are too complex (inter provider authentication). The presence service provider will create a contact for you. When a call arrives at that contact, it will be forwarded to the most appropriate device, depending on: Who is calling Caller Preferences Presentity policy You will only hand out one AOR, a SIP URI. It will work for all of your devices and your presence. Your business card has ONE address, your single AOR. It may be the case that your enterprise is the presence service provider, and it might have one of the devices under it's direct control (your desk phone). However, your mobile, your wireless PDA, your home phone and your Blackberry all are served by different SPs, that all have their own presence service, just like most of them have their own voicemail now. Robert, can this be my use case description :) Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, July 15, 2003 4:24 PM > To: Rosen, Brian > Cc: 'Chris Boulton'; Henning Schulzrinne; hisham.khartabil@nokia.com; > bcampbell@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] Tuple design team discussion summary > > > > > Rosen, Brian wrote: > > I think it will be unusual to have both device and service tuples in > > a single presence document, but it could happen. > > > > Rather, I see a service provider aggregating a number of separate > > device presence documents to produce a single service tuple. > > I also then could see another aggregator (a presence aggregator) > > aggregating a number of service tuple into a single > > user tuple. > > How do you see that happening? AFAIK, we are talking about a scenario > where tuples are PUBLISHed to and AOR, received by an > aggregator working > on behalf of that AOR, which produces aggregated presence documents > which are delivered to subscribers to that same AOR. > > How do you fit another component (a service provider) into > this picture? > I think you must introduce another AOR for the service, that > has its own > presence. > > If you do that, you are introducing something closer to > Henning's group > presentity. I would still assert that you can treat the AOR that > corresponds to the service as a device while doing no harm to the > ultimate watcher. > > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 15 18:08:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07345 for ; Tue, 15 Jul 2003 18:08:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cXxy-0005CY-9z for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 18:08:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FM8A5V019988 for simple-archive@odin.ietf.org; Tue, 15 Jul 2003 18:08:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cXxy-0005BY-5u for simple-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 18:08:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07280; Tue, 15 Jul 2003 18:08:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cXxu-0006Fr-00; Tue, 15 Jul 2003 18:08:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cXxp-0006Fo-00; Tue, 15 Jul 2003 18:08:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cXxp-0005Ak-5v; Tue, 15 Jul 2003 18:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cXxf-0005AQ-2J for simple@optimus.ietf.org; Tue, 15 Jul 2003 18:07:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07235 for ; Tue, 15 Jul 2003 18:07:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cXxc-0006Fa-00 for simple@ietf.org; Tue, 15 Jul 2003 18:07:48 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19cXxR-0006Eb-00 for simple@ietf.org; Tue, 15 Jul 2003 18:07:37 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA23292; Tue, 15 Jul 2003 18:05:35 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA24534; Tue, 15 Jul 2003 18:05:36 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MT53F>; Tue, 15 Jul 2003 18:05:36 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5BFD@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" Cc: "'Chris Boulton'" , Henning Schulzrinne , hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: RE: [Simple] Tuple design team discussion summary MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 18:05:34 -0400 I think service providers will not allow publishing presence to anyone but their PA. How many mobile operators allow you to' select your own voicemail provider? I think the only way to provide comprehensive presence will be to have a 3rd party presence provider that subscribes as a watcher to all of your service provider's PAs. I hope that the SP will allow you to construct rules that allow you to say that ONLY your presence service can get your device's presence from each of your service provider's presence services. Your presence service can then publish your "real" presence as a composite of all of your service provider's presence data. I think it will be quite rare to have two devices served by the same service provider, and I don't think service providers will make it very easy for other service providers to get PUBLISH data. Among other things, the security implications are too complex (inter provider authentication). The presence service provider will create a contact for you. When a call arrives at that contact, it will be forwarded to the most appropriate device, depending on: Who is calling Caller Preferences Presentity policy You will only hand out one AOR, a SIP URI. It will work for all of your devices and your presence. Your business card has ONE address, your single AOR. It may be the case that your enterprise is the presence service provider, and it might have one of the devices under it's direct control (your desk phone). However, your mobile, your wireless PDA, your home phone and your Blackberry all are served by different SPs, that all have their own presence service, just like most of them have their own voicemail now. Robert, can this be my use case description :) Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, July 15, 2003 4:24 PM > To: Rosen, Brian > Cc: 'Chris Boulton'; Henning Schulzrinne; hisham.khartabil@nokia.com; > bcampbell@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] Tuple design team discussion summary > > > > > Rosen, Brian wrote: > > I think it will be unusual to have both device and service tuples in > > a single presence document, but it could happen. > > > > Rather, I see a service provider aggregating a number of separate > > device presence documents to produce a single service tuple. > > I also then could see another aggregator (a presence aggregator) > > aggregating a number of service tuple into a single > > user tuple. > > How do you see that happening? AFAIK, we are talking about a scenario > where tuples are PUBLISHed to and AOR, received by an > aggregator working > on behalf of that AOR, which produces aggregated presence documents > which are delivered to subscribers to that same AOR. > > How do you fit another component (a service provider) into > this picture? > I think you must introduce another AOR for the service, that > has its own > presence. > > If you do that, you are introducing something closer to > Henning's group > presentity. I would still assert that you can treat the AOR that > corresponds to the service as a device while doing no harm to the > ultimate watcher. > > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 16 02:33:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16506; Wed, 16 Jul 2003 02:33:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cfqc-0003UC-00; Wed, 16 Jul 2003 02:33:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cfqX-0003U9-00; Wed, 16 Jul 2003 02:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cfqX-0002gv-DK; Wed, 16 Jul 2003 02:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cfpt-0002g6-LP for simple@optimus.ietf.org; Wed, 16 Jul 2003 02:32:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16460 for ; Wed, 16 Jul 2003 02:32:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cfpp-0003Td-00 for simple@ietf.org; Wed, 16 Jul 2003 02:32:17 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19cfpe-0003Ou-00 for simple@ietf.org; Wed, 16 Jul 2003 02:32:06 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6G6TluD007758; Tue, 15 Jul 2003 23:29:48 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4301.cisco.com [10.61.80.204]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR86843; Wed, 16 Jul 2003 02:29:46 -0400 (EDT) Message-ID: <3F147DC9.8040102@cisco.com> 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 CC: Robert Sparks , Aki Niemi , simple@ietf.org Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB0@esebe013.ntc.nokia.com> <1058260190.934.23.camel@RjS.localdomain> <3F14590E.10901@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 18:18:49 -0400 Content-Transfer-Encoding: 7bit I generally like this idea, but maybe it is still too complex. Why do we need the Pstream-ID? Simply say each publisher must choose unique tuple ids and leave it at that. Regarding how to set up blocking of the ones you don't want, instead of pstream, how about simply having each publisher include its identity in each tuple, as an attribute? This could be filtered out for most users. Paul Jonathan Rosenberg wrote: > I was about to post a note on agreeing with Aki. I was also going to > say that we might want the body to also be the atomic unit, so that when > you publish a tuple, the body is an XML fragment for the tuple. Then, it > ocurred to me that we were really far down the complexity ramp here. So, > I thought about what we could do to really back out of this mess > entirely. Here is my idea. > > In the beginning, PUBLISH was easy. Each PUA published its own view of > the presence of the presentity. It had no knowledge of other PUA. It > published a complete presence document which represented what it thought > was the full presence of the presentity. Indeed, if there was only one > PUA, it would be the full presence of the presentity. There was no way > for one PUA to overwrite the published data from another. The tuple IDs > didn't need to have cross-PUA scope. No naming conventions or anything. > The compositor could combine these and modify them as it chose. Each > represented a unique and different piece of info about the presentity. A > useful bit of information was this "Pstream-ID", which uniquely > identified the publisher. You can think of the Pstream-ID as a way of > scoping the tuple IDs. Each tuple ID is defined only within the scope of > a Pstream-ID, and each publisher has to have a unique PStream-ID. > > It all got complicated when we decided to try and solve a bigger > problem, where PUA could override information about other PUA. That > introduced all kinds of problems. We needed to define the atomic > information of published presence. We need to resolve tuple naming. We > need to worry about this issue about whether a publish has one or more > tuples. We needed to add Etags and If-Modified-Since. We need to worry > about how to figure out what it means for the system to "wait for human > input" in cases where thats not possible. We don't know how to do that yet. > > Perhaps we should reconsider whether we want to solve this problem this > way. We have only one use case - when I leave my PC at the office with a > presence state that is wrong, and I want to fix it at home. Well, this > is a nice feature, but is it worth all of the complexity at this point? > There are other ways to deal with it. In fact, I can think of two > alternatives: > > 1. You could use the auth policy to simply disable the PC's data from > being placed in notifications, and then publish a separate tuple (i.e., > new piece of independent information) from home. Thats not as good (PC > still refreshes useless state), but its lots simpler than the route we > are on. > > 2. You could design a system which only allowed one PUA at a time (akin > to the current model in AIM and YIM). This would manifest itself as > composition policy. The compositor would only use the published document > from the PUA which started publishing most recently - that is, when its > Pstream-ID first appeared. This would also achieve the effect of > disabling the work PC's state when you arrive at home. > > > So, to be concrete, I would propose the following: > > > 1. Publications carry complete presence documents, representing the > complete presence state of the PUA as far as it knows. > > 2. Publishers are identified by a unique PStream-ID, chosen by the > publisher. Copying someone elses Pstream-ID is not allowed, and behavior > in this case is not defined. > > 3. There is no ability to overwrite someone elses presence document or > their tuples. Each publisher publishes independent information. > > 4. We eliminate the Etag, If-Modified-Since, and atomicity/segment > discussions from Publish. > > 5. Compositors can combine the publsihed information however they like. > There is no need to carry through tuple IDs from publication to > notifications. > > 6. If you want to block a tuple from getting into a notify, you identify > it by a distinguishing property rather than by tuple ID. > > > I believe this approach works nicely for other things too. In the case > of winfo, where you have lots of presence servers, each publishing winfo > for the subscriptions they have, its the same. Each publisher (a > presence server), publishes the complete view of the state - its own > subscriptions. There is no overlap between servers. The compositor > combines these together using a basic policy (combine subscriptions > together that are for the same presentity), and thats it. > > I believe it works for mwi too. > > I really feel that it is important that we make some simplifications so > that we can make rapid progress here. I don't think we lose much since > we can still get the desired feature; we just get it in a different way. > > Thoughts? > > -Jonathan R. > > Robert Sparks wrote: > >> Another way to state this conclusion is that we need to report >> success or failure of publishing each atomic element in an independent >> fashion. One quick and easy way to achieve that property is to allow >> only one atomic element per PUBLISH request. >> >> I think I heard another way to do this mentioned during the meeting, >> where we move reporting the success/failure and any feedback from >> the attempt to publish each tuple into the message instead of trying >> to capture it all on the status line. For example (I think this is >> what I heard suggested during the meeting), for presence, we could >> publish an entire pidf document with several tuples and in the presence >> response return an xml document with one element per tuple discussing >> the disposition of attempting to publish that tuple. >> >> Something along the lines of the following (an example to convey the >> concept, not a proposal of a syntax) >> >> >> >> >> >> >> >> >> >> If we were to pursue such an optimization, it might make sense to >> look at how to specify a separate etag value in the publish (currently >> what we put in an If-Match header) for each atom in the published >> document. >> >> RjS >> >> On Mon, 2003-07-14 at 19:58, aki.niemi@nokia.com wrote: >> >>> All, >>> >>> I'll try to summarize the issues w.r.t. the atomicity of publication >>> here in an attempt to converge the discussion towards a solution to >>> this problem. BTW, I realized that my slides in the SIMPLE session >>> were perhaps not crystal clear on what the problem at hand really >>> was, so my apologies for that. >>> >>> The core problem is this: >>> EPA X sends a PUBLISH with {a, b, c}, after which EPA Y publishes {a, >>> b}. When EPA X tries to refresh its publication of {a, b, c}, the >>> request fails because of a collision, resulting in the EPA X >>> quitting. EPA Y still refreshes its publication of {a, b}, which >>> means {c} expires and goes away. As a result, the publication process >>> has lost information of {c}. This is unacceptable, and with the >>> current versioning mechanism, this can't be remedied by composer >>> policy, for example. >>> >>> Instead, to get around the above problem, what you send in a PUBLISH >>> needs to match the atomic element of the published information. So >>> each PUBLISH needs to contain a single tuple, because the versioning >>> and expiration all work on the single atomic element level anyway. >>> >>> This has the apparent drawback in that the PUA has to wait for a 200 >>> OK after each PUBLISHed tuple before it can PUBLISH the next one. >>> This occurs upon every refresh cycle, and in systems with high >>> latency, may become a major issue in terms of performance. >>> >>> Ways to get around this inefficiency: >>> - Remove the restriction on overlapping requests, i.e., allow >>> "pipelining" >>> of PUBLISH requests >>> - Treat the publisher of each tuple as a separate EPA, and >>> therefore not >>> subject to this restriction in the first place (seems like >>> cheating...) >>> In conclusion, my proposal is to go with having always a single tuple >>> in a PUBLISH, and allow overlapping PUBLISH requests. To my >>> knowledge, this would fulfill all the related requirements and solve >>> the issue. >>> >>> Thoughts? >>> >>> Cheers, >>> Aki >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 16 02:33:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16545 for ; Wed, 16 Jul 2003 02:33:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cfqj-0002iu-Cn for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 02:33:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G6XDFS010468 for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 02:33:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cfqh-0002ij-MY for simple-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 02:33:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16506; Wed, 16 Jul 2003 02:33:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cfqc-0003UC-00; Wed, 16 Jul 2003 02:33:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cfqX-0003U9-00; Wed, 16 Jul 2003 02:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cfqX-0002gv-DK; Wed, 16 Jul 2003 02:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cfpt-0002g6-LP for simple@optimus.ietf.org; Wed, 16 Jul 2003 02:32:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16460 for ; Wed, 16 Jul 2003 02:32:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cfpp-0003Td-00 for simple@ietf.org; Wed, 16 Jul 2003 02:32:17 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19cfpe-0003Ou-00 for simple@ietf.org; Wed, 16 Jul 2003 02:32:06 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6G6TluD007758; Tue, 15 Jul 2003 23:29:48 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4301.cisco.com [10.61.80.204]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR86843; Wed, 16 Jul 2003 02:29:46 -0400 (EDT) Message-ID: <3F147DC9.8040102@cisco.com> 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 CC: Robert Sparks , Aki Niemi , simple@ietf.org Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB0@esebe013.ntc.nokia.com> <1058260190.934.23.camel@RjS.localdomain> <3F14590E.10901@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 18:18:49 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I generally like this idea, but maybe it is still too complex. Why do we need the Pstream-ID? Simply say each publisher must choose unique tuple ids and leave it at that. Regarding how to set up blocking of the ones you don't want, instead of pstream, how about simply having each publisher include its identity in each tuple, as an attribute? This could be filtered out for most users. Paul Jonathan Rosenberg wrote: > I was about to post a note on agreeing with Aki. I was also going to > say that we might want the body to also be the atomic unit, so that when > you publish a tuple, the body is an XML fragment for the tuple. Then, it > ocurred to me that we were really far down the complexity ramp here. So, > I thought about what we could do to really back out of this mess > entirely. Here is my idea. > > In the beginning, PUBLISH was easy. Each PUA published its own view of > the presence of the presentity. It had no knowledge of other PUA. It > published a complete presence document which represented what it thought > was the full presence of the presentity. Indeed, if there was only one > PUA, it would be the full presence of the presentity. There was no way > for one PUA to overwrite the published data from another. The tuple IDs > didn't need to have cross-PUA scope. No naming conventions or anything. > The compositor could combine these and modify them as it chose. Each > represented a unique and different piece of info about the presentity. A > useful bit of information was this "Pstream-ID", which uniquely > identified the publisher. You can think of the Pstream-ID as a way of > scoping the tuple IDs. Each tuple ID is defined only within the scope of > a Pstream-ID, and each publisher has to have a unique PStream-ID. > > It all got complicated when we decided to try and solve a bigger > problem, where PUA could override information about other PUA. That > introduced all kinds of problems. We needed to define the atomic > information of published presence. We need to resolve tuple naming. We > need to worry about this issue about whether a publish has one or more > tuples. We needed to add Etags and If-Modified-Since. We need to worry > about how to figure out what it means for the system to "wait for human > input" in cases where thats not possible. We don't know how to do that yet. > > Perhaps we should reconsider whether we want to solve this problem this > way. We have only one use case - when I leave my PC at the office with a > presence state that is wrong, and I want to fix it at home. Well, this > is a nice feature, but is it worth all of the complexity at this point? > There are other ways to deal with it. In fact, I can think of two > alternatives: > > 1. You could use the auth policy to simply disable the PC's data from > being placed in notifications, and then publish a separate tuple (i.e., > new piece of independent information) from home. Thats not as good (PC > still refreshes useless state), but its lots simpler than the route we > are on. > > 2. You could design a system which only allowed one PUA at a time (akin > to the current model in AIM and YIM). This would manifest itself as > composition policy. The compositor would only use the published document > from the PUA which started publishing most recently - that is, when its > Pstream-ID first appeared. This would also achieve the effect of > disabling the work PC's state when you arrive at home. > > > So, to be concrete, I would propose the following: > > > 1. Publications carry complete presence documents, representing the > complete presence state of the PUA as far as it knows. > > 2. Publishers are identified by a unique PStream-ID, chosen by the > publisher. Copying someone elses Pstream-ID is not allowed, and behavior > in this case is not defined. > > 3. There is no ability to overwrite someone elses presence document or > their tuples. Each publisher publishes independent information. > > 4. We eliminate the Etag, If-Modified-Since, and atomicity/segment > discussions from Publish. > > 5. Compositors can combine the publsihed information however they like. > There is no need to carry through tuple IDs from publication to > notifications. > > 6. If you want to block a tuple from getting into a notify, you identify > it by a distinguishing property rather than by tuple ID. > > > I believe this approach works nicely for other things too. In the case > of winfo, where you have lots of presence servers, each publishing winfo > for the subscriptions they have, its the same. Each publisher (a > presence server), publishes the complete view of the state - its own > subscriptions. There is no overlap between servers. The compositor > combines these together using a basic policy (combine subscriptions > together that are for the same presentity), and thats it. > > I believe it works for mwi too. > > I really feel that it is important that we make some simplifications so > that we can make rapid progress here. I don't think we lose much since > we can still get the desired feature; we just get it in a different way. > > Thoughts? > > -Jonathan R. > > Robert Sparks wrote: > >> Another way to state this conclusion is that we need to report >> success or failure of publishing each atomic element in an independent >> fashion. One quick and easy way to achieve that property is to allow >> only one atomic element per PUBLISH request. >> >> I think I heard another way to do this mentioned during the meeting, >> where we move reporting the success/failure and any feedback from >> the attempt to publish each tuple into the message instead of trying >> to capture it all on the status line. For example (I think this is >> what I heard suggested during the meeting), for presence, we could >> publish an entire pidf document with several tuples and in the presence >> response return an xml document with one element per tuple discussing >> the disposition of attempting to publish that tuple. >> >> Something along the lines of the following (an example to convey the >> concept, not a proposal of a syntax) >> >> >> >> >> >> >> >> >> >> If we were to pursue such an optimization, it might make sense to >> look at how to specify a separate etag value in the publish (currently >> what we put in an If-Match header) for each atom in the published >> document. >> >> RjS >> >> On Mon, 2003-07-14 at 19:58, aki.niemi@nokia.com wrote: >> >>> All, >>> >>> I'll try to summarize the issues w.r.t. the atomicity of publication >>> here in an attempt to converge the discussion towards a solution to >>> this problem. BTW, I realized that my slides in the SIMPLE session >>> were perhaps not crystal clear on what the problem at hand really >>> was, so my apologies for that. >>> >>> The core problem is this: >>> EPA X sends a PUBLISH with {a, b, c}, after which EPA Y publishes {a, >>> b}. When EPA X tries to refresh its publication of {a, b, c}, the >>> request fails because of a collision, resulting in the EPA X >>> quitting. EPA Y still refreshes its publication of {a, b}, which >>> means {c} expires and goes away. As a result, the publication process >>> has lost information of {c}. This is unacceptable, and with the >>> current versioning mechanism, this can't be remedied by composer >>> policy, for example. >>> >>> Instead, to get around the above problem, what you send in a PUBLISH >>> needs to match the atomic element of the published information. So >>> each PUBLISH needs to contain a single tuple, because the versioning >>> and expiration all work on the single atomic element level anyway. >>> >>> This has the apparent drawback in that the PUA has to wait for a 200 >>> OK after each PUBLISHed tuple before it can PUBLISH the next one. >>> This occurs upon every refresh cycle, and in systems with high >>> latency, may become a major issue in terms of performance. >>> >>> Ways to get around this inefficiency: >>> - Remove the restriction on overlapping requests, i.e., allow >>> "pipelining" >>> of PUBLISH requests >>> - Treat the publisher of each tuple as a separate EPA, and >>> therefore not >>> subject to this restriction in the first place (seems like >>> cheating...) >>> In conclusion, my proposal is to go with having always a single tuple >>> in a PUBLISH, and allow overlapping PUBLISH requests. To my >>> knowledge, this would fulfill all the related requirements and solve >>> the issue. >>> >>> Thoughts? >>> >>> Cheers, >>> Aki >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 16 02:52:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17166; Wed, 16 Jul 2003 02:52:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cg92-0003fQ-00; Wed, 16 Jul 2003 02:52:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cg8x-0003fN-00; Wed, 16 Jul 2003 02:52:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg8y-0003uh-4U; Wed, 16 Jul 2003 02:52:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg8V-0003ru-Re for simple@optimus.ietf.org; Wed, 16 Jul 2003 02:51:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17150 for ; Wed, 16 Jul 2003 02:51:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cg8S-0003f1-00 for simple@ietf.org; Wed, 16 Jul 2003 02:51:32 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cg8H-0003ek-00 for simple@ietf.org; Wed, 16 Jul 2003 02:51:21 -0400 Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6G6okiB010715 for ; Wed, 16 Jul 2003 02:50:46 -0400 (EDT) Message-ID: <3F1495FD.7070809@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 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 Content-Transfer-Encoding: 7bit Subject: [Simple] A proposal for xcap direction Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 20:02:05 -0400 Content-Transfer-Encoding: 7bit Folks, During the IETF meeting, I put forward a strawman proposal on a direction for xcap. The strawman is motivated by some important observations: 1. If xcap is anything except for an obvious http usage, it will require broader ietf input. Such input, through a design team, for example, would probably add a year (plus or minus 6 months) to the work. 2. Whats REALLY important to us is the schema - how we are representing authorization policies and buddy lists. How such data is transported from a client to the server is less important to us. Its also not really our core competency. Based on this, I would propose a substantial descoping of XCAP. In particular, I would propose that: 1. We do not address batching or transactions. That is, you won't be able to lock a list or auth policy, make a bunch of modifications, and then unlock. Is this a fatal loss of functionality? No. It turns out that if you are careful about how you design the schema, you will be able to ensure that most of the things you want to do can be done with a single GET/modify/PUT operation. Here's an example. One of the big concerns we had was moving a user from a white list to a black list. That requires two steps - (1) remove the user from the white list, and then (2) add the user to the black list. There is an intermediate state thats bad - the user is on neither list. This concern is based on the assumption that the authorization policy is structured as white and black lists. If you look at the xcap authorization usage, you find thats not true. Its structured (basically) as a list of watchers, and for each one, permissions for that watcher. To achieve the effect of moving the user from a while list to a black list, you would delete the permission for that user. This operation can be done in a single DELETE operation. Thus, no locking is needed. In fact, I was careful in the construction of the authorization schema to make sure that most of what I think we need to do is doable in one shot operations. I accomplished this by making the authorization policy structured as a list of statements, where each statement applies to one or more watchers. Each statement is a list of permissions, which grants the ability to get or receive something. Permissions are positive - they always grant something, never deny something. Its the mix of positive and negative things which requires two-step operations to ensure consistency, and I avoided them. 2. Every operation is a PUT. No POST. The IETF has established guidelines for usage of HTTP as a substrate for other protocols. One of the tell-tale signs of misuse is that you are using POST as a way to tunnel operations. POST has a well defined semantic - you are sending form data to a process that uses the data as input. In the current xcap draft, the POST operation is used to insert a new element, whereas PUT is used to modify an existing one. We need to only use PUT, since there really is no form processing engine here. However, we still need an insert and a modify operation. How to do that? Well, the proposed direction gives us the answer. How does HTTP support it? Simple. If you PUT a document to a URI that represents a resource that exists, the resource is replaced. If you PUT a document to a URI that doesnt exist, the resource is created (i.e., inserted). Now, our main problem is that there is no way to specify WHERE the new resource gets inserted within the "directory". For regular filesystems, it doesnt matter. For us, it does. So, we will have a constraint that if you do an insert operation on an XML element, you have to do it in a place where either (1) the positioning is implied by the schema, or (2) the positioning isnt important. Again, this just means careful schema design. You will note that in both the authorization usage and buddy list usage, there are many key points in the schema where you can insert things where either the ordering is dictated or not important. 3. We remove the ability to have server computed data (not possible with PUT). That means that creating a buddy list requires the client to either (1) select the URI so its unique, (2) obtain the URI through some other means, (3) put the data without a URI, have the server set the URI, and then have the client fetch the data with the URI filled in. None of them are pretty. Its a limitation with the approach. 3. We may be able to keep the ability to have servers enforce data constraints that the schema cannot represent. Not sure its useful. 4. We pursue a longer term solution of working with webdav by adding partial patches through some kind of webdav extension. This would be xcap 2.0. During the meeting, there was good support for this. Ted gave some good input. His idea was to take it a step furhter and eliminate xpath. The suggestion was to obtain partial updates by treating each buddy or each watcher permission as a separate http resource. This amounts to declaring specific "breakpoints" in the current schemas which represent the atomic units we will operate on. I need to mull that over some more to see if it works. More on that when I have a concrete opinion on it. However, I did want to solicit input from the working group on the list about this direction. So, please comment or ask questions. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 16 02:52:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17200 for ; Wed, 16 Jul 2003 02:52:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg97-0003yr-Aw for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 02:52:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G6qDY2015300 for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 02:52:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg97-0003yh-5m for simple-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 02:52:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17166; Wed, 16 Jul 2003 02:52:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cg92-0003fQ-00; Wed, 16 Jul 2003 02:52:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cg8x-0003fN-00; Wed, 16 Jul 2003 02:52:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg8y-0003uh-4U; Wed, 16 Jul 2003 02:52:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg8V-0003ru-Re for simple@optimus.ietf.org; Wed, 16 Jul 2003 02:51:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17150 for ; Wed, 16 Jul 2003 02:51:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cg8S-0003f1-00 for simple@ietf.org; Wed, 16 Jul 2003 02:51:32 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cg8H-0003ek-00 for simple@ietf.org; Wed, 16 Jul 2003 02:51:21 -0400 Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6G6okiB010715 for ; Wed, 16 Jul 2003 02:50:46 -0400 (EDT) Message-ID: <3F1495FD.7070809@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 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 Content-Transfer-Encoding: 7bit Subject: [Simple] A proposal for xcap direction Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Jul 2003 20:02:05 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, During the IETF meeting, I put forward a strawman proposal on a direction for xcap. The strawman is motivated by some important observations: 1. If xcap is anything except for an obvious http usage, it will require broader ietf input. Such input, through a design team, for example, would probably add a year (plus or minus 6 months) to the work. 2. Whats REALLY important to us is the schema - how we are representing authorization policies and buddy lists. How such data is transported from a client to the server is less important to us. Its also not really our core competency. Based on this, I would propose a substantial descoping of XCAP. In particular, I would propose that: 1. We do not address batching or transactions. That is, you won't be able to lock a list or auth policy, make a bunch of modifications, and then unlock. Is this a fatal loss of functionality? No. It turns out that if you are careful about how you design the schema, you will be able to ensure that most of the things you want to do can be done with a single GET/modify/PUT operation. Here's an example. One of the big concerns we had was moving a user from a white list to a black list. That requires two steps - (1) remove the user from the white list, and then (2) add the user to the black list. There is an intermediate state thats bad - the user is on neither list. This concern is based on the assumption that the authorization policy is structured as white and black lists. If you look at the xcap authorization usage, you find thats not true. Its structured (basically) as a list of watchers, and for each one, permissions for that watcher. To achieve the effect of moving the user from a while list to a black list, you would delete the permission for that user. This operation can be done in a single DELETE operation. Thus, no locking is needed. In fact, I was careful in the construction of the authorization schema to make sure that most of what I think we need to do is doable in one shot operations. I accomplished this by making the authorization policy structured as a list of statements, where each statement applies to one or more watchers. Each statement is a list of permissions, which grants the ability to get or receive something. Permissions are positive - they always grant something, never deny something. Its the mix of positive and negative things which requires two-step operations to ensure consistency, and I avoided them. 2. Every operation is a PUT. No POST. The IETF has established guidelines for usage of HTTP as a substrate for other protocols. One of the tell-tale signs of misuse is that you are using POST as a way to tunnel operations. POST has a well defined semantic - you are sending form data to a process that uses the data as input. In the current xcap draft, the POST operation is used to insert a new element, whereas PUT is used to modify an existing one. We need to only use PUT, since there really is no form processing engine here. However, we still need an insert and a modify operation. How to do that? Well, the proposed direction gives us the answer. How does HTTP support it? Simple. If you PUT a document to a URI that represents a resource that exists, the resource is replaced. If you PUT a document to a URI that doesnt exist, the resource is created (i.e., inserted). Now, our main problem is that there is no way to specify WHERE the new resource gets inserted within the "directory". For regular filesystems, it doesnt matter. For us, it does. So, we will have a constraint that if you do an insert operation on an XML element, you have to do it in a place where either (1) the positioning is implied by the schema, or (2) the positioning isnt important. Again, this just means careful schema design. You will note that in both the authorization usage and buddy list usage, there are many key points in the schema where you can insert things where either the ordering is dictated or not important. 3. We remove the ability to have server computed data (not possible with PUT). That means that creating a buddy list requires the client to either (1) select the URI so its unique, (2) obtain the URI through some other means, (3) put the data without a URI, have the server set the URI, and then have the client fetch the data with the URI filled in. None of them are pretty. Its a limitation with the approach. 3. We may be able to keep the ability to have servers enforce data constraints that the schema cannot represent. Not sure its useful. 4. We pursue a longer term solution of working with webdav by adding partial patches through some kind of webdav extension. This would be xcap 2.0. During the meeting, there was good support for this. Ted gave some good input. His idea was to take it a step furhter and eliminate xpath. The suggestion was to obtain partial updates by treating each buddy or each watcher permission as a separate http resource. This amounts to declaring specific "breakpoints" in the current schemas which represent the atomic units we will operate on. I need to mull that over some more to see if it works. More on that when I have a concrete opinion on it. However, I did want to solicit input from the working group on the list about this direction. So, please comment or ask questions. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 16 05:10:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22192; Wed, 16 Jul 2003 05:10:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ciIb-0004xa-00; Wed, 16 Jul 2003 05:10:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ciIV-0004xX-00; Wed, 16 Jul 2003 05:10:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciIT-0004M9-73; Wed, 16 Jul 2003 05:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciI1-0004LV-Q9 for simple@optimus.ietf.org; Wed, 16 Jul 2003 05:09:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22187 for ; Wed, 16 Jul 2003 05:09:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ciHy-0004xJ-00 for simple@ietf.org; Wed, 16 Jul 2003 05:09:30 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19ciHj-0004xB-00 for simple@ietf.org; Wed, 16 Jul 2003 05:09:15 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6G98nkM015414; Wed, 16 Jul 2003 05:08:49 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6G98mg08550; Wed, 16 Jul 2003 05:08:48 -0400 Message-ID: <3F151528.6080502@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] A proposal for xcap direction References: <3F1495FD.7070809@dynamicsoft.com> In-Reply-To: <3F1495FD.7070809@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Jul 2003 05:04:40 -0400 Content-Transfer-Encoding: 7bit I'm all for minimal functionality and a single mechanism. Since we only need a small subset of the functionality of XPath functionality, it seems easier to just have atomic units as part of the path. This also avoids having to worry about micro-manipulation of individual elements and simplifies server implementation. In the simpler implementation, you can simply have an XML parser for each unit and store it internally as a database or some other more appropriate format. If you allow random element-level modification, you have to keep the DOM representation around and have to make sure that things that can't easily be modified in one step are consistent and valid in intermediate steps. Jonathan Rosenberg wrote: > Folks, > > During the IETF meeting, I put forward a strawman proposal on a > direction for xcap. The strawman is motivated by some important > observations: > > 1. If xcap is anything except for an obvious http usage, it will require > broader ietf input. Such input, through a design team, for example, > would probably add a year (plus or minus 6 months) to the work. > > 2. Whats REALLY important to us is the schema - how we are representing > authorization policies and buddy lists. How such data is transported > from a client to the server is less important to us. Its also not really > our core competency. > > Based on this, I would propose a substantial descoping of XCAP. In > particular, I would propose that: > > 1. We do not address batching or transactions. That is, you won't be > able to lock a list or auth policy, make a bunch of modifications, and > then unlock. Is this a fatal loss of functionality? No. It turns out > that if you are careful about how you design the schema, you will be > able to ensure that most of the things you want to do can be done with a > single GET/modify/PUT operation. > > Here's an example. > > One of the big concerns we had was moving a user from a white list to a > black list. That requires two steps - (1) remove the user from the white > list, and then (2) add the user to the black list. There is an > intermediate state thats bad - the user is on neither list. This concern > is based on the assumption that the authorization policy is structured > as white and black lists. If you look at the xcap authorization usage, > you find thats not true. Its structured (basically) as a list of > watchers, and for each one, permissions for that watcher. To achieve the > effect of moving the user from a while list to a black list, you would > delete the permission for that user. This operation can be done > in a single DELETE operation. Thus, no locking is needed. > > In fact, I was careful in the construction of the authorization schema > to make sure that most of what I think we need to do is doable in one > shot operations. I accomplished this by making the authorization policy > structured as a list of statements, where each statement applies to one > or more watchers. Each statement is a list of permissions, which grants > the ability to get or receive something. Permissions are positive - they > always grant something, never deny something. Its the mix of positive > and negative things which requires two-step operations to ensure > consistency, and I avoided them. > > 2. Every operation is a PUT. No POST. The IETF has established > guidelines for usage of HTTP as a substrate for other protocols. One of > the tell-tale signs of misuse is that you are using POST as a way to > tunnel operations. POST has a well defined semantic - you are sending > form data to a process that uses the data as input. In the current xcap > draft, the POST operation is used to insert a new element, whereas PUT > is used to modify an existing one. We need to only use PUT, since there > really is no form processing engine here. However, we still need an > insert and a modify operation. How to do that? > > Well, the proposed direction gives us the answer. How does HTTP support > it? Simple. If you PUT a document to a URI that represents a resource > that exists, the resource is replaced. If you PUT a document to a URI > that doesnt exist, the resource is created (i.e., inserted). Now, our > main problem is that there is no way to specify WHERE the new resource > gets inserted within the "directory". For regular filesystems, it doesnt > matter. For us, it does. So, we will have a constraint that if you do an > insert operation on an XML element, you have to do it in a place where > either (1) the positioning is implied by the schema, or (2) the > positioning isnt important. Again, this just means careful schema > design. You will note that in both the authorization usage and buddy > list usage, there are many key points in the schema where you can insert > things where either the ordering is dictated or not important. > > 3. We remove the ability to have server computed data (not possible with > PUT). That means that creating a buddy list requires the client to > either (1) select the URI so its unique, (2) obtain the URI through some > other means, (3) put the data without a URI, have the server set the > URI, and then have the client fetch the data with the URI filled in. > None of them are pretty. Its a limitation with the approach. > > 3. We may be able to keep the ability to have servers enforce data > constraints that the schema cannot represent. Not sure its useful. > > 4. We pursue a longer term solution of working with webdav by adding > partial patches through some kind of webdav extension. This would be > xcap 2.0. > > > > During the meeting, there was good support for this. Ted gave some good > input. His idea was to take it a step furhter and eliminate xpath. The > suggestion was to obtain partial updates by treating each buddy or each > watcher permission as a separate http resource. This amounts to > declaring specific "breakpoints" in the current schemas which represent > the atomic units we will operate on. I need to mull that over some more > to see if it works. More on that when I have a concrete opinion on it. > > However, I did want to solicit input from the working group on the list > about this direction. So, please comment or ask questions. > > Thanks, > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 16 05:10:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22218 for ; Wed, 16 Jul 2003 05:10:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciIf-0004Ng-7f for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 05:10:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G9ADE6016836 for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 05:10:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciIf-0004NT-3L for simple-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 05:10:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22192; Wed, 16 Jul 2003 05:10:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ciIb-0004xa-00; Wed, 16 Jul 2003 05:10:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ciIV-0004xX-00; Wed, 16 Jul 2003 05:10:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciIT-0004M9-73; Wed, 16 Jul 2003 05:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciI1-0004LV-Q9 for simple@optimus.ietf.org; Wed, 16 Jul 2003 05:09:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22187 for ; Wed, 16 Jul 2003 05:09:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ciHy-0004xJ-00 for simple@ietf.org; Wed, 16 Jul 2003 05:09:30 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19ciHj-0004xB-00 for simple@ietf.org; Wed, 16 Jul 2003 05:09:15 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6G98nkM015414; Wed, 16 Jul 2003 05:08:49 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6G98mg08550; Wed, 16 Jul 2003 05:08:48 -0400 Message-ID: <3F151528.6080502@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] A proposal for xcap direction References: <3F1495FD.7070809@dynamicsoft.com> In-Reply-To: <3F1495FD.7070809@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Jul 2003 05:04:40 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm all for minimal functionality and a single mechanism. Since we only need a small subset of the functionality of XPath functionality, it seems easier to just have atomic units as part of the path. This also avoids having to worry about micro-manipulation of individual elements and simplifies server implementation. In the simpler implementation, you can simply have an XML parser for each unit and store it internally as a database or some other more appropriate format. If you allow random element-level modification, you have to keep the DOM representation around and have to make sure that things that can't easily be modified in one step are consistent and valid in intermediate steps. Jonathan Rosenberg wrote: > Folks, > > During the IETF meeting, I put forward a strawman proposal on a > direction for xcap. The strawman is motivated by some important > observations: > > 1. If xcap is anything except for an obvious http usage, it will require > broader ietf input. Such input, through a design team, for example, > would probably add a year (plus or minus 6 months) to the work. > > 2. Whats REALLY important to us is the schema - how we are representing > authorization policies and buddy lists. How such data is transported > from a client to the server is less important to us. Its also not really > our core competency. > > Based on this, I would propose a substantial descoping of XCAP. In > particular, I would propose that: > > 1. We do not address batching or transactions. That is, you won't be > able to lock a list or auth policy, make a bunch of modifications, and > then unlock. Is this a fatal loss of functionality? No. It turns out > that if you are careful about how you design the schema, you will be > able to ensure that most of the things you want to do can be done with a > single GET/modify/PUT operation. > > Here's an example. > > One of the big concerns we had was moving a user from a white list to a > black list. That requires two steps - (1) remove the user from the white > list, and then (2) add the user to the black list. There is an > intermediate state thats bad - the user is on neither list. This concern > is based on the assumption that the authorization policy is structured > as white and black lists. If you look at the xcap authorization usage, > you find thats not true. Its structured (basically) as a list of > watchers, and for each one, permissions for that watcher. To achieve the > effect of moving the user from a while list to a black list, you would > delete the permission for that user. This operation can be done > in a single DELETE operation. Thus, no locking is needed. > > In fact, I was careful in the construction of the authorization schema > to make sure that most of what I think we need to do is doable in one > shot operations. I accomplished this by making the authorization policy > structured as a list of statements, where each statement applies to one > or more watchers. Each statement is a list of permissions, which grants > the ability to get or receive something. Permissions are positive - they > always grant something, never deny something. Its the mix of positive > and negative things which requires two-step operations to ensure > consistency, and I avoided them. > > 2. Every operation is a PUT. No POST. The IETF has established > guidelines for usage of HTTP as a substrate for other protocols. One of > the tell-tale signs of misuse is that you are using POST as a way to > tunnel operations. POST has a well defined semantic - you are sending > form data to a process that uses the data as input. In the current xcap > draft, the POST operation is used to insert a new element, whereas PUT > is used to modify an existing one. We need to only use PUT, since there > really is no form processing engine here. However, we still need an > insert and a modify operation. How to do that? > > Well, the proposed direction gives us the answer. How does HTTP support > it? Simple. If you PUT a document to a URI that represents a resource > that exists, the resource is replaced. If you PUT a document to a URI > that doesnt exist, the resource is created (i.e., inserted). Now, our > main problem is that there is no way to specify WHERE the new resource > gets inserted within the "directory". For regular filesystems, it doesnt > matter. For us, it does. So, we will have a constraint that if you do an > insert operation on an XML element, you have to do it in a place where > either (1) the positioning is implied by the schema, or (2) the > positioning isnt important. Again, this just means careful schema > design. You will note that in both the authorization usage and buddy > list usage, there are many key points in the schema where you can insert > things where either the ordering is dictated or not important. > > 3. We remove the ability to have server computed data (not possible with > PUT). That means that creating a buddy list requires the client to > either (1) select the URI so its unique, (2) obtain the URI through some > other means, (3) put the data without a URI, have the server set the > URI, and then have the client fetch the data with the URI filled in. > None of them are pretty. Its a limitation with the approach. > > 3. We may be able to keep the ability to have servers enforce data > constraints that the schema cannot represent. Not sure its useful. > > 4. We pursue a longer term solution of working with webdav by adding > partial patches through some kind of webdav extension. This would be > xcap 2.0. > > > > During the meeting, there was good support for this. Ted gave some good > input. His idea was to take it a step furhter and eliminate xpath. The > suggestion was to obtain partial updates by treating each buddy or each > watcher permission as a separate http resource. This amounts to > declaring specific "breakpoints" in the current schemas which represent > the atomic units we will operate on. I need to mull that over some more > to see if it works. More on that when I have a concrete opinion on it. > > However, I did want to solicit input from the working group on the list > about this direction. So, please comment or ask questions. > > Thanks, > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 16 06:56:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25112; Wed, 16 Jul 2003 06:56:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cjxA-0005oO-00; Wed, 16 Jul 2003 06:56:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cjx5-0005oL-00; Wed, 16 Jul 2003 06:56:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjx3-0001eQ-Pp; Wed, 16 Jul 2003 06:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjwx-0001e5-Jg for simple@optimus.ietf.org; Wed, 16 Jul 2003 06:55:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25106 for ; Wed, 16 Jul 2003 06:55:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cjwt-0005oI-00 for simple@ietf.org; Wed, 16 Jul 2003 06:55:51 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19cjwi-0005oD-00 for simple@ietf.org; Wed, 16 Jul 2003 06:55:40 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6GAt4uJ017567; Wed, 16 Jul 2003 03:55:04 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4171.cisco.com [10.61.80.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR95469; Wed, 16 Jul 2003 06:55:01 -0400 (EDT) Message-ID: <3F152F05.6070002@cisco.com> 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 CC: Jonathan Rosenberg , "Peterson, Jon" , simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - face-to-face References: <0449D80A0E9B614A83FA9031B07E8D3B257C1D@stntexch2.va.neustar.com> <3EFDB74A.7040707@cs.columbia.edu> <3F116087.5020701@dynamicsoft.com> <3F11681E.5000908@cs.columbia.edu> <3F134EC5.6050803@dynamicsoft.com> <3F13E4C2.5030107@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Jul 2003 06:55:01 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > I agree that this can easily be elsewhere; it's probably a tuple-level > parameter. Might this be a fourth label, next to 'device', 'presentity' > and 'other'? After all, it would probably not be nice to humans to > qualify a face-to-face contact as a 'device'. Why? People are just smart automatons. It is quite common to use people as automatons. Get over it and accept the assimilation. :-) Personally I think this is just another communication means. And it isn't necessarily face-face either. I think all it really means is that the user has no available device to facilitate communication. If you want to talk, you could send an intermediary with a cell phone. But given resistance to making something that can appear in a I guess a tuple-level parameter seems reasonable. I agree that having this be the implicit meaning of a tuple without a contact is troubling. But then fixing this leaves us with the problem of the meaning of a tuple without either this or a contact. Apparently it is just noise, unless some other extension assigns it meaning. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 16 06:56:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25165 for ; Wed, 16 Jul 2003 06:56:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjxF-0001ht-Et for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 06:56:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GAuD0O006562 for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 06:56:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjxF-0001hl-BT for simple-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 06:56:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25112; Wed, 16 Jul 2003 06:56:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cjxA-0005oO-00; Wed, 16 Jul 2003 06:56:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cjx5-0005oL-00; Wed, 16 Jul 2003 06:56:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjx3-0001eQ-Pp; Wed, 16 Jul 2003 06:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjwx-0001e5-Jg for simple@optimus.ietf.org; Wed, 16 Jul 2003 06:55:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25106 for ; Wed, 16 Jul 2003 06:55:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cjwt-0005oI-00 for simple@ietf.org; Wed, 16 Jul 2003 06:55:51 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19cjwi-0005oD-00 for simple@ietf.org; Wed, 16 Jul 2003 06:55:40 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6GAt4uJ017567; Wed, 16 Jul 2003 03:55:04 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4171.cisco.com [10.61.80.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR95469; Wed, 16 Jul 2003 06:55:01 -0400 (EDT) Message-ID: <3F152F05.6070002@cisco.com> 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 CC: Jonathan Rosenberg , "Peterson, Jon" , simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - face-to-face References: <0449D80A0E9B614A83FA9031B07E8D3B257C1D@stntexch2.va.neustar.com> <3EFDB74A.7040707@cs.columbia.edu> <3F116087.5020701@dynamicsoft.com> <3F11681E.5000908@cs.columbia.edu> <3F134EC5.6050803@dynamicsoft.com> <3F13E4C2.5030107@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Jul 2003 06:55:01 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > I agree that this can easily be elsewhere; it's probably a tuple-level > parameter. Might this be a fourth label, next to 'device', 'presentity' > and 'other'? After all, it would probably not be nice to humans to > qualify a face-to-face contact as a 'device'. Why? People are just smart automatons. It is quite common to use people as automatons. Get over it and accept the assimilation. :-) Personally I think this is just another communication means. And it isn't necessarily face-face either. I think all it really means is that the user has no available device to facilitate communication. If you want to talk, you could send an intermediary with a cell phone. But given resistance to making something that can appear in a I guess a tuple-level parameter seems reasonable. I agree that having this be the implicit meaning of a tuple without a contact is troubling. But then fixing this leaves us with the problem of the meaning of a tuple without either this or a contact. Apparently it is just noise, unless some other extension assigns it meaning. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 16 07:29:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25963; Wed, 16 Jul 2003 07:29:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ckTB-00065i-00; Wed, 16 Jul 2003 07:29:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ckT5-00065f-00; Wed, 16 Jul 2003 07:29:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ckSz-0003gV-6y; Wed, 16 Jul 2003 07:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ckS3-0003eM-TQ for simple@optimus.ietf.org; Wed, 16 Jul 2003 07:28:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25930 for ; Wed, 16 Jul 2003 07:28:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ckS3-00064o-00 for simple@ietf.org; Wed, 16 Jul 2003 07:28:03 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19ckRm-00063h-00 for simple@ietf.org; Wed, 16 Jul 2003 07:27:47 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6GBNAkM026811; Wed, 16 Jul 2003 07:23:11 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6GBN4g18443; Wed, 16 Jul 2003 07:23:04 -0400 Message-ID: <3F1534A0.6060509@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , "Peterson, Jon" , simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - face-to-face References: <0449D80A0E9B614A83FA9031B07E8D3B257C1D@stntexch2.va.neustar.com> <3EFDB74A.7040707@cs.columbia.edu> <3F116087.5020701@dynamicsoft.com> <3F11681E.5000908@cs.columbia.edu> <3F134EC5.6050803@dynamicsoft.com> <3F13E4C2.5030107@cs.columbia.edu> <3F152F05.6070002@cisco.com> In-Reply-To: <3F152F05.6070002@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Jul 2003 07:18:56 -0400 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Why? People are just smart automatons. It is quite common to use people > as automatons. Get over it and accept the assimilation. :-) > > But given resistance to making something that can appear in a > I guess a tuple-level parameter seems reasonable. Particularly since any designation of media is not quite orthogonal. > > I agree that having this be the implicit meaning of a tuple without a > contact is troubling. But then fixing this leaves us with the problem of > the meaning of a tuple without either this or a contact. Apparently it > is just noise, unless some other extension assigns it meaning. You might want to describe just the location of the presentity, independent of the device, even though the person does not want to be contacted in person. As you say, this seems best defined implicitly by the presence of specific descriptors. > > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 16 07:29:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26010 for ; Wed, 16 Jul 2003 07:29:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ckTO-0003q3-OE for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 07:29:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GBTQHF014751 for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 07:29:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ckTO-0003pq-LQ for simple-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 07:29:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25963; Wed, 16 Jul 2003 07:29:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ckTB-00065i-00; Wed, 16 Jul 2003 07:29:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ckT5-00065f-00; Wed, 16 Jul 2003 07:29:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ckSz-0003gV-6y; Wed, 16 Jul 2003 07:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ckS3-0003eM-TQ for simple@optimus.ietf.org; Wed, 16 Jul 2003 07:28:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25930 for ; Wed, 16 Jul 2003 07:28:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ckS3-00064o-00 for simple@ietf.org; Wed, 16 Jul 2003 07:28:03 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19ckRm-00063h-00 for simple@ietf.org; Wed, 16 Jul 2003 07:27:47 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6GBNAkM026811; Wed, 16 Jul 2003 07:23:11 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6GBN4g18443; Wed, 16 Jul 2003 07:23:04 -0400 Message-ID: <3F1534A0.6060509@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , "Peterson, Jon" , simple@ietf.org Subject: Re: [Simple] comments on rpids-01 - face-to-face References: <0449D80A0E9B614A83FA9031B07E8D3B257C1D@stntexch2.va.neustar.com> <3EFDB74A.7040707@cs.columbia.edu> <3F116087.5020701@dynamicsoft.com> <3F11681E.5000908@cs.columbia.edu> <3F134EC5.6050803@dynamicsoft.com> <3F13E4C2.5030107@cs.columbia.edu> <3F152F05.6070002@cisco.com> In-Reply-To: <3F152F05.6070002@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Jul 2003 07:18:56 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Why? People are just smart automatons. It is quite common to use people > as automatons. Get over it and accept the assimilation. :-) > > But given resistance to making something that can appear in a > I guess a tuple-level parameter seems reasonable. Particularly since any designation of media is not quite orthogonal. > > I agree that having this be the implicit meaning of a tuple without a > contact is troubling. But then fixing this leaves us with the problem of > the meaning of a tuple without either this or a contact. Apparently it > is just noise, unless some other extension assigns it meaning. You might want to describe just the location of the presentity, independent of the device, even though the person does not want to be contacted in person. As you say, this seems best defined implicitly by the presence of specific descriptors. > > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 16 10:02:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00750; Wed, 16 Jul 2003 10:02:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmr3-0004eX-2z; Wed, 16 Jul 2003 10:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmqO-0004e8-SC for simple@optimus.ietf.org; Wed, 16 Jul 2003 10:01:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00719 for ; Wed, 16 Jul 2003 10:01:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cmqM-0007Px-00 for simple@ietf.org; Wed, 16 Jul 2003 10:01:18 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19cmqB-0007M0-00 for simple@ietf.org; Wed, 16 Jul 2003 10:01:07 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 Jul 2003 06:57:13 -0700 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6GDveuJ028351; Wed, 16 Jul 2003 06:57:41 -0700 (PDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-140.cisco.com [64.100.229.140]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHG28859; Wed, 16 Jul 2003 06:57:38 -0700 (PDT) Message-Id: <4.3.2.7.2.20030716094934.00b29d00@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Ben Campbell From: Michael Hammer Subject: Re: [Simple] Tuple design team discussion summary Cc: Henning Schulzrinne , Simple WG In-Reply-To: <1058259234.2536.27.camel@verite.localdomain> References: <3F13BD7D.409@cs.columbia.edu> <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> <3F135001.9040206@dynamicsoft.com> <1058257541.2536.7.camel@verite.localdomain> <3F13BD7D.409@cs.columbia.edu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1646627==_.ALT" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Jul 2003 09:57:38 -0400 --=====================_1646627==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Ben, I am unclear whether this line of thought was abandoned or not. If not, then I have some questions: Mobile v. fixed: Do you anticipate that what is today called "fixed wireless", i.e. 802.11 will fall into the mobile category, when they figure out how to do roaming, then handoff? Would not Wireless, Roam-capable, and Handoff-capable be better descriptors? Is that what is important? Or, is mobility really just a short-hand way of indicating that there are BW constraints (which may or may not occur depending on whether it is truly broadband or not)? Is this really, just a size limit question. Text: Given that deaf folks think IM and TTY are very different, does that need to be discriminated? Do you need to discriminate between different degrees of immediacy: TTY v. IM v. slower SMS v. email? Is it the size (BW) that is of concern or is it the expectation of interactivity? Is that what stream/message intended to convey? Mike At 03:53 AM 7/15/2003 -0500, Ben Campbell wrote: >Hopefully we can generalize these a bit. For example: > >voice device >Mobile voice device >Fixed voice device >Workstation (or some sort of rich media device) >text device >short text device (i.e. don't send me big stuff) > >This list seems to me to break down to a few dimensions: > >Mobility >Media >stream/message orientation >Size limits > >Which sound a lot like capabilities to me. > >On Tue, 2003-07-15 at 03:38, Henning Schulzrinne wrote: > > Almost none of the labels in RPIDS are exhaustive or claim to be, so a > > list is better than nothing. To make progress, I would like to call for > > nominations for such labels. The obvious ones are device-oriented ones > > cell phone > > PC > > landline phone > > text device (BlackBerry, SMS, TTY, ...) > > other suggestions? > > > > Ben Campbell wrote: > > > > > > > > I think even that can be handled cleanly. Such a device just displays > > > some default icon that indicates it does not know what type of tuple it > > > has. That is no different from common usage in many other applications. > > > For example, email attachments when your browser does not recognize the > > > mime type, or gets something completely generic like > > > application/octet-stream without any other qualifiers. > > > > > > > > > > > > > > > _______________________________________________ > > 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 --=====================_1646627==_.ALT Content-Type: text/html; charset="us-ascii" Ben,

I am unclear whether this line of thought was abandoned or not. 
If not, then I have some questions:

Mobile v. fixed:  Do you anticipate that what is today called "fixed wireless", i.e. 802.11 will fall into the mobile category, when they figure out how to do roaming, then handoff?  Would not Wireless, Roam-capable, and Handoff-capable be better descriptors?  Is that what is important?

Or, is mobility really just a short-hand way of indicating that there are BW constraints (which may or may not occur depending on whether it is truly broadband or not)?  Is this really, just a size limit question.

Text:  Given that deaf folks think IM and TTY are very different, does that need to be discriminated?  Do you need to discriminate between different degrees of immediacy:  TTY v. IM v. slower SMS v. email?  Is it the size (BW) that is of concern or is it the expectation of interactivity?  Is that what stream/message intended to convey?

Mike

At 03:53 AM 7/15/2003 -0500, Ben Campbell wrote:
Hopefully we can generalize these a bit. For example:

voice device
Mobile voice device
Fixed voice device
Workstation (or some sort of rich media device)
text device
short text device (i.e. don't send me big stuff)

This list seems to me to break down to a few dimensions:

Mobility
Media
stream/message orientation
Size limits

Which sound a lot like capabilities to me.

On Tue, 2003-07-15 at 03:38, Henning Schulzrinne wrote:
> Almost none of the labels in RPIDS are exhaustive or claim to be, so a
> list is better than nothing. To make progress, I would like to call for
> nominations for such labels. The obvious ones are device-oriented ones
>    cell phone
>    PC
>    landline phone
>    text device (BlackBerry, SMS, TTY, ...)
> other suggestions?
>
> Ben Campbell wrote:
>
> >
> > I think even that can be handled cleanly. Such a device just displays
> > some default icon that indicates it does not know what type of tuple it
> > has. That is no different from common usage in many other applications.
> > For example, email attachments when your browser does not recognize the
> > mime type, or gets something completely generic like
> > application/octet-stream without any other qualifiers.
> >
>
>
>
>
>
> _______________________________________________
> 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
--=====================_1646627==_.ALT-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 16 10:03:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00790 for ; Wed, 16 Jul 2003 10:03:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmrb-0004i4-7v for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 10:02:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GE2ZK3018104 for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 10:02:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmrb-0004hv-3n for simple-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 10:02:35 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00750; Wed, 16 Jul 2003 10:02:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmr3-0004eX-2z; Wed, 16 Jul 2003 10:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmqO-0004e8-SC for simple@optimus.ietf.org; Wed, 16 Jul 2003 10:01:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00719 for ; Wed, 16 Jul 2003 10:01:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cmqM-0007Px-00 for simple@ietf.org; Wed, 16 Jul 2003 10:01:18 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19cmqB-0007M0-00 for simple@ietf.org; Wed, 16 Jul 2003 10:01:07 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 Jul 2003 06:57:13 -0700 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6GDveuJ028351; Wed, 16 Jul 2003 06:57:41 -0700 (PDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-140.cisco.com [64.100.229.140]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHG28859; Wed, 16 Jul 2003 06:57:38 -0700 (PDT) Message-Id: <4.3.2.7.2.20030716094934.00b29d00@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Ben Campbell From: Michael Hammer Subject: Re: [Simple] Tuple design team discussion summary Cc: Henning Schulzrinne , Simple WG In-Reply-To: <1058259234.2536.27.camel@verite.localdomain> References: <3F13BD7D.409@cs.columbia.edu> <9BF66EBF6BEFD942915B4D4D45C051F3EE5FE8@dyn-tx-exch-001.dynamicsoft.com> <3F135001.9040206@dynamicsoft.com> <1058257541.2536.7.camel@verite.localdomain> <3F13BD7D.409@cs.columbia.edu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1646627==_.ALT" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Jul 2003 09:57:38 -0400 --=====================_1646627==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Ben, I am unclear whether this line of thought was abandoned or not. If not, then I have some questions: Mobile v. fixed: Do you anticipate that what is today called "fixed wireless", i.e. 802.11 will fall into the mobile category, when they figure out how to do roaming, then handoff? Would not Wireless, Roam-capable, and Handoff-capable be better descriptors? Is that what is important? Or, is mobility really just a short-hand way of indicating that there are BW constraints (which may or may not occur depending on whether it is truly broadband or not)? Is this really, just a size limit question. Text: Given that deaf folks think IM and TTY are very different, does that need to be discriminated? Do you need to discriminate between different degrees of immediacy: TTY v. IM v. slower SMS v. email? Is it the size (BW) that is of concern or is it the expectation of interactivity? Is that what stream/message intended to convey? Mike At 03:53 AM 7/15/2003 -0500, Ben Campbell wrote: >Hopefully we can generalize these a bit. For example: > >voice device >Mobile voice device >Fixed voice device >Workstation (or some sort of rich media device) >text device >short text device (i.e. don't send me big stuff) > >This list seems to me to break down to a few dimensions: > >Mobility >Media >stream/message orientation >Size limits > >Which sound a lot like capabilities to me. > >On Tue, 2003-07-15 at 03:38, Henning Schulzrinne wrote: > > Almost none of the labels in RPIDS are exhaustive or claim to be, so a > > list is better than nothing. To make progress, I would like to call for > > nominations for such labels. The obvious ones are device-oriented ones > > cell phone > > PC > > landline phone > > text device (BlackBerry, SMS, TTY, ...) > > other suggestions? > > > > Ben Campbell wrote: > > > > > > > > I think even that can be handled cleanly. Such a device just displays > > > some default icon that indicates it does not know what type of tuple it > > > has. That is no different from common usage in many other applications. > > > For example, email attachments when your browser does not recognize the > > > mime type, or gets something completely generic like > > > application/octet-stream without any other qualifiers. > > > > > > > > > > > > > > > _______________________________________________ > > 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 --=====================_1646627==_.ALT Content-Type: text/html; charset="us-ascii" Ben,

I am unclear whether this line of thought was abandoned or not. 
If not, then I have some questions:

Mobile v. fixed:  Do you anticipate that what is today called "fixed wireless", i.e. 802.11 will fall into the mobile category, when they figure out how to do roaming, then handoff?  Would not Wireless, Roam-capable, and Handoff-capable be better descriptors?  Is that what is important?

Or, is mobility really just a short-hand way of indicating that there are BW constraints (which may or may not occur depending on whether it is truly broadband or not)?  Is this really, just a size limit question.

Text:  Given that deaf folks think IM and TTY are very different, does that need to be discriminated?  Do you need to discriminate between different degrees of immediacy:  TTY v. IM v. slower SMS v. email?  Is it the size (BW) that is of concern or is it the expectation of interactivity?  Is that what stream/message intended to convey?

Mike

At 03:53 AM 7/15/2003 -0500, Ben Campbell wrote:
Hopefully we can generalize these a bit. For example:

voice device
Mobile voice device
Fixed voice device
Workstation (or some sort of rich media device)
text device
short text device (i.e. don't send me big stuff)

This list seems to me to break down to a few dimensions:

Mobility
Media
stream/message orientation
Size limits

Which sound a lot like capabilities to me.

On Tue, 2003-07-15 at 03:38, Henning Schulzrinne wrote:
> Almost none of the labels in RPIDS are exhaustive or claim to be, so a
> list is better than nothing. To make progress, I would like to call for
> nominations for such labels. The obvious ones are device-oriented ones
>    cell phone
>    PC
>    landline phone
>    text device (BlackBerry, SMS, TTY, ...)
> other suggestions?
>
> Ben Campbell wrote:
>
> >
> > I think even that can be handled cleanly. Such a device just displays
> > some default icon that indicates it does not know what type of tuple it
> > has. That is no different from common usage in many other applications.
> > For example, email attachments when your browser does not recognize the
> > mime type, or gets something completely generic like
> > application/octet-stream without any other qualifiers.
> >
>
>
>
>
>
> _______________________________________________
> 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
--=====================_1646627==_.ALT-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 16 11:36:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06226; Wed, 16 Jul 2003 11:36:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19coKJ-0000Z2-00; Wed, 16 Jul 2003 11:36:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19coKD-0000Yv-00; Wed, 16 Jul 2003 11:36:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coK2-000253-0y; Wed, 16 Jul 2003 11:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coJj-00023q-Gb for simple@optimus.ietf.org; Wed, 16 Jul 2003 11:35:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06217 for ; Wed, 16 Jul 2003 11:35:39 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19coJi-0000Yo-00 for simple@ietf.org; Wed, 16 Jul 2003 11:35:42 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19coJX-0000Yh-00 for simple@ietf.org; Wed, 16 Jul 2003 11:35:31 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GFZ5B27558 for ; Wed, 16 Jul 2003 18:35:05 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jul 2003 18:35:05 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 18:35:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] A proposal for xcap direction Message-ID: Thread-Topic: [Simple] A proposal for xcap direction Thread-Index: AcNLehcgXG1GJtPhQIyE0eEHQVgzqgANDnbQ To: , Cc: X-OriginalArrivalTime: 16 Jul 2003 15:35:05.0072 (UTC) FILETIME=[D45CD700:01C34BAF] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Jul 2003 18:35:04 +0300 Content-Transfer-Encoding: quoted-printable Hi, I also think that this direction seems reasonable. Partial updates are = important, but it is enough to be able to just divide the whole data = into reasonably small chunks which could be individually updated. I also = believe that the XML schema can be designed so that the typical updates = that need to be atomic can be reasonably small. Also the timing of this work is very important. It would be good to get = the basic XCAP specs not too long after PUBLISH and MSRP, so that the = first _standards based_ SIP IM & Presence solutions could also use = standardized data manipulation. For instance I don't believe that it = would make sense to put SIP IM & P in the wireless terminals (for "mass = market") before XCAP gets to RFC. Another comment I have is that we could still at least TRY to simplify = the baseline solution for presence authorization. Hopefully the most = complex rules could be left as optional extensions.=20 Markus=20 > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 16 July, 2003 12:05 > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] A proposal for xcap direction >=20 >=20 > I'm all for minimal functionality and a single mechanism. >=20 > Since we only need a small subset of the functionality of XPath=20 > functionality, it seems easier to just have atomic units as=20 > part of the=20 > path. This also avoids having to worry about micro-manipulation of=20 > individual elements and simplifies server implementation. In=20 > the simpler=20 > implementation, you can simply have an XML parser for each unit and=20 > store it internally as a database or some other more=20 > appropriate format.=20 > If you allow random element-level modification, you have to=20 > keep the DOM=20 > representation around and have to make sure that things that can't=20 > easily be modified in one step are consistent and valid in=20 > intermediate=20 > steps. >=20 > Jonathan Rosenberg wrote: >=20 > > Folks, > >=20 > > During the IETF meeting, I put forward a strawman proposal on a=20 > > direction for xcap. The strawman is motivated by some important=20 > > observations: > >=20 > > 1. If xcap is anything except for an obvious http usage, it=20 > will require=20 > > broader ietf input. Such input, through a design team, for example,=20 > > would probably add a year (plus or minus 6 months) to the work. > >=20 > > 2. Whats REALLY important to us is the schema - how we are=20 > representing=20 > > authorization policies and buddy lists. How such data is=20 > transported=20 > > from a client to the server is less important to us. Its=20 > also not really=20 > > our core competency. > >=20 > > Based on this, I would propose a substantial descoping of XCAP. In=20 > > particular, I would propose that: > >=20 > > 1. We do not address batching or transactions. That is, you=20 > won't be=20 > > able to lock a list or auth policy, make a bunch of=20 > modifications, and=20 > > then unlock. Is this a fatal loss of functionality? No. It=20 > turns out=20 > > that if you are careful about how you design the schema,=20 > you will be=20 > > able to ensure that most of the things you want to do can=20 > be done with a=20 > > single GET/modify/PUT operation. > >=20 > > Here's an example. > >=20 > > One of the big concerns we had was moving a user from a=20 > white list to a=20 > > black list. That requires two steps - (1) remove the user=20 > from the white=20 > > list, and then (2) add the user to the black list. There is an=20 > > intermediate state thats bad - the user is on neither list.=20 > This concern=20 > > is based on the assumption that the authorization policy is=20 > structured=20 > > as white and black lists. If you look at the xcap=20 > authorization usage,=20 > > you find thats not true. Its structured (basically) as a list of=20 > > watchers, and for each one, permissions for that watcher.=20 > To achieve the=20 > > effect of moving the user from a while list to a black=20 > list, you would=20 > > delete the permission for that user. This=20 > operation can be done=20 > > in a single DELETE operation. Thus, no locking is needed. > >=20 > > In fact, I was careful in the construction of the=20 > authorization schema=20 > > to make sure that most of what I think we need to do is=20 > doable in one=20 > > shot operations. I accomplished this by making the=20 > authorization policy=20 > > structured as a list of statements, where each statement=20 > applies to one=20 > > or more watchers. Each statement is a list of permissions,=20 > which grants=20 > > the ability to get or receive something. Permissions are=20 > positive - they=20 > > always grant something, never deny something. Its the mix=20 > of positive=20 > > and negative things which requires two-step operations to ensure=20 > > consistency, and I avoided them. > >=20 > > 2. Every operation is a PUT. No POST. The IETF has established=20 > > guidelines for usage of HTTP as a substrate for other=20 > protocols. One of=20 > > the tell-tale signs of misuse is that you are using POST as=20 > a way to=20 > > tunnel operations. POST has a well defined semantic - you=20 > are sending=20 > > form data to a process that uses the data as input. In the=20 > current xcap=20 > > draft, the POST operation is used to insert a new element,=20 > whereas PUT=20 > > is used to modify an existing one. We need to only use PUT,=20 > since there=20 > > really is no form processing engine here. However, we still need an=20 > > insert and a modify operation. How to do that? > >=20 > > Well, the proposed direction gives us the answer. How does=20 > HTTP support=20 > > it? Simple. If you PUT a document to a URI that represents=20 > a resource=20 > > that exists, the resource is replaced. If you PUT a=20 > document to a URI=20 > > that doesnt exist, the resource is created (i.e.,=20 > inserted). Now, our=20 > > main problem is that there is no way to specify WHERE the=20 > new resource=20 > > gets inserted within the "directory". For regular=20 > filesystems, it doesnt=20 > > matter. For us, it does. So, we will have a constraint that=20 > if you do an=20 > > insert operation on an XML element, you have to do it in a=20 > place where=20 > > either (1) the positioning is implied by the schema, or (2) the=20 > > positioning isnt important. Again, this just means careful schema=20 > > design. You will note that in both the authorization usage=20 > and buddy=20 > > list usage, there are many key points in the schema where=20 > you can insert=20 > > things where either the ordering is dictated or not important. > >=20 > > 3. We remove the ability to have server computed data (not=20 > possible with=20 > > PUT). That means that creating a buddy list requires the client to=20 > > either (1) select the URI so its unique, (2) obtain the URI=20 > through some=20 > > other means, (3) put the data without a URI, have the=20 > server set the=20 > > URI, and then have the client fetch the data with the URI=20 > filled in.=20 > > None of them are pretty. Its a limitation with the approach. > >=20 > > 3. We may be able to keep the ability to have servers enforce data=20 > > constraints that the schema cannot represent. Not sure its useful. > >=20 > > 4. We pursue a longer term solution of working with webdav=20 > by adding=20 > > partial patches through some kind of webdav extension. This=20 > would be=20 > > xcap 2.0. > >=20 > >=20 > >=20 > > During the meeting, there was good support for this. Ted=20 > gave some good=20 > > input. His idea was to take it a step furhter and eliminate=20 > xpath. The=20 > > suggestion was to obtain partial updates by treating each=20 > buddy or each=20 > > watcher permission as a separate http resource. This amounts to=20 > > declaring specific "breakpoints" in the current schemas=20 > which represent=20 > > the atomic units we will operate on. I need to mull that=20 > over some more=20 > > to see if it works. More on that when I have a concrete=20 > opinion on it. > >=20 > > However, I did want to solicit input from the working group=20 > on the list=20 > > about this direction. So, please comment or ask questions. > >=20 > > Thanks, > > Jonathan R. >=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 exim@www1.ietf.org Wed Jul 16 11:36:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06251 for ; Wed, 16 Jul 2003 11:36:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coKL-00028X-2u for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 11:36:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GFaL5e008213 for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 11:36:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coKK-00028O-To for simple-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 11:36:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06226; Wed, 16 Jul 2003 11:36:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19coKJ-0000Z2-00; Wed, 16 Jul 2003 11:36:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19coKD-0000Yv-00; Wed, 16 Jul 2003 11:36:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coK2-000253-0y; Wed, 16 Jul 2003 11:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coJj-00023q-Gb for simple@optimus.ietf.org; Wed, 16 Jul 2003 11:35:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06217 for ; Wed, 16 Jul 2003 11:35:39 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19coJi-0000Yo-00 for simple@ietf.org; Wed, 16 Jul 2003 11:35:42 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19coJX-0000Yh-00 for simple@ietf.org; Wed, 16 Jul 2003 11:35:31 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GFZ5B27558 for ; Wed, 16 Jul 2003 18:35:05 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jul 2003 18:35:05 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 18:35:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] A proposal for xcap direction Message-ID: Thread-Topic: [Simple] A proposal for xcap direction Thread-Index: AcNLehcgXG1GJtPhQIyE0eEHQVgzqgANDnbQ To: , Cc: X-OriginalArrivalTime: 16 Jul 2003 15:35:05.0072 (UTC) FILETIME=[D45CD700:01C34BAF] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Jul 2003 18:35:04 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I also think that this direction seems reasonable. Partial updates are = important, but it is enough to be able to just divide the whole data = into reasonably small chunks which could be individually updated. I also = believe that the XML schema can be designed so that the typical updates = that need to be atomic can be reasonably small. Also the timing of this work is very important. It would be good to get = the basic XCAP specs not too long after PUBLISH and MSRP, so that the = first _standards based_ SIP IM & Presence solutions could also use = standardized data manipulation. For instance I don't believe that it = would make sense to put SIP IM & P in the wireless terminals (for "mass = market") before XCAP gets to RFC. Another comment I have is that we could still at least TRY to simplify = the baseline solution for presence authorization. Hopefully the most = complex rules could be left as optional extensions.=20 Markus=20 > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 16 July, 2003 12:05 > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] A proposal for xcap direction >=20 >=20 > I'm all for minimal functionality and a single mechanism. >=20 > Since we only need a small subset of the functionality of XPath=20 > functionality, it seems easier to just have atomic units as=20 > part of the=20 > path. This also avoids having to worry about micro-manipulation of=20 > individual elements and simplifies server implementation. In=20 > the simpler=20 > implementation, you can simply have an XML parser for each unit and=20 > store it internally as a database or some other more=20 > appropriate format.=20 > If you allow random element-level modification, you have to=20 > keep the DOM=20 > representation around and have to make sure that things that can't=20 > easily be modified in one step are consistent and valid in=20 > intermediate=20 > steps. >=20 > Jonathan Rosenberg wrote: >=20 > > Folks, > >=20 > > During the IETF meeting, I put forward a strawman proposal on a=20 > > direction for xcap. The strawman is motivated by some important=20 > > observations: > >=20 > > 1. If xcap is anything except for an obvious http usage, it=20 > will require=20 > > broader ietf input. Such input, through a design team, for example,=20 > > would probably add a year (plus or minus 6 months) to the work. > >=20 > > 2. Whats REALLY important to us is the schema - how we are=20 > representing=20 > > authorization policies and buddy lists. How such data is=20 > transported=20 > > from a client to the server is less important to us. Its=20 > also not really=20 > > our core competency. > >=20 > > Based on this, I would propose a substantial descoping of XCAP. In=20 > > particular, I would propose that: > >=20 > > 1. We do not address batching or transactions. That is, you=20 > won't be=20 > > able to lock a list or auth policy, make a bunch of=20 > modifications, and=20 > > then unlock. Is this a fatal loss of functionality? No. It=20 > turns out=20 > > that if you are careful about how you design the schema,=20 > you will be=20 > > able to ensure that most of the things you want to do can=20 > be done with a=20 > > single GET/modify/PUT operation. > >=20 > > Here's an example. > >=20 > > One of the big concerns we had was moving a user from a=20 > white list to a=20 > > black list. That requires two steps - (1) remove the user=20 > from the white=20 > > list, and then (2) add the user to the black list. There is an=20 > > intermediate state thats bad - the user is on neither list.=20 > This concern=20 > > is based on the assumption that the authorization policy is=20 > structured=20 > > as white and black lists. If you look at the xcap=20 > authorization usage,=20 > > you find thats not true. Its structured (basically) as a list of=20 > > watchers, and for each one, permissions for that watcher.=20 > To achieve the=20 > > effect of moving the user from a while list to a black=20 > list, you would=20 > > delete the permission for that user. This=20 > operation can be done=20 > > in a single DELETE operation. Thus, no locking is needed. > >=20 > > In fact, I was careful in the construction of the=20 > authorization schema=20 > > to make sure that most of what I think we need to do is=20 > doable in one=20 > > shot operations. I accomplished this by making the=20 > authorization policy=20 > > structured as a list of statements, where each statement=20 > applies to one=20 > > or more watchers. Each statement is a list of permissions,=20 > which grants=20 > > the ability to get or receive something. Permissions are=20 > positive - they=20 > > always grant something, never deny something. Its the mix=20 > of positive=20 > > and negative things which requires two-step operations to ensure=20 > > consistency, and I avoided them. > >=20 > > 2. Every operation is a PUT. No POST. The IETF has established=20 > > guidelines for usage of HTTP as a substrate for other=20 > protocols. One of=20 > > the tell-tale signs of misuse is that you are using POST as=20 > a way to=20 > > tunnel operations. POST has a well defined semantic - you=20 > are sending=20 > > form data to a process that uses the data as input. In the=20 > current xcap=20 > > draft, the POST operation is used to insert a new element,=20 > whereas PUT=20 > > is used to modify an existing one. We need to only use PUT,=20 > since there=20 > > really is no form processing engine here. However, we still need an=20 > > insert and a modify operation. How to do that? > >=20 > > Well, the proposed direction gives us the answer. How does=20 > HTTP support=20 > > it? Simple. If you PUT a document to a URI that represents=20 > a resource=20 > > that exists, the resource is replaced. If you PUT a=20 > document to a URI=20 > > that doesnt exist, the resource is created (i.e.,=20 > inserted). Now, our=20 > > main problem is that there is no way to specify WHERE the=20 > new resource=20 > > gets inserted within the "directory". For regular=20 > filesystems, it doesnt=20 > > matter. For us, it does. So, we will have a constraint that=20 > if you do an=20 > > insert operation on an XML element, you have to do it in a=20 > place where=20 > > either (1) the positioning is implied by the schema, or (2) the=20 > > positioning isnt important. Again, this just means careful schema=20 > > design. You will note that in both the authorization usage=20 > and buddy=20 > > list usage, there are many key points in the schema where=20 > you can insert=20 > > things where either the ordering is dictated or not important. > >=20 > > 3. We remove the ability to have server computed data (not=20 > possible with=20 > > PUT). That means that creating a buddy list requires the client to=20 > > either (1) select the URI so its unique, (2) obtain the URI=20 > through some=20 > > other means, (3) put the data without a URI, have the=20 > server set the=20 > > URI, and then have the client fetch the data with the URI=20 > filled in.=20 > > None of them are pretty. Its a limitation with the approach. > >=20 > > 3. We may be able to keep the ability to have servers enforce data=20 > > constraints that the schema cannot represent. Not sure its useful. > >=20 > > 4. We pursue a longer term solution of working with webdav=20 > by adding=20 > > partial patches through some kind of webdav extension. This=20 > would be=20 > > xcap 2.0. > >=20 > >=20 > >=20 > > During the meeting, there was good support for this. Ted=20 > gave some good=20 > > input. His idea was to take it a step furhter and eliminate=20 > xpath. The=20 > > suggestion was to obtain partial updates by treating each=20 > buddy or each=20 > > watcher permission as a separate http resource. This amounts to=20 > > declaring specific "breakpoints" in the current schemas=20 > which represent=20 > > the atomic units we will operate on. I need to mull that=20 > over some more=20 > > to see if it works. More on that when I have a concrete=20 > opinion on it. > >=20 > > However, I did want to solicit input from the working group=20 > on the list=20 > > about this direction. So, please comment or ask questions. > >=20 > > Thanks, > > Jonathan R. >=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-admin@ietf.org Wed Jul 16 14:56:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12606; Wed, 16 Jul 2003 14:56:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crRi-0002Df-00; Wed, 16 Jul 2003 14:56:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19crRd-0002Dc-00; Wed, 16 Jul 2003 14:56:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crRY-0006bH-Tz; Wed, 16 Jul 2003 14:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crRW-0006av-AT for simple@optimus.ietf.org; Wed, 16 Jul 2003 14:55:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12603 for ; Wed, 16 Jul 2003 14:55:53 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crRT-0002DW-00 for simple@ietf.org; Wed, 16 Jul 2003 14:55:55 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19crRI-0002DM-00 for simple@ietf.org; Wed, 16 Jul 2003 14:55:44 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GItNB24175 for ; Wed, 16 Jul 2003 21:55:23 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jul 2003 21:55:23 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 21:55:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] A proposal for xcap direction Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F19@esebe019.ntc.nokia.com> Thread-Topic: [Simple] A proposal for xcap direction Thread-Index: AcNLZu/0FujKHHiVRWecIJ+Xi26+IQAYvzVw To: , X-OriginalArrivalTime: 16 Jul 2003 18:55:23.0223 (UTC) FILETIME=[CFBD2670:01C34BCB] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Jul 2003 21:55:22 +0300 Content-Transfer-Encoding: quoted-printable We need a solution for data manipulation soon, if this is what it takes = to do it, then I say go for it. I have some comments/questions inline... > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, July 16, 2003 3:02 AM > To: Simple WG > Subject: [Simple] A proposal for xcap direction >=20 >=20 > Folks, >=20 > During the IETF meeting, I put forward a strawman proposal on a=20 > direction for xcap. The strawman is motivated by some important=20 > observations: >=20 > 1. If xcap is anything except for an obvious http usage, it will=20 > require broader ietf input. Such input, through a design team, for=20 > example, would probably add a year (plus or minus 6 months)=20 > to the work. >=20 > 2. Whats REALLY important to us is the schema - how we are=20 > representing authorization policies and buddy lists. How such data is=20 > transported from a client to the server is less important to us. Its=20 > also not really our core competency. >=20 > Based on this, I would propose a substantial descoping of XCAP. In=20 > particular, I would propose that: >=20 > 1. We do not address batching or transactions. That is, you won't be=20 > able to lock a list or auth policy, make a bunch of=20 > modifications, and=20 > then unlock. Is this a fatal loss of functionality? No. It turns out=20 > that if you are careful about how you design the schema, you will be=20 > able to ensure that most of the things you want to do can be=20 > done with=20 > a single GET/modify/PUT operation. This is a good point to remember even with XCAP 2.0. Designers and = reviewers of schemas should keep that in mind. >=20 > Here's an example. >=20 > One of the big concerns we had was moving a user from a white list to=20 > a black list. That requires two steps - (1) remove the user from the=20 > white list, and then (2) add the user to the black list. There is an=20 > intermediate state thats bad - the user is on neither list. This=20 > concern is based on the assumption that the authorization policy is=20 > structured as white and black lists. If you look at the xcap=20 > authorization usage, you find thats not true. Its structured=20 > (basically) as a list of watchers, and for each one, permissions for=20 > that watcher. To achieve the effect of moving the user from a while=20 > list to a black list, you would delete the permission for=20 > that user. This operation can be done in a single DELETE operation.=20 > Thus, no locking is needed. >=20 > In fact, I was careful in the construction of the=20 > authorization schema=20 > to make sure that most of what I think we need to do is doable in one=20 > shot operations. I accomplished this by making the authorization=20 > policy structured as a list of statements, where each statement=20 > applies to one or more watchers. Each statement is a list of=20 > permissions, which grants the ability to get or receive something.=20 > Permissions are positive - they always grant something, never deny=20 > something. Its the mix of positive and negative things which requires=20 > two-step operations to ensure consistency, and I avoided them. >=20 > 2. Every operation is a PUT. No POST. The IETF has established=20 > guidelines for usage of HTTP as a substrate for other protocols. One=20 > of the tell-tale signs of misuse is that you are using POST as a way=20 > to tunnel operations. POST has a well defined semantic - you are=20 > sending form data to a process that uses the data as input. In the=20 > current xcap draft, the POST operation is used to insert a new=20 > element, whereas PUT is used to modify an existing one. We need to=20 > only use PUT, since there really is no form processing engine here.=20 > However, we still need an insert and a modify operation. How=20 > to do that? >=20 > Well, the proposed direction gives us the answer. How does HTTP=20 > support it? Simple. If you PUT a document to a URI that represents a=20 > resource that exists, the resource is replaced. If you PUT a document=20 > to a URI that doesnt exist, the resource is created (i.e., inserted).=20 > Now, our main problem is that there is no way to specify=20 > WHERE the new=20 > resource gets inserted within the "directory". For regular=20 > filesystems, it doesnt matter. For us, it does. So, we will have a=20 > constraint that if you do an insert operation on an XML element, you=20 > have to do it in a place where either (1) the positioning is implied=20 > by the schema, or (2) the positioning isnt important. Again,=20 > this just=20 > means careful schema design. You will note that in both the=20 > authorization usage and buddy list usage, there are many key=20 > points in=20 > the schema where you can insert things where either the ordering is=20 > dictated or not important. I'm confused. Are you talking about PUTting a document or an XML = element? I thought the XML element is inserted in the location pointed = to bu the XPATH expression. >=20 > 3. We remove the ability to have server computed data (not possible=20 > with PUT). That means that creating a buddy list requires the client=20 > to either (1) select the URI so its unique, (2) obtain the=20 > URI through=20 > some other means, (3) put the data without a URI, have the server set=20 > the URI, and then have the client fetch the data with the URI filled=20 > in. None of them are pretty. Its a limitation with the approach. I thought option 3 was the server computed data. What is different? >=20 > 3. We may be able to keep the ability to have servers enforce data=20 > constraints that the schema cannot represent. Not sure its useful. It might be useful. Cases are that you have 2 elements, both are = optional, but at least one MUST exist. I don't think you can do that = with schema. >=20 > 4. We pursue a longer term solution of working with webdav by adding=20 > partial patches through some kind of webdav extension. This would be=20 > xcap 2.0. I fear that this might take longer than 1 year, maily due to the fact = that we will have version 1.0 that everyone is deploying and are not = interested in v2.0 for a while to come. Regards, Hisham >=20 >=20 >=20 > During the meeting, there was good support for this. Ted gave some=20 > good input. His idea was to take it a step furhter and eliminate=20 > xpath. The suggestion was to obtain partial updates by treating each=20 > buddy or each watcher permission as a separate http resource. This=20 > amounts to declaring specific "breakpoints" in the current schemas=20 > which represent the atomic units we will operate on. I need to mull=20 > that over some more to see if it works. More on that when I have a=20 > concrete opinion on it. >=20 > However, I did want to solicit input from the working group on the=20 > list about this direction. So, please comment or ask questions. >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=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 exim@www1.ietf.org Wed Jul 16 14:56:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12629 for ; Wed, 16 Jul 2003 14:56:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crRq-0006eg-PR for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 14:56:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GIuIRC025582 for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 14:56:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crRq-0006eX-MY for simple-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 14:56:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12606; Wed, 16 Jul 2003 14:56:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crRi-0002Df-00; Wed, 16 Jul 2003 14:56:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19crRd-0002Dc-00; Wed, 16 Jul 2003 14:56:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crRY-0006bH-Tz; Wed, 16 Jul 2003 14:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crRW-0006av-AT for simple@optimus.ietf.org; Wed, 16 Jul 2003 14:55:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12603 for ; Wed, 16 Jul 2003 14:55:53 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crRT-0002DW-00 for simple@ietf.org; Wed, 16 Jul 2003 14:55:55 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19crRI-0002DM-00 for simple@ietf.org; Wed, 16 Jul 2003 14:55:44 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GItNB24175 for ; Wed, 16 Jul 2003 21:55:23 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jul 2003 21:55:23 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 21:55:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] A proposal for xcap direction Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F19@esebe019.ntc.nokia.com> Thread-Topic: [Simple] A proposal for xcap direction Thread-Index: AcNLZu/0FujKHHiVRWecIJ+Xi26+IQAYvzVw To: , X-OriginalArrivalTime: 16 Jul 2003 18:55:23.0223 (UTC) FILETIME=[CFBD2670:01C34BCB] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Jul 2003 21:55:22 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable We need a solution for data manipulation soon, if this is what it takes = to do it, then I say go for it. I have some comments/questions inline... > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, July 16, 2003 3:02 AM > To: Simple WG > Subject: [Simple] A proposal for xcap direction >=20 >=20 > Folks, >=20 > During the IETF meeting, I put forward a strawman proposal on a=20 > direction for xcap. The strawman is motivated by some important=20 > observations: >=20 > 1. If xcap is anything except for an obvious http usage, it will=20 > require broader ietf input. Such input, through a design team, for=20 > example, would probably add a year (plus or minus 6 months)=20 > to the work. >=20 > 2. Whats REALLY important to us is the schema - how we are=20 > representing authorization policies and buddy lists. How such data is=20 > transported from a client to the server is less important to us. Its=20 > also not really our core competency. >=20 > Based on this, I would propose a substantial descoping of XCAP. In=20 > particular, I would propose that: >=20 > 1. We do not address batching or transactions. That is, you won't be=20 > able to lock a list or auth policy, make a bunch of=20 > modifications, and=20 > then unlock. Is this a fatal loss of functionality? No. It turns out=20 > that if you are careful about how you design the schema, you will be=20 > able to ensure that most of the things you want to do can be=20 > done with=20 > a single GET/modify/PUT operation. This is a good point to remember even with XCAP 2.0. Designers and = reviewers of schemas should keep that in mind. >=20 > Here's an example. >=20 > One of the big concerns we had was moving a user from a white list to=20 > a black list. That requires two steps - (1) remove the user from the=20 > white list, and then (2) add the user to the black list. There is an=20 > intermediate state thats bad - the user is on neither list. This=20 > concern is based on the assumption that the authorization policy is=20 > structured as white and black lists. If you look at the xcap=20 > authorization usage, you find thats not true. Its structured=20 > (basically) as a list of watchers, and for each one, permissions for=20 > that watcher. To achieve the effect of moving the user from a while=20 > list to a black list, you would delete the permission for=20 > that user. This operation can be done in a single DELETE operation.=20 > Thus, no locking is needed. >=20 > In fact, I was careful in the construction of the=20 > authorization schema=20 > to make sure that most of what I think we need to do is doable in one=20 > shot operations. I accomplished this by making the authorization=20 > policy structured as a list of statements, where each statement=20 > applies to one or more watchers. Each statement is a list of=20 > permissions, which grants the ability to get or receive something.=20 > Permissions are positive - they always grant something, never deny=20 > something. Its the mix of positive and negative things which requires=20 > two-step operations to ensure consistency, and I avoided them. >=20 > 2. Every operation is a PUT. No POST. The IETF has established=20 > guidelines for usage of HTTP as a substrate for other protocols. One=20 > of the tell-tale signs of misuse is that you are using POST as a way=20 > to tunnel operations. POST has a well defined semantic - you are=20 > sending form data to a process that uses the data as input. In the=20 > current xcap draft, the POST operation is used to insert a new=20 > element, whereas PUT is used to modify an existing one. We need to=20 > only use PUT, since there really is no form processing engine here.=20 > However, we still need an insert and a modify operation. How=20 > to do that? >=20 > Well, the proposed direction gives us the answer. How does HTTP=20 > support it? Simple. If you PUT a document to a URI that represents a=20 > resource that exists, the resource is replaced. If you PUT a document=20 > to a URI that doesnt exist, the resource is created (i.e., inserted).=20 > Now, our main problem is that there is no way to specify=20 > WHERE the new=20 > resource gets inserted within the "directory". For regular=20 > filesystems, it doesnt matter. For us, it does. So, we will have a=20 > constraint that if you do an insert operation on an XML element, you=20 > have to do it in a place where either (1) the positioning is implied=20 > by the schema, or (2) the positioning isnt important. Again,=20 > this just=20 > means careful schema design. You will note that in both the=20 > authorization usage and buddy list usage, there are many key=20 > points in=20 > the schema where you can insert things where either the ordering is=20 > dictated or not important. I'm confused. Are you talking about PUTting a document or an XML = element? I thought the XML element is inserted in the location pointed = to bu the XPATH expression. >=20 > 3. We remove the ability to have server computed data (not possible=20 > with PUT). That means that creating a buddy list requires the client=20 > to either (1) select the URI so its unique, (2) obtain the=20 > URI through=20 > some other means, (3) put the data without a URI, have the server set=20 > the URI, and then have the client fetch the data with the URI filled=20 > in. None of them are pretty. Its a limitation with the approach. I thought option 3 was the server computed data. What is different? >=20 > 3. We may be able to keep the ability to have servers enforce data=20 > constraints that the schema cannot represent. Not sure its useful. It might be useful. Cases are that you have 2 elements, both are = optional, but at least one MUST exist. I don't think you can do that = with schema. >=20 > 4. We pursue a longer term solution of working with webdav by adding=20 > partial patches through some kind of webdav extension. This would be=20 > xcap 2.0. I fear that this might take longer than 1 year, maily due to the fact = that we will have version 1.0 that everyone is deploying and are not = interested in v2.0 for a while to come. Regards, Hisham >=20 >=20 >=20 > During the meeting, there was good support for this. Ted gave some=20 > good input. His idea was to take it a step furhter and eliminate=20 > xpath. The suggestion was to obtain partial updates by treating each=20 > buddy or each watcher permission as a separate http resource. This=20 > amounts to declaring specific "breakpoints" in the current schemas=20 > which represent the atomic units we will operate on. I need to mull=20 > that over some more to see if it works. More on that when I have a=20 > concrete opinion on it. >=20 > However, I did want to solicit input from the working group on the=20 > list about this direction. So, please comment or ask questions. >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=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-admin@ietf.org Wed Jul 16 15:08:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13506; Wed, 16 Jul 2003 15:08:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crdJ-0002N0-00; Wed, 16 Jul 2003 15:08:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19crdD-0002Mx-00; Wed, 16 Jul 2003 15:08:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crdB-0007jm-ED; Wed, 16 Jul 2003 15:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crcx-0007i7-Uh for simple@optimus.ietf.org; Wed, 16 Jul 2003 15:07:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13460 for ; Wed, 16 Jul 2003 15:07:42 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crcu-0002Mb-00 for simple@ietf.org; Wed, 16 Jul 2003 15:07:44 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19crcj-0002MW-00 for simple@ietf.org; Wed, 16 Jul 2003 15:07:34 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GJ7RB03741 for ; Wed, 16 Jul 2003 22:07:27 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jul 2003 22:07:27 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 22:07:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F1A@esebe019.ntc.nokia.com> Thread-Topic: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Thread-Index: AcNLZE4pB8E73Rk5SjaCLbHveIzakwAaH3sA To: , Cc: , , X-OriginalArrivalTime: 16 Jul 2003 19:07:27.0528 (UTC) FILETIME=[7F755280:01C34BCD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Jul 2003 22:07:27 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, July 16, 2003 1:19 AM > To: Jonathan Rosenberg > Cc: Robert Sparks; Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: > atomicity problem >=20 >=20 > I generally like this idea, but maybe it is still too complex. >=20 > Why do we need the Pstream-ID? Simply say each publisher must choose=20 > unique tuple ids and leave it at that. >=20 > Regarding how to set up blocking of the ones you don't want,=20 > instead of=20 > pstream, how about simply having each publisher include its=20 > identity in=20 > each tuple, as an attribute? This could be filtered out for=20 > most users. tuple is presence specific. I was thinking of a time-stamp type header = (for presence, it probably carries the same info as in the time-stamp = element). But then Jonathan mentioned deleting a tuple. Hisham >=20 > Paul >=20 > Jonathan Rosenberg wrote: > > I was about to post a note on agreeing with Aki. I was=20 > also going to=20 > > say that we might want the body to also be the atomic unit,=20 > so that when=20 > > you publish a tuple, the body is an XML fragment for the=20 > tuple. Then, it=20 > > ocurred to me that we were really far down the complexity=20 > ramp here. So,=20 > > I thought about what we could do to really back out of this mess=20 > > entirely. Here is my idea. > >=20 > > In the beginning, PUBLISH was easy. Each PUA published its=20 > own view of=20 > > the presence of the presentity. It had no knowledge of=20 > other PUA. It=20 > > published a complete presence document which represented=20 > what it thought=20 > > was the full presence of the presentity. Indeed, if there=20 > was only one=20 > > PUA, it would be the full presence of the presentity. There=20 > was no way=20 > > for one PUA to overwrite the published data from another.=20 > The tuple IDs=20 > > didn't need to have cross-PUA scope. No naming conventions=20 > or anything.=20 > > The compositor could combine these and modify them as it=20 > chose. Each=20 > > represented a unique and different piece of info about the=20 > presentity. A=20 > > useful bit of information was this "Pstream-ID", which uniquely=20 > > identified the publisher. You can think of the Pstream-ID=20 > as a way of=20 > > scoping the tuple IDs. Each tuple ID is defined only within=20 > the scope of=20 > > a Pstream-ID, and each publisher has to have a unique PStream-ID. > >=20 > > It all got complicated when we decided to try and solve a bigger=20 > > problem, where PUA could override information about other PUA. That=20 > > introduced all kinds of problems. We needed to define the atomic=20 > > information of published presence. We need to resolve tuple=20 > naming. We=20 > > need to worry about this issue about whether a publish has=20 > one or more=20 > > tuples. We needed to add Etags and If-Modified-Since. We=20 > need to worry=20 > > about how to figure out what it means for the system to=20 > "wait for human=20 > > input" in cases where thats not possible. We don't know how=20 > to do that yet. > >=20 > > Perhaps we should reconsider whether we want to solve this=20 > problem this=20 > > way. We have only one use case - when I leave my PC at the=20 > office with a=20 > > presence state that is wrong, and I want to fix it at home.=20 > Well, this=20 > > is a nice feature, but is it worth all of the complexity at=20 > this point?=20 > > There are other ways to deal with it. In fact, I can think of two=20 > > alternatives: > >=20 > > 1. You could use the auth policy to simply disable the PC's=20 > data from=20 > > being placed in notifications, and then publish a separate=20 > tuple (i.e.,=20 > > new piece of independent information) from home. Thats not=20 > as good (PC=20 > > still refreshes useless state), but its lots simpler than=20 > the route we=20 > > are on. > >=20 > > 2. You could design a system which only allowed one PUA at=20 > a time (akin=20 > > to the current model in AIM and YIM). This would manifest itself as=20 > > composition policy. The compositor would only use the=20 > published document=20 > > from the PUA which started publishing most recently - that=20 > is, when its=20 > > Pstream-ID first appeared. This would also achieve the effect of=20 > > disabling the work PC's state when you arrive at home. > >=20 > >=20 > > So, to be concrete, I would propose the following: > >=20 > >=20 > > 1. Publications carry complete presence documents, representing the=20 > > complete presence state of the PUA as far as it knows. > >=20 > > 2. Publishers are identified by a unique PStream-ID, chosen by the=20 > > publisher. Copying someone elses Pstream-ID is not allowed,=20 > and behavior=20 > > in this case is not defined. > >=20 > > 3. There is no ability to overwrite someone elses presence=20 > document or=20 > > their tuples. Each publisher publishes independent information. > >=20 > > 4. We eliminate the Etag, If-Modified-Since, and atomicity/segment=20 > > discussions from Publish. > >=20 > > 5. Compositors can combine the publsihed information=20 > however they like.=20 > > There is no need to carry through tuple IDs from publication to=20 > > notifications. > >=20 > > 6. If you want to block a tuple from getting into a notify,=20 > you identify=20 > > it by a distinguishing property rather than by tuple ID. > >=20 > >=20 > > I believe this approach works nicely for other things too.=20 > In the case=20 > > of winfo, where you have lots of presence servers, each=20 > publishing winfo=20 > > for the subscriptions they have, its the same. Each publisher (a=20 > > presence server), publishes the complete view of the state=20 > - its own=20 > > subscriptions. There is no overlap between servers. The compositor=20 > > combines these together using a basic policy (combine subscriptions=20 > > together that are for the same presentity), and thats it. > >=20 > > I believe it works for mwi too. > >=20 > > I really feel that it is important that we make some=20 > simplifications so=20 > > that we can make rapid progress here. I don't think we lose=20 > much since=20 > > we can still get the desired feature; we just get it in a=20 > different way. > >=20 > > Thoughts? > >=20 > > -Jonathan R. > >=20 > > Robert Sparks wrote: > >=20 > >> Another way to state this conclusion is that we need to report > >> success or failure of publishing each atomic element in an=20 > independent > >> fashion. One quick and easy way to achieve that property=20 > is to allow > >> only one atomic element per PUBLISH request. > >> > >> I think I heard another way to do this mentioned during=20 > the meeting, > >> where we move reporting the success/failure and any feedback from > >> the attempt to publish each tuple into the message instead=20 > of trying > >> to capture it all on the status line. For example (I think this is=20 > >> what I heard suggested during the meeting), for presence, we could > >> publish an entire pidf document with several tuples and in=20 > the presence > >> response return an xml document with one element per tuple=20 > discussing > >> the disposition of attempting to publish that tuple. > >> > >> Something along the lines of the following (an example to=20 > convey the > >> concept, not a proposal of a syntax) > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> If we were to pursue such an optimization, it might make sense to > >> look at how to specify a separate etag value in the=20 > publish (currently > >> what we put in an If-Match header) for each atom in the published > >> document. > >> > >> RjS > >> > >> On Mon, 2003-07-14 at 19:58, aki.niemi@nokia.com wrote: > >> > >>> All, > >>> > >>> I'll try to summarize the issues w.r.t. the atomicity of=20 > publication=20 > >>> here in an attempt to converge the discussion towards a=20 > solution to=20 > >>> this problem. BTW, I realized that my slides in the=20 > SIMPLE session=20 > >>> were perhaps not crystal clear on what the problem at hand really=20 > >>> was, so my apologies for that. > >>> > >>> The core problem is this: > >>> EPA X sends a PUBLISH with {a, b, c}, after which EPA Y=20 > publishes {a,=20 > >>> b}. When EPA X tries to refresh its publication of {a, b, c}, the=20 > >>> request fails because of a collision, resulting in the EPA X=20 > >>> quitting. EPA Y still refreshes its publication of {a, b}, which=20 > >>> means {c} expires and goes away. As a result, the=20 > publication process=20 > >>> has lost information of {c}. This is unacceptable, and with the=20 > >>> current versioning mechanism, this can't be remedied by composer=20 > >>> policy, for example. > >>> > >>> Instead, to get around the above problem, what you send=20 > in a PUBLISH=20 > >>> needs to match the atomic element of the published=20 > information. So=20 > >>> each PUBLISH needs to contain a single tuple, because the=20 > versioning=20 > >>> and expiration all work on the single atomic element level anyway. > >>> > >>> This has the apparent drawback in that the PUA has to=20 > wait for a 200=20 > >>> OK after each PUBLISHed tuple before it can PUBLISH the next one.=20 > >>> This occurs upon every refresh cycle, and in systems with high=20 > >>> latency, may become a major issue in terms of performance. > >>> > >>> Ways to get around this inefficiency: > >>> - Remove the restriction on overlapping requests, i.e., allow=20 > >>> "pipelining" > >>> of PUBLISH requests > >>> - Treat the publisher of each tuple as a separate EPA, and=20 > >>> therefore not > >>> subject to this restriction in the first place (seems like=20 > >>> cheating...) > >>> In conclusion, my proposal is to go with having always a=20 > single tuple=20 > >>> in a PUBLISH, and allow overlapping PUBLISH requests. To my=20 > >>> knowledge, this would fulfill all the related=20 > requirements and solve=20 > >>> the issue. > >>> > >>> Thoughts? > >>> > >>> Cheers, > >>> Aki > >>> > >>> _______________________________________________ > >>> Simple mailing list > >>> Simple@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/simple > >> > >> > >> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > >> > >=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 exim@www1.ietf.org Wed Jul 16 15:08:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13579 for ; Wed, 16 Jul 2003 15:08:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crdN-0007oP-PA for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 15:08:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GJ8DAX030021 for simple-archive@odin.ietf.org; Wed, 16 Jul 2003 15:08:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crdM-0007o6-TL for simple-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 15:08:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13506; Wed, 16 Jul 2003 15:08:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crdJ-0002N0-00; Wed, 16 Jul 2003 15:08:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19crdD-0002Mx-00; Wed, 16 Jul 2003 15:08:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crdB-0007jm-ED; Wed, 16 Jul 2003 15:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crcx-0007i7-Uh for simple@optimus.ietf.org; Wed, 16 Jul 2003 15:07:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13460 for ; Wed, 16 Jul 2003 15:07:42 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crcu-0002Mb-00 for simple@ietf.org; Wed, 16 Jul 2003 15:07:44 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19crcj-0002MW-00 for simple@ietf.org; Wed, 16 Jul 2003 15:07:34 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GJ7RB03741 for ; Wed, 16 Jul 2003 22:07:27 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jul 2003 22:07:27 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 22:07:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F1A@esebe019.ntc.nokia.com> Thread-Topic: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Thread-Index: AcNLZE4pB8E73Rk5SjaCLbHveIzakwAaH3sA To: , Cc: , , X-OriginalArrivalTime: 16 Jul 2003 19:07:27.0528 (UTC) FILETIME=[7F755280:01C34BCD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Jul 2003 22:07:27 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, July 16, 2003 1:19 AM > To: Jonathan Rosenberg > Cc: Robert Sparks; Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: > atomicity problem >=20 >=20 > I generally like this idea, but maybe it is still too complex. >=20 > Why do we need the Pstream-ID? Simply say each publisher must choose=20 > unique tuple ids and leave it at that. >=20 > Regarding how to set up blocking of the ones you don't want,=20 > instead of=20 > pstream, how about simply having each publisher include its=20 > identity in=20 > each tuple, as an attribute? This could be filtered out for=20 > most users. tuple is presence specific. I was thinking of a time-stamp type header = (for presence, it probably carries the same info as in the time-stamp = element). But then Jonathan mentioned deleting a tuple. Hisham >=20 > Paul >=20 > Jonathan Rosenberg wrote: > > I was about to post a note on agreeing with Aki. I was=20 > also going to=20 > > say that we might want the body to also be the atomic unit,=20 > so that when=20 > > you publish a tuple, the body is an XML fragment for the=20 > tuple. Then, it=20 > > ocurred to me that we were really far down the complexity=20 > ramp here. So,=20 > > I thought about what we could do to really back out of this mess=20 > > entirely. Here is my idea. > >=20 > > In the beginning, PUBLISH was easy. Each PUA published its=20 > own view of=20 > > the presence of the presentity. It had no knowledge of=20 > other PUA. It=20 > > published a complete presence document which represented=20 > what it thought=20 > > was the full presence of the presentity. Indeed, if there=20 > was only one=20 > > PUA, it would be the full presence of the presentity. There=20 > was no way=20 > > for one PUA to overwrite the published data from another.=20 > The tuple IDs=20 > > didn't need to have cross-PUA scope. No naming conventions=20 > or anything.=20 > > The compositor could combine these and modify them as it=20 > chose. Each=20 > > represented a unique and different piece of info about the=20 > presentity. A=20 > > useful bit of information was this "Pstream-ID", which uniquely=20 > > identified the publisher. You can think of the Pstream-ID=20 > as a way of=20 > > scoping the tuple IDs. Each tuple ID is defined only within=20 > the scope of=20 > > a Pstream-ID, and each publisher has to have a unique PStream-ID. > >=20 > > It all got complicated when we decided to try and solve a bigger=20 > > problem, where PUA could override information about other PUA. That=20 > > introduced all kinds of problems. We needed to define the atomic=20 > > information of published presence. We need to resolve tuple=20 > naming. We=20 > > need to worry about this issue about whether a publish has=20 > one or more=20 > > tuples. We needed to add Etags and If-Modified-Since. We=20 > need to worry=20 > > about how to figure out what it means for the system to=20 > "wait for human=20 > > input" in cases where thats not possible. We don't know how=20 > to do that yet. > >=20 > > Perhaps we should reconsider whether we want to solve this=20 > problem this=20 > > way. We have only one use case - when I leave my PC at the=20 > office with a=20 > > presence state that is wrong, and I want to fix it at home.=20 > Well, this=20 > > is a nice feature, but is it worth all of the complexity at=20 > this point?=20 > > There are other ways to deal with it. In fact, I can think of two=20 > > alternatives: > >=20 > > 1. You could use the auth policy to simply disable the PC's=20 > data from=20 > > being placed in notifications, and then publish a separate=20 > tuple (i.e.,=20 > > new piece of independent information) from home. Thats not=20 > as good (PC=20 > > still refreshes useless state), but its lots simpler than=20 > the route we=20 > > are on. > >=20 > > 2. You could design a system which only allowed one PUA at=20 > a time (akin=20 > > to the current model in AIM and YIM). This would manifest itself as=20 > > composition policy. The compositor would only use the=20 > published document=20 > > from the PUA which started publishing most recently - that=20 > is, when its=20 > > Pstream-ID first appeared. This would also achieve the effect of=20 > > disabling the work PC's state when you arrive at home. > >=20 > >=20 > > So, to be concrete, I would propose the following: > >=20 > >=20 > > 1. Publications carry complete presence documents, representing the=20 > > complete presence state of the PUA as far as it knows. > >=20 > > 2. Publishers are identified by a unique PStream-ID, chosen by the=20 > > publisher. Copying someone elses Pstream-ID is not allowed,=20 > and behavior=20 > > in this case is not defined. > >=20 > > 3. There is no ability to overwrite someone elses presence=20 > document or=20 > > their tuples. Each publisher publishes independent information. > >=20 > > 4. We eliminate the Etag, If-Modified-Since, and atomicity/segment=20 > > discussions from Publish. > >=20 > > 5. Compositors can combine the publsihed information=20 > however they like.=20 > > There is no need to carry through tuple IDs from publication to=20 > > notifications. > >=20 > > 6. If you want to block a tuple from getting into a notify,=20 > you identify=20 > > it by a distinguishing property rather than by tuple ID. > >=20 > >=20 > > I believe this approach works nicely for other things too.=20 > In the case=20 > > of winfo, where you have lots of presence servers, each=20 > publishing winfo=20 > > for the subscriptions they have, its the same. Each publisher (a=20 > > presence server), publishes the complete view of the state=20 > - its own=20 > > subscriptions. There is no overlap between servers. The compositor=20 > > combines these together using a basic policy (combine subscriptions=20 > > together that are for the same presentity), and thats it. > >=20 > > I believe it works for mwi too. > >=20 > > I really feel that it is important that we make some=20 > simplifications so=20 > > that we can make rapid progress here. I don't think we lose=20 > much since=20 > > we can still get the desired feature; we just get it in a=20 > different way. > >=20 > > Thoughts? > >=20 > > -Jonathan R. > >=20 > > Robert Sparks wrote: > >=20 > >> Another way to state this conclusion is that we need to report > >> success or failure of publishing each atomic element in an=20 > independent > >> fashion. One quick and easy way to achieve that property=20 > is to allow > >> only one atomic element per PUBLISH request. > >> > >> I think I heard another way to do this mentioned during=20 > the meeting, > >> where we move reporting the success/failure and any feedback from > >> the attempt to publish each tuple into the message instead=20 > of trying > >> to capture it all on the status line. For example (I think this is=20 > >> what I heard suggested during the meeting), for presence, we could > >> publish an entire pidf document with several tuples and in=20 > the presence > >> response return an xml document with one element per tuple=20 > discussing > >> the disposition of attempting to publish that tuple. > >> > >> Something along the lines of the following (an example to=20 > convey the > >> concept, not a proposal of a syntax) > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> If we were to pursue such an optimization, it might make sense to > >> look at how to specify a separate etag value in the=20 > publish (currently > >> what we put in an If-Match header) for each atom in the published > >> document. > >> > >> RjS > >> > >> On Mon, 2003-07-14 at 19:58, aki.niemi@nokia.com wrote: > >> > >>> All, > >>> > >>> I'll try to summarize the issues w.r.t. the atomicity of=20 > publication=20 > >>> here in an attempt to converge the discussion towards a=20 > solution to=20 > >>> this problem. BTW, I realized that my slides in the=20 > SIMPLE session=20 > >>> were perhaps not crystal clear on what the problem at hand really=20 > >>> was, so my apologies for that. > >>> > >>> The core problem is this: > >>> EPA X sends a PUBLISH with {a, b, c}, after which EPA Y=20 > publishes {a,=20 > >>> b}. When EPA X tries to refresh its publication of {a, b, c}, the=20 > >>> request fails because of a collision, resulting in the EPA X=20 > >>> quitting. EPA Y still refreshes its publication of {a, b}, which=20 > >>> means {c} expires and goes away. As a result, the=20 > publication process=20 > >>> has lost information of {c}. This is unacceptable, and with the=20 > >>> current versioning mechanism, this can't be remedied by composer=20 > >>> policy, for example. > >>> > >>> Instead, to get around the above problem, what you send=20 > in a PUBLISH=20 > >>> needs to match the atomic element of the published=20 > information. So=20 > >>> each PUBLISH needs to contain a single tuple, because the=20 > versioning=20 > >>> and expiration all work on the single atomic element level anyway. > >>> > >>> This has the apparent drawback in that the PUA has to=20 > wait for a 200=20 > >>> OK after each PUBLISHed tuple before it can PUBLISH the next one.=20 > >>> This occurs upon every refresh cycle, and in systems with high=20 > >>> latency, may become a major issue in terms of performance. > >>> > >>> Ways to get around this inefficiency: > >>> - Remove the restriction on overlapping requests, i.e., allow=20 > >>> "pipelining" > >>> of PUBLISH requests > >>> - Treat the publisher of each tuple as a separate EPA, and=20 > >>> therefore not > >>> subject to this restriction in the first place (seems like=20 > >>> cheating...) > >>> In conclusion, my proposal is to go with having always a=20 > single tuple=20 > >>> in a PUBLISH, and allow overlapping PUBLISH requests. To my=20 > >>> knowledge, this would fulfill all the related=20 > requirements and solve=20 > >>> the issue. > >>> > >>> Thoughts? > >>> > >>> Cheers, > >>> Aki > >>> > >>> _______________________________________________ > >>> Simple mailing list > >>> Simple@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/simple > >> > >> > >> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > >> > >=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-admin@ietf.org Thu Jul 17 04:21:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22567; Thu, 17 Jul 2003 04:21:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d40p-0002zc-00; Thu, 17 Jul 2003 04:21:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d40j-0002zZ-00; Thu, 17 Jul 2003 04:21:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d40c-00041g-1Y; Thu, 17 Jul 2003 04:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d402-00040L-Lu for simple@optimus.ietf.org; Thu, 17 Jul 2003 04:20:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22539 for ; Thu, 17 Jul 2003 04:20:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3zn-0002yO-00 for simple@ietf.org; Thu, 17 Jul 2003 04:20:11 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19d3zc-0002wZ-00 for simple@ietf.org; Thu, 17 Jul 2003 04:20:01 -0400 Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6H8I7iB011606; Thu, 17 Jul 2003 04:18:08 -0400 (EDT) Message-ID: <3F165BBA.9020500@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, rsparks@dynamicsoft.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem References: <2038BCC78B1AD641891A0D1AE133DBB701796F1A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796F1A@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 04:18:02 -0400 Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > >> -----Original Message----- From: ext Paul Kyzivat >> [mailto:pkyzivat@cisco.com] Sent: Wednesday, July 16, 2003 1:19 >> AM To: Jonathan Rosenberg Cc: Robert Sparks; Niemi Aki >> (NMP/Helsinki); simple@ietf.org Subject: Re: Rethinking scope on >> publish, was Re: [Simple] PUBLISH: atomicity problem >> >> >> I generally like this idea, but maybe it is still too complex. >> >> Why do we need the Pstream-ID? Simply say each publisher must >> choose unique tuple ids and leave it at that. >> >> Regarding how to set up blocking of the ones you don't want, >> instead of pstream, how about simply having each publisher >> include its identity in each tuple, as an attribute? This could >> be filtered out for most users. > > > tuple is presence specific. I was thinking of a time-stamp type > header (for presence, it probably carries the same info as in the > time-stamp element). But then Jonathan mentioned deleting a tuple. > My proposal is that deletion of a tuple is done using the authorization stuff. Its not a publishing issue. The ID header is needed for soft-state. If the information being published is represented by the content of the PUBLISH request, you need an identifier in there to know when a PUBLISH updates/refreshes something published previously, or its a new PUA. You cannot rely on the From field or credentials for this disambiguation, since I may have multiple devices acting on my behalf, all publishing for me, all using my credentials and identity information. I think that pstream-ID was rejected previously because we were ALSO using tuple as semantically meaningful identifiers in publication processing. I am proposing that this not be the case. The tuple IDs only have meaning within the context of the published stream (which is pretty much the same semantic they have in a notification stream). This also allows us to draw a clean line between the process of composition, which is data-type specific, and this PUBLISH mechanism, which is meant to not be specific to the data type. The "output" of the publish mechanism, towards the compositor, is a series of N published documents for a resource. The publish processor doesnt know what these documents are, or what they represent. It only knows about this pstream ID as a way of tagging them, so it can do the soft-state management necessary. Also, consider further that deletion of published documents cannot rely on some kind of data-type specific identifier, like a tuple. Thats because the PUBLISH message with Expires:0 won't have any content. So, you NEED to have an identifier in the header for this to work. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 17 04:21:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22598 for ; Thu, 17 Jul 2003 04:21:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d40s-000440-MX for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 04:21:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8LIhX015619 for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 04:21:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d40s-00043q-Hs for simple-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 04:21:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22567; Thu, 17 Jul 2003 04:21:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d40p-0002zc-00; Thu, 17 Jul 2003 04:21:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d40j-0002zZ-00; Thu, 17 Jul 2003 04:21:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d40c-00041g-1Y; Thu, 17 Jul 2003 04:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d402-00040L-Lu for simple@optimus.ietf.org; Thu, 17 Jul 2003 04:20:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22539 for ; Thu, 17 Jul 2003 04:20:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3zn-0002yO-00 for simple@ietf.org; Thu, 17 Jul 2003 04:20:11 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19d3zc-0002wZ-00 for simple@ietf.org; Thu, 17 Jul 2003 04:20:01 -0400 Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6H8I7iB011606; Thu, 17 Jul 2003 04:18:08 -0400 (EDT) Message-ID: <3F165BBA.9020500@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, rsparks@dynamicsoft.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem References: <2038BCC78B1AD641891A0D1AE133DBB701796F1A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796F1A@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 04:18:02 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > >> -----Original Message----- From: ext Paul Kyzivat >> [mailto:pkyzivat@cisco.com] Sent: Wednesday, July 16, 2003 1:19 >> AM To: Jonathan Rosenberg Cc: Robert Sparks; Niemi Aki >> (NMP/Helsinki); simple@ietf.org Subject: Re: Rethinking scope on >> publish, was Re: [Simple] PUBLISH: atomicity problem >> >> >> I generally like this idea, but maybe it is still too complex. >> >> Why do we need the Pstream-ID? Simply say each publisher must >> choose unique tuple ids and leave it at that. >> >> Regarding how to set up blocking of the ones you don't want, >> instead of pstream, how about simply having each publisher >> include its identity in each tuple, as an attribute? This could >> be filtered out for most users. > > > tuple is presence specific. I was thinking of a time-stamp type > header (for presence, it probably carries the same info as in the > time-stamp element). But then Jonathan mentioned deleting a tuple. > My proposal is that deletion of a tuple is done using the authorization stuff. Its not a publishing issue. The ID header is needed for soft-state. If the information being published is represented by the content of the PUBLISH request, you need an identifier in there to know when a PUBLISH updates/refreshes something published previously, or its a new PUA. You cannot rely on the From field or credentials for this disambiguation, since I may have multiple devices acting on my behalf, all publishing for me, all using my credentials and identity information. I think that pstream-ID was rejected previously because we were ALSO using tuple as semantically meaningful identifiers in publication processing. I am proposing that this not be the case. The tuple IDs only have meaning within the context of the published stream (which is pretty much the same semantic they have in a notification stream). This also allows us to draw a clean line between the process of composition, which is data-type specific, and this PUBLISH mechanism, which is meant to not be specific to the data type. The "output" of the publish mechanism, towards the compositor, is a series of N published documents for a resource. The publish processor doesnt know what these documents are, or what they represent. It only knows about this pstream ID as a way of tagging them, so it can do the soft-state management necessary. Also, consider further that deletion of published documents cannot rely on some kind of data-type specific identifier, like a tuple. Thats because the PUBLISH message with Expires:0 won't have any content. So, you NEED to have an identifier in the header for this to work. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 17 05:05:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24296; Thu, 17 Jul 2003 05:05:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4hM-0003XG-00; Thu, 17 Jul 2003 05:05:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d4hG-0003XC-00; Thu, 17 Jul 2003 05:05:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4hB-0007nf-S9; Thu, 17 Jul 2003 05:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4gd-0007mT-H2 for simple@optimus.ietf.org; Thu, 17 Jul 2003 05:04:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24277 for ; Thu, 17 Jul 2003 05:04:22 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4ga-0003Wb-00 for simple@ietf.org; Thu, 17 Jul 2003 05:04:24 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19d4gP-0003WS-00 for simple@ietf.org; Thu, 17 Jul 2003 05:04:13 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6H948B25111 for ; Thu, 17 Jul 2003 12:04:09 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 12:04:08 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 12:04:08 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 12:04:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194532C@esebe013.ntc.nokia.com> Thread-Topic: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Thread-Index: AcNLEUrOOcHITGyMRdyoR6VkQSKp7wBLUnoA To: , Cc: X-OriginalArrivalTime: 17 Jul 2003 09:04:07.0642 (UTC) FILETIME=[610ED3A0:01C34C42] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 12:04:07 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 15 July, 2003 23:38 > To: Henning Schulzrinne > Cc: simple@ietf.org > Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: > atomicity problem >=20 >=20 >=20 >=20 > Henning Schulzrinne wrote: >=20 > > This does seem much simpler. I wonder if combining this=20 > with an explicit=20 > > remove operation - "drop this Pstream/tuple-id tuple" -=20 > would avoid the=20 > > rather round-about way of cleaning up dead state noted=20 > below, without=20 > > having to worry about atomicity, last-modified-issues and=20 > unique naming. >=20 > I don't follow. Thats exactly what we were doing before. The home PC=20 > will send your "drop this pstream/tuple-id" in a publish (I assume=20 > that is what you mean), and then the work PC refreshes, and now we=20 > have the conflict all over again. >=20 > One other point on my proposal. One unresolved issue which=20 > we had was,=20 > if you want to delete a tuple using Expires:0, what=20 > information in the=20 > publish identified the tuple? In the proposal I am making, its easy.=20 > The Publish has an Expires:0 and a Pstream-ID header. The published=20 > document from that pstream is deleted. Well, in the current draft, this would be done using the server provided = etag, and Expires:0. The pstream-ID is really just another way of doing = etags. Cheers, Aki >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 17 05:05:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24298; Thu, 17 Jul 2003 05:05:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4hM-0003XJ-00; Thu, 17 Jul 2003 05:05:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d4hG-0003XD-00; Thu, 17 Jul 2003 05:05:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4hB-0007nP-DC; Thu, 17 Jul 2003 05:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4gX-0007mM-S4 for simple@optimus.ietf.org; Thu, 17 Jul 2003 05:04:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24274 for ; Thu, 17 Jul 2003 05:04:17 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4gU-0003WV-00 for simple@ietf.org; Thu, 17 Jul 2003 05:04:18 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19d4gJ-0003WR-00 for simple@ietf.org; Thu, 17 Jul 2003 05:04:07 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6H943B24917 for ; Thu, 17 Jul 2003 12:04:03 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 12:04:02 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 12:04:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB4@esebe013.ntc.nokia.com> Thread-Topic: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Thread-Index: AcNLCVAxIaqnQs0lRj6GQewdVUW57gAX8ghQ To: , Cc: X-OriginalArrivalTime: 17 Jul 2003 09:04:02.0870 (UTC) FILETIME=[5E36AD60:01C34C42] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 12:04:02 +0300 Content-Transfer-Encoding: quoted-printable Hi Jonathan, In general, I like the proposal of simplifying things.=20 If I understand the proposal you're making correctly, you want to remove = all of the current discussion on segmenting presence state, and have = each PUA publish their full view. Also, instead of using server-provided = etags, you want a publication to be identified by a client-generated = pstream-ID. Firstly, I agree on removing segmentation, and the whole package that = comes with it (collision detection, overriding, tuple-ID naming = conventions etc.) As you say, this just complicates things = unnecessar=EDly, and leaving these details to composer and publication = authorization policy makes a lot of sense. But about using PStream-ID instead of etags, I don't think it saves us a = lot compared to the current usage of Etags. By having the server = generate these identifiers (etags), their uniqueness within a presentity = is guaranteed. With PStream-IDs, the EPA has to do some work in order to = generate an ID that is guaranteed to be unique. Admittedly, this isn't a = huge effort, but compared to having the server assign identifiers simply = by incrementing a counter, may be slightly more complex. It anyway = introduces the chance of colliding PStream-IDs, which we would have to = deal with one way or another. Also, with PStream-ID, you'd still need an error response in case no = such PStrean-ID exists in the ESC. So all in all, we save the task of = defining/implementing the If-Match header field, but need more to handle = the PStream-ID generation/collision issues. So my counter-proposal would be to simplify along the lines you = described, removing all of the segmentation things, but still keep the = Etags, If-Match headers. The only change in their usage would be to = remove the collision detection altogether, so that the only case when a = refresh/deletion would fail with a 412 would be if the publication had = already expired (i.e., the etag no longer existed). Cheers, Aki > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 15 July, 2003 22:42 > To: Robert Sparks > Cc: Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: Rethinking scope on publish, was Re: [Simple] PUBLISH: > atomicity problem >=20 >=20 > I was about to post a note on agreeing with Aki. I was also=20 > going to=20 > say that we might want the body to also be the atomic unit, so that=20 > when you publish a tuple, the body is an XML fragment for the tuple.=20 > Then, it ocurred to me that we were really far down the complexity=20 > ramp here. So, I thought about what we could do to really=20 > back out of=20 > this mess entirely. Here is my idea. >=20 > In the beginning, PUBLISH was easy. Each PUA published its=20 > own view of=20 > the presence of the presentity. It had no knowledge of other PUA. It=20 > published a complete presence document which represented what it=20 > thought was the full presence of the presentity. Indeed, if=20 > there was=20 > only one PUA, it would be the full presence of the presentity. There=20 > was no way for one PUA to overwrite the published data from another.=20 > The tuple IDs didn't need to have cross-PUA scope. No naming=20 > conventions or anything. The compositor could combine these=20 > and modify=20 > them as it chose. Each represented a unique and different piece of=20 > info about the presentity. A useful bit of information was this=20 > "Pstream-ID", which uniquely identified the publisher. You can think=20 > of the Pstream-ID as a way of scoping the tuple IDs. Each=20 > tuple ID is=20 > defined only within the scope of a Pstream-ID, and each=20 > publisher has=20 > to have a unique PStream-ID. I'm not sure what type of temporal scope you are suggesting for the = stream-ID. Is it very long term, like a device-ID? Or is it only = persistent across a specific publication, over its refreshes, deletion, = etc.? If the only reason for stream-ID was to scope the tuple-IDs, then = whatever uniqueness property we want for the stream-ID, can equally well = be applied to the tuple-IDs, making the actual stream-ID not needed at = all. > It all got complicated when we decided to try and solve a bigger=20 > problem, where PUA could override information about other PUA. That=20 > introduced all kinds of problems. We needed to define the atomic=20 > information of published presence. We need to resolve tuple=20 > naming. We=20 > need to worry about this issue about whether a publish has=20 > one or more=20 > tuples. We needed to add Etags and If-Modified-Since. We=20 > need to worry=20 > about how to figure out what it means for the system to "wait for=20 > human input" in cases where thats not possible. We don't know how to=20 > do that yet. I agree, the overriding requirement lead us to the problems in = atomicity, and tuple-ID naming. =20 > Perhaps we should reconsider whether we want to solve this problem=20 > this way. We have only one use case - when I leave my PC at=20 > the office=20 > with a presence state that is wrong, and I want to fix it at home.=20 > Well, this is a nice feature, but is it worth all of the=20 > complexity at=20 > this point? There are other ways to deal with it. In fact, I=20 > can think=20 > of two alternatives: >=20 > 1. You could use the auth policy to simply disable the PC's=20 > data from=20 > being placed in notifications, and then publish a separate tuple=20 > (i.e., new piece of independent information) from home. Thats not as=20 > good (PC still refreshes useless state), but its lots=20 > simpler than the=20 > route we are on. But how would you actually do that? If the only way a publisher can be = identified (PStream-ID) is generated by the publisher itself, how can = one set the appropriate authorization policy for disabling those = publications? =20 > 2. You could design a system which only allowed one PUA at a time=20 > (akin to the current model in AIM and YIM). This would=20 > manifest itself=20 > as composition policy. The compositor would only use the published=20 > document from the PUA which started publishing most recently - that=20 > is, when its Pstream-ID first appeared. This would also achieve the=20 > effect of disabling the work PC's state when you arrive at home. >=20 >=20 > So, to be concrete, I would propose the following: >=20 >=20 > 1. Publications carry complete presence documents, representing the=20 > complete presence state of the PUA as far as it knows. >=20 > 2. Publishers are identified by a unique PStream-ID, chosen by the=20 > publisher. Copying someone elses Pstream-ID is not allowed, and=20 > behavior in this case is not defined. >=20 > 3. There is no ability to overwrite someone elses presence=20 > document or=20 > their tuples. Each publisher publishes independent information. >=20 > 4. We eliminate the Etag, If-Modified-Since, and atomicity/segment=20 > discussions from Publish. >=20 > 5. Compositors can combine the publsihed information however they=20 > like. There is no need to carry through tuple IDs from=20 > publication to=20 > notifications. >=20 > 6. If you want to block a tuple from getting into a notify, you=20 > identify it by a distinguishing property rather than by tuple ID. >=20 >=20 > I believe this approach works nicely for other things too.=20 > In the case=20 > of winfo, where you have lots of presence servers, each publishing=20 > winfo for the subscriptions they have, its the same. Each=20 > publisher (a=20 > presence server), publishes the complete view of the state - its own=20 > subscriptions. There is no overlap between servers. The compositor=20 > combines these together using a basic policy (combine subscriptions=20 > together that are for the same presentity), and thats it. >=20 > I believe it works for mwi too. >=20 > I really feel that it is important that we make some simplifications=20 > so that we can make rapid progress here. I don't think we lose much=20 > since we can still get the desired feature; we just get it in a=20 > different way. >=20 > Thoughts? >=20 > -Jonathan R. >=20 > Robert Sparks wrote: >=20 > > Another way to state this conclusion is that we need to report > > success or failure of publishing each atomic element in an=20 > independent > > fashion. One quick and easy way to achieve that property=20 > is to allow > > only one atomic element per PUBLISH request. > >=20 > > I think I heard another way to do this mentioned during=20 > the meeting, > > where we move reporting the success/failure and any feedback from > > the attempt to publish each tuple into the message instead=20 > of trying > > to capture it all on the status line. For example (I think this is=20 > > what I heard suggested during the meeting), for presence, we could > > publish an entire pidf document with several tuples and in=20 > the presence > > response return an xml document with one element per tuple=20 > discussing > > the disposition of attempting to publish that tuple. > >=20 > > Something along the lines of the following (an example to=20 > convey the > > concept, not a proposal of a syntax) > > > > > > > > > > > > > > > > > >=20 > > If we were to pursue such an optimization, it might make sense to > > look at how to specify a separate etag value in the=20 > publish (currently > > what we put in an If-Match header) for each atom in the published > > document. > >=20 > > RjS > >=20 > > On Mon, 2003-07-14 at 19:58, aki.niemi@nokia.com wrote: > >=20 > >>All, > >> > >>I'll try to summarize the issues w.r.t. the atomicity of=20 > publication here in an attempt to converge the discussion=20 > towards a solution to this problem. BTW, I realized that my=20 > slides in the SIMPLE session were perhaps not crystal clear=20 > on what the problem at hand really was, so my apologies for that. > >> > >>The core problem is this:=20 > >> > >>EPA X sends a PUBLISH with {a, b, c}, after which EPA Y=20 > publishes {a, b}. When EPA X tries to refresh its=20 > publication of {a, b, c}, the request fails because of a=20 > collision, resulting in the EPA X quitting. EPA Y still=20 > refreshes its publication of {a, b}, which means {c} expires=20 > and goes away. As a result, the publication process has lost=20 > information of {c}. This is unacceptable, and with the=20 > current versioning mechanism, this can't be remedied by=20 > composer policy, for example. > >> > >>Instead, to get around the above problem, what you send in=20 > a PUBLISH needs to match the atomic element of the published=20 > information. So each PUBLISH needs to contain a single=20 > tuple, because the versioning and expiration all work on the=20 > single atomic element level anyway. > >> > >>This has the apparent drawback in that the PUA has to wait=20 > for a 200 OK after each PUBLISHed tuple before it can=20 > PUBLISH the next one. This occurs upon every refresh cycle,=20 > and in systems with high latency, may become a major issue=20 > in terms of performance. > >> > >>Ways to get around this inefficiency: > >> - Remove the restriction on overlapping requests, i.e.,=20 > allow "pipelining" > >> of PUBLISH requests > >> - Treat the publisher of each tuple as a separate EPA,=20 > and therefore not > >> subject to this restriction in the first place (seems=20 > like cheating...)=20 > >> > >>In conclusion, my proposal is to go with having always a=20 > single tuple in a PUBLISH, and allow overlapping PUBLISH=20 > requests. To my knowledge, this would fulfill all the=20 > related requirements and solve the issue. > >> > >>Thoughts? > >> > >>Cheers, > >>Aki > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 17 05:05:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24375 for ; Thu, 17 Jul 2003 05:05:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4hQ-0007tQ-Kc for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 05:05:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H95G2i030339 for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 05:05:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4hQ-0007tG-G1 for simple-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 05:05:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24296; Thu, 17 Jul 2003 05:05:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4hM-0003XG-00; Thu, 17 Jul 2003 05:05:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d4hG-0003XC-00; Thu, 17 Jul 2003 05:05:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4hB-0007nf-S9; Thu, 17 Jul 2003 05:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4gd-0007mT-H2 for simple@optimus.ietf.org; Thu, 17 Jul 2003 05:04:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24277 for ; Thu, 17 Jul 2003 05:04:22 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4ga-0003Wb-00 for simple@ietf.org; Thu, 17 Jul 2003 05:04:24 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19d4gP-0003WS-00 for simple@ietf.org; Thu, 17 Jul 2003 05:04:13 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6H948B25111 for ; Thu, 17 Jul 2003 12:04:09 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 12:04:08 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 12:04:08 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 12:04:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194532C@esebe013.ntc.nokia.com> Thread-Topic: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Thread-Index: AcNLEUrOOcHITGyMRdyoR6VkQSKp7wBLUnoA To: , Cc: X-OriginalArrivalTime: 17 Jul 2003 09:04:07.0642 (UTC) FILETIME=[610ED3A0:01C34C42] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 12:04:07 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 15 July, 2003 23:38 > To: Henning Schulzrinne > Cc: simple@ietf.org > Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: > atomicity problem >=20 >=20 >=20 >=20 > Henning Schulzrinne wrote: >=20 > > This does seem much simpler. I wonder if combining this=20 > with an explicit=20 > > remove operation - "drop this Pstream/tuple-id tuple" -=20 > would avoid the=20 > > rather round-about way of cleaning up dead state noted=20 > below, without=20 > > having to worry about atomicity, last-modified-issues and=20 > unique naming. >=20 > I don't follow. Thats exactly what we were doing before. The home PC=20 > will send your "drop this pstream/tuple-id" in a publish (I assume=20 > that is what you mean), and then the work PC refreshes, and now we=20 > have the conflict all over again. >=20 > One other point on my proposal. One unresolved issue which=20 > we had was,=20 > if you want to delete a tuple using Expires:0, what=20 > information in the=20 > publish identified the tuple? In the proposal I am making, its easy.=20 > The Publish has an Expires:0 and a Pstream-ID header. The published=20 > document from that pstream is deleted. Well, in the current draft, this would be done using the server provided = etag, and Expires:0. The pstream-ID is really just another way of doing = etags. Cheers, Aki >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 17 05:05:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24390 for ; Thu, 17 Jul 2003 05:05:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4hR-0007tl-GJ for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 05:05:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H95Hpl030357 for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 05:05:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4hQ-0007tW-Lw for simple-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 05:05:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24298; Thu, 17 Jul 2003 05:05:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4hM-0003XJ-00; Thu, 17 Jul 2003 05:05:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d4hG-0003XD-00; Thu, 17 Jul 2003 05:05:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4hB-0007nP-DC; Thu, 17 Jul 2003 05:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4gX-0007mM-S4 for simple@optimus.ietf.org; Thu, 17 Jul 2003 05:04:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24274 for ; Thu, 17 Jul 2003 05:04:17 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4gU-0003WV-00 for simple@ietf.org; Thu, 17 Jul 2003 05:04:18 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19d4gJ-0003WR-00 for simple@ietf.org; Thu, 17 Jul 2003 05:04:07 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6H943B24917 for ; Thu, 17 Jul 2003 12:04:03 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 12:04:02 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 12:04:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB4@esebe013.ntc.nokia.com> Thread-Topic: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Thread-Index: AcNLCVAxIaqnQs0lRj6GQewdVUW57gAX8ghQ To: , Cc: X-OriginalArrivalTime: 17 Jul 2003 09:04:02.0870 (UTC) FILETIME=[5E36AD60:01C34C42] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 12:04:02 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jonathan, In general, I like the proposal of simplifying things.=20 If I understand the proposal you're making correctly, you want to remove = all of the current discussion on segmenting presence state, and have = each PUA publish their full view. Also, instead of using server-provided = etags, you want a publication to be identified by a client-generated = pstream-ID. Firstly, I agree on removing segmentation, and the whole package that = comes with it (collision detection, overriding, tuple-ID naming = conventions etc.) As you say, this just complicates things = unnecessar=EDly, and leaving these details to composer and publication = authorization policy makes a lot of sense. But about using PStream-ID instead of etags, I don't think it saves us a = lot compared to the current usage of Etags. By having the server = generate these identifiers (etags), their uniqueness within a presentity = is guaranteed. With PStream-IDs, the EPA has to do some work in order to = generate an ID that is guaranteed to be unique. Admittedly, this isn't a = huge effort, but compared to having the server assign identifiers simply = by incrementing a counter, may be slightly more complex. It anyway = introduces the chance of colliding PStream-IDs, which we would have to = deal with one way or another. Also, with PStream-ID, you'd still need an error response in case no = such PStrean-ID exists in the ESC. So all in all, we save the task of = defining/implementing the If-Match header field, but need more to handle = the PStream-ID generation/collision issues. So my counter-proposal would be to simplify along the lines you = described, removing all of the segmentation things, but still keep the = Etags, If-Match headers. The only change in their usage would be to = remove the collision detection altogether, so that the only case when a = refresh/deletion would fail with a 412 would be if the publication had = already expired (i.e., the etag no longer existed). Cheers, Aki > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 15 July, 2003 22:42 > To: Robert Sparks > Cc: Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: Rethinking scope on publish, was Re: [Simple] PUBLISH: > atomicity problem >=20 >=20 > I was about to post a note on agreeing with Aki. I was also=20 > going to=20 > say that we might want the body to also be the atomic unit, so that=20 > when you publish a tuple, the body is an XML fragment for the tuple.=20 > Then, it ocurred to me that we were really far down the complexity=20 > ramp here. So, I thought about what we could do to really=20 > back out of=20 > this mess entirely. Here is my idea. >=20 > In the beginning, PUBLISH was easy. Each PUA published its=20 > own view of=20 > the presence of the presentity. It had no knowledge of other PUA. It=20 > published a complete presence document which represented what it=20 > thought was the full presence of the presentity. Indeed, if=20 > there was=20 > only one PUA, it would be the full presence of the presentity. There=20 > was no way for one PUA to overwrite the published data from another.=20 > The tuple IDs didn't need to have cross-PUA scope. No naming=20 > conventions or anything. The compositor could combine these=20 > and modify=20 > them as it chose. Each represented a unique and different piece of=20 > info about the presentity. A useful bit of information was this=20 > "Pstream-ID", which uniquely identified the publisher. You can think=20 > of the Pstream-ID as a way of scoping the tuple IDs. Each=20 > tuple ID is=20 > defined only within the scope of a Pstream-ID, and each=20 > publisher has=20 > to have a unique PStream-ID. I'm not sure what type of temporal scope you are suggesting for the = stream-ID. Is it very long term, like a device-ID? Or is it only = persistent across a specific publication, over its refreshes, deletion, = etc.? If the only reason for stream-ID was to scope the tuple-IDs, then = whatever uniqueness property we want for the stream-ID, can equally well = be applied to the tuple-IDs, making the actual stream-ID not needed at = all. > It all got complicated when we decided to try and solve a bigger=20 > problem, where PUA could override information about other PUA. That=20 > introduced all kinds of problems. We needed to define the atomic=20 > information of published presence. We need to resolve tuple=20 > naming. We=20 > need to worry about this issue about whether a publish has=20 > one or more=20 > tuples. We needed to add Etags and If-Modified-Since. We=20 > need to worry=20 > about how to figure out what it means for the system to "wait for=20 > human input" in cases where thats not possible. We don't know how to=20 > do that yet. I agree, the overriding requirement lead us to the problems in = atomicity, and tuple-ID naming. =20 > Perhaps we should reconsider whether we want to solve this problem=20 > this way. We have only one use case - when I leave my PC at=20 > the office=20 > with a presence state that is wrong, and I want to fix it at home.=20 > Well, this is a nice feature, but is it worth all of the=20 > complexity at=20 > this point? There are other ways to deal with it. In fact, I=20 > can think=20 > of two alternatives: >=20 > 1. You could use the auth policy to simply disable the PC's=20 > data from=20 > being placed in notifications, and then publish a separate tuple=20 > (i.e., new piece of independent information) from home. Thats not as=20 > good (PC still refreshes useless state), but its lots=20 > simpler than the=20 > route we are on. But how would you actually do that? If the only way a publisher can be = identified (PStream-ID) is generated by the publisher itself, how can = one set the appropriate authorization policy for disabling those = publications? =20 > 2. You could design a system which only allowed one PUA at a time=20 > (akin to the current model in AIM and YIM). This would=20 > manifest itself=20 > as composition policy. The compositor would only use the published=20 > document from the PUA which started publishing most recently - that=20 > is, when its Pstream-ID first appeared. This would also achieve the=20 > effect of disabling the work PC's state when you arrive at home. >=20 >=20 > So, to be concrete, I would propose the following: >=20 >=20 > 1. Publications carry complete presence documents, representing the=20 > complete presence state of the PUA as far as it knows. >=20 > 2. Publishers are identified by a unique PStream-ID, chosen by the=20 > publisher. Copying someone elses Pstream-ID is not allowed, and=20 > behavior in this case is not defined. >=20 > 3. There is no ability to overwrite someone elses presence=20 > document or=20 > their tuples. Each publisher publishes independent information. >=20 > 4. We eliminate the Etag, If-Modified-Since, and atomicity/segment=20 > discussions from Publish. >=20 > 5. Compositors can combine the publsihed information however they=20 > like. There is no need to carry through tuple IDs from=20 > publication to=20 > notifications. >=20 > 6. If you want to block a tuple from getting into a notify, you=20 > identify it by a distinguishing property rather than by tuple ID. >=20 >=20 > I believe this approach works nicely for other things too.=20 > In the case=20 > of winfo, where you have lots of presence servers, each publishing=20 > winfo for the subscriptions they have, its the same. Each=20 > publisher (a=20 > presence server), publishes the complete view of the state - its own=20 > subscriptions. There is no overlap between servers. The compositor=20 > combines these together using a basic policy (combine subscriptions=20 > together that are for the same presentity), and thats it. >=20 > I believe it works for mwi too. >=20 > I really feel that it is important that we make some simplifications=20 > so that we can make rapid progress here. I don't think we lose much=20 > since we can still get the desired feature; we just get it in a=20 > different way. >=20 > Thoughts? >=20 > -Jonathan R. >=20 > Robert Sparks wrote: >=20 > > Another way to state this conclusion is that we need to report > > success or failure of publishing each atomic element in an=20 > independent > > fashion. One quick and easy way to achieve that property=20 > is to allow > > only one atomic element per PUBLISH request. > >=20 > > I think I heard another way to do this mentioned during=20 > the meeting, > > where we move reporting the success/failure and any feedback from > > the attempt to publish each tuple into the message instead=20 > of trying > > to capture it all on the status line. For example (I think this is=20 > > what I heard suggested during the meeting), for presence, we could > > publish an entire pidf document with several tuples and in=20 > the presence > > response return an xml document with one element per tuple=20 > discussing > > the disposition of attempting to publish that tuple. > >=20 > > Something along the lines of the following (an example to=20 > convey the > > concept, not a proposal of a syntax) > > > > > > > > > > > > > > > > > >=20 > > If we were to pursue such an optimization, it might make sense to > > look at how to specify a separate etag value in the=20 > publish (currently > > what we put in an If-Match header) for each atom in the published > > document. > >=20 > > RjS > >=20 > > On Mon, 2003-07-14 at 19:58, aki.niemi@nokia.com wrote: > >=20 > >>All, > >> > >>I'll try to summarize the issues w.r.t. the atomicity of=20 > publication here in an attempt to converge the discussion=20 > towards a solution to this problem. BTW, I realized that my=20 > slides in the SIMPLE session were perhaps not crystal clear=20 > on what the problem at hand really was, so my apologies for that. > >> > >>The core problem is this:=20 > >> > >>EPA X sends a PUBLISH with {a, b, c}, after which EPA Y=20 > publishes {a, b}. When EPA X tries to refresh its=20 > publication of {a, b, c}, the request fails because of a=20 > collision, resulting in the EPA X quitting. EPA Y still=20 > refreshes its publication of {a, b}, which means {c} expires=20 > and goes away. As a result, the publication process has lost=20 > information of {c}. This is unacceptable, and with the=20 > current versioning mechanism, this can't be remedied by=20 > composer policy, for example. > >> > >>Instead, to get around the above problem, what you send in=20 > a PUBLISH needs to match the atomic element of the published=20 > information. So each PUBLISH needs to contain a single=20 > tuple, because the versioning and expiration all work on the=20 > single atomic element level anyway. > >> > >>This has the apparent drawback in that the PUA has to wait=20 > for a 200 OK after each PUBLISHed tuple before it can=20 > PUBLISH the next one. This occurs upon every refresh cycle,=20 > and in systems with high latency, may become a major issue=20 > in terms of performance. > >> > >>Ways to get around this inefficiency: > >> - Remove the restriction on overlapping requests, i.e.,=20 > allow "pipelining" > >> of PUBLISH requests > >> - Treat the publisher of each tuple as a separate EPA,=20 > and therefore not > >> subject to this restriction in the first place (seems=20 > like cheating...)=20 > >> > >>In conclusion, my proposal is to go with having always a=20 > single tuple in a PUBLISH, and allow overlapping PUBLISH=20 > requests. To my knowledge, this would fulfill all the=20 > related requirements and solve the issue. > >> > >>Thoughts? > >> > >>Cheers, > >>Aki > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 17 05:12:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24651; Thu, 17 Jul 2003 05:12:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4o7-0003aD-00; Thu, 17 Jul 2003 05:12:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d4o1-0003aA-00; Thu, 17 Jul 2003 05:12:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4nx-0000Eg-Eg; Thu, 17 Jul 2003 05:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4nL-0000Bf-En for simple@optimus.ietf.org; Thu, 17 Jul 2003 05:11:23 -0400 Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24622 for ; Thu, 17 Jul 2003 05:11:18 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6H9ArJ18178 for ; Thu, 17 Jul 2003 12:10:53 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 12:10:53 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 12:10:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F1D@esebe019.ntc.nokia.com> Thread-Topic: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Thread-Index: AcNMPEAxaccNU5imRBG6McH/MjSWbwABSzZQ To: Cc: , , , X-OriginalArrivalTime: 17 Jul 2003 09:10:53.0587 (UTC) FILETIME=[53051E30:01C34C43] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 12:10:53 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, July 17, 2003 11:18 AM > To: Khartabil Hisham (NMP/Helsinki) > Cc: pkyzivat@cisco.com; rsparks@dynamicsoft.com; Niemi Aki > (NMP/Helsinki); simple@ietf.org > Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: > atomicity problem >=20 >=20 > inline. >=20 > hisham.khartabil@nokia.com wrote: >=20 > >=20 > >> -----Original Message----- From: ext Paul Kyzivat > >> [mailto:pkyzivat@cisco.com] Sent: Wednesday, July 16, 2003 1:19 > >> AM To: Jonathan Rosenberg Cc: Robert Sparks; Niemi Aki > >> (NMP/Helsinki); simple@ietf.org Subject: Re: Rethinking scope on > >> publish, was Re: [Simple] PUBLISH: atomicity problem > >>=20 > >>=20 > >> I generally like this idea, but maybe it is still too complex. > >>=20 > >> Why do we need the Pstream-ID? Simply say each publisher must > >> choose unique tuple ids and leave it at that. > >>=20 > >> Regarding how to set up blocking of the ones you don't want,=20 > >> instead of pstream, how about simply having each publisher > >> include its identity in each tuple, as an attribute? This could > >> be filtered out for most users. > >=20 > >=20 > > tuple is presence specific. I was thinking of a time-stamp type > > header (for presence, it probably carries the same info as in the > > time-stamp element). But then Jonathan mentioned deleting a tuple. > >=20 >=20 > My proposal is that deletion of a tuple is done using the=20 > authorization stuff. Its not a publishing issue. In an earlier post, you proposed using Expires: 0 and pstream header to = delete a tuple. I was pointing out that having a time-stamp type header = was sufficient enough to identify who published the most fresh = information. Then I realised it was actually not sufficient enough due = to your proposal to use the pstream header for deleting. I was also objecting to having something in the tuple to identify the = most recent publish since a tuple is presence specific. >=20 > The ID header is needed for soft-state. If the information being=20 > published is represented by the content of the PUBLISH request, you=20 > need an identifier in there to know when a PUBLISH updates/refreshes=20 > something published previously, or its a new PUA. You cannot rely on=20 > the From field or credentials for this disambiguation, since I may=20 > have multiple devices acting on my behalf, all publishing for me, all=20 > using my credentials and identity information. Silly suggestion, but can we use contact-header for that? >=20 > I think that pstream-ID was rejected previously because we were ALSO=20 > using tuple as semantically meaningful identifiers in publication=20 > processing. I am proposing that this not be the case. The tuple IDs=20 > only have meaning within the context of the published stream=20 > (which is=20 > pretty much the same semantic they have in a notification stream). >=20 > This also allows us to draw a clean line between the process of=20 > composition, which is data-type specific, and this PUBLISH mechanism,=20 > which is meant to not be specific to the data type. The "output" of=20 > the publish mechanism, towards the compositor, is a series of N=20 > published documents for a resource. The publish processor doesnt know=20 > what these documents are, or what they represent. It only knows about=20 > this pstream ID as a way of tagging them, so it can do the soft-state=20 > management necessary. That's exactly what I said on the mike in SIMPLE meeting, therefore I = agree with you. The reply from one of the chairs was that we have to = define the behaviour of the compositor anyway. Regards, Hisham >=20 > Also, consider further that deletion of published documents cannot=20 > rely on some kind of data-type specific identifier, like a tuple.=20 > Thats because the PUBLISH message with Expires:0 won't have any=20 > content. So, you NEED to have an identifier in the header for this to=20 > work. >=20 > -Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 17 05:12:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24674 for ; Thu, 17 Jul 2003 05:12:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4oC-0000GU-Fw for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 05:12:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H9CGx9001012 for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 05:12:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4oA-0000GD-Vr for simple-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 05:12:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24651; Thu, 17 Jul 2003 05:12:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4o7-0003aD-00; Thu, 17 Jul 2003 05:12:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d4o1-0003aA-00; Thu, 17 Jul 2003 05:12:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4nx-0000Eg-Eg; Thu, 17 Jul 2003 05:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4nL-0000Bf-En for simple@optimus.ietf.org; Thu, 17 Jul 2003 05:11:23 -0400 Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24622 for ; Thu, 17 Jul 2003 05:11:18 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6H9ArJ18178 for ; Thu, 17 Jul 2003 12:10:53 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 12:10:53 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 12:10:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F1D@esebe019.ntc.nokia.com> Thread-Topic: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Thread-Index: AcNMPEAxaccNU5imRBG6McH/MjSWbwABSzZQ To: Cc: , , , X-OriginalArrivalTime: 17 Jul 2003 09:10:53.0587 (UTC) FILETIME=[53051E30:01C34C43] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 12:10:53 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, July 17, 2003 11:18 AM > To: Khartabil Hisham (NMP/Helsinki) > Cc: pkyzivat@cisco.com; rsparks@dynamicsoft.com; Niemi Aki > (NMP/Helsinki); simple@ietf.org > Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: > atomicity problem >=20 >=20 > inline. >=20 > hisham.khartabil@nokia.com wrote: >=20 > >=20 > >> -----Original Message----- From: ext Paul Kyzivat > >> [mailto:pkyzivat@cisco.com] Sent: Wednesday, July 16, 2003 1:19 > >> AM To: Jonathan Rosenberg Cc: Robert Sparks; Niemi Aki > >> (NMP/Helsinki); simple@ietf.org Subject: Re: Rethinking scope on > >> publish, was Re: [Simple] PUBLISH: atomicity problem > >>=20 > >>=20 > >> I generally like this idea, but maybe it is still too complex. > >>=20 > >> Why do we need the Pstream-ID? Simply say each publisher must > >> choose unique tuple ids and leave it at that. > >>=20 > >> Regarding how to set up blocking of the ones you don't want,=20 > >> instead of pstream, how about simply having each publisher > >> include its identity in each tuple, as an attribute? This could > >> be filtered out for most users. > >=20 > >=20 > > tuple is presence specific. I was thinking of a time-stamp type > > header (for presence, it probably carries the same info as in the > > time-stamp element). But then Jonathan mentioned deleting a tuple. > >=20 >=20 > My proposal is that deletion of a tuple is done using the=20 > authorization stuff. Its not a publishing issue. In an earlier post, you proposed using Expires: 0 and pstream header to = delete a tuple. I was pointing out that having a time-stamp type header = was sufficient enough to identify who published the most fresh = information. Then I realised it was actually not sufficient enough due = to your proposal to use the pstream header for deleting. I was also objecting to having something in the tuple to identify the = most recent publish since a tuple is presence specific. >=20 > The ID header is needed for soft-state. If the information being=20 > published is represented by the content of the PUBLISH request, you=20 > need an identifier in there to know when a PUBLISH updates/refreshes=20 > something published previously, or its a new PUA. You cannot rely on=20 > the From field or credentials for this disambiguation, since I may=20 > have multiple devices acting on my behalf, all publishing for me, all=20 > using my credentials and identity information. Silly suggestion, but can we use contact-header for that? >=20 > I think that pstream-ID was rejected previously because we were ALSO=20 > using tuple as semantically meaningful identifiers in publication=20 > processing. I am proposing that this not be the case. The tuple IDs=20 > only have meaning within the context of the published stream=20 > (which is=20 > pretty much the same semantic they have in a notification stream). >=20 > This also allows us to draw a clean line between the process of=20 > composition, which is data-type specific, and this PUBLISH mechanism,=20 > which is meant to not be specific to the data type. The "output" of=20 > the publish mechanism, towards the compositor, is a series of N=20 > published documents for a resource. The publish processor doesnt know=20 > what these documents are, or what they represent. It only knows about=20 > this pstream ID as a way of tagging them, so it can do the soft-state=20 > management necessary. That's exactly what I said on the mike in SIMPLE meeting, therefore I = agree with you. The reply from one of the chairs was that we have to = define the behaviour of the compositor anyway. Regards, Hisham >=20 > Also, consider further that deletion of published documents cannot=20 > rely on some kind of data-type specific identifier, like a tuple.=20 > Thats because the PUBLISH message with Expires:0 won't have any=20 > content. So, you NEED to have an identifier in the header for this to=20 > work. >=20 > -Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 17 05:26:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25834; Thu, 17 Jul 2003 05:26:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d51e-0003nR-00; Thu, 17 Jul 2003 05:26:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d51Y-0003nO-00; Thu, 17 Jul 2003 05:26:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d51V-0001NG-CC; Thu, 17 Jul 2003 05:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d513-0001MI-AY for simple@optimus.ietf.org; Thu, 17 Jul 2003 05:25:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25799 for ; Thu, 17 Jul 2003 05:25:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d50z-0003mh-00 for simple@ietf.org; Thu, 17 Jul 2003 05:25:30 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19d50p-0003kt-00 for simple@ietf.org; Thu, 17 Jul 2003 05:25:19 -0400 Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6H9MgiB011650; Thu, 17 Jul 2003 05:22:43 -0400 (EDT) Message-ID: <3F166ADC.4070806@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: rsparks@dynamicsoft.com, simple@ietf.org Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB4@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB4@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id h6H9MgiB011650 Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 05:22:36 -0400 Content-Transfer-Encoding: quoted-printable inline. aki.niemi@nokia.com wrote: > Hi Jonathan, >=20 > In general, I like the proposal of simplifying things. >=20 > If I understand the proposal you're making correctly, you want to > remove all of the current discussion on segmenting presence state, > and have each PUA publish their full view. Also, instead of using > server-provided etags, you want a publication to be identified by a > client-generated pstream-ID. Right. >=20 > Firstly, I agree on removing segmentation, and the whole package > that comes with it (collision detection, overriding, tuple-ID > naming conventions etc.) As you say, this just complicates things > unnecessar=EDly, and leaving these details to composer and > publication authorization policy makes a lot of sense. >=20 > But about using PStream-ID instead of etags, I don't think it saves > us a lot compared to the current usage of Etags. By having the > server generate these identifiers (etags), their uniqueness within > a presentity is guaranteed. With PStream-IDs, the EPA has to do > some work in order to generate an ID that is guaranteed to be > unique. Admittedly, this isn't a huge effort, but compared to > having the server assign identifiers simply by incrementing a > counter, may be slightly more complex. It anyway introduces the > chance of colliding PStream-IDs, which we would have to deal with > one way or another. OK, this is a fair point. >=20 > Also, with PStream-ID, you'd still need an error response in case > no such PStrean-ID exists in the ESC. So all in all, we save the > task of defining/implementing the If-Match header field, but need > more to handle the PStream-ID generation/collision issues. Right. Thinking about this more, I actually like etag more. With my proposed=20 model that the published data from each PUA represents that PUA's=20 "view" of the full presence state of the resource, this becomes a good=20 match for the semantics of etag. Each published document just becomes=20 one entity that represents the resource, using the http terminology.=20 So, Etag becomes a reasonable candidate for this label. >=20 > So my counter-proposal would be to simplify along the lines you > described, removing all of the segmentation things, but still keep > the Etags, If-Match headers. The only change in their usage would > be to remove the collision detection altogether, so that the only > case when a refresh/deletion would fail with a 412 would be if the > publication had already expired (i.e., the etag no longer existed). I agree with your counter proposal. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 17 05:26:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25905 for ; Thu, 17 Jul 2003 05:26:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d51j-0001Qu-6L for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 05:26:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H9QFY1005502 for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 05:26:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d51h-0001Qf-Le for simple-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 05:26:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25834; Thu, 17 Jul 2003 05:26:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d51e-0003nR-00; Thu, 17 Jul 2003 05:26:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d51Y-0003nO-00; Thu, 17 Jul 2003 05:26:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d51V-0001NG-CC; Thu, 17 Jul 2003 05:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d513-0001MI-AY for simple@optimus.ietf.org; Thu, 17 Jul 2003 05:25:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25799 for ; Thu, 17 Jul 2003 05:25:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d50z-0003mh-00 for simple@ietf.org; Thu, 17 Jul 2003 05:25:30 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19d50p-0003kt-00 for simple@ietf.org; Thu, 17 Jul 2003 05:25:19 -0400 Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6H9MgiB011650; Thu, 17 Jul 2003 05:22:43 -0400 (EDT) Message-ID: <3F166ADC.4070806@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: rsparks@dynamicsoft.com, simple@ietf.org Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB4@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8EB4@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id h6H9MgiB011650 Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 05:22:36 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable inline. aki.niemi@nokia.com wrote: > Hi Jonathan, >=20 > In general, I like the proposal of simplifying things. >=20 > If I understand the proposal you're making correctly, you want to > remove all of the current discussion on segmenting presence state, > and have each PUA publish their full view. Also, instead of using > server-provided etags, you want a publication to be identified by a > client-generated pstream-ID. Right. >=20 > Firstly, I agree on removing segmentation, and the whole package > that comes with it (collision detection, overriding, tuple-ID > naming conventions etc.) As you say, this just complicates things > unnecessar=EDly, and leaving these details to composer and > publication authorization policy makes a lot of sense. >=20 > But about using PStream-ID instead of etags, I don't think it saves > us a lot compared to the current usage of Etags. By having the > server generate these identifiers (etags), their uniqueness within > a presentity is guaranteed. With PStream-IDs, the EPA has to do > some work in order to generate an ID that is guaranteed to be > unique. Admittedly, this isn't a huge effort, but compared to > having the server assign identifiers simply by incrementing a > counter, may be slightly more complex. It anyway introduces the > chance of colliding PStream-IDs, which we would have to deal with > one way or another. OK, this is a fair point. >=20 > Also, with PStream-ID, you'd still need an error response in case > no such PStrean-ID exists in the ESC. So all in all, we save the > task of defining/implementing the If-Match header field, but need > more to handle the PStream-ID generation/collision issues. Right. Thinking about this more, I actually like etag more. With my proposed=20 model that the published data from each PUA represents that PUA's=20 "view" of the full presence state of the resource, this becomes a good=20 match for the semantics of etag. Each published document just becomes=20 one entity that represents the resource, using the http terminology.=20 So, Etag becomes a reasonable candidate for this label. >=20 > So my counter-proposal would be to simplify along the lines you > described, removing all of the segmentation things, but still keep > the Etags, If-Match headers. The only change in their usage would > be to remove the collision detection altogether, so that the only > case when a refresh/deletion would fail with a 412 would be if the > publication had already expired (i.e., the etag no longer existed). I agree with your counter proposal. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 17 05:29:43 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26116; Thu, 17 Jul 2003 05:29:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d557-0003sy-00; Thu, 17 Jul 2003 05:29:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d551-0003sv-00; Thu, 17 Jul 2003 05:29:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d54Q-0001af-AF; Thu, 17 Jul 2003 05:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d54N-0001ZV-Cu for simple@optimus.ietf.org; Thu, 17 Jul 2003 05:28:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26057 for ; Thu, 17 Jul 2003 05:28:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d54G-0003pq-00 for simple@ietf.org; Thu, 17 Jul 2003 05:28:52 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19d546-0003oj-00 for simple@ietf.org; Thu, 17 Jul 2003 05:28:42 -0400 Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6H9RmiB011653; Thu, 17 Jul 2003 05:27:49 -0400 (EDT) Message-ID: <3F166C0E.6090707@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, rsparks@dynamicsoft.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem References: <2038BCC78B1AD641891A0D1AE133DBB701796F1D@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796F1D@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 05:27:42 -0400 Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > >> -----Original Message----- From: ext Jonathan Rosenberg >> [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, July 17, 2003 >> 11:18 AM To: Khartabil Hisham (NMP/Helsinki) Cc: >> pkyzivat@cisco.com; rsparks@dynamicsoft.com; Niemi Aki >> (NMP/Helsinki); simple@ietf.org Subject: Re: Rethinking scope on >> publish, was Re: [Simple] PUBLISH: atomicity problem >> >> >> inline. >> >> hisham.khartabil@nokia.com wrote: >> >> >>>> -----Original Message----- From: ext Paul Kyzivat >>>> [mailto:pkyzivat@cisco.com] Sent: Wednesday, July 16, 2003 >>>> 1:19 AM To: Jonathan Rosenberg Cc: Robert Sparks; Niemi Aki >>>> (NMP/Helsinki); simple@ietf.org Subject: Re: Rethinking scope >>>> on publish, was Re: [Simple] PUBLISH: atomicity problem >>>> >>>> >>>> I generally like this idea, but maybe it is still too >>>> complex. >>>> >>>> Why do we need the Pstream-ID? Simply say each publisher must >>>> choose unique tuple ids and leave it at that. >>>> >>>> Regarding how to set up blocking of the ones you don't want, >>>> instead of pstream, how about simply having each publisher >>>> include its identity in each tuple, as an attribute? This >>>> could be filtered out for most users. >>> >>> >>> tuple is presence specific. I was thinking of a time-stamp type >>> header (for presence, it probably carries the same info as in >>> the time-stamp element). But then Jonathan mentioned deleting a >>> tuple. >>> >> >> My proposal is that deletion of a tuple is done using the >> authorization stuff. Its not a publishing issue. > > > In an earlier post, you proposed using Expires: 0 and pstream > header to delete a tuple. Ah, sorry. By "deleting", I thought you meant the case where the home PC removes the tuple being published by the work PC, in our canonical example. > I was pointing out that having a > time-stamp type header was sufficient enough to identify who > published the most fresh information. Then I realised it was > actually not sufficient enough due to your proposal to use the > pstream header for deleting. > > I was also objecting to having something in the tuple to identify > the most recent publish since a tuple is presence specific. So we are in agreement, I think. > > >> The ID header is needed for soft-state. If the information being >> published is represented by the content of the PUBLISH request, >> you need an identifier in there to know when a PUBLISH >> updates/refreshes something published previously, or its a new >> PUA. You cannot rely on the From field or credentials for this >> disambiguation, since I may have multiple devices acting on my >> behalf, all publishing for me, all using my credentials and >> identity information. > > > Silly suggestion, but can we use contact-header for that? No. Its the same issue Ben had raised during sip in regards to the connection-reuse stuff. Consider two publishers behind different NATs, where both publishers have an address of 10.0.1.1. In that case, both of them might publish with this contact: Contact: sip:10.0.1.1 which isnt unique. Generally, using IP addresses as unique identifiers is a bad idea. > > >> I think that pstream-ID was rejected previously because we were >> ALSO using tuple as semantically meaningful identifiers in >> publication processing. I am proposing that this not be the case. >> The tuple IDs only have meaning within the context of the >> published stream (which is pretty much the same semantic they >> have in a notification stream). >> >> This also allows us to draw a clean line between the process of >> composition, which is data-type specific, and this PUBLISH >> mechanism, which is meant to not be specific to the data type. >> The "output" of the publish mechanism, towards the compositor, is >> a series of N published documents for a resource. The publish >> processor doesnt know what these documents are, or what they >> represent. It only knows about this pstream ID as a way of >> tagging them, so it can do the soft-state management necessary. > > > That's exactly what I said on the mike in SIMPLE meeting, therefore > I agree with you. The reply from one of the chairs was that we have > to define the behaviour of the compositor anyway. I remember Jon making that comment, but I dont think he was saying that we actually needed to specify what a compositor does. Anyway, we are in agreement. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 17 05:30:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26176 for ; Thu, 17 Jul 2003 05:30:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d55B-0001iY-6i for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 05:29:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H9Tn6B006597 for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 05:29:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d55B-0001iK-3i for simple-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 05:29:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26116; Thu, 17 Jul 2003 05:29:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d557-0003sy-00; Thu, 17 Jul 2003 05:29:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d551-0003sv-00; Thu, 17 Jul 2003 05:29:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d54Q-0001af-AF; Thu, 17 Jul 2003 05:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d54N-0001ZV-Cu for simple@optimus.ietf.org; Thu, 17 Jul 2003 05:28:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26057 for ; Thu, 17 Jul 2003 05:28:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d54G-0003pq-00 for simple@ietf.org; Thu, 17 Jul 2003 05:28:52 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19d546-0003oj-00 for simple@ietf.org; Thu, 17 Jul 2003 05:28:42 -0400 Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6H9RmiB011653; Thu, 17 Jul 2003 05:27:49 -0400 (EDT) Message-ID: <3F166C0E.6090707@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, rsparks@dynamicsoft.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem References: <2038BCC78B1AD641891A0D1AE133DBB701796F1D@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796F1D@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 05:27:42 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > >> -----Original Message----- From: ext Jonathan Rosenberg >> [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, July 17, 2003 >> 11:18 AM To: Khartabil Hisham (NMP/Helsinki) Cc: >> pkyzivat@cisco.com; rsparks@dynamicsoft.com; Niemi Aki >> (NMP/Helsinki); simple@ietf.org Subject: Re: Rethinking scope on >> publish, was Re: [Simple] PUBLISH: atomicity problem >> >> >> inline. >> >> hisham.khartabil@nokia.com wrote: >> >> >>>> -----Original Message----- From: ext Paul Kyzivat >>>> [mailto:pkyzivat@cisco.com] Sent: Wednesday, July 16, 2003 >>>> 1:19 AM To: Jonathan Rosenberg Cc: Robert Sparks; Niemi Aki >>>> (NMP/Helsinki); simple@ietf.org Subject: Re: Rethinking scope >>>> on publish, was Re: [Simple] PUBLISH: atomicity problem >>>> >>>> >>>> I generally like this idea, but maybe it is still too >>>> complex. >>>> >>>> Why do we need the Pstream-ID? Simply say each publisher must >>>> choose unique tuple ids and leave it at that. >>>> >>>> Regarding how to set up blocking of the ones you don't want, >>>> instead of pstream, how about simply having each publisher >>>> include its identity in each tuple, as an attribute? This >>>> could be filtered out for most users. >>> >>> >>> tuple is presence specific. I was thinking of a time-stamp type >>> header (for presence, it probably carries the same info as in >>> the time-stamp element). But then Jonathan mentioned deleting a >>> tuple. >>> >> >> My proposal is that deletion of a tuple is done using the >> authorization stuff. Its not a publishing issue. > > > In an earlier post, you proposed using Expires: 0 and pstream > header to delete a tuple. Ah, sorry. By "deleting", I thought you meant the case where the home PC removes the tuple being published by the work PC, in our canonical example. > I was pointing out that having a > time-stamp type header was sufficient enough to identify who > published the most fresh information. Then I realised it was > actually not sufficient enough due to your proposal to use the > pstream header for deleting. > > I was also objecting to having something in the tuple to identify > the most recent publish since a tuple is presence specific. So we are in agreement, I think. > > >> The ID header is needed for soft-state. If the information being >> published is represented by the content of the PUBLISH request, >> you need an identifier in there to know when a PUBLISH >> updates/refreshes something published previously, or its a new >> PUA. You cannot rely on the From field or credentials for this >> disambiguation, since I may have multiple devices acting on my >> behalf, all publishing for me, all using my credentials and >> identity information. > > > Silly suggestion, but can we use contact-header for that? No. Its the same issue Ben had raised during sip in regards to the connection-reuse stuff. Consider two publishers behind different NATs, where both publishers have an address of 10.0.1.1. In that case, both of them might publish with this contact: Contact: sip:10.0.1.1 which isnt unique. Generally, using IP addresses as unique identifiers is a bad idea. > > >> I think that pstream-ID was rejected previously because we were >> ALSO using tuple as semantically meaningful identifiers in >> publication processing. I am proposing that this not be the case. >> The tuple IDs only have meaning within the context of the >> published stream (which is pretty much the same semantic they >> have in a notification stream). >> >> This also allows us to draw a clean line between the process of >> composition, which is data-type specific, and this PUBLISH >> mechanism, which is meant to not be specific to the data type. >> The "output" of the publish mechanism, towards the compositor, is >> a series of N published documents for a resource. The publish >> processor doesnt know what these documents are, or what they >> represent. It only knows about this pstream ID as a way of >> tagging them, so it can do the soft-state management necessary. > > > That's exactly what I said on the mike in SIMPLE meeting, therefore > I agree with you. The reply from one of the chairs was that we have > to define the behaviour of the compositor anyway. I remember Jon making that comment, but I dont think he was saying that we actually needed to specify what a compositor does. Anyway, we are in agreement. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 17 05:39:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26846; Thu, 17 Jul 2003 05:39:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d5E4-0002wS-PI; Thu, 17 Jul 2003 05:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d5E1-0002wH-EX for simple@optimus.ietf.org; Thu, 17 Jul 2003 05:38:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26827 for ; Thu, 17 Jul 2003 05:38:52 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d5Dx-0003zE-00 for simple@ietf.org; Thu, 17 Jul 2003 05:38:53 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19d5Dm-0003z6-00 for simple@ietf.org; Thu, 17 Jul 2003 05:38:43 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6H9ccB26046 for ; Thu, 17 Jul 2003 12:38:38 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 12:38:38 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 12:38:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F1E@esebe019.ntc.nokia.com> Thread-Topic: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Thread-Index: AcNLEUrOOcHITGyMRdyoR6VkQSKp7wBLUnoAAAIj0OA= To: , , Cc: X-OriginalArrivalTime: 17 Jul 2003 09:38:38.0076 (UTC) FILETIME=[3321FBC0:01C34C47] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 12:38:37 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Thursday, July 17, 2003 12:04 PM > To: jdrosen@dynamicsoft.com; hgs@cs.columbia.edu > Cc: simple@ietf.org > Subject: RE: Rethinking scope on publish, was Re: [Simple] PUBLISH: > atomicity problem >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: 15 July, 2003 23:38 > > To: Henning Schulzrinne > > Cc: simple@ietf.org > > Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: > > atomicity problem > >=20 > >=20 > >=20 > >=20 > > Henning Schulzrinne wrote: > >=20 > > > This does seem much simpler. I wonder if combining this=20 > > with an explicit=20 > > > remove operation - "drop this Pstream/tuple-id tuple" -=20 > > would avoid the=20 > > > rather round-about way of cleaning up dead state noted=20 > > below, without=20 > > > having to worry about atomicity, last-modified-issues and=20 > > unique naming. > >=20 > > I don't follow. Thats exactly what we were doing before.=20 > The home PC=20 > > will send your "drop this pstream/tuple-id" in a publish (I assume=20 > > that is what you mean), and then the work PC refreshes, and now we=20 > > have the conflict all over again. > >=20 > > One other point on my proposal. One unresolved issue which=20 > > we had was,=20 > > if you want to delete a tuple using Expires:0, what=20 > > information in the=20 > > publish identified the tuple? In the proposal I am making,=20 > its easy.=20 > > The Publish has an Expires:0 and a Pstream-ID header. The=20 > published=20 > > document from that pstream is deleted. >=20 > Well, in the current draft, this would be done using the=20 > server provided etag, and Expires:0. The pstream-ID is really=20 > just another way of doing etags. So lets keep etags. Hisham >=20 > Cheers, > Aki >=20 >=20 > >=20 > > -Jonathan R. > >=20 > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ=20 > 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > >=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 exim@www1.ietf.org Thu Jul 17 05:40:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26881 for ; Thu, 17 Jul 2003 05:40:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d5Ed-0003Ad-3V for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 05:39:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H9dZLp012181 for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 05:39:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d5Ed-0003AO-0H for simple-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 05:39:35 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26846; Thu, 17 Jul 2003 05:39:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d5E4-0002wS-PI; Thu, 17 Jul 2003 05:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d5E1-0002wH-EX for simple@optimus.ietf.org; Thu, 17 Jul 2003 05:38:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26827 for ; Thu, 17 Jul 2003 05:38:52 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d5Dx-0003zE-00 for simple@ietf.org; Thu, 17 Jul 2003 05:38:53 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19d5Dm-0003z6-00 for simple@ietf.org; Thu, 17 Jul 2003 05:38:43 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6H9ccB26046 for ; Thu, 17 Jul 2003 12:38:38 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 12:38:38 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 12:38:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F1E@esebe019.ntc.nokia.com> Thread-Topic: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem Thread-Index: AcNLEUrOOcHITGyMRdyoR6VkQSKp7wBLUnoAAAIj0OA= To: , , Cc: X-OriginalArrivalTime: 17 Jul 2003 09:38:38.0076 (UTC) FILETIME=[3321FBC0:01C34C47] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 12:38:37 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Thursday, July 17, 2003 12:04 PM > To: jdrosen@dynamicsoft.com; hgs@cs.columbia.edu > Cc: simple@ietf.org > Subject: RE: Rethinking scope on publish, was Re: [Simple] PUBLISH: > atomicity problem >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: 15 July, 2003 23:38 > > To: Henning Schulzrinne > > Cc: simple@ietf.org > > Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH: > > atomicity problem > >=20 > >=20 > >=20 > >=20 > > Henning Schulzrinne wrote: > >=20 > > > This does seem much simpler. I wonder if combining this=20 > > with an explicit=20 > > > remove operation - "drop this Pstream/tuple-id tuple" -=20 > > would avoid the=20 > > > rather round-about way of cleaning up dead state noted=20 > > below, without=20 > > > having to worry about atomicity, last-modified-issues and=20 > > unique naming. > >=20 > > I don't follow. Thats exactly what we were doing before.=20 > The home PC=20 > > will send your "drop this pstream/tuple-id" in a publish (I assume=20 > > that is what you mean), and then the work PC refreshes, and now we=20 > > have the conflict all over again. > >=20 > > One other point on my proposal. One unresolved issue which=20 > > we had was,=20 > > if you want to delete a tuple using Expires:0, what=20 > > information in the=20 > > publish identified the tuple? In the proposal I am making,=20 > its easy.=20 > > The Publish has an Expires:0 and a Pstream-ID header. The=20 > published=20 > > document from that pstream is deleted. >=20 > Well, in the current draft, this would be done using the=20 > server provided etag, and Expires:0. The pstream-ID is really=20 > just another way of doing etags. So lets keep etags. Hisham >=20 > Cheers, > Aki >=20 >=20 > >=20 > > -Jonathan R. > >=20 > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ=20 > 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > >=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-admin@ietf.org Thu Jul 17 07:17:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29936; Thu, 17 Jul 2003 07:17:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d6l3-0004uM-00; Thu, 17 Jul 2003 07:17:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d6kx-0004uJ-00; Thu, 17 Jul 2003 07:17:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6kv-00019D-Gv; Thu, 17 Jul 2003 07:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6kG-00018W-Tw for simple@optimus.ietf.org; Thu, 17 Jul 2003 07:16:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29929 for ; Thu, 17 Jul 2003 07:16:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d6kG-0004uC-00 for simple@ietf.org; Thu, 17 Jul 2003 07:16:20 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19d6k5-0004u5-00 for simple@ietf.org; Thu, 17 Jul 2003 07:16:09 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6HBF0E5015671; Thu, 17 Jul 2003 07:15:00 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jul 2003 06:15:00 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3EE600A@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Paul Kyzivat , Jonathan Rosenberg Cc: Robert Sparks , Aki Niemi , simple@ietf.org Subject: RE: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomic ity problem MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 06:14:51 -0500 Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: > Regarding how to set up blocking of the ones you don't want, > instead of > pstream, how about simply having each publisher include its > identity in > each tuple, as an attribute? This could be filtered out for > most users. This doesn't translate well to other event packages. We can't solve this problem in a way that is specific to PIDF or even XML. The solution needs to be generalizable to all event packages. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 17 07:17:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29957 for ; Thu, 17 Jul 2003 07:17:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6l4-0001Cp-Fm for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 07:17:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HBHAp4004629 for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 07:17:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6l4-0001Ca-BF for simple-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 07:17:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29936; Thu, 17 Jul 2003 07:17:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d6l3-0004uM-00; Thu, 17 Jul 2003 07:17:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d6kx-0004uJ-00; Thu, 17 Jul 2003 07:17:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6kv-00019D-Gv; Thu, 17 Jul 2003 07:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6kG-00018W-Tw for simple@optimus.ietf.org; Thu, 17 Jul 2003 07:16:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29929 for ; Thu, 17 Jul 2003 07:16:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d6kG-0004uC-00 for simple@ietf.org; Thu, 17 Jul 2003 07:16:20 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19d6k5-0004u5-00 for simple@ietf.org; Thu, 17 Jul 2003 07:16:09 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6HBF0E5015671; Thu, 17 Jul 2003 07:15:00 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jul 2003 06:15:00 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3EE600A@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Paul Kyzivat , Jonathan Rosenberg Cc: Robert Sparks , Aki Niemi , simple@ietf.org Subject: RE: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomic ity problem MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 06:14:51 -0500 Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: > Regarding how to set up blocking of the ones you don't want, > instead of > pstream, how about simply having each publisher include its > identity in > each tuple, as an attribute? This could be filtered out for > most users. This doesn't translate well to other event packages. We can't solve this problem in a way that is specific to PIDF or even XML. The solution needs to be generalizable to all event packages. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 17 08:54:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04392; Thu, 17 Jul 2003 08:54:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d8Gv-00064c-00; Thu, 17 Jul 2003 08:54:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d8Gp-00064Z-00; Thu, 17 Jul 2003 08:54:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8Gm-0007W6-DY; Thu, 17 Jul 2003 08:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8Fp-0007PQ-4g for simple@optimus.ietf.org; Thu, 17 Jul 2003 08:53:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04320 for ; Thu, 17 Jul 2003 08:52:57 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d8Fn-000636-00 for simple@ietf.org; Thu, 17 Jul 2003 08:52:59 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19d8Fc-00062D-00 for simple@ietf.org; Thu, 17 Jul 2003 08:52:48 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6HCpTJ02049 for ; Thu, 17 Jul 2003 15:51:29 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 15:51:28 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 15:50:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] New I-D on presence states for phones Message-ID: Thread-Topic: [Simple] New I-D on presence states for phones Thread-Index: AcNFHDyzWBftwm59RbW1zjJj2htE+QHQtdDQ To: , X-OriginalArrivalTime: 17 Jul 2003 12:50:30.0416 (UTC) FILETIME=[0105A900:01C34C62] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 15:50:29 +0300 Content-Transfer-Encoding: quoted-printable Hi, I think this draft defines bunch of useful information. However, I would = definitely take away the "signal-strength" attribute under the wireless = phone state. As already stated in the draft, this information is = changing frequently, so I think it is not sensible in the timescale that = SIP events work. And even if it would be possible to convey this = information, what would it mean in GPRS, WCDMA or WiFi? Is there any use = case what any watcher could in _practice_ benefit from this information? = What might be useful as an addition to "ran" is some more information on = the access-link, i.e. that the "downlink capacity class" is ~40 kbps, = and "RTT class" is ~500 ms. This _kind_ of information might give = watchers some idea what _kind_ of applications/media the device could be = able to do at the moment (although you could find that out also through = PIDF/prescaps and SDP negotiations). This kind of info is relatively = static (in the order of minutes rather than seconds), but still = changing. In any case, this would be more valuable than = "signal-strength". =20 Markus=20 > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 08 July, 2003 09:42 > To: Simple WG > Subject: [Simple] New I-D on presence states for phones >=20 >=20 > Folks, >=20 > In case folks havent seen it, I wanted to call your attention to: >=20 > http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s imple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html This draft, written by Jon and myself, defines some PIDF extensions=20 for describing phones, including traditional "black" phones, wireless=20 phones and enterprise phones. I think these will provide invaluable=20 for a device-centric view of a presentity. Comments and questions welcome. Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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 exim@www1.ietf.org Thu Jul 17 08:54:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04433 for ; Thu, 17 Jul 2003 08:54:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8Gw-0007Zb-TT for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 08:54:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HCsAap029108 for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 08:54:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8Gw-0007ZP-Pw for simple-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 08:54:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04392; Thu, 17 Jul 2003 08:54:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d8Gv-00064c-00; Thu, 17 Jul 2003 08:54:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d8Gp-00064Z-00; Thu, 17 Jul 2003 08:54:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8Gm-0007W6-DY; Thu, 17 Jul 2003 08:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8Fp-0007PQ-4g for simple@optimus.ietf.org; Thu, 17 Jul 2003 08:53:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04320 for ; Thu, 17 Jul 2003 08:52:57 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d8Fn-000636-00 for simple@ietf.org; Thu, 17 Jul 2003 08:52:59 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19d8Fc-00062D-00 for simple@ietf.org; Thu, 17 Jul 2003 08:52:48 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6HCpTJ02049 for ; Thu, 17 Jul 2003 15:51:29 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 15:51:28 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 15:50:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] New I-D on presence states for phones Message-ID: Thread-Topic: [Simple] New I-D on presence states for phones Thread-Index: AcNFHDyzWBftwm59RbW1zjJj2htE+QHQtdDQ To: , X-OriginalArrivalTime: 17 Jul 2003 12:50:30.0416 (UTC) FILETIME=[0105A900:01C34C62] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 15:50:29 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I think this draft defines bunch of useful information. However, I would = definitely take away the "signal-strength" attribute under the wireless = phone state. As already stated in the draft, this information is = changing frequently, so I think it is not sensible in the timescale that = SIP events work. And even if it would be possible to convey this = information, what would it mean in GPRS, WCDMA or WiFi? Is there any use = case what any watcher could in _practice_ benefit from this information? = What might be useful as an addition to "ran" is some more information on = the access-link, i.e. that the "downlink capacity class" is ~40 kbps, = and "RTT class" is ~500 ms. This _kind_ of information might give = watchers some idea what _kind_ of applications/media the device could be = able to do at the moment (although you could find that out also through = PIDF/prescaps and SDP negotiations). This kind of info is relatively = static (in the order of minutes rather than seconds), but still = changing. In any case, this would be more valuable than = "signal-strength". =20 Markus=20 > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 08 July, 2003 09:42 > To: Simple WG > Subject: [Simple] New I-D on presence states for phones >=20 >=20 > Folks, >=20 > In case folks havent seen it, I wanted to call your attention to: >=20 > http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s imple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html This draft, written by Jon and myself, defines some PIDF extensions=20 for describing phones, including traditional "black" phones, wireless=20 phones and enterprise phones. I think these will provide invaluable=20 for a device-centric view of a presentity. Comments and questions welcome. Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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-admin@ietf.org Thu Jul 17 11:44:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11967; Thu, 17 Jul 2003 11:44:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dAvd-0007Jp-00; Thu, 17 Jul 2003 11:44:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dAvX-0007JN-00; Thu, 17 Jul 2003 11:44:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dAvJ-0001D9-Jp; Thu, 17 Jul 2003 11:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dAvH-0001Cy-Tm for simple@optimus.ietf.org; Thu, 17 Jul 2003 11:43:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11953 for ; Thu, 17 Jul 2003 11:43:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dAvG-0007JJ-00 for simple@ietf.org; Thu, 17 Jul 2003 11:43:58 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19dAv6-0007JF-00 for simple@ietf.org; Thu, 17 Jul 2003 11:43:48 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6HFh489027670; Thu, 17 Jul 2003 08:43:05 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp225.cisco.com [10.61.64.225]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAT12422; Thu, 17 Jul 2003 11:43:02 -0400 (EDT) Message-ID: <3F16C405.3020900@cisco.com> 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 , jon.peterson@neustar.biz CC: simple@ietf.org References: <200306261203.IAA16528@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 11:43:01 -0400 Content-Transfer-Encoding: 7bit I think representing states appropriate to a phone is a good idea. But I have serious problems with the details of this draft: - multiple ways of representing equivalent state Typically a watcher is likely to care less what kind of phone you have, and simply want to know if you are available for a call and/or are in a call. Having to decipher three different representations of this same information is a needless hassle. Also, to the caller there is no functional difference between a POTS phone with call waiting available, and a business phone with two "lines" associated to the same number with one in use and one free. In both cases the callee is in a call but still available for a call. Representing these situations differently just makes things difficult for the watcher. - problematic extensibility model This pattern also sets the stage for more complexity in the future as new devices with different combinations of features hit the market. Suppose I come out with both home (single line) and business (multi line) voice/im phones. The home phone can do one voice call or one im call. The business phone can do two voice calls and two im calls. It isn't at all clear that I can extend any of the proposed models to accomodate my new phone in a graceful way. I may end up defining two new types for my new phones, different from these three types. Then I have problems with backward compatibility. - inclusion of useless data Identifiers for lines seems useless. They are all associated with the same phone number, and are not addressable for any purpose. Showing lines that are not in use is also pretty useless except for providing a way to know that a new call can be accepted. Data-state could be useful but I think I need to know a lot more info to predict what that might permit me to do. ALTERNATIVE: I think the following kind of structure would accomplish the same thing you have proposed yet address my issues: - a representation for a call. This would subsume your call-state, but omitting the not-in-call state. But it would also be extensible for other call attributes. This can be repeated as many times as needed to represent calls in progress, not lines. (This clearly overlaps with the dialog package - something worth discussing. It provides extra information in that it can show a call before a dialog is established. And with further extension it might provide a way to represent calls on hold, if we can figure out what that means.) - an indication of whether available for another call. In your model this seems to be represented by some call-state=not-in-call, or by call-waiting=available. But it also seems to be indicated by open. I'm uncomfortable using basic status for this, because the device may still be open for other kinds of signaling, such as subscriptions. In this new model availablily for calls could also be indicated by a call-state of available, but I see no need to model lines not in use. This is rooted in old world notions that there are some fixed number of lines. Conceivably some new attribute could be introduced for this, but I think the attributes in RPIDS already have this covered. (This still cries out for capabilities, to describe *what* I am available for, but that can be dealt with separately.) - an optional element representing the home network provider. This is appropriate for all kinds of phones. (I'm not sure why I would want to publish this, but I can go along.) - optional ran, roaming, visited-network, signal-strength attributes. (Assuming you think these make sense to provide at all.) These could be grouped under a mobile attribute or left standalone. - I consider data-state to be a capability. (If you think it is useful at all - it isn't clear to me what this implies I can do.) I would deal with it together with other capabilities, like voice, video, IM. Using the above, representations for POTS phones, business phones, and wireless phones are simply usage profiles. The watcher won't explicitly know what kind of phone it is except by inference from the kinds of presence he sees it use. To me this is a good thing. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 17 11:44:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11989 for ; Thu, 17 Jul 2003 11:44:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dAvf-0001Gw-9L for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 11:44:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HFiNNS004886 for simple-archive@odin.ietf.org; Thu, 17 Jul 2003 11:44:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dAvf-0001Gj-6M for simple-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 11:44:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11967; Thu, 17 Jul 2003 11:44:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dAvd-0007Jp-00; Thu, 17 Jul 2003 11:44:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dAvX-0007JN-00; Thu, 17 Jul 2003 11:44:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dAvJ-0001D9-Jp; Thu, 17 Jul 2003 11:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dAvH-0001Cy-Tm for simple@optimus.ietf.org; Thu, 17 Jul 2003 11:43:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11953 for ; Thu, 17 Jul 2003 11:43:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dAvG-0007JJ-00 for simple@ietf.org; Thu, 17 Jul 2003 11:43:58 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19dAv6-0007JF-00 for simple@ietf.org; Thu, 17 Jul 2003 11:43:48 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6HFh489027670; Thu, 17 Jul 2003 08:43:05 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp225.cisco.com [10.61.64.225]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAT12422; Thu, 17 Jul 2003 11:43:02 -0400 (EDT) Message-ID: <3F16C405.3020900@cisco.com> 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 , jon.peterson@neustar.biz CC: simple@ietf.org References: <200306261203.IAA16528@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Jul 2003 11:43:01 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think representing states appropriate to a phone is a good idea. But I have serious problems with the details of this draft: - multiple ways of representing equivalent state Typically a watcher is likely to care less what kind of phone you have, and simply want to know if you are available for a call and/or are in a call. Having to decipher three different representations of this same information is a needless hassle. Also, to the caller there is no functional difference between a POTS phone with call waiting available, and a business phone with two "lines" associated to the same number with one in use and one free. In both cases the callee is in a call but still available for a call. Representing these situations differently just makes things difficult for the watcher. - problematic extensibility model This pattern also sets the stage for more complexity in the future as new devices with different combinations of features hit the market. Suppose I come out with both home (single line) and business (multi line) voice/im phones. The home phone can do one voice call or one im call. The business phone can do two voice calls and two im calls. It isn't at all clear that I can extend any of the proposed models to accomodate my new phone in a graceful way. I may end up defining two new types for my new phones, different from these three types. Then I have problems with backward compatibility. - inclusion of useless data Identifiers for lines seems useless. They are all associated with the same phone number, and are not addressable for any purpose. Showing lines that are not in use is also pretty useless except for providing a way to know that a new call can be accepted. Data-state could be useful but I think I need to know a lot more info to predict what that might permit me to do. ALTERNATIVE: I think the following kind of structure would accomplish the same thing you have proposed yet address my issues: - a representation for a call. This would subsume your call-state, but omitting the not-in-call state. But it would also be extensible for other call attributes. This can be repeated as many times as needed to represent calls in progress, not lines. (This clearly overlaps with the dialog package - something worth discussing. It provides extra information in that it can show a call before a dialog is established. And with further extension it might provide a way to represent calls on hold, if we can figure out what that means.) - an indication of whether available for another call. In your model this seems to be represented by some call-state=not-in-call, or by call-waiting=available. But it also seems to be indicated by open. I'm uncomfortable using basic status for this, because the device may still be open for other kinds of signaling, such as subscriptions. In this new model availablily for calls could also be indicated by a call-state of available, but I see no need to model lines not in use. This is rooted in old world notions that there are some fixed number of lines. Conceivably some new attribute could be introduced for this, but I think the attributes in RPIDS already have this covered. (This still cries out for capabilities, to describe *what* I am available for, but that can be dealt with separately.) - an optional element representing the home network provider. This is appropriate for all kinds of phones. (I'm not sure why I would want to publish this, but I can go along.) - optional ran, roaming, visited-network, signal-strength attributes. (Assuming you think these make sense to provide at all.) These could be grouped under a mobile attribute or left standalone. - I consider data-state to be a capability. (If you think it is useful at all - it isn't clear to me what this implies I can do.) I would deal with it together with other capabilities, like voice, video, IM. Using the above, representations for POTS phones, business phones, and wireless phones are simply usage profiles. The watcher won't explicitly know what kind of phone it is except by inference from the kinds of presence he sees it use. To me this is a good thing. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jul 18 06:32:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26190; Fri, 18 Jul 2003 06:32:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dSX1-0007ZV-00; Fri, 18 Jul 2003 06:32:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dSWw-0007ZS-00; Fri, 18 Jul 2003 06:32:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSWv-0008L8-Hd; Fri, 18 Jul 2003 06:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSW1-0008JX-JD for simple@optimus.ietf.org; Fri, 18 Jul 2003 06:31:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26168 for ; Fri, 18 Jul 2003 06:31:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dSVx-0007Yx-00 for simple@ietf.org; Fri, 18 Jul 2003 06:31:01 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19dSVh-0007Yi-00 for simple@ietf.org; Fri, 18 Jul 2003 06:30:45 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6IAU9kM013872; Fri, 18 Jul 2003 06:30:09 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6IAU8g20059; Fri, 18 Jul 2003 06:30:09 -0400 Message-ID: <3F17CB38.6060806@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] comments on rpids-01 References: <3F116866.1090908@dynamicsoft.com> <3F117445.5080506@cs.columbia.edu> <3F134C50.7080603@dynamicsoft.com> In-Reply-To: <3F134C50.7080603@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 18 Jul 2003 06:26:00 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > What I mean is, these namespaces should be within the pidf umbrella. The > suggestion above is: > > urn:ietf:params:xml:ns:pidf:sip-rpids > > i.e., its an additional namespace component below pidf. Thus, they are > all within different namespaces (..pidf:predictive, ..pidf:capabilities, > etc.). I'm not sure I'm reading the PIDF spec correctly, but it seems to suggest that extensions are *all* within the status namespace (Section 4.2.5), as in the example given in the spec "The URN 'urn:ietf:params:xml:ns:pidf:status' has been defined as a namespace URI for extensions standardized by the IETF, and new values in this namespace must be defined by a standards-track RFC." [elided] Maybe Jon can comment on what is intended here. (I guess it doesn't say that other namespaces, as in 4.2.4, cannot be standardized, but this is rather unclear in the PIDF text.) However, forcing a single extension namespace avoids that multiple standardized extensions all define elements with the same name, which would be confusing even with the namespace qualifier. >> >> Wouldn't this be an orthogonal item, as in >> "in-transit-motorvehicle,headset"? > Yes. I hadnt meant it to be part of the previous comment, sorry. Given the IETF discussion, I wonder if this is really a phone status. If anything, it seems to be a capability (since it might make sense to ask for "mobile, but only with headset"). >> Why? The URI tells you how to retrieve it, the Content-Type what >> format it is and content-negotiation lets the watcher and owner of the >> information negotiate which format they both can deal with. After all, >> a single (HTTP) URI can point to objects of many different content >> types, languages, etc. > > > OK, then I think we need to add mention that we are using http content > negotiation (though I dont know if this exists in practice in web > servers). More importantly, do we need a baseline mandatory-to-implement > type? Clearly, content-negotation is not exactly widely available, but I'm concerned about replicating this functionality in bits and pieces. I don't think that's technically advisable and may cause delays during the later document stages. The HTTP spec does not mandate support for particular content types; given the politics around GIF and PNG, this might be a minefield. Maybe this should be part of the device requirements style documents such as the one Henry Sinnreich is putting together for phones. I'm not opposed to mandating a format (which?), but don't want to get dragged into a everybody-uses-GIF vs. GIF-is-still-patent-encumbered-in-Europe debate. > To me, the time that the tuple changed is not interesting at all. I > don't want to know that "something changes 2 minutes ago". Its much more > useful for me to know that "you got on airplace 2 minutes ago" or, "you > got home two minutes ago". Barring objections, I will make these parameters of 'activity', 'placetype', and 'privacy'. I don't think they make sense elsewhere. >> How does this differ from a 'public' place like a mall or park? We >> already have public+quiet for the subset of public places where >> ringing cell phones or chatting are inappropriate. > > > It conveys some amount of information on the range of where a user might > be. "public" and "mall" means you are within the physical boundaries of > the mall, and perhaps I can look for you. "public" and "outdoors" means > you could be on the streets of manhattan, a much different size place. > > I dont feel that strongly on this one. I suggested it primarily because > it actually exists on phones I am aware of, and it would be nice to have > a standard way of representing what exists today. I've added additional options to the 'placetype', including outdoors, and moved the vehicle designation (ship, car, airplane, ...) there as it seems to fit better in that context. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jul 18 06:32:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26216 for ; Fri, 18 Jul 2003 06:32:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSX6-0008Mo-DJ for simple-archive@odin.ietf.org; Fri, 18 Jul 2003 06:32:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IAWCrP032156 for simple-archive@odin.ietf.org; Fri, 18 Jul 2003 06:32:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSX6-0008MZ-9p for simple-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 06:32:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26190; Fri, 18 Jul 2003 06:32:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dSX1-0007ZV-00; Fri, 18 Jul 2003 06:32:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dSWw-0007ZS-00; Fri, 18 Jul 2003 06:32:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSWv-0008L8-Hd; Fri, 18 Jul 2003 06:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSW1-0008JX-JD for simple@optimus.ietf.org; Fri, 18 Jul 2003 06:31:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26168 for ; Fri, 18 Jul 2003 06:31:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dSVx-0007Yx-00 for simple@ietf.org; Fri, 18 Jul 2003 06:31:01 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19dSVh-0007Yi-00 for simple@ietf.org; Fri, 18 Jul 2003 06:30:45 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6IAU9kM013872; Fri, 18 Jul 2003 06:30:09 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6IAU8g20059; Fri, 18 Jul 2003 06:30:09 -0400 Message-ID: <3F17CB38.6060806@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] comments on rpids-01 References: <3F116866.1090908@dynamicsoft.com> <3F117445.5080506@cs.columbia.edu> <3F134C50.7080603@dynamicsoft.com> In-Reply-To: <3F134C50.7080603@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 18 Jul 2003 06:26:00 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > What I mean is, these namespaces should be within the pidf umbrella. The > suggestion above is: > > urn:ietf:params:xml:ns:pidf:sip-rpids > > i.e., its an additional namespace component below pidf. Thus, they are > all within different namespaces (..pidf:predictive, ..pidf:capabilities, > etc.). I'm not sure I'm reading the PIDF spec correctly, but it seems to suggest that extensions are *all* within the status namespace (Section 4.2.5), as in the example given in the spec "The URN 'urn:ietf:params:xml:ns:pidf:status' has been defined as a namespace URI for extensions standardized by the IETF, and new values in this namespace must be defined by a standards-track RFC." [elided] Maybe Jon can comment on what is intended here. (I guess it doesn't say that other namespaces, as in 4.2.4, cannot be standardized, but this is rather unclear in the PIDF text.) However, forcing a single extension namespace avoids that multiple standardized extensions all define elements with the same name, which would be confusing even with the namespace qualifier. >> >> Wouldn't this be an orthogonal item, as in >> "in-transit-motorvehicle,headset"? > Yes. I hadnt meant it to be part of the previous comment, sorry. Given the IETF discussion, I wonder if this is really a phone status. If anything, it seems to be a capability (since it might make sense to ask for "mobile, but only with headset"). >> Why? The URI tells you how to retrieve it, the Content-Type what >> format it is and content-negotiation lets the watcher and owner of the >> information negotiate which format they both can deal with. After all, >> a single (HTTP) URI can point to objects of many different content >> types, languages, etc. > > > OK, then I think we need to add mention that we are using http content > negotiation (though I dont know if this exists in practice in web > servers). More importantly, do we need a baseline mandatory-to-implement > type? Clearly, content-negotation is not exactly widely available, but I'm concerned about replicating this functionality in bits and pieces. I don't think that's technically advisable and may cause delays during the later document stages. The HTTP spec does not mandate support for particular content types; given the politics around GIF and PNG, this might be a minefield. Maybe this should be part of the device requirements style documents such as the one Henry Sinnreich is putting together for phones. I'm not opposed to mandating a format (which?), but don't want to get dragged into a everybody-uses-GIF vs. GIF-is-still-patent-encumbered-in-Europe debate. > To me, the time that the tuple changed is not interesting at all. I > don't want to know that "something changes 2 minutes ago". Its much more > useful for me to know that "you got on airplace 2 minutes ago" or, "you > got home two minutes ago". Barring objections, I will make these parameters of 'activity', 'placetype', and 'privacy'. I don't think they make sense elsewhere. >> How does this differ from a 'public' place like a mall or park? We >> already have public+quiet for the subset of public places where >> ringing cell phones or chatting are inappropriate. > > > It conveys some amount of information on the range of where a user might > be. "public" and "mall" means you are within the physical boundaries of > the mall, and perhaps I can look for you. "public" and "outdoors" means > you could be on the streets of manhattan, a much different size place. > > I dont feel that strongly on this one. I suggested it primarily because > it actually exists on phones I am aware of, and it would be nice to have > a standard way of representing what exists today. I've added additional options to the 'placetype', including outdoors, and moved the vehicle designation (ship, car, airplane, ...) there as it seems to fit better in that context. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jul 18 10:51:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03124; Fri, 18 Jul 2003 10:51:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dWZe-0001S5-00; Fri, 18 Jul 2003 10:51:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dWZZ-0001S2-00; Fri, 18 Jul 2003 10:51:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dWZZ-0001TP-2G; Fri, 18 Jul 2003 10:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dWZI-0001T6-KV for simple@optimus.ietf.org; Fri, 18 Jul 2003 10:50:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03120 for ; Fri, 18 Jul 2003 10:50:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dWZB-0001Rt-00 for simple@ietf.org; Fri, 18 Jul 2003 10:50:37 -0400 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 19dWZ0-0001RT-00 for simple@ietf.org; Fri, 18 Jul 2003 10:50:26 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h6IEn3LX025495; Fri, 18 Jul 2003 09:49:03 -0500 (CDT) Message-ID: <3F1808DD.B27E4256@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] New I-D on presence states for phones References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 18 Jul 2003 09:49:01 -0500 Content-Transfer-Encoding: 7bit Hello, From a user's point of view, I am not sure if "signal strength" is not a valuable information to have. Granted, it may be changing very frequently, but you can always limit how often it is updated. I am not sure however, if "signal strength" can be a valid attribute of the state of the phone. It is descriptive, more of the environment the phone is in, than the phone itself. Regards, Alex. Markus.Isomaki@nokia.com wrote: > Hi, > > I think this draft defines bunch of useful information. However, I would definitely take away the "signal-strength" attribute under the wireless phone state. As already stated in the draft, this information is changing frequently, so I think it is not sensible in the timescale that SIP events work. And even if it would be possible to convey this information, what would it mean in GPRS, WCDMA or WiFi? Is there any use case what any watcher could in _practice_ benefit from this information? > > What might be useful as an addition to "ran" is some more information on the access-link, i.e. that the "downlink capacity class" is ~40 kbps, and "RTT class" is ~500 ms. This _kind_ of information might give watchers some idea what _kind_ of applications/media the device could be able to do at the moment (although you could find that out also through PIDF/prescaps and SDP negotiations). This kind of info is relatively static (in the order of minutes rather than seconds), but still changing. In any case, this would be more valuable than "signal-strength". > > Markus > > > -----Original Message----- > > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: 08 July, 2003 09:42 > > To: Simple WG > > Subject: [Simple] New I-D on presence states for phones > > > > > > Folks, > > > > In case folks havent seen it, I wanted to call your attention to: > > > > http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s > imple-pidf-phone-00.txt > http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt > http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html > > This draft, written by Jon and myself, defines some PIDF extensions > for describing phones, including traditional "black" phones, wireless > phones and enterprise phones. I think these will provide invaluable > for a device-centric view of a presentity. > > Comments and questions welcome. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > 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 exim@www1.ietf.org Fri Jul 18 10:51:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03140 for ; Fri, 18 Jul 2003 10:51:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dWZj-0001V4-7I for simple-archive@odin.ietf.org; Fri, 18 Jul 2003 10:51:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IEpB5i005762 for simple-archive@odin.ietf.org; Fri, 18 Jul 2003 10:51:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dWZh-0001Ur-NI for simple-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 10:51:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03124; Fri, 18 Jul 2003 10:51:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dWZe-0001S5-00; Fri, 18 Jul 2003 10:51:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dWZZ-0001S2-00; Fri, 18 Jul 2003 10:51:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dWZZ-0001TP-2G; Fri, 18 Jul 2003 10:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dWZI-0001T6-KV for simple@optimus.ietf.org; Fri, 18 Jul 2003 10:50:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03120 for ; Fri, 18 Jul 2003 10:50:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dWZB-0001Rt-00 for simple@ietf.org; Fri, 18 Jul 2003 10:50:37 -0400 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 19dWZ0-0001RT-00 for simple@ietf.org; Fri, 18 Jul 2003 10:50:26 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h6IEn3LX025495; Fri, 18 Jul 2003 09:49:03 -0500 (CDT) Message-ID: <3F1808DD.B27E4256@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] New I-D on presence states for phones References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 18 Jul 2003 09:49:01 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, From a user's point of view, I am not sure if "signal strength" is not a valuable information to have. Granted, it may be changing very frequently, but you can always limit how often it is updated. I am not sure however, if "signal strength" can be a valid attribute of the state of the phone. It is descriptive, more of the environment the phone is in, than the phone itself. Regards, Alex. Markus.Isomaki@nokia.com wrote: > Hi, > > I think this draft defines bunch of useful information. However, I would definitely take away the "signal-strength" attribute under the wireless phone state. As already stated in the draft, this information is changing frequently, so I think it is not sensible in the timescale that SIP events work. And even if it would be possible to convey this information, what would it mean in GPRS, WCDMA or WiFi? Is there any use case what any watcher could in _practice_ benefit from this information? > > What might be useful as an addition to "ran" is some more information on the access-link, i.e. that the "downlink capacity class" is ~40 kbps, and "RTT class" is ~500 ms. This _kind_ of information might give watchers some idea what _kind_ of applications/media the device could be able to do at the moment (although you could find that out also through PIDF/prescaps and SDP negotiations). This kind of info is relatively static (in the order of minutes rather than seconds), but still changing. In any case, this would be more valuable than "signal-strength". > > Markus > > > -----Original Message----- > > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: 08 July, 2003 09:42 > > To: Simple WG > > Subject: [Simple] New I-D on presence states for phones > > > > > > Folks, > > > > In case folks havent seen it, I wanted to call your attention to: > > > > http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s > imple-pidf-phone-00.txt > http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt > http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html > > This draft, written by Jon and myself, defines some PIDF extensions > for describing phones, including traditional "black" phones, wireless > phones and enterprise phones. I think these will provide invaluable > for a device-centric view of a presentity. > > Comments and questions welcome. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > 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-admin@ietf.org Fri Jul 18 11:25:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03883; Fri, 18 Jul 2003 11:25:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dX6a-0001hi-00; Fri, 18 Jul 2003 11:25:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dX6V-0001hf-00; Fri, 18 Jul 2003 11:25:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dX6T-0002WU-H1; Fri, 18 Jul 2003 11:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dX6E-0002WD-Qd for simple@optimus.ietf.org; Fri, 18 Jul 2003 11:24:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03851 for ; Fri, 18 Jul 2003 11:24:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dX6D-0001hN-00 for simple@ietf.org; Fri, 18 Jul 2003 11:24:45 -0400 Received: from [203.194.209.81] (helo=website12.com) by ietf-mx with smtp (Exim 4.12) id 19dX5x-0001h2-00 for simple@ietf.org; Fri, 18 Jul 2003 11:24:30 -0400 Received: (qmail 31920 invoked from network); 18 Jul 2003 15:23:56 -0000 Received: from unknown (HELO vikas) (203.145.189.132) by website12.com with SMTP; 18 Jul 2003 15:23:56 -0000 From: "Vikas Tandon" To: Subject: RE: [Simple] New I-D on presence states for phones Message-ID: <000001c34daa$61318440$6277fea9@vikas> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal In-Reply-To: <3F1808DD.B27E4256@alcatel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 18 Jul 2003 21:01:05 -0700 Content-Transfer-Encoding: 7bit Hi Markus, Alex and SIMPLE experts, As rightly pointed out, signal strength can change several times within a second based on the attenuation factors and even what is displayed on the phone is a best-possible view. Having lower signal strength however might not be a very useful information to the watcher. Additionally and noticeably, we are talking about adding more processing on the client side. If we were to add some of the phone status attributes, we should look at ones which display what the user wants to be communicated like - I can set: My phone is switched off without letting others know that actually I'm on!! These category of information might be a useful information on the network side for delivery purpose but not for the watcher, and moreover information of this category as best picked up from the network nodes themselves rather than making the client thicker. Regards, Vikas -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Alex Audu Sent: Friday, July 18, 2003 7:49 AM To: Markus.Isomaki@nokia.com Cc: jdrosen@dynamicsoft.com; simple@ietf.org Subject: Re: [Simple] New I-D on presence states for phones Hello, From a user's point of view, I am not sure if "signal strength" is not a valuable information to have. Granted, it may be changing very frequently, but you can always limit how often it is updated. I am not sure however, if "signal strength" can be a valid attribute of the state of the phone. It is descriptive, more of the environment the phone is in, than the phone itself. Regards, Alex. Markus.Isomaki@nokia.com wrote: > Hi, > > I think this draft defines bunch of useful information. However, I > would definitely take away the "signal-strength" attribute under the > wireless phone state. As already stated in the draft, this information > is changing frequently, so I think it is not sensible in the timescale > that SIP events work. And even if it would be possible to convey this > information, what would it mean in GPRS, WCDMA or WiFi? Is there any > use case what any watcher could in _practice_ benefit from this > information? > > What might be useful as an addition to "ran" is some more information > on the access-link, i.e. that the "downlink capacity class" is ~40 > kbps, and "RTT class" is ~500 ms. This _kind_ of information might > give watchers some idea what _kind_ of applications/media the device > could be able to do at the moment (although you could find that out > also through PIDF/prescaps and SDP negotiations). This kind of info is > relatively static (in the order of minutes rather than seconds), but > still changing. In any case, this would be more valuable than > "signal-strength". > > Markus > > > -----Original Message----- > > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: 08 July, 2003 09:42 > > To: Simple WG > > Subject: [Simple] New I-D on presence states for phones > > > > > > Folks, > > > > In case folks havent seen it, I wanted to call your attention to: > > > > http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s > imple-pidf-phone-00.txt > http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt > http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html > > This draft, written by Jon and myself, defines some PIDF extensions > for describing phones, including traditional "black" phones, wireless > phones and enterprise phones. I think these will provide invaluable > for a device-centric view of a presentity. > > Comments and questions welcome. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > 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 exim@www1.ietf.org Fri Jul 18 11:25:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03901 for ; Fri, 18 Jul 2003 11:25:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dX6c-0002a0-6o for simple-archive@odin.ietf.org; Fri, 18 Jul 2003 11:25:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IFPA8s009915 for simple-archive@odin.ietf.org; Fri, 18 Jul 2003 11:25:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dX6c-0002Zq-3w for simple-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 11:25:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03883; Fri, 18 Jul 2003 11:25:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dX6a-0001hi-00; Fri, 18 Jul 2003 11:25:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dX6V-0001hf-00; Fri, 18 Jul 2003 11:25:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dX6T-0002WU-H1; Fri, 18 Jul 2003 11:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dX6E-0002WD-Qd for simple@optimus.ietf.org; Fri, 18 Jul 2003 11:24:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03851 for ; Fri, 18 Jul 2003 11:24:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dX6D-0001hN-00 for simple@ietf.org; Fri, 18 Jul 2003 11:24:45 -0400 Received: from [203.194.209.81] (helo=website12.com) by ietf-mx with smtp (Exim 4.12) id 19dX5x-0001h2-00 for simple@ietf.org; Fri, 18 Jul 2003 11:24:30 -0400 Received: (qmail 31920 invoked from network); 18 Jul 2003 15:23:56 -0000 Received: from unknown (HELO vikas) (203.145.189.132) by website12.com with SMTP; 18 Jul 2003 15:23:56 -0000 From: "Vikas Tandon" To: Subject: RE: [Simple] New I-D on presence states for phones Message-ID: <000001c34daa$61318440$6277fea9@vikas> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal In-Reply-To: <3F1808DD.B27E4256@alcatel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 18 Jul 2003 21:01:05 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Markus, Alex and SIMPLE experts, As rightly pointed out, signal strength can change several times within a second based on the attenuation factors and even what is displayed on the phone is a best-possible view. Having lower signal strength however might not be a very useful information to the watcher. Additionally and noticeably, we are talking about adding more processing on the client side. If we were to add some of the phone status attributes, we should look at ones which display what the user wants to be communicated like - I can set: My phone is switched off without letting others know that actually I'm on!! These category of information might be a useful information on the network side for delivery purpose but not for the watcher, and moreover information of this category as best picked up from the network nodes themselves rather than making the client thicker. Regards, Vikas -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Alex Audu Sent: Friday, July 18, 2003 7:49 AM To: Markus.Isomaki@nokia.com Cc: jdrosen@dynamicsoft.com; simple@ietf.org Subject: Re: [Simple] New I-D on presence states for phones Hello, From a user's point of view, I am not sure if "signal strength" is not a valuable information to have. Granted, it may be changing very frequently, but you can always limit how often it is updated. I am not sure however, if "signal strength" can be a valid attribute of the state of the phone. It is descriptive, more of the environment the phone is in, than the phone itself. Regards, Alex. Markus.Isomaki@nokia.com wrote: > Hi, > > I think this draft defines bunch of useful information. However, I > would definitely take away the "signal-strength" attribute under the > wireless phone state. As already stated in the draft, this information > is changing frequently, so I think it is not sensible in the timescale > that SIP events work. And even if it would be possible to convey this > information, what would it mean in GPRS, WCDMA or WiFi? Is there any > use case what any watcher could in _practice_ benefit from this > information? > > What might be useful as an addition to "ran" is some more information > on the access-link, i.e. that the "downlink capacity class" is ~40 > kbps, and "RTT class" is ~500 ms. This _kind_ of information might > give watchers some idea what _kind_ of applications/media the device > could be able to do at the moment (although you could find that out > also through PIDF/prescaps and SDP negotiations). This kind of info is > relatively static (in the order of minutes rather than seconds), but > still changing. In any case, this would be more valuable than > "signal-strength". > > Markus > > > -----Original Message----- > > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: 08 July, 2003 09:42 > > To: Simple WG > > Subject: [Simple] New I-D on presence states for phones > > > > > > Folks, > > > > In case folks havent seen it, I wanted to call your attention to: > > > > http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s > imple-pidf-phone-00.txt > http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt > http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html > > This draft, written by Jon and myself, defines some PIDF extensions > for describing phones, including traditional "black" phones, wireless > phones and enterprise phones. I think these will provide invaluable > for a device-centric view of a presentity. > > Comments and questions welcome. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > 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-admin@ietf.org Mon Jul 21 16:36:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10070; Mon, 21 Jul 2003 16:36:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ehOW-00069a-00; Mon, 21 Jul 2003 16:36:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ehOQ-00069R-00; Mon, 21 Jul 2003 16:36:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ehO5-0004wG-Ts; Mon, 21 Jul 2003 16:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ehNi-0004vm-6z for simple@optimus.ietf.org; Mon, 21 Jul 2003 16:35:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10058 for ; Mon, 21 Jul 2003 16:35:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ehNg-00069H-00 for simple@ietf.org; Mon, 21 Jul 2003 16:35:36 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ehNV-00068t-00 for simple@ietf.org; Mon, 21 Jul 2003 16:35:25 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6LKYlCK000578; Mon, 21 Jul 2003 16:34:47 -0400 (EDT) Message-ID: <3F1C4E62.5060700@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] A proposal for xcap direction References: <2038BCC78B1AD641891A0D1AE133DBB701796F19@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796F19@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 21 Jul 2003 16:34:42 -0400 Content-Transfer-Encoding: 7bit It seems that people are supportive of this direction, so I am going to go ahead and start working on an xcap revision which works along these lines. I'll send a separate note on how to approach xpath. some responses inline: hisham.khartabil@nokia.com wrote: >> 2. Every operation is a PUT. No POST. The IETF has established >> guidelines for usage of HTTP as a substrate for other protocols. >> One of the tell-tale signs of misuse is that you are using POST >> as a way to tunnel operations. POST has a well defined semantic - >> you are sending form data to a process that uses the data as >> input. In the current xcap draft, the POST operation is used to >> insert a new element, whereas PUT is used to modify an existing >> one. We need to only use PUT, since there really is no form >> processing engine here. However, we still need an insert and a >> modify operation. How to do that? >> >> Well, the proposed direction gives us the answer. How does HTTP >> support it? Simple. If you PUT a document to a URI that >> represents a resource that exists, the resource is replaced. If >> you PUT a document to a URI that doesnt exist, the resource is >> created (i.e., inserted). Now, our main problem is that there is >> no way to specify WHERE the new resource gets inserted within the >> "directory". For regular filesystems, it doesnt matter. For us, >> it does. So, we will have a constraint that if you do an insert >> operation on an XML element, you have to do it in a place where >> either (1) the positioning is implied by the schema, or (2) the >> positioning isnt important. Again, this just means careful schema >> design. You will note that in both the authorization usage and >> buddy list usage, there are many key points in the schema where >> you can insert things where either the ordering is dictated or >> not important. > > > I'm confused. Are you talking about PUTting a document or an XML > element? I thought the XML element is inserted in the location > pointed to bu the XPATH expression. PUT would allow you to put either a document or an XML element. > > >> 3. We remove the ability to have server computed data (not >> possible with PUT). That means that creating a buddy list >> requires the client to either (1) select the URI so its unique, >> (2) obtain the URI through some other means, (3) put the data >> without a URI, have the server set the URI, and then have the >> client fetch the data with the URI filled in. None of them are >> pretty. Its a limitation with the approach. > > > I thought option 3 was the server computed data. What is different? Whats different is that the POST request contained the XML elements without the server-provided URI, and the POST response contained the filled-in URI. In the proposed approach, the server is just a repository. If you PUT the document without the URI, there is no URI. A separate application (which could be implemented ontop of the xcap server) would watch for the PUT. When it sees it, it goes and does a PUT of its own, adding the URI. To find out the assigned uri, the client needs to either poll or use the xcap package once the change is made. > > > >> 3. We may be able to keep the ability to have servers enforce >> data constraints that the schema cannot represent. Not sure its >> useful. > > > It might be useful. Cases are that you have 2 elements, both are > optional, but at least one MUST exist. I don't think you can do > that with schema. Yeah, I dont think we can do that with schema. But, I'm not sure we have that case now. > > >> 4. We pursue a longer term solution of working with webdav by >> adding partial patches through some kind of webdav extension. >> This would be xcap 2.0. > > > > I fear that this might take longer than 1 year, maily due to the > fact that we will have version 1.0 that everyone is deploying and > are not interested in v2.0 for a while to come. Well, thats OK then. If the v1.0 solution solves everyones problems with minimal complexity, that sounds good in my book. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 21 16:36:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10102 for ; Mon, 21 Jul 2003 16:36:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ehOZ-0004zu-2w for simple-archive@odin.ietf.org; Mon, 21 Jul 2003 16:36:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LKaVBX019206 for simple-archive@odin.ietf.org; Mon, 21 Jul 2003 16:36:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ehOY-0004zh-Tg for simple-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 16:36:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10070; Mon, 21 Jul 2003 16:36:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ehOW-00069a-00; Mon, 21 Jul 2003 16:36:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ehOQ-00069R-00; Mon, 21 Jul 2003 16:36:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ehO5-0004wG-Ts; Mon, 21 Jul 2003 16:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ehNi-0004vm-6z for simple@optimus.ietf.org; Mon, 21 Jul 2003 16:35:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10058 for ; Mon, 21 Jul 2003 16:35:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ehNg-00069H-00 for simple@ietf.org; Mon, 21 Jul 2003 16:35:36 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ehNV-00068t-00 for simple@ietf.org; Mon, 21 Jul 2003 16:35:25 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6LKYlCK000578; Mon, 21 Jul 2003 16:34:47 -0400 (EDT) Message-ID: <3F1C4E62.5060700@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] A proposal for xcap direction References: <2038BCC78B1AD641891A0D1AE133DBB701796F19@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796F19@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 21 Jul 2003 16:34:42 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It seems that people are supportive of this direction, so I am going to go ahead and start working on an xcap revision which works along these lines. I'll send a separate note on how to approach xpath. some responses inline: hisham.khartabil@nokia.com wrote: >> 2. Every operation is a PUT. No POST. The IETF has established >> guidelines for usage of HTTP as a substrate for other protocols. >> One of the tell-tale signs of misuse is that you are using POST >> as a way to tunnel operations. POST has a well defined semantic - >> you are sending form data to a process that uses the data as >> input. In the current xcap draft, the POST operation is used to >> insert a new element, whereas PUT is used to modify an existing >> one. We need to only use PUT, since there really is no form >> processing engine here. However, we still need an insert and a >> modify operation. How to do that? >> >> Well, the proposed direction gives us the answer. How does HTTP >> support it? Simple. If you PUT a document to a URI that >> represents a resource that exists, the resource is replaced. If >> you PUT a document to a URI that doesnt exist, the resource is >> created (i.e., inserted). Now, our main problem is that there is >> no way to specify WHERE the new resource gets inserted within the >> "directory". For regular filesystems, it doesnt matter. For us, >> it does. So, we will have a constraint that if you do an insert >> operation on an XML element, you have to do it in a place where >> either (1) the positioning is implied by the schema, or (2) the >> positioning isnt important. Again, this just means careful schema >> design. You will note that in both the authorization usage and >> buddy list usage, there are many key points in the schema where >> you can insert things where either the ordering is dictated or >> not important. > > > I'm confused. Are you talking about PUTting a document or an XML > element? I thought the XML element is inserted in the location > pointed to bu the XPATH expression. PUT would allow you to put either a document or an XML element. > > >> 3. We remove the ability to have server computed data (not >> possible with PUT). That means that creating a buddy list >> requires the client to either (1) select the URI so its unique, >> (2) obtain the URI through some other means, (3) put the data >> without a URI, have the server set the URI, and then have the >> client fetch the data with the URI filled in. None of them are >> pretty. Its a limitation with the approach. > > > I thought option 3 was the server computed data. What is different? Whats different is that the POST request contained the XML elements without the server-provided URI, and the POST response contained the filled-in URI. In the proposed approach, the server is just a repository. If you PUT the document without the URI, there is no URI. A separate application (which could be implemented ontop of the xcap server) would watch for the PUT. When it sees it, it goes and does a PUT of its own, adding the URI. To find out the assigned uri, the client needs to either poll or use the xcap package once the change is made. > > > >> 3. We may be able to keep the ability to have servers enforce >> data constraints that the schema cannot represent. Not sure its >> useful. > > > It might be useful. Cases are that you have 2 elements, both are > optional, but at least one MUST exist. I don't think you can do > that with schema. Yeah, I dont think we can do that with schema. But, I'm not sure we have that case now. > > >> 4. We pursue a longer term solution of working with webdav by >> adding partial patches through some kind of webdav extension. >> This would be xcap 2.0. > > > > I fear that this might take longer than 1 year, maily due to the > fact that we will have version 1.0 that everyone is deploying and > are not interested in v2.0 for a while to come. Well, thats OK then. If the v1.0 solution solves everyones problems with minimal complexity, that sounds good in my book. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 21 17:10:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10946; Mon, 21 Jul 2003 17:10:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ehv7-0006Oz-00; Mon, 21 Jul 2003 17:10:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ehv1-0006Ow-00; Mon, 21 Jul 2003 17:10:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ehuy-00074m-Rj; Mon, 21 Jul 2003 17:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ehuA-00070p-5P for simple@optimus.ietf.org; Mon, 21 Jul 2003 17:09:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10917 for ; Mon, 21 Jul 2003 17:09:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ehu7-0006OF-00 for simple@ietf.org; Mon, 21 Jul 2003 17:09:08 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ehtx-0006O2-00 for simple@ietf.org; Mon, 21 Jul 2003 17:08:57 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6LL85CK000673; Mon, 21 Jul 2003 17:08:05 -0400 (EDT) Message-ID: <3F1C5631.1070102@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: hgs@cs.columbia.edu, simple@ietf.org Subject: reducing xcap-auth scope, was: Re: [Simple] A proposal for xcap direction References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 21 Jul 2003 17:08:01 -0400 Content-Transfer-Encoding: 7bit inline. Markus.Isomaki@nokia.com wrote: > Also the timing of this work is very important. It would be good to > get the basic XCAP specs not too long after PUBLISH and MSRP, so > that the first _standards based_ SIP IM & Presence solutions could > also use standardized data manipulation. For instance I don't > believe that it would make sense to put SIP IM & P in the wireless > terminals (for "mass market") before XCAP gets to RFC. I agree. We have a pressing need to finish publish, xcap, xcap buddy list, xcap auth, rpids, and message sessions. I believe that xcap-package, filtering, and partial notifications are important but are not as critical. As such, I think we should seriously consider de-scoping and simplification wherever possible to accelerate stuff. > > Another comment I have is that we could still at least TRY to > simplify the baseline solution for presence authorization. > Hopefully the most complex rules could be left as optional > extensions. I agree. I would suggest removing the following things: * the accept-if conditions related to filters (requested-namespace, requested-element, requested-tuple). * I could be convinced to remove accept-if altogether. I do think that accepting subscriptions based on durations (to allow only fetches), is pretty useful. Other opinions? * we could remove the rule-permissions altogether. This would get around most of the complexities of naming and addressing of XML elements. * I think we still need content-permissions. We could descope show-element so that you can only give permission by element name, not by xpath expression. What do we lose if we do this? If a presence doc has two tuples, and you wanted to allow a watcher to see "placetype" in one, but not the other, you couldnt do it. you could only allow or disallow "placetype" for any tuple. I think thats OK for the first version. * We could remove show-values, as it also requires xpath. * I think we still need transformational attributes. I would recommend that "set-element" and "change-value-from" would specify the element by element-name (i.e., "placetype"), and would impact all instances of that element within the presence document. What do people think of this scope reduction? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 21 17:10:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10987 for ; Mon, 21 Jul 2003 17:10:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ehvM-0007Ch-DO for simple-archive@odin.ietf.org; Mon, 21 Jul 2003 17:10:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LLAONd027684 for simple-archive@odin.ietf.org; Mon, 21 Jul 2003 17:10:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ehvM-0007CR-6v for simple-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 17:10:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10946; Mon, 21 Jul 2003 17:10:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ehv7-0006Oz-00; Mon, 21 Jul 2003 17:10:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ehv1-0006Ow-00; Mon, 21 Jul 2003 17:10:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ehuy-00074m-Rj; Mon, 21 Jul 2003 17:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ehuA-00070p-5P for simple@optimus.ietf.org; Mon, 21 Jul 2003 17:09:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10917 for ; Mon, 21 Jul 2003 17:09:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ehu7-0006OF-00 for simple@ietf.org; Mon, 21 Jul 2003 17:09:08 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ehtx-0006O2-00 for simple@ietf.org; Mon, 21 Jul 2003 17:08:57 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6LL85CK000673; Mon, 21 Jul 2003 17:08:05 -0400 (EDT) Message-ID: <3F1C5631.1070102@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: hgs@cs.columbia.edu, simple@ietf.org Subject: reducing xcap-auth scope, was: Re: [Simple] A proposal for xcap direction References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 21 Jul 2003 17:08:01 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Markus.Isomaki@nokia.com wrote: > Also the timing of this work is very important. It would be good to > get the basic XCAP specs not too long after PUBLISH and MSRP, so > that the first _standards based_ SIP IM & Presence solutions could > also use standardized data manipulation. For instance I don't > believe that it would make sense to put SIP IM & P in the wireless > terminals (for "mass market") before XCAP gets to RFC. I agree. We have a pressing need to finish publish, xcap, xcap buddy list, xcap auth, rpids, and message sessions. I believe that xcap-package, filtering, and partial notifications are important but are not as critical. As such, I think we should seriously consider de-scoping and simplification wherever possible to accelerate stuff. > > Another comment I have is that we could still at least TRY to > simplify the baseline solution for presence authorization. > Hopefully the most complex rules could be left as optional > extensions. I agree. I would suggest removing the following things: * the accept-if conditions related to filters (requested-namespace, requested-element, requested-tuple). * I could be convinced to remove accept-if altogether. I do think that accepting subscriptions based on durations (to allow only fetches), is pretty useful. Other opinions? * we could remove the rule-permissions altogether. This would get around most of the complexities of naming and addressing of XML elements. * I think we still need content-permissions. We could descope show-element so that you can only give permission by element name, not by xpath expression. What do we lose if we do this? If a presence doc has two tuples, and you wanted to allow a watcher to see "placetype" in one, but not the other, you couldnt do it. you could only allow or disallow "placetype" for any tuple. I think thats OK for the first version. * We could remove show-values, as it also requires xpath. * I think we still need transformational attributes. I would recommend that "set-element" and "change-value-from" would specify the element by element-name (i.e., "placetype"), and would impact all instances of that element within the presence document. What do people think of this scope reduction? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 21 17:21:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11176; Mon, 21 Jul 2003 17:21:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ei5k-0006Ru-00; Mon, 21 Jul 2003 17:21:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ei5f-0006Rr-00; Mon, 21 Jul 2003 17:21:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ei5c-0007Lj-S1; Mon, 21 Jul 2003 17:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ei5I-0007LN-A4 for simple@optimus.ietf.org; Mon, 21 Jul 2003 17:20:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11169 for ; Mon, 21 Jul 2003 17:20:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ei5G-0006Rj-00 for simple@ietf.org; Mon, 21 Jul 2003 17:20:38 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ei55-0006RK-00 for simple@ietf.org; Mon, 21 Jul 2003 17:20:27 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6LLJbCK000683 for ; Mon, 21 Jul 2003 17:19:37 -0400 (EDT) Message-ID: <3F1C58E4.5050608@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap and xpath Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 21 Jul 2003 17:19:32 -0400 Content-Transfer-Encoding: 7bit Folks, During the meeting, Ted had suggested a potential simplification in xcap. Namely, don't use xpath at all. If we know ahead of times the specific "break points" in the schema where we know we will do atomic operations (I.e., buddies), just define each buddy as a resource, and define the buddy list as a separate resource, and specify the objects returned by querying those specific types. I thought about this a bit. The problem I ran into is that one devices atomic unit is not the same as anothers. Consider a PC application which just wants to pull its entire buddy list in one pass. If information for each buddy is a separate resource, it has to issue N separate HTTP GETs, one for each of the N buddies on the list. Worse yet, it would need to first fetch the "buddy list" resource, which presumably has references to the resources for each buddy. Its more problematic when you want to update something. Lets say you want to add a buddy. A wireless client would need to PUT the XML document for this new buddy, and then modify the "buddy list" document to add a reference to the new buddy XML document. Thats two transactions, and one of them requires a GET/modify/PUT of a large document. An optimization is to define a resource that actually returns the full buddy list with all of its buddies. If you think about it, this is exactly the optimiziation that xpath affords us. So, I concluded that we want something like xpath, for buddy lists and for other usages we are likely to find. However, xpath is quite a big spec, and way more than we need. What we really need is a way to identify a single XML element. We need to be able to identify it by its path from the root, where each branch is defined by element name or by the value of one of its attributes. That is a very, very small subset of xpath. My recommendation, therefore, is to add a section to the spec which is a standalone definition of a string that can point to a single XML element, using the "/" notation of xpath, and using the "[@name=value]" mechanism in xpath for selecting an element by attribute name. This section would use Xpath as an informative reference only. The expressions defined by this section would be compliant xpath expressions, but we would not be using xpath. That would leave the door open in the future for full xpath support if we decide its needed. What do people think of this simplification? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 21 17:21:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11232 for ; Mon, 21 Jul 2003 17:21:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ei5n-0007NG-BQ for simple-archive@odin.ietf.org; Mon, 21 Jul 2003 17:21:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LLLBmq028344 for simple-archive@odin.ietf.org; Mon, 21 Jul 2003 17:21:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ei5n-0007N5-5Y for simple-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 17:21:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11176; Mon, 21 Jul 2003 17:21:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ei5k-0006Ru-00; Mon, 21 Jul 2003 17:21:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ei5f-0006Rr-00; Mon, 21 Jul 2003 17:21:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ei5c-0007Lj-S1; Mon, 21 Jul 2003 17:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ei5I-0007LN-A4 for simple@optimus.ietf.org; Mon, 21 Jul 2003 17:20:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11169 for ; Mon, 21 Jul 2003 17:20:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ei5G-0006Rj-00 for simple@ietf.org; Mon, 21 Jul 2003 17:20:38 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ei55-0006RK-00 for simple@ietf.org; Mon, 21 Jul 2003 17:20:27 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6LLJbCK000683 for ; Mon, 21 Jul 2003 17:19:37 -0400 (EDT) Message-ID: <3F1C58E4.5050608@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap and xpath Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 21 Jul 2003 17:19:32 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, During the meeting, Ted had suggested a potential simplification in xcap. Namely, don't use xpath at all. If we know ahead of times the specific "break points" in the schema where we know we will do atomic operations (I.e., buddies), just define each buddy as a resource, and define the buddy list as a separate resource, and specify the objects returned by querying those specific types. I thought about this a bit. The problem I ran into is that one devices atomic unit is not the same as anothers. Consider a PC application which just wants to pull its entire buddy list in one pass. If information for each buddy is a separate resource, it has to issue N separate HTTP GETs, one for each of the N buddies on the list. Worse yet, it would need to first fetch the "buddy list" resource, which presumably has references to the resources for each buddy. Its more problematic when you want to update something. Lets say you want to add a buddy. A wireless client would need to PUT the XML document for this new buddy, and then modify the "buddy list" document to add a reference to the new buddy XML document. Thats two transactions, and one of them requires a GET/modify/PUT of a large document. An optimization is to define a resource that actually returns the full buddy list with all of its buddies. If you think about it, this is exactly the optimiziation that xpath affords us. So, I concluded that we want something like xpath, for buddy lists and for other usages we are likely to find. However, xpath is quite a big spec, and way more than we need. What we really need is a way to identify a single XML element. We need to be able to identify it by its path from the root, where each branch is defined by element name or by the value of one of its attributes. That is a very, very small subset of xpath. My recommendation, therefore, is to add a section to the spec which is a standalone definition of a string that can point to a single XML element, using the "/" notation of xpath, and using the "[@name=value]" mechanism in xpath for selecting an element by attribute name. This section would use Xpath as an informative reference only. The expressions defined by this section would be compliant xpath expressions, but we would not be using xpath. That would leave the door open in the future for full xpath support if we decide its needed. What do people think of this simplification? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 21 20:35:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16003; Mon, 21 Jul 2003 20:35:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19el7V-0007XF-00; Mon, 21 Jul 2003 20:35:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19el7Q-0007XC-00; Mon, 21 Jul 2003 20:35:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19el7N-0005GR-H5; Mon, 21 Jul 2003 20:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19el7H-0005GA-J7 for simple@optimus.ietf.org; Mon, 21 Jul 2003 20:34:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15992 for ; Mon, 21 Jul 2003 20:34:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19el7F-0007Wv-00 for simple@ietf.org; Mon, 21 Jul 2003 20:34:53 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19el6z-0007Wk-00 for simple@ietf.org; Mon, 21 Jul 2003 20:34:37 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6M0XLRu027052; Mon, 21 Jul 2003 20:33:21 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6M0XJf14455; Mon, 21 Jul 2003 20:33:19 -0400 Message-ID: <3F1C8554.5060206@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Markus.Isomaki@nokia.com, simple@ietf.org Subject: Re: reducing xcap-auth scope, was: Re: [Simple] A proposal for xcap direction References: <3F1C5631.1070102@dynamicsoft.com> In-Reply-To: <3F1C5631.1070102@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 21 Jul 2003 20:29:08 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > * I could be convinced to remove accept-if altogether. I do think that > accepting subscriptions based on durations (to allow only fetches), is > pretty useful. Other opinions? Unless you restrict the number of times that somebody can subscribe each hour, why wouldn't that just be encouraging polling instead of event delivery? > * I think we still need content-permissions. We could descope > show-element so that you can only give permission by element name, not > by xpath expression. What do we lose if we do this? If a presence doc > has two tuples, and you wanted to allow a watcher to see "placetype" in > one, but not the other, you couldnt do it. you could only allow or > disallow "placetype" for any tuple. I think thats OK for the first > version. Agreed. I'm having a hard time coming up with a use case where this is truly required. Dis-allowing certain values for certain subscribers is probably more useful, albeit marginally. ("Don't show boss if my body monitor registers me in sleeping state.") Your last item addresses that. > * I think we still need transformational attributes. I would recommend > that "set-element" and "change-value-from" would specify the element by > element-name (i.e., "placetype"), and would impact all instances of that > element within the presence document. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 21 20:35:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16032 for ; Mon, 21 Jul 2003 20:35:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19el7Y-0005Hw-Jr for simple-archive@odin.ietf.org; Mon, 21 Jul 2003 20:35:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M0ZCfb020324 for simple-archive@odin.ietf.org; Mon, 21 Jul 2003 20:35:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19el7Y-0005Hj-Gd for simple-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 20:35:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16003; Mon, 21 Jul 2003 20:35:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19el7V-0007XF-00; Mon, 21 Jul 2003 20:35:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19el7Q-0007XC-00; Mon, 21 Jul 2003 20:35:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19el7N-0005GR-H5; Mon, 21 Jul 2003 20:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19el7H-0005GA-J7 for simple@optimus.ietf.org; Mon, 21 Jul 2003 20:34:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15992 for ; Mon, 21 Jul 2003 20:34:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19el7F-0007Wv-00 for simple@ietf.org; Mon, 21 Jul 2003 20:34:53 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19el6z-0007Wk-00 for simple@ietf.org; Mon, 21 Jul 2003 20:34:37 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6M0XLRu027052; Mon, 21 Jul 2003 20:33:21 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6M0XJf14455; Mon, 21 Jul 2003 20:33:19 -0400 Message-ID: <3F1C8554.5060206@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Markus.Isomaki@nokia.com, simple@ietf.org Subject: Re: reducing xcap-auth scope, was: Re: [Simple] A proposal for xcap direction References: <3F1C5631.1070102@dynamicsoft.com> In-Reply-To: <3F1C5631.1070102@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 21 Jul 2003 20:29:08 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > * I could be convinced to remove accept-if altogether. I do think that > accepting subscriptions based on durations (to allow only fetches), is > pretty useful. Other opinions? Unless you restrict the number of times that somebody can subscribe each hour, why wouldn't that just be encouraging polling instead of event delivery? > * I think we still need content-permissions. We could descope > show-element so that you can only give permission by element name, not > by xpath expression. What do we lose if we do this? If a presence doc > has two tuples, and you wanted to allow a watcher to see "placetype" in > one, but not the other, you couldnt do it. you could only allow or > disallow "placetype" for any tuple. I think thats OK for the first > version. Agreed. I'm having a hard time coming up with a use case where this is truly required. Dis-allowing certain values for certain subscribers is probably more useful, albeit marginally. ("Don't show boss if my body monitor registers me in sleeping state.") Your last item addresses that. > * I think we still need transformational attributes. I would recommend > that "set-element" and "change-value-from" would specify the element by > element-name (i.e., "placetype"), and would impact all instances of that > element within the presence document. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 22 03:49:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04739; Tue, 22 Jul 2003 03:49:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ertU-0002Ky-00; Tue, 22 Jul 2003 03:49:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ertP-0002Kv-00; Tue, 22 Jul 2003 03:49:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ertM-0002Kg-Qg; Tue, 22 Jul 2003 03:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ertF-0002Je-90 for simple@optimus.ietf.org; Tue, 22 Jul 2003 03:48:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04736 for ; Tue, 22 Jul 2003 03:48:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ertC-0002Ks-00 for simple@ietf.org; Tue, 22 Jul 2003 03:48:50 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ert2-0002Kj-00 for simple@ietf.org; Tue, 22 Jul 2003 03:48:40 -0400 Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6M7lwCK001064; Tue, 22 Jul 2003 03:47:59 -0400 (EDT) Message-ID: <3F1CEC2A.2070304@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> <3F13080F.4060706@cs.columbia.edu> <3F1330E3.8070407@lucent.com> <3F134E7E.7020409@dynamicsoft.com> <3F145A91.8000006@cs.columbia.edu> In-Reply-To: <3F145A91.8000006@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 03:47:54 -0400 Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > > >>>> I think this mostly works, particularly if this is encoded as a >>>> password, as in sam:848zcc85@example.com. >> >> >> >> I like this approach alot. I had the same thought upon reading >> Henning's note, but Vijay beat me to posting the idea. > > >> I don't quite follow Henning's concern. I don't see why the >> secretary's user agent per se cares. Presumably all of this is handled >> in the presence server. What it DOES require is that the presence >> server have a > > > Note that I'm not assuming that the boss and secretary presence server > have anything to do with each other - they can be in different domains. > I don't see how a GRUU helps here. The secretary isn't creating it; the > URI can't be public (as otherwise the third party could just hand it out > to everyone else.) Right, that is a problem. A variation below might fix that. > > In the 'password' model that Vijay implicitly proposed, the boss can > create a specific URI, such as E_k(customer,expiration,salt), which is > then handed to the customer who wants to subscribe to the boss (and the > boss' secretary) as a contact. Without further consultation, the > secretary can verify that the boss has "signed" the subscription until > the expiration time. This requires the secretary's presence server to be > able to decode the password and verify it. > > Can you explain the chain of events as you see them in a bit more detail? OK, here is the idea. We have watcher W, secretary S, boss B, all in different domains. Secretary S has granted permission for B to subscriber to him. B has given his presence server sufficient credentials so that the server can authenticate itself to S's server as B. W subscribers to B. B's presence server subscribes to S, using B's credentials. S's presence server says OK, and returns the presence information B can see. B's presence server returns a presence document with a tuple for the secretary. It has a URI that resolves to B's presence server. W SUBSCRIBES to this URI. It routes to B's presence server. Since S's presence is available at B's presence server, B returns the presence status. It effectively becomes a state agent. > >> As I mention above, I suspect that there would be some basic policy >> that applies here. In fact, the "import" appraoch you have proposed, >> Henning, is identical to using a GRUU whose policy is: "the boss's >> authorization policy gets applied" to subscriptions to the gruu. > > > In the cases of distinct presence servers, I don't see how the boss' > presence policy can apply. In the above scheme, it would work. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 22 03:49:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04756 for ; Tue, 22 Jul 2003 03:49:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ertY-0002MO-8A for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 03:49:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M7nCB1009066 for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 03:49:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ertX-0002M9-Hp for simple-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 03:49:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04739; Tue, 22 Jul 2003 03:49:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ertU-0002Ky-00; Tue, 22 Jul 2003 03:49:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ertP-0002Kv-00; Tue, 22 Jul 2003 03:49:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ertM-0002Kg-Qg; Tue, 22 Jul 2003 03:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ertF-0002Je-90 for simple@optimus.ietf.org; Tue, 22 Jul 2003 03:48:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04736 for ; Tue, 22 Jul 2003 03:48:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ertC-0002Ks-00 for simple@ietf.org; Tue, 22 Jul 2003 03:48:50 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ert2-0002Kj-00 for simple@ietf.org; Tue, 22 Jul 2003 03:48:40 -0400 Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6M7lwCK001064; Tue, 22 Jul 2003 03:47:59 -0400 (EDT) Message-ID: <3F1CEC2A.2070304@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> <3F13080F.4060706@cs.columbia.edu> <3F1330E3.8070407@lucent.com> <3F134E7E.7020409@dynamicsoft.com> <3F145A91.8000006@cs.columbia.edu> In-Reply-To: <3F145A91.8000006@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 03:47:54 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > > >>>> I think this mostly works, particularly if this is encoded as a >>>> password, as in sam:848zcc85@example.com. >> >> >> >> I like this approach alot. I had the same thought upon reading >> Henning's note, but Vijay beat me to posting the idea. > > >> I don't quite follow Henning's concern. I don't see why the >> secretary's user agent per se cares. Presumably all of this is handled >> in the presence server. What it DOES require is that the presence >> server have a > > > Note that I'm not assuming that the boss and secretary presence server > have anything to do with each other - they can be in different domains. > I don't see how a GRUU helps here. The secretary isn't creating it; the > URI can't be public (as otherwise the third party could just hand it out > to everyone else.) Right, that is a problem. A variation below might fix that. > > In the 'password' model that Vijay implicitly proposed, the boss can > create a specific URI, such as E_k(customer,expiration,salt), which is > then handed to the customer who wants to subscribe to the boss (and the > boss' secretary) as a contact. Without further consultation, the > secretary can verify that the boss has "signed" the subscription until > the expiration time. This requires the secretary's presence server to be > able to decode the password and verify it. > > Can you explain the chain of events as you see them in a bit more detail? OK, here is the idea. We have watcher W, secretary S, boss B, all in different domains. Secretary S has granted permission for B to subscriber to him. B has given his presence server sufficient credentials so that the server can authenticate itself to S's server as B. W subscribers to B. B's presence server subscribes to S, using B's credentials. S's presence server says OK, and returns the presence information B can see. B's presence server returns a presence document with a tuple for the secretary. It has a URI that resolves to B's presence server. W SUBSCRIBES to this URI. It routes to B's presence server. Since S's presence is available at B's presence server, B returns the presence status. It effectively becomes a state agent. > >> As I mention above, I suspect that there would be some basic policy >> that applies here. In fact, the "import" appraoch you have proposed, >> Henning, is identical to using a GRUU whose policy is: "the boss's >> authorization policy gets applied" to subscriptions to the gruu. > > > In the cases of distinct presence servers, I don't see how the boss' > presence policy can apply. In the above scheme, it would work. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 22 04:52:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06211; Tue, 22 Jul 2003 04:52:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19essS-0002ix-00; Tue, 22 Jul 2003 04:52:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19essM-0002iu-00; Tue, 22 Jul 2003 04:52:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19essL-0004nB-6U; Tue, 22 Jul 2003 04:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19esrT-0004mJ-63 for simple@optimus.ietf.org; Tue, 22 Jul 2003 04:51:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06184 for ; Tue, 22 Jul 2003 04:51:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19esrQ-0002iL-00 for simple@ietf.org; Tue, 22 Jul 2003 04:51:04 -0400 Received: from [194.90.70.20] (helo=ilexch1.p-cube.com) by ietf-mx with esmtp (Exim 4.12) id 19esrF-0002iE-00 for simple@ietf.org; Tue, 22 Jul 2003 04:50:53 -0400 Received: by ilexch1.p-cube.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 11:49:07 +0300 Message-ID: From: Silvi Kates To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3502E.1C348EB0" Subject: [Simple] SIMPLE - IM Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 11:49:06 +0300 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_01C3502E.1C348EB0 Content-Type: text/plain Hi, So far on all the documents and applications of Instant message the Method for sending IM messages was MESSAGE. Now I came across this draft: http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessions-01.txt Which I found in here: http://www.potaroo.net/ietf/ids-wg-simple.html That's suggests that instead of using the MESSAGE method, there are now new methods (SEND , VISIT, BIND) Of the MSRP (message session relay protocol) that are carried over SIP. Is this only a suggestion, or does it really used in real life, on SIP IM applications? Thanks Silvi ------_=_NextPart_001_01C3502E.1C348EB0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message

Hi,

So far on all the documents and applications of Instant message the Method for = sending IM messages was

MESSAGE.

Now I came across this draft: http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-ses= sions-01.txt

Which I found in here: http://www.potar= oo.net/ietf/ids-wg-simple.html

 

That's suggests that instead of using the MESSAGE method, there are now new = methods (SEND , VISIT, BIND)

Of the  MSRP (message session = relay protocol) that are carried over SIP.

Is this only a suggestion, or does it really used in real life, on SIP IM = applications?

 

 

Thanks

 Silvi

 

------_=_NextPart_001_01C3502E.1C348EB0-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 22 04:52:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06267 for ; Tue, 22 Jul 2003 04:52:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19essW-0004rx-Bs for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 04:52:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M8qCBL018716 for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 04:52:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19essW-0004rn-7T for simple-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 04:52:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06211; Tue, 22 Jul 2003 04:52:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19essS-0002ix-00; Tue, 22 Jul 2003 04:52:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19essM-0002iu-00; Tue, 22 Jul 2003 04:52:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19essL-0004nB-6U; Tue, 22 Jul 2003 04:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19esrT-0004mJ-63 for simple@optimus.ietf.org; Tue, 22 Jul 2003 04:51:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06184 for ; Tue, 22 Jul 2003 04:51:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19esrQ-0002iL-00 for simple@ietf.org; Tue, 22 Jul 2003 04:51:04 -0400 Received: from [194.90.70.20] (helo=ilexch1.p-cube.com) by ietf-mx with esmtp (Exim 4.12) id 19esrF-0002iE-00 for simple@ietf.org; Tue, 22 Jul 2003 04:50:53 -0400 Received: by ilexch1.p-cube.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 11:49:07 +0300 Message-ID: From: Silvi Kates To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3502E.1C348EB0" Subject: [Simple] SIMPLE - IM Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 11:49:06 +0300 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_01C3502E.1C348EB0 Content-Type: text/plain Hi, So far on all the documents and applications of Instant message the Method for sending IM messages was MESSAGE. Now I came across this draft: http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessions-01.txt Which I found in here: http://www.potaroo.net/ietf/ids-wg-simple.html That's suggests that instead of using the MESSAGE method, there are now new methods (SEND , VISIT, BIND) Of the MSRP (message session relay protocol) that are carried over SIP. Is this only a suggestion, or does it really used in real life, on SIP IM applications? Thanks Silvi ------_=_NextPart_001_01C3502E.1C348EB0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message

Hi,

So far on all the documents and applications of Instant message the Method for = sending IM messages was

MESSAGE.

Now I came across this draft: http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-ses= sions-01.txt

Which I found in here: http://www.potar= oo.net/ietf/ids-wg-simple.html

 

That's suggests that instead of using the MESSAGE method, there are now new = methods (SEND , VISIT, BIND)

Of the  MSRP (message session = relay protocol) that are carried over SIP.

Is this only a suggestion, or does it really used in real life, on SIP IM = applications?

 

 

Thanks

 Silvi

 

------_=_NextPart_001_01C3502E.1C348EB0-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 22 05:15:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06703; Tue, 22 Jul 2003 05:15:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19etEh-0002qb-00; Tue, 22 Jul 2003 05:15:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19etEc-0002qY-00; Tue, 22 Jul 2003 05:15:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etEb-0005Y1-8N; Tue, 22 Jul 2003 05:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etE0-0005Xf-Vz for simple@optimus.ietf.org; Tue, 22 Jul 2003 05:14:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06698 for ; Tue, 22 Jul 2003 05:14:20 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19etDx-0002px-00 for simple@ietf.org; Tue, 22 Jul 2003 05:14:21 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19etDm-0002pV-00 for simple@ietf.org; Tue, 22 Jul 2003 05:14:10 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6M9CjB28409 for ; Tue, 22 Jul 2003 12:12:46 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 22 Jul 2003 12:12:45 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Jul 2003 12:12:45 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Jul 2003 12:12:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35031.68D33ECE" Subject: RE: [Simple] SIMPLE - IM Message-ID: Thread-Topic: [Simple] SIMPLE - IM Thread-Index: AcNQLpYgWDzBlsmjRd+MQLj9q78U1wAARnxA To: , X-OriginalArrivalTime: 22 Jul 2003 09:12:44.0915 (UTC) FILETIME=[69712C30:01C35031] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 12:12:43 +0300 This is a multi-part message in MIME format. ------_=_NextPart_001_01C35031.68D33ECE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Silvi, =20 There will be two different paradigms for SIP IM: one-shot messages = using MESSAGE method, and messaging sessions using MSRP as the transport = protocol for messages. MSRP does not run on top of SIP but directly on = top of TCP. SIP INVITE & BYE are just used to setup the messaging = session (using normal SDP negotiation). The justification for the two = paradigms is quite well presented in the first two chapters of the draft = mentioned in your mail.=20 =20 SIP MESSAGE is already an RFC 3428: http://www.ietf.org/rfc/rfc3428.txt, = and supported by many implementations. Messaging Sessions and MSRP are = still in a draft phase, but getting quite close to be ready. This means = that they should appear in the "real world" in the next few months. =20 Rgs, Markus=20 -----Original Message----- From: ext Silvi Kates [mailto:silvik@p-cube.com] Sent: 22 July, 2003 11:49 To: 'simple@ietf.org' Subject: [Simple] SIMPLE - IM Hi, So far on all the documents and applications of Instant message the = Method for sending IM messages was MESSAGE. Now I came across this draft: = http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessions-01.txt= Which I found in here: http://www.potaroo.net/ietf/ids-wg-simple.html =20 That's suggests that instead of using the MESSAGE method, there are now = new methods (SEND , VISIT, BIND) Of the MSRP (message session relay protocol) that are carried over SIP. Is this only a suggestion, or does it really used in real life, on SIP = IM applications? =20 =20 Thanks Silvi =20 ------_=_NextPart_001_01C35031.68D33ECE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Silvi,
 
There=20 will be two different paradigms for SIP IM: one-shot messages using = MESSAGE=20 method, and messaging sessions using MSRP as the transport = protocol for=20 messages. MSRP does not run on top of SIP but directly on top of TCP.=20 SIP INVITE & BYE are just used to setup the messaging session = (using=20 normal SDP negotiation). The justification for the two paradigms is = quite=20 well presented in the first two chapters of the draft = mentioned in=20 your mail. 
 
SIP=20 MESSAGE is already an RFC 3428: http://www.ietf.org/rfc/rfc3= 428.txt,=20 and supported by many implementations. Messaging Sessions and = MSRP are=20 still in a draft phase, but getting quite close to be ready. = This=20 means that they should appear in the "real world" in the next few=20 months.
 
Rgs,
    Markus 
-----Original Message-----
From: ext Silvi Kates=20 [mailto:silvik@p-cube.com]
Sent: 22 July, 2003 = 11:49
To:=20 'simple@ietf.org'
Subject: [Simple] SIMPLE - = IM

Hi,

So far=20 on all the documents and applications of Instant message the Method = for=20 sending IM messages was

MESSAGE.

Now I=20 came across this draft: http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessi= ons-01.txt

Which I=20 found in here: http://www.potaro= o.net/ietf/ids-wg-simple.html

 

That's=20 suggests that instead of using the MESSAGE method, there are now new = methods=20 (SEND , VISIT, BIND)

Of=20 the  MSRP (message = session relay=20 protocol) that are carried over SIP.

Is this=20 only a suggestion, or does it really used in real life, on SIP IM=20 applications?

 

 

Thanks

 Silvi

 

------_=_NextPart_001_01C35031.68D33ECE-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 22 05:15:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06720 for ; Tue, 22 Jul 2003 05:15:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etEm-0005bX-H7 for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 05:15:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M9FCrf021537 for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 05:15:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etEl-0005ZO-LY for simple-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 05:15:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06703; Tue, 22 Jul 2003 05:15:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19etEh-0002qb-00; Tue, 22 Jul 2003 05:15:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19etEc-0002qY-00; Tue, 22 Jul 2003 05:15:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etEb-0005Y1-8N; Tue, 22 Jul 2003 05:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etE0-0005Xf-Vz for simple@optimus.ietf.org; Tue, 22 Jul 2003 05:14:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06698 for ; Tue, 22 Jul 2003 05:14:20 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19etDx-0002px-00 for simple@ietf.org; Tue, 22 Jul 2003 05:14:21 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19etDm-0002pV-00 for simple@ietf.org; Tue, 22 Jul 2003 05:14:10 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6M9CjB28409 for ; Tue, 22 Jul 2003 12:12:46 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 22 Jul 2003 12:12:45 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Jul 2003 12:12:45 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Jul 2003 12:12:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35031.68D33ECE" Subject: RE: [Simple] SIMPLE - IM Message-ID: Thread-Topic: [Simple] SIMPLE - IM Thread-Index: AcNQLpYgWDzBlsmjRd+MQLj9q78U1wAARnxA To: , X-OriginalArrivalTime: 22 Jul 2003 09:12:44.0915 (UTC) FILETIME=[69712C30:01C35031] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 12:12:43 +0300 This is a multi-part message in MIME format. ------_=_NextPart_001_01C35031.68D33ECE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Silvi, =20 There will be two different paradigms for SIP IM: one-shot messages = using MESSAGE method, and messaging sessions using MSRP as the transport = protocol for messages. MSRP does not run on top of SIP but directly on = top of TCP. SIP INVITE & BYE are just used to setup the messaging = session (using normal SDP negotiation). The justification for the two = paradigms is quite well presented in the first two chapters of the draft = mentioned in your mail.=20 =20 SIP MESSAGE is already an RFC 3428: http://www.ietf.org/rfc/rfc3428.txt, = and supported by many implementations. Messaging Sessions and MSRP are = still in a draft phase, but getting quite close to be ready. This means = that they should appear in the "real world" in the next few months. =20 Rgs, Markus=20 -----Original Message----- From: ext Silvi Kates [mailto:silvik@p-cube.com] Sent: 22 July, 2003 11:49 To: 'simple@ietf.org' Subject: [Simple] SIMPLE - IM Hi, So far on all the documents and applications of Instant message the = Method for sending IM messages was MESSAGE. Now I came across this draft: = http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessions-01.txt= Which I found in here: http://www.potaroo.net/ietf/ids-wg-simple.html =20 That's suggests that instead of using the MESSAGE method, there are now = new methods (SEND , VISIT, BIND) Of the MSRP (message session relay protocol) that are carried over SIP. Is this only a suggestion, or does it really used in real life, on SIP = IM applications? =20 =20 Thanks Silvi =20 ------_=_NextPart_001_01C35031.68D33ECE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Silvi,
 
There=20 will be two different paradigms for SIP IM: one-shot messages using = MESSAGE=20 method, and messaging sessions using MSRP as the transport = protocol for=20 messages. MSRP does not run on top of SIP but directly on top of TCP.=20 SIP INVITE & BYE are just used to setup the messaging session = (using=20 normal SDP negotiation). The justification for the two paradigms is = quite=20 well presented in the first two chapters of the draft = mentioned in=20 your mail. 
 
SIP=20 MESSAGE is already an RFC 3428: http://www.ietf.org/rfc/rfc3= 428.txt,=20 and supported by many implementations. Messaging Sessions and = MSRP are=20 still in a draft phase, but getting quite close to be ready. = This=20 means that they should appear in the "real world" in the next few=20 months.
 
Rgs,
    Markus 
-----Original Message-----
From: ext Silvi Kates=20 [mailto:silvik@p-cube.com]
Sent: 22 July, 2003 = 11:49
To:=20 'simple@ietf.org'
Subject: [Simple] SIMPLE - = IM

Hi,

So far=20 on all the documents and applications of Instant message the Method = for=20 sending IM messages was

MESSAGE.

Now I=20 came across this draft: http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessi= ons-01.txt

Which I=20 found in here: http://www.potaro= o.net/ietf/ids-wg-simple.html

 

That's=20 suggests that instead of using the MESSAGE method, there are now new = methods=20 (SEND , VISIT, BIND)

Of=20 the  MSRP (message = session relay=20 protocol) that are carried over SIP.

Is this=20 only a suggestion, or does it really used in real life, on SIP IM=20 applications?

 

 

Thanks

 Silvi

 

------_=_NextPart_001_01C35031.68D33ECE-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 22 05:23:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06830; Tue, 22 Jul 2003 05:23:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19etMS-0002tA-00; Tue, 22 Jul 2003 05:23:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19etMM-0002t7-00; Tue, 22 Jul 2003 05:23:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etMK-0005zM-JR; Tue, 22 Jul 2003 05:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etLd-0005yb-LG for simple@optimus.ietf.org; Tue, 22 Jul 2003 05:22:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06820 for ; Tue, 22 Jul 2003 05:22:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19etLa-0002ss-00 for simple@ietf.org; Tue, 22 Jul 2003 05:22:14 -0400 Received: from [194.90.70.20] (helo=ilexch1.p-cube.com) by ietf-mx with esmtp (Exim 4.12) id 19etLP-0002sL-00 for simple@ietf.org; Tue, 22 Jul 2003 05:22:03 -0400 Received: by ilexch1.p-cube.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 12:19:49 +0300 Message-ID: From: Silvi Kates To: "'Markus.Isomaki@nokia.com'" , Silvi Kates , simple@ietf.org Subject: RE: [Simple] SIMPLE - IM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35032.65D0DE80" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 12:19:48 +0300 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_01C35032.65D0DE80 Content-Type: text/plain Thanks for your answer. I have another small question. Does the known format of IM and Presence (MESSAGE, SUBSCRIBE, NOTIFY ...) used the same way on wireless networks and on wired networks? If not, can anyone point me to some document about the difference between those networks? (or documents of how it being handled on wireless networks?) Thanks again. -----Original Message----- From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] Sent: Tuesday, July 22, 2003 12:13 PM To: silvik@p-cube.com; simple@ietf.org Subject: RE: [Simple] SIMPLE - IM Hi Silvi, There will be two different paradigms for SIP IM: one-shot messages using MESSAGE method, and messaging sessions using MSRP as the transport protocol for messages. MSRP does not run on top of SIP but directly on top of TCP. SIP INVITE & BYE are just used to setup the messaging session (using normal SDP negotiation). The justification for the two paradigms is quite well presented in the first two chapters of the draft mentioned in your mail. SIP MESSAGE is already an RFC 3428: http://www.ietf.org/rfc/rfc3428.txt , and supported by many implementations. Messaging Sessions and MSRP are still in a draft phase, but getting quite close to be ready. This means that they should appear in the "real world" in the next few months. Rgs, Markus -----Original Message----- From: ext Silvi Kates [mailto:silvik@p-cube.com] Sent: 22 July, 2003 11:49 To: 'simple@ietf.org' Subject: [Simple] SIMPLE - IM Hi, So far on all the documents and applications of Instant message the Method for sending IM messages was MESSAGE. Now I came across this draft: http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessions-01.txt Which I found in here: http://www.potaroo.net/ietf/ids-wg-simple.html That's suggests that instead of using the MESSAGE method, there are now new methods (SEND , VISIT, BIND) Of the MSRP (message session relay protocol) that are carried over SIP. Is this only a suggestion, or does it really used in real life, on SIP IM applications? Thanks Silvi ------_=_NextPart_001_01C35032.65D0DE80 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message

Thanks for your = answer.

 

I have another small = question.

Does the known format of IM and = Presence (MESSAGE, SUBSCRIBE, NOTIFY ...) used the same way on wireless networks = and on wired networks?

 

If not, can anyone point me to = some document about the difference between those = networks?

(or = documents of how it being handled on wireless = networks?)

Thanks = again.

 

 

-----Original = Message-----
From: = Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
Sent: = Tuesday, July 22, = 2003 12:13 PM
To: silvik@p-cube.com; simple@ietf.org
Subject: RE: [Simple] = SIMPLE - IM

 

Hi Silvi,

 

There will be two different paradigms for SIP IM: one-shot messages using = MESSAGE method, and messaging sessions using MSRP as the transport = protocol for messages. MSRP does not run on top of SIP but directly on top of TCP. SIP INVITE & BYE are just used to setup the messaging session = (using normal SDP negotiation). The justification for the two paradigms is = quite well presented in the first two chapters of the draft = mentioned in your mail. 

 

SIP MESSAGE is already an RFC 3428: http://www.ietf.org/rfc/rfc= 3428.txt, and supported by many implementations. Messaging Sessions and = MSRP are still in a draft phase, but getting quite close to be = ready. This means that they should appear in the "real world" in the = next few months.

 

Rgs,

    Markus 

-----Original Message-----
From: ext Silvi Kates [mailto:silvik@p-cube.com]
Sent: = 22 July, 2003 = 11:49
To: = 'simple@ietf.org'
Subject: [Simple] SIMPLE = - IM

Hi,

So far on all the documents and applications of Instant message the Method for = sending IM messages was

MESSAGE.

Now I came across this draft: http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-ses= sions-01.txt

Which I found in here: http://www.potar= oo.net/ietf/ids-wg-simple.html

 

That's suggests that instead of using the MESSAGE method, there are now new = methods (SEND , VISIT, BIND)

Of the  MSRP (message session = relay protocol) that are carried over SIP.

Is this only a suggestion, or does it really used in real life, on SIP IM = applications?

 

 

Thanks

 Silvi

 

------_=_NextPart_001_01C35032.65D0DE80-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 22 05:23:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06850 for ; Tue, 22 Jul 2003 05:23:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etMW-000632-31 for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 05:23:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M9NCCj023242 for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 05:23:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etMV-00062n-Vm for simple-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 05:23:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06830; Tue, 22 Jul 2003 05:23:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19etMS-0002tA-00; Tue, 22 Jul 2003 05:23:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19etMM-0002t7-00; Tue, 22 Jul 2003 05:23:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etMK-0005zM-JR; Tue, 22 Jul 2003 05:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etLd-0005yb-LG for simple@optimus.ietf.org; Tue, 22 Jul 2003 05:22:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06820 for ; Tue, 22 Jul 2003 05:22:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19etLa-0002ss-00 for simple@ietf.org; Tue, 22 Jul 2003 05:22:14 -0400 Received: from [194.90.70.20] (helo=ilexch1.p-cube.com) by ietf-mx with esmtp (Exim 4.12) id 19etLP-0002sL-00 for simple@ietf.org; Tue, 22 Jul 2003 05:22:03 -0400 Received: by ilexch1.p-cube.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 12:19:49 +0300 Message-ID: From: Silvi Kates To: "'Markus.Isomaki@nokia.com'" , Silvi Kates , simple@ietf.org Subject: RE: [Simple] SIMPLE - IM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35032.65D0DE80" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 12:19:48 +0300 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_01C35032.65D0DE80 Content-Type: text/plain Thanks for your answer. I have another small question. Does the known format of IM and Presence (MESSAGE, SUBSCRIBE, NOTIFY ...) used the same way on wireless networks and on wired networks? If not, can anyone point me to some document about the difference between those networks? (or documents of how it being handled on wireless networks?) Thanks again. -----Original Message----- From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] Sent: Tuesday, July 22, 2003 12:13 PM To: silvik@p-cube.com; simple@ietf.org Subject: RE: [Simple] SIMPLE - IM Hi Silvi, There will be two different paradigms for SIP IM: one-shot messages using MESSAGE method, and messaging sessions using MSRP as the transport protocol for messages. MSRP does not run on top of SIP but directly on top of TCP. SIP INVITE & BYE are just used to setup the messaging session (using normal SDP negotiation). The justification for the two paradigms is quite well presented in the first two chapters of the draft mentioned in your mail. SIP MESSAGE is already an RFC 3428: http://www.ietf.org/rfc/rfc3428.txt , and supported by many implementations. Messaging Sessions and MSRP are still in a draft phase, but getting quite close to be ready. This means that they should appear in the "real world" in the next few months. Rgs, Markus -----Original Message----- From: ext Silvi Kates [mailto:silvik@p-cube.com] Sent: 22 July, 2003 11:49 To: 'simple@ietf.org' Subject: [Simple] SIMPLE - IM Hi, So far on all the documents and applications of Instant message the Method for sending IM messages was MESSAGE. Now I came across this draft: http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessions-01.txt Which I found in here: http://www.potaroo.net/ietf/ids-wg-simple.html That's suggests that instead of using the MESSAGE method, there are now new methods (SEND , VISIT, BIND) Of the MSRP (message session relay protocol) that are carried over SIP. Is this only a suggestion, or does it really used in real life, on SIP IM applications? Thanks Silvi ------_=_NextPart_001_01C35032.65D0DE80 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message

Thanks for your = answer.

 

I have another small = question.

Does the known format of IM and = Presence (MESSAGE, SUBSCRIBE, NOTIFY ...) used the same way on wireless networks = and on wired networks?

 

If not, can anyone point me to = some document about the difference between those = networks?

(or = documents of how it being handled on wireless = networks?)

Thanks = again.

 

 

-----Original = Message-----
From: = Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
Sent: = Tuesday, July 22, = 2003 12:13 PM
To: silvik@p-cube.com; simple@ietf.org
Subject: RE: [Simple] = SIMPLE - IM

 

Hi Silvi,

 

There will be two different paradigms for SIP IM: one-shot messages using = MESSAGE method, and messaging sessions using MSRP as the transport = protocol for messages. MSRP does not run on top of SIP but directly on top of TCP. SIP INVITE & BYE are just used to setup the messaging session = (using normal SDP negotiation). The justification for the two paradigms is = quite well presented in the first two chapters of the draft = mentioned in your mail. 

 

SIP MESSAGE is already an RFC 3428: http://www.ietf.org/rfc/rfc= 3428.txt, and supported by many implementations. Messaging Sessions and = MSRP are still in a draft phase, but getting quite close to be = ready. This means that they should appear in the "real world" in the = next few months.

 

Rgs,

    Markus 

-----Original Message-----
From: ext Silvi Kates [mailto:silvik@p-cube.com]
Sent: = 22 July, 2003 = 11:49
To: = 'simple@ietf.org'
Subject: [Simple] SIMPLE = - IM

Hi,

So far on all the documents and applications of Instant message the Method for = sending IM messages was

MESSAGE.

Now I came across this draft: http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-ses= sions-01.txt

Which I found in here: http://www.potar= oo.net/ietf/ids-wg-simple.html

 

That's suggests that instead of using the MESSAGE method, there are now new = methods (SEND , VISIT, BIND)

Of the  MSRP (message session = relay protocol) that are carried over SIP.

Is this only a suggestion, or does it really used in real life, on SIP IM = applications?

 

 

Thanks

 Silvi

 

------_=_NextPart_001_01C35032.65D0DE80-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 22 05:44:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07284; Tue, 22 Jul 2003 05:44:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19etgm-00032o-00; Tue, 22 Jul 2003 05:44:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19etgg-00032l-00; Tue, 22 Jul 2003 05:44:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etgf-0006yv-Eb; Tue, 22 Jul 2003 05:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etfv-0006yR-6j for simple@optimus.ietf.org; Tue, 22 Jul 2003 05:43:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07278 for ; Tue, 22 Jul 2003 05:43:10 -0400 (EDT) From: loretosa@vodafone.it Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19etfr-00032Z-00 for simple@ietf.org; Tue, 22 Jul 2003 05:43:11 -0400 Received: from [194.185.97.41] (helo=gsp04-c21d2.vodafone.it) by ietf-mx with esmtp (Exim 4.12) id 19etfh-00032M-00 for simple@ietf.org; Tue, 22 Jul 2003 05:43:01 -0400 Received: from vodafone.it (127.0.0.1) by gsp04-c21d2.vodafone.it (NPlex 5.1.046) id 3F0C420800004466 for simple@ietf.org; Tue, 22 Jul 2003 11:42:20 +0200 Message-Id: Subject: Ri:RE: [Simple] SIMPLE - IM MIME-Version: 1.0 Message-Context: text-message Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: simple@ietf.org Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 11:42:20 +0200 Content-Transfer-Encoding: quoted-printable That's an interesting question... some times ago I read something about SIP on wireless and congestion issues, if I don't wrong written by ericsson people. So can someone do a summarize about SIP and/or IM on WIRELESS ??? thanks in advance Sal > Thanks for your answer. > > I have another small question. > Does the known format of IM and Presence (MESSAGE, SUBSCRIBE, NOTIFY ...) > used the same way on wireless networks and on wired networks? > > If not, can anyone point me to some document about the difference between > those networks? > (or documents of how it being handled on wireless networks?) > Thanks again. > > > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Tuesday, July 22, 2003 12:13 PM > To: silvik@p-cube.com; simple@ietf.org > Subject: RE: [Simple] SIMPLE - IM > > Hi Silvi, > > There will be two different paradigms for SIP IM: one-shot messages using > MESSAGE method, and messaging sessions using MSRP as the transport protocol > for messages. MSRP does not run on top of SIP but directly on top of TCP. > SIP INVITE & BYE are just used to setup the messaging session (using normal > SDP negotiation). The justification for the two paradigms is quite well > presented in the first two chapters of the draft mentioned in your mail. > > SIP MESSAGE is already an RFC 3428: http://www.ietf.org/rfc/rfc3428.txt > , and supported by many > implementations. Messaging Sessions and MSRP are still in a draft phase, but > getting quite close to be ready. This means that they should appear in the > "real world" in the next few months. > > Rgs, > Markus > -----Original Message----- > From: ext Silvi Kates [mailto:silvik@p-cube.com] > Sent: 22 July, 2003 11:49 > To: 'simple@ietf.org' > Subject: [Simple] SIMPLE - IM > Hi, > So far on all the documents and applications of Instant message the Method > for sending IM messages was > MESSAGE. > Now I came across this draft: > http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessions-01.txt > > Which I found in here: http://www.potaroo.net/ietf/ids-wg-simple.html > > > That's suggests that instead of using the MESSAGE method, there are now new > methods (SEND , VISIT, BIND) > Of the MSRP (message session relay protocol) that are carried over SIP. > Is this only a suggestion, or does it really used in real life, on SIP IM > applications? > > > Thanks > Silvi > > > > List of bodypart file names _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 22 05:44:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07326 for ; Tue, 22 Jul 2003 05:44:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etgq-00072X-An for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 05:44:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M9iCI5027055 for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 05:44:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etgq-00072I-7l for simple-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 05:44:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07284; Tue, 22 Jul 2003 05:44:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19etgm-00032o-00; Tue, 22 Jul 2003 05:44:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19etgg-00032l-00; Tue, 22 Jul 2003 05:44:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etgf-0006yv-Eb; Tue, 22 Jul 2003 05:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etfv-0006yR-6j for simple@optimus.ietf.org; Tue, 22 Jul 2003 05:43:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07278 for ; Tue, 22 Jul 2003 05:43:10 -0400 (EDT) From: loretosa@vodafone.it Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19etfr-00032Z-00 for simple@ietf.org; Tue, 22 Jul 2003 05:43:11 -0400 Received: from [194.185.97.41] (helo=gsp04-c21d2.vodafone.it) by ietf-mx with esmtp (Exim 4.12) id 19etfh-00032M-00 for simple@ietf.org; Tue, 22 Jul 2003 05:43:01 -0400 Received: from vodafone.it (127.0.0.1) by gsp04-c21d2.vodafone.it (NPlex 5.1.046) id 3F0C420800004466 for simple@ietf.org; Tue, 22 Jul 2003 11:42:20 +0200 Message-Id: Subject: Ri:RE: [Simple] SIMPLE - IM MIME-Version: 1.0 Message-Context: text-message Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: simple@ietf.org Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 11:42:20 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable That's an interesting question... some times ago I read something about SIP on wireless and congestion issues, if I don't wrong written by ericsson people. So can someone do a summarize about SIP and/or IM on WIRELESS ??? thanks in advance Sal > Thanks for your answer. > > I have another small question. > Does the known format of IM and Presence (MESSAGE, SUBSCRIBE, NOTIFY ...) > used the same way on wireless networks and on wired networks? > > If not, can anyone point me to some document about the difference between > those networks? > (or documents of how it being handled on wireless networks?) > Thanks again. > > > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Tuesday, July 22, 2003 12:13 PM > To: silvik@p-cube.com; simple@ietf.org > Subject: RE: [Simple] SIMPLE - IM > > Hi Silvi, > > There will be two different paradigms for SIP IM: one-shot messages using > MESSAGE method, and messaging sessions using MSRP as the transport protocol > for messages. MSRP does not run on top of SIP but directly on top of TCP. > SIP INVITE & BYE are just used to setup the messaging session (using normal > SDP negotiation). The justification for the two paradigms is quite well > presented in the first two chapters of the draft mentioned in your mail. > > SIP MESSAGE is already an RFC 3428: http://www.ietf.org/rfc/rfc3428.txt > , and supported by many > implementations. Messaging Sessions and MSRP are still in a draft phase, but > getting quite close to be ready. This means that they should appear in the > "real world" in the next few months. > > Rgs, > Markus > -----Original Message----- > From: ext Silvi Kates [mailto:silvik@p-cube.com] > Sent: 22 July, 2003 11:49 > To: 'simple@ietf.org' > Subject: [Simple] SIMPLE - IM > Hi, > So far on all the documents and applications of Instant message the Method > for sending IM messages was > MESSAGE. > Now I came across this draft: > http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessions-01.txt > > Which I found in here: http://www.potaroo.net/ietf/ids-wg-simple.html > > > That's suggests that instead of using the MESSAGE method, there are now new > methods (SEND , VISIT, BIND) > Of the MSRP (message session relay protocol) that are carried over SIP. > Is this only a suggestion, or does it really used in real life, on SIP IM > applications? > > > Thanks > Silvi > > > > List of bodypart file names _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 22 06:26:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08282; Tue, 22 Jul 2003 06:26:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19euLN-0003KH-00; Tue, 22 Jul 2003 06:26:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19euLI-0003KE-00; Tue, 22 Jul 2003 06:26:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19euLJ-0008Kq-J6; Tue, 22 Jul 2003 06:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19euL6-0008KU-M9 for simple@optimus.ietf.org; Tue, 22 Jul 2003 06:25:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08272 for ; Tue, 22 Jul 2003 06:25:43 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19euL2-0003K3-00 for simple@ietf.org; Tue, 22 Jul 2003 06:25:44 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19euKr-0003JW-00 for simple@ietf.org; Tue, 22 Jul 2003 06:25:34 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6MANbB08108 for ; Tue, 22 Jul 2003 13:23:38 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 22 Jul 2003 13:23:37 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Jul 2003 13:23:37 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Jul 2003 13:23:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: RE: [Simple] SIMPLE - IM Message-ID: Thread-Topic: RE: [Simple] SIMPLE - IM Thread-Index: AcNQNdCU+PZDAjv+RK6JZ1PoDDRDRAAAhR8Q To: , X-OriginalArrivalTime: 22 Jul 2003 10:23:36.0787 (UTC) FILETIME=[4FC15A30:01C3503B] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 13:23:36 +0300 Content-Transfer-Encoding: quoted-printable Hi, I think this is not a topic to be discussed in SIMPLE mailing list, but = below a short clarification from my point of view, since this seems to = be a FAQ on any SIP related mailing list. There are different approaches in running SIP and related applications = on top of wireless networks: One approach is to say that there is nothing different between wires and = wireless access links, since everything works on top of IP the same way. = I guess this is generally true for instance in cases where WLAN is used = in home or office environment just to replace the wires. Another approach is to consider low capacity links (~20-100 kbps) and = terminals with small displays. For low capacity links there are a couple = of enhancements, most important of which is Signaling Compression, which = allows to reduce the size of packets. Also, some smart ways to deal with = large payloads are needed, so that they wouoldn't block the whole = transmission capacity. For presence specifically, the presence lists = spec allows reducing the number of SUBSCRIBEs that are needed over the = wireless access link. For small displays the main thing is to = standardize the protocol(s) to do the basic manipulation operations for = presence lists and authorization policies etc., so that the user would = not have to switch between the presence app (such as a presence enabled = phonebook in a cellular phone) and a Web/WAP browser. This issue is = being addressed by XCAP work in SIMPLE WG. Another thing is that = protocols should be stable and well tested before they are put to = wireless devices on the market, since software updates are still harder = to do than for PC clients. It's also clear that in the first phase it is = easier to run presence, IM etc. on top of wireless access rather than = VoIP. Third approach is the one ongoing in 3GPP (and 3GPP2). This is to take = into account all the wireless specific issues mentioned above, but also = various operator, regulatory, interoperability, scalability, security = etc. requirements, that are not necessarily related to wireless access = at all, but to being able to deploy SIP in large operator networks, and = to even go as far as replacing the whole circuit switched telephony = system. Also reuse of existing wireless infra, such as SIM-cards for = authentication and specific codecs for media make sense. Based on this = 3GPP has done IP Multimedia Subsystem (IMS) Release 5 specifications = using SIP, Diameter and other IETF protocols, and is working on Release = 6 which will include presence, IM etc. within a well-defined application = server framework. The initial radio interfaces to be used include WCDMA, = GPRS, EDGE (and CDMA-2000 for 3GPP2), but actually IMS is not limited to = any particular access technology. In practice SIP will be deployed in wireless networks with all these = three approaches. Which one is best depends on the environment (small = office vs. large operator - WLAN vs. GPRS - Pocket PC vs. cell phone = etc.) and the requirements (QoS interworking, charging etc.). I guess In = most cases people are referring to 3GPP, when talking about "wireles = SIP". Regards, Markus > -----Original Message----- > From: ext loretosa@vodafone.it [mailto:loretosa@vodafone.it] > Sent: 22 July, 2003 12:42 > To: simple@ietf.org > Subject: Ri:RE: [Simple] SIMPLE - IM >=20 >=20 >=20 > That's an interesting question... > some times ago I read something about SIP on wireless and=20 > congestion issues, > if I don't wrong written by ericsson people. >=20 > So can someone do a summarize about SIP and/or IM on WIRELESS ??? >=20 > thanks in advance > Sal >=20 >=20 >=20 > > Thanks for your answer. > > =20 > > I have another small question. > > Does the known format of IM and Presence (MESSAGE,=20 > SUBSCRIBE, NOTIFY ...) > > used the same way on wireless networks and on wired networks? > > =20 > > If not, can anyone point me to some document about the=20 > difference between > > those networks? > > (or documents of how it being handled on wireless networks?) > > Thanks again. > > =20 > > =20 > > -----Original Message----- > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 > > Sent: Tuesday, July 22, 2003 12:13 PM > > To: silvik@p-cube.com; simple@ietf.org > > Subject: RE: [Simple] SIMPLE - IM > > =20 > > Hi Silvi, > > =20 > > There will be two different paradigms for SIP IM: one-shot=20 > messages using > > MESSAGE method, and messaging sessions using MSRP as the=20 > transport protocol > > for messages. MSRP does not run on top of SIP but directly=20 > on top of TCP. > > SIP INVITE & BYE are just used to setup the messaging=20 > session (using normal > > SDP negotiation). The justification for the two paradigms=20 > is quite well > > presented in the first two chapters of the draft mentioned=20 > in your mail.=20 > > =20 > > SIP MESSAGE is already an RFC 3428:=20 http://www.ietf.org/rfc/rfc3428.txt > , and supported by many > implementations. Messaging Sessions and MSRP are still in a draft = phase, but > getting quite close to be ready. This means that they should appear in = the > "real world" in the next few months. > =20 > Rgs, > Markus=20 > -----Original Message----- > From: ext Silvi Kates [mailto:silvik@p-cube.com] > Sent: 22 July, 2003 11:49 > To: 'simple@ietf.org' > Subject: [Simple] SIMPLE - IM > Hi, > So far on all the documents and applications of Instant message the = Method > for sending IM messages was > MESSAGE. > Now I came across this draft: > = http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessions-01.txt= > = =20 > Which I found in here: http://www.potaroo.net/ietf/ids-wg-simple.html > =20 > =20 > That's suggests that instead of using the MESSAGE method, there are = now new > methods (SEND , VISIT, BIND) > Of the MSRP (message session relay protocol) that are carried over = SIP. > Is this only a suggestion, or does it really used in real life, on SIP = IM > applications? > =20 > =20 > Thanks > Silvi > =20 >=20 >=20 > List of bodypart file names _______________________________________________ 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 exim@www1.ietf.org Tue Jul 22 06:26:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08307 for ; Tue, 22 Jul 2003 06:26:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19euLT-0008Or-EZ for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 06:26:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MAQBfO032285 for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 06:26:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19euLR-0008O8-Ty for simple-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 06:26:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08282; Tue, 22 Jul 2003 06:26:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19euLN-0003KH-00; Tue, 22 Jul 2003 06:26:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19euLI-0003KE-00; Tue, 22 Jul 2003 06:26:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19euLJ-0008Kq-J6; Tue, 22 Jul 2003 06:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19euL6-0008KU-M9 for simple@optimus.ietf.org; Tue, 22 Jul 2003 06:25:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08272 for ; Tue, 22 Jul 2003 06:25:43 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19euL2-0003K3-00 for simple@ietf.org; Tue, 22 Jul 2003 06:25:44 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19euKr-0003JW-00 for simple@ietf.org; Tue, 22 Jul 2003 06:25:34 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6MANbB08108 for ; Tue, 22 Jul 2003 13:23:38 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 22 Jul 2003 13:23:37 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Jul 2003 13:23:37 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Jul 2003 13:23:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: RE: [Simple] SIMPLE - IM Message-ID: Thread-Topic: RE: [Simple] SIMPLE - IM Thread-Index: AcNQNdCU+PZDAjv+RK6JZ1PoDDRDRAAAhR8Q To: , X-OriginalArrivalTime: 22 Jul 2003 10:23:36.0787 (UTC) FILETIME=[4FC15A30:01C3503B] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 13:23:36 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I think this is not a topic to be discussed in SIMPLE mailing list, but = below a short clarification from my point of view, since this seems to = be a FAQ on any SIP related mailing list. There are different approaches in running SIP and related applications = on top of wireless networks: One approach is to say that there is nothing different between wires and = wireless access links, since everything works on top of IP the same way. = I guess this is generally true for instance in cases where WLAN is used = in home or office environment just to replace the wires. Another approach is to consider low capacity links (~20-100 kbps) and = terminals with small displays. For low capacity links there are a couple = of enhancements, most important of which is Signaling Compression, which = allows to reduce the size of packets. Also, some smart ways to deal with = large payloads are needed, so that they wouoldn't block the whole = transmission capacity. For presence specifically, the presence lists = spec allows reducing the number of SUBSCRIBEs that are needed over the = wireless access link. For small displays the main thing is to = standardize the protocol(s) to do the basic manipulation operations for = presence lists and authorization policies etc., so that the user would = not have to switch between the presence app (such as a presence enabled = phonebook in a cellular phone) and a Web/WAP browser. This issue is = being addressed by XCAP work in SIMPLE WG. Another thing is that = protocols should be stable and well tested before they are put to = wireless devices on the market, since software updates are still harder = to do than for PC clients. It's also clear that in the first phase it is = easier to run presence, IM etc. on top of wireless access rather than = VoIP. Third approach is the one ongoing in 3GPP (and 3GPP2). This is to take = into account all the wireless specific issues mentioned above, but also = various operator, regulatory, interoperability, scalability, security = etc. requirements, that are not necessarily related to wireless access = at all, but to being able to deploy SIP in large operator networks, and = to even go as far as replacing the whole circuit switched telephony = system. Also reuse of existing wireless infra, such as SIM-cards for = authentication and specific codecs for media make sense. Based on this = 3GPP has done IP Multimedia Subsystem (IMS) Release 5 specifications = using SIP, Diameter and other IETF protocols, and is working on Release = 6 which will include presence, IM etc. within a well-defined application = server framework. The initial radio interfaces to be used include WCDMA, = GPRS, EDGE (and CDMA-2000 for 3GPP2), but actually IMS is not limited to = any particular access technology. In practice SIP will be deployed in wireless networks with all these = three approaches. Which one is best depends on the environment (small = office vs. large operator - WLAN vs. GPRS - Pocket PC vs. cell phone = etc.) and the requirements (QoS interworking, charging etc.). I guess In = most cases people are referring to 3GPP, when talking about "wireles = SIP". Regards, Markus > -----Original Message----- > From: ext loretosa@vodafone.it [mailto:loretosa@vodafone.it] > Sent: 22 July, 2003 12:42 > To: simple@ietf.org > Subject: Ri:RE: [Simple] SIMPLE - IM >=20 >=20 >=20 > That's an interesting question... > some times ago I read something about SIP on wireless and=20 > congestion issues, > if I don't wrong written by ericsson people. >=20 > So can someone do a summarize about SIP and/or IM on WIRELESS ??? >=20 > thanks in advance > Sal >=20 >=20 >=20 > > Thanks for your answer. > > =20 > > I have another small question. > > Does the known format of IM and Presence (MESSAGE,=20 > SUBSCRIBE, NOTIFY ...) > > used the same way on wireless networks and on wired networks? > > =20 > > If not, can anyone point me to some document about the=20 > difference between > > those networks? > > (or documents of how it being handled on wireless networks?) > > Thanks again. > > =20 > > =20 > > -----Original Message----- > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 > > Sent: Tuesday, July 22, 2003 12:13 PM > > To: silvik@p-cube.com; simple@ietf.org > > Subject: RE: [Simple] SIMPLE - IM > > =20 > > Hi Silvi, > > =20 > > There will be two different paradigms for SIP IM: one-shot=20 > messages using > > MESSAGE method, and messaging sessions using MSRP as the=20 > transport protocol > > for messages. MSRP does not run on top of SIP but directly=20 > on top of TCP. > > SIP INVITE & BYE are just used to setup the messaging=20 > session (using normal > > SDP negotiation). The justification for the two paradigms=20 > is quite well > > presented in the first two chapters of the draft mentioned=20 > in your mail.=20 > > =20 > > SIP MESSAGE is already an RFC 3428:=20 http://www.ietf.org/rfc/rfc3428.txt > , and supported by many > implementations. Messaging Sessions and MSRP are still in a draft = phase, but > getting quite close to be ready. This means that they should appear in = the > "real world" in the next few months. > =20 > Rgs, > Markus=20 > -----Original Message----- > From: ext Silvi Kates [mailto:silvik@p-cube.com] > Sent: 22 July, 2003 11:49 > To: 'simple@ietf.org' > Subject: [Simple] SIMPLE - IM > Hi, > So far on all the documents and applications of Instant message the = Method > for sending IM messages was > MESSAGE. > Now I came across this draft: > = http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessions-01.txt= > = =20 > Which I found in here: http://www.potaroo.net/ietf/ids-wg-simple.html > =20 > =20 > That's suggests that instead of using the MESSAGE method, there are = now new > methods (SEND , VISIT, BIND) > Of the MSRP (message session relay protocol) that are carried over = SIP. > Is this only a suggestion, or does it really used in real life, on SIP = IM > applications? > =20 > =20 > Thanks > Silvi > =20 >=20 >=20 > List of bodypart file names _______________________________________________ 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-admin@ietf.org Tue Jul 22 07:14:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09525; Tue, 22 Jul 2003 07:14:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ev5u-0003c2-00; Tue, 22 Jul 2003 07:14:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ev5o-0003bz-00; Tue, 22 Jul 2003 07:14:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev5k-0001y6-PU; Tue, 22 Jul 2003 07:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev4t-0001u4-Dx for simple@optimus.ietf.org; Tue, 22 Jul 2003 07:13:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09474 for ; Tue, 22 Jul 2003 07:13:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ev4s-0003bM-00 for simple@ietf.org; Tue, 22 Jul 2003 07:13:06 -0400 Received: from [194.90.70.20] (helo=ilexch1.p-cube.com) by ietf-mx with esmtp (Exim 4.12) id 19ev4i-0003bA-00 for simple@ietf.org; Tue, 22 Jul 2003 07:12:56 -0400 Received: by ilexch1.p-cube.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 14:11:07 +0300 Message-ID: From: Silvi Kates To: "'Markus.Isomaki@nokia.com'" , loretosa@vodafone.it, simple@ietf.org Subject: RE: RE: [Simple] SIMPLE - IM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 14:11:06 +0300 Thanks for your answer. It was really interesting to read ot. Can someone also refer me to documents that will have more details on the format of the SIMPLE (sip) protocol above wireless networks (what changes are there specificly )? Or is it the same format (with SUBSCRIBE, NOTIFY, and MESSAGE ...) Thanks -----Original Message----- From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] Sent: Tuesday, July 22, 2003 1:24 PM To: loretosa@vodafone.it; simple@ietf.org Subject: RE: RE: [Simple] SIMPLE - IM Hi, I think this is not a topic to be discussed in SIMPLE mailing list, but below a short clarification from my point of view, since this seems to be a FAQ on any SIP related mailing list. There are different approaches in running SIP and related applications on top of wireless networks: One approach is to say that there is nothing different between wires and wireless access links, since everything works on top of IP the same way. I guess this is generally true for instance in cases where WLAN is used in home or office environment just to replace the wires. Another approach is to consider low capacity links (~20-100 kbps) and terminals with small displays. For low capacity links there are a couple of enhancements, most important of which is Signaling Compression, which allows to reduce the size of packets. Also, some smart ways to deal with large payloads are needed, so that they wouoldn't block the whole transmission capacity. For presence specifically, the presence lists spec allows reducing the number of SUBSCRIBEs that are needed over the wireless access link. For small displays the main thing is to standardize the protocol(s) to do the basic manipulation operations for presence lists and authorization policies etc., so that the user would not have to switch between the presence app (such as a presence enabled phonebook in a cellular phone) and a Web/WAP browser. This issue is being addressed by XCAP work in SIMPLE WG. Another thing is that protocols should be stable and well tested before they are put to wireless devices on the market, since software updates are still harder to do than for PC clients. It's also clear that in the first phase it is easier to run presence, IM etc. on top of wireless access rather than VoIP. Third approach is the one ongoing in 3GPP (and 3GPP2). This is to take into account all the wireless specific issues mentioned above, but also various operator, regulatory, interoperability, scalability, security etc. requirements, that are not necessarily related to wireless access at all, but to being able to deploy SIP in large operator networks, and to even go as far as replacing the whole circuit switched telephony system. Also reuse of existing wireless infra, such as SIM-cards for authentication and specific codecs for media make sense. Based on this 3GPP has done IP Multimedia Subsystem (IMS) Release 5 specifications using SIP, Diameter and other IETF protocols, and is working on Release 6 which will include presence, IM etc. within a well-defined application server framework. The initial radio interfaces to be used include WCDMA, GPRS, EDGE (and CDMA-2000 for 3GPP2), but actually IMS is not limited to any particular access technology. In practice SIP will be deployed in wireless networks with all these three approaches. Which one is best depends on the environment (small office vs. large operator - WLAN vs. GPRS - Pocket PC vs. cell phone etc.) and the requirements (QoS interworking, charging etc.). I guess In most cases people are referring to 3GPP, when talking about "wireles SIP". Regards, Markus > -----Original Message----- > From: ext loretosa@vodafone.it [mailto:loretosa@vodafone.it] > Sent: 22 July, 2003 12:42 > To: simple@ietf.org > Subject: Ri:RE: [Simple] SIMPLE - IM > > > > That's an interesting question... > some times ago I read something about SIP on wireless and > congestion issues, > if I don't wrong written by ericsson people. > > So can someone do a summarize about SIP and/or IM on WIRELESS ??? > > thanks in advance > Sal > > > > > Thanks for your answer. > > > > I have another small question. > > Does the known format of IM and Presence (MESSAGE, > SUBSCRIBE, NOTIFY ...) > > used the same way on wireless networks and on wired networks? > > > > If not, can anyone point me to some document about the > difference between > > those networks? > > (or documents of how it being handled on wireless networks?) > > Thanks again. > > > > > > -----Original Message----- > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > Sent: Tuesday, July 22, 2003 12:13 PM > > To: silvik@p-cube.com; simple@ietf.org > > Subject: RE: [Simple] SIMPLE - IM > > > > Hi Silvi, > > > > There will be two different paradigms for SIP IM: one-shot > messages using > > MESSAGE method, and messaging sessions using MSRP as the > transport protocol > > for messages. MSRP does not run on top of SIP but directly > on top of TCP. > > SIP INVITE & BYE are just used to setup the messaging > session (using normal > > SDP negotiation). The justification for the two paradigms > is quite well > > presented in the first two chapters of the draft mentioned > in your mail. > > > > SIP MESSAGE is already an RFC 3428: http://www.ietf.org/rfc/rfc3428.txt > , and supported by many > implementations. Messaging Sessions and MSRP are still in a draft phase, but > getting quite close to be ready. This means that they should appear in the > "real world" in the next few months. > > Rgs, > Markus > -----Original Message----- > From: ext Silvi Kates [mailto:silvik@p-cube.com] > Sent: 22 July, 2003 11:49 > To: 'simple@ietf.org' > Subject: [Simple] SIMPLE - IM > Hi, > So far on all the documents and applications of Instant message the Method > for sending IM messages was > MESSAGE. > Now I came across this draft: > http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessions-01.txt > > Which I found in here: http://www.potaroo.net/ietf/ids-wg-simple.html > > > That's suggests that instead of using the MESSAGE method, there are now new > methods (SEND , VISIT, BIND) > Of the MSRP (message session relay protocol) that are carried over SIP. > Is this only a suggestion, or does it really used in real life, on SIP IM > applications? > > > Thanks > Silvi > > > > List of bodypart file names _______________________________________________ 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 exim@www1.ietf.org Tue Jul 22 07:14:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09581 for ; Tue, 22 Jul 2003 07:14:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev5v-00024u-LR for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 07:14:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MBEBGA007982 for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 07:14:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev5v-00024f-IM for simple-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 07:14:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09525; Tue, 22 Jul 2003 07:14:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ev5u-0003c2-00; Tue, 22 Jul 2003 07:14:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ev5o-0003bz-00; Tue, 22 Jul 2003 07:14:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev5k-0001y6-PU; Tue, 22 Jul 2003 07:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev4t-0001u4-Dx for simple@optimus.ietf.org; Tue, 22 Jul 2003 07:13:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09474 for ; Tue, 22 Jul 2003 07:13:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ev4s-0003bM-00 for simple@ietf.org; Tue, 22 Jul 2003 07:13:06 -0400 Received: from [194.90.70.20] (helo=ilexch1.p-cube.com) by ietf-mx with esmtp (Exim 4.12) id 19ev4i-0003bA-00 for simple@ietf.org; Tue, 22 Jul 2003 07:12:56 -0400 Received: by ilexch1.p-cube.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 14:11:07 +0300 Message-ID: From: Silvi Kates To: "'Markus.Isomaki@nokia.com'" , loretosa@vodafone.it, simple@ietf.org Subject: RE: RE: [Simple] SIMPLE - IM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 14:11:06 +0300 Thanks for your answer. It was really interesting to read ot. Can someone also refer me to documents that will have more details on the format of the SIMPLE (sip) protocol above wireless networks (what changes are there specificly )? Or is it the same format (with SUBSCRIBE, NOTIFY, and MESSAGE ...) Thanks -----Original Message----- From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] Sent: Tuesday, July 22, 2003 1:24 PM To: loretosa@vodafone.it; simple@ietf.org Subject: RE: RE: [Simple] SIMPLE - IM Hi, I think this is not a topic to be discussed in SIMPLE mailing list, but below a short clarification from my point of view, since this seems to be a FAQ on any SIP related mailing list. There are different approaches in running SIP and related applications on top of wireless networks: One approach is to say that there is nothing different between wires and wireless access links, since everything works on top of IP the same way. I guess this is generally true for instance in cases where WLAN is used in home or office environment just to replace the wires. Another approach is to consider low capacity links (~20-100 kbps) and terminals with small displays. For low capacity links there are a couple of enhancements, most important of which is Signaling Compression, which allows to reduce the size of packets. Also, some smart ways to deal with large payloads are needed, so that they wouoldn't block the whole transmission capacity. For presence specifically, the presence lists spec allows reducing the number of SUBSCRIBEs that are needed over the wireless access link. For small displays the main thing is to standardize the protocol(s) to do the basic manipulation operations for presence lists and authorization policies etc., so that the user would not have to switch between the presence app (such as a presence enabled phonebook in a cellular phone) and a Web/WAP browser. This issue is being addressed by XCAP work in SIMPLE WG. Another thing is that protocols should be stable and well tested before they are put to wireless devices on the market, since software updates are still harder to do than for PC clients. It's also clear that in the first phase it is easier to run presence, IM etc. on top of wireless access rather than VoIP. Third approach is the one ongoing in 3GPP (and 3GPP2). This is to take into account all the wireless specific issues mentioned above, but also various operator, regulatory, interoperability, scalability, security etc. requirements, that are not necessarily related to wireless access at all, but to being able to deploy SIP in large operator networks, and to even go as far as replacing the whole circuit switched telephony system. Also reuse of existing wireless infra, such as SIM-cards for authentication and specific codecs for media make sense. Based on this 3GPP has done IP Multimedia Subsystem (IMS) Release 5 specifications using SIP, Diameter and other IETF protocols, and is working on Release 6 which will include presence, IM etc. within a well-defined application server framework. The initial radio interfaces to be used include WCDMA, GPRS, EDGE (and CDMA-2000 for 3GPP2), but actually IMS is not limited to any particular access technology. In practice SIP will be deployed in wireless networks with all these three approaches. Which one is best depends on the environment (small office vs. large operator - WLAN vs. GPRS - Pocket PC vs. cell phone etc.) and the requirements (QoS interworking, charging etc.). I guess In most cases people are referring to 3GPP, when talking about "wireles SIP". Regards, Markus > -----Original Message----- > From: ext loretosa@vodafone.it [mailto:loretosa@vodafone.it] > Sent: 22 July, 2003 12:42 > To: simple@ietf.org > Subject: Ri:RE: [Simple] SIMPLE - IM > > > > That's an interesting question... > some times ago I read something about SIP on wireless and > congestion issues, > if I don't wrong written by ericsson people. > > So can someone do a summarize about SIP and/or IM on WIRELESS ??? > > thanks in advance > Sal > > > > > Thanks for your answer. > > > > I have another small question. > > Does the known format of IM and Presence (MESSAGE, > SUBSCRIBE, NOTIFY ...) > > used the same way on wireless networks and on wired networks? > > > > If not, can anyone point me to some document about the > difference between > > those networks? > > (or documents of how it being handled on wireless networks?) > > Thanks again. > > > > > > -----Original Message----- > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > Sent: Tuesday, July 22, 2003 12:13 PM > > To: silvik@p-cube.com; simple@ietf.org > > Subject: RE: [Simple] SIMPLE - IM > > > > Hi Silvi, > > > > There will be two different paradigms for SIP IM: one-shot > messages using > > MESSAGE method, and messaging sessions using MSRP as the > transport protocol > > for messages. MSRP does not run on top of SIP but directly > on top of TCP. > > SIP INVITE & BYE are just used to setup the messaging > session (using normal > > SDP negotiation). The justification for the two paradigms > is quite well > > presented in the first two chapters of the draft mentioned > in your mail. > > > > SIP MESSAGE is already an RFC 3428: http://www.ietf.org/rfc/rfc3428.txt > , and supported by many > implementations. Messaging Sessions and MSRP are still in a draft phase, but > getting quite close to be ready. This means that they should appear in the > "real world" in the next few months. > > Rgs, > Markus > -----Original Message----- > From: ext Silvi Kates [mailto:silvik@p-cube.com] > Sent: 22 July, 2003 11:49 > To: 'simple@ietf.org' > Subject: [Simple] SIMPLE - IM > Hi, > So far on all the documents and applications of Instant message the Method > for sending IM messages was > MESSAGE. > Now I came across this draft: > http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessions-01.txt > > Which I found in here: http://www.potaroo.net/ietf/ids-wg-simple.html > > > That's suggests that instead of using the MESSAGE method, there are now new > methods (SEND , VISIT, BIND) > Of the MSRP (message session relay protocol) that are carried over SIP. > Is this only a suggestion, or does it really used in real life, on SIP IM > applications? > > > Thanks > Silvi > > > > List of bodypart file names _______________________________________________ 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-admin@ietf.org Tue Jul 22 08:35:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11150; Tue, 22 Jul 2003 08:35:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ewMF-000498-00; Tue, 22 Jul 2003 08:35:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ewM9-000494-00; Tue, 22 Jul 2003 08:35:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewM8-0004tK-QT; Tue, 22 Jul 2003 08:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewM3-0004t2-2L for simple@optimus.ietf.org; Tue, 22 Jul 2003 08:34:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11146 for ; Tue, 22 Jul 2003 08:34:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ewM1-00048w-00 for simple@ietf.org; Tue, 22 Jul 2003 08:34:53 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19ewLm-00048j-00 for simple@ietf.org; Tue, 22 Jul 2003 08:34:38 -0400 Received: from cs.columbia.edu (dhcp22.cs.columbia.edu [128.59.19.222]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6MCYBss012879 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Jul 2003 08:34:11 -0400 (EDT) Message-ID: <3F1D2F24.6040207@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> <3F13080F.4060706@cs.columbia.edu> <3F1330E3.8070407@lucent.com> <3F134E7E.7020409@dynamicsoft.com> <3F145A91.8000006@cs.columbia.edu> <3F1CEC2A.2070304@dynamicsoft.com> In-Reply-To: <3F1CEC2A.2070304@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 08:33:40 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > OK, here is the idea. We have watcher W, secretary S, boss B, all in > different domains. Secretary S has granted permission for B to > subscriber to him. B has given his presence server sufficient > credentials so that the server can authenticate itself to S's server as B. > > W subscribers to B. B's presence server subscribes to S, using B's > credentials. S's presence server says OK, and returns the presence > information B can see. B's presence server returns a presence document > with a tuple for the secretary. It has a URI that resolves to B's > presence server. W SUBSCRIBES to this URI. It routes to B's presence > server. Since S's presence is available at B's presence server, B > returns the presence status. It effectively becomes a state agent. > Paint me confused, but that sounds very similar to my original (pre-password) proposal, where B subscribes to S and delivers that information to W, except that in your proposal it is delivered as a separate document and a separate subscription. I fail to see the major difference here, except for the additional complexity. One is inclusion by reference, the other by value. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 22 08:35:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11176 for ; Tue, 22 Jul 2003 08:35:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewMH-0004ut-D4 for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 08:35:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MCZ9H0018893 for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 08:35:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewMH-0004ue-9t for simple-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 08:35:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11150; Tue, 22 Jul 2003 08:35:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ewMF-000498-00; Tue, 22 Jul 2003 08:35:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ewM9-000494-00; Tue, 22 Jul 2003 08:35:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewM8-0004tK-QT; Tue, 22 Jul 2003 08:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewM3-0004t2-2L for simple@optimus.ietf.org; Tue, 22 Jul 2003 08:34:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11146 for ; Tue, 22 Jul 2003 08:34:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ewM1-00048w-00 for simple@ietf.org; Tue, 22 Jul 2003 08:34:53 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19ewLm-00048j-00 for simple@ietf.org; Tue, 22 Jul 2003 08:34:38 -0400 Received: from cs.columbia.edu (dhcp22.cs.columbia.edu [128.59.19.222]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6MCYBss012879 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Jul 2003 08:34:11 -0400 (EDT) Message-ID: <3F1D2F24.6040207@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> <3F13080F.4060706@cs.columbia.edu> <3F1330E3.8070407@lucent.com> <3F134E7E.7020409@dynamicsoft.com> <3F145A91.8000006@cs.columbia.edu> <3F1CEC2A.2070304@dynamicsoft.com> In-Reply-To: <3F1CEC2A.2070304@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 08:33:40 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > OK, here is the idea. We have watcher W, secretary S, boss B, all in > different domains. Secretary S has granted permission for B to > subscriber to him. B has given his presence server sufficient > credentials so that the server can authenticate itself to S's server as B. > > W subscribers to B. B's presence server subscribes to S, using B's > credentials. S's presence server says OK, and returns the presence > information B can see. B's presence server returns a presence document > with a tuple for the secretary. It has a URI that resolves to B's > presence server. W SUBSCRIBES to this URI. It routes to B's presence > server. Since S's presence is available at B's presence server, B > returns the presence status. It effectively becomes a state agent. > Paint me confused, but that sounds very similar to my original (pre-password) proposal, where B subscribes to S and delivers that information to W, except that in your proposal it is delivered as a separate document and a separate subscription. I fail to see the major difference here, except for the additional complexity. One is inclusion by reference, the other by value. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 22 09:58:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13461; Tue, 22 Jul 2003 09:58:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19exeZ-0004n1-00; Tue, 22 Jul 2003 09:58:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19exeU-0004my-00; Tue, 22 Jul 2003 09:58:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exeS-0007zf-Iq; Tue, 22 Jul 2003 09:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exeH-0007zU-N1 for simple@optimus.ietf.org; Tue, 22 Jul 2003 09:57:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13452 for ; Tue, 22 Jul 2003 09:57:45 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19exeF-0004ml-00 for simple@ietf.org; Tue, 22 Jul 2003 09:57:47 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19exe4-0004mh-00 for simple@ietf.org; Tue, 22 Jul 2003 09:57:36 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6MDvDJ07407 for ; Tue, 22 Jul 2003 16:57:14 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 22 Jul 2003 16:57:13 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Jul 2003 16:57:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: reducing xcap-auth scope, was: Re: [Simple] A proposal for xcap direction Message-ID: Thread-Topic: reducing xcap-auth scope, was: Re: [Simple] A proposal for xcap direction Thread-Index: AcNPzFSzl4E3oFPYT9GvDipj1d1MyAAif2XA To: Cc: , X-OriginalArrivalTime: 22 Jul 2003 13:57:12.0985 (UTC) FILETIME=[26CDF890:01C35059] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 16:57:12 +0300 Content-Transfer-Encoding: quoted-printable Hi, Comments below. Jonathan Rosenberg wrote: >=20 > I agree. We have a pressing need to finish publish, xcap, xcap buddy=20 > list, xcap auth, rpids, and message sessions. I believe that=20 > xcap-package, filtering, and partial notifications are important but=20 > are not as critical. As such, I think we should seriously consider=20 > de-scoping and simplification wherever possible to accelerate stuff. > I agree with this prioritization of SIMPLE WG items. =20 > >=20 > > Another comment I have is that we could still at least TRY to > > simplify the baseline solution for presence authorization. > > Hopefully the most complex rules could be left as optional > > extensions. >=20 To me there are two main things that the presence authorization should = be able to deal with: - Who's subscriptions should be accepted and who's denied - What is the content to give in the notifications for accepted = subscriptions. This would have to work at least on tuple level, = hopefully even based on attributes within a tuple. I would be happy to leave most of the other stuff out if we can ensure = that it could be added as extensions to the baseline schema.=20 > I agree. I would suggest removing the following things: >=20 > * the accept-if conditions related to filters (requested-namespace,=20 > requested-element, requested-tuple). >=20 Agreed. > * I could be convinced to remove accept-if altogether. I do=20 > think that=20 > accepting subscriptions based on durations (to allow only=20 > fetches), is=20 > pretty useful. Other opinions? >=20 I think duration and anonymous are important, and in some cases = auth-mechanism would be useful too. > * we could remove the rule-permissions altogether. This would get=20 > around most of the complexities of naming and addressing of=20 > XML elements. >=20 I agree with this. > * I think we still need content-permissions. We could descope=20 > show-element so that you can only give permission by element=20 > name, not=20 > by xpath expression. What do we lose if we do this? If a presence=20 > doc has two tuples, and you wanted to allow a watcher to see=20 > "placetype" in one, but not the other, you couldnt do it. you could=20 > only allow or disallow "placetype" for any tuple. I think thats OK=20 > for the first version. >=20 Content permissions would definitely be needed. I'll still have to think = what would be an acceptable level of simplification, I suppose what you = propose makes sense. I'm not sure why XPath would be so bad on the = server side? > * We could remove show-values, as it also requires xpath. >=20 > * I think we still need transformational attributes. I would=20 > recommend=20 > that "set-element" and "change-value-from" would specify the element=20 > by element-name (i.e., "placetype"), and would impact all=20 > instances of=20 > that element within the presence document. >=20 In general sounds good. Transformational attributes might be useful for = providing different types/levels of presence info to different watcher = groups. >=20 >=20 > What do people think of this scope reduction? >=20 > Thanks, > Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 22 09:58:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13535 for ; Tue, 22 Jul 2003 09:58:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exed-00084t-MD for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 09:58:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MDwBnD031047 for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 09:58:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exec-00084g-6E for simple-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 09:58:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13461; Tue, 22 Jul 2003 09:58:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19exeZ-0004n1-00; Tue, 22 Jul 2003 09:58:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19exeU-0004my-00; Tue, 22 Jul 2003 09:58:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exeS-0007zf-Iq; Tue, 22 Jul 2003 09:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exeH-0007zU-N1 for simple@optimus.ietf.org; Tue, 22 Jul 2003 09:57:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13452 for ; Tue, 22 Jul 2003 09:57:45 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19exeF-0004ml-00 for simple@ietf.org; Tue, 22 Jul 2003 09:57:47 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19exe4-0004mh-00 for simple@ietf.org; Tue, 22 Jul 2003 09:57:36 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6MDvDJ07407 for ; Tue, 22 Jul 2003 16:57:14 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 22 Jul 2003 16:57:13 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Jul 2003 16:57:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: reducing xcap-auth scope, was: Re: [Simple] A proposal for xcap direction Message-ID: Thread-Topic: reducing xcap-auth scope, was: Re: [Simple] A proposal for xcap direction Thread-Index: AcNPzFSzl4E3oFPYT9GvDipj1d1MyAAif2XA To: Cc: , X-OriginalArrivalTime: 22 Jul 2003 13:57:12.0985 (UTC) FILETIME=[26CDF890:01C35059] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 16:57:12 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Comments below. Jonathan Rosenberg wrote: >=20 > I agree. We have a pressing need to finish publish, xcap, xcap buddy=20 > list, xcap auth, rpids, and message sessions. I believe that=20 > xcap-package, filtering, and partial notifications are important but=20 > are not as critical. As such, I think we should seriously consider=20 > de-scoping and simplification wherever possible to accelerate stuff. > I agree with this prioritization of SIMPLE WG items. =20 > >=20 > > Another comment I have is that we could still at least TRY to > > simplify the baseline solution for presence authorization. > > Hopefully the most complex rules could be left as optional > > extensions. >=20 To me there are two main things that the presence authorization should = be able to deal with: - Who's subscriptions should be accepted and who's denied - What is the content to give in the notifications for accepted = subscriptions. This would have to work at least on tuple level, = hopefully even based on attributes within a tuple. I would be happy to leave most of the other stuff out if we can ensure = that it could be added as extensions to the baseline schema.=20 > I agree. I would suggest removing the following things: >=20 > * the accept-if conditions related to filters (requested-namespace,=20 > requested-element, requested-tuple). >=20 Agreed. > * I could be convinced to remove accept-if altogether. I do=20 > think that=20 > accepting subscriptions based on durations (to allow only=20 > fetches), is=20 > pretty useful. Other opinions? >=20 I think duration and anonymous are important, and in some cases = auth-mechanism would be useful too. > * we could remove the rule-permissions altogether. This would get=20 > around most of the complexities of naming and addressing of=20 > XML elements. >=20 I agree with this. > * I think we still need content-permissions. We could descope=20 > show-element so that you can only give permission by element=20 > name, not=20 > by xpath expression. What do we lose if we do this? If a presence=20 > doc has two tuples, and you wanted to allow a watcher to see=20 > "placetype" in one, but not the other, you couldnt do it. you could=20 > only allow or disallow "placetype" for any tuple. I think thats OK=20 > for the first version. >=20 Content permissions would definitely be needed. I'll still have to think = what would be an acceptable level of simplification, I suppose what you = propose makes sense. I'm not sure why XPath would be so bad on the = server side? > * We could remove show-values, as it also requires xpath. >=20 > * I think we still need transformational attributes. I would=20 > recommend=20 > that "set-element" and "change-value-from" would specify the element=20 > by element-name (i.e., "placetype"), and would impact all=20 > instances of=20 > that element within the presence document. >=20 In general sounds good. Transformational attributes might be useful for = providing different types/levels of presence info to different watcher = groups. >=20 >=20 > What do people think of this scope reduction? >=20 > Thanks, > Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 22 14:11:28 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21316; Tue, 22 Jul 2003 14:11:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f1bl-0006P5-00; Tue, 22 Jul 2003 14:11:29 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f1bf-0006Ox-00; Tue, 22 Jul 2003 14:11:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1bJ-0001cc-CU; Tue, 22 Jul 2003 14:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1b8-0001cH-C7 for simple@optimus.ietf.org; Tue, 22 Jul 2003 14:10:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21272 for ; Tue, 22 Jul 2003 14:10:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f1b5-0006Ot-00 for simple@ietf.org; Tue, 22 Jul 2003 14:10:47 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19f1av-0006O2-00 for simple@ietf.org; Tue, 22 Jul 2003 14:10:37 -0400 Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6MI8TmF000580; Tue, 22 Jul 2003 14:08:36 -0400 (EDT) Message-ID: <3F1D7D9C.3050007@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Silvi Kates CC: "'Markus.Isomaki@nokia.com'" , loretosa@vodafone.it, simple@ietf.org Subject: Re: [Simple] SIMPLE - IM References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 14:08:28 -0400 Content-Transfer-Encoding: 7bit SIP over wireless is just regular SIP. However, signaling compression (http://www.ietf.org/rfc/rfc3320.txt) is used to compress the sip messages. THis occurs at a layer below SIP, so that SIP itself does not change. -Jonathan R. Silvi Kates wrote: > Thanks for your answer. > It was really interesting to read ot. > > Can someone also refer me to documents that will have more details on the > format of the SIMPLE (sip) protocol above wireless networks (what changes > are there specificly )? > Or is it the same format (with SUBSCRIBE, NOTIFY, and MESSAGE ...) > > Thanks > > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Tuesday, July 22, 2003 1:24 PM > To: loretosa@vodafone.it; simple@ietf.org > Subject: RE: RE: [Simple] SIMPLE - IM > > Hi, > > I think this is not a topic to be discussed in SIMPLE mailing list, but > below a short clarification from my point of view, since this seems to be a > FAQ on any SIP related mailing list. > > There are different approaches in running SIP and related applications on > top of wireless networks: > > One approach is to say that there is nothing different between wires and > wireless access links, since everything works on top of IP the same way. I > guess this is generally true for instance in cases where WLAN is used in > home or office environment just to replace the wires. > > Another approach is to consider low capacity links (~20-100 kbps) and > terminals with small displays. For low capacity links there are a couple of > enhancements, most important of which is Signaling Compression, which allows > to reduce the size of packets. Also, some smart ways to deal with large > payloads are needed, so that they wouoldn't block the whole transmission > capacity. For presence specifically, the presence lists spec allows reducing > the number of SUBSCRIBEs that are needed over the wireless access link. For > small displays the main thing is to standardize the protocol(s) to do the > basic manipulation operations for presence lists and authorization policies > etc., so that the user would not have to switch between the presence app > (such as a presence enabled phonebook in a cellular phone) and a Web/WAP > browser. This issue is being addressed by XCAP work in SIMPLE WG. Another > thing is that protocols should be stable and well tested before they are > put to wireless devices on the market, since software updates are still > harder to do than for PC clients. It's also clear that in the first phase it > is easier to run presence, IM etc. on top of wireless access rather than > VoIP. > > Third approach is the one ongoing in 3GPP (and 3GPP2). This is to take into > account all the wireless specific issues mentioned above, but also various > operator, regulatory, interoperability, scalability, security etc. > requirements, that are not necessarily related to wireless access at all, > but to being able to deploy SIP in large operator networks, and to even go > as far as replacing the whole circuit switched telephony system. Also reuse > of existing wireless infra, such as SIM-cards for authentication and > specific codecs for media make sense. Based on this 3GPP has done IP > Multimedia Subsystem (IMS) Release 5 specifications using SIP, Diameter and > other IETF protocols, and is working on Release 6 which will include > presence, IM etc. within a well-defined application server framework. The > initial radio interfaces to be used include WCDMA, GPRS, EDGE (and CDMA-2000 > for 3GPP2), but actually IMS is not limited to any particular access > technology. > > In practice SIP will be deployed in wireless networks with all these three > approaches. Which one is best depends on the environment (small office vs. > large operator - WLAN vs. GPRS - Pocket PC vs. cell phone etc.) and the > requirements (QoS interworking, charging etc.). I guess In most cases people > are referring to 3GPP, when talking about "wireles SIP". > > Regards, > Markus > > >>-----Original Message----- >>From: ext loretosa@vodafone.it [mailto:loretosa@vodafone.it] >>Sent: 22 July, 2003 12:42 >>To: simple@ietf.org >>Subject: Ri:RE: [Simple] SIMPLE - IM >> >> >> >>That's an interesting question... >>some times ago I read something about SIP on wireless and >>congestion issues, >>if I don't wrong written by ericsson people. >> >>So can someone do a summarize about SIP and/or IM on WIRELESS ??? >> >>thanks in advance >>Sal >> >> >> >> >>>Thanks for your answer. >>> >>>I have another small question. >>>Does the known format of IM and Presence (MESSAGE, >> >>SUBSCRIBE, NOTIFY ...) >> >>>used the same way on wireless networks and on wired networks? >>> >>>If not, can anyone point me to some document about the >> >>difference between >> >>>those networks? >>>(or documents of how it being handled on wireless networks?) >>>Thanks again. >>> >>> >>>-----Original Message----- >>>From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>>Sent: Tuesday, July 22, 2003 12:13 PM >>>To: silvik@p-cube.com; simple@ietf.org >>>Subject: RE: [Simple] SIMPLE - IM >>> >>>Hi Silvi, >>> >>>There will be two different paradigms for SIP IM: one-shot >> >>messages using >> >>>MESSAGE method, and messaging sessions using MSRP as the >> >>transport protocol >> >>>for messages. MSRP does not run on top of SIP but directly >> >>on top of TCP. >> >>>SIP INVITE & BYE are just used to setup the messaging >> >>session (using normal >> >>>SDP negotiation). The justification for the two paradigms >> >>is quite well >> >>>presented in the first two chapters of the draft mentioned >> >>in your mail. >> >>> >>>SIP MESSAGE is already an RFC 3428: > > http://www.ietf.org/rfc/rfc3428.txt > >> , and supported by many >>implementations. Messaging Sessions and MSRP are still in a draft phase, > > but > >>getting quite close to be ready. This means that they should appear in the >>"real world" in the next few months. >> >>Rgs, >> Markus >>-----Original Message----- >>From: ext Silvi Kates [mailto:silvik@p-cube.com] >>Sent: 22 July, 2003 11:49 >>To: 'simple@ietf.org' >>Subject: [Simple] SIMPLE - IM >>Hi, >>So far on all the documents and applications of Instant message the Method >>for sending IM messages was >>MESSAGE. >>Now I came across this draft: >>http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessions-01.txt >> > > > >>Which I found in here: http://www.potaroo.net/ietf/ids-wg-simple.html >> >> >>That's suggests that instead of using the MESSAGE method, there are now > > new > >>methods (SEND , VISIT, BIND) >>Of the MSRP (message session relay protocol) that are carried over SIP. >>Is this only a suggestion, or does it really used in real life, on SIP IM >>applications? >> >> >>Thanks >> Silvi >> >> >> >>List of bodypart file names > > > > _______________________________________________ > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 22 14:12:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21342 for ; Tue, 22 Jul 2003 14:12:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1bo-0001gQ-Ll for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 14:11:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MIBWEC006466 for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 14:11:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1bo-0001gD-HY for simple-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 14:11:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21316; Tue, 22 Jul 2003 14:11:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f1bl-0006P5-00; Tue, 22 Jul 2003 14:11:29 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f1bf-0006Ox-00; Tue, 22 Jul 2003 14:11:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1bJ-0001cc-CU; Tue, 22 Jul 2003 14:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1b8-0001cH-C7 for simple@optimus.ietf.org; Tue, 22 Jul 2003 14:10:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21272 for ; Tue, 22 Jul 2003 14:10:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f1b5-0006Ot-00 for simple@ietf.org; Tue, 22 Jul 2003 14:10:47 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19f1av-0006O2-00 for simple@ietf.org; Tue, 22 Jul 2003 14:10:37 -0400 Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6MI8TmF000580; Tue, 22 Jul 2003 14:08:36 -0400 (EDT) Message-ID: <3F1D7D9C.3050007@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Silvi Kates CC: "'Markus.Isomaki@nokia.com'" , loretosa@vodafone.it, simple@ietf.org Subject: Re: [Simple] SIMPLE - IM References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 14:08:28 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit SIP over wireless is just regular SIP. However, signaling compression (http://www.ietf.org/rfc/rfc3320.txt) is used to compress the sip messages. THis occurs at a layer below SIP, so that SIP itself does not change. -Jonathan R. Silvi Kates wrote: > Thanks for your answer. > It was really interesting to read ot. > > Can someone also refer me to documents that will have more details on the > format of the SIMPLE (sip) protocol above wireless networks (what changes > are there specificly )? > Or is it the same format (with SUBSCRIBE, NOTIFY, and MESSAGE ...) > > Thanks > > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Tuesday, July 22, 2003 1:24 PM > To: loretosa@vodafone.it; simple@ietf.org > Subject: RE: RE: [Simple] SIMPLE - IM > > Hi, > > I think this is not a topic to be discussed in SIMPLE mailing list, but > below a short clarification from my point of view, since this seems to be a > FAQ on any SIP related mailing list. > > There are different approaches in running SIP and related applications on > top of wireless networks: > > One approach is to say that there is nothing different between wires and > wireless access links, since everything works on top of IP the same way. I > guess this is generally true for instance in cases where WLAN is used in > home or office environment just to replace the wires. > > Another approach is to consider low capacity links (~20-100 kbps) and > terminals with small displays. For low capacity links there are a couple of > enhancements, most important of which is Signaling Compression, which allows > to reduce the size of packets. Also, some smart ways to deal with large > payloads are needed, so that they wouoldn't block the whole transmission > capacity. For presence specifically, the presence lists spec allows reducing > the number of SUBSCRIBEs that are needed over the wireless access link. For > small displays the main thing is to standardize the protocol(s) to do the > basic manipulation operations for presence lists and authorization policies > etc., so that the user would not have to switch between the presence app > (such as a presence enabled phonebook in a cellular phone) and a Web/WAP > browser. This issue is being addressed by XCAP work in SIMPLE WG. Another > thing is that protocols should be stable and well tested before they are > put to wireless devices on the market, since software updates are still > harder to do than for PC clients. It's also clear that in the first phase it > is easier to run presence, IM etc. on top of wireless access rather than > VoIP. > > Third approach is the one ongoing in 3GPP (and 3GPP2). This is to take into > account all the wireless specific issues mentioned above, but also various > operator, regulatory, interoperability, scalability, security etc. > requirements, that are not necessarily related to wireless access at all, > but to being able to deploy SIP in large operator networks, and to even go > as far as replacing the whole circuit switched telephony system. Also reuse > of existing wireless infra, such as SIM-cards for authentication and > specific codecs for media make sense. Based on this 3GPP has done IP > Multimedia Subsystem (IMS) Release 5 specifications using SIP, Diameter and > other IETF protocols, and is working on Release 6 which will include > presence, IM etc. within a well-defined application server framework. The > initial radio interfaces to be used include WCDMA, GPRS, EDGE (and CDMA-2000 > for 3GPP2), but actually IMS is not limited to any particular access > technology. > > In practice SIP will be deployed in wireless networks with all these three > approaches. Which one is best depends on the environment (small office vs. > large operator - WLAN vs. GPRS - Pocket PC vs. cell phone etc.) and the > requirements (QoS interworking, charging etc.). I guess In most cases people > are referring to 3GPP, when talking about "wireles SIP". > > Regards, > Markus > > >>-----Original Message----- >>From: ext loretosa@vodafone.it [mailto:loretosa@vodafone.it] >>Sent: 22 July, 2003 12:42 >>To: simple@ietf.org >>Subject: Ri:RE: [Simple] SIMPLE - IM >> >> >> >>That's an interesting question... >>some times ago I read something about SIP on wireless and >>congestion issues, >>if I don't wrong written by ericsson people. >> >>So can someone do a summarize about SIP and/or IM on WIRELESS ??? >> >>thanks in advance >>Sal >> >> >> >> >>>Thanks for your answer. >>> >>>I have another small question. >>>Does the known format of IM and Presence (MESSAGE, >> >>SUBSCRIBE, NOTIFY ...) >> >>>used the same way on wireless networks and on wired networks? >>> >>>If not, can anyone point me to some document about the >> >>difference between >> >>>those networks? >>>(or documents of how it being handled on wireless networks?) >>>Thanks again. >>> >>> >>>-----Original Message----- >>>From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>>Sent: Tuesday, July 22, 2003 12:13 PM >>>To: silvik@p-cube.com; simple@ietf.org >>>Subject: RE: [Simple] SIMPLE - IM >>> >>>Hi Silvi, >>> >>>There will be two different paradigms for SIP IM: one-shot >> >>messages using >> >>>MESSAGE method, and messaging sessions using MSRP as the >> >>transport protocol >> >>>for messages. MSRP does not run on top of SIP but directly >> >>on top of TCP. >> >>>SIP INVITE & BYE are just used to setup the messaging >> >>session (using normal >> >>>SDP negotiation). The justification for the two paradigms >> >>is quite well >> >>>presented in the first two chapters of the draft mentioned >> >>in your mail. >> >>> >>>SIP MESSAGE is already an RFC 3428: > > http://www.ietf.org/rfc/rfc3428.txt > >> , and supported by many >>implementations. Messaging Sessions and MSRP are still in a draft phase, > > but > >>getting quite close to be ready. This means that they should appear in the >>"real world" in the next few months. >> >>Rgs, >> Markus >>-----Original Message----- >>From: ext Silvi Kates [mailto:silvik@p-cube.com] >>Sent: 22 July, 2003 11:49 >>To: 'simple@ietf.org' >>Subject: [Simple] SIMPLE - IM >>Hi, >>So far on all the documents and applications of Instant message the Method >>for sending IM messages was >>MESSAGE. >>Now I came across this draft: >>http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessions-01.txt >> > > > >>Which I found in here: http://www.potaroo.net/ietf/ids-wg-simple.html >> >> >>That's suggests that instead of using the MESSAGE method, there are now > > new > >>methods (SEND , VISIT, BIND) >>Of the MSRP (message session relay protocol) that are carried over SIP. >>Is this only a suggestion, or does it really used in real life, on SIP IM >>applications? >> >> >>Thanks >> Silvi >> >> >> >>List of bodypart file names > > > > _______________________________________________ > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 22 19:02:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00133; Tue, 22 Jul 2003 19:02:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f69G-00006b-00; Tue, 22 Jul 2003 19:02:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f69A-00006S-00; Tue, 22 Jul 2003 19:02:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f68v-0004OS-6J; Tue, 22 Jul 2003 19:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f680-0004Mf-Rt for simple@optimus.ietf.org; Tue, 22 Jul 2003 19:01:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00110 for ; Tue, 22 Jul 2003 19:00:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f67x-00006G-00 for simple@ietf.org; Tue, 22 Jul 2003 19:01:01 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19f67m-00005d-00 for simple@ietf.org; Tue, 22 Jul 2003 19:00:50 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6MMxs500176; Tue, 22 Jul 2003 17:59:54 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h6MMxrk15818; Tue, 22 Jul 2003 17:59:53 -0500 (CDT) Message-ID: <3F1DC1E4.60703@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> <3F13080F.4060706@cs.columbia.edu> <3F1330E3.8070407@lucent.com> <3F134E7E.7020409@dynamicsoft.com> <3F145A91.8000006@cs.columbia.edu> <3F1CEC2A.2070304@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 17:59:48 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > W subscribers to B. B's presence server subscribes to S, using B's > credentials. S's presence server says OK, and returns the presence > information B can see. B's presence server returns a presence document > with a tuple for the secretary. It has a URI that resolves to B's > presence server. W SUBSCRIBES to this URI. It routes to B's presence > server. Since S's presence is available at B's presence server, B > returns the presence status. It effectively becomes a state agent. My first thought on reading this was, "yikes! this is complex from an implementation point of view". Are we loosing sight of the fact that in majority of the cases, when W subscribes to B, she is only interested in B's presence; not S's. If B is not available, B's presence document will list S as a surrogate and W can then >>choose<< to click on the S's URI to actively subscribe to S's presence. But the decision on whether to subscribe to S's presence is W's alone. She does not get it implicitly just because she subscribed to B's presence. Using the import technique or if B becomes a state agent for S complicates things tremendously. Henning Schulzrinne wrote: > In the 'password' model that Vijay implicitly proposed, the boss can > create a specific URI, such as E_k(customer,expiration,salt), which is > then handed to the customer who wants to subscribe to the boss (and > the boss' secretary) as a contact. Without further consultation, the > secretary can verify that the boss has "signed" the subscription until > the expiration time. This requires the secretary's presence server to > be able to decode the password and verify it. We had agreed that instead of populating B's presence document with S's tuples, it was far better to provide a reference for S in B's document (see http://www1.ietf.org/mail-archive/working-groups/simple/current/msg01156.html) So, using that concept and the idea of a 'ticket' I proposed earlier we get something like this: Assistant The two problems with this approach that Dr. Schulzrinne pointed out were: > - needs special support in secretary user agent; unless this > is standardized, this isn't going to work in any usable way, > while the "import" mechanism uses standard components that > we already have. and difficult to explain failure cases; again to quote: > With inclusion, if the boss-to-secretary subscription > fails, the boss can deal with it, with local knowledge. If > the ticket/reference fails, the boss won't know and will, > at best, get some vague "your secretary refuses to be > subscribed to" explanation But I think that these problems maybe easier to deal with than the alternative. I wonder if some sort of two factor authentication (like SecureID) can work here? This will prevent replay attacks as the surrogate's URI is good for a few minutes after the boss's presence document is generated. Some timing mechanism (like this URI is good only from 10AM - 2PM) can be either added as URI parameters or attributes to the element. I believe that the attribute is important enough that some manner of convergence around how to implement and understand its semantics will be advantageous down the line. Thoughts? Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 22 19:02:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00173 for ; Tue, 22 Jul 2003 19:02:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f69K-0004Sc-1S for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 19:02:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MN2QnD017140 for simple-archive@odin.ietf.org; Tue, 22 Jul 2003 19:02:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f69J-0004SN-UQ for simple-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 19:02:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00133; Tue, 22 Jul 2003 19:02:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f69G-00006b-00; Tue, 22 Jul 2003 19:02:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f69A-00006S-00; Tue, 22 Jul 2003 19:02:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f68v-0004OS-6J; Tue, 22 Jul 2003 19:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f680-0004Mf-Rt for simple@optimus.ietf.org; Tue, 22 Jul 2003 19:01:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00110 for ; Tue, 22 Jul 2003 19:00:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f67x-00006G-00 for simple@ietf.org; Tue, 22 Jul 2003 19:01:01 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19f67m-00005d-00 for simple@ietf.org; Tue, 22 Jul 2003 19:00:50 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6MMxs500176; Tue, 22 Jul 2003 17:59:54 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h6MMxrk15818; Tue, 22 Jul 2003 17:59:53 -0500 (CDT) Message-ID: <3F1DC1E4.60703@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 CC: Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> <3F13080F.4060706@cs.columbia.edu> <3F1330E3.8070407@lucent.com> <3F134E7E.7020409@dynamicsoft.com> <3F145A91.8000006@cs.columbia.edu> <3F1CEC2A.2070304@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 17:59:48 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > W subscribers to B. B's presence server subscribes to S, using B's > credentials. S's presence server says OK, and returns the presence > information B can see. B's presence server returns a presence document > with a tuple for the secretary. It has a URI that resolves to B's > presence server. W SUBSCRIBES to this URI. It routes to B's presence > server. Since S's presence is available at B's presence server, B > returns the presence status. It effectively becomes a state agent. My first thought on reading this was, "yikes! this is complex from an implementation point of view". Are we loosing sight of the fact that in majority of the cases, when W subscribes to B, she is only interested in B's presence; not S's. If B is not available, B's presence document will list S as a surrogate and W can then >>choose<< to click on the S's URI to actively subscribe to S's presence. But the decision on whether to subscribe to S's presence is W's alone. She does not get it implicitly just because she subscribed to B's presence. Using the import technique or if B becomes a state agent for S complicates things tremendously. Henning Schulzrinne wrote: > In the 'password' model that Vijay implicitly proposed, the boss can > create a specific URI, such as E_k(customer,expiration,salt), which is > then handed to the customer who wants to subscribe to the boss (and > the boss' secretary) as a contact. Without further consultation, the > secretary can verify that the boss has "signed" the subscription until > the expiration time. This requires the secretary's presence server to > be able to decode the password and verify it. We had agreed that instead of populating B's presence document with S's tuples, it was far better to provide a reference for S in B's document (see http://www1.ietf.org/mail-archive/working-groups/simple/current/msg01156.html) So, using that concept and the idea of a 'ticket' I proposed earlier we get something like this: Assistant The two problems with this approach that Dr. Schulzrinne pointed out were: > - needs special support in secretary user agent; unless this > is standardized, this isn't going to work in any usable way, > while the "import" mechanism uses standard components that > we already have. and difficult to explain failure cases; again to quote: > With inclusion, if the boss-to-secretary subscription > fails, the boss can deal with it, with local knowledge. If > the ticket/reference fails, the boss won't know and will, > at best, get some vague "your secretary refuses to be > subscribed to" explanation But I think that these problems maybe easier to deal with than the alternative. I wonder if some sort of two factor authentication (like SecureID) can work here? This will prevent replay attacks as the surrogate's URI is good for a few minutes after the boss's presence document is generated. Some timing mechanism (like this URI is good only from 10AM - 2PM) can be either added as URI parameters or attributes to the element. I believe that the attribute is important enough that some manner of convergence around how to implement and understand its semantics will be advantageous down the line. Thoughts? Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 23 21:51:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09871; Wed, 23 Jul 2003 21:51:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fVGL-0002KD-00; Wed, 23 Jul 2003 21:51:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fVGF-0002K5-00; Wed, 23 Jul 2003 21:51:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fVG2-0003CP-0B; Wed, 23 Jul 2003 21:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fVFZ-0003C9-1X for simple@optimus.ietf.org; Wed, 23 Jul 2003 21:50:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09862 for ; Wed, 23 Jul 2003 21:50:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fVFW-0002Jp-00 for simple@ietf.org; Wed, 23 Jul 2003 21:50:30 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19fVFG-0002JZ-00 for simple@ietf.org; Wed, 23 Jul 2003 21:50:14 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6O1n1l7006519; Wed, 23 Jul 2003 21:49:01 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6O1mxf02757; Wed, 23 Jul 2003 21:48:59 -0400 Message-ID: <3F1F3B08.4060102@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> <3F13080F.4060706@cs.columbia.edu> <3F1330E3.8070407@lucent.com> <3F134E7E.7020409@dynamicsoft.com> <3F145A91.8000006@cs.columbia.edu> <3F1CEC2A.2070304@dynamicsoft.com> <3F1DC1E4.60703@lucent.com> In-Reply-To: <3F1DC1E4.60703@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 23 Jul 2003 21:48:56 -0400 Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > > I believe that the attribute is important enough > that some manner of convergence around how to implement and > understand its semantics will be advantageous down the line. Agreed; it would be nice to support all three models: - plain 'pres' reference; let S and B work it out behind the scenes; does not appear to work well in terms of authorization - ticket, but we would need to standardize the token to have any hope of being usable in practice; requires a shared secret between S and B and needs special support in S and B - inclusion; requires extra effort only by B, but raises philosophical concerns > > - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 23 21:51:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09887 for ; Wed, 23 Jul 2003 21:51:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fVGQ-0003Dz-Az for simple-archive@odin.ietf.org; Wed, 23 Jul 2003 21:51:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O1pQ9a012392 for simple-archive@odin.ietf.org; Wed, 23 Jul 2003 21:51:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fVGQ-0003Dn-6J for simple-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 21:51:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09871; Wed, 23 Jul 2003 21:51:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fVGL-0002KD-00; Wed, 23 Jul 2003 21:51:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fVGF-0002K5-00; Wed, 23 Jul 2003 21:51:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fVG2-0003CP-0B; Wed, 23 Jul 2003 21:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fVFZ-0003C9-1X for simple@optimus.ietf.org; Wed, 23 Jul 2003 21:50:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09862 for ; Wed, 23 Jul 2003 21:50:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fVFW-0002Jp-00 for simple@ietf.org; Wed, 23 Jul 2003 21:50:30 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19fVFG-0002JZ-00 for simple@ietf.org; Wed, 23 Jul 2003 21:50:14 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6O1n1l7006519; Wed, 23 Jul 2003 21:49:01 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6O1mxf02757; Wed, 23 Jul 2003 21:48:59 -0400 Message-ID: <3F1F3B08.4060102@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <2038BCC78B1AD641891A0D1AE133DBB701796EFD@esebe019.ntc.nokia.com> <3F1270D7.70302@cs.columbia.edu> <3F12CB84.7000902@lucent.com> <3F13080F.4060706@cs.columbia.edu> <3F1330E3.8070407@lucent.com> <3F134E7E.7020409@dynamicsoft.com> <3F145A91.8000006@cs.columbia.edu> <3F1CEC2A.2070304@dynamicsoft.com> <3F1DC1E4.60703@lucent.com> In-Reply-To: <3F1DC1E4.60703@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 23 Jul 2003 21:48:56 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > > I believe that the attribute is important enough > that some manner of convergence around how to implement and > understand its semantics will be advantageous down the line. Agreed; it would be nice to support all three models: - plain 'pres' reference; let S and B work it out behind the scenes; does not appear to work well in terms of authorization - ticket, but we would need to standardize the token to have any hope of being usable in practice; requires a shared secret between S and B and needs special support in S and B - inclusion; requires extra effort only by B, but raises philosophical concerns > > - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 24 07:56:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03011; Thu, 24 Jul 2003 07:56:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19feiJ-0005TP-00; Thu, 24 Jul 2003 07:56:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19feiE-0005TM-00; Thu, 24 Jul 2003 07:56:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fehW-0006uO-CD; Thu, 24 Jul 2003 07:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fegv-0006tW-8Q for simple@optimus.ietf.org; Thu, 24 Jul 2003 07:55:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02945 for ; Thu, 24 Jul 2003 07:55:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fegu-0005S0-00 for simple@ietf.org; Thu, 24 Jul 2003 07:55:24 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19fegj-0005RL-00 for simple@ietf.org; Thu, 24 Jul 2003 07:55:13 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA16584; Thu, 24 Jul 2003 07:53:36 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA04725; Thu, 24 Jul 2003 07:53:33 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MZSKW>; Thu, 24 Jul 2003 07:53:33 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5C3E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , "Vijay K. Gurbani" Cc: Jonathan Rosenberg , simple@ietf.org Subject: RE: [Simple] Re: rpids-01 - security and MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 24 Jul 2003 07:53:24 -0400 We've had some customer demand for this kind of thing. One aspect that has not been mentioned is that S is not one person. Either there are M B's and N S's, or at the very least, there is one or more B's and one S, but S has backups. Thus, S is not an actual person, but a role. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, July 23, 2003 9:49 PM > To: Vijay K. Gurbani > Cc: Jonathan Rosenberg; simple@ietf.org > Subject: Re: [Simple] Re: rpids-01 - security and > > > Vijay K. Gurbani wrote: > > > > > > > I believe that the attribute is important enough > > that some manner of convergence around how to implement and > > understand its semantics will be advantageous down the line. > > Agreed; it would be nice to support all three models: > - plain 'pres' reference; let S and B work it out behind the scenes; > does not appear to work well in terms of authorization > > - ticket, but we would need to standardize the token to have > any hope of > being usable in practice; requires a shared secret between S > and B and > needs special support in S and B > > - inclusion; requires extra effort only by B, but raises > philosophical > concerns > > > > > - vijay > > > > _______________________________________________ > 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 exim@www1.ietf.org Thu Jul 24 07:57:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03050 for ; Thu, 24 Jul 2003 07:57:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19feiL-000714-Bq for simple-archive@odin.ietf.org; Thu, 24 Jul 2003 07:56:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OBurLj026966 for simple-archive@odin.ietf.org; Thu, 24 Jul 2003 07:56:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19feiL-00070r-92 for simple-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 07:56:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03011; Thu, 24 Jul 2003 07:56:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19feiJ-0005TP-00; Thu, 24 Jul 2003 07:56:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19feiE-0005TM-00; Thu, 24 Jul 2003 07:56:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fehW-0006uO-CD; Thu, 24 Jul 2003 07:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fegv-0006tW-8Q for simple@optimus.ietf.org; Thu, 24 Jul 2003 07:55:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02945 for ; Thu, 24 Jul 2003 07:55:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fegu-0005S0-00 for simple@ietf.org; Thu, 24 Jul 2003 07:55:24 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19fegj-0005RL-00 for simple@ietf.org; Thu, 24 Jul 2003 07:55:13 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA16584; Thu, 24 Jul 2003 07:53:36 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA04725; Thu, 24 Jul 2003 07:53:33 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MZSKW>; Thu, 24 Jul 2003 07:53:33 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5C3E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , "Vijay K. Gurbani" Cc: Jonathan Rosenberg , simple@ietf.org Subject: RE: [Simple] Re: rpids-01 - security and MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 24 Jul 2003 07:53:24 -0400 We've had some customer demand for this kind of thing. One aspect that has not been mentioned is that S is not one person. Either there are M B's and N S's, or at the very least, there is one or more B's and one S, but S has backups. Thus, S is not an actual person, but a role. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, July 23, 2003 9:49 PM > To: Vijay K. Gurbani > Cc: Jonathan Rosenberg; simple@ietf.org > Subject: Re: [Simple] Re: rpids-01 - security and > > > Vijay K. Gurbani wrote: > > > > > > > I believe that the attribute is important enough > > that some manner of convergence around how to implement and > > understand its semantics will be advantageous down the line. > > Agreed; it would be nice to support all three models: > - plain 'pres' reference; let S and B work it out behind the scenes; > does not appear to work well in terms of authorization > > - ticket, but we would need to standardize the token to have > any hope of > being usable in practice; requires a shared secret between S > and B and > needs special support in S and B > > - inclusion; requires extra effort only by B, but raises > philosophical > concerns > > > > > - vijay > > > > _______________________________________________ > 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-admin@ietf.org Thu Jul 24 09:39:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05877; Thu, 24 Jul 2003 09:39:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fgK1-000660-00; Thu, 24 Jul 2003 09:39:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fgJv-00065x-00; Thu, 24 Jul 2003 09:39:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgJB-0004s8-Du; Thu, 24 Jul 2003 09:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgIV-0004kz-Dq for simple@optimus.ietf.org; Thu, 24 Jul 2003 09:38:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05811 for ; Thu, 24 Jul 2003 09:38:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fgIT-00065R-00 for simple@ietf.org; Thu, 24 Jul 2003 09:38:17 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19fgID-00065J-00 for simple@ietf.org; Thu, 24 Jul 2003 09:38:01 -0400 Received: from cs.columbia.edu (dhcp22.cs.columbia.edu [128.59.19.222]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6ODbQue029931; Thu, 24 Jul 2003 09:37:26 -0400 (EDT) Message-ID: <3F1FE116.8060006@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <313680C9A886D511A06000204840E1CF070B5C3E@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B5C3E@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 24 Jul 2003 09:37:26 -0400 Content-Transfer-Encoding: 7bit This seems similar to AORs like sales@example.com, with some kind of aggregate presence. Here, it would presumably be something like "secretary_pool7@bigcorp.com". Does this change any of the mechanisms, besides maybe complicating any secret management? Rosen, Brian wrote: > We've had some customer demand for this kind of thing. > One aspect that has not been mentioned is that S is not > one person. Either there are M B's and N S's, or > at the very least, there is one or more B's and one S, > but S has backups. > > Thus, S is not an actual person, but a role. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 24 09:40:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05913 for ; Thu, 24 Jul 2003 09:40:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgK3-0004w2-QV for simple-archive@odin.ietf.org; Thu, 24 Jul 2003 09:39:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ODdtEI018964 for simple-archive@odin.ietf.org; Thu, 24 Jul 2003 09:39:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgK3-0004vn-MP for simple-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 09:39:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05877; Thu, 24 Jul 2003 09:39:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fgK1-000660-00; Thu, 24 Jul 2003 09:39:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fgJv-00065x-00; Thu, 24 Jul 2003 09:39:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgJB-0004s8-Du; Thu, 24 Jul 2003 09:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgIV-0004kz-Dq for simple@optimus.ietf.org; Thu, 24 Jul 2003 09:38:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05811 for ; Thu, 24 Jul 2003 09:38:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fgIT-00065R-00 for simple@ietf.org; Thu, 24 Jul 2003 09:38:17 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19fgID-00065J-00 for simple@ietf.org; Thu, 24 Jul 2003 09:38:01 -0400 Received: from cs.columbia.edu (dhcp22.cs.columbia.edu [128.59.19.222]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6ODbQue029931; Thu, 24 Jul 2003 09:37:26 -0400 (EDT) Message-ID: <3F1FE116.8060006@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: simple@ietf.org Subject: Re: [Simple] Re: rpids-01 - security and References: <313680C9A886D511A06000204840E1CF070B5C3E@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B5C3E@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 24 Jul 2003 09:37:26 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This seems similar to AORs like sales@example.com, with some kind of aggregate presence. Here, it would presumably be something like "secretary_pool7@bigcorp.com". Does this change any of the mechanisms, besides maybe complicating any secret management? Rosen, Brian wrote: > We've had some customer demand for this kind of thing. > One aspect that has not been mentioned is that S is not > one person. Either there are M B's and N S's, or > at the very least, there is one or more B's and one S, > but S has backups. > > Thus, S is not an actual person, but a role. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 24 09:53:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06352; Thu, 24 Jul 2003 09:53:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fgXU-0006Au-00; Thu, 24 Jul 2003 09:53:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fgXP-0006Ar-00; Thu, 24 Jul 2003 09:53:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgWj-0005nX-C9; Thu, 24 Jul 2003 09:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgVt-0005iM-T8 for simple@optimus.ietf.org; Thu, 24 Jul 2003 09:52:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06309 for ; Thu, 24 Jul 2003 09:52:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fgVr-0006AT-00 for simple@ietf.org; Thu, 24 Jul 2003 09:52:08 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19fgVh-0006A2-00 for simple@ietf.org; Thu, 24 Jul 2003 09:51:57 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA20436; Thu, 24 Jul 2003 09:50:33 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA21096; Thu, 24 Jul 2003 09:50:33 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MZVYG>; Thu, 24 Jul 2003 09:50:33 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5C45@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" Cc: simple@ietf.org Subject: RE: [Simple] Re: rpids-01 - security and MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 24 Jul 2003 09:50:25 -0400 I think it only affects security issues. Addressing and presence aggregation is easy. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, July 24, 2003 9:37 AM > To: Rosen, Brian > Cc: simple@ietf.org > Subject: Re: [Simple] Re: rpids-01 - security and > > > This seems similar to AORs like sales@example.com, with some kind of > aggregate presence. Here, it would presumably be something like > "secretary_pool7@bigcorp.com". Does this change any of the > mechanisms, > besides maybe complicating any secret management? > > Rosen, Brian wrote: > > > We've had some customer demand for this kind of thing. > > One aspect that has not been mentioned is that S is not > > one person. Either there are M B's and N S's, or > > at the very least, there is one or more B's and one S, > > but S has backups. > > > > Thus, S is not an actual person, but a role. > > > > _______________________________________________ > 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 exim@www1.ietf.org Thu Jul 24 09:54:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06375 for ; Thu, 24 Jul 2003 09:54:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgXX-0005up-Az for simple-archive@odin.ietf.org; Thu, 24 Jul 2003 09:53:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ODrpvS022725 for simple-archive@odin.ietf.org; Thu, 24 Jul 2003 09:53:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgXX-0005uI-79 for simple-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 09:53:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06352; Thu, 24 Jul 2003 09:53:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fgXU-0006Au-00; Thu, 24 Jul 2003 09:53:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fgXP-0006Ar-00; Thu, 24 Jul 2003 09:53:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgWj-0005nX-C9; Thu, 24 Jul 2003 09:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgVt-0005iM-T8 for simple@optimus.ietf.org; Thu, 24 Jul 2003 09:52:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06309 for ; Thu, 24 Jul 2003 09:52:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fgVr-0006AT-00 for simple@ietf.org; Thu, 24 Jul 2003 09:52:08 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19fgVh-0006A2-00 for simple@ietf.org; Thu, 24 Jul 2003 09:51:57 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA20436; Thu, 24 Jul 2003 09:50:33 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA21096; Thu, 24 Jul 2003 09:50:33 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MZVYG>; Thu, 24 Jul 2003 09:50:33 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5C45@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" Cc: simple@ietf.org Subject: RE: [Simple] Re: rpids-01 - security and MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 24 Jul 2003 09:50:25 -0400 I think it only affects security issues. Addressing and presence aggregation is easy. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, July 24, 2003 9:37 AM > To: Rosen, Brian > Cc: simple@ietf.org > Subject: Re: [Simple] Re: rpids-01 - security and > > > This seems similar to AORs like sales@example.com, with some kind of > aggregate presence. Here, it would presumably be something like > "secretary_pool7@bigcorp.com". Does this change any of the > mechanisms, > besides maybe complicating any secret management? > > Rosen, Brian wrote: > > > We've had some customer demand for this kind of thing. > > One aspect that has not been mentioned is that S is not > > one person. Either there are M B's and N S's, or > > at the very least, there is one or more B's and one S, > > but S has backups. > > > > Thus, S is not an actual person, but a role. > > > > _______________________________________________ > 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-admin@ietf.org Mon Jul 28 11:07:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04843; Mon, 28 Jul 2003 11:07:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h9bE-0003Hr-00; Mon, 28 Jul 2003 11:07:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19h9bC-0003Hd-00; Mon, 28 Jul 2003 11:07:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9aY-0000nF-1b; Mon, 28 Jul 2003 11:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19esO8-0003bC-OA for simple@optimus.ietf.org; Tue, 22 Jul 2003 04:20:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05465 for ; Tue, 22 Jul 2003 04:20:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19esO5-0002X4-00 for simple@ietf.org; Tue, 22 Jul 2003 04:20:45 -0400 Received: from [194.90.70.20] (helo=ilexch1.p-cube.com) by ietf-mx with esmtp (Exim 4.12) id 19esNu-0002Wh-00 for simple@ietf.org; Tue, 22 Jul 2003 04:20:35 -0400 Received: by ilexch1.p-cube.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 11:18:50 +0300 Message-ID: From: Silvi Kates MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35029.E0EDADE0" Subject: [Simple] RE: [Sipforum-discussion] PUBLISH method Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 11:18:49 +0300 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_01C35029.E0EDADE0 Content-Type: text/plain Hi, So far on all the documents and applications of Instant message the Method for sending IM messages was MESSAGE. Now I came across this draft: http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessions-01.txt Which I found in here: http://www.potaroo.net/ietf/ids-wg-simple.html That's suggests that instead of using the MESSAGE method, there are now new methods (SEND , VISIT, BIND) Of the MSRP (message session relay protocol) that are carried over SIP. Is this only a suggestion, or does it really used in real life, on SIP IM applications? Thanks Silvi ------_=_NextPart_001_01C35029.E0EDADE0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message

Hi,

So far on all the documents and applications of Instant message the Method for sending IM messages = was

MESSAGE.<= /font>

Now I came across this draft: http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-ses= sions-01.txt

Which I found in here: http://www.potar= oo.net/ietf/ids-wg-simple.html

 

=

That's suggests that instead of using the MESSAGE method, there are now new methods (SEND , VISIT, BIND)

Of the  MSRP (message session = relay protocol) that are carried over SIP.

Is this only a suggestion, or does = it really used in real life, on SIP IM = applications?

 

=

 

=

Thanks

=

 Silvi<= /o:p>

 

------_=_NextPart_001_01C35029.E0EDADE0-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 28 11:07:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04846; Mon, 28 Jul 2003 11:07:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h9bE-0003Hs-00; Mon, 28 Jul 2003 11:07:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19h9bC-0003He-00; Mon, 28 Jul 2003 11:07:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9aX-0000mz-Ln; Mon, 28 Jul 2003 11:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eXRb-0006g9-SU for simple@optimus.ietf.org; Mon, 21 Jul 2003 05:58:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22384 for ; Mon, 21 Jul 2003 05:58:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eXRY-0001P2-00 for simple@ietf.org; Mon, 21 Jul 2003 05:58:56 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 19eXRN-0001Os-00 for simple@ietf.org; Mon, 21 Jul 2003 05:58:45 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Jul 2003 11:57:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] New I-D on presence states for phones Message-ID: Thread-Topic: [Simple] New I-D on presence states for phones Thread-Index: AcNFHDyzWBftwm59RbW1zjJj2htE+QHQtdDQAMNKDOA= From: "MANSOOR Usama FTRD/DMR/LON" To: , , X-OriginalArrivalTime: 21 Jul 2003 09:57:42.0585 (UTC) FILETIME=[86F73290:01C34F6E] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 21 Jul 2003 11:57:38 +0200 Content-Transfer-Encoding: quoted-printable Knowing the link characteristics (bandwidth, delay, etc.) would = certainly be a useful thing for mobile networks, for services that adapt = to the different constraints.=20 What I'd also like to see, in addition to the roaming, is some kind of = indication of what time zone you're in. Hopefully this would allow = telesales people to know not to call me 3.00 am in the morning asking if = I would like buy some double glazing when I'm roaming in a different = country :) -----Original Message----- From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] Sent: Thursday, July 17, 2003 1:50 PM To: jdrosen@dynamicsoft.com; simple@ietf.org Subject: RE: [Simple] New I-D on presence states for phones Hi, I think this draft defines bunch of useful information. However, I would = definitely take away the "signal-strength" attribute under the wireless = phone state. As already stated in the draft, this information is = changing frequently, so I think it is not sensible in the timescale that = SIP events work. And even if it would be possible to convey this = information, what would it mean in GPRS, WCDMA or WiFi? Is there any use = case what any watcher could in _practice_ benefit from this information? = What might be useful as an addition to "ran" is some more information on = the access-link, i.e. that the "downlink capacity class" is ~40 kbps, = and "RTT class" is ~500 ms. This _kind_ of information might give = watchers some idea what _kind_ of applications/media the device could be = able to do at the moment (although you could find that out also through = PIDF/prescaps and SDP negotiations). This kind of info is relatively = static (in the order of minutes rather than seconds), but still = changing. In any case, this would be more valuable than = "signal-strength". =20 Markus=20 > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 08 July, 2003 09:42 > To: Simple WG > Subject: [Simple] New I-D on presence states for phones >=20 >=20 > Folks, >=20 > In case folks havent seen it, I wanted to call your attention to: >=20 > http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s imple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html This draft, written by Jon and myself, defines some PIDF extensions=20 for describing phones, including traditional "black" phones, wireless=20 phones and enterprise phones. I think these will provide invaluable=20 for a device-centric view of a presentity. Comments and questions welcome. Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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-admin@ietf.org Mon Jul 28 11:07:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04875; Mon, 28 Jul 2003 11:07:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h9bD-0003Hm-00; Mon, 28 Jul 2003 11:07:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19h9bC-0003Hc-00; Mon, 28 Jul 2003 11:07:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9aY-0000nV-Cf; Mon, 28 Jul 2003 11:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gJA7-0005IK-7j for simple@optimus.ietf.org; Sat, 26 Jul 2003 03:08:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27419 for ; Sat, 26 Jul 2003 03:08:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gJA2-0004SU-00 for simple@ietf.org; Sat, 26 Jul 2003 03:08:10 -0400 Received: from [61.144.161.2] (helo=mta0.huawei.com) by ietf-mx with esmtp (Exim 4.12) id 19gJ9z-0004Qj-00 for simple@ietf.org; Sat, 26 Jul 2003 03:08:08 -0400 Received: from zhousiyi (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HIM00DIGEE96O@mta0.huawei.com> for simple@ietf.org; Sat, 26 Jul 2003 15:06:10 +0800 (CST) From: Lavis To: simple@ietf.org Message-id: <004a01c35344$9a3434a0$693a0b0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Simple] PUBLISH Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 26 Jul 2003 15:07:40 +0800 Content-Transfer-Encoding: 7BIT Hi, Can somebody tell me why there are two drafts about PUBLISH: draft-ietf-simple-publish-01.txt and draft-olson-simple-publish-02.txt ? And which one I should refer? Thanks Lavis _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 28 11:08:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04920 for ; Mon, 28 Jul 2003 11:08:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9bI-0001Dt-5l for simple-archive@odin.ietf.org; Mon, 28 Jul 2003 11:07:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SF7mtL004691 for simple-archive@odin.ietf.org; Mon, 28 Jul 2003 11:07:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9bI-0001Da-1U for simple-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 11:07:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04846; Mon, 28 Jul 2003 11:07:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h9bE-0003Hs-00; Mon, 28 Jul 2003 11:07:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19h9bC-0003He-00; Mon, 28 Jul 2003 11:07:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9aX-0000mz-Ln; Mon, 28 Jul 2003 11:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eXRb-0006g9-SU for simple@optimus.ietf.org; Mon, 21 Jul 2003 05:58:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22384 for ; Mon, 21 Jul 2003 05:58:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eXRY-0001P2-00 for simple@ietf.org; Mon, 21 Jul 2003 05:58:56 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 19eXRN-0001Os-00 for simple@ietf.org; Mon, 21 Jul 2003 05:58:45 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Jul 2003 11:57:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] New I-D on presence states for phones Message-ID: Thread-Topic: [Simple] New I-D on presence states for phones Thread-Index: AcNFHDyzWBftwm59RbW1zjJj2htE+QHQtdDQAMNKDOA= From: "MANSOOR Usama FTRD/DMR/LON" To: , , X-OriginalArrivalTime: 21 Jul 2003 09:57:42.0585 (UTC) FILETIME=[86F73290:01C34F6E] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 21 Jul 2003 11:57:38 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Knowing the link characteristics (bandwidth, delay, etc.) would = certainly be a useful thing for mobile networks, for services that adapt = to the different constraints.=20 What I'd also like to see, in addition to the roaming, is some kind of = indication of what time zone you're in. Hopefully this would allow = telesales people to know not to call me 3.00 am in the morning asking if = I would like buy some double glazing when I'm roaming in a different = country :) -----Original Message----- From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] Sent: Thursday, July 17, 2003 1:50 PM To: jdrosen@dynamicsoft.com; simple@ietf.org Subject: RE: [Simple] New I-D on presence states for phones Hi, I think this draft defines bunch of useful information. However, I would = definitely take away the "signal-strength" attribute under the wireless = phone state. As already stated in the draft, this information is = changing frequently, so I think it is not sensible in the timescale that = SIP events work. And even if it would be possible to convey this = information, what would it mean in GPRS, WCDMA or WiFi? Is there any use = case what any watcher could in _practice_ benefit from this information? = What might be useful as an addition to "ran" is some more information on = the access-link, i.e. that the "downlink capacity class" is ~40 kbps, = and "RTT class" is ~500 ms. This _kind_ of information might give = watchers some idea what _kind_ of applications/media the device could be = able to do at the moment (although you could find that out also through = PIDF/prescaps and SDP negotiations). This kind of info is relatively = static (in the order of minutes rather than seconds), but still = changing. In any case, this would be more valuable than = "signal-strength". =20 Markus=20 > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 08 July, 2003 09:42 > To: Simple WG > Subject: [Simple] New I-D on presence states for phones >=20 >=20 > Folks, >=20 > In case folks havent seen it, I wanted to call your attention to: >=20 > http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s imple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html This draft, written by Jon and myself, defines some PIDF extensions=20 for describing phones, including traditional "black" phones, wireless=20 phones and enterprise phones. I think these will provide invaluable=20 for a device-centric view of a presentity. Comments and questions welcome. Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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 exim@www1.ietf.org Mon Jul 28 11:08:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04935 for ; Mon, 28 Jul 2003 11:08:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9bK-0001Es-8W for simple-archive@odin.ietf.org; Mon, 28 Jul 2003 11:07:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SF7ojk004756 for simple-archive@odin.ietf.org; Mon, 28 Jul 2003 11:07:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9bK-0001Ed-48 for simple-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 11:07:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04875; Mon, 28 Jul 2003 11:07:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h9bD-0003Hm-00; Mon, 28 Jul 2003 11:07:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19h9bC-0003Hc-00; Mon, 28 Jul 2003 11:07:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9aY-0000nV-Cf; Mon, 28 Jul 2003 11:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gJA7-0005IK-7j for simple@optimus.ietf.org; Sat, 26 Jul 2003 03:08:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27419 for ; Sat, 26 Jul 2003 03:08:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gJA2-0004SU-00 for simple@ietf.org; Sat, 26 Jul 2003 03:08:10 -0400 Received: from [61.144.161.2] (helo=mta0.huawei.com) by ietf-mx with esmtp (Exim 4.12) id 19gJ9z-0004Qj-00 for simple@ietf.org; Sat, 26 Jul 2003 03:08:08 -0400 Received: from zhousiyi (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HIM00DIGEE96O@mta0.huawei.com> for simple@ietf.org; Sat, 26 Jul 2003 15:06:10 +0800 (CST) From: Lavis To: simple@ietf.org Message-id: <004a01c35344$9a3434a0$693a0b0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Simple] PUBLISH Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 26 Jul 2003 15:07:40 +0800 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, Can somebody tell me why there are two drafts about PUBLISH: draft-ietf-simple-publish-01.txt and draft-olson-simple-publish-02.txt ? And which one I should refer? Thanks Lavis _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jul 28 11:08:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04953 for ; Mon, 28 Jul 2003 11:08:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9bH-0001DV-A6 for simple-archive@odin.ietf.org; Mon, 28 Jul 2003 11:07:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SF7leZ004675 for simple-archive@odin.ietf.org; Mon, 28 Jul 2003 11:07:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9bH-0001DK-6M for simple-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 11:07:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04843; Mon, 28 Jul 2003 11:07:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h9bE-0003Hr-00; Mon, 28 Jul 2003 11:07:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19h9bC-0003Hd-00; Mon, 28 Jul 2003 11:07:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9aY-0000nF-1b; Mon, 28 Jul 2003 11:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19esO8-0003bC-OA for simple@optimus.ietf.org; Tue, 22 Jul 2003 04:20:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05465 for ; Tue, 22 Jul 2003 04:20:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19esO5-0002X4-00 for simple@ietf.org; Tue, 22 Jul 2003 04:20:45 -0400 Received: from [194.90.70.20] (helo=ilexch1.p-cube.com) by ietf-mx with esmtp (Exim 4.12) id 19esNu-0002Wh-00 for simple@ietf.org; Tue, 22 Jul 2003 04:20:35 -0400 Received: by ilexch1.p-cube.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 11:18:50 +0300 Message-ID: From: Silvi Kates MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35029.E0EDADE0" Subject: [Simple] RE: [Sipforum-discussion] PUBLISH method Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 11:18:49 +0300 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_01C35029.E0EDADE0 Content-Type: text/plain Hi, So far on all the documents and applications of Instant message the Method for sending IM messages was MESSAGE. Now I came across this draft: http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-sessions-01.txt Which I found in here: http://www.potaroo.net/ietf/ids-wg-simple.html That's suggests that instead of using the MESSAGE method, there are now new methods (SEND , VISIT, BIND) Of the MSRP (message session relay protocol) that are carried over SIP. Is this only a suggestion, or does it really used in real life, on SIP IM applications? Thanks Silvi ------_=_NextPart_001_01C35029.E0EDADE0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message

Hi,

So far on all the documents and applications of Instant message the Method for sending IM messages = was

MESSAGE.<= /font>

Now I came across this draft: http://www.potaroo.net/ietf/ids/draft-ietf-simple-message-ses= sions-01.txt

Which I found in here: http://www.potar= oo.net/ietf/ids-wg-simple.html

 

=

That's suggests that instead of using the MESSAGE method, there are now new methods (SEND , VISIT, BIND)

Of the  MSRP (message session = relay protocol) that are carried over SIP.

Is this only a suggestion, or does = it really used in real life, on SIP IM = applications?

 

=

 

=

Thanks

=

 Silvi<= /o:p>

 

------_=_NextPart_001_01C35029.E0EDADE0-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jul 28 14:04:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14341; Mon, 28 Jul 2003 14:04:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hCKz-0006Gt-00; Mon, 28 Jul 2003 14:03:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hCKy-0006Gq-00; Mon, 28 Jul 2003 14:03:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hCKq-0000bB-Pp; Mon, 28 Jul 2003 14:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hCJt-0000aD-Dz for simple@optimus.ietf.org; Mon, 28 Jul 2003 14:02:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14294 for ; Mon, 28 Jul 2003 14:01:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hCJr-0006GS-00 for simple@ietf.org; Mon, 28 Jul 2003 14:01:59 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 19hCJq-0006GM-00 for simple@ietf.org; Mon, 28 Jul 2003 14:01:58 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h6SI1l6X000637; Mon, 28 Jul 2003 11:01:48 -0700 (PDT) Received: from MAHENDRA.qualcomm.com (mahendra.qualcomm.com [129.46.75.104]) by sabrina.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h6SI1jBC020342; Mon, 28 Jul 2003 11:01:46 -0700 (PDT) Message-Id: <5.2.0.9.2.20030728105937.01e65bd8@m2.qualcomm.com> X-Sender: mahendra@m2.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Lavis , simple@ietf.org From: AC Mahendran Subject: Re: [Simple] PUBLISH In-Reply-To: <004a01c35344$9a3434a0$693a0b0a@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 28 Jul 2003 11:01:44 -0700 Use draft-ietf-simple-publish-01.txt (the draft-olson-simple-publish-02.txt has been merged with this one) -AC At 03:07 PM 7/26/2003 +0800, Lavis wrote: >Hi, > >Can somebody tell me why there are two drafts about PUBLISH: > >draft-ietf-simple-publish-01.txt and >draft-olson-simple-publish-02.txt >? > >And which one I should refer? > >Thanks >Lavis > >_______________________________________________ >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 exim@www1.ietf.org Mon Jul 28 14:04:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14400 for ; Mon, 28 Jul 2003 14:04:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hCM4-0000fF-HB for simple-archive@odin.ietf.org; Mon, 28 Jul 2003 14:04:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SI4GhA002547 for simple-archive@odin.ietf.org; Mon, 28 Jul 2003 14:04:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hCM4-0000f0-Cv for simple-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 14:04:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14341; Mon, 28 Jul 2003 14:04:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hCKz-0006Gt-00; Mon, 28 Jul 2003 14:03:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hCKy-0006Gq-00; Mon, 28 Jul 2003 14:03:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hCKq-0000bB-Pp; Mon, 28 Jul 2003 14:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hCJt-0000aD-Dz for simple@optimus.ietf.org; Mon, 28 Jul 2003 14:02:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14294 for ; Mon, 28 Jul 2003 14:01:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hCJr-0006GS-00 for simple@ietf.org; Mon, 28 Jul 2003 14:01:59 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 19hCJq-0006GM-00 for simple@ietf.org; Mon, 28 Jul 2003 14:01:58 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h6SI1l6X000637; Mon, 28 Jul 2003 11:01:48 -0700 (PDT) Received: from MAHENDRA.qualcomm.com (mahendra.qualcomm.com [129.46.75.104]) by sabrina.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h6SI1jBC020342; Mon, 28 Jul 2003 11:01:46 -0700 (PDT) Message-Id: <5.2.0.9.2.20030728105937.01e65bd8@m2.qualcomm.com> X-Sender: mahendra@m2.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Lavis , simple@ietf.org From: AC Mahendran Subject: Re: [Simple] PUBLISH In-Reply-To: <004a01c35344$9a3434a0$693a0b0a@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 28 Jul 2003 11:01:44 -0700 Use draft-ietf-simple-publish-01.txt (the draft-olson-simple-publish-02.txt has been merged with this one) -AC At 03:07 PM 7/26/2003 +0800, Lavis wrote: >Hi, > >Can somebody tell me why there are two drafts about PUBLISH: > >draft-ietf-simple-publish-01.txt and >draft-olson-simple-publish-02.txt >? > >And which one I should refer? > >Thanks >Lavis > >_______________________________________________ >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-admin@ietf.org Mon Jul 28 20:36:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25719; Mon, 28 Jul 2003 20:36:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hITM-0001Sl-00; Mon, 28 Jul 2003 20:36:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hITL-0001Si-00; Mon, 28 Jul 2003 20:36:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hITC-0002zb-PF; Mon, 28 Jul 2003 20:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hISV-0002z3-Vm for simple@optimus.ietf.org; Mon, 28 Jul 2003 20:35:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25707 for ; Mon, 28 Jul 2003 20:35:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hIST-0001SC-00 for simple@ietf.org; Mon, 28 Jul 2003 20:35:17 -0400 Received: from mgw2.noc.ntt.com ([210.163.32.69]) by ietf-mx with esmtp (Exim 4.12) id 19hISS-0001Ri-00 for simple@ietf.org; Mon, 28 Jul 2003 20:35:17 -0400 Received: from mop2.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id h6T0YPJW018700; Tue, 29 Jul 2003 09:34:25 +0900 (JST) Received: from mip2.noc.ntt.com (mvi2.noc.ntt.com) by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0HIR0057JG9DAG@ntt.com>; Tue, 29 Jul 2003 09:34:25 +0900 (JST) Received: from nttu26skyyrabi by mip2.noc.ntt.com (NTT-Com MailSV) with SMTP id <0HIR00CKXG9DNU@ntt.com>; Tue, 29 Jul 2003 09:34:25 +0900 (JST) Content-return: prohibited From: "Ashir Ahmed" Subject: Re: [Simple] New I-D on presence states for phones To: "MANSOOR Usama FTRD/DMR/LON" , Markus.Isomaki@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org Message-id: <011601c35568$1ae23d20$cd44320a@nttu26skyyrabi> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 09:26:51 +0900 Content-Transfer-Encoding: 7bit Hi Mansoor, A location object carries location information (geographic or civil) of a device. http://www.ietf.org/internet-drafts/draft-ietf-geopriv-reqs-03.txt Time-zone information can be included into the location object as a location data type or can be calculated locally by the presence server or by the endpoint. Ashir ----- Original Message ----- From: "MANSOOR Usama FTRD/DMR/LON" To: ; ; Sent: Monday, July 21, 2003 6:57 PM Subject: RE: [Simple] New I-D on presence states for phones Knowing the link characteristics (bandwidth, delay, etc.) would certainly be a useful thing for mobile networks, for services that adapt to the different constraints. What I'd also like to see, in addition to the roaming, is some kind of indication of what time zone you're in. Hopefully this would allow telesales people to know not to call me 3.00 am in the morning asking if I would like buy some double glazing when I'm roaming in a different country :) -----Original Message----- From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] Sent: Thursday, July 17, 2003 1:50 PM To: jdrosen@dynamicsoft.com; simple@ietf.org Subject: RE: [Simple] New I-D on presence states for phones Hi, I think this draft defines bunch of useful information. However, I would definitely take away the "signal-strength" attribute under the wireless phone state. As already stated in the draft, this information is changing frequently, so I think it is not sensible in the timescale that SIP events work. And even if it would be possible to convey this information, what would it mean in GPRS, WCDMA or WiFi? Is there any use case what any watcher could in _practice_ benefit from this information? What might be useful as an addition to "ran" is some more information on the access-link, i.e. that the "downlink capacity class" is ~40 kbps, and "RTT class" is ~500 ms. This _kind_ of information might give watchers some idea what _kind_ of applications/media the device could be able to do at the moment (although you could find that out also through PIDF/prescaps and SDP negotiations). This kind of info is relatively static (in the order of minutes rather than seconds), but still changing. In any case, this would be more valuable than "signal-strength". Markus > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 08 July, 2003 09:42 > To: Simple WG > Subject: [Simple] New I-D on presence states for phones > > > Folks, > > In case folks havent seen it, I wanted to call your attention to: > > http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s imple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html This draft, written by Jon and myself, defines some PIDF extensions for describing phones, including traditional "black" phones, wireless phones and enterprise phones. I think these will provide invaluable for a device-centric view of a presentity. Comments and questions welcome. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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 exim@www1.ietf.org Mon Jul 28 20:36:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25738 for ; Mon, 28 Jul 2003 20:36:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hITP-00031O-3e for simple-archive@odin.ietf.org; Mon, 28 Jul 2003 20:36:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T0aFJg011610 for simple-archive@odin.ietf.org; Mon, 28 Jul 2003 20:36:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hITP-00031B-0q for simple-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 20:36:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25719; Mon, 28 Jul 2003 20:36:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hITM-0001Sl-00; Mon, 28 Jul 2003 20:36:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hITL-0001Si-00; Mon, 28 Jul 2003 20:36:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hITC-0002zb-PF; Mon, 28 Jul 2003 20:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hISV-0002z3-Vm for simple@optimus.ietf.org; Mon, 28 Jul 2003 20:35:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25707 for ; Mon, 28 Jul 2003 20:35:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hIST-0001SC-00 for simple@ietf.org; Mon, 28 Jul 2003 20:35:17 -0400 Received: from mgw2.noc.ntt.com ([210.163.32.69]) by ietf-mx with esmtp (Exim 4.12) id 19hISS-0001Ri-00 for simple@ietf.org; Mon, 28 Jul 2003 20:35:17 -0400 Received: from mop2.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id h6T0YPJW018700; Tue, 29 Jul 2003 09:34:25 +0900 (JST) Received: from mip2.noc.ntt.com (mvi2.noc.ntt.com) by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0HIR0057JG9DAG@ntt.com>; Tue, 29 Jul 2003 09:34:25 +0900 (JST) Received: from nttu26skyyrabi by mip2.noc.ntt.com (NTT-Com MailSV) with SMTP id <0HIR00CKXG9DNU@ntt.com>; Tue, 29 Jul 2003 09:34:25 +0900 (JST) Content-return: prohibited From: "Ashir Ahmed" Subject: Re: [Simple] New I-D on presence states for phones To: "MANSOOR Usama FTRD/DMR/LON" , Markus.Isomaki@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org Message-id: <011601c35568$1ae23d20$cd44320a@nttu26skyyrabi> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 09:26:51 +0900 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Mansoor, A location object carries location information (geographic or civil) of a device. http://www.ietf.org/internet-drafts/draft-ietf-geopriv-reqs-03.txt Time-zone information can be included into the location object as a location data type or can be calculated locally by the presence server or by the endpoint. Ashir ----- Original Message ----- From: "MANSOOR Usama FTRD/DMR/LON" To: ; ; Sent: Monday, July 21, 2003 6:57 PM Subject: RE: [Simple] New I-D on presence states for phones Knowing the link characteristics (bandwidth, delay, etc.) would certainly be a useful thing for mobile networks, for services that adapt to the different constraints. What I'd also like to see, in addition to the roaming, is some kind of indication of what time zone you're in. Hopefully this would allow telesales people to know not to call me 3.00 am in the morning asking if I would like buy some double glazing when I'm roaming in a different country :) -----Original Message----- From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] Sent: Thursday, July 17, 2003 1:50 PM To: jdrosen@dynamicsoft.com; simple@ietf.org Subject: RE: [Simple] New I-D on presence states for phones Hi, I think this draft defines bunch of useful information. However, I would definitely take away the "signal-strength" attribute under the wireless phone state. As already stated in the draft, this information is changing frequently, so I think it is not sensible in the timescale that SIP events work. And even if it would be possible to convey this information, what would it mean in GPRS, WCDMA or WiFi? Is there any use case what any watcher could in _practice_ benefit from this information? What might be useful as an addition to "ran" is some more information on the access-link, i.e. that the "downlink capacity class" is ~40 kbps, and "RTT class" is ~500 ms. This _kind_ of information might give watchers some idea what _kind_ of applications/media the device could be able to do at the moment (although you could find that out also through PIDF/prescaps and SDP negotiations). This kind of info is relatively static (in the order of minutes rather than seconds), but still changing. In any case, this would be more valuable than "signal-strength". Markus > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 08 July, 2003 09:42 > To: Simple WG > Subject: [Simple] New I-D on presence states for phones > > > Folks, > > In case folks havent seen it, I wanted to call your attention to: > > http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s imple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html This draft, written by Jon and myself, defines some PIDF extensions for describing phones, including traditional "black" phones, wireless phones and enterprise phones. I think these will provide invaluable for a device-centric view of a presentity. Comments and questions welcome. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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-admin@ietf.org Tue Jul 29 01:55:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01088; Tue, 29 Jul 2003 01:55:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hNS4-0002q8-00; Tue, 29 Jul 2003 01:55:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hNS3-0002q5-00; Tue, 29 Jul 2003 01:55:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNRs-0004Dz-OJ; Tue, 29 Jul 2003 01:55:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNR1-0004DR-1W for simple@optimus.ietf.org; Tue, 29 Jul 2003 01:54:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01074 for ; Tue, 29 Jul 2003 01:54:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hNQx-0002pr-00 for simple@ietf.org; Tue, 29 Jul 2003 01:54:03 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19hNQx-0002pm-00 for simple@ietf.org; Tue, 29 Jul 2003 01:54:03 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6T5rS6Y003080; Tue, 29 Jul 2003 01:53:29 -0400 (EDT) Message-ID: <3F260BD6.9090100@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: hgs@cs.columbia.edu, simple@ietf.org Subject: Re: reducing xcap-auth scope, was: Re: [Simple] A proposal for xcap direction References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 01:53:26 -0400 Content-Transfer-Encoding: 7bit I was hoping for some additional comments on scope from folks besides Markus and Henning. Please do comment. In the interim, I will rev xcap-auth to descope it based on the discussion here. One response inline: Markus.Isomaki@nokia.com wrote: > > >> * I think we still need content-permissions. We could descope >> show-element so that you can only give permission by element >> name, not by xpath expression. What do we lose if we do this? If >> a presence doc has two tuples, and you wanted to allow a watcher >> to see "placetype" in one, but not the other, you couldnt do it. >> you could only allow or disallow "placetype" for any tuple. I >> think thats OK for the first version. >> > > > Content permissions would definitely be needed. I'll still have to > think what would be an acceptable level of simplification, I > suppose what you propose makes sense. I'm not sure why XPath would > be so bad on the server side? Its not complexity, so much as that the user needs to guess where in the XML document the data will show up. Its the same issue with using Xpath for filters that I have expressed previously. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 29 01:55:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01112 for ; Tue, 29 Jul 2003 01:55:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNS8-0004Eq-AM for simple-archive@odin.ietf.org; Tue, 29 Jul 2003 01:55:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T5tGQi016286 for simple-archive@odin.ietf.org; Tue, 29 Jul 2003 01:55:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNS8-0004Eb-7N for simple-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 01:55:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01088; Tue, 29 Jul 2003 01:55:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hNS4-0002q8-00; Tue, 29 Jul 2003 01:55:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hNS3-0002q5-00; Tue, 29 Jul 2003 01:55:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNRs-0004Dz-OJ; Tue, 29 Jul 2003 01:55:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNR1-0004DR-1W for simple@optimus.ietf.org; Tue, 29 Jul 2003 01:54:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01074 for ; Tue, 29 Jul 2003 01:54:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hNQx-0002pr-00 for simple@ietf.org; Tue, 29 Jul 2003 01:54:03 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19hNQx-0002pm-00 for simple@ietf.org; Tue, 29 Jul 2003 01:54:03 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6T5rS6Y003080; Tue, 29 Jul 2003 01:53:29 -0400 (EDT) Message-ID: <3F260BD6.9090100@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: hgs@cs.columbia.edu, simple@ietf.org Subject: Re: reducing xcap-auth scope, was: Re: [Simple] A proposal for xcap direction References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 01:53:26 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I was hoping for some additional comments on scope from folks besides Markus and Henning. Please do comment. In the interim, I will rev xcap-auth to descope it based on the discussion here. One response inline: Markus.Isomaki@nokia.com wrote: > > >> * I think we still need content-permissions. We could descope >> show-element so that you can only give permission by element >> name, not by xpath expression. What do we lose if we do this? If >> a presence doc has two tuples, and you wanted to allow a watcher >> to see "placetype" in one, but not the other, you couldnt do it. >> you could only allow or disallow "placetype" for any tuple. I >> think thats OK for the first version. >> > > > Content permissions would definitely be needed. I'll still have to > think what would be an acceptable level of simplification, I > suppose what you propose makes sense. I'm not sure why XPath would > be so bad on the server side? Its not complexity, so much as that the user needs to guess where in the XML document the data will show up. Its the same issue with using Xpath for filters that I have expressed previously. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jul 29 10:02:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23019; Tue, 29 Jul 2003 10:02:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hV3u-0005kO-00; Tue, 29 Jul 2003 10:02:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hV3t-0005kL-00; Tue, 29 Jul 2003 10:02:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hV3B-0003jo-34; Tue, 29 Jul 2003 10:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUct-0002wp-GU for simple@optimus.ietf.org; Tue, 29 Jul 2003 09:34:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22329 for ; Tue, 29 Jul 2003 09:34:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hUcr-0005WO-00 for simple@ietf.org; Tue, 29 Jul 2003 09:34:49 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 19hUcr-0005WH-00 for simple@ietf.org; Tue, 29 Jul 2003 09:34:49 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Jul 2003 13:18:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] New I-D on presence states for phones Message-ID: Thread-Topic: [Simple] New I-D on presence states for phones Thread-Index: AcNVaVSSoXsiVkSeQ16BgQB6GUWV4gAWDNgQ From: "MANSOOR Usama FTRD/DMR/LON" To: "Ashir Ahmed" , , , X-OriginalArrivalTime: 29 Jul 2003 11:18:22.0152 (UTC) FILETIME=[1EE08480:01C355C3] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 13:18:21 +0200 Content-Transfer-Encoding: quoted-printable Hi Ashir, Thanks for pointing me towards how to obtain the timezone info. Now, = with this information, I would like a kind of 'presence state' = (apologies if that's the wrong terminology) that shows quickly that I'm = available, but, say, 5 hours ahead. So, a presence state that is the = timezone.=20 - Usama -----Original Message----- From: Ashir Ahmed [mailto:a.ahmed@ntt.com] Sent: Tuesday, July 29, 2003 1:27 AM To: MANSOOR Usama FTRD/DMR/LON; Markus.Isomaki@nokia.com; jdrosen@dynamicsoft.com; simple@ietf.org Subject: Re: [Simple] New I-D on presence states for phones Hi Mansoor, A location object carries location information (geographic or civil) of = a device. http://www.ietf.org/internet-drafts/draft-ietf-geopriv-reqs-03.txt Time-zone information can be included into the location object as a = location data type or can be calculated locally by the presence server or by the endpoint. Ashir ----- Original Message ----- From: "MANSOOR Usama FTRD/DMR/LON" To: ; ; = Sent: Monday, July 21, 2003 6:57 PM Subject: RE: [Simple] New I-D on presence states for phones Knowing the link characteristics (bandwidth, delay, etc.) would = certainly be a useful thing for mobile networks, for services that adapt to the = different constraints. What I'd also like to see, in addition to the roaming, is some kind of indication of what time zone you're in. Hopefully this would allow = telesales people to know not to call me 3.00 am in the morning asking if I would = like buy some double glazing when I'm roaming in a different country :) -----Original Message----- From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] Sent: Thursday, July 17, 2003 1:50 PM To: jdrosen@dynamicsoft.com; simple@ietf.org Subject: RE: [Simple] New I-D on presence states for phones Hi, I think this draft defines bunch of useful information. However, I would definitely take away the "signal-strength" attribute under the wireless phone state. As already stated in the draft, this information is = changing frequently, so I think it is not sensible in the timescale that SIP = events work. And even if it would be possible to convey this information, what would it mean in GPRS, WCDMA or WiFi? Is there any use case what any = watcher could in _practice_ benefit from this information? What might be useful as an addition to "ran" is some more information on = the access-link, i.e. that the "downlink capacity class" is ~40 kbps, and = "RTT class" is ~500 ms. This _kind_ of information might give watchers some = idea what _kind_ of applications/media the device could be able to do at the moment (although you could find that out also through PIDF/prescaps and = SDP negotiations). This kind of info is relatively static (in the order of minutes rather than seconds), but still changing. In any case, this = would be more valuable than "signal-strength". Markus > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 08 July, 2003 09:42 > To: Simple WG > Subject: [Simple] New I-D on presence states for phones > > > Folks, > > In case folks havent seen it, I wanted to call your attention to: > > http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s imple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html This draft, written by Jon and myself, defines some PIDF extensions for describing phones, including traditional "black" phones, wireless phones and enterprise phones. I think these will provide invaluable for a device-centric view of a presentity. Comments and questions welcome. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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 exim@www1.ietf.org Tue Jul 29 10:03:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23044 for ; Tue, 29 Jul 2003 10:03:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hV3x-0003nY-Bg for simple-archive@odin.ietf.org; Tue, 29 Jul 2003 10:02:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TE2nmd014600 for simple-archive@odin.ietf.org; Tue, 29 Jul 2003 10:02:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hV3x-0003nP-5B for simple-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 10:02:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23019; Tue, 29 Jul 2003 10:02:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hV3u-0005kO-00; Tue, 29 Jul 2003 10:02:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hV3t-0005kL-00; Tue, 29 Jul 2003 10:02:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hV3B-0003jo-34; Tue, 29 Jul 2003 10:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUct-0002wp-GU for simple@optimus.ietf.org; Tue, 29 Jul 2003 09:34:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22329 for ; Tue, 29 Jul 2003 09:34:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hUcr-0005WO-00 for simple@ietf.org; Tue, 29 Jul 2003 09:34:49 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 19hUcr-0005WH-00 for simple@ietf.org; Tue, 29 Jul 2003 09:34:49 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Jul 2003 13:18:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] New I-D on presence states for phones Message-ID: Thread-Topic: [Simple] New I-D on presence states for phones Thread-Index: AcNVaVSSoXsiVkSeQ16BgQB6GUWV4gAWDNgQ From: "MANSOOR Usama FTRD/DMR/LON" To: "Ashir Ahmed" , , , X-OriginalArrivalTime: 29 Jul 2003 11:18:22.0152 (UTC) FILETIME=[1EE08480:01C355C3] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 13:18:21 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Ashir, Thanks for pointing me towards how to obtain the timezone info. Now, = with this information, I would like a kind of 'presence state' = (apologies if that's the wrong terminology) that shows quickly that I'm = available, but, say, 5 hours ahead. So, a presence state that is the = timezone.=20 - Usama -----Original Message----- From: Ashir Ahmed [mailto:a.ahmed@ntt.com] Sent: Tuesday, July 29, 2003 1:27 AM To: MANSOOR Usama FTRD/DMR/LON; Markus.Isomaki@nokia.com; jdrosen@dynamicsoft.com; simple@ietf.org Subject: Re: [Simple] New I-D on presence states for phones Hi Mansoor, A location object carries location information (geographic or civil) of = a device. http://www.ietf.org/internet-drafts/draft-ietf-geopriv-reqs-03.txt Time-zone information can be included into the location object as a = location data type or can be calculated locally by the presence server or by the endpoint. Ashir ----- Original Message ----- From: "MANSOOR Usama FTRD/DMR/LON" To: ; ; = Sent: Monday, July 21, 2003 6:57 PM Subject: RE: [Simple] New I-D on presence states for phones Knowing the link characteristics (bandwidth, delay, etc.) would = certainly be a useful thing for mobile networks, for services that adapt to the = different constraints. What I'd also like to see, in addition to the roaming, is some kind of indication of what time zone you're in. Hopefully this would allow = telesales people to know not to call me 3.00 am in the morning asking if I would = like buy some double glazing when I'm roaming in a different country :) -----Original Message----- From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] Sent: Thursday, July 17, 2003 1:50 PM To: jdrosen@dynamicsoft.com; simple@ietf.org Subject: RE: [Simple] New I-D on presence states for phones Hi, I think this draft defines bunch of useful information. However, I would definitely take away the "signal-strength" attribute under the wireless phone state. As already stated in the draft, this information is = changing frequently, so I think it is not sensible in the timescale that SIP = events work. And even if it would be possible to convey this information, what would it mean in GPRS, WCDMA or WiFi? Is there any use case what any = watcher could in _practice_ benefit from this information? What might be useful as an addition to "ran" is some more information on = the access-link, i.e. that the "downlink capacity class" is ~40 kbps, and = "RTT class" is ~500 ms. This _kind_ of information might give watchers some = idea what _kind_ of applications/media the device could be able to do at the moment (although you could find that out also through PIDF/prescaps and = SDP negotiations). This kind of info is relatively static (in the order of minutes rather than seconds), but still changing. In any case, this = would be more valuable than "signal-strength". Markus > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 08 July, 2003 09:42 > To: Simple WG > Subject: [Simple] New I-D on presence states for phones > > > Folks, > > In case folks havent seen it, I wanted to call your attention to: > > http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s imple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html This draft, written by Jon and myself, defines some PIDF extensions for describing phones, including traditional "black" phones, wireless phones and enterprise phones. I think these will provide invaluable for a device-centric view of a presentity. Comments and questions welcome. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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-admin@ietf.org Tue Jul 29 18:58:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14273; Tue, 29 Jul 2003 18:58:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hdQ0-0002hv-00; Tue, 29 Jul 2003 18:58:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hdQ0-0002hq-00; Tue, 29 Jul 2003 18:58:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdPs-0003LW-KD; Tue, 29 Jul 2003 18:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdPb-0003LF-HE for simple@optimus.ietf.org; Tue, 29 Jul 2003 18:57:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14248 for ; Tue, 29 Jul 2003 18:57:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hdPY-0002hi-00 for simple@ietf.org; Tue, 29 Jul 2003 18:57:40 -0400 Received: from mtiwmhc11.worldnet.att.net ([204.127.131.115]) by ietf-mx with esmtp (Exim 4.12) id 19hdPX-0002hT-00 for simple@ietf.org; Tue, 29 Jul 2003 18:57:39 -0400 Received: from cs.columbia.edu (76.chicago-01rh15rt.il.dial-access.att.net[12.84.96.76]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <20030729225709111008cnete>; Tue, 29 Jul 2003 22:57:09 +0000 Message-ID: <3F26FBC2.8070207@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MANSOOR Usama FTRD/DMR/LON CC: Ashir Ahmed , simple@ietf.org Subject: Re: [Simple] New I-D on presence states for phones References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 18:57:06 -0400 Content-Transfer-Encoding: 7bit Location objects are being discussed in the GEOPRIV working group. You may want to follow the discussion there. (There are efforts in GEOPRIV that effectively extend the PIDF presence format.) I suspect that timezone is really a third 'coordinate system', next to geospatial and civil, as it is not clearly aligned with either. (Timezones are usually by country, sometimes by county, but just by longitude in international waters.) MANSOOR Usama FTRD/DMR/LON wrote: > Hi Ashir, > > Thanks for pointing me towards how to obtain the timezone info. Now, with this information, I would like a kind of 'presence state' (apologies if that's the wrong terminology) that shows quickly that I'm available, but, say, 5 hours ahead. So, a presence state that is the timezone. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jul 29 18:58:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14293 for ; Tue, 29 Jul 2003 18:58:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdQ4-0003MI-Mm for simple-archive@odin.ietf.org; Tue, 29 Jul 2003 18:58:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TMwCIu012904 for simple-archive@odin.ietf.org; Tue, 29 Jul 2003 18:58:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdQ4-0003M3-Ii for simple-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 18:58:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14273; Tue, 29 Jul 2003 18:58:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hdQ0-0002hv-00; Tue, 29 Jul 2003 18:58:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hdQ0-0002hq-00; Tue, 29 Jul 2003 18:58:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdPs-0003LW-KD; Tue, 29 Jul 2003 18:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdPb-0003LF-HE for simple@optimus.ietf.org; Tue, 29 Jul 2003 18:57:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14248 for ; Tue, 29 Jul 2003 18:57:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hdPY-0002hi-00 for simple@ietf.org; Tue, 29 Jul 2003 18:57:40 -0400 Received: from mtiwmhc11.worldnet.att.net ([204.127.131.115]) by ietf-mx with esmtp (Exim 4.12) id 19hdPX-0002hT-00 for simple@ietf.org; Tue, 29 Jul 2003 18:57:39 -0400 Received: from cs.columbia.edu (76.chicago-01rh15rt.il.dial-access.att.net[12.84.96.76]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <20030729225709111008cnete>; Tue, 29 Jul 2003 22:57:09 +0000 Message-ID: <3F26FBC2.8070207@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MANSOOR Usama FTRD/DMR/LON CC: Ashir Ahmed , simple@ietf.org Subject: Re: [Simple] New I-D on presence states for phones References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 18:57:06 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Location objects are being discussed in the GEOPRIV working group. You may want to follow the discussion there. (There are efforts in GEOPRIV that effectively extend the PIDF presence format.) I suspect that timezone is really a third 'coordinate system', next to geospatial and civil, as it is not clearly aligned with either. (Timezones are usually by country, sometimes by county, but just by longitude in international waters.) MANSOOR Usama FTRD/DMR/LON wrote: > Hi Ashir, > > Thanks for pointing me towards how to obtain the timezone info. Now, with this information, I would like a kind of 'presence state' (apologies if that's the wrong terminology) that shows quickly that I'm available, but, say, 5 hours ahead. So, a presence state that is the timezone. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 30 11:59:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06069; Wed, 30 Jul 2003 11:59:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htMa-0001KD-00; Wed, 30 Jul 2003 11:59:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19htMZ-0001KA-00; Wed, 30 Jul 2003 11:59:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htLx-0005xk-EB; Wed, 30 Jul 2003 11:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htLE-0005xC-TJ for simple@optimus.ietf.org; Wed, 30 Jul 2003 11:58:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06038 for ; Wed, 30 Jul 2003 11:58:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htLD-0001JI-00 for simple@ietf.org; Wed, 30 Jul 2003 11:58:15 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19htLC-0001J8-00 for simple@ietf.org; Wed, 30 Jul 2003 11:58:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h6UFveB15316 for ; Wed, 30 Jul 2003 10:57:40 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1059580659.940.58.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] draft minutes and presentation material from IETF57 SIMPLE meeting Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 30 Jul 2003 10:57:40 -0500 Content-Transfer-Encoding: 7bit Please review the draft minutes at http://kevlar.softarmor.com/simple/meets/ietf57/notes/dwillis-simple-notes-ietf57.txt and send any corrections to me as soon as possible. If you provided slides, please review http://kevlar.softarmor.com/simple/meets/ietf57/slides/ to make sure I got the right thing. I will submit these for the proceedings Friday. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 30 12:00:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06126 for ; Wed, 30 Jul 2003 12:00:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htMb-00061g-VI for simple-archive@odin.ietf.org; Wed, 30 Jul 2003 11:59:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UFxf17023160 for simple-archive@odin.ietf.org; Wed, 30 Jul 2003 11:59:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htMb-00061T-PT for simple-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 11:59:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06069; Wed, 30 Jul 2003 11:59:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htMa-0001KD-00; Wed, 30 Jul 2003 11:59:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19htMZ-0001KA-00; Wed, 30 Jul 2003 11:59:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htLx-0005xk-EB; Wed, 30 Jul 2003 11:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htLE-0005xC-TJ for simple@optimus.ietf.org; Wed, 30 Jul 2003 11:58:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06038 for ; Wed, 30 Jul 2003 11:58:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htLD-0001JI-00 for simple@ietf.org; Wed, 30 Jul 2003 11:58:15 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19htLC-0001J8-00 for simple@ietf.org; Wed, 30 Jul 2003 11:58:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h6UFveB15316 for ; Wed, 30 Jul 2003 10:57:40 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1059580659.940.58.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] draft minutes and presentation material from IETF57 SIMPLE meeting Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 30 Jul 2003 10:57:40 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please review the draft minutes at http://kevlar.softarmor.com/simple/meets/ietf57/notes/dwillis-simple-notes-ietf57.txt and send any corrections to me as soon as possible. If you provided slides, please review http://kevlar.softarmor.com/simple/meets/ietf57/slides/ to make sure I got the right thing. I will submit these for the proceedings Friday. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 30 12:02:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06283; Wed, 30 Jul 2003 12:02:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htPl-0001N7-00; Wed, 30 Jul 2003 12:02:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19htPk-0001N4-00; Wed, 30 Jul 2003 12:02:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htOs-0006N4-4P; Wed, 30 Jul 2003 12:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htNy-00069K-0S for simple@optimus.ietf.org; Wed, 30 Jul 2003 12:01:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06179 for ; Wed, 30 Jul 2003 12:01:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htNw-0001L4-00 for simple@ietf.org; Wed, 30 Jul 2003 12:01:04 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19htNv-0001Kk-00 for simple@ietf.org; Wed, 30 Jul 2003 12:01:04 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h6UG0XB15370 for ; Wed, 30 Jul 2003 11:00:33 -0500 From: Robert Sparks To: simple@ietf.org In-Reply-To: <1059580659.940.58.camel@RjS.localdomain> References: <1059580659.940.58.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1059580832.940.61.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft minutes and presentation material from IETF57 SIMPLE meeting Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 30 Jul 2003 11:00:32 -0500 Content-Transfer-Encoding: 7bit Grr - I provided incorrect URLs in the last message. Corrected URLs appear below. RjS On Wed, 2003-07-30 at 10:57, Robert Sparks wrote: > Please review the draft minutes at > http://www.softarmor.com/simple/meets/ietf57/notes/dwillis-simple-notes-ietf57.txt > and send any corrections to me as soon as possible. > > If you provided slides, please review > http://www.softarmor.com/simple/meets/ietf57/slides/ > to make sure I got the right thing. > > I will submit these for the proceedings Friday. > > Thanks, > > RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 30 12:03:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06345 for ; Wed, 30 Jul 2003 12:03:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htPq-0006Ul-1v for simple-archive@odin.ietf.org; Wed, 30 Jul 2003 12:03:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UG32Nj024961 for simple-archive@odin.ietf.org; Wed, 30 Jul 2003 12:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htPp-0006UW-Tc for simple-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 12:03:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06283; Wed, 30 Jul 2003 12:02:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htPl-0001N7-00; Wed, 30 Jul 2003 12:02:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19htPk-0001N4-00; Wed, 30 Jul 2003 12:02:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htOs-0006N4-4P; Wed, 30 Jul 2003 12:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htNy-00069K-0S for simple@optimus.ietf.org; Wed, 30 Jul 2003 12:01:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06179 for ; Wed, 30 Jul 2003 12:01:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htNw-0001L4-00 for simple@ietf.org; Wed, 30 Jul 2003 12:01:04 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19htNv-0001Kk-00 for simple@ietf.org; Wed, 30 Jul 2003 12:01:04 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h6UG0XB15370 for ; Wed, 30 Jul 2003 11:00:33 -0500 From: Robert Sparks To: simple@ietf.org In-Reply-To: <1059580659.940.58.camel@RjS.localdomain> References: <1059580659.940.58.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1059580832.940.61.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft minutes and presentation material from IETF57 SIMPLE meeting Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 30 Jul 2003 11:00:32 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Grr - I provided incorrect URLs in the last message. Corrected URLs appear below. RjS On Wed, 2003-07-30 at 10:57, Robert Sparks wrote: > Please review the draft minutes at > http://www.softarmor.com/simple/meets/ietf57/notes/dwillis-simple-notes-ietf57.txt > and send any corrections to me as soon as possible. > > If you provided slides, please review > http://www.softarmor.com/simple/meets/ietf57/slides/ > to make sure I got the right thing. > > I will submit these for the proceedings Friday. > > Thanks, > > RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 30 17:41:32 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19263; Wed, 30 Jul 2003 17:41:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hyhU-0003wg-00; Wed, 30 Jul 2003 17:41:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hyhT-0003wd-00; Wed, 30 Jul 2003 17:41:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hygv-0006Nc-As; Wed, 30 Jul 2003 17:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hygB-0006Lw-Kd for simple@optimus.ietf.org; Wed, 30 Jul 2003 17:40:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19227 for ; Wed, 30 Jul 2003 17:40:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hyg9-0003wL-00 for simple@ietf.org; Wed, 30 Jul 2003 17:40:13 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19hyg8-0003vv-00 for simple@ietf.org; Wed, 30 Jul 2003 17:40:12 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6ULde6Y004398; Wed, 30 Jul 2003 17:39:40 -0400 (EDT) Message-ID: <3F283B1A.2040303@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vikas Tandon CC: simple@ietf.org Subject: Re: [Simple] New I-D on presence states for phones References: <000001c34daa$61318440$6277fea9@vikas> In-Reply-To: <000001c34daa$61318440$6277fea9@vikas> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 17:39:38 -0400 Content-Transfer-Encoding: 7bit Generally, I agree that the scope of the draft was too broad, covering a bunch of things which probably are outside the scope of presence. But, thats the nature of a -00 draft, and the way to get discussion going. The reason I had put signal strength in there in the first place was that, ultimately, a watcher would know that their call/IM/whatever won't succeed if the target has poor signal strength. However, I agree with Markus that it really does change too much (and also probably nearly impossible to obtain in any accurate or timely way). So, I will remove it from the next rev of the document. The best way to determine what is, and what is out, of scope is for people to give examples of the kinds of applications that might need each piece of presence data. If you can't think of a presence app that needs a piece of data, there is a good chance it should just be removed from the spec. So, here are some thoughts on the motivating apps and some of their presence needs: call state: very useful for rendering to watchers, says alot about whether now is a good time to make a call to them. Also useful input to other pieces of presence which can be derived from it, such as OPEN/CLOSED for voice. I agree that the full call state model is perhaps not needed. In particular I cant think of a reason why a watcher cares to know ringing vs. in a call. Both are probably the same in terms of presence. registration state: this seems pretty fundamental - no communication is possible unless this is true. I think its also really useful to render to people, to let them know if the phone is on or off. A change in registration state is frequently the trigger for push apps, such as a ringback application. data-state: useful for knowing if a SIP IM will succeed or not - clearly not if the data-state is not connected. I dont think its useful to render to a user, but applications which want to push information to a user probably care. roaming: I think this is really useful to render to watchers. Its sort of really high level geoloc information. Frequently, you want to know whether someone is on a trip or not, to decide whether to call them, and roaming helps the watcher know that. visited/home strings: not really sure what these might be used for. Seems neat, but perhaps its too much. Anyone have any ideas? barred: I'm not sure this is usefully different than not registered, but I need to think about it. -Jonathan R. Vikas Tandon wrote: > Hi Markus, Alex and SIMPLE experts, > > As rightly pointed out, signal strength can change several times within > a second based on the attenuation factors and even what is displayed on > the phone is a best-possible view. Having lower signal strength however > might not be a very useful information to the watcher. Additionally and > noticeably, we are talking about adding more processing on the client > side. > > If we were to add some of the phone status attributes, we should look at > ones which display what the user wants to be communicated like - I can > set: My phone is switched off without letting others know that actually > I'm on!! > > These category of information might be a useful information on the > network side for delivery purpose but not for the watcher, and moreover > information of this category as best picked up from the network nodes > themselves rather than making the client thicker. > > Regards, > Vikas > > > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of > Alex Audu > Sent: Friday, July 18, 2003 7:49 AM > To: Markus.Isomaki@nokia.com > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] New I-D on presence states for phones > > > Hello, > >>From a user's point of view, I am not sure if "signal strength" is not a > valuable information to have. Granted, it may be changing very > frequently, but you can always limit how often it is updated. > > I am not sure however, if "signal strength" can be a valid attribute of > the state of the phone. It is descriptive, more of the environment the > phone is in, than the phone itself. > > Regards, > Alex. > > Markus.Isomaki@nokia.com wrote: > > >>Hi, >> >>I think this draft defines bunch of useful information. However, I >>would definitely take away the "signal-strength" attribute under the >>wireless phone state. As already stated in the draft, this information > > >>is changing frequently, so I think it is not sensible in the timescale > > >>that SIP events work. And even if it would be possible to convey this >>information, what would it mean in GPRS, WCDMA or WiFi? Is there any >>use case what any watcher could in _practice_ benefit from this >>information? >> >>What might be useful as an addition to "ran" is some more information >>on the access-link, i.e. that the "downlink capacity class" is ~40 >>kbps, and "RTT class" is ~500 ms. This _kind_ of information might >>give watchers some idea what _kind_ of applications/media the device >>could be able to do at the moment (although you could find that out >>also through PIDF/prescaps and SDP negotiations). This kind of info is > > >>relatively static (in the order of minutes rather than seconds), but >>still changing. In any case, this would be more valuable than >>"signal-strength". >> >>Markus >> >> >>>-----Original Message----- >>>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>>Sent: 08 July, 2003 09:42 >>>To: Simple WG >>>Subject: [Simple] New I-D on presence states for phones >>> >>> >>>Folks, >>> >>>In case folks havent seen it, I wanted to call your attention to: >>> >>>http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s >> >>imple-pidf-phone-00.txt >>http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt >>http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html >> >>This draft, written by Jon and myself, defines some PIDF extensions >>for describing phones, including traditional "black" phones, wireless >>phones and enterprise phones. I think these will provide invaluable >>for a device-centric view of a presentity. >> >>Comments and questions welcome. >> >>Thanks, >>Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >>_______________________________________________ >>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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 30 17:42:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19288 for ; Wed, 30 Jul 2003 17:42:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyhX-0006RG-Ey for simple-archive@odin.ietf.org; Wed, 30 Jul 2003 17:41:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ULfdiH024746 for simple-archive@odin.ietf.org; Wed, 30 Jul 2003 17:41:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyhX-0006R3-Be for simple-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 17:41:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19263; Wed, 30 Jul 2003 17:41:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hyhU-0003wg-00; Wed, 30 Jul 2003 17:41:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hyhT-0003wd-00; Wed, 30 Jul 2003 17:41:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hygv-0006Nc-As; Wed, 30 Jul 2003 17:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hygB-0006Lw-Kd for simple@optimus.ietf.org; Wed, 30 Jul 2003 17:40:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19227 for ; Wed, 30 Jul 2003 17:40:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hyg9-0003wL-00 for simple@ietf.org; Wed, 30 Jul 2003 17:40:13 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19hyg8-0003vv-00 for simple@ietf.org; Wed, 30 Jul 2003 17:40:12 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6ULde6Y004398; Wed, 30 Jul 2003 17:39:40 -0400 (EDT) Message-ID: <3F283B1A.2040303@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vikas Tandon CC: simple@ietf.org Subject: Re: [Simple] New I-D on presence states for phones References: <000001c34daa$61318440$6277fea9@vikas> In-Reply-To: <000001c34daa$61318440$6277fea9@vikas> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 17:39:38 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Generally, I agree that the scope of the draft was too broad, covering a bunch of things which probably are outside the scope of presence. But, thats the nature of a -00 draft, and the way to get discussion going. The reason I had put signal strength in there in the first place was that, ultimately, a watcher would know that their call/IM/whatever won't succeed if the target has poor signal strength. However, I agree with Markus that it really does change too much (and also probably nearly impossible to obtain in any accurate or timely way). So, I will remove it from the next rev of the document. The best way to determine what is, and what is out, of scope is for people to give examples of the kinds of applications that might need each piece of presence data. If you can't think of a presence app that needs a piece of data, there is a good chance it should just be removed from the spec. So, here are some thoughts on the motivating apps and some of their presence needs: call state: very useful for rendering to watchers, says alot about whether now is a good time to make a call to them. Also useful input to other pieces of presence which can be derived from it, such as OPEN/CLOSED for voice. I agree that the full call state model is perhaps not needed. In particular I cant think of a reason why a watcher cares to know ringing vs. in a call. Both are probably the same in terms of presence. registration state: this seems pretty fundamental - no communication is possible unless this is true. I think its also really useful to render to people, to let them know if the phone is on or off. A change in registration state is frequently the trigger for push apps, such as a ringback application. data-state: useful for knowing if a SIP IM will succeed or not - clearly not if the data-state is not connected. I dont think its useful to render to a user, but applications which want to push information to a user probably care. roaming: I think this is really useful to render to watchers. Its sort of really high level geoloc information. Frequently, you want to know whether someone is on a trip or not, to decide whether to call them, and roaming helps the watcher know that. visited/home strings: not really sure what these might be used for. Seems neat, but perhaps its too much. Anyone have any ideas? barred: I'm not sure this is usefully different than not registered, but I need to think about it. -Jonathan R. Vikas Tandon wrote: > Hi Markus, Alex and SIMPLE experts, > > As rightly pointed out, signal strength can change several times within > a second based on the attenuation factors and even what is displayed on > the phone is a best-possible view. Having lower signal strength however > might not be a very useful information to the watcher. Additionally and > noticeably, we are talking about adding more processing on the client > side. > > If we were to add some of the phone status attributes, we should look at > ones which display what the user wants to be communicated like - I can > set: My phone is switched off without letting others know that actually > I'm on!! > > These category of information might be a useful information on the > network side for delivery purpose but not for the watcher, and moreover > information of this category as best picked up from the network nodes > themselves rather than making the client thicker. > > Regards, > Vikas > > > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of > Alex Audu > Sent: Friday, July 18, 2003 7:49 AM > To: Markus.Isomaki@nokia.com > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] New I-D on presence states for phones > > > Hello, > >>From a user's point of view, I am not sure if "signal strength" is not a > valuable information to have. Granted, it may be changing very > frequently, but you can always limit how often it is updated. > > I am not sure however, if "signal strength" can be a valid attribute of > the state of the phone. It is descriptive, more of the environment the > phone is in, than the phone itself. > > Regards, > Alex. > > Markus.Isomaki@nokia.com wrote: > > >>Hi, >> >>I think this draft defines bunch of useful information. However, I >>would definitely take away the "signal-strength" attribute under the >>wireless phone state. As already stated in the draft, this information > > >>is changing frequently, so I think it is not sensible in the timescale > > >>that SIP events work. And even if it would be possible to convey this >>information, what would it mean in GPRS, WCDMA or WiFi? Is there any >>use case what any watcher could in _practice_ benefit from this >>information? >> >>What might be useful as an addition to "ran" is some more information >>on the access-link, i.e. that the "downlink capacity class" is ~40 >>kbps, and "RTT class" is ~500 ms. This _kind_ of information might >>give watchers some idea what _kind_ of applications/media the device >>could be able to do at the moment (although you could find that out >>also through PIDF/prescaps and SDP negotiations). This kind of info is > > >>relatively static (in the order of minutes rather than seconds), but >>still changing. In any case, this would be more valuable than >>"signal-strength". >> >>Markus >> >> >>>-----Original Message----- >>>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>>Sent: 08 July, 2003 09:42 >>>To: Simple WG >>>Subject: [Simple] New I-D on presence states for phones >>> >>> >>>Folks, >>> >>>In case folks havent seen it, I wanted to call your attention to: >>> >>>http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s >> >>imple-pidf-phone-00.txt >>http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt >>http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html >> >>This draft, written by Jon and myself, defines some PIDF extensions >>for describing phones, including traditional "black" phones, wireless >>phones and enterprise phones. I think these will provide invaluable >>for a device-centric view of a presentity. >> >>Comments and questions welcome. >> >>Thanks, >>Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >>_______________________________________________ >>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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 30 18:04:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20230; Wed, 30 Jul 2003 18:04:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hz3G-0004FT-00; Wed, 30 Jul 2003 18:04:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hz3G-0004FQ-00; Wed, 30 Jul 2003 18:04:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz3B-0007Mj-Vh; Wed, 30 Jul 2003 18:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz2J-0007L3-D7 for simple@optimus.ietf.org; Wed, 30 Jul 2003 18:03:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20096 for ; Wed, 30 Jul 2003 18:03:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hz19-0004Dp-00 for simple@ietf.org; Wed, 30 Jul 2003 18:01:55 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hz18-0004DY-00 for simple@ietf.org; Wed, 30 Jul 2003 18:01:54 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6UM1M7F006936; Wed, 30 Jul 2003 15:01:23 -0700 (PDT) Received: from mhammer-w2k03.cisco.com (dhcp-64-100-224-114.cisco.com [64.100.224.114]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIY18155; Wed, 30 Jul 2003 15:01:21 -0700 (PDT) Message-Id: <4.3.2.7.2.20030730175554.00b2d918@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jonathan Rosenberg From: Michael Hammer Subject: Re: [Simple] New I-D on presence states for phones Cc: Vikas Tandon , simple@ietf.org In-Reply-To: <3F283B1A.2040303@dynamicsoft.com> References: <000001c34daa$61318440$6277fea9@vikas> <000001c34daa$61318440$6277fea9@vikas> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_33900005==_.ALT" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 18:01:22 -0400 --=====================_33900005==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 05:39 PM 7/30/2003 -0400, Jonathan Rosenberg wrote: >roaming: I think this is really useful to render to watchers. Its sort of >really high level geoloc information. Frequently, you want to know whether >someone is on a trip or not, to decide whether to call them, and roaming >helps the watcher know that. Thinking of this in the WiFi space rather than traditional cellular, the target may be moving from one hot-spot to another. Short trip v. long-distance trip. Also given that roaming may occur if the network has spotty coverage, this may be more of an issue of whether the user will have full service in the visited v. home area, e.g. do they pay by the byte v. use pre-paid bulk BW/minutes. May affect the media that one chooses. Mike --=====================_33900005==_.ALT Content-Type: text/html; charset="us-ascii" At 05:39 PM 7/30/2003 -0400, Jonathan Rosenberg wrote:
roaming: I think this is really useful to render to watchers. Its sort of really high level geoloc information. Frequently, you want to know whether someone is on a trip or not, to decide whether to call them, and roaming helps the watcher know that.

Thinking of this in the WiFi space rather than traditional cellular, the target may be moving from one hot-spot to another.  Short trip v. long-distance trip.

Also given that roaming may occur if the network has spotty coverage, this may be more of an issue of whether the user will have full service in the visited v. home area, e.g. do they pay by the byte v. use pre-paid bulk BW/minutes.  May affect the media that one chooses.

Mike
  --=====================_33900005==_.ALT-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 30 18:04:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20321 for ; Wed, 30 Jul 2003 18:04:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz3K-0007UC-BY for simple-archive@odin.ietf.org; Wed, 30 Jul 2003 18:04:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UM4AEn028776 for simple-archive@odin.ietf.org; Wed, 30 Jul 2003 18:04:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz3K-0007U3-8R for simple-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 18:04:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20230; Wed, 30 Jul 2003 18:04:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hz3G-0004FT-00; Wed, 30 Jul 2003 18:04:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hz3G-0004FQ-00; Wed, 30 Jul 2003 18:04:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz3B-0007Mj-Vh; Wed, 30 Jul 2003 18:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz2J-0007L3-D7 for simple@optimus.ietf.org; Wed, 30 Jul 2003 18:03:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20096 for ; Wed, 30 Jul 2003 18:03:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hz19-0004Dp-00 for simple@ietf.org; Wed, 30 Jul 2003 18:01:55 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hz18-0004DY-00 for simple@ietf.org; Wed, 30 Jul 2003 18:01:54 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6UM1M7F006936; Wed, 30 Jul 2003 15:01:23 -0700 (PDT) Received: from mhammer-w2k03.cisco.com (dhcp-64-100-224-114.cisco.com [64.100.224.114]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIY18155; Wed, 30 Jul 2003 15:01:21 -0700 (PDT) Message-Id: <4.3.2.7.2.20030730175554.00b2d918@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jonathan Rosenberg From: Michael Hammer Subject: Re: [Simple] New I-D on presence states for phones Cc: Vikas Tandon , simple@ietf.org In-Reply-To: <3F283B1A.2040303@dynamicsoft.com> References: <000001c34daa$61318440$6277fea9@vikas> <000001c34daa$61318440$6277fea9@vikas> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_33900005==_.ALT" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 18:01:22 -0400 --=====================_33900005==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 05:39 PM 7/30/2003 -0400, Jonathan Rosenberg wrote: >roaming: I think this is really useful to render to watchers. Its sort of >really high level geoloc information. Frequently, you want to know whether >someone is on a trip or not, to decide whether to call them, and roaming >helps the watcher know that. Thinking of this in the WiFi space rather than traditional cellular, the target may be moving from one hot-spot to another. Short trip v. long-distance trip. Also given that roaming may occur if the network has spotty coverage, this may be more of an issue of whether the user will have full service in the visited v. home area, e.g. do they pay by the byte v. use pre-paid bulk BW/minutes. May affect the media that one chooses. Mike --=====================_33900005==_.ALT Content-Type: text/html; charset="us-ascii" At 05:39 PM 7/30/2003 -0400, Jonathan Rosenberg wrote:
roaming: I think this is really useful to render to watchers. Its sort of really high level geoloc information. Frequently, you want to know whether someone is on a trip or not, to decide whether to call them, and roaming helps the watcher know that.

Thinking of this in the WiFi space rather than traditional cellular, the target may be moving from one hot-spot to another.  Short trip v. long-distance trip.

Also given that roaming may occur if the network has spotty coverage, this may be more of an issue of whether the user will have full service in the visited v. home area, e.g. do they pay by the byte v. use pre-paid bulk BW/minutes.  May affect the media that one chooses.

Mike
  --=====================_33900005==_.ALT-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 30 18:05:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20420; Wed, 30 Jul 2003 18:05:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hz4C-0004H5-00; Wed, 30 Jul 2003 18:05:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hz4B-0004H1-00; Wed, 30 Jul 2003 18:05:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz49-0007dV-3q; Wed, 30 Jul 2003 18:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz3R-0007VL-9y for simple@optimus.ietf.org; Wed, 30 Jul 2003 18:04:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20263 for ; Wed, 30 Jul 2003 18:04:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hz3O-0004Fp-00 for simple@ietf.org; Wed, 30 Jul 2003 18:04:14 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19hz3N-0004Ey-00 for simple@ietf.org; Wed, 30 Jul 2003 18:04:13 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6UM3Z6Y004415; Wed, 30 Jul 2003 18:03:35 -0400 (EDT) Message-ID: <3F2840B4.5030202@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: jon.peterson@neustar.biz, simple@ietf.org References: <200306261203.IAA16528@ietf.org> <3F16C405.3020900@cisco.com> In-Reply-To: <3F16C405.3020900@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 18:03:32 -0400 Content-Transfer-Encoding: 7bit Thanks for the comments. Responses inline. Paul Kyzivat wrote: > I think representing states appropriate to a phone is a good idea. But I > have serious problems with the details of this draft: > > - multiple ways of representing equivalent state > > Typically a watcher is likely to care less what kind of phone you have, > and simply want to know if you are available for a call and/or are in a > call. Having to decipher three different representations of this same > information is a needless hassle. I think a watcher may want to know what type of phone you have - knowing that its home vs. wireless vs. business is useful presence information in itself, I believe. > > Also, to the caller there is no functional difference between a POTS > phone with call waiting available, and a business phone with two "lines" > associated to the same number with one in use and one free. In both > cases the callee is in a call but still available for a call. > Representing these situations differently just makes things difficult > for the watcher. I think I agree with that. I should point out that our split of the doc and schema along the device type lines was primarily to facilitate a division of labor, not because of a fundamental belief that these needed to be totally separated. That said, there definitely are differences in states and infrmation between devices. I'm all for making as much common as is possible though. Perhaps a better way to deal with this is to indicate that there exists another call in progress, or perhaps an indication of how many calls are in progress (useful for call routing to customer support operators perhaps?). > > - problematic extensibility model > > This pattern also sets the stage for more complexity in the future as > new devices with different combinations of features hit the market. > Suppose I come out with both home (single line) and business (multi > line) voice/im phones. The home phone can do one voice call or one im > call. The business phone can do two voice calls and two im calls. > > It isn't at all clear that I can extend any of the proposed models to > accomodate my new phone in a graceful way. I may end up defining two new > types for my new phones, different from these three types. Then I have > problems with backward compatibility. I'm not sure I see the specific problem here - is it because your phones can do IM also, and none of the phone types in the doc discuss IM? If this is the case, I would argue that it comes back to a service/device view. The current draft doesnt separate the two. Many aspects of the draft refer to a service view, where the service is telephony. Others refer to the device view - things such as access network and signal strength (which I agree should be booted) are device properties that span services. For example, IM and PTT may also run on the phone, and things like signal strength would affect all of them. So, if I have a device as you describe, I could present it with a service view that lists telephony as one service, IM as another. The device-specific attributes would perhaps get replicated in each service, or else composed in some way into the overall availability (OPEN/CLOSED). What do you think about splitting the attributes along those lines? > > - inclusion of useless data > > Identifiers for lines seems useless. They are all associated with the > same phone number, and are not addressable for any purpose. Showing > lines that are not in use is also pretty useless except for providing a > way to know that a new call can be accepted. I'll agree with that. > Data-state could be useful > but I think I need to know a lot more info to predict what that might > permit me to do. As per my other note, its useful for applications that want to push data to the phone. > > ALTERNATIVE: > > I think the following kind of structure would accomplish the same thing > you have proposed yet address my issues: > > - a representation for a call. This would subsume your call-state, but > omitting the not-in-call state. But it would also be extensible for > other call attributes. This can be repeated as many times as needed to > represent calls in progress, not lines. (This clearly overlaps with the > dialog package - something worth discussing. It provides extra > information in that it can show a call before a dialog is established. > And with further extension it might provide a way to represent calls on > hold, if we can figure out what that means.) This is different from dialog package in that there isnt a sip dialog. Nothing in the simple-pidf draft is specific to sip phones. In my mind, the model is that a presence server might itsefl subscribe to the dialog package for a phone, and based on that information, generate presence documents using the pidf information. For other phone types, such as a wireline phone, it might use the spirits interface or some proprietary i/f to a switch. > > - an indication of whether available for another call. In your model > this seems to be represented by some call-state=not-in-call, or by > call-waiting=available. But it also seems to be indicated by > open. I'm uncomfortable using basic status for this, > because the device may still be open for other kinds of signaling, such > as subscriptions. > > In this new model availablily for calls could also be indicated by a > call-state of available, but I see no need to model lines not in use. > This is rooted in old world notions that there are some fixed number of > lines. Conceivably some new attribute could be introduced for this, but > I think the attributes in RPIDS already have this covered. (This still > cries out for capabilities, to describe *what* I am available for, but > that can be dealt with separately.) I think your proposal is reasonable - the phone "service" is modeled by zero or more call elements that represent some amount of call state, and information on ability to take another call. I see this as different from basic status, in that basic status would depend on other things too. For example, if I'm in a meeting, even if I can take another call, the basic status for my telephony service would be closed. > > - an optional element representing the home network provider. This is > appropriate for all kinds of phones. (I'm not sure why I would want to > publish this, but I can go along.) I can go either way on this too. Now, is this a device or service property? I can have an IM service on my phone from a different provider than the one that provides me data access. Arguably, the data access provider is a device property. > > - optional ran, roaming, visited-network, signal-strength attributes. > (Assuming you think these make sense to provide at all.) These could be > grouped under a mobile attribute or left standalone. I dont think they can be in a single mobile attribute, there is a bunch of separate information here. > > - I consider data-state to be a capability. (If you think it is useful > at all - it isn't clear to me what this implies I can do.) I would deal > with it together with other capabilities, like voice, video, IM. I think its a device capability that says something about availability across a number of services. > > Using the above, representations for POTS phones, business phones, and > wireless phones are simply usage profiles. The watcher won't explicitly > know what kind of phone it is except by inference from the kinds of > presence he sees it use. To me this is a good thing. Well, I would still argue that an attribute that describes the type of device is useful. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 30 18:05:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20509 for ; Wed, 30 Jul 2003 18:05:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz4F-0007h5-Ty for simple-archive@odin.ietf.org; Wed, 30 Jul 2003 18:05:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UM57ua029571 for simple-archive@odin.ietf.org; Wed, 30 Jul 2003 18:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz4F-0007gs-Pd for simple-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 18:05:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20420; Wed, 30 Jul 2003 18:05:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hz4C-0004H5-00; Wed, 30 Jul 2003 18:05:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hz4B-0004H1-00; Wed, 30 Jul 2003 18:05:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz49-0007dV-3q; Wed, 30 Jul 2003 18:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz3R-0007VL-9y for simple@optimus.ietf.org; Wed, 30 Jul 2003 18:04:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20263 for ; Wed, 30 Jul 2003 18:04:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hz3O-0004Fp-00 for simple@ietf.org; Wed, 30 Jul 2003 18:04:14 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19hz3N-0004Ey-00 for simple@ietf.org; Wed, 30 Jul 2003 18:04:13 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6UM3Z6Y004415; Wed, 30 Jul 2003 18:03:35 -0400 (EDT) Message-ID: <3F2840B4.5030202@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: jon.peterson@neustar.biz, simple@ietf.org References: <200306261203.IAA16528@ietf.org> <3F16C405.3020900@cisco.com> In-Reply-To: <3F16C405.3020900@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 18:03:32 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for the comments. Responses inline. Paul Kyzivat wrote: > I think representing states appropriate to a phone is a good idea. But I > have serious problems with the details of this draft: > > - multiple ways of representing equivalent state > > Typically a watcher is likely to care less what kind of phone you have, > and simply want to know if you are available for a call and/or are in a > call. Having to decipher three different representations of this same > information is a needless hassle. I think a watcher may want to know what type of phone you have - knowing that its home vs. wireless vs. business is useful presence information in itself, I believe. > > Also, to the caller there is no functional difference between a POTS > phone with call waiting available, and a business phone with two "lines" > associated to the same number with one in use and one free. In both > cases the callee is in a call but still available for a call. > Representing these situations differently just makes things difficult > for the watcher. I think I agree with that. I should point out that our split of the doc and schema along the device type lines was primarily to facilitate a division of labor, not because of a fundamental belief that these needed to be totally separated. That said, there definitely are differences in states and infrmation between devices. I'm all for making as much common as is possible though. Perhaps a better way to deal with this is to indicate that there exists another call in progress, or perhaps an indication of how many calls are in progress (useful for call routing to customer support operators perhaps?). > > - problematic extensibility model > > This pattern also sets the stage for more complexity in the future as > new devices with different combinations of features hit the market. > Suppose I come out with both home (single line) and business (multi > line) voice/im phones. The home phone can do one voice call or one im > call. The business phone can do two voice calls and two im calls. > > It isn't at all clear that I can extend any of the proposed models to > accomodate my new phone in a graceful way. I may end up defining two new > types for my new phones, different from these three types. Then I have > problems with backward compatibility. I'm not sure I see the specific problem here - is it because your phones can do IM also, and none of the phone types in the doc discuss IM? If this is the case, I would argue that it comes back to a service/device view. The current draft doesnt separate the two. Many aspects of the draft refer to a service view, where the service is telephony. Others refer to the device view - things such as access network and signal strength (which I agree should be booted) are device properties that span services. For example, IM and PTT may also run on the phone, and things like signal strength would affect all of them. So, if I have a device as you describe, I could present it with a service view that lists telephony as one service, IM as another. The device-specific attributes would perhaps get replicated in each service, or else composed in some way into the overall availability (OPEN/CLOSED). What do you think about splitting the attributes along those lines? > > - inclusion of useless data > > Identifiers for lines seems useless. They are all associated with the > same phone number, and are not addressable for any purpose. Showing > lines that are not in use is also pretty useless except for providing a > way to know that a new call can be accepted. I'll agree with that. > Data-state could be useful > but I think I need to know a lot more info to predict what that might > permit me to do. As per my other note, its useful for applications that want to push data to the phone. > > ALTERNATIVE: > > I think the following kind of structure would accomplish the same thing > you have proposed yet address my issues: > > - a representation for a call. This would subsume your call-state, but > omitting the not-in-call state. But it would also be extensible for > other call attributes. This can be repeated as many times as needed to > represent calls in progress, not lines. (This clearly overlaps with the > dialog package - something worth discussing. It provides extra > information in that it can show a call before a dialog is established. > And with further extension it might provide a way to represent calls on > hold, if we can figure out what that means.) This is different from dialog package in that there isnt a sip dialog. Nothing in the simple-pidf draft is specific to sip phones. In my mind, the model is that a presence server might itsefl subscribe to the dialog package for a phone, and based on that information, generate presence documents using the pidf information. For other phone types, such as a wireline phone, it might use the spirits interface or some proprietary i/f to a switch. > > - an indication of whether available for another call. In your model > this seems to be represented by some call-state=not-in-call, or by > call-waiting=available. But it also seems to be indicated by > open. I'm uncomfortable using basic status for this, > because the device may still be open for other kinds of signaling, such > as subscriptions. > > In this new model availablily for calls could also be indicated by a > call-state of available, but I see no need to model lines not in use. > This is rooted in old world notions that there are some fixed number of > lines. Conceivably some new attribute could be introduced for this, but > I think the attributes in RPIDS already have this covered. (This still > cries out for capabilities, to describe *what* I am available for, but > that can be dealt with separately.) I think your proposal is reasonable - the phone "service" is modeled by zero or more call elements that represent some amount of call state, and information on ability to take another call. I see this as different from basic status, in that basic status would depend on other things too. For example, if I'm in a meeting, even if I can take another call, the basic status for my telephony service would be closed. > > - an optional element representing the home network provider. This is > appropriate for all kinds of phones. (I'm not sure why I would want to > publish this, but I can go along.) I can go either way on this too. Now, is this a device or service property? I can have an IM service on my phone from a different provider than the one that provides me data access. Arguably, the data access provider is a device property. > > - optional ran, roaming, visited-network, signal-strength attributes. > (Assuming you think these make sense to provide at all.) These could be > grouped under a mobile attribute or left standalone. I dont think they can be in a single mobile attribute, there is a bunch of separate information here. > > - I consider data-state to be a capability. (If you think it is useful > at all - it isn't clear to me what this implies I can do.) I would deal > with it together with other capabilities, like voice, video, IM. I think its a device capability that says something about availability across a number of services. > > Using the above, representations for POTS phones, business phones, and > wireless phones are simply usage profiles. The watcher won't explicitly > know what kind of phone it is except by inference from the kinds of > presence he sees it use. To me this is a good thing. Well, I would still argue that an attribute that describes the type of device is useful. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jul 30 21:48:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26467; Wed, 30 Jul 2003 21:48:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i2Y2-0006Il-00; Wed, 30 Jul 2003 21:48:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19i2Y2-0006Ig-00; Wed, 30 Jul 2003 21:48:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i2Xw-0006bR-OF; Wed, 30 Jul 2003 21:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i2X8-0006b5-Hj for simple@optimus.ietf.org; Wed, 30 Jul 2003 21:47:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26460 for ; Wed, 30 Jul 2003 21:47:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i2X5-0006Id-00 for simple@ietf.org; Wed, 30 Jul 2003 21:47:07 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19i2X4-0006Ia-00 for simple@ietf.org; Wed, 30 Jul 2003 21:47:06 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6V1l1l7006044; Wed, 30 Jul 2003 21:47:01 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6V1ku512450; Wed, 30 Jul 2003 21:46:58 -0400 Message-ID: <3F287503.1050505@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt References: <200306261203.IAA16528@ietf.org> <3F16C405.3020900@cisco.com> <3F2840B4.5030202@dynamicsoft.com> In-Reply-To: <3F2840B4.5030202@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 21:46:43 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I think a watcher may want to know what type of phone you have - knowing > that its home vs. wireless vs. business is useful presence information > in itself, I believe. Isn't that partially covered by the device-capabilities extension that was split off again from RPIDS? > > Perhaps a better way to deal with this is to indicate that there exists > another call in progress, or perhaps an indication of how many calls are > in progress (useful for call routing to customer support operators > perhaps?). Only if the presentity is a group, not an individual, I'd think. >> - a representation for a call. This would subsume your call-state, but >> omitting the not-in-call state. But it would also be extensible for >> other call attributes. This can be repeated as many times as needed to >> represent calls in progress, not lines. (This clearly overlaps with >> the dialog package - something worth discussing. It provides extra >> information in that it can show a call before a dialog is established. >> And with further extension it might provide a way to represent calls >> on hold, if we can figure out what that means.) One of the questions is whether this or dialog state is the right model for directed call pickup. If I can subscribe to another user's phone and get the Call-ID and other identifying information, I can then pick up the call via REFER. I suspect that dialog-package is the better one, but one of them should be made to work for that... >> - optional ran, roaming, visited-network, signal-strength attributes. >> (Assuming you think these make sense to provide at all.) These could >> be grouped under a mobile attribute or left standalone. > > > I dont think they can be in a single mobile attribute, there is a bunch > of separate information here. I am dubious on 'roaming'. This can mean many different things and nothing at all. Without having detailed knowledge of the presentity's carrier subscription and its coverage, it says essentially nothing. (In NJ, the pin-drop carrier can make you roam into analog just a few miles west on Rt. 4, as that's the border of digital coverage, so this says nothing about distance from home.) Also, are there currently any interfaces that would allow you to retrieve this information? >> Using the above, representations for POTS phones, business phones, and >> wireless phones are simply usage profiles. The watcher won't >> explicitly know what kind of phone it is except by inference from the >> kinds of presence he sees it use. To me this is a good thing. > > > Well, I would still argue that an attribute that describes the type of > device is useful. What's the difference between a 'business' phone on an analog PBX and a POTS phone? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jul 30 21:48:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26488 for ; Wed, 30 Jul 2003 21:48:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i2Y5-0006dK-WB for simple-archive@odin.ietf.org; Wed, 30 Jul 2003 21:48:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V1m9Im025455 for simple-archive@odin.ietf.org; Wed, 30 Jul 2003 21:48:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i2Y5-0006by-S1 for simple-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 21:48:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26467; Wed, 30 Jul 2003 21:48:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i2Y2-0006Il-00; Wed, 30 Jul 2003 21:48:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19i2Y2-0006Ig-00; Wed, 30 Jul 2003 21:48:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i2Xw-0006bR-OF; Wed, 30 Jul 2003 21:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i2X8-0006b5-Hj for simple@optimus.ietf.org; Wed, 30 Jul 2003 21:47:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26460 for ; Wed, 30 Jul 2003 21:47:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i2X5-0006Id-00 for simple@ietf.org; Wed, 30 Jul 2003 21:47:07 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19i2X4-0006Ia-00 for simple@ietf.org; Wed, 30 Jul 2003 21:47:06 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6V1l1l7006044; Wed, 30 Jul 2003 21:47:01 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6V1ku512450; Wed, 30 Jul 2003 21:46:58 -0400 Message-ID: <3F287503.1050505@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt References: <200306261203.IAA16528@ietf.org> <3F16C405.3020900@cisco.com> <3F2840B4.5030202@dynamicsoft.com> In-Reply-To: <3F2840B4.5030202@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 21:46:43 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I think a watcher may want to know what type of phone you have - knowing > that its home vs. wireless vs. business is useful presence information > in itself, I believe. Isn't that partially covered by the device-capabilities extension that was split off again from RPIDS? > > Perhaps a better way to deal with this is to indicate that there exists > another call in progress, or perhaps an indication of how many calls are > in progress (useful for call routing to customer support operators > perhaps?). Only if the presentity is a group, not an individual, I'd think. >> - a representation for a call. This would subsume your call-state, but >> omitting the not-in-call state. But it would also be extensible for >> other call attributes. This can be repeated as many times as needed to >> represent calls in progress, not lines. (This clearly overlaps with >> the dialog package - something worth discussing. It provides extra >> information in that it can show a call before a dialog is established. >> And with further extension it might provide a way to represent calls >> on hold, if we can figure out what that means.) One of the questions is whether this or dialog state is the right model for directed call pickup. If I can subscribe to another user's phone and get the Call-ID and other identifying information, I can then pick up the call via REFER. I suspect that dialog-package is the better one, but one of them should be made to work for that... >> - optional ran, roaming, visited-network, signal-strength attributes. >> (Assuming you think these make sense to provide at all.) These could >> be grouped under a mobile attribute or left standalone. > > > I dont think they can be in a single mobile attribute, there is a bunch > of separate information here. I am dubious on 'roaming'. This can mean many different things and nothing at all. Without having detailed knowledge of the presentity's carrier subscription and its coverage, it says essentially nothing. (In NJ, the pin-drop carrier can make you roam into analog just a few miles west on Rt. 4, as that's the border of digital coverage, so this says nothing about distance from home.) Also, are there currently any interfaces that would allow you to retrieve this information? >> Using the above, representations for POTS phones, business phones, and >> wireless phones are simply usage profiles. The watcher won't >> explicitly know what kind of phone it is except by inference from the >> kinds of presence he sees it use. To me this is a good thing. > > > Well, I would still argue that an attribute that describes the type of > device is useful. What's the difference between a 'business' phone on an analog PBX and a POTS phone? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 31 09:45:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25475; Thu, 31 Jul 2003 09:45:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iDk1-0003tD-00; Thu, 31 Jul 2003 09:45:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iDk1-0003tA-00; Thu, 31 Jul 2003 09:45:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDjp-0000dQ-57; Thu, 31 Jul 2003 09:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDjl-0000d3-Oo for simple@optimus.ietf.org; Thu, 31 Jul 2003 09:44:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25463 for ; Thu, 31 Jul 2003 09:44:53 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iDjj-0003t5-00 for simple@ietf.org; Thu, 31 Jul 2003 09:44:55 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19iDjj-0003t2-00 for simple@ietf.org; Thu, 31 Jul 2003 09:44:55 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6VDiqG04468 for ; Thu, 31 Jul 2003 08:44:54 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 31 Jul 2003 08:44:52 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 31 Jul 2003 06:43:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt Message-ID: Thread-Topic: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt Thread-Index: AcNXBdndCObjAoTTStO0y6sVQTgrswAY1wIg To: , Cc: , , X-OriginalArrivalTime: 31 Jul 2003 13:43:57.0344 (UTC) FILETIME=[CA488A00:01C35769] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 09:43:55 -0400 Content-Transfer-Encoding: quoted-printable >>> - optional ran, roaming, visited-network, signal-strength=20 >attributes.=20 >>> (Assuming you think these make sense to provide at all.)=20 >These could=20 >>> be grouped under a mobile attribute or left standalone. >>=20 >>=20 >> I dont think they can be in a single mobile attribute, there=20 >is a bunch=20 >> of separate information here. > >I am dubious on 'roaming'. This can mean many different things and=20 >nothing at all. Without having detailed knowledge of the presentity's=20 >carrier subscription and its coverage, it says essentially=20 >nothing. (In=20 >NJ, the pin-drop carrier can make you roam into analog just a=20 >few miles=20 >west on Rt. 4, as that's the border of digital coverage, so this says=20 >nothing about distance from home.) Also, are there currently any=20 >interfaces that would allow you to retrieve this information? > I agree with Henning here. Roaming constitutes a rather ambiguous = semantic. Without having means to annotate "roaming" by some kind of particular semantic = it is mostly doomed=20 to be misinterpreted by watchers rather than used usefully. Hence, = either remove it, or bound it to a particular semantic, or introduce further possible semantics of = "roaming" as separate values (gets messy though). Dirk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 31 09:45:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25496 for ; Thu, 31 Jul 2003 09:45:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDk4-0000iX-Ht for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 09:45:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VDjGwh002753 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 09:45:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDk4-0000iK-D8 for simple-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 09:45:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25475; Thu, 31 Jul 2003 09:45:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iDk1-0003tD-00; Thu, 31 Jul 2003 09:45:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iDk1-0003tA-00; Thu, 31 Jul 2003 09:45:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDjp-0000dQ-57; Thu, 31 Jul 2003 09:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDjl-0000d3-Oo for simple@optimus.ietf.org; Thu, 31 Jul 2003 09:44:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25463 for ; Thu, 31 Jul 2003 09:44:53 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iDjj-0003t5-00 for simple@ietf.org; Thu, 31 Jul 2003 09:44:55 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19iDjj-0003t2-00 for simple@ietf.org; Thu, 31 Jul 2003 09:44:55 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6VDiqG04468 for ; Thu, 31 Jul 2003 08:44:54 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 31 Jul 2003 08:44:52 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 31 Jul 2003 06:43:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt Message-ID: Thread-Topic: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt Thread-Index: AcNXBdndCObjAoTTStO0y6sVQTgrswAY1wIg To: , Cc: , , X-OriginalArrivalTime: 31 Jul 2003 13:43:57.0344 (UTC) FILETIME=[CA488A00:01C35769] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 09:43:55 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >>> - optional ran, roaming, visited-network, signal-strength=20 >attributes.=20 >>> (Assuming you think these make sense to provide at all.)=20 >These could=20 >>> be grouped under a mobile attribute or left standalone. >>=20 >>=20 >> I dont think they can be in a single mobile attribute, there=20 >is a bunch=20 >> of separate information here. > >I am dubious on 'roaming'. This can mean many different things and=20 >nothing at all. Without having detailed knowledge of the presentity's=20 >carrier subscription and its coverage, it says essentially=20 >nothing. (In=20 >NJ, the pin-drop carrier can make you roam into analog just a=20 >few miles=20 >west on Rt. 4, as that's the border of digital coverage, so this says=20 >nothing about distance from home.) Also, are there currently any=20 >interfaces that would allow you to retrieve this information? > I agree with Henning here. Roaming constitutes a rather ambiguous = semantic. Without having means to annotate "roaming" by some kind of particular semantic = it is mostly doomed=20 to be misinterpreted by watchers rather than used usefully. Hence, = either remove it, or bound it to a particular semantic, or introduce further possible semantics of = "roaming" as separate values (gets messy though). Dirk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 31 10:14:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27430; Thu, 31 Jul 2003 10:14:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iECI-000463-00; Thu, 31 Jul 2003 10:14:26 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iECG-00045y-00; Thu, 31 Jul 2003 10:14:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEBt-0001zh-3a; Thu, 31 Jul 2003 10:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iC0x-0004OC-7O for simple@optimus.ietf.org; Thu, 31 Jul 2003 07:54:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21534 for ; Thu, 31 Jul 2003 07:54:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iC0w-0002hw-00 for simple@ietf.org; Thu, 31 Jul 2003 07:54:34 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 19iC0v-0002hh-00 for simple@ietf.org; Thu, 31 Jul 2003 07:54:33 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 31 Jul 2003 13:53:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] New I-D on presence states for phones Message-ID: Thread-Topic: [Simple] New I-D on presence states for phones Thread-Index: AcNW40zc7cm/g5t5Qi2fPOM83ZUttQAdAHog From: "MANSOOR Usama FTRD/DMR/LON" To: "Jonathan Rosenberg" , "Vikas Tandon" Cc: X-OriginalArrivalTime: 31 Jul 2003 11:53:55.0698 (UTC) FILETIME=[6B654D20:01C3575A] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 13:53:54 +0200 Content-Transfer-Encoding: quoted-printable One possible application for signal strength would be if you want to hand over from Wi-Fi to cellular and back again, and having the handover triggered according to the signal strength on the two network types.=20 Another, I guess, would be knowing whether you had GSM and/or Wi-Fi coverage, and being able to use the most appropriate codecs for the bandwidth available (e.g. if you have good enough wi-fi signal strength, then stream a high bandwidth video, otherwise, if you only have GPRS, only stream a low bandwidth video).=20 I'm not sure whether real people would have to see this info though, it could just be of use to the element that controls the call.=20 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, July 30, 2003 10:40 PM To: Vikas Tandon Cc: simple@ietf.org Subject: Re: [Simple] New I-D on presence states for phones Generally, I agree that the scope of the draft was too broad, covering=20 a bunch of things which probably are outside the scope of presence.=20 But, thats the nature of a -00 draft, and the way to get discussion going. The reason I had put signal strength in there in the first place was=20 that, ultimately, a watcher would know that their call/IM/whatever=20 won't succeed if the target has poor signal strength. However, I agree=20 with Markus that it really does change too much (and also probably=20 nearly impossible to obtain in any accurate or timely way). So, I will=20 remove it from the next rev of the document. The best way to determine what is, and what is out, of scope is for=20 people to give examples of the kinds of applications that might need=20 each piece of presence data. If you can't think of a presence app that=20 needs a piece of data, there is a good chance it should just be=20 removed from the spec. So, here are some thoughts on the motivating apps and some of their=20 presence needs: call state: very useful for rendering to watchers, says alot about=20 whether now is a good time to make a call to them. Also useful input=20 to other pieces of presence which can be derived from it, such as=20 OPEN/CLOSED for voice. I agree that the full call state model is=20 perhaps not needed. In particular I cant think of a reason why a=20 watcher cares to know ringing vs. in a call. Both are probably the=20 same in terms of presence. registration state: this seems pretty fundamental - no communication=20 is possible unless this is true. I think its also really useful to=20 render to people, to let them know if the phone is on or off. A change=20 in registration state is frequently the trigger for push apps, such as=20 a ringback application. data-state: useful for knowing if a SIP IM will succeed or not -=20 clearly not if the data-state is not connected. I dont think its=20 useful to render to a user, but applications which want to push=20 information to a user probably care. roaming: I think this is really useful to render to watchers. Its sort=20 of really high level geoloc information. Frequently, you want to know=20 whether someone is on a trip or not, to decide whether to call them,=20 and roaming helps the watcher know that. visited/home strings: not really sure what these might be used for.=20 Seems neat, but perhaps its too much. Anyone have any ideas? barred: I'm not sure this is usefully different than not registered,=20 but I need to think about it. -Jonathan R. Vikas Tandon wrote: > Hi Markus, Alex and SIMPLE experts, >=20 > As rightly pointed out, signal strength can change several times within > a second based on the attenuation factors and even what is displayed on > the phone is a best-possible view. Having lower signal strength however > might not be a very useful information to the watcher. Additionally and > noticeably, we are talking about adding more processing on the client > side. >=20 > If we were to add some of the phone status attributes, we should look at > ones which display what the user wants to be communicated like - I can > set: My phone is switched off without letting others know that actually > I'm on!!=20 >=20 > These category of information might be a useful information on the > network side for delivery purpose but not for the watcher, and moreover > information of this category as best picked up from the network nodes > themselves rather than making the client thicker. >=20 > Regards, > Vikas >=20 >=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of > Alex Audu > Sent: Friday, July 18, 2003 7:49 AM > To: Markus.Isomaki@nokia.com > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] New I-D on presence states for phones >=20 >=20 > Hello, >=20 >>From a user's point of view, I am not sure if "signal strength" is not a > valuable information to have. Granted, it may be changing very > frequently, but you can always limit how often it is updated. >=20 > I am not sure however, if "signal strength" can be a valid attribute of > the state of the phone. It is descriptive, more of the environment the > phone is in, than the phone itself. >=20 > Regards, > Alex. >=20 > Markus.Isomaki@nokia.com wrote: >=20 >=20 >>Hi, >> >>I think this draft defines bunch of useful information. However, I >>would definitely take away the "signal-strength" attribute under the=20 >>wireless phone state. As already stated in the draft, this information >=20 >=20 >>is changing frequently, so I think it is not sensible in the timescale >=20 >=20 >>that SIP events work. And even if it would be possible to convey this=20 >>information, what would it mean in GPRS, WCDMA or WiFi? Is there any=20 >>use case what any watcher could in _practice_ benefit from this=20 >>information? >> >>What might be useful as an addition to "ran" is some more information >>on the access-link, i.e. that the "downlink capacity class" is ~40=20 >>kbps, and "RTT class" is ~500 ms. This _kind_ of information might=20 >>give watchers some idea what _kind_ of applications/media the device=20 >>could be able to do at the moment (although you could find that out=20 >>also through PIDF/prescaps and SDP negotiations). This kind of info is >=20 >=20 >>relatively static (in the order of minutes rather than seconds), but=20 >>still changing. In any case, this would be more valuable than=20 >>"signal-strength". >> >>Markus >> >> >>>-----Original Message----- >>>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>>Sent: 08 July, 2003 09:42 >>>To: Simple WG >>>Subject: [Simple] New I-D on presence states for phones >>> >>> >>>Folks, >>> >>>In case folks havent seen it, I wanted to call your attention to: >>> >>>http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s >> >>imple-pidf-phone-00.txt >>http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt >>http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html >> >>This draft, written by Jon and myself, defines some PIDF extensions >>for describing phones, including traditional "black" phones, wireless=20 >>phones and enterprise phones. I think these will provide invaluable=20 >>for a device-centric view of a presentity. >> >>Comments and questions welcome. >> >>Thanks, >>Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=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 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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-admin@ietf.org Thu Jul 31 10:14:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27429; Thu, 31 Jul 2003 10:14:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iECI-000465-00; Thu, 31 Jul 2003 10:14:26 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iECG-00045z-00; Thu, 31 Jul 2003 10:14:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEBs-0001zZ-Pc; Thu, 31 Jul 2003 10:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iBfs-0003fk-VV for simple@optimus.ietf.org; Thu, 31 Jul 2003 07:32:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21148 for ; Thu, 31 Jul 2003 07:32:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iBfs-0002Xb-00 for simple@ietf.org; Thu, 31 Jul 2003 07:32:48 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 19iBfr-0002XU-00 for simple@ietf.org; Thu, 31 Jul 2003 07:32:47 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 31 Jul 2003 13:30:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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-rosenberg-peterson-simple-pidf-phone-00.txt Message-ID: Thread-Topic: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt Thread-Index: AcNXBc78ke5q/dm/SduCMKIRmK+85AATuFQw From: "MANSOOR Usama FTRD/DMR/LON" To: "Henning Schulzrinne" , "Jonathan Rosenberg" Cc: "Paul Kyzivat" , , X-OriginalArrivalTime: 31 Jul 2003 11:30:34.0519 (UTC) FILETIME=[283A5A70:01C35757] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 13:30:33 +0200 Content-Transfer-Encoding: quoted-printable I guess it's not the fact that they may be on a different network that's important, but the fact that they may be in a different country, in a different timezone, and will cost more to call that people are interested in. (Well, in Europe at least :) So maybe we should represent this somehow instead of 'roaming'? - Usama -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, July 31, 2003 2:47 AM To: Jonathan Rosenberg Cc: Paul Kyzivat; jon.peterson@neustar.biz; simple@ietf.org Subject: Re: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt I am dubious on 'roaming'. This can mean many different things and=20 nothing at all. Without having detailed knowledge of the presentity's=20 carrier subscription and its coverage, it says essentially nothing. (In=20 NJ, the pin-drop carrier can make you roam into analog just a few miles=20 west on Rt. 4, as that's the border of digital coverage, so this says=20 nothing about distance from home.) Also, are there currently any=20 interfaces that would allow you to retrieve this information? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 31 10:14:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27577 for ; Thu, 31 Jul 2003 10:14:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iECL-00026q-M1 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 10:14:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VEETSe008102 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 10:14:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iECL-00026W-Gt for simple-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 10:14:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27429; Thu, 31 Jul 2003 10:14:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iECI-000465-00; Thu, 31 Jul 2003 10:14:26 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iECG-00045z-00; Thu, 31 Jul 2003 10:14:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEBs-0001zZ-Pc; Thu, 31 Jul 2003 10:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iBfs-0003fk-VV for simple@optimus.ietf.org; Thu, 31 Jul 2003 07:32:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21148 for ; Thu, 31 Jul 2003 07:32:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iBfs-0002Xb-00 for simple@ietf.org; Thu, 31 Jul 2003 07:32:48 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 19iBfr-0002XU-00 for simple@ietf.org; Thu, 31 Jul 2003 07:32:47 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 31 Jul 2003 13:30:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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-rosenberg-peterson-simple-pidf-phone-00.txt Message-ID: Thread-Topic: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt Thread-Index: AcNXBc78ke5q/dm/SduCMKIRmK+85AATuFQw From: "MANSOOR Usama FTRD/DMR/LON" To: "Henning Schulzrinne" , "Jonathan Rosenberg" Cc: "Paul Kyzivat" , , X-OriginalArrivalTime: 31 Jul 2003 11:30:34.0519 (UTC) FILETIME=[283A5A70:01C35757] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 13:30:33 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I guess it's not the fact that they may be on a different network that's important, but the fact that they may be in a different country, in a different timezone, and will cost more to call that people are interested in. (Well, in Europe at least :) So maybe we should represent this somehow instead of 'roaming'? - Usama -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, July 31, 2003 2:47 AM To: Jonathan Rosenberg Cc: Paul Kyzivat; jon.peterson@neustar.biz; simple@ietf.org Subject: Re: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt I am dubious on 'roaming'. This can mean many different things and=20 nothing at all. Without having detailed knowledge of the presentity's=20 carrier subscription and its coverage, it says essentially nothing. (In=20 NJ, the pin-drop carrier can make you roam into analog just a few miles=20 west on Rt. 4, as that's the border of digital coverage, so this says=20 nothing about distance from home.) Also, are there currently any=20 interfaces that would allow you to retrieve this information? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 31 10:43:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29955; Thu, 31 Jul 2003 10:43:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEeJ-0004iy-00; Thu, 31 Jul 2003 10:43:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iEeI-0004iv-00; Thu, 31 Jul 2003 10:43:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEdx-0003jT-37; Thu, 31 Jul 2003 10:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEdZ-0003iS-Fh for simple@optimus.ietf.org; Thu, 31 Jul 2003 10:42:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29914 for ; Thu, 31 Jul 2003 10:42:31 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEdW-0004i6-00 for simple@ietf.org; Thu, 31 Jul 2003 10:42:34 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19iEdV-0004i3-00 for simple@ietf.org; Thu, 31 Jul 2003 10:42:34 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6VEgWB21439 for ; Thu, 31 Jul 2003 17:42:32 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 31 Jul 2003 17:42:31 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 31 Jul 2003 17:42:31 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 31 Jul 2003 07:41:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] New I-D on presence states for phones Message-ID: Thread-Topic: [Simple] New I-D on presence states for phones Thread-Index: AcNW40zc7cm/g5t5Qi2fPOM83ZUttQAdAHogAAaUYFA= To: , , Cc: X-OriginalArrivalTime: 31 Jul 2003 14:41:45.0937 (UTC) FILETIME=[DDB9D410:01C35771] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:41:44 -0400 Content-Transfer-Encoding: quoted-printable >One possible application for signal strength would be if you want to >hand over from Wi-Fi to cellular and back again, and having=20 >the handover >triggered according to the signal strength on the two network types.=20 I strongly hope you are not suggesting handover control based on SIP = presence based signal strength. There are appropriate L2 mechanisms doing this in = real-time=20 rather well. I do not see this as a real application example. Dirk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 31 10:43:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29981 for ; Thu, 31 Jul 2003 10:43:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEeM-0003nM-IM for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 10:43:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VEhQjD014582 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 10:43:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEeM-0003n7-EZ for simple-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 10:43:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29955; Thu, 31 Jul 2003 10:43:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEeJ-0004iy-00; Thu, 31 Jul 2003 10:43:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iEeI-0004iv-00; Thu, 31 Jul 2003 10:43:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEdx-0003jT-37; Thu, 31 Jul 2003 10:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEdZ-0003iS-Fh for simple@optimus.ietf.org; Thu, 31 Jul 2003 10:42:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29914 for ; Thu, 31 Jul 2003 10:42:31 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEdW-0004i6-00 for simple@ietf.org; Thu, 31 Jul 2003 10:42:34 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19iEdV-0004i3-00 for simple@ietf.org; Thu, 31 Jul 2003 10:42:34 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6VEgWB21439 for ; Thu, 31 Jul 2003 17:42:32 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 31 Jul 2003 17:42:31 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 31 Jul 2003 17:42:31 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 31 Jul 2003 07:41:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] New I-D on presence states for phones Message-ID: Thread-Topic: [Simple] New I-D on presence states for phones Thread-Index: AcNW40zc7cm/g5t5Qi2fPOM83ZUttQAdAHogAAaUYFA= To: , , Cc: X-OriginalArrivalTime: 31 Jul 2003 14:41:45.0937 (UTC) FILETIME=[DDB9D410:01C35771] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:41:44 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >One possible application for signal strength would be if you want to >hand over from Wi-Fi to cellular and back again, and having=20 >the handover >triggered according to the signal strength on the two network types.=20 I strongly hope you are not suggesting handover control based on SIP = presence based signal strength. There are appropriate L2 mechanisms doing this in = real-time=20 rather well. I do not see this as a real application example. Dirk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 31 10:55:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00377; Thu, 31 Jul 2003 10:55:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEpc-0004pE-00; Thu, 31 Jul 2003 10:55:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iEpb-0004pB-00; Thu, 31 Jul 2003 10:55:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEob-0004NH-3j; Thu, 31 Jul 2003 10:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEo2-0004KB-N8 for simple@optimus.ietf.org; Thu, 31 Jul 2003 10:53:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00294 for ; Thu, 31 Jul 2003 10:53:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEo0-0004oJ-00 for simple@ietf.org; Thu, 31 Jul 2003 10:53:24 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19iEnz-0004oA-00 for simple@ietf.org; Thu, 31 Jul 2003 10:53:23 -0400 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6VErEdf025125 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Jul 2003 10:53:14 -0400 (EDT) Message-ID: <3F292D5A.7070004@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dirk.Trossen@nokia.com CC: usama.mansoor@rd.francetelecom.com, jdrosen@dynamicsoft.com, vikas@arciis.com, simple@ietf.org Subject: Re: [Simple] New I-D on presence states for phones References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:53:14 -0400 Content-Transfer-Encoding: 7bit Dirk.Trossen@nokia.com wrote: >>One possible application for signal strength would be if you want to >>hand over from Wi-Fi to cellular and back again, and having >>the handover >>triggered according to the signal strength on the two network types. > > > I strongly hope you are not suggesting handover control based on SIP presence > based signal strength. There are appropriate L2 mechanisms doing this in real-time > rather well. I do not see this as a real application example. > Also, comparing signal strengths in the two different networks is rather like comparing apples and oranges... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 31 10:55:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00409 for ; Thu, 31 Jul 2003 10:55:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEpf-0004TD-H5 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 10:55:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VEt7WN017177 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 10:55:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEpf-0004Sy-D5 for simple-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 10:55:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00377; Thu, 31 Jul 2003 10:55:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEpc-0004pE-00; Thu, 31 Jul 2003 10:55:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iEpb-0004pB-00; Thu, 31 Jul 2003 10:55:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEob-0004NH-3j; Thu, 31 Jul 2003 10:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEo2-0004KB-N8 for simple@optimus.ietf.org; Thu, 31 Jul 2003 10:53:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00294 for ; Thu, 31 Jul 2003 10:53:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEo0-0004oJ-00 for simple@ietf.org; Thu, 31 Jul 2003 10:53:24 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19iEnz-0004oA-00 for simple@ietf.org; Thu, 31 Jul 2003 10:53:23 -0400 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6VErEdf025125 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Jul 2003 10:53:14 -0400 (EDT) Message-ID: <3F292D5A.7070004@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dirk.Trossen@nokia.com CC: usama.mansoor@rd.francetelecom.com, jdrosen@dynamicsoft.com, vikas@arciis.com, simple@ietf.org Subject: Re: [Simple] New I-D on presence states for phones References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:53:14 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dirk.Trossen@nokia.com wrote: >>One possible application for signal strength would be if you want to >>hand over from Wi-Fi to cellular and back again, and having >>the handover >>triggered according to the signal strength on the two network types. > > > I strongly hope you are not suggesting handover control based on SIP presence > based signal strength. There are appropriate L2 mechanisms doing this in real-time > rather well. I do not see this as a real application example. > Also, comparing signal strengths in the two different networks is rather like comparing apples and oranges... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 31 11:04:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27579 for ; Thu, 31 Jul 2003 10:14:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iECL-00026V-G3 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 10:14:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VEETG8008086 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 10:14:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iECL-00026L-B1 for simple-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 10:14:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27430; Thu, 31 Jul 2003 10:14:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iECI-000463-00; Thu, 31 Jul 2003 10:14:26 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iECG-00045y-00; Thu, 31 Jul 2003 10:14:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEBt-0001zh-3a; Thu, 31 Jul 2003 10:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iC0x-0004OC-7O for simple@optimus.ietf.org; Thu, 31 Jul 2003 07:54:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21534 for ; Thu, 31 Jul 2003 07:54:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iC0w-0002hw-00 for simple@ietf.org; Thu, 31 Jul 2003 07:54:34 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 19iC0v-0002hh-00 for simple@ietf.org; Thu, 31 Jul 2003 07:54:33 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 31 Jul 2003 13:53:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] New I-D on presence states for phones Message-ID: Thread-Topic: [Simple] New I-D on presence states for phones Thread-Index: AcNW40zc7cm/g5t5Qi2fPOM83ZUttQAdAHog From: "MANSOOR Usama FTRD/DMR/LON" To: "Jonathan Rosenberg" , "Vikas Tandon" Cc: X-OriginalArrivalTime: 31 Jul 2003 11:53:55.0698 (UTC) FILETIME=[6B654D20:01C3575A] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 13:53:54 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable One possible application for signal strength would be if you want to hand over from Wi-Fi to cellular and back again, and having the handover triggered according to the signal strength on the two network types.=20 Another, I guess, would be knowing whether you had GSM and/or Wi-Fi coverage, and being able to use the most appropriate codecs for the bandwidth available (e.g. if you have good enough wi-fi signal strength, then stream a high bandwidth video, otherwise, if you only have GPRS, only stream a low bandwidth video).=20 I'm not sure whether real people would have to see this info though, it could just be of use to the element that controls the call.=20 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, July 30, 2003 10:40 PM To: Vikas Tandon Cc: simple@ietf.org Subject: Re: [Simple] New I-D on presence states for phones Generally, I agree that the scope of the draft was too broad, covering=20 a bunch of things which probably are outside the scope of presence.=20 But, thats the nature of a -00 draft, and the way to get discussion going. The reason I had put signal strength in there in the first place was=20 that, ultimately, a watcher would know that their call/IM/whatever=20 won't succeed if the target has poor signal strength. However, I agree=20 with Markus that it really does change too much (and also probably=20 nearly impossible to obtain in any accurate or timely way). So, I will=20 remove it from the next rev of the document. The best way to determine what is, and what is out, of scope is for=20 people to give examples of the kinds of applications that might need=20 each piece of presence data. If you can't think of a presence app that=20 needs a piece of data, there is a good chance it should just be=20 removed from the spec. So, here are some thoughts on the motivating apps and some of their=20 presence needs: call state: very useful for rendering to watchers, says alot about=20 whether now is a good time to make a call to them. Also useful input=20 to other pieces of presence which can be derived from it, such as=20 OPEN/CLOSED for voice. I agree that the full call state model is=20 perhaps not needed. In particular I cant think of a reason why a=20 watcher cares to know ringing vs. in a call. Both are probably the=20 same in terms of presence. registration state: this seems pretty fundamental - no communication=20 is possible unless this is true. I think its also really useful to=20 render to people, to let them know if the phone is on or off. A change=20 in registration state is frequently the trigger for push apps, such as=20 a ringback application. data-state: useful for knowing if a SIP IM will succeed or not -=20 clearly not if the data-state is not connected. I dont think its=20 useful to render to a user, but applications which want to push=20 information to a user probably care. roaming: I think this is really useful to render to watchers. Its sort=20 of really high level geoloc information. Frequently, you want to know=20 whether someone is on a trip or not, to decide whether to call them,=20 and roaming helps the watcher know that. visited/home strings: not really sure what these might be used for.=20 Seems neat, but perhaps its too much. Anyone have any ideas? barred: I'm not sure this is usefully different than not registered,=20 but I need to think about it. -Jonathan R. Vikas Tandon wrote: > Hi Markus, Alex and SIMPLE experts, >=20 > As rightly pointed out, signal strength can change several times within > a second based on the attenuation factors and even what is displayed on > the phone is a best-possible view. Having lower signal strength however > might not be a very useful information to the watcher. Additionally and > noticeably, we are talking about adding more processing on the client > side. >=20 > If we were to add some of the phone status attributes, we should look at > ones which display what the user wants to be communicated like - I can > set: My phone is switched off without letting others know that actually > I'm on!!=20 >=20 > These category of information might be a useful information on the > network side for delivery purpose but not for the watcher, and moreover > information of this category as best picked up from the network nodes > themselves rather than making the client thicker. >=20 > Regards, > Vikas >=20 >=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of > Alex Audu > Sent: Friday, July 18, 2003 7:49 AM > To: Markus.Isomaki@nokia.com > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] New I-D on presence states for phones >=20 >=20 > Hello, >=20 >>From a user's point of view, I am not sure if "signal strength" is not a > valuable information to have. Granted, it may be changing very > frequently, but you can always limit how often it is updated. >=20 > I am not sure however, if "signal strength" can be a valid attribute of > the state of the phone. It is descriptive, more of the environment the > phone is in, than the phone itself. >=20 > Regards, > Alex. >=20 > Markus.Isomaki@nokia.com wrote: >=20 >=20 >>Hi, >> >>I think this draft defines bunch of useful information. However, I >>would definitely take away the "signal-strength" attribute under the=20 >>wireless phone state. As already stated in the draft, this information >=20 >=20 >>is changing frequently, so I think it is not sensible in the timescale >=20 >=20 >>that SIP events work. And even if it would be possible to convey this=20 >>information, what would it mean in GPRS, WCDMA or WiFi? Is there any=20 >>use case what any watcher could in _practice_ benefit from this=20 >>information? >> >>What might be useful as an addition to "ran" is some more information >>on the access-link, i.e. that the "downlink capacity class" is ~40=20 >>kbps, and "RTT class" is ~500 ms. This _kind_ of information might=20 >>give watchers some idea what _kind_ of applications/media the device=20 >>could be able to do at the moment (although you could find that out=20 >>also through PIDF/prescaps and SDP negotiations). This kind of info is >=20 >=20 >>relatively static (in the order of minutes rather than seconds), but=20 >>still changing. In any case, this would be more valuable than=20 >>"signal-strength". >> >>Markus >> >> >>>-----Original Message----- >>>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>>Sent: 08 July, 2003 09:42 >>>To: Simple WG >>>Subject: [Simple] New I-D on presence states for phones >>> >>> >>>Folks, >>> >>>In case folks havent seen it, I wanted to call your attention to: >>> >>>http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s >> >>imple-pidf-phone-00.txt >>http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt >>http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html >> >>This draft, written by Jon and myself, defines some PIDF extensions >>for describing phones, including traditional "black" phones, wireless=20 >>phones and enterprise phones. I think these will provide invaluable=20 >>for a device-centric view of a presentity. >> >>Comments and questions welcome. >> >>Thanks, >>Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=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 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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-admin@ietf.org Thu Jul 31 11:15:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01160; Thu, 31 Jul 2003 11:15:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iF9I-0004zP-00; Thu, 31 Jul 2003 11:15:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iF9H-0004zM-00; Thu, 31 Jul 2003 11:15:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF7x-0005ea-1q; Thu, 31 Jul 2003 11:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF6z-0005dw-O7 for simple@optimus.ietf.org; Thu, 31 Jul 2003 11:13:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01107 for ; Thu, 31 Jul 2003 11:12:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iF6y-0004yE-00 for simple@ietf.org; Thu, 31 Jul 2003 11:13:00 -0400 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 19iF6y-0004y5-00 for simple@ietf.org; Thu, 31 Jul 2003 11:13:00 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h6VFC5wA020850; Thu, 31 Jul 2003 10:12:05 -0500 (CDT) Message-ID: <3F2931C5.AE6BBF5D@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt References: <200306261203.IAA16528@ietf.org> <3F16C405.3020900@cisco.com> <3F2840B4.5030202@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:12:05 -0500 Content-Transfer-Encoding: 7bit Jonathan, I think I'll agree with Paul on the issue that a watcher could care less about the type of device on the other end. Frankly, all we should care about is the service type. The device type has no value (in my mind). New devices that provide telephony/IM services are coming to the market almost daily. And of course, lets not forget softphones which can be staged on any computing device. Regards, Alex. Jonathan Rosenberg wrote: > Thanks for the comments. Responses inline. > > Paul Kyzivat wrote: > > > I think representing states appropriate to a phone is a good idea. But I > > have serious problems with the details of this draft: > > > > - multiple ways of representing equivalent state > > > > Typically a watcher is likely to care less what kind of phone you have, > > and simply want to know if you are available for a call and/or are in a > > call. Having to decipher three different representations of this same > > information is a needless hassle. > > I think a watcher may want to know what type of phone you have - > knowing that its home vs. wireless vs. business is useful presence > information in itself, I believe. > > > > > Also, to the caller there is no functional difference between a POTS > > phone with call waiting available, and a business phone with two "lines" > > associated to the same number with one in use and one free. In both > > cases the callee is in a call but still available for a call. > > Representing these situations differently just makes things difficult > > for the watcher. > > I think I agree with that. I should point out that our split of the > doc and schema along the device type lines was primarily to facilitate > a division of labor, not because of a fundamental belief that these > needed to be totally separated. That said, there definitely are > differences in states and infrmation between devices. I'm all for > making as much common as is possible though. > > Perhaps a better way to deal with this is to indicate that there > exists another call in progress, or perhaps an indication of how many > calls are in progress (useful for call routing to customer support > operators perhaps?). > > > > > - problematic extensibility model > > > > This pattern also sets the stage for more complexity in the future as > > new devices with different combinations of features hit the market. > > Suppose I come out with both home (single line) and business (multi > > line) voice/im phones. The home phone can do one voice call or one im > > call. The business phone can do two voice calls and two im calls. > > > > It isn't at all clear that I can extend any of the proposed models to > > accomodate my new phone in a graceful way. I may end up defining two new > > types for my new phones, different from these three types. Then I have > > problems with backward compatibility. > > I'm not sure I see the specific problem here - is it because your > phones can do IM also, and none of the phone types in the doc discuss IM? > > If this is the case, I would argue that it comes back to a > service/device view. The current draft doesnt separate the two. Many > aspects of the draft refer to a service view, where the service is > telephony. Others refer to the device view - things such as access > network and signal strength (which I agree should be booted) are > device properties that span services. For example, IM and PTT may also > run on the phone, and things like signal strength would affect all of > them. > > So, if I have a device as you describe, I could present it with a > service view that lists telephony as one service, IM as another. The > device-specific attributes would perhaps get replicated in each > service, or else composed in some way into the overall availability > (OPEN/CLOSED). > > What do you think about splitting the attributes along those lines? > > > > > - inclusion of useless data > > > > Identifiers for lines seems useless. They are all associated with the > > same phone number, and are not addressable for any purpose. Showing > > lines that are not in use is also pretty useless except for providing a > > way to know that a new call can be accepted. > > I'll agree with that. > > > Data-state could be useful > > but I think I need to know a lot more info to predict what that might > > permit me to do. > > As per my other note, its useful for applications that want to push > data to the phone. > > > > > ALTERNATIVE: > > > > I think the following kind of structure would accomplish the same thing > > you have proposed yet address my issues: > > > > - a representation for a call. This would subsume your call-state, but > > omitting the not-in-call state. But it would also be extensible for > > other call attributes. This can be repeated as many times as needed to > > represent calls in progress, not lines. (This clearly overlaps with the > > dialog package - something worth discussing. It provides extra > > information in that it can show a call before a dialog is established. > > And with further extension it might provide a way to represent calls on > > hold, if we can figure out what that means.) > > This is different from dialog package in that there isnt a sip dialog. > Nothing in the simple-pidf draft is specific to sip phones. In my > mind, the model is that a presence server might itsefl subscribe to > the dialog package for a phone, and based on that information, > generate presence documents using the pidf information. For other > phone types, such as a wireline phone, it might use the spirits > interface or some proprietary i/f to a switch. > > > > > - an indication of whether available for another call. In your model > > this seems to be represented by some call-state=not-in-call, or by > > call-waiting=available. But it also seems to be indicated by > > open. I'm uncomfortable using basic status for this, > > because the device may still be open for other kinds of signaling, such > > as subscriptions. > > > > In this new model availablily for calls could also be indicated by a > > call-state of available, but I see no need to model lines not in use. > > This is rooted in old world notions that there are some fixed number of > > lines. Conceivably some new attribute could be introduced for this, but > > I think the attributes in RPIDS already have this covered. (This still > > cries out for capabilities, to describe *what* I am available for, but > > that can be dealt with separately.) > > I think your proposal is reasonable - the phone "service" is modeled > by zero or more call elements that represent some amount of call > state, and information on ability to take another call. > > I see this as different from basic status, in that basic status would > depend on other things too. For example, if I'm in a meeting, even if > I can take another call, the basic status for my telephony service > would be closed. > > > > > - an optional element representing the home network provider. This is > > appropriate for all kinds of phones. (I'm not sure why I would want to > > publish this, but I can go along.) > > I can go either way on this too. Now, is this a device or service > property? I can have an IM service on my phone from a different > provider than the one that provides me data access. Arguably, the data > access provider is a device property. > > > > > - optional ran, roaming, visited-network, signal-strength attributes. > > (Assuming you think these make sense to provide at all.) These could be > > grouped under a mobile attribute or left standalone. > > I dont think they can be in a single mobile attribute, there is a > bunch of separate information here. > > > > > - I consider data-state to be a capability. (If you think it is useful > > at all - it isn't clear to me what this implies I can do.) I would deal > > with it together with other capabilities, like voice, video, IM. > > I think its a device capability that says something about availability > across a number of services. > > > > > Using the above, representations for POTS phones, business phones, and > > wireless phones are simply usage profiles. The watcher won't explicitly > > know what kind of phone it is except by inference from the kinds of > > presence he sees it use. To me this is a good thing. > > Well, I would still argue that an attribute that describes the type of > device is useful. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > 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 exim@www1.ietf.org Thu Jul 31 11:15:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01217 for ; Thu, 31 Jul 2003 11:15:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF9K-0005nv-3y for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 11:15:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VFFQQZ022305 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 11:15:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF9J-0005ng-Vj for simple-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 11:15:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01160; Thu, 31 Jul 2003 11:15:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iF9I-0004zP-00; Thu, 31 Jul 2003 11:15:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iF9H-0004zM-00; Thu, 31 Jul 2003 11:15:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF7x-0005ea-1q; Thu, 31 Jul 2003 11:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF6z-0005dw-O7 for simple@optimus.ietf.org; Thu, 31 Jul 2003 11:13:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01107 for ; Thu, 31 Jul 2003 11:12:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iF6y-0004yE-00 for simple@ietf.org; Thu, 31 Jul 2003 11:13:00 -0400 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 19iF6y-0004y5-00 for simple@ietf.org; Thu, 31 Jul 2003 11:13:00 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h6VFC5wA020850; Thu, 31 Jul 2003 10:12:05 -0500 (CDT) Message-ID: <3F2931C5.AE6BBF5D@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt References: <200306261203.IAA16528@ietf.org> <3F16C405.3020900@cisco.com> <3F2840B4.5030202@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:12:05 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan, I think I'll agree with Paul on the issue that a watcher could care less about the type of device on the other end. Frankly, all we should care about is the service type. The device type has no value (in my mind). New devices that provide telephony/IM services are coming to the market almost daily. And of course, lets not forget softphones which can be staged on any computing device. Regards, Alex. Jonathan Rosenberg wrote: > Thanks for the comments. Responses inline. > > Paul Kyzivat wrote: > > > I think representing states appropriate to a phone is a good idea. But I > > have serious problems with the details of this draft: > > > > - multiple ways of representing equivalent state > > > > Typically a watcher is likely to care less what kind of phone you have, > > and simply want to know if you are available for a call and/or are in a > > call. Having to decipher three different representations of this same > > information is a needless hassle. > > I think a watcher may want to know what type of phone you have - > knowing that its home vs. wireless vs. business is useful presence > information in itself, I believe. > > > > > Also, to the caller there is no functional difference between a POTS > > phone with call waiting available, and a business phone with two "lines" > > associated to the same number with one in use and one free. In both > > cases the callee is in a call but still available for a call. > > Representing these situations differently just makes things difficult > > for the watcher. > > I think I agree with that. I should point out that our split of the > doc and schema along the device type lines was primarily to facilitate > a division of labor, not because of a fundamental belief that these > needed to be totally separated. That said, there definitely are > differences in states and infrmation between devices. I'm all for > making as much common as is possible though. > > Perhaps a better way to deal with this is to indicate that there > exists another call in progress, or perhaps an indication of how many > calls are in progress (useful for call routing to customer support > operators perhaps?). > > > > > - problematic extensibility model > > > > This pattern also sets the stage for more complexity in the future as > > new devices with different combinations of features hit the market. > > Suppose I come out with both home (single line) and business (multi > > line) voice/im phones. The home phone can do one voice call or one im > > call. The business phone can do two voice calls and two im calls. > > > > It isn't at all clear that I can extend any of the proposed models to > > accomodate my new phone in a graceful way. I may end up defining two new > > types for my new phones, different from these three types. Then I have > > problems with backward compatibility. > > I'm not sure I see the specific problem here - is it because your > phones can do IM also, and none of the phone types in the doc discuss IM? > > If this is the case, I would argue that it comes back to a > service/device view. The current draft doesnt separate the two. Many > aspects of the draft refer to a service view, where the service is > telephony. Others refer to the device view - things such as access > network and signal strength (which I agree should be booted) are > device properties that span services. For example, IM and PTT may also > run on the phone, and things like signal strength would affect all of > them. > > So, if I have a device as you describe, I could present it with a > service view that lists telephony as one service, IM as another. The > device-specific attributes would perhaps get replicated in each > service, or else composed in some way into the overall availability > (OPEN/CLOSED). > > What do you think about splitting the attributes along those lines? > > > > > - inclusion of useless data > > > > Identifiers for lines seems useless. They are all associated with the > > same phone number, and are not addressable for any purpose. Showing > > lines that are not in use is also pretty useless except for providing a > > way to know that a new call can be accepted. > > I'll agree with that. > > > Data-state could be useful > > but I think I need to know a lot more info to predict what that might > > permit me to do. > > As per my other note, its useful for applications that want to push > data to the phone. > > > > > ALTERNATIVE: > > > > I think the following kind of structure would accomplish the same thing > > you have proposed yet address my issues: > > > > - a representation for a call. This would subsume your call-state, but > > omitting the not-in-call state. But it would also be extensible for > > other call attributes. This can be repeated as many times as needed to > > represent calls in progress, not lines. (This clearly overlaps with the > > dialog package - something worth discussing. It provides extra > > information in that it can show a call before a dialog is established. > > And with further extension it might provide a way to represent calls on > > hold, if we can figure out what that means.) > > This is different from dialog package in that there isnt a sip dialog. > Nothing in the simple-pidf draft is specific to sip phones. In my > mind, the model is that a presence server might itsefl subscribe to > the dialog package for a phone, and based on that information, > generate presence documents using the pidf information. For other > phone types, such as a wireline phone, it might use the spirits > interface or some proprietary i/f to a switch. > > > > > - an indication of whether available for another call. In your model > > this seems to be represented by some call-state=not-in-call, or by > > call-waiting=available. But it also seems to be indicated by > > open. I'm uncomfortable using basic status for this, > > because the device may still be open for other kinds of signaling, such > > as subscriptions. > > > > In this new model availablily for calls could also be indicated by a > > call-state of available, but I see no need to model lines not in use. > > This is rooted in old world notions that there are some fixed number of > > lines. Conceivably some new attribute could be introduced for this, but > > I think the attributes in RPIDS already have this covered. (This still > > cries out for capabilities, to describe *what* I am available for, but > > that can be dealt with separately.) > > I think your proposal is reasonable - the phone "service" is modeled > by zero or more call elements that represent some amount of call > state, and information on ability to take another call. > > I see this as different from basic status, in that basic status would > depend on other things too. For example, if I'm in a meeting, even if > I can take another call, the basic status for my telephony service > would be closed. > > > > > - an optional element representing the home network provider. This is > > appropriate for all kinds of phones. (I'm not sure why I would want to > > publish this, but I can go along.) > > I can go either way on this too. Now, is this a device or service > property? I can have an IM service on my phone from a different > provider than the one that provides me data access. Arguably, the data > access provider is a device property. > > > > > - optional ran, roaming, visited-network, signal-strength attributes. > > (Assuming you think these make sense to provide at all.) These could be > > grouped under a mobile attribute or left standalone. > > I dont think they can be in a single mobile attribute, there is a > bunch of separate information here. > > > > > - I consider data-state to be a capability. (If you think it is useful > > at all - it isn't clear to me what this implies I can do.) I would deal > > with it together with other capabilities, like voice, video, IM. > > I think its a device capability that says something about availability > across a number of services. > > > > > Using the above, representations for POTS phones, business phones, and > > wireless phones are simply usage profiles. The watcher won't explicitly > > know what kind of phone it is except by inference from the kinds of > > presence he sees it use. To me this is a good thing. > > Well, I would still argue that an attribute that describes the type of > device is useful. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > 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-admin@ietf.org Thu Jul 31 11:19:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01331; Thu, 31 Jul 2003 11:19:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFD9-00051o-00; Thu, 31 Jul 2003 11:19:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iFD8-00051l-00; Thu, 31 Jul 2003 11:19:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFBp-0005v9-54; Thu, 31 Jul 2003 11:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFBc-0005uw-Eq for simple@optimus.ietf.org; Thu, 31 Jul 2003 11:17:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01284 for ; Thu, 31 Jul 2003 11:17:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFBb-00050o-00 for simple@ietf.org; Thu, 31 Jul 2003 11:17:47 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19iFBa-00050T-00 for simple@ietf.org; Thu, 31 Jul 2003 11:17:46 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29348; Thu, 31 Jul 2003 11:17:09 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24079; Thu, 31 Jul 2003 11:17:10 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 11:17:10 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5C96@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , Dirk.Trossen@nokia.com Cc: usama.mansoor@rd.francetelecom.com, jdrosen@dynamicsoft.com, vikas@arciis.com, simple@ietf.org Subject: RE: [Simple] New I-D on presence states for phones MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 11:17:09 -0400 I think you are dreaming, There are TWO networks, and they are not usually under the same administrative control. If you have a call up, to do a handoff, you will need to do it at the SIP level. It's not something the L2 is going to do. L2 handoff would only work if both networks were in the same administrative domain. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, July 31, 2003 10:53 AM > To: Dirk.Trossen@nokia.com > Cc: usama.mansoor@rd.francetelecom.com; jdrosen@dynamicsoft.com; > vikas@arciis.com; simple@ietf.org > Subject: Re: [Simple] New I-D on presence states for phones > > > Dirk.Trossen@nokia.com wrote: > > >>One possible application for signal strength would be if you want to > >>hand over from Wi-Fi to cellular and back again, and having > >>the handover > >>triggered according to the signal strength on the two > network types. > > > > > > I strongly hope you are not suggesting handover control > based on SIP presence > > based signal strength. There are appropriate L2 mechanisms > doing this in real-time > > rather well. I do not see this as a real application example. > > > Also, comparing signal strengths in the two different > networks is rather > like comparing apples and oranges... > > > _______________________________________________ > 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 exim@www1.ietf.org Thu Jul 31 11:19:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01374 for ; Thu, 31 Jul 2003 11:19:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFDA-00062V-O3 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 11:19:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VFJOQr023209 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 11:19:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFDA-00062G-K6 for simple-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 11:19:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01331; Thu, 31 Jul 2003 11:19:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFD9-00051o-00; Thu, 31 Jul 2003 11:19:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iFD8-00051l-00; Thu, 31 Jul 2003 11:19:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFBp-0005v9-54; Thu, 31 Jul 2003 11:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFBc-0005uw-Eq for simple@optimus.ietf.org; Thu, 31 Jul 2003 11:17:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01284 for ; Thu, 31 Jul 2003 11:17:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFBb-00050o-00 for simple@ietf.org; Thu, 31 Jul 2003 11:17:47 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19iFBa-00050T-00 for simple@ietf.org; Thu, 31 Jul 2003 11:17:46 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29348; Thu, 31 Jul 2003 11:17:09 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24079; Thu, 31 Jul 2003 11:17:10 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 11:17:10 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5C96@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , Dirk.Trossen@nokia.com Cc: usama.mansoor@rd.francetelecom.com, jdrosen@dynamicsoft.com, vikas@arciis.com, simple@ietf.org Subject: RE: [Simple] New I-D on presence states for phones MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 11:17:09 -0400 I think you are dreaming, There are TWO networks, and they are not usually under the same administrative control. If you have a call up, to do a handoff, you will need to do it at the SIP level. It's not something the L2 is going to do. L2 handoff would only work if both networks were in the same administrative domain. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, July 31, 2003 10:53 AM > To: Dirk.Trossen@nokia.com > Cc: usama.mansoor@rd.francetelecom.com; jdrosen@dynamicsoft.com; > vikas@arciis.com; simple@ietf.org > Subject: Re: [Simple] New I-D on presence states for phones > > > Dirk.Trossen@nokia.com wrote: > > >>One possible application for signal strength would be if you want to > >>hand over from Wi-Fi to cellular and back again, and having > >>the handover > >>triggered according to the signal strength on the two > network types. > > > > > > I strongly hope you are not suggesting handover control > based on SIP presence > > based signal strength. There are appropriate L2 mechanisms > doing this in real-time > > rather well. I do not see this as a real application example. > > > Also, comparing signal strengths in the two different > networks is rather > like comparing apples and oranges... > > > _______________________________________________ > 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-admin@ietf.org Thu Jul 31 11:26:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01587; Thu, 31 Jul 2003 11:26:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFJv-00055Q-00; Thu, 31 Jul 2003 11:26:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iFJu-00055N-00; Thu, 31 Jul 2003 11:26:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFIb-0006KJ-QS; Thu, 31 Jul 2003 11:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFI1-0006IO-OK for simple@optimus.ietf.org; Thu, 31 Jul 2003 11:24:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01454 for ; Thu, 31 Jul 2003 11:24:21 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFI0-00053h-00 for simple@ietf.org; Thu, 31 Jul 2003 11:24:24 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19iFHu-00053e-00 for simple@ietf.org; Thu, 31 Jul 2003 11:24:24 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6VFOGG27315 for ; Thu, 31 Jul 2003 10:24:17 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 31 Jul 2003 10:24:15 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 31 Jul 2003 08:24:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] New I-D on presence states for phones Message-ID: Thread-Topic: [Simple] New I-D on presence states for phones Thread-Index: AcNXdv90B+BP4xiPRt6/WTdcQ5D02wAAGdtA To: , Cc: , , , X-OriginalArrivalTime: 31 Jul 2003 15:24:07.0672 (UTC) FILETIME=[C8B7CF80:01C35777] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 11:24:06 -0400 Content-Transfer-Encoding: quoted-printable And for the SIP level handoff, you would use signal strength = indications, obtained from=20 SIP phone presence information?=20 You shouldn't stick to my L2 comment rather than to the doubt I have = that=20 a SIP event based notification on signal strength would suffice to do = handover control. Dirk >-----Original Message----- >From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] >Sent: Thursday, July 31, 2003 11:17 AM >To: 'Henning Schulzrinne'; Trossen Dirk (NRC/Boston) >Cc: usama.mansoor@rd.francetelecom.com; jdrosen@dynamicsoft.com; >vikas@arciis.com; simple@ietf.org >Subject: RE: [Simple] New I-D on presence states for phones > > >I think you are dreaming, > >There are TWO networks, and they are not usually under the same >administrative control. If you have a call up, >to do a handoff, you will need to do it at the SIP level. >It's not something the L2 is going to do. L2 handoff would >only work if both networks were in the same administrative >domain.=20 > >Brian > > > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Thursday, July 31, 2003 10:53 AM >> To: Dirk.Trossen@nokia.com >> Cc: usama.mansoor@rd.francetelecom.com; jdrosen@dynamicsoft.com; >> vikas@arciis.com; simple@ietf.org >> Subject: Re: [Simple] New I-D on presence states for phones >>=20 >>=20 >> Dirk.Trossen@nokia.com wrote: >>=20 >> >>One possible application for signal strength would be if=20 >you want to >> >>hand over from Wi-Fi to cellular and back again, and having=20 >> >>the handover >> >>triggered according to the signal strength on the two=20 >> network types.=20 >> >=20 >> >=20 >> > I strongly hope you are not suggesting handover control=20 >> based on SIP presence >> > based signal strength. There are appropriate L2 mechanisms=20 >> doing this in real-time=20 >> > rather well. I do not see this as a real application example. >> >=20 >> Also, comparing signal strengths in the two different=20 >> networks is rather=20 >> like comparing apples and oranges... >>=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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 31 11:26:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01615 for ; Thu, 31 Jul 2003 11:26:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFJw-0006VS-Rn for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 11:26:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VFQOot025011 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 11:26:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFJw-0006VK-N8 for simple-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 11:26:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01587; Thu, 31 Jul 2003 11:26:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFJv-00055Q-00; Thu, 31 Jul 2003 11:26:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iFJu-00055N-00; Thu, 31 Jul 2003 11:26:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFIb-0006KJ-QS; Thu, 31 Jul 2003 11:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFI1-0006IO-OK for simple@optimus.ietf.org; Thu, 31 Jul 2003 11:24:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01454 for ; Thu, 31 Jul 2003 11:24:21 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFI0-00053h-00 for simple@ietf.org; Thu, 31 Jul 2003 11:24:24 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19iFHu-00053e-00 for simple@ietf.org; Thu, 31 Jul 2003 11:24:24 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6VFOGG27315 for ; Thu, 31 Jul 2003 10:24:17 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 31 Jul 2003 10:24:15 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 31 Jul 2003 08:24:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] New I-D on presence states for phones Message-ID: Thread-Topic: [Simple] New I-D on presence states for phones Thread-Index: AcNXdv90B+BP4xiPRt6/WTdcQ5D02wAAGdtA To: , Cc: , , , X-OriginalArrivalTime: 31 Jul 2003 15:24:07.0672 (UTC) FILETIME=[C8B7CF80:01C35777] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 11:24:06 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable And for the SIP level handoff, you would use signal strength = indications, obtained from=20 SIP phone presence information?=20 You shouldn't stick to my L2 comment rather than to the doubt I have = that=20 a SIP event based notification on signal strength would suffice to do = handover control. Dirk >-----Original Message----- >From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] >Sent: Thursday, July 31, 2003 11:17 AM >To: 'Henning Schulzrinne'; Trossen Dirk (NRC/Boston) >Cc: usama.mansoor@rd.francetelecom.com; jdrosen@dynamicsoft.com; >vikas@arciis.com; simple@ietf.org >Subject: RE: [Simple] New I-D on presence states for phones > > >I think you are dreaming, > >There are TWO networks, and they are not usually under the same >administrative control. If you have a call up, >to do a handoff, you will need to do it at the SIP level. >It's not something the L2 is going to do. L2 handoff would >only work if both networks were in the same administrative >domain.=20 > >Brian > > > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Thursday, July 31, 2003 10:53 AM >> To: Dirk.Trossen@nokia.com >> Cc: usama.mansoor@rd.francetelecom.com; jdrosen@dynamicsoft.com; >> vikas@arciis.com; simple@ietf.org >> Subject: Re: [Simple] New I-D on presence states for phones >>=20 >>=20 >> Dirk.Trossen@nokia.com wrote: >>=20 >> >>One possible application for signal strength would be if=20 >you want to >> >>hand over from Wi-Fi to cellular and back again, and having=20 >> >>the handover >> >>triggered according to the signal strength on the two=20 >> network types.=20 >> >=20 >> >=20 >> > I strongly hope you are not suggesting handover control=20 >> based on SIP presence >> > based signal strength. There are appropriate L2 mechanisms=20 >> doing this in real-time=20 >> > rather well. I do not see this as a real application example. >> >=20 >> Also, comparing signal strengths in the two different=20 >> networks is rather=20 >> like comparing apples and oranges... >>=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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 31 11:27:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01634; Thu, 31 Jul 2003 11:27:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFKr-00055k-00; Thu, 31 Jul 2003 11:27:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iFKq-00055g-00; Thu, 31 Jul 2003 11:27:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFJY-0006Qq-SW; Thu, 31 Jul 2003 11:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFJF-0006OF-LS for simple@optimus.ietf.org; Thu, 31 Jul 2003 11:25:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01557 for ; Thu, 31 Jul 2003 11:25:37 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFJE-00054n-00 for simple@ietf.org; Thu, 31 Jul 2003 11:25:40 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19iFJD-00054k-00 for simple@ietf.org; Thu, 31 Jul 2003 11:25:39 -0400 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6VFPdG27600 for ; Thu, 31 Jul 2003 10:25:39 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 31 Jul 2003 10:25:38 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 31 Jul 2003 08:24:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt Message-ID: Thread-Topic: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt Thread-Index: AcNXdm+j8L9JGNknTGmpRgYRBuVkqgAACjHg To: , Cc: , , X-OriginalArrivalTime: 31 Jul 2003 15:24:55.0173 (UTC) FILETIME=[E507E350:01C35777] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 11:24:53 -0400 Content-Transfer-Encoding: quoted-printable Hi, what confuses me about Jonathan's "type of phone" that the examples = represent a variety of=20 different "types" that are not even necessarily related to each other. = Specifically, how does "home vs. wireless vs. business" relate to each other? What constitutes = a "type of phone"?=20 Its ownership (home vs. business)? Its usage (private vs. business)? Its = connectivity (wired vs. wireless)?=20 Dirk >-----Original Message----- >From: ext Alex Audu [mailto:alex.audu@alcatel.com] >Sent: Thursday, July 31, 2003 11:12 AM >To: Jonathan Rosenberg >Cc: Paul Kyzivat; jon.peterson@neustar.biz; simple@ietf.org >Subject: Re: [Simple] Re: >draft-rosenberg-peterson-simple-pidf-phone-00.txt > > >Jonathan, > >I think I'll agree with Paul on the issue that a watcher could=20 >care less about >the >type of device on the other end. Frankly, all we should care=20 >about is the >service >type. The device type has no value (in my mind). New devices=20 >that provide >telephony/IM services are coming to the market almost daily.=20 >And of course, >lets >not forget softphones which can be staged on any computing device. > >Regards, >Alex. > >Jonathan Rosenberg wrote: > >> Thanks for the comments. Responses inline. >> >> Paul Kyzivat wrote: >> >> > I think representing states appropriate to a phone is a=20 >good idea. But I >> > have serious problems with the details of this draft: >> > >> > - multiple ways of representing equivalent state >> > >> > Typically a watcher is likely to care less what kind of=20 >phone you have, >> > and simply want to know if you are available for a call=20 >and/or are in a >> > call. Having to decipher three different representations=20 >of this same >> > information is a needless hassle. >> >> I think a watcher may want to know what type of phone you have - >> knowing that its home vs. wireless vs. business is useful presence >> information in itself, I believe. >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 31 11:27:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01685 for ; Thu, 31 Jul 2003 11:27:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFKt-0006XU-5u for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 11:27:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VFRNRI025132 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 11:27:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFKt-0006XH-2r for simple-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 11:27:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01636; Thu, 31 Jul 2003 11:27:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFKr-00055n-00; Thu, 31 Jul 2003 11:27:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iFKq-00055h-00; Thu, 31 Jul 2003 11:27:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFJY-0006Ow-Cr; Thu, 31 Jul 2003 11:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF9D-0005nM-Fd for simple@optimus.ietf.org; Thu, 31 Jul 2003 11:15:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01157 for ; Thu, 31 Jul 2003 11:15:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iF9C-0004zH-00 for simple@ietf.org; Thu, 31 Jul 2003 11:15:18 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 19iF9B-0004z0-00 for simple@ietf.org; Thu, 31 Jul 2003 11:15:17 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 31 Jul 2003 17:14:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] New I-D on presence states for phones Message-ID: Thread-Topic: [Simple] New I-D on presence states for phones Thread-Index: AcNXc4DR8apztOPGR++5IBFl+XH3MQAAPxuw From: "MANSOOR Usama FTRD/DMR/LON" To: "Henning Schulzrinne" , Cc: , , X-OriginalArrivalTime: 31 Jul 2003 15:14:31.0652 (UTC) FILETIME=[71622240:01C35776] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 17:14:27 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Yes, agreed, using it to hand over for proper voice calls, video calls, etc. is not the best way of doing that.=20 What I was thinking of was more for data transfers (e.g. peer-to-peer, file transfer, one way streaming video, etc.), where it might be better to use the higher bandwidth wi-fi if you can. In this case the acutal value of the signal strength is not important, it's whether wi-fi is available or not.=20 But if people think it's an unlikely scenario, then I guess there is no need for a signal strength attribute.=20 -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, July 31, 2003 3:53 PM To: Dirk.Trossen@nokia.com Cc: MANSOOR Usama FTRD/DMR/LON; jdrosen@dynamicsoft.com; vikas@arciis.com; simple@ietf.org Subject: Re: [Simple] New I-D on presence states for phones Dirk.Trossen@nokia.com wrote: >>One possible application for signal strength would be if you want to >>hand over from Wi-Fi to cellular and back again, and having=20 >>the handover >>triggered according to the signal strength on the two network types.=20 >=20 >=20 > I strongly hope you are not suggesting handover control based on SIP presence > based signal strength. There are appropriate L2 mechanisms doing this in real-time=20 > rather well. I do not see this as a real application example. >=20 Also, comparing signal strengths in the two different networks is rather like comparing apples and oranges... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 31 11:27:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01687 for ; Thu, 31 Jul 2003 11:27:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFKt-0006Xo-DS for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 11:27:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VFRNIG025150 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 11:27:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFKt-0006XY-80 for simple-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 11:27:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01634; Thu, 31 Jul 2003 11:27:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFKr-00055k-00; Thu, 31 Jul 2003 11:27:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iFKq-00055g-00; Thu, 31 Jul 2003 11:27:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFJY-0006Qq-SW; Thu, 31 Jul 2003 11:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFJF-0006OF-LS for simple@optimus.ietf.org; Thu, 31 Jul 2003 11:25:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01557 for ; Thu, 31 Jul 2003 11:25:37 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFJE-00054n-00 for simple@ietf.org; Thu, 31 Jul 2003 11:25:40 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19iFJD-00054k-00 for simple@ietf.org; Thu, 31 Jul 2003 11:25:39 -0400 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6VFPdG27600 for ; Thu, 31 Jul 2003 10:25:39 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 31 Jul 2003 10:25:38 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 31 Jul 2003 08:24:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt Message-ID: Thread-Topic: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt Thread-Index: AcNXdm+j8L9JGNknTGmpRgYRBuVkqgAACjHg To: , Cc: , , X-OriginalArrivalTime: 31 Jul 2003 15:24:55.0173 (UTC) FILETIME=[E507E350:01C35777] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 11:24:53 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, what confuses me about Jonathan's "type of phone" that the examples = represent a variety of=20 different "types" that are not even necessarily related to each other. = Specifically, how does "home vs. wireless vs. business" relate to each other? What constitutes = a "type of phone"?=20 Its ownership (home vs. business)? Its usage (private vs. business)? Its = connectivity (wired vs. wireless)?=20 Dirk >-----Original Message----- >From: ext Alex Audu [mailto:alex.audu@alcatel.com] >Sent: Thursday, July 31, 2003 11:12 AM >To: Jonathan Rosenberg >Cc: Paul Kyzivat; jon.peterson@neustar.biz; simple@ietf.org >Subject: Re: [Simple] Re: >draft-rosenberg-peterson-simple-pidf-phone-00.txt > > >Jonathan, > >I think I'll agree with Paul on the issue that a watcher could=20 >care less about >the >type of device on the other end. Frankly, all we should care=20 >about is the >service >type. The device type has no value (in my mind). New devices=20 >that provide >telephony/IM services are coming to the market almost daily.=20 >And of course, >lets >not forget softphones which can be staged on any computing device. > >Regards, >Alex. > >Jonathan Rosenberg wrote: > >> Thanks for the comments. Responses inline. >> >> Paul Kyzivat wrote: >> >> > I think representing states appropriate to a phone is a=20 >good idea. But I >> > have serious problems with the details of this draft: >> > >> > - multiple ways of representing equivalent state >> > >> > Typically a watcher is likely to care less what kind of=20 >phone you have, >> > and simply want to know if you are available for a call=20 >and/or are in a >> > call. Having to decipher three different representations=20 >of this same >> > information is a needless hassle. >> >> I think a watcher may want to know what type of phone you have - >> knowing that its home vs. wireless vs. business is useful presence >> information in itself, I believe. >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 31 11:42:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02096; Thu, 31 Jul 2003 11:42:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFZQ-0005Cx-00; Thu, 31 Jul 2003 11:42:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iFZQ-0005Cu-00; Thu, 31 Jul 2003 11:42:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFY6-0007VP-Bt; Thu, 31 Jul 2003 11:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFXh-0007SC-2a for simple@optimus.ietf.org; Thu, 31 Jul 2003 11:40:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02008 for ; Thu, 31 Jul 2003 11:40:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFXf-0005Bo-00 for simple@ietf.org; Thu, 31 Jul 2003 11:40:36 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19iFXf-0005BL-00 for simple@ietf.org; Thu, 31 Jul 2003 11:40:35 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA00313; Thu, 31 Jul 2003 11:40:03 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27764; Thu, 31 Jul 2003 11:40:03 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 11:40:03 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5C98@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dirk.Trossen@nokia.com'" , hgs@cs.columbia.edu Cc: usama.mansoor@rd.francetelecom.com, jdrosen@dynamicsoft.com, vikas@arciis.com, simple@ietf.org Subject: RE: [Simple] New I-D on presence states for phones MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 11:40:02 -0400 I dunno. It's all in how much work you want to do in the phone. I'd personally be inclined to have the phone decide, in which case signal strength may not be very interesting, but YMMV. I'm not really convinced of the value of signal strength in presence. It might be useful, but I doubt it. Brian > -----Original Message----- > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > Sent: Thursday, July 31, 2003 11:24 AM > To: Brian.Rosen@marconi.com; hgs@cs.columbia.edu > Cc: usama.mansoor@rd.francetelecom.com; jdrosen@dynamicsoft.com; > vikas@arciis.com; simple@ietf.org > Subject: RE: [Simple] New I-D on presence states for phones > > > And for the SIP level handoff, you would use signal strength > indications, obtained from > SIP phone presence information? > > You shouldn't stick to my L2 comment rather than to the doubt > I have that > a SIP event based notification on signal strength would > suffice to do handover control. > > Dirk > > >-----Original Message----- > >From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > >Sent: Thursday, July 31, 2003 11:17 AM > >To: 'Henning Schulzrinne'; Trossen Dirk (NRC/Boston) > >Cc: usama.mansoor@rd.francetelecom.com; jdrosen@dynamicsoft.com; > >vikas@arciis.com; simple@ietf.org > >Subject: RE: [Simple] New I-D on presence states for phones > > > > > >I think you are dreaming, > > > >There are TWO networks, and they are not usually under the same > >administrative control. If you have a call up, > >to do a handoff, you will need to do it at the SIP level. > >It's not something the L2 is going to do. L2 handoff would > >only work if both networks were in the same administrative > >domain. > > > >Brian > > > > > > > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> Sent: Thursday, July 31, 2003 10:53 AM > >> To: Dirk.Trossen@nokia.com > >> Cc: usama.mansoor@rd.francetelecom.com; jdrosen@dynamicsoft.com; > >> vikas@arciis.com; simple@ietf.org > >> Subject: Re: [Simple] New I-D on presence states for phones > >> > >> > >> Dirk.Trossen@nokia.com wrote: > >> > >> >>One possible application for signal strength would be if > >you want to > >> >>hand over from Wi-Fi to cellular and back again, and having > >> >>the handover > >> >>triggered according to the signal strength on the two > >> network types. > >> > > >> > > >> > I strongly hope you are not suggesting handover control > >> based on SIP presence > >> > based signal strength. There are appropriate L2 mechanisms > >> doing this in real-time > >> > rather well. I do not see this as a real application example. > >> > > >> Also, comparing signal strengths in the two different > >> networks is rather > >> like comparing apples and oranges... > >> > >> > >> _______________________________________________ > >> 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 exim@www1.ietf.org Thu Jul 31 11:42:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02119 for ; Thu, 31 Jul 2003 11:42:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFZS-0007ct-N0 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 11:42:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VFgQKM029311 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 11:42:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFZS-0007cg-Jt for simple-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 11:42:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02096; Thu, 31 Jul 2003 11:42:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFZQ-0005Cx-00; Thu, 31 Jul 2003 11:42:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iFZQ-0005Cu-00; Thu, 31 Jul 2003 11:42:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFY6-0007VP-Bt; Thu, 31 Jul 2003 11:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFXh-0007SC-2a for simple@optimus.ietf.org; Thu, 31 Jul 2003 11:40:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02008 for ; Thu, 31 Jul 2003 11:40:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFXf-0005Bo-00 for simple@ietf.org; Thu, 31 Jul 2003 11:40:36 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19iFXf-0005BL-00 for simple@ietf.org; Thu, 31 Jul 2003 11:40:35 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA00313; Thu, 31 Jul 2003 11:40:03 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27764; Thu, 31 Jul 2003 11:40:03 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 11:40:03 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5C98@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dirk.Trossen@nokia.com'" , hgs@cs.columbia.edu Cc: usama.mansoor@rd.francetelecom.com, jdrosen@dynamicsoft.com, vikas@arciis.com, simple@ietf.org Subject: RE: [Simple] New I-D on presence states for phones MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 11:40:02 -0400 I dunno. It's all in how much work you want to do in the phone. I'd personally be inclined to have the phone decide, in which case signal strength may not be very interesting, but YMMV. I'm not really convinced of the value of signal strength in presence. It might be useful, but I doubt it. Brian > -----Original Message----- > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > Sent: Thursday, July 31, 2003 11:24 AM > To: Brian.Rosen@marconi.com; hgs@cs.columbia.edu > Cc: usama.mansoor@rd.francetelecom.com; jdrosen@dynamicsoft.com; > vikas@arciis.com; simple@ietf.org > Subject: RE: [Simple] New I-D on presence states for phones > > > And for the SIP level handoff, you would use signal strength > indications, obtained from > SIP phone presence information? > > You shouldn't stick to my L2 comment rather than to the doubt > I have that > a SIP event based notification on signal strength would > suffice to do handover control. > > Dirk > > >-----Original Message----- > >From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > >Sent: Thursday, July 31, 2003 11:17 AM > >To: 'Henning Schulzrinne'; Trossen Dirk (NRC/Boston) > >Cc: usama.mansoor@rd.francetelecom.com; jdrosen@dynamicsoft.com; > >vikas@arciis.com; simple@ietf.org > >Subject: RE: [Simple] New I-D on presence states for phones > > > > > >I think you are dreaming, > > > >There are TWO networks, and they are not usually under the same > >administrative control. If you have a call up, > >to do a handoff, you will need to do it at the SIP level. > >It's not something the L2 is going to do. L2 handoff would > >only work if both networks were in the same administrative > >domain. > > > >Brian > > > > > > > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> Sent: Thursday, July 31, 2003 10:53 AM > >> To: Dirk.Trossen@nokia.com > >> Cc: usama.mansoor@rd.francetelecom.com; jdrosen@dynamicsoft.com; > >> vikas@arciis.com; simple@ietf.org > >> Subject: Re: [Simple] New I-D on presence states for phones > >> > >> > >> Dirk.Trossen@nokia.com wrote: > >> > >> >>One possible application for signal strength would be if > >you want to > >> >>hand over from Wi-Fi to cellular and back again, and having > >> >>the handover > >> >>triggered according to the signal strength on the two > >> network types. > >> > > >> > > >> > I strongly hope you are not suggesting handover control > >> based on SIP presence > >> > based signal strength. There are appropriate L2 mechanisms > >> doing this in real-time > >> > rather well. I do not see this as a real application example. > >> > > >> Also, comparing signal strengths in the two different > >> networks is rather > >> like comparing apples and oranges... > >> > >> > >> _______________________________________________ > >> 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-admin@ietf.org Thu Jul 31 12:14:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01636; Thu, 31 Jul 2003 11:27:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFKr-00055n-00; Thu, 31 Jul 2003 11:27:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iFKq-00055h-00; Thu, 31 Jul 2003 11:27:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFJY-0006Ow-Cr; Thu, 31 Jul 2003 11:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF9D-0005nM-Fd for simple@optimus.ietf.org; Thu, 31 Jul 2003 11:15:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01157 for ; Thu, 31 Jul 2003 11:15:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iF9C-0004zH-00 for simple@ietf.org; Thu, 31 Jul 2003 11:15:18 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 19iF9B-0004z0-00 for simple@ietf.org; Thu, 31 Jul 2003 11:15:17 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 31 Jul 2003 17:14:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] New I-D on presence states for phones Message-ID: Thread-Topic: [Simple] New I-D on presence states for phones Thread-Index: AcNXc4DR8apztOPGR++5IBFl+XH3MQAAPxuw From: "MANSOOR Usama FTRD/DMR/LON" To: "Henning Schulzrinne" , Cc: , , X-OriginalArrivalTime: 31 Jul 2003 15:14:31.0652 (UTC) FILETIME=[71622240:01C35776] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 17:14:27 +0200 Content-Transfer-Encoding: quoted-printable Yes, agreed, using it to hand over for proper voice calls, video calls, etc. is not the best way of doing that.=20 What I was thinking of was more for data transfers (e.g. peer-to-peer, file transfer, one way streaming video, etc.), where it might be better to use the higher bandwidth wi-fi if you can. In this case the acutal value of the signal strength is not important, it's whether wi-fi is available or not.=20 But if people think it's an unlikely scenario, then I guess there is no need for a signal strength attribute.=20 -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, July 31, 2003 3:53 PM To: Dirk.Trossen@nokia.com Cc: MANSOOR Usama FTRD/DMR/LON; jdrosen@dynamicsoft.com; vikas@arciis.com; simple@ietf.org Subject: Re: [Simple] New I-D on presence states for phones Dirk.Trossen@nokia.com wrote: >>One possible application for signal strength would be if you want to >>hand over from Wi-Fi to cellular and back again, and having=20 >>the handover >>triggered according to the signal strength on the two network types.=20 >=20 >=20 > I strongly hope you are not suggesting handover control based on SIP presence > based signal strength. There are appropriate L2 mechanisms doing this in real-time=20 > rather well. I do not see this as a real application example. >=20 Also, comparing signal strengths in the two different networks is rather like comparing apples and oranges... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 31 12:27:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03310; Thu, 31 Jul 2003 12:27:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGGv-0005Vg-00; Thu, 31 Jul 2003 12:27:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iGGv-0005Vd-00; Thu, 31 Jul 2003 12:27:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGFd-0001B4-EC; Thu, 31 Jul 2003 12:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGEj-00019N-PL for simple@optimus.ietf.org; Thu, 31 Jul 2003 12:25:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03255 for ; Thu, 31 Jul 2003 12:25:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGEi-0005V5-00 for simple@ietf.org; Thu, 31 Jul 2003 12:25:04 -0400 Received: from almso2.att.com ([192.128.166.71] helo=almso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 19iGEh-0005Uu-00 for simple@ietf.org; Thu, 31 Jul 2003 12:25:03 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h6VGKRPt006770 for ; Thu, 31 Jul 2003 12:24:32 -0400 Received: from acclust02evs1.ugd.att.com (135.37.16.9) by attrh0i.attrh.att.com (6.5.032) id 3F08489B0059514F; Thu, 31 Jul 2003 12:23:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] New I-D on presence states for phones Message-ID: <34DA635B184A644DA4588E260EC0A25A0487BD70@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Simple] New I-D on presence states for phones Thread-Index: AcNXesD+nrYq+ebxQtWnEjGeP1JHygABKhiA From: "Roy, Radhika R, ALABS" To: "Rosen, Brian" , "Henning Schulzrinne" , Cc: , , , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 12:24:28 -0400 Content-Transfer-Encoding: quoted-printable Inline [RRR] -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Thursday, July 31, 2003 11:17 AM To: 'Henning Schulzrinne'; Dirk.Trossen@nokia.com Cc: usama.mansoor@rd.francetelecom.com; jdrosen@dynamicsoft.com; vikas@arciis.com; simple@ietf.org Subject: RE: [Simple] New I-D on presence states for phones I think you are dreaming, There are TWO networks, and they are not usually under the same administrative control. If you have a call up, to do a handoff, you will need to do it at the SIP level. It's not something the L2 is going to do. L2 handoff would only work if both networks were in the same administrative domain.=20 [RRR] Right. When the impact of handoff (i.e., change in attachment) = affects the upper application layer (e.g., SIP), more works need to be = done in the application layer (e.g., SIP) for mobility management = (signaling and media) in addition to the lower layer. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 31 12:27:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03339 for ; Thu, 31 Jul 2003 12:27:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGGx-0001N4-MD for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 12:27:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VGRNWs005264 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 12:27:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGGx-0001Mp-Iz for simple-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 12:27:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03310; Thu, 31 Jul 2003 12:27:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGGv-0005Vg-00; Thu, 31 Jul 2003 12:27:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iGGv-0005Vd-00; Thu, 31 Jul 2003 12:27:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGFd-0001B4-EC; Thu, 31 Jul 2003 12:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGEj-00019N-PL for simple@optimus.ietf.org; Thu, 31 Jul 2003 12:25:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03255 for ; Thu, 31 Jul 2003 12:25:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGEi-0005V5-00 for simple@ietf.org; Thu, 31 Jul 2003 12:25:04 -0400 Received: from almso2.att.com ([192.128.166.71] helo=almso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 19iGEh-0005Uu-00 for simple@ietf.org; Thu, 31 Jul 2003 12:25:03 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h6VGKRPt006770 for ; Thu, 31 Jul 2003 12:24:32 -0400 Received: from acclust02evs1.ugd.att.com (135.37.16.9) by attrh0i.attrh.att.com (6.5.032) id 3F08489B0059514F; Thu, 31 Jul 2003 12:23:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] New I-D on presence states for phones Message-ID: <34DA635B184A644DA4588E260EC0A25A0487BD70@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Simple] New I-D on presence states for phones Thread-Index: AcNXesD+nrYq+ebxQtWnEjGeP1JHygABKhiA From: "Roy, Radhika R, ALABS" To: "Rosen, Brian" , "Henning Schulzrinne" , Cc: , , , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 12:24:28 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Inline [RRR] -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Thursday, July 31, 2003 11:17 AM To: 'Henning Schulzrinne'; Dirk.Trossen@nokia.com Cc: usama.mansoor@rd.francetelecom.com; jdrosen@dynamicsoft.com; vikas@arciis.com; simple@ietf.org Subject: RE: [Simple] New I-D on presence states for phones I think you are dreaming, There are TWO networks, and they are not usually under the same administrative control. If you have a call up, to do a handoff, you will need to do it at the SIP level. It's not something the L2 is going to do. L2 handoff would only work if both networks were in the same administrative domain.=20 [RRR] Right. When the impact of handoff (i.e., change in attachment) = affects the upper application layer (e.g., SIP), more works need to be = done in the application layer (e.g., SIP) for mobility management = (signaling and media) in addition to the lower layer. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 31 14:08:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06671; Thu, 31 Jul 2003 14:08:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iHqw-0006FX-00; Thu, 31 Jul 2003 14:08:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iHqw-0006FU-00; Thu, 31 Jul 2003 14:08:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iHqK-0006I9-ON; Thu, 31 Jul 2003 14:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iHq7-0006Fv-TQ for simple@optimus.ietf.org; Thu, 31 Jul 2003 14:07:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06624 for ; Thu, 31 Jul 2003 14:07:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iHq5-0006Ec-00 for simple@ietf.org; Thu, 31 Jul 2003 14:07:45 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iHq3-0006EP-00 for simple@ietf.org; Thu, 31 Jul 2003 14:07:43 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6VI6iLd008291; Thu, 31 Jul 2003 11:07:11 -0700 (PDT) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABD48478; Thu, 31 Jul 2003 14:06:40 -0400 (EDT) Message-ID: <3F295AB0.3000107@cisco.com> 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 CC: Jonathan Rosenberg , jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt References: <200306261203.IAA16528@ietf.org> <3F16C405.3020900@cisco.com> <3F2840B4.5030202@dynamicsoft.com> <3F287503.1050505@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 14:06:40 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > >> Perhaps a better way to deal with this is to indicate that there >> exists another call in progress, or perhaps an indication of how many >> calls are in progress (useful for call routing to customer support >> operators perhaps?). [note: "this" above referred to representations of "lines" currently in use.] > Only if the presentity is a group, not an individual, I'd think. I disagree, though it may also apply in that case. The use case was when the presentity is already on the phone, but has call waiting, or has a phone that can otherwise support multiple "calls" per "line". The user may not be able to talk to multiple calls at the same time, but still may accept and switch among them, with the extra ones on hold. So the point is that being on-the-phone isn't mutually exclusive with being able to accept a call. Both pieces of information (being on-the-phone and ability to take a call) are useful presence status. When on-the-phone, it might also be useful to know how many active calls there are. >>> - a representation for a call. This would subsume your call-state, >>> but omitting the not-in-call state. But it would also be extensible >>> for other call attributes. This can be repeated as many times as >>> needed to represent calls in progress, not lines. (This clearly >>> overlaps with the dialog package - something worth discussing. It >>> provides extra information in that it can show a call before a dialog >>> is established. And with further extension it might provide a way to >>> represent calls on hold, if we can figure out what that means.) > > One of the questions is whether this or dialog state is the right model > for directed call pickup. If I can subscribe to another user's phone and > get the Call-ID and other identifying information, I can then pick up > the call via REFER. I suspect that dialog-package is the better one, but > one of them should be made to work for that... For directed call pickup I think you point is valid. I certainly don't think that is the only purpose of this information. I think one way to draw a line is to decide what is needed to maintain a presence status display - say of a buddy list. Everything you need to display the presence of a buddy should be included in the presence document. It is highly undesirable to have to subscribe to other event packages for each buddy, or send OPTIONS requests, or whatever, on a coninual basis. OTOH, I think its ok if there is stuff you need to query for after making a decision to use a particular tuple. >>> - optional ran, roaming, visited-network, signal-strength attributes. >>> (Assuming you think these make sense to provide at all.) These could >>> be grouped under a mobile attribute or left standalone. >> >> I dont think they can be in a single mobile attribute, there is a >> bunch of separate information here. > > I am dubious on 'roaming'. This can mean many different things and > nothing at all. Without having detailed knowledge of the presentity's > carrier subscription and its coverage, it says essentially nothing. (In > NJ, the pin-drop carrier can make you roam into analog just a few miles > west on Rt. 4, as that's the border of digital coverage, so this says > nothing about distance from home.) Also, are there currently any > interfaces that would allow you to retrieve this information? I agree. I would much rather have some kind of specific information that can be used in a well defined way to decide whether to contact this endpoint. For instance, if roaming is going to affect how much it costs me to call, then the specific info that permits my UA to make the cost computation would be helpful. Similarly if it affects how the callee will be charged and I might care to minimize (or maximize that). If this is simply about being away from home then I think this is inappropriate, and geoloc or one of the other attributes should be used instead. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 31 14:09:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06714 for ; Thu, 31 Jul 2003 14:09:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iHqz-0006M2-NQ for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 14:08:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VI8fwJ024422 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 14:08:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iHqz-0006Lp-KX for simple-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 14:08:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06671; Thu, 31 Jul 2003 14:08:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iHqw-0006FX-00; Thu, 31 Jul 2003 14:08:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iHqw-0006FU-00; Thu, 31 Jul 2003 14:08:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iHqK-0006I9-ON; Thu, 31 Jul 2003 14:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iHq7-0006Fv-TQ for simple@optimus.ietf.org; Thu, 31 Jul 2003 14:07:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06624 for ; Thu, 31 Jul 2003 14:07:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iHq5-0006Ec-00 for simple@ietf.org; Thu, 31 Jul 2003 14:07:45 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iHq3-0006EP-00 for simple@ietf.org; Thu, 31 Jul 2003 14:07:43 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6VI6iLd008291; Thu, 31 Jul 2003 11:07:11 -0700 (PDT) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABD48478; Thu, 31 Jul 2003 14:06:40 -0400 (EDT) Message-ID: <3F295AB0.3000107@cisco.com> 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 CC: Jonathan Rosenberg , jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt References: <200306261203.IAA16528@ietf.org> <3F16C405.3020900@cisco.com> <3F2840B4.5030202@dynamicsoft.com> <3F287503.1050505@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 14:06:40 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > >> Perhaps a better way to deal with this is to indicate that there >> exists another call in progress, or perhaps an indication of how many >> calls are in progress (useful for call routing to customer support >> operators perhaps?). [note: "this" above referred to representations of "lines" currently in use.] > Only if the presentity is a group, not an individual, I'd think. I disagree, though it may also apply in that case. The use case was when the presentity is already on the phone, but has call waiting, or has a phone that can otherwise support multiple "calls" per "line". The user may not be able to talk to multiple calls at the same time, but still may accept and switch among them, with the extra ones on hold. So the point is that being on-the-phone isn't mutually exclusive with being able to accept a call. Both pieces of information (being on-the-phone and ability to take a call) are useful presence status. When on-the-phone, it might also be useful to know how many active calls there are. >>> - a representation for a call. This would subsume your call-state, >>> but omitting the not-in-call state. But it would also be extensible >>> for other call attributes. This can be repeated as many times as >>> needed to represent calls in progress, not lines. (This clearly >>> overlaps with the dialog package - something worth discussing. It >>> provides extra information in that it can show a call before a dialog >>> is established. And with further extension it might provide a way to >>> represent calls on hold, if we can figure out what that means.) > > One of the questions is whether this or dialog state is the right model > for directed call pickup. If I can subscribe to another user's phone and > get the Call-ID and other identifying information, I can then pick up > the call via REFER. I suspect that dialog-package is the better one, but > one of them should be made to work for that... For directed call pickup I think you point is valid. I certainly don't think that is the only purpose of this information. I think one way to draw a line is to decide what is needed to maintain a presence status display - say of a buddy list. Everything you need to display the presence of a buddy should be included in the presence document. It is highly undesirable to have to subscribe to other event packages for each buddy, or send OPTIONS requests, or whatever, on a coninual basis. OTOH, I think its ok if there is stuff you need to query for after making a decision to use a particular tuple. >>> - optional ran, roaming, visited-network, signal-strength attributes. >>> (Assuming you think these make sense to provide at all.) These could >>> be grouped under a mobile attribute or left standalone. >> >> I dont think they can be in a single mobile attribute, there is a >> bunch of separate information here. > > I am dubious on 'roaming'. This can mean many different things and > nothing at all. Without having detailed knowledge of the presentity's > carrier subscription and its coverage, it says essentially nothing. (In > NJ, the pin-drop carrier can make you roam into analog just a few miles > west on Rt. 4, as that's the border of digital coverage, so this says > nothing about distance from home.) Also, are there currently any > interfaces that would allow you to retrieve this information? I agree. I would much rather have some kind of specific information that can be used in a well defined way to decide whether to contact this endpoint. For instance, if roaming is going to affect how much it costs me to call, then the specific info that permits my UA to make the cost computation would be helpful. Similarly if it affects how the callee will be charged and I might care to minimize (or maximize that). If this is simply about being away from home then I think this is inappropriate, and geoloc or one of the other attributes should be used instead. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 31 18:23:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17206; Thu, 31 Jul 2003 18:23:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iLpF-0000Ly-00; Thu, 31 Jul 2003 18:23:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iLpF-0000Lv-00; Thu, 31 Jul 2003 18:23:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iLp7-0008DP-6N; Thu, 31 Jul 2003 18:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iLoY-0008D9-8D for simple@optimus.ietf.org; Thu, 31 Jul 2003 18:22:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17203 for ; Thu, 31 Jul 2003 18:22:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iLoU-0000Ln-00 for simple@ietf.org; Thu, 31 Jul 2003 18:22:22 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19iLoS-0000LT-00 for simple@ietf.org; Thu, 31 Jul 2003 18:22:21 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6VMLK6Y005045; Thu, 31 Jul 2003 18:21:22 -0400 (EDT) Message-ID: <3F29965E.8000702@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Henning Schulzrinne , jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt References: <200306261203.IAA16528@ietf.org> <3F16C405.3020900@cisco.com> <3F2840B4.5030202@dynamicsoft.com> <3F287503.1050505@cs.columbia.edu> <3F295AB0.3000107@cisco.com> In-Reply-To: <3F295AB0.3000107@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 18:21:18 -0400 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > > > Henning Schulzrinne wrote: > >> >>> Perhaps a better way to deal with this is to indicate that there >>> exists another call in progress, or perhaps an indication of how many >>> calls are in progress (useful for call routing to customer support >>> operators perhaps?). > > > [note: "this" above referred to representations of "lines" currently in > use.] > >> Only if the presentity is a group, not an individual, I'd think. > > > I disagree, though it may also apply in that case. The use case was when > the presentity is already on the phone, but has call waiting, or has a > phone that can otherwise support multiple "calls" per "line". The user > may not be able to talk to multiple calls at the same time, but still > may accept and switch among them, with the extra ones on hold. > > So the point is that being on-the-phone isn't mutually exclusive with > being able to accept a call. Both pieces of information (being > on-the-phone and ability to take a call) are useful presence status. > When on-the-phone, it might also be useful to know how many active calls > there are. I agree. My example of a call center rep is also referring to a presentity that is one person, but that can handle multiple calls at once. > >>>> - a representation for a call. This would subsume your call-state, >>>> but omitting the not-in-call state. But it would also be extensible >>>> for other call attributes. This can be repeated as many times as >>>> needed to represent calls in progress, not lines. (This clearly >>>> overlaps with the dialog package - something worth discussing. It >>>> provides extra information in that it can show a call before a >>>> dialog is established. And with further extension it might provide a >>>> way to represent calls on hold, if we can figure out what that means.) >> >> >> One of the questions is whether this or dialog state is the right >> model for directed call pickup. If I can subscribe to another user's >> phone and get the Call-ID and other identifying information, I can >> then pick up the call via REFER. I suspect that dialog-package is the >> better one, but one of them should be made to work for that... > > > For directed call pickup I think you point is valid. I certainly don't > think that is the only purpose of this information. > > I think one way to draw a line is to decide what is needed to maintain a > presence status display - say of a buddy list. Everything you need to > display the presence of a buddy should be included in the presence > document. It is highly undesirable to have to subscribe to other event > packages for each buddy, or send OPTIONS requests, or whatever, on a > coninual basis. > > OTOH, I think its ok if there is stuff you need to query for after > making a decision to use a particular tuple. I don't think that directed call pickup is really a "presence" application though. The way to tell is whether information beyond dialog state is useful for it. In the case of ringback, for example, I think it is a presence application. Its useful to know that you are truly available, as opposed to just no longer in a dialog. Not so for directed pickup (unless you have a different service definition in mind than I do). > >>>> - optional ran, roaming, visited-network, signal-strength >>>> attributes. (Assuming you think these make sense to provide at all.) >>>> These could be grouped under a mobile attribute or left standalone. >>> >>> >>> I dont think they can be in a single mobile attribute, there is a >>> bunch of separate information here. >> >> >> I am dubious on 'roaming'. This can mean many different things and >> nothing at all. Without having detailed knowledge of the presentity's >> carrier subscription and its coverage, it says essentially nothing. >> (In NJ, the pin-drop carrier can make you roam into analog just a few >> miles west on Rt. 4, as that's the border of digital coverage, so this >> says nothing about distance from home.) Also, are there currently any >> interfaces that would allow you to retrieve this information? > > > I agree. I would much rather have some kind of specific information that > can be used in a well defined way to decide whether to contact this > endpoint. For instance, if roaming is going to affect how much it costs > me to call, then the specific info that permits my UA to make the cost > computation would be helpful. Similarly if it affects how the callee > will be charged and I might care to minimize (or maximize that). > > If this is simply about being away from home then I think this is > inappropriate, and geoloc or one of the other attributes should be used > instead. OK, I will agree with all of this. The real information I was after with roaming is geoloc. Cost is another potential derived piece of information, and I agree its better to represent it directly if we want to (though I think its out of scope). Unless someone can think of something else to do with the roaming flag (and I can't), I'll remove it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 31 18:23:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17226 for ; Thu, 31 Jul 2003 18:23:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iLpJ-0008Ex-Sz for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 18:23:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VMNDD7031675 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 18:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iLpJ-0008Eo-Pz for simple-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 18:23:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17206; Thu, 31 Jul 2003 18:23:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iLpF-0000Ly-00; Thu, 31 Jul 2003 18:23:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iLpF-0000Lv-00; Thu, 31 Jul 2003 18:23:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iLp7-0008DP-6N; Thu, 31 Jul 2003 18:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iLoY-0008D9-8D for simple@optimus.ietf.org; Thu, 31 Jul 2003 18:22:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17203 for ; Thu, 31 Jul 2003 18:22:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iLoU-0000Ln-00 for simple@ietf.org; Thu, 31 Jul 2003 18:22:22 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19iLoS-0000LT-00 for simple@ietf.org; Thu, 31 Jul 2003 18:22:21 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6VMLK6Y005045; Thu, 31 Jul 2003 18:21:22 -0400 (EDT) Message-ID: <3F29965E.8000702@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Henning Schulzrinne , jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt References: <200306261203.IAA16528@ietf.org> <3F16C405.3020900@cisco.com> <3F2840B4.5030202@dynamicsoft.com> <3F287503.1050505@cs.columbia.edu> <3F295AB0.3000107@cisco.com> In-Reply-To: <3F295AB0.3000107@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 18:21:18 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > > > Henning Schulzrinne wrote: > >> >>> Perhaps a better way to deal with this is to indicate that there >>> exists another call in progress, or perhaps an indication of how many >>> calls are in progress (useful for call routing to customer support >>> operators perhaps?). > > > [note: "this" above referred to representations of "lines" currently in > use.] > >> Only if the presentity is a group, not an individual, I'd think. > > > I disagree, though it may also apply in that case. The use case was when > the presentity is already on the phone, but has call waiting, or has a > phone that can otherwise support multiple "calls" per "line". The user > may not be able to talk to multiple calls at the same time, but still > may accept and switch among them, with the extra ones on hold. > > So the point is that being on-the-phone isn't mutually exclusive with > being able to accept a call. Both pieces of information (being > on-the-phone and ability to take a call) are useful presence status. > When on-the-phone, it might also be useful to know how many active calls > there are. I agree. My example of a call center rep is also referring to a presentity that is one person, but that can handle multiple calls at once. > >>>> - a representation for a call. This would subsume your call-state, >>>> but omitting the not-in-call state. But it would also be extensible >>>> for other call attributes. This can be repeated as many times as >>>> needed to represent calls in progress, not lines. (This clearly >>>> overlaps with the dialog package - something worth discussing. It >>>> provides extra information in that it can show a call before a >>>> dialog is established. And with further extension it might provide a >>>> way to represent calls on hold, if we can figure out what that means.) >> >> >> One of the questions is whether this or dialog state is the right >> model for directed call pickup. If I can subscribe to another user's >> phone and get the Call-ID and other identifying information, I can >> then pick up the call via REFER. I suspect that dialog-package is the >> better one, but one of them should be made to work for that... > > > For directed call pickup I think you point is valid. I certainly don't > think that is the only purpose of this information. > > I think one way to draw a line is to decide what is needed to maintain a > presence status display - say of a buddy list. Everything you need to > display the presence of a buddy should be included in the presence > document. It is highly undesirable to have to subscribe to other event > packages for each buddy, or send OPTIONS requests, or whatever, on a > coninual basis. > > OTOH, I think its ok if there is stuff you need to query for after > making a decision to use a particular tuple. I don't think that directed call pickup is really a "presence" application though. The way to tell is whether information beyond dialog state is useful for it. In the case of ringback, for example, I think it is a presence application. Its useful to know that you are truly available, as opposed to just no longer in a dialog. Not so for directed pickup (unless you have a different service definition in mind than I do). > >>>> - optional ran, roaming, visited-network, signal-strength >>>> attributes. (Assuming you think these make sense to provide at all.) >>>> These could be grouped under a mobile attribute or left standalone. >>> >>> >>> I dont think they can be in a single mobile attribute, there is a >>> bunch of separate information here. >> >> >> I am dubious on 'roaming'. This can mean many different things and >> nothing at all. Without having detailed knowledge of the presentity's >> carrier subscription and its coverage, it says essentially nothing. >> (In NJ, the pin-drop carrier can make you roam into analog just a few >> miles west on Rt. 4, as that's the border of digital coverage, so this >> says nothing about distance from home.) Also, are there currently any >> interfaces that would allow you to retrieve this information? > > > I agree. I would much rather have some kind of specific information that > can be used in a well defined way to decide whether to contact this > endpoint. For instance, if roaming is going to affect how much it costs > me to call, then the specific info that permits my UA to make the cost > computation would be helpful. Similarly if it affects how the callee > will be charged and I might care to minimize (or maximize that). > > If this is simply about being away from home then I think this is > inappropriate, and geoloc or one of the other attributes should be used > instead. OK, I will agree with all of this. The real information I was after with roaming is geoloc. Cost is another potential derived piece of information, and I agree its better to represent it directly if we want to (though I think its out of scope). Unless someone can think of something else to do with the roaming flag (and I can't), I'll remove it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jul 31 19:04:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18306; Thu, 31 Jul 2003 19:04:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iMSw-0000e4-00; Thu, 31 Jul 2003 19:04:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iMSw-0000e1-00; Thu, 31 Jul 2003 19:04:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iMSn-0001Rq-D1; Thu, 31 Jul 2003 19:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iMSA-0001Re-Uc for simple@optimus.ietf.org; Thu, 31 Jul 2003 19:03:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18298 for ; Thu, 31 Jul 2003 19:03:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iMS7-0000di-00 for simple@ietf.org; Thu, 31 Jul 2003 19:03:19 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iMS5-0000db-00 for simple@ietf.org; Thu, 31 Jul 2003 19:03:17 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6VN2ZPY017624; Thu, 31 Jul 2003 16:02:35 -0700 (PDT) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABD77366; Thu, 31 Jul 2003 19:02:34 -0400 (EDT) Message-ID: <3F29A00A.3030709@cisco.com> 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 CC: jon.peterson@neustar.biz, simple@ietf.org References: <200306261203.IAA16528@ietf.org> <3F16C405.3020900@cisco.com> <3F2840B4.5030202@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 19:02:34 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > >> Typically a watcher is likely to care less what kind of phone you >> have, and simply want to know if you are available for a call and/or >> are in a call. Having to decipher three different representations of >> this same information is a needless hassle. > > I think a watcher may want to know what type of phone you have - knowing > that its home vs. wireless vs. business is useful presence information > in itself, I believe. Others have brought up the problem of how can you enumerate all the types of phones. It has also been controversial in the attempt to define characteristics of a business phone. I don't think a watcher is likely to care, but who am I to say you shouldn't want to know this. As long as it is an independent piece of information that may or may not be present then I have no problem with it. But in this draft it is *necessary* to divulge what kind of phone you have in order to publish phone characteristics. That's bad. >> Also, to the caller there is no functional difference between a POTS >> phone with call waiting available, and a business phone with two >> "lines" associated to the same number with one in use and one free. In >> both cases the callee is in a call but still available for a call. >> Representing these situations differently just makes things difficult >> for the watcher. > > I think I agree with that. I should point out that our split of the doc > and schema along the device type lines was primarily to facilitate a > division of labor, not because of a fundamental belief that these needed > to be totally separated. That said, there definitely are differences in > states and infrmation between devices. I'm all for making as much common > as is possible though. Certainly there are states or attributes that some phones have and others don't. I think we can effectively deal with that in a generic way. > Perhaps a better way to deal with this is to indicate that there exists > another call in progress, or perhaps an indication of how many calls are > in progress (useful for call routing to customer support operators > perhaps?). Yes, something like that might work. That would minimize the overlap with the dialog event package. But we do need to sort out how much of the dialog package state also makes sense in presence. Offhand I can't think of a reason to include more about a call than its existence, but maybe somebody else can. Number of calls could be sensitive information, so (like ) if we go this way I think there is a requirement to leave the actual number unspecified - just indicating that it is > 0. (There might be some objections to just anybody learning how many calls are in queue to the help desk.) But lets note that this information probably belongs in RPIDS rather than here - it is in now way specific to phones. I am just as interested in how many chat sessions you are in as I am in how many phone calls you are in. And in reality we can't typically classify a call as a chat call or a voice call - its just a call that involves some assortment of media. >> - problematic extensibility model >> >> This pattern also sets the stage for more complexity in the future as >> new devices with different combinations of features hit the market. >> Suppose I come out with both home (single line) and business (multi >> line) voice/im phones. The home phone can do one voice call or one im >> call. The business phone can do two voice calls and two im calls. >> >> It isn't at all clear that I can extend any of the proposed models to >> accomodate my new phone in a graceful way. I may end up defining two >> new types for my new phones, different from these three types. Then I >> have problems with backward compatibility. > > I'm not sure I see the specific problem here - is it because your phones > can do IM also, and none of the phone types in the doc discuss IM? Yes. Although that is just an example. > If this is the case, I would argue that it comes back to a > service/device view. The current draft doesnt separate the two. Many > aspects of the draft refer to a service view, where the service is > telephony. Others refer to the device view - things such as access > network and signal strength (which I agree should be booted) are device > properties that span services. For example, IM and PTT may also run on > the phone, and things like signal strength would affect all of them. > > So, if I have a device as you describe, I could present it with a > service view that lists telephony as one service, IM as another. The > device-specific attributes would perhaps get replicated in each service, > or else composed in some way into the overall availability (OPEN/CLOSED). > > What do you think about splitting the attributes along those lines? I disagree with the service view for this (and almost everything else) because I don't think it is desirable to partition these things into disjoint services. (I won't mind so much if your concept of service permits the same tuple to support multiple services.) The devices I am concerned with can support IM and voice independently or together in the same session. So I need to describe them as part of the same tuple. Otherwise a subscriber won't know they can be used together. >> - inclusion of useless data >> >> Identifiers for lines seems useless. They are all associated with the >> same phone number, and are not addressable for any purpose. Showing >> lines that are not in use is also pretty useless except for providing >> a way to know that a new call can be accepted. > > I'll agree with that. > >> Data-state could be useful but I think I need to know a lot more info >> to predict what that might permit me to do. > > As per my other note, its useful for applications that want to push data > to the phone. As I read it, the data state didn't say anything about what kinds of features it enabled. If it implies certain features *at the same address as the voice features being reported", then I would rather see those features explicitly enumerated. But I suspect what you suggest is even weirder than that. I suspect you have in mind a cell phone that has one way of doing voice (non-sip) and another way of doing "data", which might include sip for IM, or other internet protocols. If so, then I don't see how those belong as part of the same tuple. At the very least they ought to be in a different tuple, associated with the address at which the features can be invoked. >> ALTERNATIVE: >> >> I think the following kind of structure would accomplish the same >> thing you have proposed yet address my issues: >> >> - a representation for a call. This would subsume your call-state, but >> omitting the not-in-call state. But it would also be extensible for >> other call attributes. This can be repeated as many times as needed to >> represent calls in progress, not lines. (This clearly overlaps with >> the dialog package - something worth discussing. It provides extra >> information in that it can show a call before a dialog is established. >> And with further extension it might provide a way to represent calls >> on hold, if we can figure out what that means.) > > This is different from dialog package in that there isnt a sip dialog. > Nothing in the simple-pidf draft is specific to sip phones. In my mind, > the model is that a presence server might itsefl subscribe to the dialog > package for a phone, and based on that information, generate presence > documents using the pidf information. For other phone types, such as a > wireline phone, it might use the spirits interface or some proprietary > i/f to a switch. OK, maybe it doesn't conflict with the dialog package because it applies to non-sip phones. Good. It is still worth discussing if this level of detail is needed, vs the existence (or a count) of calls in progress. An interesting question is what to do about phones that have multiple "lines". (Register contacts with multiple AORs). The presence is being reported on an address-by-address basis. Typically the presentity will be associated with one of the lines on the phone, so status of calls on other lines doesn't belong in the presence document at all. But the fact that the phone device itself is engaged in a call may be significant nevertheless. Perhaps this is sufficiently covered by activity="on-the-phone". Another piece of information that is significant is if the phone is off-hook (i.e. in process of placing a call) even though not actually in a call. But maybe that is also covered by "on-the-phone". >> - an indication of whether available for another call. In your model >> this seems to be represented by some call-state=not-in-call, or by >> call-waiting=available. But it also seems to be indicated by >> open. I'm uncomfortable using basic status for this, >> because the device may still be open for other kinds of signaling, >> such as subscriptions. >> >> In this new model availablily for calls could also be indicated by a >> call-state of available, but I see no need to model lines not in use. >> This is rooted in old world notions that there are some fixed number >> of lines. Conceivably some new attribute could be introduced for this, >> but I think the attributes in RPIDS already have this covered. (This >> still cries out for capabilities, to describe *what* I am available >> for, but that can be dealt with separately.) > > I think your proposal is reasonable - the phone "service" is modeled by > zero or more call elements that represent some amount of call state, and > information on ability to take another call. > > I see this as different from basic status, in that basic status would > depend on other things too. For example, if I'm in a meeting, even if I > can take another call, the basic status for my telephony service would > be closed. Hmm. That seems quite backward to me. If all my "lines" are in use so that I can't take a call, then I think I would show that as closed. If I am in a meeting where I shouldn't be disturbed, I might show that as closed, or I might show it as open with some qualifiers. OTOH, if my phone can accept pages vis MESSAGE, and I am willing to do those while in the meeting, then I will want to show my tuple as open, with capabilities that include use of MESSAGE but not voice calls. I know this is crossing the line from phone status, but I think these things can and should be mixed in the same tuples, so they can't be discussed in total isolation. >> - an optional element representing the home network provider. This is >> appropriate for all kinds of phones. (I'm not sure why I would want to >> publish this, but I can go along.) > > I can go either way on this too. Now, is this a device or service > property? I can have an IM service on my phone from a different provider > than the one that provides me data access. Arguably, the data access > provider is a device property. I still don't get this distinction between device and service properties. Whatever a service is, doesn't a given tuple have to be one or the other? >> - optional ran, roaming, visited-network, signal-strength attributes. >> (Assuming you think these make sense to provide at all.) These could >> be grouped under a mobile attribute or left standalone. > > I dont think they can be in a single mobile attribute, there is a bunch > of separate information here. Whatever. I don't care. This seems like very weird stuff to publish, but if you want it I see no reason to object. >> - I consider data-state to be a capability. (If you think it is useful >> at all - it isn't clear to me what this implies I can do.) I would >> deal with it together with other capabilities, like voice, video, IM. > > I think its a device capability that says something about availability > across a number of services. That 'service' word again. :-( >> Using the above, representations for POTS phones, business phones, and >> wireless phones are simply usage profiles. The watcher won't >> explicitly know what kind of phone it is except by inference from the >> kinds of presence he sees it use. To me this is a good thing. > > Well, I would still argue that an attribute that describes the type of > device is useful. As noted above, if you want an *independent* phone-type attribute I'm not going to object. Make sure you either make it a text string or set up an extension mechanism for new values. (I think IANA may be too cumbersome for the number of types that people are likely to want.) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jul 31 19:04:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18340 for ; Thu, 31 Jul 2003 19:04:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iMT2-0001TT-7D for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 19:04:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VN4G81005661 for simple-archive@odin.ietf.org; Thu, 31 Jul 2003 19:04:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iMT2-0001TE-2h for simple-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 19:04:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18306; Thu, 31 Jul 2003 19:04:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iMSw-0000e4-00; Thu, 31 Jul 2003 19:04:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iMSw-0000e1-00; Thu, 31 Jul 2003 19:04:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iMSn-0001Rq-D1; Thu, 31 Jul 2003 19:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iMSA-0001Re-Uc for simple@optimus.ietf.org; Thu, 31 Jul 2003 19:03:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18298 for ; Thu, 31 Jul 2003 19:03:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iMS7-0000di-00 for simple@ietf.org; Thu, 31 Jul 2003 19:03:19 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iMS5-0000db-00 for simple@ietf.org; Thu, 31 Jul 2003 19:03:17 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6VN2ZPY017624; Thu, 31 Jul 2003 16:02:35 -0700 (PDT) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABD77366; Thu, 31 Jul 2003 19:02:34 -0400 (EDT) Message-ID: <3F29A00A.3030709@cisco.com> 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 CC: jon.peterson@neustar.biz, simple@ietf.org References: <200306261203.IAA16528@ietf.org> <3F16C405.3020900@cisco.com> <3F2840B4.5030202@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 19:02:34 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > >> Typically a watcher is likely to care less what kind of phone you >> have, and simply want to know if you are available for a call and/or >> are in a call. Having to decipher three different representations of >> this same information is a needless hassle. > > I think a watcher may want to know what type of phone you have - knowing > that its home vs. wireless vs. business is useful presence information > in itself, I believe. Others have brought up the problem of how can you enumerate all the types of phones. It has also been controversial in the attempt to define characteristics of a business phone. I don't think a watcher is likely to care, but who am I to say you shouldn't want to know this. As long as it is an independent piece of information that may or may not be present then I have no problem with it. But in this draft it is *necessary* to divulge what kind of phone you have in order to publish phone characteristics. That's bad. >> Also, to the caller there is no functional difference between a POTS >> phone with call waiting available, and a business phone with two >> "lines" associated to the same number with one in use and one free. In >> both cases the callee is in a call but still available for a call. >> Representing these situations differently just makes things difficult >> for the watcher. > > I think I agree with that. I should point out that our split of the doc > and schema along the device type lines was primarily to facilitate a > division of labor, not because of a fundamental belief that these needed > to be totally separated. That said, there definitely are differences in > states and infrmation between devices. I'm all for making as much common > as is possible though. Certainly there are states or attributes that some phones have and others don't. I think we can effectively deal with that in a generic way. > Perhaps a better way to deal with this is to indicate that there exists > another call in progress, or perhaps an indication of how many calls are > in progress (useful for call routing to customer support operators > perhaps?). Yes, something like that might work. That would minimize the overlap with the dialog event package. But we do need to sort out how much of the dialog package state also makes sense in presence. Offhand I can't think of a reason to include more about a call than its existence, but maybe somebody else can. Number of calls could be sensitive information, so (like ) if we go this way I think there is a requirement to leave the actual number unspecified - just indicating that it is > 0. (There might be some objections to just anybody learning how many calls are in queue to the help desk.) But lets note that this information probably belongs in RPIDS rather than here - it is in now way specific to phones. I am just as interested in how many chat sessions you are in as I am in how many phone calls you are in. And in reality we can't typically classify a call as a chat call or a voice call - its just a call that involves some assortment of media. >> - problematic extensibility model >> >> This pattern also sets the stage for more complexity in the future as >> new devices with different combinations of features hit the market. >> Suppose I come out with both home (single line) and business (multi >> line) voice/im phones. The home phone can do one voice call or one im >> call. The business phone can do two voice calls and two im calls. >> >> It isn't at all clear that I can extend any of the proposed models to >> accomodate my new phone in a graceful way. I may end up defining two >> new types for my new phones, different from these three types. Then I >> have problems with backward compatibility. > > I'm not sure I see the specific problem here - is it because your phones > can do IM also, and none of the phone types in the doc discuss IM? Yes. Although that is just an example. > If this is the case, I would argue that it comes back to a > service/device view. The current draft doesnt separate the two. Many > aspects of the draft refer to a service view, where the service is > telephony. Others refer to the device view - things such as access > network and signal strength (which I agree should be booted) are device > properties that span services. For example, IM and PTT may also run on > the phone, and things like signal strength would affect all of them. > > So, if I have a device as you describe, I could present it with a > service view that lists telephony as one service, IM as another. The > device-specific attributes would perhaps get replicated in each service, > or else composed in some way into the overall availability (OPEN/CLOSED). > > What do you think about splitting the attributes along those lines? I disagree with the service view for this (and almost everything else) because I don't think it is desirable to partition these things into disjoint services. (I won't mind so much if your concept of service permits the same tuple to support multiple services.) The devices I am concerned with can support IM and voice independently or together in the same session. So I need to describe them as part of the same tuple. Otherwise a subscriber won't know they can be used together. >> - inclusion of useless data >> >> Identifiers for lines seems useless. They are all associated with the >> same phone number, and are not addressable for any purpose. Showing >> lines that are not in use is also pretty useless except for providing >> a way to know that a new call can be accepted. > > I'll agree with that. > >> Data-state could be useful but I think I need to know a lot more info >> to predict what that might permit me to do. > > As per my other note, its useful for applications that want to push data > to the phone. As I read it, the data state didn't say anything about what kinds of features it enabled. If it implies certain features *at the same address as the voice features being reported", then I would rather see those features explicitly enumerated. But I suspect what you suggest is even weirder than that. I suspect you have in mind a cell phone that has one way of doing voice (non-sip) and another way of doing "data", which might include sip for IM, or other internet protocols. If so, then I don't see how those belong as part of the same tuple. At the very least they ought to be in a different tuple, associated with the address at which the features can be invoked. >> ALTERNATIVE: >> >> I think the following kind of structure would accomplish the same >> thing you have proposed yet address my issues: >> >> - a representation for a call. This would subsume your call-state, but >> omitting the not-in-call state. But it would also be extensible for >> other call attributes. This can be repeated as many times as needed to >> represent calls in progress, not lines. (This clearly overlaps with >> the dialog package - something worth discussing. It provides extra >> information in that it can show a call before a dialog is established. >> And with further extension it might provide a way to represent calls >> on hold, if we can figure out what that means.) > > This is different from dialog package in that there isnt a sip dialog. > Nothing in the simple-pidf draft is specific to sip phones. In my mind, > the model is that a presence server might itsefl subscribe to the dialog > package for a phone, and based on that information, generate presence > documents using the pidf information. For other phone types, such as a > wireline phone, it might use the spirits interface or some proprietary > i/f to a switch. OK, maybe it doesn't conflict with the dialog package because it applies to non-sip phones. Good. It is still worth discussing if this level of detail is needed, vs the existence (or a count) of calls in progress. An interesting question is what to do about phones that have multiple "lines". (Register contacts with multiple AORs). The presence is being reported on an address-by-address basis. Typically the presentity will be associated with one of the lines on the phone, so status of calls on other lines doesn't belong in the presence document at all. But the fact that the phone device itself is engaged in a call may be significant nevertheless. Perhaps this is sufficiently covered by activity="on-the-phone". Another piece of information that is significant is if the phone is off-hook (i.e. in process of placing a call) even though not actually in a call. But maybe that is also covered by "on-the-phone". >> - an indication of whether available for another call. In your model >> this seems to be represented by some call-state=not-in-call, or by >> call-waiting=available. But it also seems to be indicated by >> open. I'm uncomfortable using basic status for this, >> because the device may still be open for other kinds of signaling, >> such as subscriptions. >> >> In this new model availablily for calls could also be indicated by a >> call-state of available, but I see no need to model lines not in use. >> This is rooted in old world notions that there are some fixed number >> of lines. Conceivably some new attribute could be introduced for this, >> but I think the attributes in RPIDS already have this covered. (This >> still cries out for capabilities, to describe *what* I am available >> for, but that can be dealt with separately.) > > I think your proposal is reasonable - the phone "service" is modeled by > zero or more call elements that represent some amount of call state, and > information on ability to take another call. > > I see this as different from basic status, in that basic status would > depend on other things too. For example, if I'm in a meeting, even if I > can take another call, the basic status for my telephony service would > be closed. Hmm. That seems quite backward to me. If all my "lines" are in use so that I can't take a call, then I think I would show that as closed. If I am in a meeting where I shouldn't be disturbed, I might show that as closed, or I might show it as open with some qualifiers. OTOH, if my phone can accept pages vis MESSAGE, and I am willing to do those while in the meeting, then I will want to show my tuple as open, with capabilities that include use of MESSAGE but not voice calls. I know this is crossing the line from phone status, but I think these things can and should be mixed in the same tuples, so they can't be discussed in total isolation. >> - an optional element representing the home network provider. This is >> appropriate for all kinds of phones. (I'm not sure why I would want to >> publish this, but I can go along.) > > I can go either way on this too. Now, is this a device or service > property? I can have an IM service on my phone from a different provider > than the one that provides me data access. Arguably, the data access > provider is a device property. I still don't get this distinction between device and service properties. Whatever a service is, doesn't a given tuple have to be one or the other? >> - optional ran, roaming, visited-network, signal-strength attributes. >> (Assuming you think these make sense to provide at all.) These could >> be grouped under a mobile attribute or left standalone. > > I dont think they can be in a single mobile attribute, there is a bunch > of separate information here. Whatever. I don't care. This seems like very weird stuff to publish, but if you want it I see no reason to object. >> - I consider data-state to be a capability. (If you think it is useful >> at all - it isn't clear to me what this implies I can do.) I would >> deal with it together with other capabilities, like voice, video, IM. > > I think its a device capability that says something about availability > across a number of services. That 'service' word again. :-( >> Using the above, representations for POTS phones, business phones, and >> wireless phones are simply usage profiles. The watcher won't >> explicitly know what kind of phone it is except by inference from the >> kinds of presence he sees it use. To me this is a good thing. > > Well, I would still argue that an attribute that describes the type of > device is useful. As noted above, if you want an *independent* phone-type attribute I'm not going to object. Make sure you either make it a text string or set up an extension mechanism for new values. (I think IANA may be too cumbersome for the number of types that people are likely to want.) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple