From mailman-bounces@ietf.org Sat Jan 1 06:37:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12251 for ; Sat, 1 Jan 2005 06:37:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkhlT-0007iS-OK for simple-archive@ietf.org; Sat, 01 Jan 2005 06:49:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkgLV-0003hf-Dv for simple-archive@ietf.org; Sat, 01 Jan 2005 05:18:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: simple-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:05:58 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit 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, mailman-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: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@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 ADNJHTZWPTGPN@msn.com Mon Jan 3 06:03:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16808; Mon, 3 Jan 2005 06:03:04 -0500 (EST) Received: from [221.143.163.103] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1ClQBW-00013p-8T; Mon, 03 Jan 2005 06:15:38 -0500 Received: from [41.120.231.0] (helo=..dearriba.com) by smtp2.cistron.nl with esmtp ( 3.35 #1 ()) id 320LFL-0050PT-62 Message-ID: <61654143144732.R37431@.noc..gr> Sender: freeradius-devel-ADNJHTZWPTGPN@msn.com X-Mailman-Version: 2.0.1 Date: Mon, 03 Jan 2005 11:58:23 +0100 From: "Marisa Delgado" To: simple-admin@ietf.org, simple-archive@ietf.org, simple-request@ietf.org, simple-web-archive@ietf.org Subject: Look...Here Simple-admin X-Spam-Score: 3.4 (+++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Wide range of medss available to choose in our stores. Saveee uup to 7o % Viiagraa, Ciallis, Vallium, Xanaax and many moore.. http://058.kuolocl.com/c/ Happy New Year FSrZeoKLg9t04SkNkxEFcVFuiRCIMV03xin23IFknRD0CRD From simple-bounces@ietf.org Mon Jan 3 11:59:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13445; Mon, 3 Jan 2005 11:59:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClVkY-0000Dn-Cz; Mon, 03 Jan 2005 12:12:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClVVe-0006Un-Mx; Mon, 03 Jan 2005 11:56:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClVUj-0006CW-Ad; Mon, 03 Jan 2005 11:55:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13182; Mon, 3 Jan 2005 11:55:46 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClVgs-00009S-6p; Mon, 03 Jan 2005 12:08:25 -0500 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j03GtajI097298 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 3 Jan 2005 10:55:37 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: <41D0955B.2080704@nostrum.com> References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> <41D0955B.2080704@nostrum.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <4E86F292-5DA8-11D9-A1D2-000D93B0AE1A@nostrum.com> From: Ben Campbell Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern Date: Mon, 3 Jan 2005 10:55:43 -0600 To: Adam Roach X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Joerg Ott , mmusic@ietf.org, Simple WG , Colin Perkins X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0987691806==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --===============0987691806== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--237391422; protocol="application/pkcs7-signature" --Apple-Mail-8--237391422 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I sent the following proposed compromise out before the holidays. If anyone commented on it, I have not seen the comments. The general idea is that MSRP aware endpoints would use the path attribute, but a non MSRP aware device could still determine the destination address and port from the m and c lines. thoughts? > How about this as a potential compromise: > > We keep the path attribute as is, but _also_ copy the information for > the endpoint into the m and c lines. This would seem to me to be > consistent with the usage in the current ICE draft, in which ICE aware > endpoints use the candidate attributes to determine the address and > port, but the default address and port are copied into the m and c > line for backwards compatibility? Considering that the ICE need for > backwards compatibility seems much more clear than the MSRP need for > the same? --Apple-Mail-8--237391422 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGEjCCAssw ggI0oAMCAQICAwwdSDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwNDEyMjA0NTUyWhcNMDUwNDEyMjA0NTUyWjBBMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR4wHAYJKoZIhvcNAQkBFg9iZW5Abm9zdHJ1bS5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGFv8c1i8a9NXiEohMEryzypOcyz39k8PN WxTS4F45JSYwQ0/RAZ4vaemHCyJaUc7tc5DN3o7zl2oaqQuOIrvnjk79ILGJVfRgwt+uGDIGyaSM YmBeKXSdawFiJdk5jGtMzlgF8tzJzc4do5Mzl5YS39AR8mj8PF4zEgIlYYkKXBByHQ2jPA0qVfm/ Aj71RdYZyDAD4P7TyW9jKvZCl7KCfajar1llEQVj+kWMvt/3AE6mwAHXfkU7nL9XzLvGSnMUJvYx hq3UDju4IacXsYFw2oLb4LQdvwP4Lbg6qdp08h59+TkHlV6WNdt3ggM9C/cGQTDCa0CVJsr+76Dm mPorAgMBAAGjLDAqMBoGA1UdEQQTMBGBD2JlbkBub3N0cnVtLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBAUAA4GBAApFAg5tsI2OhByoUglTZ+ip3M/1xfWDsCNsDB4+HtnH9fZfKkrkGp4e JQyuvl5VhvW67qYU6wEPMD0EKoWDU3v7l1huzR7Cpkf7n21y4LLG+VxldYiA3SEkv7RBPhhVhdMl sHwNZAYyVXFCdnvuVjfeytdAeXK6vzcaUvo9EwkHMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0B AQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv biBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAw MDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoT zyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GU MIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3 dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQ g+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsA xRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXe JLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMMHUgwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMDUwMTAzMTY1NTQ0WjAjBgkqhkiG9w0BCQQxFgQU5ss49FkudmMZXARB JAaQksR1okkweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0ECAwwdSDB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMHUgwDQYJKoZIhvcNAQEBBQAEggEAYg1InaMf42hj4GVJ ZPn0HJ2Z00C5KZDA3RzFk5o/Ty1PyFUA8bp4gWiuxfxTTXF6/qL8XiasRoeRL7+IqsWJdLy/Kln1 mYCQKDwPX7SlP7Ia/vcBEKhYuqaIszt8mjbaI2B5kEPcNjA6jiZt+FfSTtso9pIUO7+iKZid6QrV eKaUDH/NK0M62N+qem04SOhaTFyZ6DiL0LwMZ+t33r674BFQhPj2625EERUu/WN+Os/j5xi+BTXc S5k2xOFo3x6wKXiAZF1ej4O2FDhj3M15syMEYaa9EKVXA6aiNRoE4Tk9nujCKYTbSFWMpX8oZwNS 2XDMK70+CnKz3Eg4tlG3NAAAAAAAAA== --Apple-Mail-8--237391422-- --===============0987691806== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0987691806==-- From simple-bounces@ietf.org Mon Jan 3 12:26:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15540; Mon, 3 Jan 2005 12:26:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClWAE-0000pl-H1; Mon, 03 Jan 2005 12:38:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClVpj-0006ye-Mr; Mon, 03 Jan 2005 12:17:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClVkX-0003fB-N1; Mon, 03 Jan 2005 12:12:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14382; Mon, 3 Jan 2005 12:12:07 -0500 (EST) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClVwX-0000TN-8E; Mon, 03 Jan 2005 12:24:46 -0500 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id DF3E6A9653; Mon, 3 Jan 2005 18:11:19 +0100 (CET) Received: from [192.168.1.67] (unknown [82.196.203.62]) by voyager.coretrek.no (Postfix) with ESMTP id A2B5DA9652; Mon, 3 Jan 2005 18:11:18 +0100 (CET) In-Reply-To: <4E86F292-5DA8-11D9-A1D2-000D93B0AE1A@nostrum.com> References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> <41D0955B.2080704@nostrum.com> <4E86F292-5DA8-11D9-A1D2-000D93B0AE1A@nostrum.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <768E41B2-5DAA-11D9-9BB1-000D93C60BA0@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern Date: Mon, 3 Jan 2005 18:11:09 +0100 To: Ben Campbell X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Simple WG , Joerg Ott , Adam Roach , mmusic@ietf.org, Colin Perkins X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit I don't see the need. The information in the c and m line will be ignored anyway by the receiver, so why waste CPU cycles? Also, backwards compatible with what? Anyway, I don't feel too strongly about this. If it makes the SDP people happy, then we can add it. Regards, Hisham On Jan 3, 2005, at 5:55 PM, Ben Campbell wrote: > I sent the following proposed compromise out before the holidays. If > anyone commented on it, I have not seen the comments. The general idea > is that MSRP aware endpoints would use the path attribute, but a non > MSRP aware device could still determine the destination address and > port from the m and c lines. thoughts? > >> How about this as a potential compromise: >> >> We keep the path attribute as is, but _also_ copy the information for >> the endpoint into the m and c lines. This would seem to me to be >> consistent with the usage in the current ICE draft, in which ICE >> aware endpoints use the candidate attributes to determine the address >> and port, but the default address and port are copied into the m and >> c line for backwards compatibility? Considering that the ICE need for >> backwards compatibility seems much more clear than the MSRP need for >> the same? > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 3 12:43:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17449; Mon, 3 Jan 2005 12:43:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClWQk-0001OS-6z; Mon, 03 Jan 2005 12:55:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClW8i-0007Ey-3G; Mon, 03 Jan 2005 12:37:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClW5m-0005sD-75; Mon, 03 Jan 2005 12:34:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16658; Mon, 3 Jan 2005 12:34:03 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClWHv-00017J-Jz; Mon, 03 Jan 2005 12:46:42 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 03 Jan 2005 10:44:00 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j03HXSvl012197; Mon, 3 Jan 2005 09:33:29 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-24.cisco.com [10.86.242.24]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOB13618; Mon, 3 Jan 2005 12:33:27 -0500 (EST) Message-ID: <41D981E7.4020202@cisco.com> Date: Mon, 03 Jan 2005 12:33:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> <41D0955B.2080704@nostrum.com> <4E86F292-5DA8-11D9-A1D2-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: Colin Perkins , Joerg Ott , Adam Roach , mmusic@ietf.org, Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Ben, I think there is a potential problem with this solution, and in fact with any solution that uses the m- and c- lines for address and port: it is possible that there could be two (or more) MSRP media streams in the same offer/answer. Because of the multiplexing capabilities of MSRP, there could be multiple streams that share the same address and port. In the case of RTP streams, every stream must have a unique address/port. Technically I believe the rules about this are transport dependent, so that there could be separate rules for MSRP, permitting this. However, I am concerned that those arguing that we must use m- and c- for address and port will also object to duplicates, even with the msrp transport. Conversely, if we are permitted to define the rules differently for msrp, I don't see why we can't define the rules so we don't use m- and c- for address and port. Paul Ben Campbell wrote: > I sent the following proposed compromise out before the holidays. If > anyone commented on it, I have not seen the comments. The general idea > is that MSRP aware endpoints would use the path attribute, but a non > MSRP aware device could still determine the destination address and port > from the m and c lines. thoughts? > >> How about this as a potential compromise: >> >> We keep the path attribute as is, but _also_ copy the information for >> the endpoint into the m and c lines. This would seem to me to be >> consistent with the usage in the current ICE draft, in which ICE aware >> endpoints use the candidate attributes to determine the address and >> port, but the default address and port are copied into the m and c >> line for backwards compatibility? Considering that the ICE need for >> backwards compatibility seems much more clear than the MSRP need for >> the same? > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 3 14:01:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27079; Mon, 3 Jan 2005 14:01:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClXe7-0003k0-0I; Mon, 03 Jan 2005 14:13:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClXLX-0003L4-26; Mon, 03 Jan 2005 13:54:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClXHx-0002Fd-Ia; Mon, 03 Jan 2005 13:50:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25585; Mon, 3 Jan 2005 13:50:44 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClXU9-0003N7-Bp; Mon, 03 Jan 2005 14:03:22 -0500 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j03Iocp6006905 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 3 Jan 2005 12:50:39 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: <41D981E7.4020202@cisco.com> References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> <41D0955B.2080704@nostrum.com> <4E86F292-5DA8-11D9-A1D2-000D93B0AE1A@nostrum.com> <41D981E7.4020202@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <60AB4694-5DB8-11D9-A341-000D93B0AE1A@nostrum.com> From: Ben Campbell Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern Date: Mon, 3 Jan 2005 12:50:45 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Colin Perkins , Joerg Ott , Adam Roach , mmusic@ietf.org, Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1424596719==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f --===============1424596719== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--230489038; protocol="application/pkcs7-signature" --Apple-Mail-3--230489038 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit It sounds to me that you have just described a real technical issue where using the m and c lines _cannot_ work in the general case unless we break other SDP rules anyway. On Jan 3, 2005, at 11:33 AM, Paul Kyzivat wrote: > Ben, > > I think there is a potential problem with this solution, and in fact > with any solution that uses the m- and c- lines for address and port: > > it is possible that there could be two (or more) MSRP media streams in > the same offer/answer. Because of the multiplexing capabilities of > MSRP, there could be multiple streams that share the same address and > port. > > In the case of RTP streams, every stream must have a unique > address/port. Technically I believe the rules about this are transport > dependent, so that there could be separate rules for MSRP, permitting > this. However, I am concerned that those arguing that we must use m- > and c- for address and port will also object to duplicates, even with > the msrp transport. > > Conversely, if we are permitted to define the rules differently for > msrp, I don't see why we can't define the rules so we don't use m- and > c- for address and port. > > Paul > > Ben Campbell wrote: >> I sent the following proposed compromise out before the holidays. If >> anyone commented on it, I have not seen the comments. The general >> idea is that MSRP aware endpoints would use the path attribute, but a >> non MSRP aware device could still determine the destination address >> and port from the m and c lines. thoughts? >>> How about this as a potential compromise: >>> >>> We keep the path attribute as is, but _also_ copy the information >>> for the endpoint into the m and c lines. This would seem to me to be >>> consistent with the usage in the current ICE draft, in which ICE >>> aware endpoints use the candidate attributes to determine the >>> address and port, but the default address and port are copied into >>> the m and c line for backwards compatibility? Considering that the >>> ICE need for backwards compatibility seems much more clear than the >>> MSRP need for the same? >> ---------------------------------------------------------------------- >> -- >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic --Apple-Mail-3--230489038 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGEjCCAssw ggI0oAMCAQICAwwdSDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwNDEyMjA0NTUyWhcNMDUwNDEyMjA0NTUyWjBBMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR4wHAYJKoZIhvcNAQkBFg9iZW5Abm9zdHJ1bS5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGFv8c1i8a9NXiEohMEryzypOcyz39k8PN WxTS4F45JSYwQ0/RAZ4vaemHCyJaUc7tc5DN3o7zl2oaqQuOIrvnjk79ILGJVfRgwt+uGDIGyaSM YmBeKXSdawFiJdk5jGtMzlgF8tzJzc4do5Mzl5YS39AR8mj8PF4zEgIlYYkKXBByHQ2jPA0qVfm/ Aj71RdYZyDAD4P7TyW9jKvZCl7KCfajar1llEQVj+kWMvt/3AE6mwAHXfkU7nL9XzLvGSnMUJvYx hq3UDju4IacXsYFw2oLb4LQdvwP4Lbg6qdp08h59+TkHlV6WNdt3ggM9C/cGQTDCa0CVJsr+76Dm mPorAgMBAAGjLDAqMBoGA1UdEQQTMBGBD2JlbkBub3N0cnVtLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBAUAA4GBAApFAg5tsI2OhByoUglTZ+ip3M/1xfWDsCNsDB4+HtnH9fZfKkrkGp4e JQyuvl5VhvW67qYU6wEPMD0EKoWDU3v7l1huzR7Cpkf7n21y4LLG+VxldYiA3SEkv7RBPhhVhdMl sHwNZAYyVXFCdnvuVjfeytdAeXK6vzcaUvo9EwkHMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0B AQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv biBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAw MDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoT zyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GU MIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3 dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQ g+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsA xRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXe JLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMMHUgwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMDUwMTAzMTg1MDQ2WjAjBgkqhkiG9w0BCQQxFgQUFWWiV6SSFKYhkgWe P3I5NrhHxBgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0ECAwwdSDB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMHUgwDQYJKoZIhvcNAQEBBQAEggEAApXDrVq0ASterhK6 BSD57OYU1o+NqZQSi93JK2amJQ1em54wC4XCR/kr68yzvG1Oq0b6a7oadw8AtCEJywG/x9YW1bON iwkXee3QAbM6qIPUMdJaRkIU9xgTjiTx9mzo/e7EBrsYS3Rvxs9oYFdeh0sRy5a4aIv5E7TvU9gE zNWSJ5ueEVVF+yzn5sSmXERbLOeU5976GW6yOk6jJ4/DjPe2CrbFWe2KtANCPrig/XEAuzamGcKi /wfzWK5lhhhpTAt/wzJO60t29lvWoF0E3NliUC5YZIljrARPkKV3R4VPaCiJzobmhIheodAa4Ftq 2xbmQUEcqii492Ol7XQSpQAAAAAAAA== --Apple-Mail-3--230489038-- --===============1424596719== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1424596719==-- From simple-bounces@ietf.org Mon Jan 3 16:41:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22233; Mon, 3 Jan 2005 16:41:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cla9n-0002eg-IL; Mon, 03 Jan 2005 16:54:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClZ4G-00014N-CZ; Mon, 03 Jan 2005 15:44:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClZ1M-0007J6-Ne; Mon, 03 Jan 2005 15:41:44 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07980; Mon, 3 Jan 2005 15:41:43 -0500 (EST) Message-Id: <200501032041.PAA07980@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 03 Jan 2005 15:41:42 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-event-list-07.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --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 : A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists Author(s) : A. Roach, et al. Filename : draft-ietf-simple-event-list-07.txt Pages : 48 Date : 2005-1-3 This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list, and then receive notifications when the state of any of the resources in the list changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-event-list-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-event-list-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-3151335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-event-list-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-event-list-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-3151335.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Mon Jan 3 23:16:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22531; Mon, 3 Jan 2005 23:16:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClgJU-00038x-VE; Mon, 03 Jan 2005 23:28:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clfz5-0002Gx-H7; Mon, 03 Jan 2005 23:07:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClfyY-0001rF-J0; Mon, 03 Jan 2005 23:07:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22108; Mon, 3 Jan 2005 23:07:16 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClgAn-0002zs-L9; Mon, 03 Jan 2005 23:20:00 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 03 Jan 2005 21:17:18 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0446cvl002406; Mon, 3 Jan 2005 20:06:38 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-24.cisco.com [10.86.242.24]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOB28551; Mon, 3 Jan 2005 23:06:38 -0500 (EST) Message-ID: <41DA164E.40603@cisco.com> Date: Mon, 03 Jan 2005 23:06:38 -0500 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: Colin Perkins Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> <41D0955B.2080704@nostrum.com> <4E86F292-5DA8-11D9-A1D2-000D93B0AE1A@nostrum.com> <768E41B2-5DAA-11D9-9BB1-000D93C60BA0@telio.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: Joerg Ott , Adam Roach , mmusic@ietf.org, Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Colin Perkins wrote: > On 3 Jan 2005, at 17:11, Hisham Khartabil wrote: > >> I don't see the need. The information in the c and m line will be >> ignored anyway by the receiver, so why waste CPU cycles? > > Because SDP requires the "c=" and "m=" lines to indicate where the media > is sent, and because there could be a middlebox or other device > processing the SDP that needs that information. For a middlebox to work with this, it must understand the *semantics*, not just the syntax. Even if we were to use the m- and c- lines as requested, a middlebox without specific knowledge of msrp will not know what to do: is the tcp, udp, rtp, or what? And in the case of msrp, the msrp relay *is* the middlebox, and the sdp syntax has been designed specifically to accomodate it. >> Also, backwards compatible with what? > > Other devices that parse SDP, some of which may be outside your control. I still don't buy this. There is no issue of *parsing* the SDP. Nothing we have done is inconsistent with SDP parsing. I think the issue you are alluding to must be more to "implementing" SDP to a greater extent than just parsing it. But in all cases the semantics are a function of the particular transport. Its not clear to me that are any standard semantics. Colin - I would like to hear exactly what you think can be implemented generically across all transports, including unknown ones. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 4 10:19:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18465; Tue, 4 Jan 2005 10:19:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClqfT-0007Ln-LA; Tue, 04 Jan 2005 10:32:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClqRr-0003nx-22; Tue, 04 Jan 2005 10:18:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClWZE-0000my-Ri; Mon, 03 Jan 2005 13:04:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20839; Mon, 3 Jan 2005 13:04:30 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClWlQ-00025i-Ie; Mon, 03 Jan 2005 13:17:09 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62322 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1ClWYh-0001Ze-EW; Mon, 03 Jan 2005 18:03:59 +0000 In-Reply-To: <768E41B2-5DAA-11D9-9BB1-000D93C60BA0@telio.no> References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> <41D0955B.2080704@nostrum.com> <4E86F292-5DA8-11D9-A1D2-000D93B0AE1A@nostrum.com> <768E41B2-5DAA-11D9-9BB1-000D93C60BA0@telio.no> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern Date: Mon, 3 Jan 2005 18:03:52 +0000 To: Hisham Khartabil X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 04 Jan 2005 10:18:14 -0500 Cc: Joerg Ott , Adam Roach , mmusic@ietf.org, Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit On 3 Jan 2005, at 17:11, Hisham Khartabil wrote: > I don't see the need. The information in the c and m line will be > ignored anyway by the receiver, so why waste CPU cycles? Because SDP requires the "c=" and "m=" lines to indicate where the media is sent, and because there could be a middlebox or other device processing the SDP that needs that information. > Also, backwards compatible with what? Other devices that parse SDP, some of which may be outside your control. Colin _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 4 10:21:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18662; Tue, 4 Jan 2005 10:21:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clqgy-0007Nr-8Q; Tue, 04 Jan 2005 10:33:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClqRr-0003o2-G7; Tue, 04 Jan 2005 10:18:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClWbN-0001M4-L1; Mon, 03 Jan 2005 13:06:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21044; Mon, 3 Jan 2005 13:06:42 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClWnZ-00028E-Dj; Mon, 03 Jan 2005 13:19:22 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62350 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1ClWar-0001aM-KG; Mon, 03 Jan 2005 18:06:13 +0000 In-Reply-To: <4E86F292-5DA8-11D9-A1D2-000D93B0AE1A@nostrum.com> References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> <41D0955B.2080704@nostrum.com> <4E86F292-5DA8-11D9-A1D2-000D93B0AE1A@nostrum.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <25DF6EBA-5DB2-11D9-ADD5-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern Date: Mon, 3 Jan 2005 18:06:10 +0000 To: Ben Campbell X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 04 Jan 2005 10:18:14 -0500 Cc: Joerg Ott , Adam Roach , Simple WG , mmusic@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit On 3 Jan 2005, at 16:55, Ben Campbell wrote: > I sent the following proposed compromise out before the holidays. If > anyone commented on it, I have not seen the comments. The general idea > is that MSRP aware endpoints would use the path attribute, but a non > MSRP aware device could still determine the destination address and > port from the m and c lines. thoughts? Not ideal, but better than ignoring the addresses in the "c=" and "m=" lines. Colin _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 4 14:06:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08660; Tue, 4 Jan 2005 14:06:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CluCp-0004eo-Ji; Tue, 04 Jan 2005 14:19:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CltvE-0005PN-WE; Tue, 04 Jan 2005 14:00:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cltmx-000127-DA; Tue, 04 Jan 2005 13:52:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07376; Tue, 4 Jan 2005 13:52:14 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CltzM-0004DT-UT; Tue, 04 Jan 2005 14:05:05 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 04 Jan 2005 12:02:24 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j04Ipdvl003760; Tue, 4 Jan 2005 10:51:40 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOB71474; Tue, 4 Jan 2005 13:51:38 -0500 (EST) Message-ID: <41DAE5BA.6080100@cisco.com> Date: Tue, 04 Jan 2005 13:51:38 -0500 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: Joerg Ott Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> <41D0955B.2080704@nostrum.com> <4E86F292-5DA8-11D9-A1D2-000D93B0AE1A@nostrum.com> <768E41B2-5DAA-11D9-9BB1-000D93C60BA0@telio.no> <41DA164E.40603@cisco.com> <41DAD42A.4060508@tzi.uni-bremen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Content-Transfer-Encoding: 7bit Cc: Simple WG , Adam Roach , Colin Perkins , mmusic@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Content-Transfer-Encoding: 7bit Joerg Ott wrote: > The essence of what I hear (or read) Paul saying is: > > From SDP, we need the "m=" part to delimit streams > and to identify something as MSRP. There may be a few common > attributes and further fields but do not count on them because > the rest is up to the interpretation per media protocol. Its not the m=media-type part (m=application) that is significant here. It is the transport protocol in the m-line that is most significant. (m=application 9 msrp *). And it really isn't just about msrp, although that is clearly what is motivating the discussion. SDP *claims* to be flexible to different transport protocols, and makes a considerable part of the semantics conditional on that. But in large part it seems like lip service, because the document is heavily biased towards RTP. Only in the context of the transport protocol is it possible to know what to do with the address and port. A middlebox looking at SDP cannot do anything useful to influence the communication in any way without understanding the protocol identifier and the semantics attached to it. For instance, no matter what else we do, a middlebox that doesn't understand "msrp" as a transport protocol identifier will not be able to open a pinhole thru a firewall - it won't know whether it is looking at a TCP address/port, a UDP address/port, or something else. There in nothing in the protocol identifier that would permit it to guess that. And those components that *do* understand the protocol identifier need to understand *all* the associated semantics, and the attributes that convey it. Once you assume they do, then it doesn't matter that the c= line or the port on the m= line is irrelevant. > This viewpoint doesn't really convince me at this point. > We have numerous rules and extensions for SDP (preconditions, > labels, etc.), and I haven't yet gone through the exercise > to find out whether such a "usage" of SDP would actually > work with all of these. (This does not mean that I would > like this approach even if we can make this work.) Have you gone thru the exercise to see if they all work for comedia? At a superficial level I see no reason why they wouldn't. Certainly it should be no issue for label, and the generic mechanism for preconditions should also be unaffected. The establishment of QoS itself clearly is dependent on the kind of transport that is in use. I think there may indeed be some problems with any connection oriented transport, such as defined by comedia. This is highly intertwined with the semantics of the transport, and only incidentally with the specifics of the sdp notation used to specify the connection establishment parameters. > But leaving alone the "ugliness" issue for the moment, I > would like to discuss two issues so that we can take a > meaningful decision and move on: > > 1. Need for Relays > > MSRP motivates relays primarily by NAT/firewall traversal. This is one of the reasons. But there is a general understanding that enterprises may require a policy engine in the media path for IM for other reasons as well. Also, unlike voice, it is common to have several concurrent IM sessions open. Some endpoints wish to multiplex the sessions over a single connection. Because competing protocols do this it is desirable to retain this as a possibility. > But, of course, it would be much nicer if two endpoints > could talk to each other directly (rather than via an > intermediary). We have worked hard to retain this as the preferred path when possible and permitted by policy. However, > Then, we would not really need multiplexing > (unless maybe two gateways talk -- which is conceptually > different) I don't see why this is conceptually different. Are you suggesting we invent a different solution for this case? > and a single m=/c= line would be sufficient > (and might simply reuse comedia and be done with it). We have been down that path - its probably been two years now, when that was the assumed solution, until we found a multitude of reasons why it wouldn't work. Remember, this is at least our 3rd (depending on how you count) attempt to produce a solution that meets our needs. If you didn't walk the path with us, then please don't discount all the work we did before arriving at the solution we have. > Hence, what we are arguing over is a (potentially endlessly > lasting) interim solution until we get the connectivity right. > If there was a way to do something like ICE here as well, > we would be done with it. I think it would be easy to argue that this is better than ICE, and is an option specifically because we have no backward compatibility issues to deal with. There are enough reasons for relays, besides NATs and FWs, that I don't imagine they will go away any time soon. In any case, I expect to be dead before NATs and FWs are gone. > So, how much hassle are we willing to take up to make the > interim solution work. This should add to the basic version > instead of having the basic version designed as a special > case of the interim. If you want to take up the general case, fine. But we don't have the time. MSRP is long overdue. If it is *ever* to be adopted we need to get it out *soon*. > 2. Generality > > Assuming that there is a need for a stepwise connection via > some relay (and that this will never go away), I suspect that > MSRP will not be only application protocol that is going to > need it. T.38 via TCP may be another example and so may a > shared PowerPoint presetation or VNC application. > > Then, I would like to have a general solution developed that > is _not_ specific to MSRP and is documented as such. We would > need to design something like draft-*-comedia-muxed-via-relays > rather than having one specific solution now and coming up > with another one every week. I don't think we know how to do that, and I doubt there is a quorum to work on that problem. The main issue is that to multiplex, you need to have addressing associated with the chunks that are being multiplexed. We could do that in MSRP because we defined the protocol. How would you do that for an unspecified transport protocol? > This appears to call for some explicitly spelled out requirements > rather than a detailed discussion about a partial technical > solution. We have a sufficient solution for our needs. It would be helpful to have suggestions on how to *improve* this, rather than suggestions for how we could delay msrp for another couple of years. Also, I thought there was a goal to minimize work on SDP. Is it really worth investing in a general mechanism that likely won't be used again? I have been looking thru sdp-new-23 carefully for specifics that relate to the problems being discussed. I will post another message shortly with the results of that. Perhaps I can propose something that will be considered more in keeping with the "philosophy" of sdp. Paul > Joerg > > Paul Kyzivat wrote: > >> >> >> Colin Perkins wrote: >> >>> On 3 Jan 2005, at 17:11, Hisham Khartabil wrote: >>> >>>> I don't see the need. The information in the c and m line will be >>>> ignored anyway by the receiver, so why waste CPU cycles? >>> >>> >>> >>> Because SDP requires the "c=" and "m=" lines to indicate where the >>> media is sent, and because there could be a middlebox or other device >>> processing the SDP that needs that information. >> >> >> >> For a middlebox to work with this, it must understand the *semantics*, >> not just the syntax. Even if we were to use the m- and c- lines as >> requested, a middlebox without specific knowledge of msrp will not >> know what to do: is the tcp, udp, rtp, or what? >> >> And in the case of msrp, the msrp relay *is* the middlebox, and the >> sdp syntax has been designed specifically to accomodate it. >> >>>> Also, backwards compatible with what? >>> >>> >>> >>> Other devices that parse SDP, some of which may be outside your control. >> >> >> >> I still don't buy this. There is no issue of *parsing* the SDP. >> Nothing we have done is inconsistent with SDP parsing. >> >> I think the issue you are alluding to must be more to "implementing" >> SDP to a greater extent than just parsing it. But in all cases the >> semantics are a function of the particular transport. Its not clear to >> me that are any standard semantics. >> >> Colin - I would like to hear exactly what you think can be implemented >> generically across all transports, including unknown ones. >> >> Paul >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 4 15:34:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16093; Tue, 4 Jan 2005 15:34:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClvZt-0006SM-Sm; Tue, 04 Jan 2005 15:46:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClvHn-0002q1-Js; Tue, 04 Jan 2005 15:28:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clv8x-0004Ip-P1; Tue, 04 Jan 2005 15:19:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14967; Tue, 4 Jan 2005 15:19:01 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClvLK-0006C7-Sj; Tue, 04 Jan 2005 15:31:54 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Jan 2005 13:29:10 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j04KIPjw000087; Tue, 4 Jan 2005 12:18:25 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOB80391; Tue, 4 Jan 2005 15:18:23 -0500 (EST) Message-ID: <41DAFA0F.9070805@cisco.com> Date: Tue, 04 Jan 2005 15:18:23 -0500 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: Colin Perkins , Joerg Ott Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> <41D0955B.2080704@nostrum.com> <4E86F292-5DA8-11D9-A1D2-000D93B0AE1A@nostrum.com> <768E41B2-5DAA-11D9-9BB1-000D93C60BA0@telio.no> <41DA164E.40603@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Content-Transfer-Encoding: 7bit I have been looking carefully at sdp-new-23 for further enlightenment on this discussion. The following are interesting: ------------ Section 4.1: "For unicast IP sessions, the following are conveyed: o The remote address for media o The remote transport port for media The semantics of this address and port depend on the media and transport protocol defined. By default, this SHOULD be the remote address and remote port to which data is sent. Some media types MAY redefine this behaviour, but this is NOT RECOMMENDED." The above is already somewhat suspect for TCP (e.g. comedia), because the address and port are not those to which data is sent, but instead is the remote address with which a connection is (sometimes) established. It seems to me that the above shows a strong bias towards UDP and RTP, and must be taken with a large grain of salt for transports that are dissimilar from those. I think there may be some question as to whether it is even proper to describe an MSRP session as a "unicast IP session", since it may be multiplexed with other MSRP sessions on a single TCP connection. ---------------- Section 5.7 (c=): "The first sub-field ("") is the network type, which is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8). The second sub-field ("") is the address type. This allows SDP to be used for sessions that are not IP based. This memo only defines IP4 and IP6, but other values MAY be registered in the future (see Section 8). The third sub-field ("") is the connection address. OPTIONAL sub-fields MAY be added after the connection address depending on the value of the field." The above textual description is not entirely in line with the syntax. In particular, while the above says additional subfields may follow the connection address depending on the value of , the syntax makes no provision for this. "When the is IP4 and IP6, the connection address is defined as follows: o If the session is multicast, the connection address will be an IP multicast group address. If the session is not multicast, then the connection address contains the unicast IP address of the expected data source or data relay or data sink as determined by additional attribute fields. It is not expected that unicast addresses will be given in a session description that is communicated by a multicast announcement, though this is not prohibited." The above seems to assume that the data source, relay, or sink can be identified by the connection address (presumably in conjunction with the port), and that attributes simply specify whether it is a source, relay, or sink. The possibility doesn't seem to have been considered that there might be multiple sinks at the same address/port that must be identified. There is however the possibility of defining a new net type or address type that would fit our needs, permitting a complete identification to be included in the c-line. Assuming the problem with additional subfields were corrected, a possible accomodation might be to reformulate the "path" attribute as a c-line with a new addrtype, such as: c=IN MSRP-PATH ... where "MSRP-PATH" is a new addrtype, the first msrp-url is the (a newly defined form of ), and the remaining urls in the path are "additional subfields". This would arguably be more in the spirit of SDP, but for compatibility purposes I don't find it nearly as friendly as what is currently defined. ----------------- Section 5.13 (a=): "Attribute interpretation depends on the media tool being invoked. Thus receivers of session descriptions should be configurable in their interpretation of session descriptions in general and of attributes in particular." The above provides a great deal of lattitude. But there is little clarity about what how "media tools" should behave with things they have not been configured for. (There is the general requirement that a-lines not understood must be ignored. I don't believe there is any similar requirement re transport protocol identifiers in the m-line. Rather than worrying about the particular usage of the c-line and port with the msrp protocol, I think it would be more worthwhile to specify processing when encountering a protocol that is not understood. ----------------- Section 5.14 (m=): " is the transport port to which the media stream is sent. The meaning of the transport port depends on the network being used as specified in the relevant "c=" field, and on the transport protocol defined in the sub-field of the media field. Other ports used by the media application (such as the RTCP port [18]) MAY be derived algorithmically from the base media port or MAY be specified in a separate attribute (for example "a=rtcp:" as defined in [21])." So the meaning of the port depends on the transport protocol. Since we are defining a new transport protocol, we get to define the meaning of the port with that protocol. "The combination of ports specified in "m=" lines and IP addresses specified in "c=" lines MUST comply with the following rules for RTP-based media streams (other protocols SHOULD define similar rules):" So the provided rules do not apply in our case, and we should define appropriate ones that do apply to our usage. (However there are also other rules in the offer/answer protocol that also affect this, and that may not have been made conditional on transport protocol.) "Two media sessions with the same transport address indicate alternatives for the same media stream, i.e. all profiles, media types, and payload types provided in any of the "m=" lines are valid." The way the text is formatted (following the rules mentioned above), this does not appear to be scoped by the transport protocol, and so would seem to be intended to apply regardless of transport protocol. If this indeed applies for new transport protocols (such as msrp), then it constrains how we use the connection-address and port. If we were to follow the suggestion to insert the IP address from the first path entry in the c-line, and the insert the port into the m-line, then two msrp sessions with the same next hop would be treated as alternatives, which is not correct. This is not a problem as we currently have things specified, because we require unique ports be used, even though they are ignored. ======================================================================= To fix the problem that the syntax doesn't support the text in allowing additional subfields following connection-address depending on addrtype, I would propose the following change to the syntax: old: extn-addr = non-ws-string new: extn-addr = non-ws-string *(SP non-ws-string) Then, using that, I propose the following SDP extensions to support msrp. (It is my impression that these can be in the msrp draft rather than in sdp-new): old: unicast-address = IP4-address / IP6-address / FQDN / extn-addr new: unicast-address = IP4-address / IP6-address / FQDN / msrp-path ; valid for addrtype of "msrp-path" / extn-addr Also, define "MSRP-PATH" as a new . (Not part of syntax.) Then the c-line replaces the path attribute. For example: - as currently proposed: v=0 o=alice 2890844526 2890844527 IN IP4 alice.example.com s= c=IN IP4 alice.example.com m=message 9 msrp * a=accept-types:text/plain a=path:msrp://a.example.com:7394/2s93i;tcp - with info replicated in c- and m-: v=0 o=alice 2890844526 2890844527 IN IP4 alice.example.com s= c=IN IP4 a.example.com m=message 7394 msrp * a=accept-types:text/plain a=path:msrp://a.example.com:7394/2s93i;tcp - with new c- format: v=0 o=alice 2890844526 2890844527 IN IP4 alice.example.com s= m=message 9 msrp * c=IN MSRP-PATH msrp://a.example.com:7394/2s93i;tcp a=accept-types:text/plain Another example with relays and multiple sessions: - as currently proposed: v=0 o=alice 2890844526 2890844527 IN IP4 alice.example.com s= c=IN IP4 alice.example.com m=message 9 msrp * a=accept-types:text/plain a=path:msrp://relay.example.com:9000/hjdhfha;tcp \ msrp://a.example.com:7394/2s93i;tcp m=message 10 msrp * a=accept-types:text/plain a=path:msrp://relay.example.com:9000/hjdhfha;tcp \ msrp://b.example.com:1234/fuige;tcp (Note the use of different port numbers. This makes the media streams independent of one another even though the address is otherwise the same. It can be used because the port is ignored.) - with info replicated in c- and m-: v=0 o=alice 2890844526 2890844527 IN IP4 alice.example.com s= m=message 9000 msrp * c=IN IP4 relay.example.com a=accept-types:text/plain a=path:msrp://relay.example.com:9000/hjdhfha;tcp \ msrp://a.example.com:7394/2s93i;tcp m=message 9000 msrp * c=IN IP4 relay.example.com a=accept-types:text/plain a=path:msrp://relay.example.com:9000/hjdhfha;tcp \ msrp://b.example.com:1234/fuige;tcp (Note that this doesn't work right! We have two media sessions with the same transport address, but which are not alternatives.) - with new c- format: v=0 o=alice 2890844526 2890844527 IN IP4 alice.example.com s= m=message 9 msrp * c=IN MSRP-PATH msrp://relay.example.com:9000/hjdhfha;tcp \ msrp://a.example.com:7394/2s93i;tcp a=accept-types:text/plain m=message 9 msrp * c=IN MSRP-PATH msrp://relay.example.com:9000/hjdhfha;tcp \ msrp://b.example.com:1234/fuige;tcp a=accept-types:text/plain (Note that here I am assuming we can use port 9 all the time, because the media sessions have different values for the c-line.) Is this better than what is currently proposed in draft-ietf-simple-message-sessions-09? Debatable. Does it come closer to the spirit of SDP? Also debatable. Paul Paul Kyzivat wrote: > > > Colin Perkins wrote: > >> On 3 Jan 2005, at 17:11, Hisham Khartabil wrote: >> >>> I don't see the need. The information in the c and m line will be >>> ignored anyway by the receiver, so why waste CPU cycles? >> >> >> Because SDP requires the "c=" and "m=" lines to indicate where the >> media is sent, and because there could be a middlebox or other device >> processing the SDP that needs that information. > > > For a middlebox to work with this, it must understand the *semantics*, > not just the syntax. Even if we were to use the m- and c- lines as > requested, a middlebox without specific knowledge of msrp will not know > what to do: is the tcp, udp, rtp, or what? > > And in the case of msrp, the msrp relay *is* the middlebox, and the sdp > syntax has been designed specifically to accomodate it. > >>> Also, backwards compatible with what? >> >> >> Other devices that parse SDP, some of which may be outside your control. > > > I still don't buy this. There is no issue of *parsing* the SDP. Nothing > we have done is inconsistent with SDP parsing. > > I think the issue you are alluding to must be more to "implementing" SDP > to a greater extent than just parsing it. But in all cases the semantics > are a function of the particular transport. Its not clear to me that are > any standard semantics. > > Colin - I would like to hear exactly what you think can be implemented > generically across all transports, including unknown ones. > > Paul > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 4 21:53:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16697; Tue, 4 Jan 2005 21:53:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm1VM-0007IN-1c; Tue, 04 Jan 2005 22:06:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm15q-0002tq-K7; Tue, 04 Jan 2005 21:40:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm132-0001wq-31; Tue, 04 Jan 2005 21:37:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15412; Tue, 4 Jan 2005 21:37:18 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm1FW-0006uU-6W; Tue, 04 Jan 2005 21:50:14 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 04 Jan 2005 19:42:56 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j052W6l2028524; Tue, 4 Jan 2005 18:32:06 -0800 (PST) Received: from [10.0.45.182] (sjc-vpn7-653.cisco.com [10.21.146.141]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AVF54429; Tue, 4 Jan 2005 18:32:06 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 04 Jan 2005 19:35:09 -0500 Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern From: Cullen Jennings To: Joerg Ott , Paul H Kyzivat Message-ID: In-Reply-To: <41DAD42A.4060508@tzi.uni-bremen.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" , Adam Roach , "simple@ietf.org" , Colin Perkins X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit On 1/4/05 9:36 AM, "Joerg Ott" wrote: > 1. Need for Relays I view the primary need for relays was around logging and policy control. Things like filtering for viruses. People have allowed IM to do things like email and expect to be able to apply similar policy and control to it. Luckily I'm not aware of any reported virus sent over T.38 yet but there are virus that can propagate over IM. Systems apply policy to the signaling of all the media - things like who can talk to who. However they don't apply policy to the semantic content of audio or video because the state of the art does not allow for automatic interpretation of it well enough to apply policy. However, text based media such as IM and email people do want to apply policy to the content. Brokerage firms filter on key words that can be sent from certain types of users to others. Many people check for viruses. If this is used only for NAT traversal, the exit mechanism is the same as STUN where devices that were not behind a NAT just do not use a relay. The behave wg is having pretty good luck forming peer to peer TCP connections between endpoints that are both behind NATs so it's even hopeful that relays would not always be needed even if there still were NATs. The motivation text in the document may need some update - there were many long threads on the need for relays and I'm not sure that the document captured all that. Once the WG all agreed they were needed, we were pretty worn down on documenting all the detail of how we came to that decision. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From kieokpmmqi@msn.com Wed Jan 5 06:35:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24349; Wed, 5 Jan 2005 06:35:50 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm9el-0001ia-Vv; Wed, 05 Jan 2005 06:48:53 -0500 Received: from bip123.neoplus.adsl.tpnet.pl ([83.28.131.123]) by mx2.foretec.com with smtp (Exim 4.24) id 1Cm9S9-0006O7-Fj; Wed, 05 Jan 2005 06:35:52 -0500 Received: from .anu..au ([194.22.192.209] helo=anu..au) by smtp6..co with esmtp id 1A5Ys6-636113-28 Message-ID: Sender: freeradius-devel-kieokpmmqi@msn.com X-Mailman-Version: 2.0.1 Date: Wed, 05 Jan 2005 06:24:18 -0500 From: "Henry Duarte" To: simple-archive@ietf.org, simple-request@ietf.org, simple-web-archive@ietf.org, sip@ietf.org, sip-admin@ietf.org, sip-request@ietf.org, sip-security@ietf.org, sip-security-admin@ietf.org, sip-security-web-archive@ietf.org Subject: SU-per Hu^ge 0ffers Simple-archive X-Spam-Score: 3.0 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Huge offer for Viicodin, Viagraa, Vallium and lots moreee... savee up to 7o% meds on our stores. Visit uss today http://coolhealth.info/in.php?aid=56 Happy New Year cCiL3YksFsTNWwfWRcnyfrGrM9IrOc54laZeKEASL4u5exO4Drehlolm03GV From simple-bounces@ietf.org Wed Jan 5 09:43:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08313; Wed, 5 Jan 2005 09:43:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmCaU-0006Ce-R4; Wed, 05 Jan 2005 09:56:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmCLz-0005Ru-AF; Wed, 05 Jan 2005 09:41:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClscX-0003dZ-AT; Tue, 04 Jan 2005 12:37:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00552; Tue, 4 Jan 2005 12:37:22 -0500 (EST) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clsov-0002EG-4B; Tue, 04 Jan 2005 12:50:14 -0500 Received: from tzi.uni-bremen.de (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j04HajKu018198; Tue, 4 Jan 2005 18:36:53 +0100 (MET) Message-ID: <41DAD42A.4060508@tzi.uni-bremen.de> Date: Tue, 04 Jan 2005 18:36:42 +0100 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> <41D0955B.2080704@nostrum.com> <4E86F292-5DA8-11D9-A1D2-000D93B0AE1A@nostrum.com> <768E41B2-5DAA-11D9-9BB1-000D93C60BA0@telio.no> <41DA164E.40603@cisco.com> In-Reply-To: <41DA164E.40603@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 05 Jan 2005 09:41:37 -0500 Cc: Simple WG , Adam Roach , Colin Perkins , mmusic@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit The essence of what I hear (or read) Paul saying is: From SDP, we need the "m=" part to delimit streams and to identify something as MSRP. There may be a few common attributes and further fields but do not count on them because the rest is up to the interpretation per media protocol. This viewpoint doesn't really convince me at this point. We have numerous rules and extensions for SDP (preconditions, labels, etc.), and I haven't yet gone through the exercise to find out whether such a "usage" of SDP would actually work with all of these. (This does not mean that I would like this approach even if we can make this work.) But leaving alone the "ugliness" issue for the moment, I would like to discuss two issues so that we can take a meaningful decision and move on: 1. Need for Relays MSRP motivates relays primarily by NAT/firewall traversal. But, of course, it would be much nicer if two endpoints could talk to each other directly (rather than via an intermediary). Then, we would not really need multiplexing (unless maybe two gateways talk -- which is conceptually different) and a single m=/c= line would be sufficient (and might simply reuse comedia and be done with it). Hence, what we are arguing over is a (potentially endlessly lasting) interim solution until we get the connectivity right. If there was a way to do something like ICE here as well, we would be done with it. So, how much hassle are we willing to take up to make the interim solution work. This should add to the basic version instead of having the basic version designed as a special case of the interim. 2. Generality Assuming that there is a need for a stepwise connection via some relay (and that this will never go away), I suspect that MSRP will not be only application protocol that is going to need it. T.38 via TCP may be another example and so may a shared PowerPoint presetation or VNC application. Then, I would like to have a general solution developed that is _not_ specific to MSRP and is documented as such. We would need to design something like draft-*-comedia-muxed-via-relays rather than having one specific solution now and coming up with another one every week. This appears to call for some explicitly spelled out requirements rather than a detailed discussion about a partial technical solution. Joerg Paul Kyzivat wrote: > > > Colin Perkins wrote: > >> On 3 Jan 2005, at 17:11, Hisham Khartabil wrote: >> >>> I don't see the need. The information in the c and m line will be >>> ignored anyway by the receiver, so why waste CPU cycles? >> >> >> Because SDP requires the "c=" and "m=" lines to indicate where the >> media is sent, and because there could be a middlebox or other device >> processing the SDP that needs that information. > > > For a middlebox to work with this, it must understand the *semantics*, > not just the syntax. Even if we were to use the m- and c- lines as > requested, a middlebox without specific knowledge of msrp will not know > what to do: is the tcp, udp, rtp, or what? > > And in the case of msrp, the msrp relay *is* the middlebox, and the sdp > syntax has been designed specifically to accomodate it. > >>> Also, backwards compatible with what? >> >> >> Other devices that parse SDP, some of which may be outside your control. > > > I still don't buy this. There is no issue of *parsing* the SDP. Nothing > we have done is inconsistent with SDP parsing. > > I think the issue you are alluding to must be more to "implementing" SDP > to a greater extent than just parsing it. But in all cases the semantics > are a function of the particular transport. Its not clear to me that are > any standard semantics. > > Colin - I would like to hear exactly what you think can be implemented > generically across all transports, including unknown ones. > > Paul > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 5 09:45:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08508; Wed, 5 Jan 2005 09:45:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmCch-0006Fl-Oc; Wed, 05 Jan 2005 09:58:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmCLz-0005T9-WC; Wed, 05 Jan 2005 09:41:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm129-0001ck-8f; Tue, 04 Jan 2005 21:36:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15315; Tue, 4 Jan 2005 21:36:23 -0500 (EST) Received: from mta7.srv.hcvlny.cv.net ([167.206.5.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm1Eb-0006tq-7q; Tue, 04 Jan 2005 21:49:19 -0500 Received: from Nadia (ool-44c6903d.dyn.optonline.net [68.198.144.61]) by mta7.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with SMTP id <0I9T00I14OKLPN@mta7.srv.hcvlny.cv.net>; Tue, 04 Jan 2005 21:36:22 -0500 (EST) Date: Tue, 04 Jan 2005 21:36:22 -0500 From: prarch Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern To: Paul Kyzivat , Colin Perkins Message-id: <056501c4f2cf$581b9050$3d90c644@Nadia> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> <41D0955B.2080704@nostrum.com> <4E86F292-5DA8-11D9-A1D2-000D93B0AE1A@nostrum.com> <768E41B2-5DAA-11D9-9BB1-000D93C60BA0@telio.no> <41DA164E.40603@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Wed, 05 Jan 2005 09:41:37 -0500 Cc: Joerg Ott , Adam Roach , mmusic@ietf.org, Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7BIT A new start up company located in New York, NY in VoIP/Telephony software space is looking for software architects and developers. 1.. Network Management Software product architects 2.. SNMP/MIB architects and developers 3.. Voice application product architects 4.. Voice protocol architects and developers 5.. Application GUI architects and developers 6.. Technical marketing and product engineering 7.. Sales engineers Please send your resume to prarch@optonline.net ----- Original Message ----- From: "Paul Kyzivat" To: "Colin Perkins" Cc: "Joerg Ott" ; "Adam Roach" ; ; "Simple WG" Sent: Monday, January 03, 2005 11:06 PM Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern > > > Colin Perkins wrote: >> On 3 Jan 2005, at 17:11, Hisham Khartabil wrote: >> >>> I don't see the need. The information in the c and m line will be >>> ignored anyway by the receiver, so why waste CPU cycles? >> >> Because SDP requires the "c=" and "m=" lines to indicate where the media >> is sent, and because there could be a middlebox or other device >> processing the SDP that needs that information. > > For a middlebox to work with this, it must understand the *semantics*, not > just the syntax. Even if we were to use the m- and c- lines as requested, > a middlebox without specific knowledge of msrp will not know what to do: > is the tcp, udp, rtp, or what? > > And in the case of msrp, the msrp relay *is* the middlebox, and the sdp > syntax has been designed specifically to accomodate it. > >>> Also, backwards compatible with what? >> >> Other devices that parse SDP, some of which may be outside your control. > > I still don't buy this. There is no issue of *parsing* the SDP. Nothing we > have done is inconsistent with SDP parsing. > > I think the issue you are alluding to must be more to "implementing" SDP > to a greater extent than just parsing it. But in all cases the semantics > are a function of the particular transport. Its not clear to me that are > any standard semantics. > > Colin - I would like to hear exactly what you think can be implemented > generically across all transports, including unknown ones. > > Paul > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 5 09:48:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08670; Wed, 5 Jan 2005 09:48:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmCf6-0006KE-AG; Wed, 05 Jan 2005 10:01:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmCM0-0005Tj-Lk; Wed, 05 Jan 2005 09:41:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm13u-0002E4-FV; Tue, 04 Jan 2005 21:38:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15455; Tue, 4 Jan 2005 21:38:12 -0500 (EST) Received: from mta1.srv.hcvlny.cv.net ([167.206.5.67]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm1GO-0006wk-Ic; Tue, 04 Jan 2005 21:51:08 -0500 Received: from Nadia (ool-44c6903d.dyn.optonline.net [68.198.144.61]) by mta1.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with SMTP id <0I9T0055MOMO1Q@mta1.srv.hcvlny.cv.net>; Tue, 04 Jan 2005 21:37:37 -0500 (EST) Date: Tue, 04 Jan 2005 21:37:37 -0500 From: prarch Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern To: Paul Kyzivat , Colin Perkins Message-id: <058301c4f2cf$85280100$3d90c644@Nadia> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> <41D0955B.2080704@nostrum.com> <4E86F292-5DA8-11D9-A1D2-000D93B0AE1A@nostrum.com> <768E41B2-5DAA-11D9-9BB1-000D93C60BA0@telio.no> <41DA164E.40603@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Wed, 05 Jan 2005 09:41:37 -0500 Cc: Joerg Ott , Adam Roach , mmusic@ietf.org, Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7BIT A new start up company located in New York, NY in VoIP/Telephony software space is looking for software architects and developers. 1.. Network Management Software product architects 2.. SNMP/MIB architects and developers 3.. Voice application product architects 4.. Voice protocol architects and developers 5.. Application GUI architects and developers 6.. Technical marketing and product engineering 7.. Sales engineers Please send your resume to prarch@optonline.net ----- Original Message ----- From: "Paul Kyzivat" To: "Colin Perkins" Cc: "Joerg Ott" ; "Adam Roach" ; ; "Simple WG" Sent: Monday, January 03, 2005 11:06 PM Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern > > > Colin Perkins wrote: >> On 3 Jan 2005, at 17:11, Hisham Khartabil wrote: >> >>> I don't see the need. The information in the c and m line will be >>> ignored anyway by the receiver, so why waste CPU cycles? >> >> Because SDP requires the "c=" and "m=" lines to indicate where the media >> is sent, and because there could be a middlebox or other device >> processing the SDP that needs that information. > > For a middlebox to work with this, it must understand the *semantics*, not > just the syntax. Even if we were to use the m- and c- lines as requested, > a middlebox without specific knowledge of msrp will not know what to do: > is the tcp, udp, rtp, or what? > > And in the case of msrp, the msrp relay *is* the middlebox, and the sdp > syntax has been designed specifically to accomodate it. > >>> Also, backwards compatible with what? >> >> Other devices that parse SDP, some of which may be outside your control. > > I still don't buy this. There is no issue of *parsing* the SDP. Nothing we > have done is inconsistent with SDP parsing. > > I think the issue you are alluding to must be more to "implementing" SDP > to a greater extent than just parsing it. But in all cases the semantics > are a function of the particular transport. Its not clear to me that are > any standard semantics. > > Colin - I would like to hear exactly what you think can be implemented > generically across all transports, including unknown ones. > > Paul > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 5 09:49:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08830; Wed, 5 Jan 2005 09:49:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmCgb-0006Mn-Ao; Wed, 05 Jan 2005 10:02:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmCM1-0005U5-2L; Wed, 05 Jan 2005 09:41:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm1Il-0007IW-7G for simple@megatron.ietf.org; Tue, 04 Jan 2005 21:53:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16691 for ; Tue, 4 Jan 2005 21:53:33 -0500 (EST) Received: from mta3.srv.hcvlny.cv.net ([167.206.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm1VE-0007I9-Ii for simple@ietf.org; Tue, 04 Jan 2005 22:06:29 -0500 Received: from Nadia (ool-44c6903d.dyn.optonline.net [68.198.144.61]) by mta3.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with SMTP id <0I9T007CUPD1KI@mta3.srv.hcvlny.cv.net> for simple@ietf.org; Tue, 04 Jan 2005 21:53:26 -0500 (EST) Date: Tue, 04 Jan 2005 21:53:26 -0500 From: prarch To: Message-id: <063b01c4f2d1$bad9d060$3d90c644@Nadia> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> <41D0955B.2080704@nostrum.com> <4E86F292-5DA8-11D9-A1D2-000D93B0AE1A@nostrum.com> <768E41B2-5DAA-11D9-9BB1-000D93C60BA0@telio.no> <41DA164E.40603@cisco.com> <41DAD42A.4060508@tzi.uni-bremen.de> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Wed, 05 Jan 2005 09:41:37 -0500 Subject: [Simple] VoIP/Telephony Opportunity X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT A new start up company located in New York, NY in VoIP/Telephony software space is looking for software architects and developers. 1.. Network Management Software product architects 2.. SNMP/MIB architects and developers 3.. Voice application product architects 4.. Voice protocol architects and developers 5.. Application GUI architects and developers 6.. Technical marketing and product engineering 7.. Sales engineers Please send your resume to prarch@optonline.net _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 5 11:11:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17144; Wed, 5 Jan 2005 11:11:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmDxQ-0000DA-My; Wed, 05 Jan 2005 11:24:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmDiz-0008Q8-TP; Wed, 05 Jan 2005 11:09:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmDeK-00073X-N3 for simple@megatron.ietf.org; Wed, 05 Jan 2005 11:04:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16608 for ; Wed, 5 Jan 2005 11:04:37 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmDqv-0008Sa-28 for simple@ietf.org; Wed, 05 Jan 2005 11:17:42 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2005 08:04:32 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j05G441Z025508 for ; Wed, 5 Jan 2005 08:04:06 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOC34946; Wed, 5 Jan 2005 11:04:03 -0500 (EST) Message-ID: <41DC0FF3.4090606@cisco.com> Date: Wed, 05 Jan 2005 11:04:03 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-ietf-simple-event-list-07 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit One nit on this document: Section 4.1: Sending of "Supported: eventlist" in a NOTIFY message is meaningless and silly. Implementations SHOULD NOT include "Supported: eventlist" in any requests except for SUBSCRIBE. This seems a bit harsh. Currently the rules for when to send Supported are very fuzzy. But ideally there should be some standard approach, rather than having to decide on an option-by-option *and* message-by-message basis whether a particular option tag should be declared. In any case the above seems to say that the supported: eventlist not be included in OPTIONS, which is clearly wrong. Pending the development of some standard guidance on this subject, I think it would be sufficient to replace the above with: Sending of "Supported: eventlist" in a NOTIFY message is meaningless and unnecessary. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jan 6 13:36:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29991; Thu, 6 Jan 2005 13:36:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmchJ-0007T1-TU; Thu, 06 Jan 2005 13:49:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmcJc-00073r-52; Thu, 06 Jan 2005 13:24:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmcGe-0006IW-0S; Thu, 06 Jan 2005 13:21:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29121; Thu, 6 Jan 2005 13:21:49 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmcTO-0006oq-2K; Thu, 06 Jan 2005 13:35:07 -0500 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j06ILbVu031640 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 6 Jan 2005 12:21:38 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: <41DAFA0F.9070805@cisco.com> References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> <41D0955B.2080704@nostrum.com> <4E86F292-5DA8-11D9-A1D2-000D93B0AE1A@nostrum.com> <768E41B2-5DAA-11D9-9BB1-000D93C60BA0@telio.no> <41DA164E.40603@cisco.com> <41DAFA0F.9070805@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: From: Ben Campbell Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern Date: Thu, 6 Jan 2005 12:21:30 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: mmusic@ietf.org, Joerg Ott , Colin Perkins , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2033744626==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --===============2033744626== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-26955797; protocol="application/pkcs7-signature" --Apple-Mail-3-26955797 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jan 4, 2005, at 2:18 PM, Paul Kyzivat wrote: [...] [Lots of text removed concerning moving the MSRP path from an a-line into the c-line] > Is this better than what is currently proposed in > draft-ietf-simple-message-sessions-09? Debatable. > > Does it come closer to the spirit of SDP? Also debatable. > It also seems like it would also have a higher chance of breaking existing parsers than the a-line attribute approach. [...] --Apple-Mail-3-26955797 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGEjCCAssw ggI0oAMCAQICAwwdSDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwNDEyMjA0NTUyWhcNMDUwNDEyMjA0NTUyWjBBMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR4wHAYJKoZIhvcNAQkBFg9iZW5Abm9zdHJ1bS5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGFv8c1i8a9NXiEohMEryzypOcyz39k8PN WxTS4F45JSYwQ0/RAZ4vaemHCyJaUc7tc5DN3o7zl2oaqQuOIrvnjk79ILGJVfRgwt+uGDIGyaSM YmBeKXSdawFiJdk5jGtMzlgF8tzJzc4do5Mzl5YS39AR8mj8PF4zEgIlYYkKXBByHQ2jPA0qVfm/ Aj71RdYZyDAD4P7TyW9jKvZCl7KCfajar1llEQVj+kWMvt/3AE6mwAHXfkU7nL9XzLvGSnMUJvYx hq3UDju4IacXsYFw2oLb4LQdvwP4Lbg6qdp08h59+TkHlV6WNdt3ggM9C/cGQTDCa0CVJsr+76Dm mPorAgMBAAGjLDAqMBoGA1UdEQQTMBGBD2JlbkBub3N0cnVtLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBAUAA4GBAApFAg5tsI2OhByoUglTZ+ip3M/1xfWDsCNsDB4+HtnH9fZfKkrkGp4e JQyuvl5VhvW67qYU6wEPMD0EKoWDU3v7l1huzR7Cpkf7n21y4LLG+VxldYiA3SEkv7RBPhhVhdMl sHwNZAYyVXFCdnvuVjfeytdAeXK6vzcaUvo9EwkHMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0B AQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv biBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAw MDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoT zyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GU MIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3 dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQ g+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsA xRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXe JLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMMHUgwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMDUwMTA2MTgyMTMxWjAjBgkqhkiG9w0BCQQxFgQUJ3fPjsAU2/lqb4F3 gUTm0vwa+ncweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0ECAwwdSDB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMHUgwDQYJKoZIhvcNAQEBBQAEggEAapvqcgWcLTdSGKhT JvE4ikfSg1VesI8e1O+5ZFanTFpMSe4NSo7I6H9jnv/9NwW4AcK9KZS/39P1PkL6/p2QEVWE6m0a 0MXRFqBDf6xicLgiaTmiYOajElVnkok54YNWMEDcTox/iKrgWP8AJtd+IyeDYJjP/MxzEEVNBYb/ JTQnRpSHXTOqmiBW3auTJUEfZL5I5nDky8V+VPoMKkxC/cArWyt60wOF9f7GTRLS7/xEBsqXFWJR DL2ucyvVM8ueBOUsuo/V+VVdZnEt3W3XT6zsSDy/Ib/rfwmFpl6tTduwYr5KpE/LFNhbHQlDnpj/ 3QSCJIvH3nTxmn68wh4P7AAAAAAAAA== --Apple-Mail-3-26955797-- --===============2033744626== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============2033744626==-- From simple-bounces@ietf.org Thu Jan 6 15:54:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15437; Thu, 6 Jan 2005 15:54:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmeqv-00008I-Jd; Thu, 06 Jan 2005 16:07:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmeX3-0007ve-B2; Thu, 06 Jan 2005 15:46:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmeQP-0003KA-S3 for simple@megatron.ietf.org; Thu, 06 Jan 2005 15:40:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14315 for ; Thu, 6 Jan 2005 15:40:03 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmedF-00083T-0o for simple@ietf.org; Thu, 06 Jan 2005 15:53:22 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j06KdTqH018531; Thu, 6 Jan 2005 14:39:29 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j06KdTq19247; Thu, 6 Jan 2005 14:39:29 -0600 (CST) Message-ID: <41DDA200.7080600@lucent.com> Date: Thu, 06 Jan 2005 14:39:28 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41B67ECE.4000300@cs.columbia.edu> In-Reply-To: <41B67ECE.4000300@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > We've gotten ourselves stuck lately in a few places in the presence > data model. In particular, folks have come forward with requirements > for having multiple services with the same URI. The use cases that > have been brought forward include: > > 1. I have a softphone on my PC that is one integrated application, > available at one AOR with one contact/gruu. I'd like to be able to say > that I'm available for IM but not available for voice. Jonathan: More feedback on the dispatchers is in a later email; but I do have one question on the above scenario, though. Why is this hard to do with the current data model? Is it not the case that a composer could publish a document with two tuples; both will have the same Contact URI, but different servcaps method. The tuple with the INVITE servcap will have the priority attribute of contact element set to 0; the one with the MESSAGE servcap will have the priority attribute of the contact element set to > 0.0? A watcher making a routing decision based on such a document has all the information it needs, no? Or am I missing something? - 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-bounces@ietf.org Thu Jan 6 18:01:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03429; Thu, 6 Jan 2005 18:01:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmgqY-0006WK-Gp; Thu, 06 Jan 2005 18:15:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmgcY-0004V6-Il; Thu, 06 Jan 2005 18:00:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmgc3-0003rh-Ca for simple@megatron.ietf.org; Thu, 06 Jan 2005 18:00:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03295 for ; Thu, 6 Jan 2005 18:00:12 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmgou-0006Qi-6q for simple@ietf.org; Thu, 06 Jan 2005 18:13:33 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 06 Jan 2005 16:10:49 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j06Mxbvl019663; Thu, 6 Jan 2005 14:59:38 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOD60984; Thu, 6 Jan 2005 17:59:38 -0500 (EST) Message-ID: <41DDC2DA.1080304@cisco.com> Date: Thu, 06 Jan 2005 17:59:38 -0500 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: "Vijay K. Gurbani" Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41B67ECE.4000300@cs.columbia.edu> <41DDA200.7080600@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Jonathan Rosenberg wrote: > >> We've gotten ourselves stuck lately in a few places in the presence >> data model. In particular, folks have come forward with requirements >> for having multiple services with the same URI. The use cases that >> have been brought forward include: >> >> 1. I have a softphone on my PC that is one integrated application, >> available at one AOR with one contact/gruu. I'd like to be able to say >> that I'm available for IM but not available for voice. > > > Jonathan: > > More feedback on the dispatchers is in a later email; but I do > have one question on the above scenario, though. > > Why is this hard to do with the current data model? Is it not > the case that a composer could publish a document with two tuples; > both will have the same Contact URI, but different servcaps method. > The tuple with the INVITE servcap will have the priority > attribute of contact element set to 0; the one with the > MESSAGE servcap will have the priority attribute of the > contact element set to > 0.0? A watcher making a routing > decision based on such a document has all the information it > needs, no? I agree this can be done (well) with the current model - but I disagree with the way you propose. I imagine the device Jonathan is describing is capable (in general) of doing both voice and IM, together or separately, but is currently unavailable for voice. This should preferably be represented as a single tuple, so that both voice and IM can be represented together. The fact that they could also be used separately is implicit in the way capabilities are described. The single tuple can be open, specifying audio as unavailable, message (the media - i.e. msrp - for session mode IM) as available, and method=MESSAGE as available (for page mode IM). Later, when voice is also available, this tuple can be updated to reflect that small change. The thing that is currently hard to model is mutual exclusion - when this softphone can do *either* voice, or IM, but not both concurrently. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jan 6 18:10:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04288; Thu, 6 Jan 2005 18:10:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmgyX-0006xm-Nm; Thu, 06 Jan 2005 18:23:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmgkG-0002Ym-Er; Thu, 06 Jan 2005 18:08:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmgjG-0001xG-NS for simple@megatron.ietf.org; Thu, 06 Jan 2005 18:07:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04002 for ; Thu, 6 Jan 2005 18:07:40 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmgw8-0006pI-K6 for simple@ietf.org; Thu, 06 Jan 2005 18:21:00 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j06N79U7001091; Thu, 6 Jan 2005 17:07:09 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j06N79q09917; Thu, 6 Jan 2005 17:07:09 -0600 (CST) Message-ID: <41DDC49D.7040802@lucent.com> Date: Thu, 06 Jan 2005 17:07:09 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41B67ECE.4000300@cs.columbia.edu> <41DDA200.7080600@lucent.com> <41DDC2DA.1080304@cisco.com> In-Reply-To: <41DDC2DA.1080304@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > I agree this can be done (well) with the current model - but I disagree > with the way you propose. > > I imagine the device Jonathan is describing is capable (in general) of > doing both voice and IM, together or separately, but is currently > unavailable for voice. > > This should preferably be represented as a single tuple, Paul: Please help me understand -- is this a requirement (i.e., a single tuple be used to represent different capabilities)? Clearly we have the atomic parts to model this -- the tuples could be tied together by a device-id so that the watcher knows that we are referring to the same device... > The thing that is currently hard to model is mutual exclusion - when > this softphone can do *either* voice, or IM, but not both concurrently. In a single tuple, yes. But then again, is this a requirement somewhere that I may have missed? 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-bounces@ietf.org Thu Jan 6 18:25:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05725; Thu, 6 Jan 2005 18:25:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmhDa-0007Lh-37; Thu, 06 Jan 2005 18:39:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmgwp-0004rz-EC; Thu, 06 Jan 2005 18:21:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmgwT-0004Wx-Ku for simple@megatron.ietf.org; Thu, 06 Jan 2005 18:21:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05478 for ; Thu, 6 Jan 2005 18:21:18 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmh9I-0007EJ-FO for simple@ietf.org; Thu, 06 Jan 2005 18:34:40 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 06 Jan 2005 15:21:26 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j06NKh1X002373; Thu, 6 Jan 2005 15:20:43 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOD62582; Thu, 6 Jan 2005 18:20:41 -0500 (EST) Message-ID: <41DDC7C9.1060702@cisco.com> Date: Thu, 06 Jan 2005 18:20:41 -0500 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: "Vijay K. Gurbani" Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41B67ECE.4000300@cs.columbia.edu> <41DDA200.7080600@lucent.com> <41DDC2DA.1080304@cisco.com> <41DDC49D.7040802@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Paul Kyzivat wrote: > >> I agree this can be done (well) with the current model - but I >> disagree with the way you propose. >> >> I imagine the device Jonathan is describing is capable (in general) of >> doing both voice and IM, together or separately, but is currently >> unavailable for voice. >> >> This should preferably be represented as a single tuple, > > > Paul: > > Please help me understand -- is this a requirement (i.e., a single > tuple be used to represent different capabilities)? Is there a requirement that a publisher must *use* a single tuple to represent different capabilities? No. There are hardly any requirements on how this stuff must be used. Is there a requirement that it be *possible* to use a single tuple to represent different capabilities? In my mind the answer is yes. In any case, requirement or not, it is possible with RPID. > Clearly we > have the atomic parts to model this -- the tuples could be tied > together by a device-id so that the watcher knows that we are > referring to the same device... Ah. But is that the same as saying they may be used concurrently? (My device is both a floor mop *and* a pogo stick. But it can't do both at the same time.) I imagine that the *advanced* presence enabled client will filter the set of tuples and capabilities down to the ones it has the ability to use, and display those to me. Then I can pick one to establish communications with. I would be making my decision on which to pick based on availability for the media I want to use. >> The thing that is currently hard to model is mutual exclusion - when >> this softphone can do *either* voice, or IM, but not both concurrently. > > In a single tuple, yes. But then again, is this a requirement > somewhere that I may have missed? I've lost what the current proposal is right now. You can express this with multiple tuples identifying the same contact, *if* we don't treat that as an override. That is part of the argument. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jan 6 23:53:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28665; Thu, 6 Jan 2005 23:53:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmmKZ-0005Mk-QK; Fri, 07 Jan 2005 00:06:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmm6D-0006EG-By; Thu, 06 Jan 2005 23:51:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmm3u-0005Cs-PL for simple@megatron.ietf.org; Thu, 06 Jan 2005 23:49:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28482 for ; Thu, 6 Jan 2005 23:49:20 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmmGp-000572-75 for simple@ietf.org; Fri, 07 Jan 2005 00:02:44 -0500 Received: from [10.42.2.141] ([66.228.72.30]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j074nIh2082602 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 6 Jan 2005 22:49:20 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: simple@ietf.org From: Robert Sparks Date: Thu, 6 Jan 2005 22:49:16 -0600 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Subject: [Simple] Moving the presence data model work forward X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit We seem to have ground to a halt again on finishing the Presence Data Model. This is blocking a very large portion of the rest of our work. The current sticking point is, at its core, about where we are drawing the line for a baseline composition algorithm. We've looked several times at whether we would try to provide a complete standardized composition system, and have consistently come to the conclusion that the task is vastly difficult. We've agreed to build a minimal system that would not preclude work on more complex standardized composition in the future. We've achieved consensus around a using simple union as the baseline mechanism. Anything more would be something done outside a standard. We recognize that this means that different services may do different things with the same inputs, but until we have more deployment experience, doing much more is a "boiling the ocean" class problem. To hopefully avoid some of the problems that might arise with that compromise, the Presence Data Model work tried to add two important things: - It introduced a structure that made it more likely that elements creating presence documents would put information in consistent places. This reduces ambiguity and makes it more likely that the intent of the document will be rendered accurately across different implementations. - It tried to take one more step towards a more complex composition policy by defining what identifies a service tuple, so that compositors would have a standard algorithm for choosing to combine information about the "same service" from different sources. The effort was very successful on the first point. We have not yet achieved consensus around the second. To reach agreement, we will need either to back up to something closer to our previous consensus point, or go further towards a complete standard composition system. In order to allow the document suite that is blocked on this conversation to go forward, so that we can get implementation and deployment experience, I believe it will be necessary to step back: - We keep the representation model in the PDM work - and have been accepted as useful. - We maintain the notion that tuples with contacts are "services", but don't try to standardize what "same service" means at this time beyond the basic tools that PIDF gives us. - We break out discussion of a more complete standard composition system into a separate document -> AND TABLE IT <- until the current document suite is done. This is a clearly a compromise position - it would be better if we _could_ specify a more fleshed out composition mechanism, but history indicates that this is not likely to happen. Lets get this base mechanism out there so we can get some more real-world data to help guide the later debate. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 7 09:00:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14987; Fri, 7 Jan 2005 09:00:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmusZ-00083C-LZ; Fri, 07 Jan 2005 09:14:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmuXU-0006ou-RG; Fri, 07 Jan 2005 08:52:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmuUq-0005i6-JO for simple@megatron.ietf.org; Fri, 07 Jan 2005 08:49:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14256 for ; Fri, 7 Jan 2005 08:49:43 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmuhp-0006zm-Bb for simple@ietf.org; Fri, 07 Jan 2005 09:03:10 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 07 Jan 2005 09:01:11 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j07DnAW0027758; Fri, 7 Jan 2005 08:49:10 -0500 (EST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOD91011; Fri, 7 Jan 2005 08:49:09 -0500 (EST) Message-ID: <41DE9355.5080004@cisco.com> Date: Fri, 07 Jan 2005 08:49:09 -0500 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 Subject: Re: [Simple] Moving the presence data model work forward References: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Robert - thanks! I am in agreement that this is the way forward. Paul Robert Sparks wrote: > We seem to have ground to a halt again on finishing > the Presence Data Model. This is blocking a very large > portion of the rest of our work. > > The current sticking point is, at its core, about where > we are drawing the line for a baseline composition > algorithm. > > We've looked several times at whether we would > try to provide a complete standardized composition > system, and have consistently come to the conclusion > that the task is vastly difficult. We've agreed to build > a minimal system that would not preclude work on > more complex standardized composition in the future. > > We've achieved consensus around a using simple > union as the baseline mechanism. Anything more > would be something done outside a standard. We > recognize that this means that different services may > do different things with the same inputs, but until we > have more deployment experience, doing much more > is a "boiling the ocean" class problem. > > To hopefully avoid some of the problems that might arise > with that compromise, the Presence Data Model work > tried to add two important things: > > - It introduced a structure that made it more likely > that elements creating presence documents would > put information in consistent places. This reduces > ambiguity and makes it more likely that the intent > of the document will be rendered accurately across > different implementations. > - It tried to take one more step towards a more complex > composition policy by defining what identifies a service > tuple, so that compositors would have a standard > algorithm for choosing to combine information about > the "same service" from different sources. > > The effort was very successful on the first point. We have > not yet achieved consensus around the second. To reach > agreement, we will need either to back up to something > closer to our previous consensus point, or go further towards > a complete standard composition system. > > In order to allow the document suite that is blocked > on this conversation to go forward, so that we can get > implementation and deployment experience, I believe > it will be necessary to step back: > > - We keep the representation model in the PDM work - > and have been accepted as useful. > > - We maintain the notion that tuples with contacts are "services", > but don't try to standardize what "same service" means at this > time beyond the basic tools that PIDF gives us. > > - We break out discussion of a more complete standard composition > system into a separate document -> AND TABLE IT <- until the > current document suite is done. > > This is a clearly a compromise position - it would be better > if we _could_ specify a more fleshed out composition mechanism, > but history indicates that this is not likely to happen. Lets get > this base mechanism out there so we can get some more > real-world data to help guide the later debate. > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 7 11:59:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27985; Fri, 7 Jan 2005 11:59:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmxfj-0006LC-IE; Fri, 07 Jan 2005 12:13:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmxKo-0003S6-Ev; Fri, 07 Jan 2005 11:51:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmx90-0007vY-Um for simple@megatron.ietf.org; Fri, 07 Jan 2005 11:39:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25690 for ; Fri, 7 Jan 2005 11:39:20 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmxM2-0004zj-01 for simple@ietf.org; Fri, 07 Jan 2005 11:52:50 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j07Gd5i08472; Fri, 7 Jan 2005 18:39:07 +0200 (EET) X-Scanned: Fri, 7 Jan 2005 18:38:54 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j07Gcs3p004587; Fri, 7 Jan 2005 18:38:54 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00j1qwD3; Fri, 07 Jan 2005 18:38:54 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j07GcWU16199; Fri, 7 Jan 2005 18:38:32 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 7 Jan 2005 18:38:26 +0200 Received: from esebe052.NOE.Nokia.com ([172.21.138.217]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 7 Jan 2005 18:38:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] Moving the presence data model work forward Date: Fri, 7 Jan 2005 18:38:26 +0200 Message-ID: Thread-Topic: [Simple] Moving the presence data model work forward Thread-Index: AcT0wiNXOY0XwQbVRuaCwKSbUsWIjQAE5FKA To: , X-OriginalArrivalTime: 07 Jan 2005 16:38:26.0682 (UTC) FILETIME=[4FC73DA0:01C4F4D7] X-Spam-Score: 0.3 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Robert, I basically agree with your proposal, since as you say, it seems the = only way to get things forward.=20 I completely agree with the data model with respect to how the presence = data is modeled as PERSON, SERVICE and DEVICE, and that a SERVICE is = described as a tuple according to PIDF (and vice versa, a tuple always = means a SERVICE). So please, let's go ahead with that part. What has not been agreeable is the current draft was the use of a = contact address to uniquely identify a tuple, and thus meaning that = several tuples within the same presence document with a common contact = address was not allowed. That tied the presence togeher with GRUUs, = which in my opinion should not be mandated. There was a proposal to = describe a dispatcher as a solution when there are multiple "services" = using a single contact, but perhaps that was a step toward too much = complexity. So what we are losing at this point would be the explicit (standardized) = override capability, to e.g. deal with false information coming from = another source. While I considered that feature important, I think it = might be best at this point to leave it out, and say that the _default_ = composition algorithm is a simple union. We can define further, = client-configurable, algorithms later on. So, splitting the data model and letting all of the other stuff go = forward is the best solution. Regards, Markus=20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Paul Kyzivat > Sent: 07 January, 2005 15:49 > To: Robert Sparks > Cc: simple@ietf.org > Subject: Re: [Simple] Moving the presence data model work forward >=20 >=20 > Robert - thanks! I am in agreement that this is the way forward. >=20 > Paul >=20 > Robert Sparks wrote: > > We seem to have ground to a halt again on finishing > > the Presence Data Model. This is blocking a very large > > portion of the rest of our work. > >=20 > > The current sticking point is, at its core, about where > > we are drawing the line for a baseline composition > > algorithm. > >=20 > > We've looked several times at whether we would > > try to provide a complete standardized composition > > system, and have consistently come to the conclusion > > that the task is vastly difficult. We've agreed to build > > a minimal system that would not preclude work on > > more complex standardized composition in the future. > >=20 > > We've achieved consensus around a using simple > > union as the baseline mechanism. Anything more > > would be something done outside a standard. We > > recognize that this means that different services may > > do different things with the same inputs, but until we > > have more deployment experience, doing much more > > is a "boiling the ocean" class problem. > >=20 > > To hopefully avoid some of the problems that might arise > > with that compromise, the Presence Data Model work > > tried to add two important things: > >=20 > > - It introduced a structure that made it more likely > > that elements creating presence documents would > > put information in consistent places. This reduces > > ambiguity and makes it more likely that the intent > > of the document will be rendered accurately across > > different implementations. > > - It tried to take one more step towards a more complex > > composition policy by defining what identifies a service > > tuple, so that compositors would have a standard > > algorithm for choosing to combine information about > > the "same service" from different sources. > >=20 > > The effort was very successful on the first point. We have > > not yet achieved consensus around the second. To reach > > agreement, we will need either to back up to something > > closer to our previous consensus point, or go further towards > > a complete standard composition system. > >=20 > > In order to allow the document suite that is blocked > > on this conversation to go forward, so that we can get > > implementation and deployment experience, I believe > > it will be necessary to step back: > >=20 > > - We keep the representation model in the PDM work - > > and have been accepted as useful. > >=20 > > - We maintain the notion that tuples with contacts are "services", > > but don't try to standardize what "same service" means at this > > time beyond the basic tools that PIDF gives us. > >=20 > > - We break out discussion of a more complete standard composition > > system into a separate document -> AND TABLE IT <- until the > > current document suite is done. > >=20 > > This is a clearly a compromise position - it would be better > > if we _could_ specify a more fleshed out composition mechanism, > > but history indicates that this is not likely to happen. Lets get > > this base mechanism out there so we can get some more > > real-world data to help guide the later debate. > >=20 > > RjS > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 7 14:14:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05625; Fri, 7 Jan 2005 14:14:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmzmU-00082N-Ss; Fri, 07 Jan 2005 14:28:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmzXY-0005qW-Kz; Fri, 07 Jan 2005 14:12:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmzX9-0005dF-PP for simple@megatron.ietf.org; Fri, 07 Jan 2005 14:12:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05509 for ; Fri, 7 Jan 2005 14:12:26 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmzk9-0007py-Bm for simple@ietf.org; Fri, 07 Jan 2005 14:25:56 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j07JCKdi007969; Fri, 7 Jan 2005 13:12:21 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j07JCKq24278; Fri, 7 Jan 2005 13:12:20 -0600 (CST) Message-ID: <41DEDF14.8030803@lucent.com> Date: Fri, 07 Jan 2005 13:12:20 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41B67ECE.4000300@cs.columbia.edu> <41DDA200.7080600@lucent.com> <41DDC2DA.1080304@cisco.com> <41DDC49D.7040802@lucent.com> <41DDC7C9.1060702@cisco.com> In-Reply-To: <41DDC7C9.1060702@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Is there a requirement that a publisher must *use* a single tuple to > represent different capabilities? No. There are hardly any requirements > on how this stuff must be used. > > Is there a requirement that it be *possible* to use a single tuple to > represent different capabilities? In my mind the answer is yes. In any > case, requirement or not, it is possible with RPID. Yes, it is. But the problem is that we do not use RPID to make a routing decision. RPID can contain conflicting information about the presentity in a single tuple (e.g. activity=steering and place-type =home). We do not make routing decisions based on RIPD; but we are making routing decisions based on whether a IM or voice can be used. Maybe it is not accurate to capture the state of the presentity in a single tuple when describing capabilities that lead to routing decisions. >> Clearly we >> have the atomic parts to model this -- the tuples could be tied >> together by a device-id so that the watcher knows that we are >> referring to the same device... > > Ah. But is that the same as saying they may be used concurrently? OK, then does it suffice to add a new attribute "concurrent=yes"; then when a single tuple contains servcaps of {MESSAGE, INVITE} then it is a good indication that it can do both concurrently. >>> The thing that is currently hard to model is mutual exclusion - when >>> this softphone can do *either* voice, or IM, but not both concurrently. If the softphone cannot do IM and voice concurrently, then it would publish two tuples as I suggested earlier. If it could, one tuple with the new attribute suffices. Maybe this attribute could be added to the servcaps XML...? 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-bounces@ietf.org Fri Jan 7 15:13:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17321; Fri, 7 Jan 2005 15:13:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn0hV-0004Wy-Rk; Fri, 07 Jan 2005 15:27:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn0TA-0002zc-Ar; Fri, 07 Jan 2005 15:12:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn0OP-0007Wj-Jk for simple@megatron.ietf.org; Fri, 07 Jan 2005 15:07:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16731 for ; Fri, 7 Jan 2005 15:07:28 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn0bS-00041p-M3 for simple@ietf.org; Fri, 07 Jan 2005 15:20:59 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 07 Jan 2005 13:18:15 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j07K6tjw021707; Fri, 7 Jan 2005 12:06:56 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOE25059; Fri, 7 Jan 2005 15:06:53 -0500 (EST) Message-ID: <41DEEBDD.5030101@cisco.com> Date: Fri, 07 Jan 2005 15:06:53 -0500 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: "Vijay K. Gurbani" Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41B67ECE.4000300@cs.columbia.edu> <41DDA200.7080600@lucent.com> <41DDC2DA.1080304@cisco.com> <41DDC49D.7040802@lucent.com> <41DDC7C9.1060702@cisco.com> <41DEDF14.8030803@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Paul Kyzivat wrote: > >> Is there a requirement that a publisher must *use* a single tuple to >> represent different capabilities? No. There are hardly any >> requirements on how this stuff must be used. >> >> Is there a requirement that it be *possible* to use a single tuple to >> represent different capabilities? In my mind the answer is yes. In any >> case, requirement or not, it is possible with RPID. > > > Yes, it is. But the problem is that we do not use RPID to make a ^^ Who is "we"? > routing decision. RPID can contain conflicting information about > the presentity in a single tuple (e.g. activity=steering and place-type > =home). We do not make routing decisions based on RIPD; but we are > making routing decisions based on whether a IM or voice can be used. Of course there can be conflicting information. But that doesn't mean people don't make decisions of whether or not to call, and where, based on it. It is a subjective decision. Perhaps you have a different use case in mind than I do. I am thinking of the case where the tuples are rendered to the watching user via a presence gui, and the user can request to initiate communication to the endpoint associated with any tuple. (Think of a common IM buddy display on steroids, where the row for a buddy can be expanded to show separate lines for each tuple. Then a right click can request communication.) It sounds like you are thinking of a presence-aware proxy for an AoR, that uses presence to decide which of the registered contacts to route to. That is not an unreasonable thing to do, but is likely to use a different strategy for use of the RPID data. In the end it doesn't really matter much which tuple it picks - it can parallel fork to them all. Using the presence data is just an optimization. > Maybe it is not accurate to capture the state of the presentity in a > single tuple when describing capabilities that lead to routing > decisions. The tuple doesn't capture the entire state of the presentity. But it captures at least some of the state of the service at that address. And that is enough for the purpose. If there are multiple tuples with conflicting information, that refer to the same contact address, then no big deal. The watching user probably doesn't see the actual url anyway, so doesn't know (or care) that they are the same. They just look like two services which might be contacted. So he picks one based on what it claims, and tries to communicate with it. >>> Clearly we have the atomic parts to model this -- the tuples could be >>> tied >>> together by a device-id so that the watcher knows that we are >>> referring to the same device... >> >> Ah. But is that the same as saying they may be used concurrently? > > OK, then does it suffice to add a new attribute "concurrent=yes"; > then when a single tuple contains servcaps of {MESSAGE, INVITE} then > it is a good indication that it can do both concurrently. These capabilities already mean "concurrent" in callerprefs, as well as in prescaps. Why do we need a new attribute? So we can say in a single attribute that they are *not* concurrent? Not concurrent with what? You need a grouping syntax if you want to do this in a single tuple. But we already have a grouping syntax - the tuple - so why invent another? >>>> The thing that is currently hard to model is mutual exclusion - when >>>> this softphone can do *either* voice, or IM, but not both concurrently. > > If the softphone cannot do IM and voice concurrently, then it would > publish two tuples as I suggested earlier. If it could, one > tuple with the new attribute suffices. Maybe this attribute could > be added to the servcaps XML...? One tuple, *without* the new attribute suffice. I have a feeling we are talking past one another. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 7 17:56:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05359; Fri, 7 Jan 2005 17:56:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn3F8-0003El-Ns; Fri, 07 Jan 2005 18:10:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn2zR-0001bO-8Q; Fri, 07 Jan 2005 17:53:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn2ux-0000v8-Kg for simple@megatron.ietf.org; Fri, 07 Jan 2005 17:49:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05070 for ; Fri, 7 Jan 2005 17:49:13 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn381-0002y3-8N for simple@ietf.org; Fri, 07 Jan 2005 18:02:46 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j07MmVso026041; Fri, 7 Jan 2005 16:48:32 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j07MmVq00801; Fri, 7 Jan 2005 16:48:31 -0600 (CST) Message-ID: <41DF11BF.409@lucent.com> Date: Fri, 07 Jan 2005 16:48:31 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41B67ECE.4000300@cs.columbia.edu> <41DDA200.7080600@lucent.com> <41DDC2DA.1080304@cisco.com> <41DDC49D.7040802@lucent.com> <41DDC7C9.1060702@cisco.com> <41DEDF14.8030803@lucent.com> <41DEEBDD.5030101@cisco.com> In-Reply-To: <41DEEBDD.5030101@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: [...] > I have a feeling we are talking past one another. Paul: The crux of the matter is single tuple or multiple tuples to represent discrete services accessible through the same Contact URI. I favor having multiple tuples with attributes defining the characteristics of the service; each such tuple has the same Contact URI (instead of a GRUU). But as I understand it, there isn't consensus since you may favor a single tuple for all services accessible through the same Contact URI. Ciao. - 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-bounces@ietf.org Fri Jan 7 18:04:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05780; Fri, 7 Jan 2005 18:04:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn3N7-0003cj-Nj; Fri, 07 Jan 2005 18:18:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn38v-0005y6-JR; Fri, 07 Jan 2005 18:03:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn38M-0005Sl-Le for simple@megatron.ietf.org; Fri, 07 Jan 2005 18:03:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05620 for ; Fri, 7 Jan 2005 18:03:04 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn3LR-0003aN-BA for simple@ietf.org; Fri, 07 Jan 2005 18:16:37 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j07N2XZh003220; Fri, 7 Jan 2005 17:02:33 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j07N2Xq10963; Fri, 7 Jan 2005 17:02:33 -0600 (CST) Message-ID: <41DF1509.6050304@lucent.com> Date: Fri, 07 Jan 2005 17:02:33 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Simple] Moving the presence data model work forward References: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> In-Reply-To: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Robert Sparks wrote: > We seem to have ground to a halt again on finishing > the Presence Data Model. This is blocking a very large > portion of the rest of our work. [...] > This is a clearly a compromise position - it would be better > if we _could_ specify a more fleshed out composition mechanism, > but history indicates that this is not likely to happen. Lets get > this base mechanism out there so we can get some more > real-world data to help guide the later debate. Robert: Sounds reasonable. 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-bounces@ietf.org Fri Jan 7 18:29:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07963; Fri, 7 Jan 2005 18:29:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn3l2-0004sw-GK; Fri, 07 Jan 2005 18:43:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn3Vh-0008E8-V1; Fri, 07 Jan 2005 18:27:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn3Pg-0006uC-E2 for simple@megatron.ietf.org; Fri, 07 Jan 2005 18:21:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07615 for ; Fri, 7 Jan 2005 18:20:57 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn3cb-0004R4-3Z for simple@ietf.org; Fri, 07 Jan 2005 18:34:31 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 07 Jan 2005 16:31:38 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j07NK9l2023939; Fri, 7 Jan 2005 15:20:10 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOE42297; Fri, 7 Jan 2005 18:20:14 -0500 (EST) Message-ID: <41DF192E.80101@cisco.com> Date: Fri, 07 Jan 2005 18:20:14 -0500 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: "Vijay K. Gurbani" Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41B67ECE.4000300@cs.columbia.edu> <41DDA200.7080600@lucent.com> <41DDC2DA.1080304@cisco.com> <41DDC49D.7040802@lucent.com> <41DDC7C9.1060702@cisco.com> <41DEDF14.8030803@lucent.com> <41DEEBDD.5030101@cisco.com> <41DF11BF.409@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Paul Kyzivat wrote: > [...] > >> I have a feeling we are talking past one another. > > > Paul: > > The crux of the matter is single tuple or multiple tuples to > represent discrete services accessible through the same > Contact URI. I favor having multiple tuples with attributes > defining the characteristics of the service; each such tuple > has the same Contact URI (instead of a GRUU). But as I > understand it, there isn't consensus since you may favor > a single tuple for all services accessible through the > same Contact URI. If there are discrete services available thru the same contact URI than I agree with representing them as distinct tuples. The difference of opinion is when there are two services and when there is one service with multiple capabilities. Some examples: 1) a video phone. It has both audio and video capabilities. It is possible to use either or both in a single session. It is also possible to start with just voice and then add video later in the session. I think this is one service with one tuple. 2) same as (1), but I have disabled the video feature. It is still one service, one tuple, now the video capability is indicated as absent. 3) a sip communicator client on a pc. supports voice, video, and session mode IM via MSRP. Any combination of these can be used in a single session. Still one service, one tuple. 4) a sip communicator client on a pc. Supports voice, video, page mode IM. Permits any combination of voice and video in a session. Permits MESSAGE only outside a dialog. The UI for IM is separate from the UI for voice/video. This is two services - one for voice & video, another for IM. 5) same as (4), but MESSAGE is permitted both in a dialog and outside. MESSAGE in a dialog is integrated with the UI for voice/video. MESSAGE outside a dialog has a separate UI. Not at all clear to me whether this is one service or two. (Best not to build this device.) Do you disagree with the above? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 7 19:48:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12200; Fri, 7 Jan 2005 19:48:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn4z1-0002aQ-6A; Fri, 07 Jan 2005 20:01:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn4g6-0001RW-Ov; Fri, 07 Jan 2005 19:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn4Z1-0008VT-Vb for simple@megatron.ietf.org; Fri, 07 Jan 2005 19:34:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11532 for ; Fri, 7 Jan 2005 19:34:40 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn4m6-0001jv-FS for simple@ietf.org; Fri, 07 Jan 2005 19:48:15 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Jan 2005 16:42:48 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j080Y7l4000437; Fri, 7 Jan 2005 16:34:09 -0800 (PST) Received: from [10.32.131.77] ([10.32.131.77]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AVJ00445; Fri, 7 Jan 2005 16:34:07 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 07 Jan 2005 13:53:19 -0800 Subject: Re: [Simple] Moving the presence data model work forward From: Cullen Jennings To: Robert Sparks , "simple@ietf.org" Message-ID: In-Reply-To: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit I think this sounds like the a good path for us to pursue. This would allow a very large percentage of applications people are taking about today to be build in a standardized way without complex composition. I don't think it makes it any harder to bring in the complex composition later if we do this now. Cullen On 1/6/05 8:49 PM, "Robert Sparks" wrote: > We seem to have ground to a halt again on finishing > the Presence Data Model. This is blocking a very large > portion of the rest of our work. > > The current sticking point is, at its core, about where > we are drawing the line for a baseline composition > algorithm. > > We've looked several times at whether we would > try to provide a complete standardized composition > system, and have consistently come to the conclusion > that the task is vastly difficult. We've agreed to build > a minimal system that would not preclude work on > more complex standardized composition in the future. > > We've achieved consensus around a using simple > union as the baseline mechanism. Anything more > would be something done outside a standard. We > recognize that this means that different services may > do different things with the same inputs, but until we > have more deployment experience, doing much more > is a "boiling the ocean" class problem. > > To hopefully avoid some of the problems that might arise > with that compromise, the Presence Data Model work > tried to add two important things: > > - It introduced a structure that made it more likely > that elements creating presence documents would > put information in consistent places. This reduces > ambiguity and makes it more likely that the intent > of the document will be rendered accurately across > different implementations. > - It tried to take one more step towards a more complex > composition policy by defining what identifies a service > tuple, so that compositors would have a standard > algorithm for choosing to combine information about > the "same service" from different sources. > > The effort was very successful on the first point. We have > not yet achieved consensus around the second. To reach > agreement, we will need either to back up to something > closer to our previous consensus point, or go further towards > a complete standard composition system. > > In order to allow the document suite that is blocked > on this conversation to go forward, so that we can get > implementation and deployment experience, I believe > it will be necessary to step back: > > - We keep the representation model in the PDM work - > and have been accepted as useful. > > - We maintain the notion that tuples with contacts are "services", > but don't try to standardize what "same service" means at this > time beyond the basic tools that PIDF gives us. > > - We break out discussion of a more complete standard composition > system into a separate document -> AND TABLE IT <- until the > current document suite is done. > > This is a clearly a compromise position - it would be better > if we _could_ specify a more fleshed out composition mechanism, > but history indicates that this is not likely to happen. Lets get > this base mechanism out there so we can get some more > real-world data to help guide the later debate. > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 7 23:21:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23247; Fri, 7 Jan 2005 23:21:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn8JA-0002hE-5r; Fri, 07 Jan 2005 23:34:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn83Q-0002Ln-3g; Fri, 07 Jan 2005 23:18:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn7rV-0006sz-T1 for simple@megatron.ietf.org; Fri, 07 Jan 2005 23:06:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21945 for ; Fri, 7 Jan 2005 23:05:59 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn84d-0001GZ-5S for simple@ietf.org; Fri, 07 Jan 2005 23:19:35 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j083ulqm025283 for ; Fri, 7 Jan 2005 22:56:47 -0500 (EST) Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j083ukqm025248 for ; Fri, 7 Jan 2005 22:56:46 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] modeling dispatchers in the data model: a proposal formoving forward Date: Fri, 7 Jan 2005 23:05:58 -0500 Message-ID: <8CA1128D59AD27429985B397118CEDDF0489CBC0@nj7460avexu1.global.avaya.com> Thread-Topic: [Simple] modeling dispatchers in the data model: a proposal formoving forward Thread-Index: AcT1EO7e3IpVaLemTPayZGV2QdAjjQAJCfJg From: "Boyer, David G \(Dave\)" To: "Paul Kyzivat" , "Vijay K. Gurbani" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable Paul, Comments inline > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, January 07, 2005 6:20 PM > To: Vijay K. Gurbani > Cc: Simple WG > Subject: Re: [Simple] modeling dispatchers in the data model:=20 > a proposal formoving forward >=20 >=20 >=20 >=20 > Vijay K. Gurbani wrote: > > Paul Kyzivat wrote: > > [...] > >=20 > >> I have a feeling we are talking past one another. > >=20 > >=20 > > Paul: > >=20 > > The crux of the matter is single tuple or multiple tuples=20 > to represent=20 > > discrete services accessible through the same Contact URI. I favor=20 > > having multiple tuples with attributes defining the=20 > characteristics of=20 > > the service; each such tuple has the same Contact URI (instead of a=20 > > GRUU). But as I understand it, there isn't consensus since you may=20 > > favor a single tuple for all services accessible through the > > same Contact URI. >=20 > If there are discrete services available thru the same=20 > contact URI than=20 > I agree with representing them as distinct tuples. >=20 > The difference of opinion is when there are two services and=20 > when there=20 > is one service with multiple capabilities. Some examples: >=20 > 1) a video phone. It has both audio and video capabilities. It is=20 > possible to use either or both in a single session. It is=20 > also possible=20 > to start with just voice and then add video later in the session. I=20 > think this is one service with one tuple. >=20 Most video phones code the audio and video together - can't usually start with audio and add video. You can start with an audio conference and then go to a video conference but this is a different case. Some systems, as you mention below, allow this separation - not sure how useful this is because of the different delays in the transmitted audio and=20 video streams (lip sync problems). Anyway, these are two distinct services and should be in two tuples. > 2) same as (1), but I have disabled the video feature. It is=20 > still one=20 > service, one tuple, now the video capability is indicated as absent. I think this would then just be an audio service. >=20 > 3) a sip communicator client on a pc. supports voice, video,=20 > and session=20 > mode IM via MSRP. Any combination of these can be used in a single=20 > session. Still one service, one tuple. >From the user perspective I can see how this would be viewed as a single service (the web collaboration environment supports all of these=20 communication modalities). You may have a conference where not all of the modalities are active, but the unused modalities would not be available for another session from within the sip communicator client. >=20 > 4) a sip communicator client on a pc. Supports voice, video,=20 > page mode=20 > IM. Permits any combination of voice and video in a session. Permits=20 > MESSAGE only outside a dialog. The UI for IM is separate from=20 > the UI for=20 > voice/video. This is two services - one for voice & video,=20 > another for IM. This one confuses me. If the IM pager has a distinct interface, how is it part of the sip communicator client? In 3 if the IM chat session is undockable with unique session controls (start / stop IM session) does that mean it would be represented as a distinct tuple? >=20 > 5) same as (4), but MESSAGE is permitted both in a dialog and=20 > outside.=20 > MESSAGE in a dialog is integrated with the UI for=20 > voice/video. MESSAGE=20 > outside a dialog has a separate UI. Not at all clear to me=20 > whether this=20 > is one service or two. (Best not to build this device.) I guess I reached a similar conclusion above.. dave >=20 > Do you disagree with the above? >=20 > Paul >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jan 8 00:28:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27761; Sat, 8 Jan 2005 00:28:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn9Mt-00076q-Rm; Sat, 08 Jan 2005 00:42:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn98d-00028B-L2; Sat, 08 Jan 2005 00:27:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn97g-0001pV-U6 for simple@megatron.ietf.org; Sat, 08 Jan 2005 00:26:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27635 for ; Sat, 8 Jan 2005 00:26:46 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn9Kl-0006yv-Ml for simple@ietf.org; Sat, 08 Jan 2005 00:40:23 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 07 Jan 2005 21:27:10 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j085QB1X025958; Fri, 7 Jan 2005 21:26:12 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-84.cisco.com [10.86.242.84]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AGX22586; Fri, 7 Jan 2005 21:26:10 -0800 (PST) Message-ID: <41DF6EF2.2000705@cisco.com> Date: Sat, 08 Jan 2005 00:26:10 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Simple] Moving the presence data model work forward References: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> In-Reply-To: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7bit Robert, Thanks for trying to forge some consensus here. I think you are on the right path, but I don't think its as simple as just saying that we don't try to say in what way two services are the same or not. Let me try to explain better the root cause of my concern. The issue for me is that the meaning of the service tuple is that its a loose contract of sorts; it means that if you *select* this service, where selection involves invoking that URI, then the nature of the service you will receive is defined by the characteristics and status associated with that tuple. If you select a different tuple, you click on its URI, and you get something different. Furthermore, a service tuple is actually something concrete - its a software or hardware agent that is listening for requests at that URI, and the characteristics and status within the tuple represent the whole of its characteristics and status. Its OK if that agent is distributed across several components (i.e, a forking proxy and several UAs) - the service represents the union of the service they provide. Thus, my beef with having two services with the same URI is that it means this contract is no longer meaningful. Indeed, the watcher can no longer select a service tuple at all; to reach the service indicated in a tuple they'll have to not only invoke the URI, they'll need to somehow construct a request which they hope is routed to that service, possibly based on creating one matching the capabilities listed by this service. This introduces a lot of ambiguity, and in particular, it really wrecks the ability of the watcher to ->choose<-. The PDM spends some time talking about why watcher choice is one of the key reasons why there are multiple services to begin with. If there are multiple service tuples but there isn't choice, then it becomes entirely unclear why you have multiple tuples - is it a way to express complicated capabilities? Should a watcher render a union of the capabilities as one choice to select to call? Is this about conflicting information? In other words, a service tuple is no longer anything concrete at all; its just a bit of information about the service and thus unclear how it relates to other bits about the same service. In my mind, the whole semantic that the PDM is advocating falls apart. That is why I find it is anathema to what the PDM is trying to do. I am fine if we don't try to support override initially. I am fine if we have a really simple composition policy documented initially. I am even fine to use an opaque token as a tuple ID. I am not fine if we return to what I view as the root problem we had all along - the lack of a clear meaning to multiple tuples in a document, and I believe using the same URI for multiple tuples has that effect. As such, I find nothing to disagree with in your proposal but I don't see how it addresses what appears to be the primary source of disagreement at this point. It does, however, address other points of dispute and confusion, for example how to handle authorization policies which are based on presence data itself. In particular, I think it is possible to split out sections 6 and 7 of the current PDM. The rest of the document describes merely the document and its meaning, 6 and 7 describe the processing done by presence servers and UAs using that data. That split would allow us, once we address this issue of unique URI, to move forward with RPID and the various presence document extensions. However, I believe that the authorization policy work depends on the modeling in section 7, and would still be blocked on us at least understanding the specific way in which authorization policy takes place within the context of presence server processing. -Jonathan R. HTH, Jonathan R. Robert Sparks wrote: > We seem to have ground to a halt again on finishing > the Presence Data Model. This is blocking a very large > portion of the rest of our work. > > The current sticking point is, at its core, about where > we are drawing the line for a baseline composition > algorithm. > > We've looked several times at whether we would > try to provide a complete standardized composition > system, and have consistently come to the conclusion > that the task is vastly difficult. We've agreed to build > a minimal system that would not preclude work on > more complex standardized composition in the future. > > We've achieved consensus around a using simple > union as the baseline mechanism. Anything more > would be something done outside a standard. We > recognize that this means that different services may > do different things with the same inputs, but until we > have more deployment experience, doing much more > is a "boiling the ocean" class problem. > > To hopefully avoid some of the problems that might arise > with that compromise, the Presence Data Model work > tried to add two important things: > > - It introduced a structure that made it more likely > that elements creating presence documents would > put information in consistent places. This reduces > ambiguity and makes it more likely that the intent > of the document will be rendered accurately across > different implementations. > - It tried to take one more step towards a more complex > composition policy by defining what identifies a service > tuple, so that compositors would have a standard > algorithm for choosing to combine information about > the "same service" from different sources. > > The effort was very successful on the first point. We have > not yet achieved consensus around the second. To reach > agreement, we will need either to back up to something > closer to our previous consensus point, or go further towards > a complete standard composition system. > > In order to allow the document suite that is blocked > on this conversation to go forward, so that we can get > implementation and deployment experience, I believe > it will be necessary to step back: > > - We keep the representation model in the PDM work - > and have been accepted as useful. > > - We maintain the notion that tuples with contacts are "services", > but don't try to standardize what "same service" means at this > time beyond the basic tools that PIDF gives us. > > - We break out discussion of a more complete standard composition > system into a separate document -> AND TABLE IT <- until the > current document suite is done. > > This is a clearly a compromise position - it would be better > if we _could_ specify a more fleshed out composition mechanism, > but history indicates that this is not likely to happen. Lets get > this base mechanism out there so we can get some more > real-world data to help guide the later debate. > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jan 8 00:53:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28815; Sat, 8 Jan 2005 00:53:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn9ke-0000NC-VH; Sat, 08 Jan 2005 01:07:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn9W1-0006Bj-27; Sat, 08 Jan 2005 00:51:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn9Uv-0005zD-G3 for simple@megatron.ietf.org; Sat, 08 Jan 2005 00:50:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28642 for ; Sat, 8 Jan 2005 00:50:46 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn9i3-00006z-2r for simple@ietf.org; Sat, 08 Jan 2005 01:04:23 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 07 Jan 2005 21:51:13 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j085oFjw020647; Fri, 7 Jan 2005 21:50:15 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-84.cisco.com [10.86.242.84]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AGX22973; Fri, 7 Jan 2005 21:50:13 -0800 (PST) Message-ID: <41DF7495.70204@cisco.com> Date: Sat, 08 Jan 2005 00:50:13 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41C2997D.9010800@nokia.com> In-Reply-To: <41C2997D.9010800@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit inline. I'd ask folks to please read to the end where I have another compromise proposal on unique URI that may be more palatable than my previous one. Aki Niemi wrote: > Hi Jonathan, > > First of all, thanks for pushing the resolution of this issue forward by > making a concrete proposal. > > I don't think making the dispatcher visible to the composer/watcher > actually solves the real problem; it does however reaffirm the statement > made in the data model that unique contacts URIs are required in service > tuples. The primary motivation for this requirement seems to be that it > enables overriding service elements. No, not so at all. Please see my post in response to Robert's compromise proposal where I try to explain the concern more. > > I think we are working with the wrong publication model to begin with, > which makes override of service elements problematic. The publication > model is that of a presentity employing a set of PUAs with equal rights > -- no one PUA is more authoritative than another. They are all > publishing their own full view of the presentity's service statuses. > > This is much like a set of users running processes in an OS. Let's say > that user 'apniemi' sees that a process run by 'calendar' has gone awry > and is not responding. Using the current data model, fixing, or > overriding this process would entail user 'apniemi' creating a new > process, with matching properties (such as the pid), but a different > binary, resulting in overriding the 'calendar' user's process. Normally, > of course 'apniemi' probably wouldn't be able to do that, but instead, > would need to become 'root' and 'kill' the process. > > So I think ultimately, we need a new interface to the composer, call it > root account, that gives us a way to "kill" publications that are > publishing stale event state. Perhaps such an interface could be > provided as part of the composer policy or authorization policy, but I > don't think it necessarily requires uniqueness of service URIs. Sure, I agree with that you don't require unique URI to do this override. As long as you have some kind of unique and easily learnable handle it can work. The override isn't the real problem though. > > If we reverse the assumption made in the data model that requires > uniqueness of service URIs, will watchers generally be confused if they > encounter service tuples with the same contact? I don't think so, as > long as the watcher does the following: > > 1) takes note of the meta-information of each service (timestamp, > q-value) giving preference to a fresher service, or one with higher > q-value. The point of q-value is not to say "please use this service over another service". PDM talks about this. If that were true there would be no point in advertising anything but the highest priority service. > > 2) takes note of the characteristics of each service (prescaps for > example) along with the contact URI, applying its own known > characteristics and service URIs to determine what service the tuple is > describing This seems like the "and magic happens" step, and is exactly the one I'm worried about. There is basically no way two watchers are going to interpret these the same. The essence of the problem is that the document has lost standalone meaning for what the tuple represents. > > 3) takes note of the status, meaning that a basic status of OPEN is a > better choice than one with CLOSED, for example > > 4) all of the above being equal, folds all identical services together > (after all they are identical in all ways that have relevance to the > watcher) > > These steps should guarantee that the watcher can always make a proper > selection of which service to invoke. Invoking the service then involves > more than a simple "clicking the contact", since in the case of SIP the > watcher generally will e.g. construct an SDP offer that matches the > service that the watcher thinks the tuple is describing. It could do that but it need not; the benefit of a URI and its definitional characteristic is that you need no other context beyond the URI to use it. I should be able to make a SIP call to that URI without having seen the presence document at all, and it works to the degree that SIP itself would allow the call to proceed. Presence might help optimize by allowing me to select media streams that work out of the box, for example, but its an optimization not a requirment for contacting the URI. If it is, the URI becomes meaningless. > I believe the > invoking of a service MUST work using an AoR. If an INVITE offering > voice ends up served by a chess application, I think the system is > utterly broken, and needs to be fixed. This is contradictory. You are saying that two services that are different have to be able to have the same AoR, but if you have the same AOR, how can you guarantee that an INVITE to that AOR is properly dispatched to the right app depending on where it came from? One fix could be using GRUUs as > contacts, but that is not the only fix, and may not even be the best > one, IMHO. > > All and all, I still don't buy the requirement for unique service URIs. > Also, I think that the default composer policy of union (i.e., collect > all service tuples together intact) will take care of the 95% need, > leaving out more sophisticated things like override and > merging/splitting for future study. I agree with that. I'll note that using GRUU has that effect. Let me make another proposal, which is a variation on the dispatcher model I suggested, modified by an idea Henning proposed. When a PUA publishes a tuple about itself, the , if present, still needs to route to itself. However, we also define an additional presence attribute called (suggested by Henning), which contains a URI which routes to a dispatcher through which that service might be reachable. In the SIP case, this could contain the AOR. Thus, one could build a PUA which publishes about itself. It has no GRUU, so it omits the URI and includes containing the AOR. Another smarter PUA would include the GRUU in the , possibly in addition to with the AOR. A dumb composer can always union. A smarter composer can use the service URIs in the if present, in combination with the information to correlate the services together. It could then produce a tuple with the AOR in the and no . The current contract and meaning of the as a service remains as it is in the PDM. However, we now have the case where there is a tuple describing a service that is not directly reachable. The watcher knows a URI through which it might be reached, and can render or combine those together in whatever way it sees fit. In the future, we could define this dispatcher service so that a watcher could even learn the policy governing how the dispatch is done. I think this is simpler than my original proposal, has the benefit of maintaining the union operation as the default composition policy, retains the semantics of the service tuple as currently in the PDM. I would be amenable to defining some kind of additional ID that serves to identify a tuple uniquely when the is not present. This would allow override even for tuples with no contact (as those published from a PUA not supporting gruu). Is that more palatable? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jan 8 01:03:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29356; Sat, 8 Jan 2005 01:03:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn9um-0001NC-AW; Sat, 08 Jan 2005 01:17:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn9gr-0008LL-Jf; Sat, 08 Jan 2005 01:03:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn9cC-0007Jw-OK for simple@megatron.ietf.org; Sat, 08 Jan 2005 00:58:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29036 for ; Sat, 8 Jan 2005 00:58:17 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn9pJ-0000rh-Uh for simple@ietf.org; Sat, 08 Jan 2005 01:11:55 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 07 Jan 2005 21:58:44 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j085vkRO008071; Fri, 7 Jan 2005 21:57:46 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-84.cisco.com [10.86.242.84]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AGX23102; Fri, 7 Jan 2005 21:57:44 -0800 (PST) Message-ID: <41DF7658.7000306@cisco.com> Date: Sat, 08 Jan 2005 00:57:44 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nevo Oded Subject: Re: [Simple] Presence Data Model : Device - Service Realations References: <522B9797154BD549B17BA4EAF1DF200C1082F9@il-tlv-mail02.comverse.com> In-Reply-To: <522B9797154BD549B17BA4EAF1DF200C1082F9@il-tlv-mail02.comverse.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit responses inline. Nevo Oded wrote: > Hi > > The draft-ietf-simple-presence-data-model-01 define many to many > > Realation between the presentity services to the presentity devices. > > A service can be related to list of devices as defined in the service > schema. > > My questions are: > > Does the presence status of a service which have a list of devices is > synchronize > > In all the devices the service is execute on? If a service runs on multiple devices, there is still just one identifying the service, and it has one status. > > When one of the devices in the service list is shut down ( when all > other devices are on) > > how does it should reflect on the service presence status? This is something for the compositor to figure out. It could choose to set the status of all services on that device to CLOSED. > > Does the device list of a service is just a list of all the presentity > > Devices that the service installed on, and the presence status represents > > Only the status of the communication mean that could be reached through > > The uri in the contact attribute? Yes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jan 8 01:05:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29481; Sat, 8 Jan 2005 01:05:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn9wL-0001Qd-9z; Sat, 08 Jan 2005 01:19:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn9gu-0008LU-R7; Sat, 08 Jan 2005 01:03:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn9dG-0007b0-Lk for simple@megatron.ietf.org; Sat, 08 Jan 2005 00:59:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29135 for ; Sat, 8 Jan 2005 00:59:23 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn9qO-0000sY-16 for simple@ietf.org; Sat, 08 Jan 2005 01:13:01 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 07 Jan 2005 21:59:50 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j085wp1X001122; Fri, 7 Jan 2005 21:58:52 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-84.cisco.com [10.86.242.84]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AGX23117; Fri, 7 Jan 2005 21:58:50 -0800 (PST) Message-ID: <41DF769A.4020706@cisco.com> Date: Sat, 08 Jan 2005 00:58:50 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nevo Oded Subject: Re: [Simple] Tuple ID References: <522B9797154BD549B17BA4EAF1DF200C108303@il-tlv-mail02.comverse.com> In-Reply-To: <522B9797154BD549B17BA4EAF1DF200C108303@il-tlv-mail02.comverse.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit We are in the process of debating this right now. -Jonathan R. Nevo Oded wrote: > Hi > > When Presence Server receives PUBLISH > > message from client how does the server should > > update presence info for a service, does the service > > should be uniquley identified by the "tuple id" or > > by the "contact" uri?" > > 10x Oded > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jan 8 17:09:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02907; Sat, 8 Jan 2005 17:09:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnOzn-00030e-67; Sat, 08 Jan 2005 17:23:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnOlJ-0002sH-KX; Sat, 08 Jan 2005 17:08:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnOja-0002bf-42 for simple@megatron.ietf.org; Sat, 08 Jan 2005 17:06:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02822 for ; Sat, 8 Jan 2005 17:06:56 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnOwo-0002sz-3O for simple@ietf.org; Sat, 08 Jan 2005 17:20:41 -0500 Received: from razor.cs.columbia.edu (IDENT:EhuEtJkkwoHf7KV/7JSKMAdgqPpE1ABk@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j08M6hir012401 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 8 Jan 2005 17:06:43 -0500 (EST) Received: from [127.0.0.1] (IDENT:WodTsdGAxFVbY7tx9962miondUidfYG2@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j08M6giw006948; Sat, 8 Jan 2005 17:06:42 -0500 Message-ID: <41E05975.6080308@cs.columbia.edu> Date: Sat, 08 Jan 2005 17:06:45 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Moving the presence data model work forward References: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> <41DF6EF2.2000705@cisco.com> In-Reply-To: <41DF6EF2.2000705@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.8.18 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P3_5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_DPTCOMPNY 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Let me try to explain better the root cause of my concern. The issue for > me is that the meaning of the service tuple is that its a loose contract > of sorts; it means that if you *select* this service, where selection > involves invoking that URI, then the nature of the service you will > receive is defined by the characteristics and status associated with > that tuple. If you select a different tuple, you click on its URI, and > you get something different. This isn't quite true. Even if the URIs in services tuples are different, you may well get exactly the same service, just reached by a different identifier. Thus, there is no way that a watcher can rely on the URI identity to know whether it will reach a different service. Also, as we discussed in DC and on the list, a basic union composer will have no way to ascertain, in general, whether two URIs might be the same unless it is familiar with the URI scheme. I thought there was agreement that we did not want to require the composer or PA to know the details of the URI scheme. Furthermore, we discussed that there are URI schemes which have, today, well-defined mechanisms to select content based on pieces of the request beyond the URI. The HTTP content selection mechanism, widely available in Apache, is one prominent example. http://embassy.fr (French version) note: this is the french version content-language: fr http://embassy.fr (English version) note: this is the english version content-language: en > > Furthermore, a service tuple is actually something concrete - its a > software or hardware agent that is listening for requests at that URI, > and the characteristics and status within the tuple represent the whole > of its characteristics and status. Its OK if that agent is distributed > across several components (i.e, a forking proxy and several UAs) - the > service represents the union of the service they provide. > > Thus, my beef with having two services with the same URI is that it > means this contract is no longer meaningful. Indeed, the watcher can no > longer select a service tuple at all; to reach the service indicated in > a tuple they'll have to not only invoke the URI, they'll need to somehow > construct a request which they hope is routed to that service, possibly > based on creating one matching the capabilities listed by this service. > > This introduces a lot of ambiguity, and in particular, it really wrecks > the ability of the watcher to ->choose<-. The PDM spends some time > talking about why watcher choice is one of the key reasons why there are > multiple services to begin with. If there are multiple service tuples > but there isn't choice, then it becomes entirely unclear why you have > multiple tuples - is it a way to express complicated capabilities? > Should a watcher render a union of the capabilities as one choice to > select to call? Is this about conflicting information? In other words, a > service tuple is no longer anything concrete at all; its just a bit of > information about the service and thus unclear how it relates to other > bits about the same service. > > In my mind, the whole semantic that the PDM is advocating falls apart. > That is why I find it is anathema to what the PDM is trying to do. > > I am fine if we don't try to support override initially. I am fine if we > have a really simple composition policy documented initially. I am even > fine to use an opaque token as a tuple ID. I am not fine if we return to > what I view as the root problem we had all along - the lack of a clear > meaning to multiple tuples in a document, and I believe using the same > URI for multiple tuples has that effect. I don't see that forcing the PA to merge or reject or override same-URI tuples either increases the descriptiveness or, conversely, that not enforcing this in any way decreases it. You keep asserting that this would get us back into the wild woods of anything goes, but provide no evidence for this. In general, there are two cases from a watcher perspective: - The service description is meaningful beyond the URI. - There is no meaningful service description (since, for example, the service description contains information not understood by the watcher). A URI scheme itself provides almost no service information beyond the mechanics of contacting it, so an enumeration of different URIs without description isn't any more meaningful than a list of the same URIs. URI1 (some service description 1, D1) URI2 (some service description 2, D2) There are the following possible cases, all with well-defined behavior for the watcher: URI1 == URI2, D1 == D2 presumably a mistake, but harmless duplication; watcher drops duplicate URI1 == URI2, D1 != D2 if the watcher knows how to use D1 and D2 to qualify the request to URI1/2, it does so; otherwise, the two tuples are the same as far as the watcher is concerned and the watcher drops one or the other (or indicates that the watcher might get D1 or D2, based on the luck of the draw and the mood of the proxy). This is logically no different than saying "This URI might give you either A or B, but I can't tell you ahead of time what you'll get", i.e., common behavior for any proxied SIP URI today. URI1 != URI2, D1 == D2 somewhat confusing to the watcher, but no worse than the common habit of having a list of phone numbers on a business card, with no differentiation by function. Not a problem affected by this discussion. URI1 != URI2, D1 != D2 common case; no problem It is then up to the elements contributing to the presence information to choose the URIs and descriptions that are most likely to work. That's an operational decision and allows service upgrades without upgrading the composer or PA, over which I have no control. Thus, the meaning and algorithm are well defined *for the watcher*. We should probably describe this in a bit more detail. My concern is that once we "outlaw" equality in URIs, that we lose the ability to describe and handle such scenarios and require composers that need to deal with such cases, without having the means to do so in a predictable and information-conserving manner, given the simple-union requirement. Unless we describe a composer in detail, I don't see how we can rule out duplicate URIs. We would have to describe: - whether URI equality is syntactic or semantic - whether "latest wins" - whether such 'latest wins' would lead to Kerry-style flip-flop behavior, i.e., if URI1(D1) and URI2(D2) have URI1=URI2, the watcher would see D1 or D2, depending on whether the publisher representing D1 or D2 has last published information. In summary, I believe that we gain no semantic clarity by ruling out the existence of duplicate elements at the composer and that the watcher is the only entity qualified to make appropriate equality judgements. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jan 8 17:14:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03172; Sat, 8 Jan 2005 17:14:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnP46-0003B0-Hu; Sat, 08 Jan 2005 17:28:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnOpL-0003aM-BG; Sat, 08 Jan 2005 17:12:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnOng-00038p-2W for simple@megatron.ietf.org; Sat, 08 Jan 2005 17:11:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02952 for ; Sat, 8 Jan 2005 17:11:10 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnP0w-00031g-B1 for simple@ietf.org; Sat, 08 Jan 2005 17:24:55 -0500 Received: from razor.cs.columbia.edu (IDENT:dCMu+VdVEnRzD8WkcP0q8scWarwmPfwl@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j08M9uir013192 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 8 Jan 2005 17:09:57 -0500 (EST) Received: from [127.0.0.1] (IDENT:Tq2e6kspSMP40ta0afHyT0/wTl8BgAhp@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j08M9uiw006953; Sat, 8 Jan 2005 17:09:56 -0500 Message-ID: <41E05A37.9050303@cs.columbia.edu> Date: Sat, 08 Jan 2005 17:09:59 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41B67ECE.4000300@cs.columbia.edu> <41DDA200.7080600@lucent.com> <41DDC2DA.1080304@cisco.com> <41DDC49D.7040802@lucent.com> <41DDC7C9.1060702@cisco.com> <41DEDF14.8030803@lucent.com> In-Reply-To: <41DEDF14.8030803@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.8.18 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Paul Kyzivat wrote: > Yes, it is. But the problem is that we do not use RPID to make a > routing decision. RPID can contain conflicting information about > the presentity in a single tuple (e.g. activity=steering and place-type > =home). This is the houseboat presence status :-) Sorry, couldn't resist. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jan 8 17:55:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04523; Sat, 8 Jan 2005 17:55:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnPiK-0004kc-Kw; Sat, 08 Jan 2005 18:09:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnPTu-0000RE-Lh; Sat, 08 Jan 2005 17:54:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnPRs-0000Bt-MC for simple@megatron.ietf.org; Sat, 08 Jan 2005 17:52:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04426 for ; Sat, 8 Jan 2005 17:52:42 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnPf7-0004ZT-80 for simple@ietf.org; Sat, 08 Jan 2005 18:06:28 -0500 Received: from razor.cs.columbia.edu (IDENT:perP7xcmoDBb88PbAzX5+XYZnzRX3PNJ@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j08MqZir022492 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 8 Jan 2005 17:52:35 -0500 (EST) Received: from [127.0.0.1] (IDENT:fj7mjB+HGAtCL6OZm+P06naBFGaOr78Y@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j08MqYiw007103; Sat, 8 Jan 2005 17:52:34 -0500 Message-ID: <41E06431.8020808@cs.columbia.edu> Date: Sat, 08 Jan 2005 17:52:33 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Boyer, David G \(Dave\)" Subject: Re: [Simple] modeling dispatchers in the data model: a proposal formoving forward References: <8CA1128D59AD27429985B397118CEDDF0489CBC0@nj7460avexu1.global.avaya.com> In-Reply-To: <8CA1128D59AD27429985B397118CEDDF0489CBC0@nj7460avexu1.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.8.18 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , "Vijay K. Gurbani" , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit > Most video phones code the audio and video together - can't usually > start with audio and add video. You can start with an audio conference We've had a system (sipc, http://www.cs.columbia.edu/IRT/sipc) for quite a while that can indeed add video at any time, as well as any other supported medium. This is a standard re-INVITE scenario. > and then go to a video conference but this is a different case. Some > systems, as you mention below, allow this separation - not sure how > useful > this is because of the different delays in the transmitted audio and > video streams (lip sync problems). While we don't do this, rat and vic have had the ability to lip-sync across independent applications since the mid-90s. (That said, I suspect that few combined systems do real lip-sync...) > Anyway, these are two distinct services and should be in two tuples. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jan 8 18:25:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06640; Sat, 8 Jan 2005 18:25:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnQAV-0005la-7Y; Sat, 08 Jan 2005 18:38:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnPw3-0006wm-I5; Sat, 08 Jan 2005 18:23:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnPsG-0006K9-Ki for simple@megatron.ietf.org; Sat, 08 Jan 2005 18:20:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06448 for ; Sat, 8 Jan 2005 18:19:58 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnQ5X-0005gk-97 for simple@ietf.org; Sat, 08 Jan 2005 18:33:44 -0500 Received: from razor.cs.columbia.edu (IDENT:fERmn/tZK0eU9o8W4I2B61E41qbNVBv0@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j08NJtir029272 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 8 Jan 2005 18:19:55 -0500 (EST) Received: from [127.0.0.1] (IDENT:EdtwcfaKtdhRC/l55xGz8+24bYmOjhlt@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j08NJsiw007189; Sat, 8 Jan 2005 18:19:54 -0500 Message-ID: <41E06A95.8010109@cs.columbia.edu> Date: Sat, 08 Jan 2005 18:19:49 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41C2997D.9010800@nokia.com> <41DF7495.70204@cisco.com> In-Reply-To: <41DF7495.70204@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.8.18 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit I'm generally happy with that proposal as a way to move forward. More information for the watcher allowing correlation is always a good thing. I think this means in more detail: - Use of is RECOMMENDED. - PUA SHOULD publish distinct contacts, which MAY share the same element value. - Since existing non-RPID system won't know about , composers MAY do simple union (keeping tuples with identical Contact and maybe a different element to avoid information loss) or MAY apply a smart composition policy that somehow merges the two same-contact tuples. The content-selection HTTP URIs I mentioned earlier may not have contact URIs as such (they sometimes do, typically in file-based systems), so this is a bit SIP-specific. Jonathan Rosenberg wrote: > Let me make another proposal, which is a variation on the dispatcher > model I suggested, modified by an idea Henning proposed. > > When a PUA publishes a tuple about itself, the , if present, > still needs to route to itself. However, we also define an additional > presence attribute called (suggested by Henning), which > contains a URI which routes to a dispatcher through which that service > might be reachable. In the SIP case, this could contain the AOR. > > Thus, one could build a PUA which publishes about itself. It has no > GRUU, so it omits the URI and includes > containing the AOR. > > Another smarter PUA would include the GRUU in the , possibly in > addition to with the AOR. > > A dumb composer can always union. A smarter composer can use the service > URIs in the if present, in combination with the > information to correlate the services together. It could then produce a > tuple with the AOR in the and no . > > The current contract and meaning of the as a service remains as > it is in the PDM. However, we now have the case where there is a tuple > describing a service that is not directly reachable. The watcher knows a > URI through which it might be reached, and can render or combine those > together in whatever way it sees fit. > > In the future, we could define this dispatcher service so that a watcher > could even learn the policy governing how the dispatch is done. > > I think this is simpler than my original proposal, has the benefit of > maintaining the union operation as the default composition policy, > retains the semantics of the service tuple as currently in the PDM. > > I would be amenable to defining some kind of additional ID that serves > to identify a tuple uniquely when the is not present. This > would allow override even for tuples with no contact (as those published > from a PUA not supporting gruu). > > Is that more palatable? > > Thanks, > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jan 9 09:59:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17834; Sun, 9 Jan 2005 09:59:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnelN-0002nF-1r; Sun, 09 Jan 2005 10:13:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CneWs-0003mY-4l; Sun, 09 Jan 2005 09:58:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CneNT-0002wc-Ct for simple@megatron.ietf.org; Sun, 09 Jan 2005 09:49:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17490 for ; Sun, 9 Jan 2005 09:49:09 -0500 (EST) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cneai-0002M2-0v for simple@ietf.org; Sun, 09 Jan 2005 10:03:03 -0500 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id 695D5A96A2; Sun, 9 Jan 2005 15:48:27 +0100 (CET) Received: from [192.168.1.5] (unknown [82.196.203.62]) by voyager.coretrek.no (Postfix) with ESMTP id 05458A969E; Sun, 9 Jan 2005 15:48:26 +0100 (CET) In-Reply-To: <41DF6EF2.2000705@cisco.com> References: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> <41DF6EF2.2000705@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7FA467F9-624D-11D9-91E0-000D93C60BA0@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Moving the presence data model work forward Date: Sun, 9 Jan 2005 15:48:17 +0100 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: 7bit On Jan 8, 2005, at 6:26 AM, Jonathan Rosenberg wrote: > Robert, > > Thanks for trying to forge some consensus here. > > I think you are on the right path, but I don't think its as simple as > just saying that we don't try to say in what way two services are the > same or not. Robert is not saying that we don't try. Robert is saying that we need implementation, deployment and user experience before you, Henning, Aki or whoever can justify his own view point. Clearly we are not reaching consensus on anything at this point and only time will tell. We are trying to model and standardise something that we don't have full and common understanding of. We will be much more successful in standardising this when we get feedback from the community. Until then, the debate is an academic one. Lets just give implementers the building blocks and let them decide, along with their customers, how composition policy can be made to work. > > Let me try to explain better the root cause of my concern. The issue > for me is that the meaning of the service tuple is that its a loose > contract of sorts; it means that if you *select* this service, where > selection involves invoking that URI, then the nature of the service > you will receive is defined by the characteristics and status > associated with that tuple. If you select a different tuple, you click > on its URI, and you get something different. That's because you are hung up on the idea that the URI that is represented in the tuple is the only way to reach that service. Others have other ideas. Again, we need to allow for deployments to happen before someone can say "see, I told you so". > > Furthermore, a service tuple is actually something concrete - its a > software or hardware agent that is listening for requests at that URI, > and the characteristics and status within the tuple represent the > whole of its characteristics and status. Its OK if that agent is > distributed across several components (i.e, a forking proxy and > several UAs) - the service represents the union of the service they > provide. > > Thus, my beef with having two services with the same URI is that it > means this contract is no longer meaningful. Indeed, the watcher can > no longer select a service tuple at all; to reach the service > indicated in a tuple they'll have to not only invoke the URI, they'll > need to somehow construct a request which they hope is routed to that > service, possibly based on creating one matching the capabilities > listed by this service. > > This introduces a lot of ambiguity, and in particular, it really > wrecks the ability of the watcher to ->choose<-. The PDM spends some > time talking about why watcher choice is one of the key reasons why > there are multiple services to begin with. If there are multiple > service tuples but there isn't choice, then it becomes entirely > unclear why you have multiple tuples - is it a way to express > complicated capabilities? Should a watcher render a union of the > capabilities as one choice to select to call? Is this about > conflicting information? In other words, a service tuple is no longer > anything concrete at all; its just a bit of information about the > service and thus unclear how it relates to other bits about the same > service. Again, we are not saying we will never make this more concrete in an RFC, but please lets get implementation and deployment experience first and lets stop speculating. > > In my mind, the whole semantic that the PDM is advocating falls apart. > That is why I find it is anathema to what the PDM is trying to do. > > I am fine if we don't try to support override initially. I am fine if > we have a really simple composition policy documented initially. I am > even fine to use an opaque token as a tuple ID. I am not fine if we > return to what I view as the root problem we had all along - the lack > of a clear meaning to multiple tuples in a document, and I believe > using the same URI for multiple tuples has that effect. Robert's suggestion was to rip out the composition policy stuff completely from the draft. > > As such, I find nothing to disagree with in your proposal but I don't > see how it addresses what appears to be the primary source of > disagreement at this point. Its addressing it by allowing real user experience to dictate how things should be viewed. > > It does, however, address other points of dispute and confusion, for > example how to handle authorization policies which are based on > presence data itself. In particular, I think it is possible to split > out sections 6 and 7 of the current PDM. The rest of the document > describes merely the document and its meaning, 6 and 7 describe the > processing done by presence servers and UAs using that data. That is the idea. > > That split would allow us, once we address this issue of unique URI, > to move forward with RPID and the various presence document > extensions. However, I believe that the authorization policy work > depends on the modeling in section 7, and would still be blocked on us > at least understanding the specific way in which authorization policy > takes place within the context of presence server processing. We don't want to block RPID and the various document extensions. If that is true, then this whole conversation is mute. Can you elaborate on why this unique URI issue is blocking this work and the authorisation policy work? Regards, Hisham > > -Jonathan R. > > HTH, > Jonathan R. > > Robert Sparks wrote: > >> We seem to have ground to a halt again on finishing >> the Presence Data Model. This is blocking a very large >> portion of the rest of our work. >> The current sticking point is, at its core, about where >> we are drawing the line for a baseline composition >> algorithm. >> We've looked several times at whether we would >> try to provide a complete standardized composition >> system, and have consistently come to the conclusion >> that the task is vastly difficult. We've agreed to build >> a minimal system that would not preclude work on >> more complex standardized composition in the future. >> We've achieved consensus around a using simple >> union as the baseline mechanism. Anything more >> would be something done outside a standard. We >> recognize that this means that different services may >> do different things with the same inputs, but until we >> have more deployment experience, doing much more >> is a "boiling the ocean" class problem. >> To hopefully avoid some of the problems that might arise >> with that compromise, the Presence Data Model work >> tried to add two important things: >> - It introduced a structure that made it more likely >> that elements creating presence documents would >> put information in consistent places. This reduces >> ambiguity and makes it more likely that the intent >> of the document will be rendered accurately across >> different implementations. >> - It tried to take one more step towards a more complex >> composition policy by defining what identifies a service >> tuple, so that compositors would have a standard >> algorithm for choosing to combine information about >> the "same service" from different sources. >> The effort was very successful on the first point. We have >> not yet achieved consensus around the second. To reach >> agreement, we will need either to back up to something >> closer to our previous consensus point, or go further towards >> a complete standard composition system. >> In order to allow the document suite that is blocked >> on this conversation to go forward, so that we can get >> implementation and deployment experience, I believe >> it will be necessary to step back: >> - We keep the representation model in the PDM work - >> and have been accepted as useful. >> - We maintain the notion that tuples with contacts are "services", >> but don't try to standardize what "same service" means at this >> time beyond the basic tools that PIDF gives us. >> - We break out discussion of a more complete standard composition >> system into a separate document -> AND TABLE IT <- until the >> current document suite is done. >> This is a clearly a compromise position - it would be better >> if we _could_ specify a more fleshed out composition mechanism, >> but history indicates that this is not likely to happen. Lets get >> this base mechanism out there so we can get some more >> real-world data to help guide the later debate. >> RjS >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jan 9 20:00:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20086; Sun, 9 Jan 2005 20:00:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cno8A-0007WW-5U; Sun, 09 Jan 2005 20:14:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnnsY-0002d7-Fg; Sun, 09 Jan 2005 19:57:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnnpG-00020A-Q1 for simple@megatron.ietf.org; Sun, 09 Jan 2005 19:54:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19873 for ; Sun, 9 Jan 2005 19:54:27 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cno2m-0007Pk-7f for simple@ietf.org; Sun, 09 Jan 2005 20:08:28 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j0A0qPFe012043 for ; Sun, 9 Jan 2005 19:52:25 -0500 (EST) Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j0A0qNFe012017 for ; Sun, 9 Jan 2005 19:52:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] modeling dispatchers in the data model: a proposal formoving forward Date: Sun, 9 Jan 2005 19:54:25 -0500 Message-ID: <8CA1128D59AD27429985B397118CEDDF0489CC1E@nj7460avexu1.global.avaya.com> Thread-Topic: [Simple] modeling dispatchers in the data model: a proposal formoving forward Thread-Index: AcT11MJv55bL8G8UTYumfXbUU2FgSQA2cP4w From: "Boyer, David G \(Dave\)" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: Paul Kyzivat , "Vijay K. Gurbani" , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Henning, I was refering to what is primarily available in commerical systems, which dispatchers will have to support. I know systems have been developed that support adding media dynamically, the point is there are systems (most commercial systems) that do not support this type of re-INVITE. Dave > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Sent: Saturday, January 08, 2005 5:53 PM > To: Boyer, David G (Dave) > Cc: Paul Kyzivat; Vijay K. Gurbani; Simple WG > Subject: Re: [Simple] modeling dispatchers in the data model:=20 > a proposal formoving forward >=20 >=20 >=20 > > Most video phones code the audio and video together - can't usually=20 > > start with audio and add video. You can start with an audio=20 > > conference >=20 > We've had a system (sipc,=20 > http://www.cs.columbia.edu/IRT/sipc) for quite=20 > a while that can indeed add video at any time, as well as any other=20 > supported medium. This is a standard re-INVITE scenario. >=20 >=20 > > and then go to a video conference but this is a different=20 > case. Some=20 > > systems, as you mention below, allow this separation - not sure how=20 > > useful this is because of the different delays in the transmitted=20 > > audio and video streams (lip sync problems). >=20 > While we don't do this, rat and vic have had the ability to lip-sync=20 > across independent applications since the mid-90s. (That=20 > said, I suspect=20 > that few combined systems do real lip-sync...) >=20 >=20 > > Anyway, these are two distinct services and should be in two tuples. >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 10 06:11:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08863; Mon, 10 Jan 2005 06:11:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cnxg2-00045M-37; Mon, 10 Jan 2005 06:25:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnxNu-0006Rq-0L; Mon, 10 Jan 2005 06:06:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnxNR-0006JR-Ou for simple@megatron.ietf.org; Mon, 10 Jan 2005 06:06:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08669 for ; Mon, 10 Jan 2005 06:06:23 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cnxb2-0003sv-AZ for simple@ietf.org; Mon, 10 Jan 2005 06:20:28 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0AB6Bi01472; Mon, 10 Jan 2005 13:06:11 +0200 (EET) X-Scanned: Mon, 10 Jan 2005 13:05:42 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j0AB5g0Q026142; Mon, 10 Jan 2005 13:05:42 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00aYwy0d; Mon, 10 Jan 2005 12:59:01 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0AAx0x04990; Mon, 10 Jan 2005 12:59:00 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 10 Jan 2005 12:59:00 +0200 Received: from esebe052.NOE.Nokia.com ([172.21.138.217]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 10 Jan 2005 12:59:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] modeling dispatchers in the data model: a proposal formoving forward Date: Mon, 10 Jan 2005 12:59:00 +0200 Message-ID: Thread-Topic: [Simple] modeling dispatchers in the data model: a proposal formoving forward Thread-Index: AcT13TNkgsP7BYNJT0yPGJ3Dcj62mABIopIA To: , X-OriginalArrivalTime: 10 Jan 2005 10:59:00.0271 (UTC) FILETIME=[63B0CBF0:01C4F703] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: quoted-printable Hi, I think that the proposal looks quite promising. However, I would like = to clarify some points. As I understood the proposal, the use of wrt. tuple = identification and composing would remain as it currently is in the data = model. This means that each tuple in the presence document must have a = unique , and if the compositor gets multiple tuples with equal = , it will forward only of them, by default the latest, i.e. an = explicit override operation would be possible. Is this correct? How = about the URI comparison issues beyond SIP that Henning has brought up? would be a new attribute that could be used instead of = in case it is not possible to generate unique contacts. So, = for instance in Rel 6 IMS, where GRUU is not supported, service tuples = would typically contain only with an AoR, but no = . The default composer policy would be to just union those = tuples, i.e. forward everything. Jonathan Rosenberg wrote: > > A dumb composer can always union. A smarter composer can=20 > use the service=20 > > URIs in the if present, in combination with the=20 > =20 > > information to correlate the services together. It could=20 > then produce a=20 > > tuple with the AOR in the and no . I suppose this means a case where the contacts are unique? I don't quite = understand WHY the composer should ever do this kind of combination. If = the tuples really represent different applications or different = preferences, doesn't the combination loose this important information? = It seems smarter to forward all the information to the watcher. In case = some contacts are equal, the composer overrides the older tuples with = the latest ones, right? I suppose the case where there would be two tuples with equal = but a different is quite peculiar (but is it an error?). = In that case the composer would by default still look only at the = and would choose the latest tuple? Jonathan Rosenberg wrote: > > I would be amenable to defining some kind of additional ID=20 > that serves=20 > > to identify a tuple uniquely when the is not=20 > present. This=20 > > would allow override even for tuples with no contact (as=20 > those published=20 > > from a PUA not supporting gruu). Yes, I support this too. In case that both and this additional = ID are present (would that even be allowed?), I suppose would = take presedence in the composer policy? Henning Schulzrinne wrote: > - Since existing non-RPID system won't know about ,=20 > composers MAY do simple union (keeping tuples with identical=20 > Contact and=20 > maybe a different element to avoid information loss)=20 > or MAY apply=20 > a smart composition policy that somehow merges the two=20 > same-contact tuples. This would bring back some ambiguity. Could we just put a note in the = draft/RFC which says that there are some pre-standard systems that are = likely to do this, but this would still not be even MAY in _this_ spec?=20 Markus > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Henning Schulzrinne > Sent: 09 January, 2005 01:20 > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] modeling dispatchers in the data model:=20 > a proposal > formoving forward >=20 >=20 > I'm generally happy with that proposal as a way to move forward. More=20 > information for the watcher allowing correlation is always a=20 > good thing. >=20 > I think this means in more detail: >=20 > - Use of is RECOMMENDED. >=20 > - PUA SHOULD publish distinct contacts, which MAY share the same=20 > element value. >=20 > - Since existing non-RPID system won't know about ,=20 > composers MAY do simple union (keeping tuples with identical=20 > Contact and=20 > maybe a different element to avoid information loss)=20 > or MAY apply=20 > a smart composition policy that somehow merges the two=20 > same-contact tuples. >=20 > The content-selection HTTP URIs I mentioned earlier may not=20 > have contact=20 > URIs as such (they sometimes do, typically in file-based systems), so=20 > this is a bit SIP-specific. >=20 > Jonathan Rosenberg wrote: >=20 > > Let me make another proposal, which is a variation on the=20 > dispatcher=20 > > model I suggested, modified by an idea Henning proposed. > >=20 > > When a PUA publishes a tuple about itself, the ,=20 > if present,=20 > > still needs to route to itself. However, we also define an=20 > additional=20 > > presence attribute called (suggested by=20 > Henning), which=20 > > contains a URI which routes to a dispatcher through which=20 > that service=20 > > might be reachable. In the SIP case, this could contain the AOR. > >=20 > > Thus, one could build a PUA which publishes about itself. It has no=20 > > GRUU, so it omits the URI and includes =20 > > containing the AOR. > >=20 > > Another smarter PUA would include the GRUU in the=20 > , possibly in=20 > > addition to with the AOR. > >=20 > > A dumb composer can always union. A smarter composer can=20 > use the service=20 > > URIs in the if present, in combination with the=20 > =20 > > information to correlate the services together. It could=20 > then produce a=20 > > tuple with the AOR in the and no . > >=20 > > The current contract and meaning of the as a=20 > service remains as=20 > > it is in the PDM. However, we now have the case where there=20 > is a tuple=20 > > describing a service that is not directly reachable. The=20 > watcher knows a=20 > > URI through which it might be reached, and can render or=20 > combine those=20 > > together in whatever way it sees fit. > >=20 > > In the future, we could define this dispatcher service so=20 > that a watcher=20 > > could even learn the policy governing how the dispatch is done. > >=20 > > I think this is simpler than my original proposal, has the=20 > benefit of=20 > > maintaining the union operation as the default composition policy,=20 > > retains the semantics of the service tuple as currently in the PDM. > >=20 > > I would be amenable to defining some kind of additional ID=20 > that serves=20 > > to identify a tuple uniquely when the is not=20 > present. This=20 > > would allow override even for tuples with no contact (as=20 > those published=20 > > from a PUA not supporting gruu). > >=20 > > Is that more palatable? > >=20 > > Thanks, > > Jonathan R. >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 10 09:36:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22206; Mon, 10 Jan 2005 09:36:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co0sn-0002zZ-Kb; Mon, 10 Jan 2005 09:51:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co0cU-0008HJ-DA; Mon, 10 Jan 2005 09:34:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co0XE-0007TS-G4 for simple@megatron.ietf.org; Mon, 10 Jan 2005 09:28:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21675 for ; Mon, 10 Jan 2005 09:28:42 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co0kn-0002gN-NO for simple@ietf.org; Mon, 10 Jan 2005 09:42:49 -0500 Received: from [10.240.20.76] (m015f36d0.tmodns.net [208.54.95.1]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j0AER7pf034764 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 10 Jan 2005 08:27:08 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <8CA1128D59AD27429985B397118CEDDF0489CC1E@nj7460avexu1.global.avaya.com> References: <8CA1128D59AD27429985B397118CEDDF0489CC1E@nj7460avexu1.global.avaya.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Simple] modeling dispatchers in the data model: a proposal formoving forward Date: Mon, 10 Jan 2005 08:27:06 -0600 To: "Boyer, David G \(Dave\)" X-Mailer: Apple Mail (2.619) X-Spam-Score: 2.9 (++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , "Vijay K. Gurbani" , Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit I disagree with the "most" below. Most of the systems capable of video I've seen deal with reINVITEs that add/remove video streams independently from audio. Some even start with no video by default. RjS On Jan 9, 2005, at 6:54 PM, Boyer, David G ((Dave)) wrote: > Henning, > > I was refering to what is primarily available in commerical systems, > which > dispatchers will have to support. I know systems have been developed > that support adding media dynamically, the point is there are systems > (most commercial > systems) that do not support this type of re-INVITE. > > Dave > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Saturday, January 08, 2005 5:53 PM >> To: Boyer, David G (Dave) >> Cc: Paul Kyzivat; Vijay K. Gurbani; Simple WG >> Subject: Re: [Simple] modeling dispatchers in the data model: >> a proposal formoving forward >> >> >> >>> Most video phones code the audio and video together - can't usually >>> start with audio and add video. You can start with an audio >>> conference >> >> We've had a system (sipc, >> http://www.cs.columbia.edu/IRT/sipc) for quite >> a while that can indeed add video at any time, as well as any other >> supported medium. This is a standard re-INVITE scenario. >> >> >>> and then go to a video conference but this is a different >> case. Some >>> systems, as you mention below, allow this separation - not sure how >>> useful this is because of the different delays in the transmitted >>> audio and video streams (lip sync problems). >> >> While we don't do this, rat and vic have had the ability to lip-sync >> across independent applications since the mid-90s. (That >> said, I suspect >> that few combined systems do real lip-sync...) >> >> >>> Anyway, these are two distinct services and should be in two tuples. >> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 10 11:02:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28367; Mon, 10 Jan 2005 11:02:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co2Dy-0006Vk-MX; Mon, 10 Jan 2005 11:16:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co1xv-0008Sk-KF; Mon, 10 Jan 2005 11:00:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co1tz-0007xm-Dx for simple@megatron.ietf.org; Mon, 10 Jan 2005 10:56:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27854 for ; Mon, 10 Jan 2005 10:56:17 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co27c-0006AP-M5 for simple@ietf.org; Mon, 10 Jan 2005 11:10:25 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 10 Jan 2005 08:03:06 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0AFqWk0025772; Mon, 10 Jan 2005 07:52:34 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOF13893; Mon, 10 Jan 2005 10:52:31 -0500 (EST) Message-ID: <41E2A4BF.9080306@cisco.com> Date: Mon, 10 Jan 2005 10:52:31 -0500 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: "Boyer, David G \(Dave\)" Subject: Re: [Simple] modeling dispatchers in the data model: a proposal formoving forward References: <8CA1128D59AD27429985B397118CEDDF0489CBC0@nj7460avexu1.global.avaya.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: "Vijay K. Gurbani" , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Dave - comments inline. Extraneous material edited out. Paul Boyer, David G (Dave) wrote: ... > Comments inline ... >>Vijay K. Gurbani wrote: >> >>>Paul Kyzivat wrote: ... >>The difference of opinion is when there are two services and >>when there >>is one service with multiple capabilities. Some examples: >> >>1) a video phone. It has both audio and video capabilities. It is >>possible to use either or both in a single session. It is >>also possible >>to start with just voice and then add video later in the session. I >>think this is one service with one tuple. > > Most video phones code the audio and video together - can't usually > start with audio and add video. You can start with an audio conference > and then go to a video conference but this is a different case. Some > systems, as you mention below, allow this separation - not sure how > useful > this is because of the different delays in the transmitted audio and > video streams (lip sync problems). > Anyway, these are two distinct services and should be in two tuples. If so, then they will get smarter over time. Lets not assume they will stat so dumb. And hopefully they at least will interoperate with devices that are more capable. I trust the phones you refer to will at least *accept* a call that offers only audio. Then what will they do if a subsequent reinvite offers video as well? (I hope they will accept it if they would have accepting it on the initial invite.) >>2) same as (1), but I have disabled the video feature. It is >>still one >>service, one tuple, now the video capability is indicated as absent. > > I think this would then just be an audio service. Yes, it will probably look like a basic audio service while the video feature is disabled, but could dynamically switch to looking like an audio+video service when the video is enabled. It could even look like an audio service to some watchers and an audio+video service to others. >>3) a sip communicator client on a pc. supports voice, video, >>and session >>mode IM via MSRP. Any combination of these can be used in a single >>session. Still one service, one tuple. > >>From the user perspective I can see how this would be viewed as a single > service (the web collaboration environment supports all of these > communication modalities). You may have a conference where not all > of the modalities are active, but the unused modalities would not be > available for another session from within the sip communicator client. > >>4) a sip communicator client on a pc. Supports voice, video, >>page mode >>IM. Permits any combination of voice and video in a session. Permits >>MESSAGE only outside a dialog. The UI for IM is separate from >>the UI for >>voice/video. This is two services - one for voice & video, >>another for IM. > > This one confuses me. If the IM pager has a distinct interface, how is > it part of the sip communicator client? It would be part of the same "client" because it shares the same address. Something at a low level above the sip stack could split these things to separarate UIs. I'm not suggesting this would be a highly desirable way to build something, but it seems quite plausible. A MESSAGE based IM client would perhaps not use dialogs (because you aren't supposed to use MESSAGE that way), and a "regular" voice+video client might not have a UI that is suitable for support of message. In this case it would perhaps be "better" if they had separate contact addresses, registrations, and presence tuples. But its not hard to imagine someone wanting to circumvent all this "overhead". > In 3 if the IM chat session > is undockable with unique session controls (start / stop IM session) > does > that mean it would be represented as a distinct tuple? I don't understand the case you are describing. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 10 11:05:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28558; Mon, 10 Jan 2005 11:05:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co2G5-0006aG-6y; Mon, 10 Jan 2005 11:19:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co1xw-0008T2-ES; Mon, 10 Jan 2005 11:00:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co1vT-00088p-4D for simple@megatron.ietf.org; Mon, 10 Jan 2005 10:57:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27946 for ; Mon, 10 Jan 2005 10:57:49 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co294-0006GA-Gi for simple@ietf.org; Mon, 10 Jan 2005 11:11:56 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 10 Jan 2005 08:07:46 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0AFvDjw027713; Mon, 10 Jan 2005 07:57:14 -0800 (PST) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j0AFsH8g003032; Mon, 10 Jan 2005 07:54:17 -0800 In-Reply-To: References: <8CA1128D59AD27429985B397118CEDDF0489CC1E@nj7460avexu1.global.avaya.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4876EDDB-6320-11D9-9F77-000A95C73842@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Simple] modeling dispatchers in the data model: a proposal formoving forward Date: Mon, 10 Jan 2005 10:57:08 -0500 To: Robert Sparks X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1105372458.694778"; x:"432200"; a:"rsa-sha1"; b:"nofws:2493"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"BmYzKu4AlkM2S/PpYUNJwcJK/xJc2nLtNkdvTwL+/z7/QRYpKY85hHf7J7Hka" "wFe1p4IvcJEFNMzwe+wx+Kn14bqKqzlUC0C32Do9iOjT8Akfza3GhhUL/bx4B" "bPmRT/G7XqM7ho8EgEPTb4ileP0k8Cq39ttjeLyN7BIyujsmI="; c:"From: David R Oran "; c:"Subject: Re: [Simple] modeling dispatchers in the data model: a propos" "al formoving forward"; c:"Date: Mon, 10 Jan 2005 10:57:08 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , "Vijay K. Gurbani" , Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit On Jan 10, 2005, at 9:27 AM, Robert Sparks wrote: > I disagree with the "most" below. > Me too. We need to be looking forward, not backward. > Most of the systems capable of video I've seen deal > with reINVITEs that add/remove video streams independently > from audio. Some even start with no video by default. > > RjS > > On Jan 9, 2005, at 6:54 PM, Boyer, David G ((Dave)) wrote: > >> Henning, >> >> I was refering to what is primarily available in commerical systems, >> which >> dispatchers will have to support. I know systems have been developed >> that support adding media dynamically, the point is there are systems >> (most commercial >> systems) that do not support this type of re-INVITE. >> >> Dave >> >>> -----Original Message----- >>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>> Sent: Saturday, January 08, 2005 5:53 PM >>> To: Boyer, David G (Dave) >>> Cc: Paul Kyzivat; Vijay K. Gurbani; Simple WG >>> Subject: Re: [Simple] modeling dispatchers in the data model: >>> a proposal formoving forward >>> >>> >>> >>>> Most video phones code the audio and video together - can't usually >>>> start with audio and add video. You can start with an audio >>>> conference >>> >>> We've had a system (sipc, >>> http://www.cs.columbia.edu/IRT/sipc) for quite >>> a while that can indeed add video at any time, as well as any other >>> supported medium. This is a standard re-INVITE scenario. >>> >>> >>>> and then go to a video conference but this is a different >>> case. Some >>>> systems, as you mention below, allow this separation - not sure how >>>> useful this is because of the different delays in the transmitted >>>> audio and video streams (lip sync problems). >>> >>> While we don't do this, rat and vic have had the ability to lip-sync >>> across independent applications since the mid-90s. (That >>> said, I suspect >>> that few combined systems do real lip-sync...) >>> >>> >>>> Anyway, these are two distinct services and should be in two tuples. >>> >>> >> >> _______________________________________________ >> 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 > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 10 11:41:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03650; Mon, 10 Jan 2005 11:41:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co2pZ-0008HU-3T; Mon, 10 Jan 2005 11:55:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co2SU-0005qM-O0; Mon, 10 Jan 2005 11:31:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co2JT-0003hi-0e for simple@megatron.ietf.org; Mon, 10 Jan 2005 11:22:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29490 for ; Mon, 10 Jan 2005 11:22:36 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co2X4-0007FH-LS for simple@ietf.org; Mon, 10 Jan 2005 11:36:45 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Jan 2005 09:33:57 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0AGLxvl024527; Mon, 10 Jan 2005 08:22:00 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOF16653; Mon, 10 Jan 2005 11:22:01 -0500 (EST) Message-ID: <41E2ABA9.90103@cisco.com> Date: Mon, 10 Jan 2005 11:22:01 -0500 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: Aki Niemi Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41C2997D.9010800@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Aki Niemi wrote: ... > These steps should guarantee that the watcher can always make a proper > selection of which service to invoke. Invoking the service then involves > more than a simple "clicking the contact", since in the case of SIP the > watcher generally will e.g. construct an SDP offer that matches the > service that the watcher thinks the tuple is describing. I believe the > invoking of a service MUST work using an AoR. If an INVITE offering > voice ends up served by a chess application, I think the system is > utterly broken, and needs to be fixed. One fix could be using GRUUs as > contacts, but that is not the only fix, and may not even be the best > one, IMHO. OK, lets investigate how that might work. I think you assume that when I have selected a tuple, and constructed a request to it, that the request wll contain attributes of some sort that correlate to the tuple I selected, and no other. This is a bad assumption. Consider the following case: - we have presentity sip:alice@atlanta.com. - she has one tuple that identifies a "voice" service ( false). - she has another tuple that identifies a "chess" service ( true). - These two tuples really represent different UAs, but in each case it is the AoR that is included as a contact in the tuple - Bob looks at the entry for Alice in his buddy list, and selects the IM tuple to initiate a call. How do you see this working? I guess your assumption is that this is no problem. If an INVITE arrives at the proxy with an offer for audio the proxy will send it to voice service, while one with an offer for chess protocol. But suppose it is a 3pcc controller that is sending the invite, and it has chosen to send the invite without an offer. What can the proxy do now? The best it can probably do is fork the invite. If so, the voice app would perhaps respond with a 18x with an offer of audio, while the chess app would respond with a 18x for chess. If so, Bob's UA could cancel the chess dialog and keep the one with the voice device. But it is also possible that the chess app would respond immediately with a 2xx. If so, you indeed end up talking to a chess service. How would you propose to solve this problem? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 10 15:08:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18809; Mon, 10 Jan 2005 15:08:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co644-0006Kx-FA; Mon, 10 Jan 2005 15:23:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co5ob-0006CI-Tr; Mon, 10 Jan 2005 15:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co5h6-0000I3-IE for simple@megatron.ietf.org; Mon, 10 Jan 2005 14:59:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17637 for ; Mon, 10 Jan 2005 14:59:14 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co5ul-00062v-Uo for simple@ietf.org; Mon, 10 Jan 2005 15:13:24 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j0AJnvqm013774 for ; Mon, 10 Jan 2005 14:49:58 -0500 (EST) Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j0AJneqm013218 for ; Mon, 10 Jan 2005 14:49:45 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] modeling dispatchers in the data model: a proposal formoving forward Date: Mon, 10 Jan 2005 14:58:54 -0500 Message-ID: <8CA1128D59AD27429985B397118CEDDF03046810@nj7460avexu1.global.avaya.com> Thread-Topic: [Simple] modeling dispatchers in the data model: a proposal formoving forward Thread-Index: AcT3LRTeisZyxOLkSq+9gnVnH2MoVQAIZ4DQ From: "Boyer, David G \(Dave\)" To: "David R Oran" , "Robert Sparks" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Cc: Paul Kyzivat , "Vijay K. Gurbani" , Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable OK, OK, stuck my foot in my mouth with the "most" comment. Still think we should accomodate "legacy" solutions. dave > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: Monday, January 10, 2005 10:57 AM > To: Robert Sparks > Cc: Paul Kyzivat; Simple WG; Boyer, David G (Dave); Henning=20 > Schulzrinne; > Vijay K. Gurbani > Subject: Re: [Simple] modeling dispatchers in the data model:=20 > a proposal > formoving forward >=20 >=20 >=20 > On Jan 10, 2005, at 9:27 AM, Robert Sparks wrote: >=20 > > I disagree with the "most" below. > > > Me too. We need to be looking forward, not backward. >=20 > > Most of the systems capable of video I've seen deal > > with reINVITEs that add/remove video streams independently > > from audio. Some even start with no video by default. > > > > RjS > > > > On Jan 9, 2005, at 6:54 PM, Boyer, David G ((Dave)) wrote: > > > >> Henning, > >> > >> I was refering to what is primarily available in=20 > commerical systems, > >> which > >> dispatchers will have to support. I know systems have=20 > been developed > >> that support adding media dynamically, the point is there=20 > are systems > >> (most commercial > >> systems) that do not support this type of re-INVITE. > >> > >> Dave > >> > >>> -----Original Message----- > >>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>> Sent: Saturday, January 08, 2005 5:53 PM > >>> To: Boyer, David G (Dave) > >>> Cc: Paul Kyzivat; Vijay K. Gurbani; Simple WG > >>> Subject: Re: [Simple] modeling dispatchers in the data model: > >>> a proposal formoving forward > >>> > >>> > >>> > >>>> Most video phones code the audio and video together -=20 > can't usually > >>>> start with audio and add video. You can start with an audio > >>>> conference > >>> > >>> We've had a system (sipc, > >>> http://www.cs.columbia.edu/IRT/sipc) for quite > >>> a while that can indeed add video at any time, as well as=20 > any other > >>> supported medium. This is a standard re-INVITE scenario. > >>> > >>> > >>>> and then go to a video conference but this is a different > >>> case. Some > >>>> systems, as you mention below, allow this separation -=20 > not sure how > >>>> useful this is because of the different delays in the transmitted > >>>> audio and video streams (lip sync problems). > >>> > >>> While we don't do this, rat and vic have had the ability=20 > to lip-sync > >>> across independent applications since the mid-90s. (That > >>> said, I suspect > >>> that few combined systems do real lip-sync...) > >>> > >>> > >>>> Anyway, these are two distinct services and should be in=20 > two tuples. > >>> > >>> > >> > >> _______________________________________________ > >> 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 > > > David R. Oran > Cisco Fellow > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 USA > Tel: +1 978 264 2048 > Email: oran@cisco.com >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 10 18:12:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12425; Mon, 10 Jan 2005 18:12:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co8vZ-0005ZA-Cv; Mon, 10 Jan 2005 18:26:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co8YO-0000s8-Nj; Mon, 10 Jan 2005 18:02:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co8RP-0006Ay-2E for simple@megatron.ietf.org; Mon, 10 Jan 2005 17:55:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10624 for ; Mon, 10 Jan 2005 17:55:12 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co8f5-00059z-B6 for simple@ietf.org; Mon, 10 Jan 2005 18:09:24 -0500 Received: from lion.cs.columbia.edu (IDENT:BUG5Is3rjYpjZ0KHh6oZqlQQYEa1w6XP@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0AMs6ir010565 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 10 Jan 2005 17:54:07 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j0AMs5qp004098 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 10 Jan 2005 17:54:06 -0500 Message-ID: <41E30788.4010605@cs.columbia.edu> Date: Mon, 10 Jan 2005 17:54:00 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: [Simple] modeling dispatchers in the data model: a proposal formoving forward References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.10.28 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit > latest, i.e. an explicit override operation would be possible. Is > this correct? How about the URI comparison issues beyond SIP that > Henning has brought up? While I think that the makes it easier to avoid contact duplication, I don't think we should (nor need to) rely on contact uniqueness. The behavior of the client is clearly defined even if an (accidental) duplication occurs. As far as I can tell, there is "ambiguity" in the sense that the client is confused as to the true state of the world. The client may not actually get to pick among the possible choices, but no presence system can prevent that unless you assign a unique URI to each mutually-exclusive set of capabilities, including codec exclusions. (For example, while it may be possible in theory to get both audio and video for a tuple indicating such capability, with my particular combination of available codecs, only audio may be possible. Presence isn't going to fix that.) > I suppose this means a case where the contacts are unique? I don't > quite understand WHY the composer should ever do this kind of > combination. If the tuples really represent different applications or > different preferences, doesn't the combination loose this important > information? It seems smarter to forward all the information to the > watcher. In case some contacts are equal, the composer overrides the > older tuples with the latest ones, right? Maybe one general guideline is that composers shouldn't try to be smarter than watchers unless they really know they are and are the only ones that can prevent providing wrong (rather than just uncertain) information. The flip-flopping behavior that mechanical last-wins composition by URL induces seems far worse and more confusing than showing the watcher that he might get one or the other. Something like 18:01 sip:foo@example.com audio replaced by 18:02 sip:foo@example.com video+audio replaced by 18:03 sip:foo@example.com text as the PUAs battle it out seems rather confusing to the watcher, compared to [constant] (sip:foo@example.com audio + sip:foo@example.com video+audio sip:foo@example.com text) >> - Since existing non-RPID system won't know about , >> composers MAY do simple union (keeping tuples with identical >> Contact and maybe a different element to avoid information >> loss) or MAY apply a smart composition policy that somehow merges >> the two same-contact tuples. > > > This would bring back some ambiguity. Could we just put a note in the > draft/RFC which says that there are some pre-standard systems that > are likely to do this, but this would still not be even MAY in _this_ > spec? > See above. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 10 18:14:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12696; Mon, 10 Jan 2005 18:14:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co8xa-0005bl-C4; Mon, 10 Jan 2005 18:28:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co8YP-0000tL-Mb; Mon, 10 Jan 2005 18:02:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co8Sj-0006d5-21 for simple@megatron.ietf.org; Mon, 10 Jan 2005 17:56:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10702 for ; Mon, 10 Jan 2005 17:56:34 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co8gQ-0005Ba-BS for simple@ietf.org; Mon, 10 Jan 2005 18:10:46 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 10 Jan 2005 18:08:41 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0AMu1m4023712; Mon, 10 Jan 2005 17:56:02 -0500 (EST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOF56964; Mon, 10 Jan 2005 17:56:00 -0500 (EST) Message-ID: <41E30800.80004@cisco.com> Date: Mon, 10 Jan 2005 17:56:00 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41C2997D.9010800@nokia.com> <41DF7495.70204@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: Aki Niemi , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > inline. I'd ask folks to please read to the end where I have another > compromise proposal on unique URI that may be more palatable than my > previous one. I *think* I'm ok with this, as long as it is specified that and are mutually exclusive. Paul > Let me make another proposal, which is a variation on the dispatcher > model I suggested, modified by an idea Henning proposed. > > When a PUA publishes a tuple about itself, the , if present, > still needs to route to itself. However, we also define an additional > presence attribute called (suggested by Henning), which > contains a URI which routes to a dispatcher through which that service > might be reachable. In the SIP case, this could contain the AOR. > > Thus, one could build a PUA which publishes about itself. It has no > GRUU, so it omits the URI and includes > containing the AOR. > > Another smarter PUA would include the GRUU in the , possibly in > addition to with the AOR. > > A dumb composer can always union. A smarter composer can use the service > URIs in the if present, in combination with the > information to correlate the services together. It could then produce a > tuple with the AOR in the and no . > > The current contract and meaning of the as a service remains as > it is in the PDM. However, we now have the case where there is a tuple > describing a service that is not directly reachable. The watcher knows a > URI through which it might be reached, and can render or combine those > together in whatever way it sees fit. > > In the future, we could define this dispatcher service so that a watcher > could even learn the policy governing how the dispatch is done. > > I think this is simpler than my original proposal, has the benefit of > maintaining the union operation as the default composition policy, > retains the semantics of the service tuple as currently in the PDM. > > I would be amenable to defining some kind of additional ID that serves > to identify a tuple uniquely when the is not present. This > would allow override even for tuples with no contact (as those published > from a PUA not supporting gruu). _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 10 18:14:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12767; Mon, 10 Jan 2005 18:14:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co8y0-0005cN-IB; Mon, 10 Jan 2005 18:28:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co8YR-0000wB-Nl; Mon, 10 Jan 2005 18:02:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co8TU-0006of-Jt for simple@megatron.ietf.org; Mon, 10 Jan 2005 17:57:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10777 for ; Mon, 10 Jan 2005 17:57:22 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co8hB-0005Do-T5 for simple@ietf.org; Mon, 10 Jan 2005 18:11:34 -0500 Received: from lion.cs.columbia.edu (IDENT:c91+qTN72svBH7szURWCnvWaLS7FQwjP@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0AMuKir010916 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 10 Jan 2005 17:56:21 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j0AMuKqp004112 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 10 Jan 2005 17:56:20 -0500 Message-ID: <41E3080F.5070108@cs.columbia.edu> Date: Mon, 10 Jan 2005 17:56:15 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41C2997D.9010800@nokia.com> <41E2ABA9.90103@cisco.com> In-Reply-To: <41E2ABA9.90103@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.10.28 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: Aki Niemi , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Caller preferences would be one mechanism to address this at the signaling level. I don't think relying on SDP inspection is particularly helpful. Paul Kyzivat wrote: > > > Aki Niemi wrote: > ... > >> These steps should guarantee that the watcher can always make a proper >> selection of which service to invoke. Invoking the service then >> involves more than a simple "clicking the contact", since in the case >> of SIP the watcher generally will e.g. construct an SDP offer that >> matches the service that the watcher thinks the tuple is describing. >> I believe the >> invoking of a service MUST work using an AoR. If an INVITE offering >> voice ends up served by a chess application, I think the system is >> utterly broken, and needs to be fixed. One fix could be using GRUUs as >> contacts, but that is not the only fix, and may not even be the best >> one, IMHO. > > > OK, lets investigate how that might work. I think you assume that when I > have selected a tuple, and constructed a request to it, that the request > wll contain attributes of some sort that correlate to the tuple I > selected, and no other. This is a bad assumption. > > Consider the following case: > > - we have presentity sip:alice@atlanta.com. > > - she has one tuple that identifies a "voice" service > ( false). > > - she has another tuple that identifies a "chess" service > ( true). > > - These two tuples really represent different UAs, but in each case > it is the AoR that is included as a contact in the tuple > > - Bob looks at the entry for Alice in his buddy list, and selects > the IM tuple to initiate a call. > > How do you see this working? I guess your assumption is that this is no > problem. If an INVITE arrives at the proxy with an offer for audio the > proxy will send it to voice service, while one with an offer for chess > protocol. > > But suppose it is a 3pcc controller that is sending the invite, and it > has chosen to send the invite without an offer. What can the proxy do now? > > The best it can probably do is fork the invite. If so, the voice app > would perhaps respond with a 18x with an offer of audio, while the chess > app would respond with a 18x for chess. If so, Bob's UA could cancel the > chess dialog and keep the one with the voice device. > > But it is also possible that the chess app would respond immediately > with a 2xx. If so, you indeed end up talking to a chess service. How > would you propose to solve this problem? > > Paul > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 10 19:07:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16277; Mon, 10 Jan 2005 19:07:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co9mi-0006bX-MO; Mon, 10 Jan 2005 19:21:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co9GX-0007po-D3; Mon, 10 Jan 2005 18:48:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co9E9-0007E9-Ql for simple@megatron.ietf.org; Mon, 10 Jan 2005 18:45:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15155 for ; Mon, 10 Jan 2005 18:45:34 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co9Ro-0006D7-1t for simple@ietf.org; Mon, 10 Jan 2005 18:59:47 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jan 2005 15:45:02 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jan 2005 15:44:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Jan 2005 15:44:44 -0800 Message-ID: <1BEC4DA05ABCD34FACFCFC82086AC2470494F0B3@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: PIDF "entity" attribute usage thread-index: AcT3blycHjw8yfECQOSI2eo7uRrntA== From: "Tim Rang" To: X-OriginalArrivalTime: 10 Jan 2005 23:44:44.0906 (UTC) FILETIME=[5CD3BCA0:01C4F76E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Subject: [Simple] PIDF "entity" attribute usage X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0634655959==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba This is a multi-part message in MIME format. --===============0634655959== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F76E.5CDD8E5A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F76E.5CDD8E5A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 In nearly all of the I-Ds related to presence, every example pidf document I find contains an entity attribute with a "pres" scheme. The schema for RFC 3863 indicates that any URI is acceptable here. However, section 4.1.1 states- The value of the 'entity' attribute is the 'pres' URL of the PRESENTITY publishing this presence document. =20 Recently, I've started to see some instances where the entity attribute contains a sip scheme (Ex- draft-ietf-simple-presence-data-model-01 ). =20 My questions are: - What is the intended usage of this entity attribute in SIMPLE? - What is the meaning of the 'pres' scheme and why should we use it over something more relevant (i.e. 'sip')? =20 Thanks, Tim Rang ------_=_NextPart_001_01C4F76E.5CDD8E5A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

In nearly all of the I-Ds related to presence, every = example pidf document I find contains an entity attribute with a = “pres” scheme.  The schema for RFC 3863 indicates that any URI is = acceptable here.  However, section 4.1.1 states-

         =
      The value of the 'entity' =
attribute is the 'pres' URL of the PRESENTITY publishing this presence =
document.

 

Recently, I’ve started to see some instances =
where the entity attribute contains a sip scheme (Ex- =
draft-ietf-simple-presence-data-model-01

).

 

My questions are:

-          What is the intended usage of this entity = attribute in SIMPLE?

-          What is the meaning of the ‘pres’ = scheme and why should we use it over something more relevant (i.e. = ‘sip’)?

 

Thanks,

Tim Rang

------_=_NextPart_001_01C4F76E.5CDD8E5A-- --===============0634655959== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0634655959==-- From simple-bounces@ietf.org Tue Jan 11 04:40:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06385; Tue, 11 Jan 2005 04:40:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoIjl-0000Tj-Dg; Tue, 11 Jan 2005 04:54:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoIRp-0006rz-NL; Tue, 11 Jan 2005 04:36:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoIOv-0006GW-Ts for simple@megatron.ietf.org; Tue, 11 Jan 2005 04:33:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05547 for ; Tue, 11 Jan 2005 04:33:20 -0500 (EST) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoIcf-0000Dh-Lw for simple@ietf.org; Tue, 11 Jan 2005 04:47:37 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0B9X7g28793; Tue, 11 Jan 2005 11:33:08 +0200 (EET) X-Scanned: Tue, 11 Jan 2005 11:32:50 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j0B9Wo1R030873; Tue, 11 Jan 2005 11:32:50 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00zMU2vC; Tue, 11 Jan 2005 11:32:49 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0B9WDU11695; Tue, 11 Jan 2005 11:32:13 +0200 (EET) Received: from [192.168.1.186] ([10.162.252.227]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 Jan 2005 11:32:09 +0200 Message-ID: <41E39D18.609@nokia.com> Date: Tue, 11 Jan 2005 11:32:08 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Robert Sparks Subject: Re: [Simple] Moving the presence data model work forward References: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> In-Reply-To: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2005 09:32:09.0770 (UTC) FILETIME=[6C6730A0:01C4F7C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit I agree with this approach. Cheers, Aki ext Robert Sparks wrote: > We seem to have ground to a halt again on finishing > the Presence Data Model. This is blocking a very large > portion of the rest of our work. > > The current sticking point is, at its core, about where > we are drawing the line for a baseline composition > algorithm. > > We've looked several times at whether we would > try to provide a complete standardized composition > system, and have consistently come to the conclusion > that the task is vastly difficult. We've agreed to build > a minimal system that would not preclude work on > more complex standardized composition in the future. > > We've achieved consensus around a using simple > union as the baseline mechanism. Anything more > would be something done outside a standard. We > recognize that this means that different services may > do different things with the same inputs, but until we > have more deployment experience, doing much more > is a "boiling the ocean" class problem. > > To hopefully avoid some of the problems that might arise > with that compromise, the Presence Data Model work > tried to add two important things: > > - It introduced a structure that made it more likely > that elements creating presence documents would > put information in consistent places. This reduces > ambiguity and makes it more likely that the intent > of the document will be rendered accurately across > different implementations. > - It tried to take one more step towards a more complex > composition policy by defining what identifies a service > tuple, so that compositors would have a standard > algorithm for choosing to combine information about > the "same service" from different sources. > > The effort was very successful on the first point. We have > not yet achieved consensus around the second. To reach > agreement, we will need either to back up to something > closer to our previous consensus point, or go further towards > a complete standard composition system. > > In order to allow the document suite that is blocked > on this conversation to go forward, so that we can get > implementation and deployment experience, I believe > it will be necessary to step back: > > - We keep the representation model in the PDM work - > and have been accepted as useful. > > - We maintain the notion that tuples with contacts are "services", > but don't try to standardize what "same service" means at this > time beyond the basic tools that PIDF gives us. > > - We break out discussion of a more complete standard composition > system into a separate document -> AND TABLE IT <- until the > current document suite is done. > > This is a clearly a compromise position - it would be better > if we _could_ specify a more fleshed out composition mechanism, > but history indicates that this is not likely to happen. Lets get > this base mechanism out there so we can get some more > real-world data to help guide the later debate. > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 11 06:07:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12519; Tue, 11 Jan 2005 06:07:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoK5w-0002C9-6Z; Tue, 11 Jan 2005 06:21:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoJqy-0000Qi-5P; Tue, 11 Jan 2005 06:06:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoJoJ-00082t-F6 for simple@megatron.ietf.org; Tue, 11 Jan 2005 06:03:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12158 for ; Tue, 11 Jan 2005 06:03:37 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoK27-00026c-65 for simple@ietf.org; Tue, 11 Jan 2005 06:17:55 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0BB3YT21234; Tue, 11 Jan 2005 13:03:35 +0200 (EET) X-Scanned: Tue, 11 Jan 2005 13:03:02 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j0BB32Um003910; Tue, 11 Jan 2005 13:03:02 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00cTuWN2; Tue, 11 Jan 2005 12:59:11 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0BAxAx14980; Tue, 11 Jan 2005 12:59:10 +0200 (EET) Received: from [192.168.1.186] ([10.162.252.227]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 Jan 2005 12:59:04 +0200 Message-ID: <41E3B176.3000008@nokia.com> Date: Tue, 11 Jan 2005 12:59:02 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Paul Kyzivat Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41C2997D.9010800@nokia.com> <41E2ABA9.90103@cisco.com> In-Reply-To: <41E2ABA9.90103@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2005 10:59:04.0844 (UTC) FILETIME=[90D454C0:01C4F7CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Ahh, the notorious 3pcc, offerless INVITE scenario... I've always been a bit suspect of this working in an environment that isn't voice-centric. How to make the 3pcc scenario work? Well, if the watcher can't live with the uncertainty that it brings, and the very real possibility that they get an offer containing chess when they really wanted voice, then simply don't send an offerless INVITE! 3pcc seems equally broken in this scenario, regardless of whether AoRs are used with presence or without presence, e.g., typed in from a business card. Cheers, Aki ext Paul Kyzivat wrote: > > > Aki Niemi wrote: > ... > >> These steps should guarantee that the watcher can always make a proper >> selection of which service to invoke. Invoking the service then >> involves more than a simple "clicking the contact", since in the case >> of SIP the watcher generally will e.g. construct an SDP offer that >> matches the service that the watcher thinks the tuple is describing. >> I believe the >> invoking of a service MUST work using an AoR. If an INVITE offering >> voice ends up served by a chess application, I think the system is >> utterly broken, and needs to be fixed. One fix could be using GRUUs as >> contacts, but that is not the only fix, and may not even be the best >> one, IMHO. > > > OK, lets investigate how that might work. I think you assume that when I > have selected a tuple, and constructed a request to it, that the request > wll contain attributes of some sort that correlate to the tuple I > selected, and no other. This is a bad assumption. > > Consider the following case: > > - we have presentity sip:alice@atlanta.com. > > - she has one tuple that identifies a "voice" service > ( false). > > - she has another tuple that identifies a "chess" service > ( true). > > - These two tuples really represent different UAs, but in each case > it is the AoR that is included as a contact in the tuple > > - Bob looks at the entry for Alice in his buddy list, and selects > the IM tuple to initiate a call. > > How do you see this working? I guess your assumption is that this is no > problem. If an INVITE arrives at the proxy with an offer for audio the > proxy will send it to voice service, while one with an offer for chess > protocol. > > But suppose it is a 3pcc controller that is sending the invite, and it > has chosen to send the invite without an offer. What can the proxy do now? > > The best it can probably do is fork the invite. If so, the voice app > would perhaps respond with a 18x with an offer of audio, while the chess > app would respond with a 18x for chess. If so, Bob's UA could cancel the > chess dialog and keep the one with the voice device. > > But it is also possible that the chess app would respond immediately > with a 2xx. If so, you indeed end up talking to a chess service. How > would you propose to solve this problem? > > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 11 08:30:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22784; Tue, 11 Jan 2005 08:30:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoMKZ-0005Ni-Ia; Tue, 11 Jan 2005 08:45:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoLxx-0005OZ-6v; Tue, 11 Jan 2005 08:21:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoLuf-0004ui-V7 for simple@megatron.ietf.org; Tue, 11 Jan 2005 08:18:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21943 for ; Tue, 11 Jan 2005 08:18:20 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoM8S-00057J-GX for simple@ietf.org; Tue, 11 Jan 2005 08:32:39 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0BDIET16216; Tue, 11 Jan 2005 15:18:15 +0200 (EET) X-Scanned: Tue, 11 Jan 2005 15:17:44 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j0BDHiSY028501; Tue, 11 Jan 2005 15:17:44 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00eKUIym; Tue, 11 Jan 2005 15:17:43 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0BDHSU00825; Tue, 11 Jan 2005 15:17:28 +0200 (EET) Received: from [192.168.1.186] ([10.162.252.227]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 Jan 2005 15:17:26 +0200 Message-ID: <41E3D1E3.90702@nokia.com> Date: Tue, 11 Jan 2005 15:17:23 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41C2997D.9010800@nokia.com> <41DF7495.70204@cisco.com> In-Reply-To: <41DF7495.70204@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2005 13:17:26.0120 (UTC) FILETIME=[E4C68680:01C4F7DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Content-Transfer-Encoding: 7bit Hi Jonathan, Inline. ext Jonathan Rosenberg wrote: > inline. I'd ask folks to please read to the end where I have another > compromise proposal on unique URI that may be more palatable than my > previous one. > > Aki Niemi wrote: > >> Hi Jonathan, >> >> First of all, thanks for pushing the resolution of this issue forward by >> making a concrete proposal. >> >> I don't think making the dispatcher visible to the composer/watcher >> actually solves the real problem; it does however reaffirm the >> statement made in the data model that unique contacts URIs are >> required in service tuples. The primary motivation for this >> requirement seems to be that it enables overriding service elements. > > > No, not so at all. Please see my post in response to Robert's compromise > proposal where I try to explain the concern more. All right, let's continue this discussion there. ..snip.. >> If we reverse the assumption made in the data model that requires >> uniqueness of service URIs, will watchers generally be confused if >> they encounter service tuples with the same contact? I don't think so, >> as long as the watcher does the following: >> >> 1) takes note of the meta-information of each service (timestamp, >> q-value) giving preference to a fresher service, or one with higher >> q-value. > > > The point of q-value is not to say "please use this service over another > service". PDM talks about this. If that were true there would be no > point in advertising anything but the highest priority service. Sure it does. Q-value (the priority attribute, that is) is the service-independent, presentity-provided preference. Unless I've totally misread PIDF, the priority attribute is used to indicate to the watcher the preference with which the various communications channels employed by the presentity should be used. It doesn't prohibit selecting a tuple whose priority is not the highest. >> 2) takes note of the characteristics of each service (prescaps for >> example) along with the contact URI, applying its own known >> characteristics and service URIs to determine what service the tuple >> is describing > > > This seems like the "and magic happens" step, and is exactly the one I'm > worried about. There is basically no way two watchers are going to > interpret these the same. The essence of the problem is that the > document has lost standalone meaning for what the tuple represents. I'm assuming that each tuple needs to carry meta-information (e.g., prescaps) that unambiguously identifies the offered service. Otherwise, a watcher could select a GRUU contact with a misinterpreted service, causing for example an IM agent to receive a voice invitation. This could happen for example with a barebones SIP user agent that has limited understanding of the meta-information. This assumption has to hold regardless of whether we stick to the URI uniqueness rule or not. In fact, an AoR contact is less prone to errors caused by watcher misinterpretation, since any false selection decision made by the wathcer can still be recovered, if for example, the INVITE is received by a dispatcher that has a suitable helper application. So, agreed the above step is "magic", but I was under the assumption that we were defining this magic in the form of prescaps, and other similar markup. >> 3) takes note of the status, meaning that a basic status of OPEN is a >> better choice than one with CLOSED, for example >> >> 4) all of the above being equal, folds all identical services together >> (after all they are identical in all ways that have relevance to the >> watcher) >> >> These steps should guarantee that the watcher can always make a proper >> selection of which service to invoke. Invoking the service then >> involves more than a simple "clicking the contact", since in the case >> of SIP the watcher generally will e.g. construct an SDP offer that >> matches the service that the watcher thinks the tuple is describing. > > > It could do that but it need not; the benefit of a URI and its > definitional characteristic is that you need no other context beyond the > URI to use it. I should be able to make a SIP call to that URI without > having seen the presence document at all, and it works to the degree > that SIP itself would allow the call to proceed. Presence might help > optimize by allowing me to select media streams that work out of the > box, for example, but its an optimization not a requirment for > contacting the URI. If it is, the URI becomes meaningless. I agree, but you sound like you would be in favor of AoR contact over a GRUU contact here. After all, a GRUU really needs a context to be all that useful. Without one, e.g., going through my call-logs from last month, there is no guarantee that a GRUU used then would work any more, or indeed work for any other session than the one made back then. AoR has that property in a sense that it can be expected to work independent of time, place and type of session. Also, there are always (at least) two participants in a call and both have their preference over which media to use. Surely the watcher also has a say in what sort of media to commit to. This may not be that evident in todays UAs that predominantly offer voice-only. >> I believe the invoking of a service MUST work using an AoR. If an >> INVITE offering voice ends up served by a chess application, I think >> the system is utterly broken, and needs to be fixed. > > > This is contradictory. You are saying that two services that are > different have to be able to have the same AoR, but if you have the same > AOR, how can you guarantee that an INVITE to that AOR is properly > dispatched to the right app depending on where it came from? Aren't you forgetting something here, namely an SDP offer that (usually [1]) goes along with the INVITE? To me this sounds like we have systems where dispatching can only work based on Request URI. But surely you can dispatch using a plethora of other handles, such as Require-tokens, SDP parameters and Subject-headers, to name a few. I don't like the idea of making the SDP be a static description of all media available to the wathcer, and base service dispatch (whether done locally at the client or by a proxy) on information "encoded" in the GRUU. This seems to be the direction were heading here. > > One fix could be using GRUUs as > >> contacts, but that is not the only fix, and may not even be the best >> one, IMHO. >> >> All and all, I still don't buy the requirement for unique service >> URIs. Also, I think that the default composer policy of union (i.e., >> collect all service tuples together intact) will take care of the 95% >> need, leaving out more sophisticated things like override and >> merging/splitting for future study. > > > I agree with that. I'll note that using GRUU has that effect. > > Let me make another proposal, which is a variation on the dispatcher > model I suggested, modified by an idea Henning proposed. > > When a PUA publishes a tuple about itself, the , if present, > still needs to route to itself. However, we also define an additional > presence attribute called (suggested by Henning), which > contains a URI which routes to a dispatcher through which that service > might be reachable. In the SIP case, this could contain the AOR. > > Thus, one could build a PUA which publishes about itself. It has no > GRUU, so it omits the URI and includes > containing the AOR. > > Another smarter PUA would include the GRUU in the , possibly in > addition to with the AOR. > > A dumb composer can always union. A smarter composer can use the service > URIs in the if present, in combination with the > information to correlate the services together. It could then produce a > tuple with the AOR in the and no . > > The current contract and meaning of the as a service remains as > it is in the PDM. However, we now have the case where there is a tuple > describing a service that is not directly reachable. The watcher knows a > URI through which it might be reached, and can render or combine those > together in whatever way it sees fit. > > In the future, we could define this dispatcher service so that a watcher > could even learn the policy governing how the dispatch is done. > > I think this is simpler than my original proposal, has the benefit of > maintaining the union operation as the default composition policy, > retains the semantics of the service tuple as currently in the PDM. > > I would be amenable to defining some kind of additional ID that serves > to identify a tuple uniquely when the is not present. This > would allow override even for tuples with no contact (as those published > from a PUA not supporting gruu). > > Is that more palatable? I agree this is a simpler approach, but the underlying notion of unique contact URIs still bugs me. Cheers, Aki [1] Paul pointed out the 3pcc scenario in another message, where admittedly an offerless INVITE would cause problems. > Thanks, > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 11 09:01:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24545; Tue, 11 Jan 2005 09:01:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoMoa-0005zr-HK; Tue, 11 Jan 2005 09:16:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoMV3-00029L-OP; Tue, 11 Jan 2005 08:55:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoMRd-0001iv-RF for simple@megatron.ietf.org; Tue, 11 Jan 2005 08:52:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24132 for ; Tue, 11 Jan 2005 08:52:24 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoMfO-0005q4-SU for simple@ietf.org; Tue, 11 Jan 2005 09:06:43 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 11 Jan 2005 08:51:51 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0BDpmW0010620; Tue, 11 Jan 2005 08:51:48 -0500 (EST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOF86111; Tue, 11 Jan 2005 08:50:28 -0500 (EST) Message-ID: <41E3D9A4.702@cisco.com> Date: Tue, 11 Jan 2005 08:50:28 -0500 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: Tim Rang Subject: Re: [Simple] PIDF "entity" attribute usage References: <1BEC4DA05ABCD34FACFCFC82086AC2470494F0B3@RED-MSG-43.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA24132 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Tim Rang wrote: > Folks, >=20 > =20 >=20 > In nearly all of the I-Ds related to presence, every example pidf=20 > document I find contains an entity attribute with a =93pres=94 scheme. = The=20 > schema for RFC 3863 indicates that any URI is acceptable here. However= ,=20 > section 4.1.1 states- >=20 > The value of the 'entity' attribute is the 'pres' URL of= the PRESENTITY publishing this presence document. >=20 > =20 >=20 > Recently, I=92ve started to see some instances where the entity attribu= te contains a sip scheme (Ex- draft-ietf-simple-presence-data-model-01 >=20 > ). >=20 > =20 >=20 > My questions are: >=20 > - What is the intended usage of this entity attribute in SIMPL= E? It identifies the entity that the pidf document describes. In many cases you should already know that (because you subscribed to=20 it) and in those cases it may be redundant. In other cases, such as when=20 you have used an RLS to subscribe to a list of presentities, it is=20 important information. The URI it contains also is usually what you use to request presence. > - What is the meaning of the =91pres=92 scheme and why should = we=20 > use it over something more relevant (i.e. =91sip=92)? The original work on presence was done by the IMPP WG. The PIDF and CPIM=20 specifications were intended to be protocol independent - allowing=20 multiple IM&Presence protocols to be developed that could interoperate. One aspect of this is having a presence URI scheme ("pres") that is=20 itself independent of the protocols that are used to access it. SIMPLE is one protocol specific realization of the presence=20 functionality defined by IMPP. Of course it is built on SIP, and so SIP=20 URIs are natural for identifying presentities in SIMPLE. However the=20 means by which pres URIs can be used with SIMPLE is also defined. So, at least in principle, when using SIMPLE, you can use either sip or=20 pres URIs. However this assumes the specific implementation you are=20 using actually supports this. In practice you should determine what the=20 implementation you are using supports. Paul > Thanks, >=20 > Tim Rang >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 11 09:46:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27738; Tue, 11 Jan 2005 09:46:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoNVu-0006vO-Ta; Tue, 11 Jan 2005 10:00:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoNGP-00017F-61; Tue, 11 Jan 2005 09:44:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoNCr-0000pH-B2 for simple@megatron.ietf.org; Tue, 11 Jan 2005 09:41:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27467 for ; Tue, 11 Jan 2005 09:41:11 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoNQf-0006oZ-2S for simple@ietf.org; Tue, 11 Jan 2005 09:55:31 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 11 Jan 2005 09:53:23 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0BEecm4005636; Tue, 11 Jan 2005 09:40:38 -0500 (EST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOF89473; Tue, 11 Jan 2005 09:40:37 -0500 (EST) Message-ID: <41E3E565.4060105@cisco.com> Date: Tue, 11 Jan 2005 09:40:37 -0500 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: Aki Niemi Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41C2997D.9010800@nokia.com> <41E2ABA9.90103@cisco.com> <41E3B176.3000008@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit Aki Niemi wrote: > Ahh, the notorious 3pcc, offerless INVITE scenario... I've always been a > bit suspect of this working in an environment that isn't voice-centric. > > How to make the 3pcc scenario work? Well, if the watcher can't live with > the uncertainty that it brings, and the very real possibility that they > get an offer containing chess when they really wanted voice, then simply > don't send an offerless INVITE! > > 3pcc seems equally broken in this scenario, regardless of whether AoRs > are used with presence or without presence, e.g., typed in from a > business card. The problem isn't with offerless INVITE - it is with the interaction of offerless invite with forking. Both features frequently present problems on their own, and in combination things get even worse. However, when I have no information about the AoR I am inviting, my expectations can't be very high. I have explicitly said that I want the callee to make me an offer. So if the offer is one I don't like, I must deal with that. However, when I am a presence watcher, my expectations are higher. I have specific information from the tuple I have selected, that voice should be available from the address specified in the tuple. So if I send an offerless invite I should have a reasonable expectation that the returned offer will include audio. Getting an offer for chess instead should be surprising. Even so, in a lot of cases this scenario will indeed do something reasonable. As long as all the forked calls return 1xx responses with offers, and don't answer too quickly, the caller will have a chance to cancel the ones that don't match expectations. But this rules out any auto-answer applications that answer on the first ring, at least in forking situations. You suggest not sending an offerless invite. But whenever there is a 3pcc involved there is a bootstrapping problem - it doesn't inherently know what to offer without asking one end or the other. While there is paranoia about B2BUAs and hence 3PCC within the sip wg, there are a lot of very interesting applications (such as various forms of click-to-dial) that can be built using this technique. We really don't want to break it. A better solution in some of these cases would be to change how forking works. If the forking were replaced by redirection to multiple targets (so that the caller can do the forking locally), or if all forks were permitted to proceed to completion, then this wouldn't be a problem. But that is a discussion for another day. Until then, I see no better alternative than to go ahead, living with the limitations. They will cause problems in some cases, and we will then be forced to deal with them. At least we will know where to expect them, and will know some work-arounds for them. For you guys that don't want to use GRUUs, I think you could find an alternative with properties that are sufficient for your needs. For instance, you mignt consider adding a grid parameter to the AoR in each tuple, explicitly identifying the service. Paul > Cheers, > Aki > > ext Paul Kyzivat wrote: > >> >> >> Aki Niemi wrote: >> ... >> >>> These steps should guarantee that the watcher can always make a >>> proper selection of which service to invoke. Invoking the service >>> then involves more than a simple "clicking the contact", since in the >>> case of SIP the watcher generally will e.g. construct an SDP offer >>> that matches the service that the watcher thinks the tuple is >>> describing. I believe the >>> invoking of a service MUST work using an AoR. If an INVITE offering >>> voice ends up served by a chess application, I think the system is >>> utterly broken, and needs to be fixed. One fix could be using GRUUs >>> as contacts, but that is not the only fix, and may not even be the >>> best one, IMHO. >> >> >> >> OK, lets investigate how that might work. I think you assume that when >> I have selected a tuple, and constructed a request to it, that the >> request wll contain attributes of some sort that correlate to the >> tuple I selected, and no other. This is a bad assumption. >> >> Consider the following case: >> >> - we have presentity sip:alice@atlanta.com. >> >> - she has one tuple that identifies a "voice" service >> ( false). >> >> - she has another tuple that identifies a "chess" service >> ( true). >> >> - These two tuples really represent different UAs, but in each case >> it is the AoR that is included as a contact in the tuple >> >> - Bob looks at the entry for Alice in his buddy list, and selects >> the IM tuple to initiate a call. >> >> How do you see this working? I guess your assumption is that this is >> no problem. If an INVITE arrives at the proxy with an offer for audio >> the proxy will send it to voice service, while one with an offer for >> chess protocol. >> >> But suppose it is a 3pcc controller that is sending the invite, and it >> has chosen to send the invite without an offer. What can the proxy do >> now? >> >> The best it can probably do is fork the invite. If so, the voice app >> would perhaps respond with a 18x with an offer of audio, while the >> chess app would respond with a 18x for chess. If so, Bob's UA could >> cancel the chess dialog and keep the one with the voice device. >> >> But it is also possible that the chess app would respond immediately >> with a 2xx. If so, you indeed end up talking to a chess service. How >> would you propose to solve this problem? >> >> Paul >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 11 10:42:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02221; Tue, 11 Jan 2005 10:42:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoONb-0007xa-81; Tue, 11 Jan 2005 10:56:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoO6r-0005ii-RS; Tue, 11 Jan 2005 10:39:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoNyq-000493-GK for simple@megatron.ietf.org; Tue, 11 Jan 2005 10:30:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01456 for ; Tue, 11 Jan 2005 10:30:46 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoOCg-0007jT-7L for simple@ietf.org; Tue, 11 Jan 2005 10:45:07 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 11 Jan 2005 07:31:36 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0BFTqKE003474; Tue, 11 Jan 2005 07:29:54 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOF94202; Tue, 11 Jan 2005 10:29:50 -0500 (EST) Message-ID: <41E3F0EE.7020805@cisco.com> Date: Tue, 11 Jan 2005 10:29:50 -0500 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: Aki Niemi Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41C2997D.9010800@nokia.com> <41DF7495.70204@cisco.com> <41E3D1E3.90702@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: 7bit Inline. Aki Niemi wrote: [snip] >>> If we reverse the assumption made in the data model that requires >>> uniqueness of service URIs, will watchers generally be confused if >>> they encounter service tuples with the same contact? I don't think >>> so, as long as the watcher does the following: >>> >>> 1) takes note of the meta-information of each service (timestamp, >>> q-value) giving preference to a fresher service, or one with higher >>> q-value. >> >> The point of q-value is not to say "please use this service over >> another service". PDM talks about this. If that were true there would >> be no point in advertising anything but the highest priority service. > > Sure it does. Q-value (the priority attribute, that is) is the > service-independent, presentity-provided preference. Unless I've totally > misread PIDF, the priority attribute is used to indicate to the watcher > the preference with which the various communications channels employed > by the presentity should be used. It doesn't prohibit selecting a tuple > whose priority is not the highest. I agree with you both, and don't see what there is to disagree about. It becomes a problem only if I do something stupid, like decide to use your chess service tuple rather than the voice service one because of q-values even though I am going to send an invite for voice. >>> 2) takes note of the characteristics of each service (prescaps for >>> example) along with the contact URI, applying its own known >>> characteristics and service URIs to determine what service the tuple >>> is describing >> >> This seems like the "and magic happens" step, and is exactly the one >> I'm worried about. There is basically no way two watchers are going to >> interpret these the same. The essence of the problem is that the >> document has lost standalone meaning for what the tuple represents. > > I'm assuming that each tuple needs to carry meta-information (e.g., > prescaps) that unambiguously identifies the offered service. Otherwise, > a watcher could select a GRUU contact with a misinterpreted service, > causing for example an IM agent to receive a voice invitation. This > could happen for example with a barebones SIP user agent that has > limited understanding of the meta-information. > > This assumption has to hold regardless of whether we stick to the URI > uniqueness rule or not. In fact, an AoR contact is less prone to errors > caused by watcher misinterpretation, since any false selection decision > made by the wathcer can still be recovered, if for example, the INVITE > is received by a dispatcher that has a suitable helper application. > > So, agreed the above step is "magic", but I was under the assumption > that we were defining this magic in the form of prescaps, and other > similar markup. I don't understand Jonathan's issue here. We long ago agreed on the feature based identification of services. You may have a "service" that you call X, which is described by features A,B,C,D that it publishes in a tuple. I have a service Y that can work with anything having features A,B,C. So to me the tuple published by your service X is an instance of service Y. The two can communicate, so we are both happy. No magic. >>> 3) takes note of the status, meaning that a basic status of OPEN is a >>> better choice than one with CLOSED, for example >>> >>> 4) all of the above being equal, folds all identical services >>> together (after all they are identical in all ways that have >>> relevance to the watcher) >>> >>> These steps should guarantee that the watcher can always make a >>> proper selection of which service to invoke. Invoking the service >>> then involves more than a simple "clicking the contact", since in the >>> case of SIP the watcher generally will e.g. construct an SDP offer >>> that matches the service that the watcher thinks the tuple is >>> describing. >> >> It could do that but it need not; the benefit of a URI and its >> definitional characteristic is that you need no other context beyond >> the URI to use it. I should be able to make a SIP call to that URI >> without having seen the presence document at all, and it works to the >> degree that SIP itself would allow the call to proceed. Presence might >> help optimize by allowing me to select media streams that work out of >> the box, for example, but its an optimization not a requirment for >> contacting the URI. If it is, the URI becomes meaningless. Here I agree with Jonathan. Elsewhere I pointed out the 3PCC offerless invite case. But there are other cases as well. Consider the case where you have two tuples containing the same AoR. One is just voice. The other is voice+video. Because I have a video phone, and anticipate using the video, I choose to call your tuple that has video. But I start out with my video disabled because I'm polite and want to ask before using it. So my initial invite only contains audio. (If/when I turn on video a reinvite will add the video stream.) But your proxy, thinking itself clever, looks at my offer and decides to send it to your audio phone. Now when I try to add video (which I think I should expect because your tuple advertised it), the attempt fails because you have no video. Yuck! > I agree, but you sound like you would be in favor of AoR contact over a > GRUU contact here. After all, a GRUU really needs a context to be all > that useful. What is your point? Is this "context" needed in the caller or callee? If you mean the callee, then yes, it is possible for gruu to be used in a way where the grid parameter indexes context stored in the callee, with the gruu useless once that context has been forgotten. But that isn't always the case. In some cases all that is necessary is that the gruu route to the right UA, with no added context necessary at the receiving end. (The grid parameter may be irrelevant.) In other cases the context needed at the receiving end may be encoded into the grid parameter. If you mean the caller needs context, then isn't that the caller's problem? In the situation at hand the caller *has* context: the presentity and all the contents of the selected tuple. > Without one, e.g., going through my call-logs from last > month, there is no guarantee that a GRUU used then would work any more, > or indeed work for any other session than the one made back then. I recall you brought up this point in private discussion, and I have been thinking about it. It is an interesting problem, but one that is in no way restricted to presence based calling. It is relevant to many uses of GRUU. In all cases I think the caller has context other than the gruu. We may need to find a way to incorporate that into the call so that it may be incorporated in call logs. Another possibility is that we might consider defining an encoding of gruus that explicitly exposes the related AoR. This would have to be optional, for cases when that info is not intended to be public, but in many cases it is not secret information. > AoR has that property in a sense that it can be expected to work > independent of time, place and type of session. Remember that the original motivation for gruu was to ensure that transfers get to the right UA. That is still an important property. The use of AoR didn't work for that. The problem with call logs is going to exist in that scenario too. Also, I don't understand how you are going to solve the whole range of problems that gruus address without using gruus. Are you simply counting on there only being a single UAS per AoR in your environment? > Also, there are always (at least) two participants in a call and both > have their preference over which media to use. Surely the watcher also > has a say in what sort of media to commit to. This may not be that > evident in todays UAs that predominantly offer voice-only. How is this relevant? The watcher will be looking at the tuples to find ones that are consistent in capabilities (including media) that it can deal with. >>> I believe the invoking of a service MUST work using an AoR. If an >>> INVITE offering voice ends up served by a chess application, I think >>> the system is utterly broken, and needs to be fixed. >> >> This is contradictory. You are saying that two services that are >> different have to be able to have the same AoR, but if you have the >> same AOR, how can you guarantee that an INVITE to that AOR is properly >> dispatched to the right app depending on where it came from? > > Aren't you forgetting something here, namely an SDP offer that (usually > [1]) goes along with the INVITE? To me this sounds like we have systems > where dispatching can only work based on Request URI. But surely you can > dispatch using a plethora of other handles, such as Require-tokens, SDP > parameters and Subject-headers, to name a few. I believe there are problems to be worked out before e2e encryption can work in the presence of forking. But in theory the contents of the SDP body might not be available to the proxy. Building a system that depends on routing that way will rule out support for e2e security. > I don't like the idea of making the SDP be a static description of all > media available to the wathcer, and base service dispatch (whether done > locally at the client or by a proxy) on information "encoded" in the > GRUU. This seems to be the direction were heading here. I'm not sure of your point here. When making an offer, the offerer should offer whatever media it desires to use at that time. This need not include every medium that could be used later in the call, or on some other call. For instance, Alice might have a voice+IM client. With it she can make many calls containing IM, but I can only have active voice in a single call. She is in a voice call with Bob, but also needs to talk to Charlie. So, while still talking to Bob, she looks up Charlie in her buddylist, finds a tuple for voice+IM, and makes an IM-only call to it. In her IM session with Charlie she starts to fill him in. When her call to Bob is over, she adds voice in to the call with Charlie. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 11 15:14:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22446; Tue, 11 Jan 2005 15:14:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoScr-0005cq-Hm; Tue, 11 Jan 2005 15:28:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoSM6-0007rV-EZ; Tue, 11 Jan 2005 15:11:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoSHT-0003IW-Ox for simple@megatron.ietf.org; Tue, 11 Jan 2005 15:06:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21410 for ; Tue, 11 Jan 2005 15:06:18 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoSVM-0005R1-21 for simple@ietf.org; Tue, 11 Jan 2005 15:20:40 -0500 Received: from [127.0.0.1] (adam@magus.nostrum.com [10.10.10.2]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j0BK6BuS076117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jan 2005 14:06:13 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <41E431B4.5060305@nostrum.com> Date: Tue, 11 Jan 2005 14:06:12 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Simple] Moving the presence data model work forward References: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> In-Reply-To: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit I'd like to add my voice to the several other messages posted here: I think this is a reasonable way to proceed. /a Robert Sparks wrote: > We seem to have ground to a halt again on finishing > the Presence Data Model. This is blocking a very large > portion of the rest of our work. > > The current sticking point is, at its core, about where > we are drawing the line for a baseline composition > algorithm. > > We've looked several times at whether we would > try to provide a complete standardized composition > system, and have consistently come to the conclusion > that the task is vastly difficult. We've agreed to build > a minimal system that would not preclude work on > more complex standardized composition in the future. > > We've achieved consensus around a using simple > union as the baseline mechanism. Anything more > would be something done outside a standard. We > recognize that this means that different services may > do different things with the same inputs, but until we > have more deployment experience, doing much more > is a "boiling the ocean" class problem. > > To hopefully avoid some of the problems that might arise > with that compromise, the Presence Data Model work > tried to add two important things: > > - It introduced a structure that made it more likely > that elements creating presence documents would > put information in consistent places. This reduces > ambiguity and makes it more likely that the intent > of the document will be rendered accurately across > different implementations. > - It tried to take one more step towards a more complex > composition policy by defining what identifies a service > tuple, so that compositors would have a standard > algorithm for choosing to combine information about > the "same service" from different sources. > > The effort was very successful on the first point. We have > not yet achieved consensus around the second. To reach > agreement, we will need either to back up to something > closer to our previous consensus point, or go further towards > a complete standard composition system. > > In order to allow the document suite that is blocked > on this conversation to go forward, so that we can get > implementation and deployment experience, I believe > it will be necessary to step back: > > - We keep the representation model in the PDM work - > and have been accepted as useful. > > - We maintain the notion that tuples with contacts are "services", > but don't try to standardize what "same service" means at this > time beyond the basic tools that PIDF gives us. > > - We break out discussion of a more complete standard composition > system into a separate document -> AND TABLE IT <- until the > current document suite is done. > > This is a clearly a compromise position - it would be better > if we _could_ specify a more fleshed out composition mechanism, > but history indicates that this is not likely to happen. Lets get > this base mechanism out there so we can get some more > real-world data to help guide the later debate. > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 11 21:57:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29596; Tue, 11 Jan 2005 21:57:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoYuz-0000Fe-Ob; Tue, 11 Jan 2005 22:11:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoYZu-0006GL-99; Tue, 11 Jan 2005 21:49:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoYUA-0004tQ-2v for simple@megatron.ietf.org; Tue, 11 Jan 2005 21:43:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29008 for ; Tue, 11 Jan 2005 21:43:48 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoYi5-0008R1-4l for simple@ietf.org; Tue, 11 Jan 2005 21:58:14 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 11 Jan 2005 18:45:03 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0C2hEiH011287; Tue, 11 Jan 2005 18:43:15 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn7-723.cisco.com [10.21.146.211]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AVM72112; Tue, 11 Jan 2005 18:43:13 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 11 Jan 2005 17:48:04 -0800 From: Cullen Jennings To: Justin Uberti , Ben Campbell , Orit Levin , Robert Sparks , Rohan Mahy Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" Subject: [Simple] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Justin brought up an interesting uses case - I remember discussing this before but I forget the resolution. I think Orit might have pointed it out before. Say we have a xcon style text conference and the focus is M and A, B, and C have an MSRP connection to M. Now when A and B send to M, M will send the text to C and the SIP session will be to M and in many ways it will look like it came from M. However, we need a way for the message to indicate a hint that M believes it was originally from A (or B as the case may be). Do folks remember if we resolved this? Saying all messages have to be CPIM seems like overkill to me for simple text conferencing. You could have this same case in a simpler form where B is has a direction session with A and C and B is doing the "mixing" of the text. Thoughts, Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 12 00:00:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07394; Wed, 12 Jan 2005 00:00:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Coaqd-0002j3-Mw; Wed, 12 Jan 2005 00:15:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoaV9-0003p9-VQ; Tue, 11 Jan 2005 23:52:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoaL7-0001WJ-Df for simple@megatron.ietf.org; Tue, 11 Jan 2005 23:42:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06139 for ; Tue, 11 Jan 2005 23:42:34 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoaZ1-0002Dv-7A for simple@ietf.org; Tue, 11 Jan 2005 23:57:02 -0500 Received: from [127.0.0.1] (adam@magus.nostrum.com [10.10.10.2]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j0C4eA28016983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jan 2005 22:40:11 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <41E4AA2A.5050206@nostrum.com> Date: Tue, 11 Jan 2005 22:40:10 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple] References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Orit Levin , "simple@ietf.org" , Justin Uberti X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: >Say we have a xcon style text conference and the focus is M and A, B, and C >have an MSRP connection to M. Now when A and B send to M, M will send the >text to C and the SIP session will be to M and in many ways it will look >like it came from M. However, we need a way for the message to indicate a >hint that M believes it was originally from A (or B as the case may be). > >Do folks remember if we resolved this? Saying all messages have to be CPIM >seems like overkill to me for simple text conferencing. > > I thought that was it. Is CPIM perceived to be that heavy? It seems excruciatingly straightforward to implement to me. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 12 00:02:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07561; Wed, 12 Jan 2005 00:02:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Coasa-0002lo-Pb; Wed, 12 Jan 2005 00:17:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoaVA-0003pI-Jt; Tue, 11 Jan 2005 23:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoaL8-0001YP-Ur for simple@megatron.ietf.org; Tue, 11 Jan 2005 23:42:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06143 for ; Tue, 11 Jan 2005 23:42:36 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoaZ4-0002Dy-V7 for simple@ietf.org; Tue, 11 Jan 2005 23:57:04 -0500 Received: from [192.168.1.102] (c-24-23-89-57.client.comcast.net [24.23.89.57]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j0C4fCIV017069 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 11 Jan 2005 22:41:13 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2CCC485F-6454-11D9-B9AF-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Tue, 11 Jan 2005 22:41:07 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: Justin Uberti , Rohan Mahy , Orit Levin , "simple@ietf.org" Subject: [Simple] Re: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit We had lots of gnashing of teeth on this one. The original intent was to use message/cpim wrappers when you need to make an attribution to an identity other than the one associated with M. A number of people argued on either side, and we ended up where we started, with the additional caveat of punting on things like chained identities (i.e. what if B was _also_ a focus...) The most recent draft had some clarifying text on this. On Jan 11, 2005, at 7:48 PM, Cullen Jennings wrote: > > Justin brought up an interesting uses case - I remember discussing this > before but I forget the resolution. I think Orit might have pointed it > out > before. > > Say we have a xcon style text conference and the focus is M and A, B, > and C > have an MSRP connection to M. Now when A and B send to M, M will send > the > text to C and the SIP session will be to M and in many ways it will > look > like it came from M. However, we need a way for the message to > indicate a > hint that M believes it was originally from A (or B as the case may > be). > > Do folks remember if we resolved this? Saying all messages have to be > CPIM > seems like overkill to me for simple text conferencing. > > You could have this same case in a simpler form where B is has a > direction > session with A and C and B is doing the "mixing" of the text. > > Thoughts, > > Cullen > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 12 09:01:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14380; Wed, 12 Jan 2005 09:01:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CojHk-0006Pz-M4; Wed, 12 Jan 2005 09:15:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoitF-0001II-9y; Wed, 12 Jan 2005 08:50:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Coiph-00086K-NF for simple@megatron.ietf.org; Wed, 12 Jan 2005 08:46:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13097 for ; Wed, 12 Jan 2005 08:46:44 -0500 (EST) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Coj3g-0005wh-19 for simple@ietf.org; Wed, 12 Jan 2005 09:01:16 -0500 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id 2FF79A96B9; Wed, 12 Jan 2005 14:46:03 +0100 (CET) Received: from [10.150.225.105] (gprs-ggsn6-nat.mobil.telenor.no [212.17.141.54]) by voyager.coretrek.no (Postfix) with ESMTP id B7048A8929; Wed, 12 Jan 2005 14:45:58 +0100 (CET) In-Reply-To: <41DF7495.70204@cisco.com> References: <41B60EAD.5090504@cisco.com> <41C2997D.9010800@nokia.com> <41DF7495.70204@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <474374BC-64A0-11D9-8262-000D93C60BA0@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward Date: Wed, 12 Jan 2005 14:45:53 +0100 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: Simple WG , Aki Niemi X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit On Jan 8, 2005, at 6:50 AM, Jonathan Rosenberg wrote: > > Let me make another proposal, which is a variation on the dispatcher > model I suggested, modified by an idea Henning proposed. > > When a PUA publishes a tuple about itself, the , if present, > still needs to route to itself. However, we also define an additional > presence attribute called (suggested by Henning), which > contains a URI which routes to a dispatcher through which that service > might be reachable. In the SIP case, this could contain the AOR. > > Thus, one could build a PUA which publishes about itself. It has no > GRUU, so it omits the URI and includes > containing the AOR. > > Another smarter PUA would include the GRUU in the , possibly > in addition to with the AOR. > > A dumb composer can always union. A smarter composer can use the > service URIs in the if present, in combination with the > information to correlate the services together. It could > then produce a tuple with the AOR in the and no > . > > The current contract and meaning of the as a service remains > as it is in the PDM. However, we now have the case where there is a > tuple describing a service that is not directly reachable. The watcher > knows a URI through which it might be reached, and can render or > combine those together in whatever way it sees fit. > > In the future, we could define this dispatcher service so that a > watcher could even learn the policy governing how the dispatch is > done. > > I think this is simpler than my original proposal, has the benefit of > maintaining the union operation as the default composition policy, > retains the semantics of the service tuple as currently in the PDM. > > I would be amenable to defining some kind of additional ID that serves > to identify a tuple uniquely when the is not present. This > would allow override even for tuples with no contact (as those > published from a PUA not supporting gruu). > > Is that more palatable? Yes, I think this is proposal is ok. /Hisham > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 12 18:07:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26598; Wed, 12 Jan 2005 18:07:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoroF-0002nb-EP; Wed, 12 Jan 2005 18:21:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CorX3-0002zl-7b; Wed, 12 Jan 2005 18:04:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CokpG-0006pX-7U for simple@megatron.ietf.org; Wed, 12 Jan 2005 10:54:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23958 for ; Wed, 12 Jan 2005 10:54:24 -0500 (EST) Received: from imo-m24.mx.aol.com ([64.12.137.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Col3G-0000b0-62 for simple@ietf.org; Wed, 12 Jan 2005 11:08:57 -0500 Received: from Juberti@aol.com by imo-m24.mx.aol.com (mail_out_v37_r3.8.) id e.89.1e1baaf1 (15877); Wed, 12 Jan 2005 10:53:14 -0500 (EST) Received: from pc-sn654362.ad.aol.aoltw.net ([10.180.61.178]) by air-id07.mx.aol.com (v104.17) with ESMTP id MAILINID74-3e0541e547e949; Wed, 12 Jan 2005 10:53:14 -0500 Date: Wed, 12 Jan 2005 10:53:15 -0500 From: "Justin Uberti" To: "Ben Campbell" In-Reply-To: <2CCC485F-6454-11D9-B9AF-000D93B0AE1A@nostrum.com> Message-ID: <41E547EB.7040004@aol.com> References: <2CCC485F-6454-11D9-B9AF-000D93B0AE1A@nostrum.com> X-Mailer: AOL Communicator (20030919.3 Win) Organization: America Online MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii X-AOL-IP: 10.180.61.178 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-Mailman-Approved-At: Wed, 12 Jan 2005 18:04:03 -0500 Cc: Cullen Jennings , Rohan Mahy , Orit Levin , "simple@ietf.org" Subject: [Simple] Re: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab I quickly read RFC 3862 to come up to speed on message/cpim. Which header lines are mandatory to implement? When used with MSRP, the From header seems to be the only thing needed to solve the original problem I raised. Thanks, --justin Ben Campbell wrote on 1/11/2005, 11:41 PM: > We had lots of gnashing of teeth on this one. The original intent was > to use message/cpim wrappers when you need to make an attribution to an > identity other than the one associated with M. > > A number of people argued on either side, and we ended up where we > started, with the additional caveat of punting on things like chained > identities (i.e. what if B was _also_ a focus...) > > The most recent draft had some clarifying text on this. > > On Jan 11, 2005, at 7:48 PM, Cullen Jennings wrote: > > > > > Justin brought up an interesting uses case - I remember discussing this > > before but I forget the resolution. I think Orit might have pointed it > > out > > before. > > > > Say we have a xcon style text conference and the focus is M and A, B, > > and C > > have an MSRP connection to M. Now when A and B send to M, M will send > > the > > text to C and the SIP session will be to M and in many ways it will > > look > > like it came from M. However, we need a way for the message to > > indicate a > > hint that M believes it was originally from A (or B as the case may > > be). > > > > Do folks remember if we resolved this? Saying all messages have to be > > CPIM > > seems like overkill to me for simple text conferencing. > > > > You could have this same case in a simpler form where B is has a > > direction > > session with A and C and B is doing the "mixing" of the text. > > > > Thoughts, > > > > Cullen > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 12 18:44:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29923; Wed, 12 Jan 2005 18:44:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CosOV-0003VZ-Rp; Wed, 12 Jan 2005 18:59:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cos0w-0007VQ-8v; Wed, 12 Jan 2005 18:34:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cornp-0004p4-Js for simple@megatron.ietf.org; Wed, 12 Jan 2005 18:21:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28356 for ; Wed, 12 Jan 2005 18:21:23 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cos1t-00034y-Fd for simple@ietf.org; Wed, 12 Jan 2005 18:36:00 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 12 Jan 2005 15:20:50 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0CNKiiH000819; Wed, 12 Jan 2005 15:20:45 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOH24741; Wed, 12 Jan 2005 18:20:42 -0500 (EST) Message-ID: <41E5B0CA.2010306@cisco.com> Date: Wed, 12 Jan 2005 18:20:42 -0500 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: Justin Uberti Subject: Re: [Simple] Re: References: <2CCC485F-6454-11D9-B9AF-000D93B0AE1A@nostrum.com> <41E547EB.7040004@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Orit Levin , "simple@ietf.org" , Rohan Mahy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Justin Uberti wrote: > I quickly read RFC 3862 to come up to speed on message/cpim. Which > header lines are mandatory to implement? When used with MSRP, the From > header seems to be the only thing needed to solve the original problem I > raised. As I recall, they are all mandatory to *implement*. But they aren't all mandatory to *use*. And of course "implementing" the ones you don't use isn't so hard. Paul > Thanks, > --justin > > Ben Campbell wrote on 1/11/2005, 11:41 PM: > > > We had lots of gnashing of teeth on this one. The original intent was > > to use message/cpim wrappers when you need to make an attribution to an > > identity other than the one associated with M. > > > > A number of people argued on either side, and we ended up where we > > started, with the additional caveat of punting on things like chained > > identities (i.e. what if B was _also_ a focus...) > > > > The most recent draft had some clarifying text on this. > > > > On Jan 11, 2005, at 7:48 PM, Cullen Jennings wrote: > > > > > > > > Justin brought up an interesting uses case - I remember discussing this > > > before but I forget the resolution. I think Orit might have pointed it > > > out > > > before. > > > > > > Say we have a xcon style text conference and the focus is M and A, B, > > > and C > > > have an MSRP connection to M. Now when A and B send to M, M will send > > > the > > > text to C and the SIP session will be to M and in many ways it will > > > look > > > like it came from M. However, we need a way for the message to > > > indicate a > > > hint that M believes it was originally from A (or B as the case may > > > be). > > > > > > Do folks remember if we resolved this? Saying all messages have to be > > > CPIM > > > seems like overkill to me for simple text conferencing. > > > > > > You could have this same case in a simpler form where B is has a > > > direction > > > session with A and C and B is doing the "mixing" of the text. > > > > > > Thoughts, > > > > > > Cullen > > > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jan 13 13:54:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03598; Thu, 13 Jan 2005 13:54:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpALY-00035D-Pp; Thu, 13 Jan 2005 14:09:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp9xd-0004Mh-3r; Thu, 13 Jan 2005 13:44:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp9rn-0002VO-GJ for simple@megatron.ietf.org; Thu, 13 Jan 2005 13:38:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02481 for ; Thu, 13 Jan 2005 13:38:39 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpA62-0002hn-Md for simple@ietf.org; Thu, 13 Jan 2005 13:53:29 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jan 2005 10:38:08 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Thu, 13 Jan 2005 10:38:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] PIDF "entity" attribute usage Date: Thu, 13 Jan 2005 10:38:07 -0800 Message-ID: <1BEC4DA05ABCD34FACFCFC82086AC24704A0D3E1@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: [Simple] PIDF "entity" attribute usage Thread-Index: AcT35K+1K7hZkG2uQd6vIwY5WmkVoABudvRg From: "Tim Rang" To: "Paul Kyzivat" X-OriginalArrivalTime: 13 Jan 2005 18:38:08.0778 (UTC) FILETIME=[071E9EA0:01C4F99F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Paul, You had me until here- So, at least in principle, when using SIMPLE, you can use either sip or pres URIs. However this assumes the specific implementation you are=20 using actually supports this. In practice you should determine what the=20 implementation you are using supports. [Tim Rang] Can a SIMPLE implementation expect that all other SIMPLE implementations support receiving the sip scheme in the entity attribute? Thanks, Tim _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jan 13 17:12:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28380; Thu, 13 Jan 2005 17:12:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpDRL-00021j-9O; Thu, 13 Jan 2005 17:27:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpD7T-000689-3N; Thu, 13 Jan 2005 17:07:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpCeX-0005HQ-6U for simple@megatron.ietf.org; Thu, 13 Jan 2005 16:37:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23499 for ; Thu, 13 Jan 2005 16:37:10 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpCso-0000QL-V6 for simple@ietf.org; Thu, 13 Jan 2005 16:52:00 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 13 Jan 2005 16:49:48 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0DLabm4003069; Thu, 13 Jan 2005 16:36:38 -0500 (EST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOH96088; Thu, 13 Jan 2005 16:36:37 -0500 (EST) Message-ID: <41E6E9E5.2000305@cisco.com> Date: Thu, 13 Jan 2005 16:36:37 -0500 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: Tim Rang Subject: Re: [Simple] PIDF "entity" attribute usage References: <1BEC4DA05ABCD34FACFCFC82086AC24704A0D3E1@RED-MSG-43.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Tim Rang wrote: > Paul, > > You had me until here- > > > So, at least in principle, when using SIMPLE, you can use either sip or > > pres URIs. However this assumes the specific implementation you are > using actually supports this. In practice you should determine what the > implementation you are using supports. > > > [Tim Rang] Can a SIMPLE implementation expect that all other SIMPLE > implementations support receiving the sip scheme in the entity > attribute? Probably not. I *think* a SIMPLE implementation must at least support receiving an entity attribute containing the URI used to subscribe for that presence. (And I suspect many will require that - don't recall if the specs require it.) So the bigger question is whether a SIMPLE implementation is able to *issue* a presence subscription to a { sip / pres } URI, and whether it is able to *accept* a presence subscription to a { sip / pres } URI. The issue of accepting doesn't seem like a big deal. The presence implementation is responsible for defining what URIs its presentities have, so a user should know what uri is supported to access that presentity. The ability to issue subscription requests to one kind or the other of uri is probably the big issue. If I tell you my presence URI is pres:paul@example.com but your presence client doesn't support pres URIs, then you are just out of luck. I personally don't see any particular value in pres URIs. If I want a SIMPLE presence client, it is probably in support of a SIP UA that will be doing voice or IM. Both of those require the use of sip URIs. If I have all the support for sip, then why not use it for presence too? The pres URI is just a 5th wheel. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jan 13 17:59:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02258; Thu, 13 Jan 2005 17:59:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpEAc-00038k-Fr; Thu, 13 Jan 2005 18:14:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpDkP-0006xD-HD; Thu, 13 Jan 2005 17:47:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpDe8-0004N6-EJ for simple@megatron.ietf.org; Thu, 13 Jan 2005 17:40:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00685 for ; Thu, 13 Jan 2005 17:40:49 -0500 (EST) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpDsQ-0002hP-HB for simple@ietf.org; Thu, 13 Jan 2005 17:55:39 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j0DMeGeD007987; Thu, 13 Jan 2005 14:40:17 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j0DMeCHm001815; Thu, 13 Jan 2005 14:40:13 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <41E6E9E5.2000305@cisco.com> References: <1BEC4DA05ABCD34FACFCFC82086AC24704A0D3E1@RED-MSG-43.redmond.corp.microsof t.com> <41E6E9E5.2000305@cisco.com> Date: Thu, 13 Jan 2005 14:40:10 -0800 To: Paul Kyzivat , Tim Rang From: Ted Hardie Subject: Re: [Simple] PIDF "entity" attribute usage Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-PMX-Version: 4.7.0.111621 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 At 4:36 PM -0500 1/13/05, Paul Kyzivat wrote: >TThe ability to issue subscription requests to one kind or the other >of uri is probably the big issue. If I tell you my presence URI is >pres:paul@example.com but your presence client doesn't support pres >URIs, then you are just out of luck. > >I personally don't see any particular value in pres URIs. If I want >a SIMPLE presence client, it is probably in support of a SIP UA that >will be doing voice or IM. Both of those require the use of sip >URIs. If I have all the support for sip, then why not use it for >presence too? The pres URI is just a 5th wheel. > RFC 3859 would argue that it is a useful mechanism for creating a presence service abstracted from the specific presence/IM services (still largely proprietary) in the wider world. In a world where gateways are still a common feature, I don't personally see it as a 5th wheel. regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jan 13 18:45:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06419; Thu, 13 Jan 2005 18:45:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpEtR-00048g-VN; Thu, 13 Jan 2005 19:00:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpEJy-0004f5-K3; Thu, 13 Jan 2005 18:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpEF6-0007XO-64 for simple@megatron.ietf.org; Thu, 13 Jan 2005 18:19:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04458 for ; Thu, 13 Jan 2005 18:19:00 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpETO-0003Xb-Jt for simple@ietf.org; Thu, 13 Jan 2005 18:33:52 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 13 Jan 2005 15:18:41 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0DNIR1M017782; Thu, 13 Jan 2005 15:18:28 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOI04180; Thu, 13 Jan 2005 18:18:26 -0500 (EST) Message-ID: <41E701C2.8080807@cisco.com> Date: Thu, 13 Jan 2005 18:18:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Simple] PIDF "entity" attribute usage References: <1BEC4DA05ABCD34FACFCFC82086AC24704A0D3E1@RED-MSG-43.redmond.corp.microsof t.com> <41E6E9E5.2000305@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Tim Rang , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Ted Hardie wrote: > At 4:36 PM -0500 1/13/05, Paul Kyzivat wrote: > >> TThe ability to issue subscription requests to one kind or the other >> of uri is probably the big issue. If I tell you my presence URI is >> pres:paul@example.com but your presence client doesn't support pres >> URIs, then you are just out of luck. >> >> I personally don't see any particular value in pres URIs. If I want a >> SIMPLE presence client, it is probably in support of a SIP UA that >> will be doing voice or IM. Both of those require the use of sip URIs. >> If I have all the support for sip, then why not use it for presence >> too? The pres URI is just a 5th wheel. >> > > RFC 3859 would argue that it is a useful mechanism for creating a presence > service abstracted from the specific presence/IM services (still > largely proprietary) in the wider world. In a world where gateways > are still a common feature, I don't personally see it as a 5th wheel. I agree if and when the necessary gateways are built. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 14 16:21:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22381; Fri, 14 Jan 2005 16:21:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpZ7G-0006Iq-Ls; Fri, 14 Jan 2005 16:36:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpYGO-0002V9-Hw; Fri, 14 Jan 2005 15:41:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpY8W-0004aj-7w; Fri, 14 Jan 2005 15:33:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14412; Fri, 14 Jan 2005 15:33:34 -0500 (EST) Message-Id: <200501142033.PAA14412@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 14 Jan 2005 15:33:34 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-filter-format-04.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 --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 : An Extensible Markup Language (XML) Based Format for Event Notification Filtering Author(s) : H. Khartabil, et al. Filename : draft-ietf-simple-filter-format-04.txt Pages : 24 Date : 2005-1-14 The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying the rules for when that information should be delivered. In order to enable this, a format is needed to enable the subscriber to choose when notifications are to be sent to it and what they are to contain. This document presents a solution in the form of an XML document format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-filter-format-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-filter-format-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-14153335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-filter-format-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-filter-format-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-14153335.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Fri Jan 14 16:24:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22985; Fri, 14 Jan 2005 16:24:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpZAK-0006Tq-Mg; Fri, 14 Jan 2005 16:39:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpYGR-0002bX-T2; Fri, 14 Jan 2005 15:41:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpY8a-0004jc-Qw; Fri, 14 Jan 2005 15:33:40 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14419; Fri, 14 Jan 2005 15:33:39 -0500 (EST) Message-Id: <200501142033.PAA14419@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 14 Jan 2005 15:33:39 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-event-filter-funct-04.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 --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 : Functional Description of Event Notification Filtering Author(s) : H. Khartabil, et al. Filename : draft-ietf-simple-event-filter-funct-04.txt Pages : 31 Date : 2005-1-14 The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. This document describes the operations a subscriber performs in order to define filtering rules, how to handle responses to subscriptions carrying filtering rules, and how to handle notifications with filtering rules applied to them. The document also describes how the notifier behaves when receiving such filtering rules and how a notification is constructed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-event-filter-funct-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-event-filter-funct-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-event-filter-funct-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-14153341.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-event-filter-funct-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-event-filter-funct-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-14153341.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Fri Jan 14 17:06:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29833; Fri, 14 Jan 2005 17:06:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpZol-0008Tu-Ak; Fri, 14 Jan 2005 17:21:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpZTN-00006I-FP; Fri, 14 Jan 2005 16:59:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpZDr-0000ve-K7 for simple@megatron.ietf.org; Fri, 14 Jan 2005 16:43:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25857 for ; Fri, 14 Jan 2005 16:43:09 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpZSN-0007OK-6S for simple@ietf.org; Fri, 14 Jan 2005 16:58:11 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0ELh6s13868; Fri, 14 Jan 2005 23:43:07 +0200 (EET) X-Scanned: Fri, 14 Jan 2005 23:42:59 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j0ELgxOQ031551; Fri, 14 Jan 2005 23:42:59 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 0065CKKw; Fri, 14 Jan 2005 23:42:57 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0ELgvx15994; Fri, 14 Jan 2005 23:42:57 +0200 (EET) Received: from [192.168.1.186] ([10.162.253.122]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 14 Jan 2005 23:40:15 +0200 Message-ID: <41E83C3E.8060508@nokia.com> Date: Fri, 14 Jan 2005 23:40:14 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Paul Kyzivat Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41C2997D.9010800@nokia.com> <41DF7495.70204@cisco.com> <41E3D1E3.90702@nokia.com> <41E3F0EE.7020805@cisco.com> In-Reply-To: <41E3F0EE.7020805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2005 21:40:15.0256 (UTC) FILETIME=[A2389980:01C4FA81] X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit Inline. ext Paul Kyzivat wrote: >>> It could do that but it need not; the benefit of a URI and its >>> definitional characteristic is that you need no other context beyond >>> the URI to use it. I should be able to make a SIP call to that URI >>> without having seen the presence document at all, and it works to the >>> degree that SIP itself would allow the call to proceed. Presence >>> might help optimize by allowing me to select media streams that work >>> out of the box, for example, but its an optimization not a requirment >>> for contacting the URI. If it is, the URI becomes meaningless. > > Here I agree with Jonathan. Elsewhere I pointed out the 3PCC offerless > invite case. But there are other cases as well. Consider the case where > you have two tuples containing the same AoR. One is just voice. The > other is voice+video. Because I have a video phone, and anticipate using > the video, I choose to call your tuple that has video. But I start out > with my video disabled because I'm polite and want to ask before using > it. So my initial invite only contains audio. (If/when I turn on video a > reinvite will add the video stream.) > > But your proxy, thinking itself clever, looks at my offer and decides to > send it to your audio phone. Now when I try to add video (which I think > I should expect because your tuple advertised it), the attempt fails > because you have no video. Yuck! > >> I agree, but you sound like you would be in favor of AoR contact over >> a GRUU contact here. After all, a GRUU really needs a context to be >> all that useful. > > > What is your point? Is this "context" needed in the caller or callee? Both. > If you mean the callee, then yes, it is possible for gruu to be used in > a way where the grid parameter indexes context stored in the callee, > with the gruu useless once that context has been forgotten. But that > isn't always the case. In some cases all that is necessary is that the > gruu route to the right UA, with no added context necessary at the > receiving end. (The grid parameter may be irrelevant.) In other cases > the context needed at the receiving end may be encoded into the grid > parameter. > > If you mean the caller needs context, then isn't that the caller's > problem? In the situation at hand the caller *has* context: the > presentity and all the contents of the selected tuple. > >> Without one, e.g., going through my call-logs from last month, there >> is no guarantee that a GRUU used then would work any more, or indeed >> work for any other session than the one made back then. > > > I recall you brought up this point in private discussion, and I have > been thinking about it. It is an interesting problem, but one that is in > no way restricted to presence based calling. It is relevant to many uses > of GRUU. > > In all cases I think the caller has context other than the gruu. We may > need to find a way to incorporate that into the call so that it may be > incorporated in call logs. > > Another possibility is that we might consider defining an encoding of > gruus that explicitly exposes the related AoR. This would have to be > optional, for cases when that info is not intended to be public, but in > many cases it is not secret information. Yes, this is something I've also thought about. It might be a good idea to have the presentity include as contact a URI that adds some "magic" token into the request. Now while the end result is similar to a GRUU, the mechanism would be different. >> AoR has that property in a sense that it can be expected to work >> independent of time, place and type of session. > > > Remember that the original motivation for gruu was to ensure that > transfers get to the right UA. That is still an important property. The > use of AoR didn't work for that. The problem with call logs is going to > exist in that scenario too. > > Also, I don't understand how you are going to solve the whole range of > problems that gruus address without using gruus. Are you simply counting > on there only being a single UAS per AoR in your environment? Perhaps I'm not making myself clear. I'm not against putting GRUUs in presence documents ever (or using them elsewhere). I'm against making this a *mandatory* thing, and basing composer behavior on assuming gruuness across the presence documents. There is a big difference. >> Also, there are always (at least) two participants in a call and both >> have their preference over which media to use. Surely the watcher also >> has a say in what sort of media to commit to. This may not be that >> evident in todays UAs that predominantly offer voice-only. > > > How is this relevant? The watcher will be looking at the tuples to find > ones that are consistent in capabilities (including media) that it can > deal with. Yes, and (usually) constructs a request that is aligned with those capabilities. It won't be a simple "clicking the link", as is somehow been suggested. We also have things like caller preferences to make these choices affect the routing of a call. >>>> I believe the invoking of a service MUST work using an AoR. If an >>>> INVITE offering voice ends up served by a chess application, I think >>>> the system is utterly broken, and needs to be fixed. >>> >>> >>> This is contradictory. You are saying that two services that are >>> different have to be able to have the same AoR, but if you have the >>> same AOR, how can you guarantee that an INVITE to that AOR is >>> properly dispatched to the right app depending on where it came from? >> >> >> Aren't you forgetting something here, namely an SDP offer that >> (usually [1]) goes along with the INVITE? To me this sounds like we >> have systems where dispatching can only work based on Request URI. But >> surely you can dispatch using a plethora of other handles, such as >> Require-tokens, SDP parameters and Subject-headers, to name a few. > > > I believe there are problems to be worked out before e2e encryption can > work in the presence of forking. But in theory the contents of the SDP > body might not be available to the proxy. Building a system that depends > on routing that way will rule out support for e2e security. Proxy /= dispatcher, I've never said that. A dispatcher is an element that handles "routing" way after the messages have been decrypted. >> I don't like the idea of making the SDP be a static description of all >> media available to the wathcer, and base service dispatch (whether >> done locally at the client or by a proxy) on information "encoded" in >> the GRUU. This seems to be the direction were heading here. > > > I'm not sure of your point here. When making an offer, the offerer > should offer whatever media it desires to use at that time. This need > not include every medium that could be used later in the call, or on > some other call. Then we agree. > For instance, Alice might have a voice+IM client. With it she can make > many calls containing IM, but I can only have active voice in a single > call. She is in a voice call with Bob, but also needs to talk to > Charlie. So, while still talking to Bob, she looks up Charlie in her > buddylist, finds a tuple for voice+IM, and makes an IM-only call to it. > In her IM session with Charlie she starts to fill him in. When her call > to Bob is over, she adds voice in to the call with Charlie. I just don't see these types of scenarios 100% representative of how presence will be used. There are other issues as well -- Alice might not see that Charlie has both IM+voice, but when in a session, this combination is actually present. The reason we should be certain of 100% representation is that mandating the GRUU approach rules out other otherwise valid approaches. Cheers, Aki > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jan 15 09:14:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12500; Sat, 15 Jan 2005 09:14:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cpow6-0001Hj-PQ; Sat, 15 Jan 2005 09:29:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cpofh-00054T-DD; Sat, 15 Jan 2005 09:12:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cpocu-0004Vl-GF for simple@megatron.ietf.org; Sat, 15 Jan 2005 09:10:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12326 for ; Sat, 15 Jan 2005 09:10:02 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CporY-0001Dm-4t for simple@ietf.org; Sat, 15 Jan 2005 09:25:13 -0500 Received: from [10.240.21.36] (m015f36d0.tmodns.net [208.54.95.1]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j0FE9xC9092170 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sat, 15 Jan 2005 08:10:00 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <221ABF6B-66FF-11D9-AA3E-000D93326732@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Simple WG From: Robert Sparks Date: Sat, 15 Jan 2005 08:09:55 -0600 X-Mailer: Apple Mail (2.619) X-Spam-Score: 2.9 (++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Simple] presence-rules: providing all attributes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit I had an offline conversation with Jonathan about the minimum statement a presentity needs to make to say "give the matching subscriber everything in my presence document". Currently, that requires a pretty beefy transformation section for something that's likely to be a common policy to assert. We discussed adding a shorthand like inside each of person, service, device, or even a at the transformations level. Thoughts? RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jan 15 09:20:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12830; Sat, 15 Jan 2005 09:20:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cpp1M-0001Nj-TG; Sat, 15 Jan 2005 09:35:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpolQ-0006SJ-6l; Sat, 15 Jan 2005 09:18:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpokY-0006GU-6u for simple@megatron.ietf.org; Sat, 15 Jan 2005 09:17:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12745 for ; Sat, 15 Jan 2005 09:17:56 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpozC-0001M4-TA for simple@ietf.org; Sat, 15 Jan 2005 09:33:07 -0500 Received: from [10.240.21.36] (m015f36d0.tmodns.net [208.54.95.1]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j0FEHthf092684 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sat, 15 Jan 2005 08:17:56 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <3DBDB601-6700-11D9-AA3E-000D93326732@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Simple WG From: Robert Sparks Date: Sat, 15 Jan 2005 08:17:51 -0600 X-Mailer: Apple Mail (2.619) X-Spam-Score: 2.9 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Simple] presence-rules: Selecting on class X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit There is a piece of functionality missing from presence-rules that (I think) we were expecting to have. A presentity needs to be able to expose tuples based on the class the presentity assigned to it (this was a primary motivator of the class element if I understand it correctly, allowing me to group elements to expose to my family vs those I expose to my co-workers). Currently, there's no way to make that kind of transformation with a presence-rule. Jonathan and I discussed this briefly - the idea that came out was to add one or more elements to that would only provide those services matching one of the stated classes. Thoughts? I suspect we need this for and too? RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 17 03:16:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14806; Mon, 17 Jan 2005 03:16:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqSIi-000644-79; Mon, 17 Jan 2005 03:31:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqRzW-0003b9-R5; Mon, 17 Jan 2005 03:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqRy1-0003TJ-Lj for simple@megatron.ietf.org; Mon, 17 Jan 2005 03:10:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14529 for ; Mon, 17 Jan 2005 03:10:26 -0500 (EST) Received: from bigipbgp.itri.org.tw ([61.61.254.20] helo=maillog.itri.org.tw) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqSD0-0005wV-QX for simple@ietf.org; Mon, 17 Jan 2005 03:25:59 -0500 Received: from mail.itri.org.tw (mail [140.96.157.2]) by maillog.itri.org.tw (8.11.6+Sun/8.11.6) with ESMTP id j0H8B6v28054 for ; Mon, 17 Jan 2005 16:11:06 +0800 (CST) Received: from ms2.itri.org.tw (ms2.itri.org.tw [140.96.147.44]) by mail.itri.org.tw (8.11.6+Sun/8.11.6) with ESMTP id j0H82cr02261 for ; Mon, 17 Jan 2005 16:02:38 +0800 (CST) Received: from 01092035392 ([140.96.254.153]) by ms2.itri.org.tw (Lotus Domino Release 5.0.11) with ESMTP id 2005011716094962:14508 ; Mon, 17 Jan 2005 16:09:49 +0800 From: "Jeffrey" To: Subject: [Simple] About change in authorization policy Date: Mon, 17 Jan 2005 16:13:50 +0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Thread-Index: AcT8bHlpCul9c+cZSG+pvpYkYd5fIg== X-MIMETrack: Itemize by SMTP Server on MS2/ITRI(Release 5.0.11 |July 24, 2002) at 2005-01-17 04:09:49 PM, Serialize by Router on MS2/ITRI(Release 5.0.11 |July 24, 2002) at 2005-01-17 04:09:50 PM, Serialize complete at 2005-01-17 04:09:50 PM X-Spam-Score: 0.5 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1527716962==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 This is a multi-part message in MIME format. --===============1527716962== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01C4FCAF.8C2FB670" This is a multi-part message in MIME format. ------=_NextPart_000_003C_01C4FCAF.8C2FB670 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit Hi all, I would like to ask a problem about change in authorization policy. According to RFC 3265, when a presentity grants and then blocks some watcher, the Notifier must reply to the Subscribe request with the "Subscription-State" value being "terminated". This subscription will be also terminated in Notifier. If the presentity unblocks that watcher later (i.e. change authorization policy for that watcher), how can that watcher receive the presence information because the original subscription has been terminated? Is "XCAP Event Package" the best way of solution? (that is when such change in authorization policy, Notifier inform that watcher to issue a new Subscribe request.) Are there any other solutions? Thanks a lot. Best Regards, Jeffrey Ho ------=_NextPart_000_003C_01C4FCAF.8C2FB670 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable [Simple] About change in authorization policy

Hi all,

I would like to ask a = problem about change in authorization policy. According to RFC 3265, = when a presentity grants and then blocks some watcher, the Notifier must = reply to the Subscribe request with the "Subscription-State" = value being "terminated". This subscription will be also = terminated in Notifier. If the presentity unblocks that watcher later = (i.e. change authorization policy for that watcher), how can that = watcher receive the presence information because the original = subscription has been terminated? Is "XCAP Event Package" the = best way of solution? (that is when such change in authorization policy, = Notifier inform that watcher to issue a new Subscribe request.) Are = there any other solutions?

Thanks a lot.

Best Regards,
Jeffrey Ho

------=_NextPart_000_003C_01C4FCAF.8C2FB670-- --===============1527716962== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1527716962==-- From simple-bounces@ietf.org Mon Jan 17 17:22:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29891; Mon, 17 Jan 2005 17:22:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqfWB-0003xi-GG; Mon, 17 Jan 2005 17:38:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqf4Z-000155-VH; Mon, 17 Jan 2005 17:10:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqeT6-00059c-TP for simple@megatron.ietf.org; Mon, 17 Jan 2005 16:31:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17374 for ; Mon, 17 Jan 2005 16:31:22 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqeiE-00081z-Tw for simple@ietf.org; Mon, 17 Jan 2005 16:47:03 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HLVB418340; Mon, 17 Jan 2005 23:31:12 +0200 (EET) X-Scanned: Mon, 17 Jan 2005 23:39:12 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j0HLdC80005147; Mon, 17 Jan 2005 23:39:12 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00QWjDN4; Mon, 17 Jan 2005 23:38:45 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HLTcx14429; Mon, 17 Jan 2005 23:29:38 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 Jan 2005 23:29:32 +0200 Received: from esebe052.NOE.Nokia.com ([172.21.138.217]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 Jan 2005 23:29:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] presence-rules: providing all attributes Date: Mon, 17 Jan 2005 23:29:32 +0200 Message-ID: Thread-Topic: [Simple] presence-rules: providing all attributes Thread-Index: AcT7DPVD0RE7amUuRq+5mxPefK4OCABzfIvA To: , X-OriginalArrivalTime: 17 Jan 2005 21:29:33.0709 (UTC) FILETIME=[A3118BD0:01C4FCDB] X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Hi, Yes, I agree that there should be a shortcut for saying "give = everything". I think both and = would be useful. I suppose all attributes would mean also all "unknown" = attributes. Markus > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Robert Sparks > Sent: 15 January, 2005 16:10 > To: Simple WG > Subject: [Simple] presence-rules: providing all attributes >=20 >=20 > I had an offline conversation with Jonathan about the minimum > statement a presentity needs to make to say "give the matching > subscriber everything in my presence document". Currently, > that requires a pretty beefy transformation section for something > that's likely to be a common policy to assert. >=20 > We discussed adding a shorthand like > inside each of person, service, device, or even a > at the transformations level. >=20 > Thoughts? >=20 > RjS >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 17 17:25:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00255; Mon, 17 Jan 2005 17:25:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqfYA-00044J-1D; Mon, 17 Jan 2005 17:40:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqfEl-00064q-Rh; Mon, 17 Jan 2005 17:20:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqepl-0001RA-PO for simple@megatron.ietf.org; Mon, 17 Jan 2005 16:54:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23795 for ; Mon, 17 Jan 2005 16:54:47 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqf4s-0001pT-Mg for simple@ietf.org; Mon, 17 Jan 2005 17:10:27 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HLsil16219; Mon, 17 Jan 2005 23:54:44 +0200 (EET) X-Scanned: Mon, 17 Jan 2005 23:54:38 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j0HLsc4E009036; Mon, 17 Jan 2005 23:54:38 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00TWbP3V; Mon, 17 Jan 2005 23:54:37 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HLsbx12851; Mon, 17 Jan 2005 23:54:37 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 Jan 2005 23:54:34 +0200 Received: from esebe052.NOE.Nokia.com ([172.21.138.217]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 Jan 2005 23:54:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] modeling dispatchers in the data model: a proposal formoving forward Date: Mon, 17 Jan 2005 23:54:34 +0200 Message-ID: Thread-Topic: [Simple] modeling dispatchers in the data model: a proposal formoving forward Thread-Index: AcT3akRS1r2IXftbR1usSXFp5YJaUAFcu7xg To: , X-OriginalArrivalTime: 17 Jan 2005 21:54:33.0810 (UTC) FILETIME=[2132CB20:01C4FCDF] X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: aki.niemi@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Hi, Paul Kyzivat wrote: >=20 > Jonathan Rosenberg wrote: > > inline. I'd ask folks to please read to the end where I=20 > have another=20 > > compromise proposal on unique URI that may be more=20 > palatable than my=20 > > previous one. >=20 > I *think* I'm ok with this, as long as it is specified that =20 > and are mutually exclusive. >=20 A basic question: In case we have a GRUU in the contact, is there some = use for also telling what the AoR is within the tuple? If yes, = in addition to would be useful, otherwise Paul's = suggestion for keeping these mutually exclusive works. I don't know, but = I remember some discussion on problems with GRUUs in call logs.=20 In either case, I think should be accompanied with an = instance id, so that the combination of the and the id = would be unique in the same way as the is supposed to be in = the current data model. That would help doing authorizations. Now we = have and in presence-rules to match tuples. I propose = changing these to and and adding = and (or along those lines). = Also, the id would help in deciding override vs. union between tuples, = and further along the path if we do configurable composition policies. I = don't there's ever been a question whether a tuple should have these = kind of unique keys, the argument has just been about whether contact = can be such. I hope we can conclude that we do both ways. Markus=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 17 17:32:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00910; Mon, 17 Jan 2005 17:32:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqffS-0004HB-2j; Mon, 17 Jan 2005 17:48:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqfN1-0002GC-RL; Mon, 17 Jan 2005 17:29:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqfFC-0006r1-Qc for simple@megatron.ietf.org; Mon, 17 Jan 2005 17:21:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29357 for ; Mon, 17 Jan 2005 17:21:03 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqfUK-0003mn-Md for simple@ietf.org; Mon, 17 Jan 2005 17:36:45 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HMKjl00875; Tue, 18 Jan 2005 00:20:51 +0200 (EET) X-Scanned: Tue, 18 Jan 2005 00:20:35 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j0HMKZOs012719; Tue, 18 Jan 2005 00:20:35 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00HyKNmX; Tue, 18 Jan 2005 00:20:25 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HLf1x26027; Mon, 17 Jan 2005 23:41:01 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 Jan 2005 23:39:50 +0200 Received: from esebe052.NOE.Nokia.com ([172.21.138.217]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 Jan 2005 23:39:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] presence-rules: Selecting on class Date: Mon, 17 Jan 2005 23:39:49 +0200 Message-ID: Thread-Topic: [Simple] presence-rules: Selecting on class Thread-Index: AcT7DaLrTJJdTtYITv6GsrI66/9xWQBzo0tA To: , X-OriginalArrivalTime: 17 Jan 2005 21:39:50.0467 (UTC) FILETIME=[12AF5930:01C4FCDD] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Hi, > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Robert Sparks > Sent: 15 January, 2005 16:18 > To: Simple WG > Subject: [Simple] presence-rules: Selecting on class >=20 >=20 > There is a piece of functionality missing from presence-rules that > (I think) we were expecting to have. >=20 > A presentity needs to be able to expose tuples based on the class > the presentity assigned to it (this was a primary motivator=20 > of the class > element if I understand it correctly, allowing me to group elements to > expose to my family vs those I expose to my co-workers). Currently, > there's no way to make that kind of transformation with a=20 > presence-rule. >=20 Yes, I am expecting to be able to use class for that, although it might = have other usages too.=20 > Jonathan and I discussed this briefly - the idea that came out was to > add one or more elements to that would > only provide those services matching one of the stated classes. >=20 Yes, this is a good idea.=20 > Thoughts? >=20 > I suspect we need this for and too? >=20 Yes, I support this too. In this case RPID needs to say that class = applies to , and (if the latest version already = does not). A follow-up question obviously is that how is the rule-maker able to = know which class values a PUA is going to use. If they are co-located, = it's easy, but if the user has e.g. multiple devices, this gets more = difficult. But that is a separated problem from the presence-rules.=20 > RjS >=20 Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 17 18:51:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07134; Mon, 17 Jan 2005 18:51:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqgtU-0005qn-8p; Mon, 17 Jan 2005 19:06:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqgcO-0006Jp-Vk; Mon, 17 Jan 2005 18:49:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqgXr-0005uc-2a for simple@megatron.ietf.org; Mon, 17 Jan 2005 18:44:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06845 for ; Mon, 17 Jan 2005 18:44:23 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqgmz-0005jT-Dj for simple@ietf.org; Mon, 17 Jan 2005 19:00:06 -0500 Received: from razor.cs.columbia.edu (IDENT:OF5EMo9buVaTmyKELXBa6ZtpgrskL/Ih@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0HNiMir002666 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 17 Jan 2005 18:44:22 -0500 (EST) Received: from [127.0.0.1] (IDENT:Ro+H35Q+PmoPKDFvM4UTwMOkJzYUtzi1@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0HNiKiw009731; Mon, 17 Jan 2005 18:44:21 -0500 Message-ID: <41EC4DC0.8050608@cs.columbia.edu> Date: Mon, 17 Jan 2005 18:44:00 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: [Simple] presence-rules: Selecting on class References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.17.7 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit > > Yes, I support this too. In this case RPID needs to say that class > applies to , and (if the latest version > already does not). The current draft does. > > A follow-up question obviously is that how is the rule-maker able to > know which class values a PUA is going to use. If they are > co-located, it's easy, but if the user has e.g. multiple devices, > this gets more difficult. But that is a separated problem from the > presence-rules. The idea for was to have some notion of higher-level coordination, possibly at the service (not in the SIMPLE sense) or human level. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 17 18:53:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07251; Mon, 17 Jan 2005 18:53:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqgve-0005t8-9F; Mon, 17 Jan 2005 19:09:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqgd6-0006SL-RJ; Mon, 17 Jan 2005 18:49:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqgZc-000618-OQ for simple@megatron.ietf.org; Mon, 17 Jan 2005 18:46:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06898 for ; Mon, 17 Jan 2005 18:46:13 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqgom-0005lO-6N for simple@ietf.org; Mon, 17 Jan 2005 19:01:56 -0500 Received: from razor.cs.columbia.edu (IDENT:RmYDTcO3IMnMfba3RFDXdz+Pbi9ym0/e@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0HNkBir002999 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 17 Jan 2005 18:46:12 -0500 (EST) Received: from [127.0.0.1] (IDENT:iL3YkR1g82HwZdOtY6UYXoLS06+7Uznj@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0HNk9iw009745; Mon, 17 Jan 2005 18:46:10 -0500 Message-ID: <41EC4E2C.7070305@cs.columbia.edu> Date: Mon, 17 Jan 2005 18:45:48 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: [Simple] presence-rules: Selecting on class References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.17.7 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit >>A presentity needs to be able to expose tuples based on the class >>the presentity assigned to it (this was a primary motivator >>of the class >>element if I understand it correctly, allowing me to group elements to >>expose to my family vs those I expose to my co-workers). Currently, >>there's no way to make that kind of transformation with a >>presence-rule. Be sure not to confuse with . Class might be used for something like labeling "sensitive information" vs. "public information" or "primary information" vs. "secondary information". Generally, the same tuple would keep the same class, while my sphere changes throughout the day. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 17 19:11:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08023; Mon, 17 Jan 2005 19:11:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqhDA-0006Cb-V4; Mon, 17 Jan 2005 19:27:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqgvV-0001SA-Lq; Mon, 17 Jan 2005 19:08:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqguV-0001Bi-JT for simple@megatron.ietf.org; Mon, 17 Jan 2005 19:07:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07850 for ; Mon, 17 Jan 2005 19:07:48 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqh9d-00067v-SI for simple@ietf.org; Mon, 17 Jan 2005 19:23:31 -0500 Received: from [10.0.1.38] (customer-208-212.pdchawaii.com [66.192.208.212] (may be forged)) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j0I07ewF037808 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 17 Jan 2005 18:07:43 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <41EC4E2C.7070305@cs.columbia.edu> References: <41EC4E2C.7070305@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Simple] presence-rules: Selecting on class Date: Mon, 17 Jan 2005 18:07:24 -0600 To: Henning Schulzrinne X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit I had no confusion. is definitely a different beast, and -rules- deals with the presentity's current just fine. I may have raised a flag for you when I used family and co-workers as examples. I can have a set of tuples that I provide to my family only if I happen to be at work. The rule will match I'm at work based on sphere, that set of tuples will be added by transformations based on class. RjS On Jan 17, 2005, at 5:45 PM, Henning Schulzrinne wrote: >>> A presentity needs to be able to expose tuples based on the class >>> the presentity assigned to it (this was a primary motivator of the >>> class >>> element if I understand it correctly, allowing me to group elements >>> to >>> expose to my family vs those I expose to my co-workers). Currently, >>> there's no way to make that kind of transformation with a >>> presence-rule. > > Be sure not to confuse with . Class might be used for > something like labeling "sensitive information" vs. "public > information" or "primary information" vs. "secondary information". > > Generally, the same tuple would keep the same class, while my sphere > changes throughout the day. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 17 19:16:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08385; Mon, 17 Jan 2005 19:16:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqhHi-0006J8-Vg; Mon, 17 Jan 2005 19:31:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqh1Q-0002Ph-Pa; Mon, 17 Jan 2005 19:15:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqh15-0002IU-Iy for simple@megatron.ietf.org; Mon, 17 Jan 2005 19:14:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08284 for ; Mon, 17 Jan 2005 19:14:36 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqhGD-0006Gf-Pk for simple@ietf.org; Mon, 17 Jan 2005 19:30:19 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 17 Jan 2005 16:18:22 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0I0E1jw013040; Mon, 17 Jan 2005 16:14:02 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOJ89310; Mon, 17 Jan 2005 19:13:59 -0500 (EST) Message-ID: <41EC54C7.1010101@cisco.com> Date: Mon, 17 Jan 2005 19:13:59 -0500 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: Jeffrey Subject: Re: [Simple] About change in authorization policy References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Jeffrey wrote: > Hi all, > > I would like to ask a problem about change in authorization policy. > According to RFC 3265, when a presentity grants and then blocks some > watcher, the Notifier must reply to the Subscribe request with the > "Subscription-State" value being "terminated". This subscription will be > also terminated in Notifier. If the presentity unblocks that watcher > later (i.e. change authorization policy for that watcher), how can that > watcher receive the presence information because the original > subscription has been terminated? Is "XCAP Event Package" the best way > of solution? (that is when such change in authorization policy, Notifier > inform that watcher to issue a new Subscribe request.) Are there any > other solutions? I believe the subscription model allows three authorization states for a watcher: allowed, forbidden, pending. It is only when the authorization transitions to forbidden that it is necessary to terminate the subscription. If I put you in that category, it means I overtly made a decision that I don't want you bothering me. In that situation, don't hold your breath while waiting for me to change my mind. Maybe if you talk to me and convince me that you are no longer such a pest, maybe I will change my mind. Then you can try again, but you will have to poll until I actually make the change. From my POV this is a feature. In principle, I suppose I could move you from allowed to pending when I get annoyed with you. In that case you could continue to subscribe, but not get any useful information until I change my mind. But that doesn't seem like a use case you should count on. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 18 07:24:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17076; Tue, 18 Jan 2005 07:24:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqseL-0006I4-Um; Tue, 18 Jan 2005 07:39:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqsO7-0005wt-NA; Tue, 18 Jan 2005 07:23:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqsML-0005c6-8r for simple@megatron.ietf.org; Tue, 18 Jan 2005 07:21:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16954 for ; Tue, 18 Jan 2005 07:21:18 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqsbb-0006F1-3g for simple@ietf.org; Tue, 18 Jan 2005 07:37:07 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0ICL3O25840; Tue, 18 Jan 2005 14:21:03 +0200 (EET) X-Scanned: Tue, 18 Jan 2005 14:20:48 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j0ICKmxY016965; Tue, 18 Jan 2005 14:20:48 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00gls63S; Tue, 18 Jan 2005 14:20:46 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0IBSjU03060; Tue, 18 Jan 2005 13:28:45 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 18 Jan 2005 13:28:29 +0200 Received: from esebe052.NOE.Nokia.com ([172.21.138.217]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 18 Jan 2005 13:28:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] About change in authorization policy Date: Tue, 18 Jan 2005 13:28:25 +0200 Message-ID: Thread-Topic: [Simple] About change in authorization policy Thread-Index: AcT88yTluqUj803vRvGo9KWfIsLC/gAW/M7w To: , X-OriginalArrivalTime: 18 Jan 2005 11:28:28.0657 (UTC) FILETIME=[D5091610:01C4FD50] X-Spam-Score: 0.3 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Paul, I think there is at least one realistic case where what Jeffrey brought = up causes some trouble.=20 If value is used to influence the authorization decisions, i.e. = different authorization rules apply when sphere=3D=3D"home" than = sphere=3D=3D"work", the allowed vs. forbidden state for a particular = subscriber could very well change at least twice a day. If that = subscriber wants to be constantly subscribed to presence whenever it is = allowed, she would have to do some polling. For instance if someone = forbids her boss to subscribe while she is not working, the boss would = not know when to subscribe again after the previous subscription was = terminated. This makes me think that the recommended way to use should be = not to make it affect the subscription state, but just the content, = perhaps using polite blocking. If we don't come up with any other fix to this, I think at least this = issue should be written in a relevant section of the presence-rules RFC. = Possible fixes? Well, some sort of new event package might work, but in = any case it would be quite complex. Markus =20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Paul Kyzivat > Sent: 18 January, 2005 02:14 > To: Jeffrey > Cc: simple@ietf.org > Subject: Re: [Simple] About change in authorization policy >=20 >=20 >=20 >=20 > Jeffrey wrote: > > Hi all, > >=20 > > I would like to ask a problem about change in authorization policy.=20 > > According to RFC 3265, when a presentity grants and then=20 > blocks some=20 > > watcher, the Notifier must reply to the Subscribe request with the=20 > > "Subscription-State" value being "terminated". This=20 > subscription will be=20 > > also terminated in Notifier. If the presentity unblocks=20 > that watcher=20 > > later (i.e. change authorization policy for that watcher),=20 > how can that=20 > > watcher receive the presence information because the original=20 > > subscription has been terminated? Is "XCAP Event Package"=20 > the best way=20 > > of solution? (that is when such change in authorization=20 > policy, Notifier=20 > > inform that watcher to issue a new Subscribe request.) Are=20 > there any=20 > > other solutions? >=20 > I believe the subscription model allows three authorization=20 > states for a > watcher: allowed, forbidden, pending. >=20 > It is only when the authorization transitions to forbidden that it is > necessary to terminate the subscription. If I put you in that=20 > category, > it means I overtly made a decision that I don't want you bothering me. > In that situation, don't hold your breath while waiting for=20 > me to change > my mind. Maybe if you talk to me and convince me that you are=20 > no longer > such a pest, maybe I will change my mind. Then you can try again, but > you will have to poll until I actually make the change. From=20 > my POV this > is a feature. >=20 > In principle, I suppose I could move you from allowed to=20 > pending when I > get annoyed with you. In that case you could continue to=20 > subscribe, but > not get any useful information until I change my mind. But=20 > that doesn't > seem like a use case you should count on. >=20 > Paul >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 18 11:28:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08068; Tue, 18 Jan 2005 11:28:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqwSO-0004Uq-WA; Tue, 18 Jan 2005 11:43:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqw1c-00058h-GI; Tue, 18 Jan 2005 11:16:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqvxQ-00043V-Tn for simple@megatron.ietf.org; Tue, 18 Jan 2005 11:11:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06550 for ; Tue, 18 Jan 2005 11:11:50 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqwCj-0003tj-0I for simple@ietf.org; Tue, 18 Jan 2005 11:27:41 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2005 11:11:22 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0IGBIW0023914; Tue, 18 Jan 2005 11:11:18 -0500 (EST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOK24341; Tue, 18 Jan 2005 11:11:13 -0500 (EST) Message-ID: <41ED3521.2030106@cisco.com> Date: Tue, 18 Jan 2005 11:11:13 -0500 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: Markus.Isomaki@nokia.com Subject: Re: [Simple] About change in authorization policy References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: > Paul, > > I think there is at least one realistic case where what Jeffrey brought up causes some trouble. > > If value is used to influence the authorization decisions, i.e. different authorization rules apply when sphere=="home" than sphere=="work", the allowed vs. forbidden state for a particular subscriber could very well change at least twice a day. If that subscriber wants to be constantly subscribed to presence whenever it is allowed, she would have to do some polling. For instance if someone forbids her boss to subscribe while she is not working, the boss would not know when to subscribe again after the previous subscription was terminated. > > This makes me think that the recommended way to use should be not to make it affect the subscription state, but just the content, perhaps using polite blocking. Yes. This falls into the category of "if it hurts, don't do it". In this case, you may not want your boss bothering you while you are not working, but you probably don't want to piss off your boss. > If we don't come up with any other fix to this, I think at least this issue should be written in a relevant section of the presence-rules RFC. This sounds like a different document - a best practices for presence. Paul > Possible fixes? Well, some sort of new event package might work, but in any case it would be quite complex. > > Markus > > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Paul Kyzivat >>Sent: 18 January, 2005 02:14 >>To: Jeffrey >>Cc: simple@ietf.org >>Subject: Re: [Simple] About change in authorization policy >> >> >> >> >>Jeffrey wrote: >> >>>Hi all, >>> >>>I would like to ask a problem about change in authorization policy. >>>According to RFC 3265, when a presentity grants and then >> >>blocks some >> >>>watcher, the Notifier must reply to the Subscribe request with the >>>"Subscription-State" value being "terminated". This >> >>subscription will be >> >>>also terminated in Notifier. If the presentity unblocks >> >>that watcher >> >>>later (i.e. change authorization policy for that watcher), >> >>how can that >> >>>watcher receive the presence information because the original >>>subscription has been terminated? Is "XCAP Event Package" >> >>the best way >> >>>of solution? (that is when such change in authorization >> >>policy, Notifier >> >>>inform that watcher to issue a new Subscribe request.) Are >> >>there any >> >>>other solutions? >> >>I believe the subscription model allows three authorization >>states for a >>watcher: allowed, forbidden, pending. >> >>It is only when the authorization transitions to forbidden that it is >>necessary to terminate the subscription. If I put you in that >>category, >>it means I overtly made a decision that I don't want you bothering me. >>In that situation, don't hold your breath while waiting for >>me to change >>my mind. Maybe if you talk to me and convince me that you are >>no longer >>such a pest, maybe I will change my mind. Then you can try again, but >>you will have to poll until I actually make the change. From >>my POV this >>is a feature. >> >>In principle, I suppose I could move you from allowed to >>pending when I >>get annoyed with you. In that case you could continue to >>subscribe, but >>not get any useful information until I change my mind. But >>that doesn't >>seem like a use case you should count on. >> >> Paul >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 18 17:04:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11786; Tue, 18 Jan 2005 17:04:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr1iX-0006qG-Ks; Tue, 18 Jan 2005 17:20:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr1PY-0002SD-AH; Tue, 18 Jan 2005 17:01:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr1Iy-0001TX-HY for simple@megatron.ietf.org; Tue, 18 Jan 2005 16:54:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11194 for ; Tue, 18 Jan 2005 16:54:25 -0500 (EST) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr1YJ-0006ar-8L for simple@ietf.org; Tue, 18 Jan 2005 17:10:20 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j0ILrtdt073542 for ; Tue, 18 Jan 2005 21:53:55 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0ILsqeY170194 for ; Tue, 18 Jan 2005 22:54:52 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0ILrt7G021935 for ; Tue, 18 Jan 2005 22:53:55 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0ILrtin021928 for ; Tue, 18 Jan 2005 22:53:55 +0100 To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M2_07222004 Beta 2NP July 22, 2004 Message-ID: From: Avshalom Houri Date: Tue, 18 Jan 2005 23:54:11 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 18/01/2005 23:54:13, Serialize complete at 18/01/2005 23:54:13 X-Spam-Score: 0.5 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: [Simple] Byte Range in MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1288741145==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 This is a multipart message in MIME format. --===============1288741145== Content-Type: multipart/alternative; boundary="=_alternative 007849EC42256F8D_=" This is a multipart message in MIME format. --=_alternative 007849EC42256F8D_= Content-Type: text/plain; charset="US-ASCII" In the MSRP 09 draft following examples appear: MSRP a786hjs2 SEND To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp Message-ID: 87652 Content-Type: text/plain Hey Bob, are you there? -------a786hjs2$ MSRP a786hjs2 200 OK To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp Message-ID: 87652 -------a786hjs2$ Note that this format of messages enforces the reader of the messages to scan the messages in order to find the end of the message. It does not enable an implementation that decides to include byte count in the message to do so. Was not there a suggestion to include a Byte-Range (with an option to put a '*' instead of a range) in every message even messages that are not chunked? This way an implementation that wants to start writing to the output buffer immediately will put "Byte-Range: *-*/*" while an implementation that wants to put the actual byte count in order to make message reading more efficient will put "Byte-Range 1-N/N" where N is the size of the message. Avshalom --=_alternative 007849EC42256F8D_= Content-Type: text/html; charset="US-ASCII"
In the MSRP 09 draft following examples appear:

   MSRP a786hjs2 SEND
  To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
  From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp
  Message-ID: 87652
  Content-Type: text/plain

  Hey Bob, are you there?
  -------a786hjs2$

  MSRP a786hjs2 200 OK
  To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp
  From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
  Message-ID: 87652
  -------a786hjs2$

Note that this format of messages enforces the reader of the messages to scan
the messages in order to find the end of the message.

It does not enable an implementation that decides to include byte count in
the message to do so.

Was not there a suggestion to include a Byte-Range (with an option to
put a '*' instead of a range) in every message even messages that
are not chunked?

This way an implementation that wants to start writing to the output
buffer immediately will put "Byte-Range: *-*/*" while an implementation
that wants to put the actual byte count in order to make message reading
more efficient will put "Byte-Range 1-N/N" where N is the size of the message.

Avshalom

--=_alternative 007849EC42256F8D_=-- --===============1288741145== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1288741145==-- From simple-bounces@ietf.org Tue Jan 18 19:01:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20559; Tue, 18 Jan 2005 19:01:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr3Xj-0000qP-43; Tue, 18 Jan 2005 19:17:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr39c-0007z0-CW; Tue, 18 Jan 2005 18:52:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr392-0007nX-GU for simple@megatron.ietf.org; Tue, 18 Jan 2005 18:52:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19815 for ; Tue, 18 Jan 2005 18:52:17 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr3ON-0000Zh-PL for simple@ietf.org; Tue, 18 Jan 2005 19:08:13 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 18 Jan 2005 15:51:58 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0INpjRO011025; Tue, 18 Jan 2005 15:51:45 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Received: e2k4.cisco.com 171.70.93.57 from 10.82.241.12 10.82.241.12 via HTTP with MS-WebStorage 6.5.6944 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable User-Agent: Microsoft-Entourage/11.1.0.040913 In-Reply-To: Content-class: urn:content-classes:message Subject: Re: [Simple] Byte Range in MSRP Date: Tue, 18 Jan 2005 15:50:38 -0800 Message-ID: Thread-Topic: [Simple] Byte Range in MSRP Thread-Index: AcT9uILe2KbUK0PFQLGrYSVPfpAfsA== From: "Jennings, Cullen" To: "Avshalom Houri" , X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Right - this topic has been widely discussed on many previous emails On 1/18/05 11:54 AM, "Avshalom Houri" wrote: >=20 > In the MSRP 09 draft following examples appear: >=20 > MSRP a786hjs2 SEND > To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp > From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp > Message-ID: 87652 > Content-Type: text/plain >=20 > Hey Bob, are you there? > -------a786hjs2$ >=20 > MSRP a786hjs2 200 OK > To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp > From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp > Message-ID: 87652 > -------a786hjs2$ >=20 > Note that this format of messages enforces the reader of the messages = to scan > the messages in order to find the end of the message. Yes - this is because of the multiplexing behavior, a message may be = split up mid way through transmission on this - since this is not known when = it starts, you need of scan. Extensive playing with this has shown that scanning for ------- is just = as fast as coping to memory on every system someone could find >=20 > It does not enable an implementation that decides to include byte = count in > the message to do so. The draft does support including a byte count >=20 > Was not there a suggestion to include a Byte-Range (with an option to > put a '*' instead of a range) in every message even messages that > are not chunked?=20 Yes this Byte-Range stuff is all in the 09 version of the draft - and = the stuff below=20 >=20 > This way an implementation that wants to start writing to the output > buffer immediately will put "Byte-Range: *-*/*" while an = implementation > that wants to put the actual byte count in order to make message = reading > more efficient will put "Byte-Range 1-N/N" where N is the size of the = message. > =20 > Avshalom=20 >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 18 21:17:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00860; Tue, 18 Jan 2005 21:17:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr5ed-0003vW-6R; Tue, 18 Jan 2005 21:33:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr5O5-0000kB-Ou; Tue, 18 Jan 2005 21:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr5Mv-0000VO-Fa for simple@megatron.ietf.org; Tue, 18 Jan 2005 21:14:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00780 for ; Tue, 18 Jan 2005 21:14:47 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr5cI-0003sK-TQ for simple@ietf.org; Tue, 18 Jan 2005 21:30:43 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 18 Jan 2005 18:14:17 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 18 Jan 2005 18:14:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Byte Range in MSRP Date: Tue, 18 Jan 2005 18:14:10 -0800 Message-ID: Thread-Topic: [Simple] Byte Range in MSRP Thread-Index: AcT9uILe2KbUK0PFQLGrYSVPfpAfsAAEqlDQ From: "Orit Levin" To: "Jennings, Cullen" , "Avshalom Houri" , X-OriginalArrivalTime: 19 Jan 2005 02:14:16.0115 (UTC) FILETIME=[93639830:01C4FDCC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Avshalom has a good point here, which I have overlooked.=20 We have never agreed that scanning is the always preferred way of finding the end of the packet. The current mechanism allows for both, indeed. I would strongly suggest to include an example in the draft that shows the byte count being included even where no chunking is performed. When the originator doesn't chunk the message to start from, the byte range SHOULD be included (I think that MUST is even more appropriate). Thanks, Orit. > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Jennings, Cullen > Sent: Tuesday, January 18, 2005 3:51 PM > To: Avshalom Houri; simple@ietf.org > Subject: Re: [Simple] Byte Range in MSRP >=20 >=20 > Right - this topic has been widely discussed on many previous emails >=20 > On 1/18/05 11:54 AM, "Avshalom Houri" wrote: >=20 > >=20 > > In the MSRP 09 draft following examples appear: > >=20 > > MSRP a786hjs2 SEND > > To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp > > From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp > > Message-ID: 87652 > > Content-Type: text/plain > >=20 > > Hey Bob, are you there? > > -------a786hjs2$ > >=20 > > MSRP a786hjs2 200 OK > > To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp > > From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp > > Message-ID: 87652 > > -------a786hjs2$ > >=20 > > Note that this format of messages enforces the reader of=20 > the messages=20 > > to scan the messages in order to find the end of the message. > Yes - this is because of the multiplexing behavior, a message=20 > may be split up mid way through transmission on this - since=20 > this is not known when it starts, you need of scan. >=20 > Extensive playing with this has shown that scanning for=20 > ------- is just as fast as coping to memory on every system=20 > someone could find >=20 > >=20 > > It does not enable an implementation that decides to include byte=20 > > count in the message to do so. >=20 > The draft does support including a byte count >=20 > >=20 > > Was not there a suggestion to include a Byte-Range (with an=20 > option to=20 > > put a '*' instead of a range) in every message even=20 > messages that are=20 > > not chunked? >=20 > Yes this Byte-Range stuff is all in the 09 version of the=20 > draft - and the stuff below=20 >=20 > >=20 > > This way an implementation that wants to start writing to=20 > the output=20 > > buffer immediately will put "Byte-Range: *-*/*" while an=20 > > implementation that wants to put the actual byte count in order to=20 > > make message reading more efficient will put "Byte-Range=20 > 1-N/N" where N is the size of the message. > > > =20 > > Avshalom > >=20 > >=20 > >=20 > > _______________________________________________ > > 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-bounces@ietf.org Tue Jan 18 21:48:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02293; Tue, 18 Jan 2005 21:48:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr68b-0004V7-5G; Tue, 18 Jan 2005 22:04:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr5rA-0005dI-8t; Tue, 18 Jan 2005 21:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr5qd-0005VB-CW for simple@megatron.ietf.org; Tue, 18 Jan 2005 21:45:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01987 for ; Tue, 18 Jan 2005 21:45:29 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr660-0004PO-Qb for simple@ietf.org; Tue, 18 Jan 2005 22:01:25 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 18 Jan 2005 18:45:17 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0J2ivRO028387; Tue, 18 Jan 2005 18:44:58 -0800 (PST) Received: e2k4.cisco.com 171.70.93.57 from 10.21.121.85 10.21.121.85 via HTTP with MS-WebStorage 6.5.6944 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 18 Jan 2005 16:44:57 -1000 Subject: Re: [Simple] Byte Range in MSRP From: Cullen Jennings To: Orit Levin , Avshalom Houri , "simple@ietf.org" Message-ID: In-Reply-To: Mime-version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0726152983==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 > 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. --===============0726152983== Content-type: multipart/alternative; boundary="B_3188911498_89963" > 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. --B_3188911498_89963 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Agree - good point - I'll make sure there is an example in the Framing and chunking section section that has this. Cullen On 1/18/05 4:14 PM, "Orit Levin" wrote: > Avshalom has a good point here, which I have overlooked. > > We have never agreed that scanning is the always preferred way of > finding the end of the packet. The current mechanism allows for both, > indeed. > I would strongly suggest to include an example in the draft that shows > the byte count being included even where no chunking is performed. > > When the originator doesn't chunk the message to start from, the byte > range SHOULD be included (I think that MUST is even more appropriate). > > Thanks, > Orit. > >> > -----Original Message----- >> > From: simple-bounces@ietf.org >> > [mailto:simple-bounces@ietf.org] On Behalf Of Jennings, Cullen >> > Sent: Tuesday, January 18, 2005 3:51 PM >> > To: Avshalom Houri; simple@ietf.org >> > Subject: Re: [Simple] Byte Range in MSRP >> > >> > >> > Right - this topic has been widely discussed on many previous emails >> > >> > On 1/18/05 11:54 AM, "Avshalom Houri" wrote: >> > >>> > > >>> > > In the MSRP 09 draft following examples appear: >>> > > >>> > > MSRP a786hjs2 SEND >>> > > To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp >>> > > From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp >>> > > Message-ID: 87652 >>> > > Content-Type: text/plain >>> > > >>> > > Hey Bob, are you there? >>> > > -------a786hjs2$ >>> > > >>> > > MSRP a786hjs2 200 OK >>> > > To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp >>> > > From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp >>> > > Message-ID: 87652 >>> > > -------a786hjs2$ >>> > > >>> > > Note that this format of messages enforces the reader of >> > the messages >>> > > to scan the messages in order to find the end of the message. >> > Yes - this is because of the multiplexing behavior, a message >> > may be split up mid way through transmission on this - since >> > this is not known when it starts, you need of scan. >> > >> > Extensive playing with this has shown that scanning for >> > ------- is just as fast as coping to memory on every system >> > someone could find >> > >>> > > >>> > > It does not enable an implementation that decides to include byte >>> > > count in the message to do so. >> > >> > The draft does support including a byte count >> > >>> > > >>> > > Was not there a suggestion to include a Byte-Range (with an >> > option to >>> > > put a '*' instead of a range) in every message even >> > messages that are >>> > > not chunked? >> > >> > Yes this Byte-Range stuff is all in the 09 version of the >> > draft - and the stuff below >> > >>> > > >>> > > This way an implementation that wants to start writing to >> > the output >>> > > buffer immediately will put "Byte-Range: *-*/*" while an >>> > > implementation that wants to put the actual byte count in order to >>> > > make message reading more efficient will put "Byte-Range >> > 1-N/N" where N is the size of the message. >>> > > >> > >>> > > Avshalom >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > 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 >> > > --B_3188911498_89963 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Simple] Byte Range in MSRP
Agree - good point - I'll make sure there is an example in the Framing and = chunking section section that has this.

Cullen

On 1/18/05 4:14 PM, "Orit Levin" <oritl@microsoft.com> wrot= e:

Avshalom has a good point here, which I have overlooked= .

We have never agreed that scanning is the always preferred way of
finding the end of the packet. The current mechanism allows for both,
indeed.
I would strongly suggest to include an example in the draft that shows
the byte count being included even where no chunking is performed.

When the originator doesn't chunk the message to start from, the byte
range SHOULD be included (I think that MUST is even more appropriate).

Thanks,
Orit.

> -----Original Message-----
> From: simple-bounces@ietf.org
> [mailto:simple-bounces@ietf.= org] On Behalf Of Jennings, Cullen
> Sent: Tuesday, January 18, 2005 3:51 PM
> To: Avshalom Houri; simple@ietf.org
> Subject: Re: [Simple] Byte Range in MSRP
>
>
> Right - this topic has been widely discussed on many previous emails <= BR> >
> On 1/18/05 11:54 AM, "Avshalom Houri" <AVSHALOM@il.ibm.co= m> wrote:
>
> >
> > In the MSRP 09 draft following examples appear:
> >
> >    MSRP a786hjs2 SEND
> >    To-Path: msrp://biloxi.example.com:12763/kjhd37= s2s2;tcp
> >    From-Path: msrp://atlanta.example.com:7654/jshA= 7we;tcp
> >    Message-ID: 87652
> >    Content-Type: text/plain
> >
> >    Hey Bob, are you there?
> >    -------a786hjs2$
> >
> >    MSRP a786hjs2 200 OK
> >    To-Path: msrp://atlanta.example.com:7654/jshA7w= e;tcp
> >    From-Path: msrp://biloxi.example.com:12763/kjhd= 37s2s2;tcp
> >    Message-ID: 87652
> >    -------a786hjs2$
> >
> > Note that this format of messages enforces the reader of
> the messages
> > to scan the messages in order to find the end of the message. > Yes - this is because of the multiplexing behavior, a message
> may be split up mid way through transmission on this - since
> this is not known when it starts, you need of scan.
>
> Extensive playing with this has shown that scanning for
> ------- is just as fast as coping to memory on every system
> someone could find
>
> >
> > It does not enable an implementation that decides to include byte=
> > count in the message to do so.
>
> The draft does support including a byte count
>
> >
> > Was not there a suggestion to include a Byte-Range (with an
> option to
> > put a '*' instead of a range) in every message even
> messages that are
> > not chunked?
>
> Yes this Byte-Range stuff is all in the 09 version of the
> draft - and the stuff below
>
> >
> > This way an implementation that wants to start writing to
> the output
> > buffer immediately will put "Byte-Range: *-*/*" while a= n
> > implementation that wants to put the actual byte count in order t= o
> > make message reading more efficient will put "Byte-Range > 1-N/N" where N is the size of the message.
> >
>  
> > Avshalom
> >
> >
> >
> > _______________________________________________
> > 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
>


--B_3188911498_89963-- --===============0726152983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0726152983==-- From simple-bounces@ietf.org Wed Jan 19 14:45:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13997; Wed, 19 Jan 2005 14:45:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrM10-0003bL-R6; Wed, 19 Jan 2005 15:01:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrLjY-0007Py-2c; Wed, 19 Jan 2005 14:43:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrLgE-0006gh-8J for simple@megatron.ietf.org; Wed, 19 Jan 2005 14:39:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13650 for ; Wed, 19 Jan 2005 14:39:48 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrLvk-0003Qj-LK for simple@ietf.org; Wed, 19 Jan 2005 14:55:53 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Jan 2005 11:39:17 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Jan 2005 11:39:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple] Byte Range in MSRP Date: Wed, 19 Jan 2005 11:38:25 -0800 Message-ID: Thread-Topic: [Simple] Byte Range in MSRP Thread-Index: AcT90N7itbcynfEBTbSmBD+E6qGnvwAjR8Ig From: "Orit Levin" To: "Cullen Jennings" , "Avshalom Houri" , X-OriginalArrivalTime: 19 Jan 2005 19:39:24.0406 (UTC) FILETIME=[94717160:01C4FE5E] X-Spam-Score: 0.6 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0678626602==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d This is a multi-part message in MIME format. --===============0678626602== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FE5E.721F63CA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4FE5E.721F63CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cool. It can be very useful to have this (i.e. non-chunked short message) example using the byte range in the general section rather than in the chunking section. =20 Thanks, Orit. ________________________________ From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Tuesday, January 18, 2005 6:45 PM To: Orit Levin; Avshalom Houri; simple@ietf.org Subject: Re: [Simple] Byte Range in MSRP =09 =09 =09 Agree - good point - I'll make sure there is an example in the Framing and chunking section section that has this. =09 Cullen =09 On 1/18/05 4:14 PM, "Orit Levin" wrote: =09 =09 Avshalom has a good point here, which I have overlooked. =09 We have never agreed that scanning is the always preferred way of=20 finding the end of the packet. The current mechanism allows for both,=20 indeed.=20 I would strongly suggest to include an example in the draft that shows=20 the byte count being included even where no chunking is performed.=20 =09 When the originator doesn't chunk the message to start from, the byte=20 range SHOULD be included (I think that MUST is even more appropriate).=20 =09 Thanks,=20 Orit.=20 =09 > -----Original Message-----=20 > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Jennings, Cullen=20 > Sent: Tuesday, January 18, 2005 3:51 PM=20 > To: Avshalom Houri; simple@ietf.org=20 > Subject: Re: [Simple] Byte Range in MSRP=20 >=20 >=20 > Right - this topic has been widely discussed on many previous emails=20 >=20 > On 1/18/05 11:54 AM, "Avshalom Houri" wrote:=20 >=20 > >=20 > > In the MSRP 09 draft following examples appear:=20 > >=20 > > MSRP a786hjs2 SEND=20 > > To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp=20 > > From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp=20 > > Message-ID: 87652=20 > > Content-Type: text/plain=20 > >=20 > > Hey Bob, are you there?=20 > > -------a786hjs2$=20 > >=20 > > MSRP a786hjs2 200 OK=20 > > To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp=20 > > From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp=20 > > Message-ID: 87652=20 > > -------a786hjs2$=20 > >=20 > > Note that this format of messages enforces the reader of=20 > the messages=20 > > to scan the messages in order to find the end of the message.=20 > Yes - this is because of the multiplexing behavior, a message=20 > may be split up mid way through transmission on this - since=20 > this is not known when it starts, you need of scan.=20 >=20 > Extensive playing with this has shown that scanning for=20 > ------- is just as fast as coping to memory on every system=20 > someone could find=20 >=20 > >=20 > > It does not enable an implementation that decides to include byte=20 > > count in the message to do so.=20 >=20 > The draft does support including a byte count=20 >=20 > >=20 > > Was not there a suggestion to include a Byte-Range (with an=20 > option to=20 > > put a '*' instead of a range) in every message even=20 > messages that are=20 > > not chunked?=20 >=20 > Yes this Byte-Range stuff is all in the 09 version of the=20 > draft - and the stuff below=20 >=20 > >=20 > > This way an implementation that wants to start writing to=20 > the output=20 > > buffer immediately will put "Byte-Range: *-*/*" while an=20 > > implementation that wants to put the actual byte count in order to=20 > > make message reading more efficient will put "Byte-Range=20 > 1-N/N" where N is the size of the message.=20 > >=20 > =20 > > Avshalom=20 > >=20 > >=20 > >=20 > > _______________________________________________=20 > > Simple mailing list=20 > > Simple@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/simple=20 >=20 >=20 >=20 >=20 > _______________________________________________=20 > Simple mailing list=20 > Simple@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/simple=20 >=20 =09 =09 =09 =09 ------_=_NextPart_001_01C4FE5E.721F63CA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Simple] Byte Range in MSRP
Cool.
It can be very useful to have this (i.e. = non-chunked short=20 message) example using the byte range in the general section rather than = in the=20 chunking section.
 
Thanks,
Orit.

From: Cullen Jennings=20 [mailto:fluffy@cisco.com]
Sent: Tuesday, January 18, 2005 = 6:45=20 PM
To: Orit Levin; Avshalom Houri;=20 simple@ietf.org
Subject: Re: [Simple] Byte Range in=20 MSRP


Agree - good point - I'll make sure = there is an=20 example in the Framing and chunking section section that has=20 this.

Cullen

On 1/18/05 4:14 PM, "Orit Levin"=20 <oritl@microsoft.com> wrote:
Avshalom has a good point here, which I = have=20 overlooked.

We have never agreed that scanning is the always = preferred way of
finding the end of the packet. The current = mechanism=20 allows for both,
indeed.
I would strongly suggest to include = an=20 example in the draft that shows
the byte count being included = even where=20 no chunking is performed.

When the originator doesn't chunk = the=20 message to start from, the byte
range SHOULD be included (I = think that=20 MUST is even more appropriate).

Thanks,
Orit. =

>=20 -----Original Message-----
> From: simple-bounces@ietf.org =
>=20 [mailto:simple-bounces@ietf.org]<= /A>=20 On Behalf Of Jennings, Cullen
> Sent: Tuesday, January 18, = 2005 3:51=20 PM
> To: Avshalom Houri; simple@ietf.org
> Subject: = Re:=20 [Simple] Byte Range in MSRP
>
>
> Right - this = topic=20 has been widely discussed on many previous emails
>
> = On=20 1/18/05 11:54 AM, "Avshalom Houri" <AVSHALOM@il.ibm.com> = wrote:=20
>
> >
> > In the MSRP 09 draft following = examples=20 appear:
> >
> >    MSRP a786hjs2 = SEND=20
> >    To-Path:=20 msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
> >=20    From-Path: = msrp://atlanta.example.com:7654/jshA7we;tcp=20
> >    Message-ID: 87652
> >=20    Content-Type: text/plain
> >
> = >=20    Hey Bob, are you there?
> >=20    -------a786hjs2$
> >
> >=20    MSRP a786hjs2 200 OK
> >=20    To-Path: = msrp://atlanta.example.com:7654/jshA7we;tcp=20
> >    From-Path:=20 msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
> >=20    Message-ID: 87652
> >=20    -------a786hjs2$
> >
> > Note = that=20 this format of messages enforces the reader of
> the messages =
> > to scan the messages in order to find the end of the = message.=20
> Yes - this is because of the multiplexing behavior, a = message=20
> may be split up mid way through transmission on this - = since=20
> this is not known when it starts, you need of scan. =
>=20
> Extensive playing with this has shown that scanning for =
>=20 ------- is just as fast as coping to memory on every system
> = someone=20 could find
>
> >
> > It does not enable = an=20 implementation that decides to include byte
> > count in = the=20 message to do so.
>
> The draft does support including = a byte=20 count
>
> >
> > Was not there a = suggestion to=20 include a Byte-Range (with an
> option to
> > put a = '*'=20 instead of a range) in every message even
> messages that are =
> > not chunked?
>
> Yes this Byte-Range = stuff is=20 all in the 09 version of the
> draft - and the stuff below =
>=20
> >
> > This way an implementation that wants to = start=20 writing to
> the output
> > buffer immediately will = put=20 "Byte-Range: *-*/*" while an
> > implementation that wants = to put=20 the actual byte count in order to
> > make message reading = more=20 efficient will put "Byte-Range
> 1-N/N" where N is the size = of the=20 message.
> >
>  
> > Avshalom =
> >=20
> >
> >
> >=20 _______________________________________________
> > Simple = mailing=20 list
> > Simple@ietf.org
> >=20 https://www1.ietf.org/mailman/listinfo/simple
>
> =
>=20
>
> _______________________________________________ =
>=20 Simple mailing list
> Simple@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/simple
>=20


------_=_NextPart_001_01C4FE5E.721F63CA-- --===============0678626602== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0678626602==-- From qeeubi@msn.com Wed Jan 19 22:33:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27458; Wed, 19 Jan 2005 22:33:51 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrTKZ-0008Rd-Na; Wed, 19 Jan 2005 22:50:00 -0500 Received: from 60-240-102-245-nsw-pppoe.tpgi.com.au ([60.240.102.245]) by mx2.foretec.com with smtp (Exim 4.24) id 1CrT4j-00038k-Ej; Wed, 19 Jan 2005 22:33:49 -0500 Received: from circumcise.anu.strabismic.au ([125.244.191.7] helo=anu.corridor.au) by smtp1.crappie.co with esmtp id 1A5Ys6-261106-60 Message-ID: Sender: freeradius-devel-qeeubi@msn.com X-Mailman-Version: 2.0.1 Date: Wed, 19 Jan 2005 22:26:22 -0500 From: "Shannon Dalton" To: sic@ietf.org, sigtran@ietf.org, sigtran-admin@ietf.org, simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-request@ietf.org, simple-web-archive@ietf.org, sip@ietf.org, sip-admin@ietf.org, sip-request@ietf.org, sip-security@ietf.org Subject: Viic0din for 0nly $90 dNc X-Spam-Score: 3.0 (+++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Huge offer for Viicodin, Viagraa, Vallium and lots moreee... savee up to 7o% meds on our stores. Visit uss today http://uhviagra.info/in.php?aid=56 This is 1 -time mailing. N0-re m0val are re'qui-red MDelG3CJsFo4dqKUrP0SowENBUKr3vfzDVKlg3ioh4SGSt1aQ9Tv6ygGmgbl7m From simple-bounces@ietf.org Wed Jan 19 23:00:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00508; Wed, 19 Jan 2005 23:00:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrTkT-0000lI-Kz; Wed, 19 Jan 2005 23:16:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrTMU-0006By-Da; Wed, 19 Jan 2005 22:51:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrTHC-0005NK-VR for simple@megatron.ietf.org; Wed, 19 Jan 2005 22:46:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29126 for ; Wed, 19 Jan 2005 22:46:28 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrTWn-0000Ny-QM for simple@ietf.org; Wed, 19 Jan 2005 23:02:38 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2005 19:46:26 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0K3j71M023207; Wed, 19 Jan 2005 19:45:08 -0800 (PST) Received: e2k4.cisco.com 171.70.93.57 from 10.21.88.131 10.21.88.131 via HTTP with MS-WebStorage 6.5.6944 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 19 Jan 2005 17:45:08 -1000 Subject: Re: [Simple] Byte Range in MSRP From: Cullen Jennings To: Orit Levin , Avshalom Houri , "simple@ietf.org" Message-ID: In-Reply-To: Mime-version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1125244390==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad > 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. --===============1125244390== Content-type: multipart/alternative; boundary="B_3189001508_563190" > 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. --B_3189001508_563190 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Fair enough - I will go and update the examples in the Overview section to have a Byte-Range header. On 1/19/05 9:38 AM, "Orit Levin" wrote: > Cool. > It can be very useful to have this (i.e. non-chunked short message) example > using the byte range in the general section rather than in the chunking > section. > > Thanks, > Orit. > >> >> >> >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Tuesday, January 18, 2005 6:45 PM >> To: Orit Levin; Avshalom Houri; simple@ietf.org >> Subject: Re: [Simple] Byte Range in MSRP >> >> >> >> Agree - good point - I'll make sure there is an example in the Framing and >> chunking section section that has this. >> >> Cullen >> >> On 1/18/05 4:14 PM, "Orit Levin" wrote: >> >> >>> Avshalom has a good point here, which I have overlooked. >>> >>> We have never agreed that scanning is the always preferred way of >>> finding the end of the packet. The current mechanism allows for both, >>> indeed. >>> I would strongly suggest to include an example in the draft that shows >>> the byte count being included even where no chunking is performed. >>> >>> When the originator doesn't chunk the message to start from, the byte >>> range SHOULD be included (I think that MUST is even more appropriate). >>> >>> Thanks, >>> Orit. >>> >>>> > -----Original Message----- >>>> > From: simple-bounces@ietf.org >>>> > [mailto:simple-bounces@ietf.org] On Behalf Of Jennings, Cullen >>>> > Sent: Tuesday, January 18, 2005 3:51 PM >>>> > To: Avshalom Houri; simple@ietf.org >>>> > Subject: Re: [Simple] Byte Range in MSRP >>>> > >>>> > >>>> > Right - this topic has been widely discussed on many previous emails >>>> > >>>> > On 1/18/05 11:54 AM, "Avshalom Houri" wrote: >>>> > >>>>> > > >>>>> > > In the MSRP 09 draft following examples appear: >>>>> > > >>>>> > > MSRP a786hjs2 SEND >>>>> > > To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp >>>>> > > From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp >>>>> > > Message-ID: 87652 >>>>> > > Content-Type: text/plain >>>>> > > >>>>> > > Hey Bob, are you there? >>>>> > > -------a786hjs2$ >>>>> > > >>>>> > > MSRP a786hjs2 200 OK >>>>> > > To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp >>>>> > > From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp >>>>> > > Message-ID: 87652 >>>>> > > -------a786hjs2$ >>>>> > > >>>>> > > Note that this format of messages enforces the reader of >>>> > the messages >>>>> > > to scan the messages in order to find the end of the message. >>>> > Yes - this is because of the multiplexing behavior, a message >>>> > may be split up mid way through transmission on this - since >>>> > this is not known when it starts, you need of scan. >>>> > >>>> > Extensive playing with this has shown that scanning for >>>> > ------- is just as fast as coping to memory on every system >>>> > someone could find >>>> > >>>>> > > >>>>> > > It does not enable an implementation that decides to include byte >>>>> > > count in the message to do so. >>>> > >>>> > The draft does support including a byte count >>>> > >>>>> > > >>>>> > > Was not there a suggestion to include a Byte-Range (with an >>>> > option to >>>>> > > put a '*' instead of a range) in every message even >>>> > messages that are >>>>> > > not chunked? >>>> > >>>> > Yes this Byte-Range stuff is all in the 09 version of the >>>> > draft - and the stuff below >>>> > >>>>> > > >>>>> > > This way an implementation that wants to start writing to >>>> > the output >>>>> > > buffer immediately will put "Byte-Range: *-*/*" while an >>>>> > > implementation that wants to put the actual byte count in order to >>>>> > > make message reading more efficient will put "Byte-Range >>>> > 1-N/N" where N is the size of the message. >>>>> > > >>>> > >>>>> > > Avshalom >>>>> > > >>>>> > > >>>>> > > >>>>> > > _______________________________________________ >>>>> > > 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 >>>> > >>> >> > --B_3189001508_563190 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Simple] Byte Range in MSRP
Fair enough - I will go and update the examples in the Overview section to = have a Byte-Range header.


On 1/19/05 9:38 AM, "Orit Levin" <oritl@microsoft.com> wrot= e:

Cool.
It can be very useful to have this (i.e. non-chunked short message) example= using the byte range in the general section rather than in the chunking sec= tion.
Thanks,
Orit.


 
From:= Cullen Jennings  [mailto:fluffy= @cisco.com]
Sent: Tuesday, January 18, 2005 6:45  PM
To: Orit Levin; Avshalom Houri;  simple@ietf.org
Subject: Re: [Simple] Byte Range in  MSRP

 

Agree - good point - I'll make sure there is an  example in the Framin= g and chunking section section that has  this.

Cullen

On 1/18/05 4:14 PM, "Orit Levin"  <oritl@microsoft.com>= ; wrote:

 
Avshalom has a good point here, which I have  over= looked.

We have never agreed that scanning is the always  preferred way of finding the end of the packet. The current mechanism  allows for both,=
indeed.
I would strongly suggest to include an  example in the draft that show= s
the byte count being included even where  no chunking is performed.
When the originator doesn't chunk the  message to start from, the byte=
range SHOULD be included (I think that  MUST is even more appropriate)= .

Thanks,
Orit.

>  -----Original Message-----
> From: simple-bounces@ietf.org
>  [mailto:simple-bounces= @ietf.org]  On Behalf Of Jennings, Cullen
> Sent: Tuesday, January 18, 2005 3:51  PM
> To: Avshalom Houri; simple@ietf.org
> Subject: Re:  [Simple] Byte Range in MSRP
>
>
> Right - this topic  has been widely discussed on many previous em= ails
>
> On  1/18/05 11:54 AM, "Avshalom Houri" <AVSHALOM@il.= ibm.com> wrote:  
>
> >
> > In the MSRP 09 draft following examples  appear:
> >
> >    MSRP a786hjs2 SEND  
> >    To-Path:  msrp://biloxi.example.com:12763/= kjhd37s2s2;tcp
> >     From-Path: msrp://atlanta.example.com:765= 4/jshA7we;tcp  
> >    Message-ID: 87652
> >     Content-Type: text/plain
> >
> >     Hey Bob, are you there?
> >     -------a786hjs2$
> >
> >     MSRP a786hjs2 200 OK
> >     To-Path: msrp://atlanta.example.com:7654/= jshA7we;tcp  
> >    From-Path:  msrp://biloxi.example.com:1276= 3/kjhd37s2s2;tcp
> >     Message-ID: 87652
> >     -------a786hjs2$
> >
> > Note that  this format of messages enforces the reader of > the messages  
> > to scan the messages in order to find the end of the message. &nb= sp;
> Yes - this is because of the multiplexing behavior, a message   > may be split up mid way through transmission on this - since   > this is not known when it starts, you need of scan.
>  
> Extensive playing with this has shown that scanning for
>  ------- is just as fast as coping to memory on every system
> someone  could find
>
> >
> > It does not enable an  implementation that decides to includ= e byte
> > count in the  message to do so.
>
> The draft does support including a byte  count
>
> >
> > Was not there a suggestion to  include a Byte-Range (with an=
> option to
> > put a '*'  instead of a range) in every message even
> messages that are  
> > not chunked?
>
> Yes this Byte-Range stuff is  all in the 09 version of the
> draft - and the stuff below
>  
> >
> > This way an implementation that wants to start  writing to <= BR> > the output
> > buffer immediately will put  "Byte-Range: *-*/*" w= hile an
> > implementation that wants to put  the actual byte count in o= rder to
> > make message reading more  efficient will put "Byte-Ran= ge
> 1-N/N" where N is the size of the  message.
> >
>  
> > Avshalom
> >  
> >
> >
> >  _______________________________________________
> > 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
>  




 --B_3189001508_563190-- --===============1125244390== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1125244390==-- From simple-bounces@ietf.org Fri Jan 21 07:36:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05524; Fri, 21 Jan 2005 07:36:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CryHC-0001dY-6R; Fri, 21 Jan 2005 07:52:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrxyG-00026s-Cu; Fri, 21 Jan 2005 07:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crxxf-0001xq-Jk for simple@megatron.ietf.org; Fri, 21 Jan 2005 07:32:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05193 for ; Fri, 21 Jan 2005 07:32:22 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CryDY-0001Y1-08 for simple@ietf.org; Fri, 21 Jan 2005 07:48:48 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Jan 2005 05:40:04 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0LCW4Nt013044; Fri, 21 Jan 2005 04:32:04 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-154.cisco.com [10.86.242.154]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHE58011; Fri, 21 Jan 2005 04:32:03 -0800 (PST) Message-ID: <41F06687.5010504@cisco.com> Date: Thu, 20 Jan 2005 21:18:47 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: multiple person elements, was: Re: [Simple] presence-rules: Selecting on class References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: >> A presentity needs to be able to expose tuples based on the class >> the presentity assigned to it (this was a primary motivator of the >> class element if I understand it correctly, allowing me to group >> elements to expose to my family vs those I expose to my >> co-workers). Currently, there's no way to make that kind of >> transformation with a presence-rule. >> > > > Yes, I am expecting to be able to use class for that, although it > might have other usages too. > > >> Jonathan and I discussed this briefly - the idea that came out was >> to add one or more elements to that >> would only provide those services matching one of the stated >> classes. >> > > > Yes, this is a good idea. > > >> Thoughts? >> >> I suspect we need this for and too? >> > > > Yes, I support this too. In this case RPID needs to say that class > applies to , and (if the latest version > already does not). I am fine with this, and will add class-based selectors to the provide-service, provide-device and provide-person elements. I'll note that we never really concluded on the issue of multiple person elements in a document. There did appear consensus (though I personally still disagree) to support multiple person elements in a document in order to represent conflicting data about a person. This raised several questions we need to answer: 1. how to distinctly identify each one of them? I'd propose that we keep this really simple for now and just use an "id" attribute of the element. 2. what kind of meta-data do we need to provide the watcher the tools they need to pick a particular source of data? I'd propose that, for now - nothing. 3. impact on the data model I'd actually like to keep the underlying model in the document, which says that there is one person; this is still true - we are still talking about ONE person, its just that we have multiple conflicting pieces of information about that person, and so have chosen the syntactic approach of using multiple elements to convey this. Thanks, Jonathan R. > > A follow-up question obviously is that how is the rule-maker able to > know which class values a PUA is going to use. If they are > co-located, it's easy, but if the user has e.g. multiple devices, > this gets more difficult. But that is a separated problem from the > presence-rules. > > >> RjS >> > > > Markus > > _______________________________________________ Simple mailing list > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 21 07:40:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05664; Fri, 21 Jan 2005 07:40:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CryL1-0001ig-TG; Fri, 21 Jan 2005 07:56:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrxyH-000271-64; Fri, 21 Jan 2005 07:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crxxg-0001xu-8t for simple@megatron.ietf.org; Fri, 21 Jan 2005 07:32:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05196 for ; Fri, 21 Jan 2005 07:32:23 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CryDY-0001Y1-Pw for simple@ietf.org; Fri, 21 Jan 2005 07:48:49 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 21 Jan 2005 05:40:08 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0LCVuM8024389; Fri, 21 Jan 2005 04:31:56 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-154.cisco.com [10.86.242.154]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHE58016; Fri, 21 Jan 2005 04:32:07 -0800 (PST) Message-ID: <41F06F88.8090205@cisco.com> Date: Thu, 20 Jan 2005 21:57:12 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] PIDF "entity" attribute usage References: <1BEC4DA05ABCD34FACFCFC82086AC24704A0D3E1@RED-MSG-43.redmond.corp.microsoft.com> <41E6E9E5.2000305@cisco.com> In-Reply-To: <41E6E9E5.2000305@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Cc: Tim Rang , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > > > Tim Rang wrote: > >> Paul, >> >> You had me until here- >> >> >> So, at least in principle, when using SIMPLE, you can use either sip or >> >> pres URIs. However this assumes the specific implementation you are >> using actually supports this. In practice you should determine what >> the implementation you are using supports. >> >> >> [Tim Rang] Can a SIMPLE implementation expect that all other SIMPLE >> implementations support receiving the sip scheme in the entity >> attribute? > > > Probably not. I *think* a SIMPLE implementation must at least support > receiving an entity attribute containing the URI used to subscribe for > that presence. (And I suspect many will require that - don't recall if > the specs require it.) > > So the bigger question is whether a SIMPLE implementation is able to > *issue* a presence subscription to a { sip / pres } URI, and whether it > is able to *accept* a presence subscription to a { sip / pres } URI. > > The issue of accepting doesn't seem like a big deal. The presence > implementation is responsible for defining what URIs its presentities > have, so a user should know what uri is supported to access that > presentity. I don't follow this. Lets consider watchers for a moment. There two things for a watcher: 1. could it issue a SUBSCRIBE request to a pres: URI; appropriately doing the DNS operations needed to resolve it to a SIP URI 2. if it receives a presence document in a notification, could it handle an entity attribute that is a pres URI For the presence agent, there are a bunch of cases: 1. Could the PA receive a SUBSCRIBE request where the r-uri is a pres URI, presumably equating it to presence data associated with a SIP URI? 2. Could the PA receive a presence document in a PUBLISH where one or both of the r-uri and entity tags in the published document are pres URI? These are complicated questions. I think we should place the burden on the owner of the domain to really worry about correlation of these identifiers. That would argue for the following: 1. If a watcher genreates a SUBSCRIBE request with a pres URI in the r-uri, and the presence agent is responsible for generation of the presence document and can thus create one with either a pres or SIP URI in the entity attribute, it MUST create one using the pres URI. 2. If a watcher genreates a SUBSCRIBE request with a sip URI in the r-uri, and the presence agent is responsible for generation of the presence document and can thus create one with either a pres or SIP URI in the entity attribute, it MUST create one using the sip URI. 3. If the PA cannot genreate the document or otherwise modify its entity attribute (for example if covered by an e2e signature), it MUST be capable of receiving subscriptions to either the pres or SIP URI in the request URI (thus be capable of equating the two URI) and thus return whatever it has. Rules (1) and (2) also operate under the principle of least surprise; I should get documents where the entity attribute matches what I subscribed to. It also means that a watcher which has never even heard of a pres URI would never see a notification containing a document with a pres URI in the entity attribute, unless e2e signatures prevents it. From a publishing perspective, I think the PA should support any of the four combinations of pres/sip URI in the r-uri and entity attributes. Where does this discussion belong? Since it largely deals with the construction of presence documents, I'd argue in the data model, but I'm open to suggestions. Thoughts? -Jonathan R. > > The ability to issue subscription requests to one kind or the other of > uri is probably the big issue. If I tell you my presence URI is > pres:paul@example.com but your presence client doesn't support pres > URIs, then you are just out of luck. > > I personally don't see any particular value in pres URIs. If I want a > SIMPLE presence client, it is probably in support of a SIP UA that will > be doing voice or IM. Both of those require the use of sip URIs. If I > have all the support for sip, then why not use it for presence too? The > pres URI is just a 5th wheel. > > Paul > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 21 07:41:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05718; Fri, 21 Jan 2005 07:41:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CryM0-0001jr-Gd; Fri, 21 Jan 2005 07:57:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrxyI-00027H-HT; Fri, 21 Jan 2005 07:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crxxs-0001yk-Ki for simple@megatron.ietf.org; Fri, 21 Jan 2005 07:32:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05225 for ; Fri, 21 Jan 2005 07:32:35 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CryDl-0001Y5-7d for simple@ietf.org; Fri, 21 Jan 2005 07:49:01 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 21 Jan 2005 04:34:37 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0LCW21M018045; Fri, 21 Jan 2005 04:32:03 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-154.cisco.com [10.86.242.154]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHE58010; Fri, 21 Jan 2005 04:32:01 -0800 (PST) Message-ID: <41F063DF.9040405@cisco.com> Date: Thu, 20 Jan 2005 21:07:27 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] About change in authorization policy References: <41ED3521.2030106@cisco.com> In-Reply-To: <41ED3521.2030106@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > > > Markus.Isomaki@nokia.com wrote: > >> Paul, >> >> I think there is at least one realistic case where what Jeffrey >> brought up causes some trouble. >> If value is used to influence the authorization decisions, >> i.e. different authorization rules apply when sphere=="home" than >> sphere=="work", the allowed vs. forbidden state for a particular >> subscriber could very well change at least twice a day. If that >> subscriber wants to be constantly subscribed to presence whenever it >> is allowed, she would have to do some polling. For instance if someone >> forbids her boss to subscribe while she is not working, the boss would >> not know when to subscribe again after the previous subscription was >> terminated. >> >> This makes me think that the recommended way to use should be >> not to make it affect the subscription state, but just the content, >> perhaps using polite blocking. > > > Yes. This falls into the category of "if it hurts, don't do it". In this > case, you may not want your boss bothering you while you are not > working, but you probably don't want to piss off your boss. I concur here as well. I think this issue has been raised in the past as a general concern around using presence state itself as a condition for subscription acceptance/rejection. However, I will note that the same issues arise for any decision based on dynamic data, such as time of day. > >> If we don't come up with any other fix to this, I think at least this >> issue should be written in a relevant section of the presence-rules RFC. > > > This sounds like a different document - a best practices for presence. I don't think it could hurt to mention this in the authorization rules document. I'll do that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 21 07:41:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05747; Fri, 21 Jan 2005 07:41:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CryMf-0001kc-4z; Fri, 21 Jan 2005 07:58:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrxyJ-00027M-5g; Fri, 21 Jan 2005 07:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crxxt-0001ym-Vt for simple@megatron.ietf.org; Fri, 21 Jan 2005 07:32:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05230 for ; Fri, 21 Jan 2005 07:32:36 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CryDl-0001Y5-Pd for simple@ietf.org; Fri, 21 Jan 2005 07:49:02 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 21 Jan 2005 04:34:41 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0LCW6RO005319; Fri, 21 Jan 2005 04:32:07 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-154.cisco.com [10.86.242.154]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHE58014; Fri, 21 Jan 2005 04:32:05 -0800 (PST) Message-ID: <41F069D7.7080505@cisco.com> Date: Thu, 20 Jan 2005 21:32:55 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: [Simple] presence-rules: providing all attributes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit I'd propose that we have a "provide-all-attributes" that is similar to "provide-unknown-attributes" This would provide attributes across the device, service and person components of the document. One important point on the impact of this on combining of authorization documents. THe common policy document talks about the computation of the value of a permission when it appears more than once based on data-type specific operations - MAX for integers, union for sets, OR for booleans. This works great under the assumption that each permission in the rule covers a non-overlapping part of the document; that is, for any part of the document you are interested in, its inclusion in the document is based on the value of a single permission in the rules. Thus, construction of the final document is fully spceified by the meaning of each permission and the generic combination rules. However, adding a means that the inclusion of a piece of data in the presence document, say the element, now depends on the value of two permissions - and . Thus, there needs to be a rule about combining those too, in a way that is consistent with the architectural principles of the common policy framework. In thise case at least, I think its relatively easy. A particular attribute is included if its specific rule (provide-foo) indicates that, OR if the is present. In essence, can almost be considered as a macro, expanding out into a sequence of for every foo in the document. Indeed, I think it probably makes sense to define it explicitly that way, so as it fits within the framework of the combining rules. That is, if you define it this way, then it is still the case that the final document is determined by the semantics of each permission along with the generic combining rules. You don't need to specify more combining rules specific to new permissions. That does have an interesting implication in your selection of an initial set of permissions. Ideally, you want those to be fairly fine grained, so that you could specify future permissions that affect the same data through a macro operation that expands into a series of these more fine-grained rules. Thanks, Jonathan R. Markus.Isomaki@nokia.com wrote: > Hi, > > Yes, I agree that there should be a shortcut for saying "give everything". I think both and would be useful. I suppose all attributes would mean also all "unknown" attributes. > > Markus > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Robert Sparks >>Sent: 15 January, 2005 16:10 >>To: Simple WG >>Subject: [Simple] presence-rules: providing all attributes >> >> >>I had an offline conversation with Jonathan about the minimum >>statement a presentity needs to make to say "give the matching >>subscriber everything in my presence document". Currently, >>that requires a pretty beefy transformation section for something >>that's likely to be a common policy to assert. >> >>We discussed adding a shorthand like >>inside each of person, service, device, or even a >>at the transformations level. >> >>Thoughts? >> >>RjS >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 21 10:28:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19751; Fri, 21 Jan 2005 10:28:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs0yU-0006pu-HG; Fri, 21 Jan 2005 10:45:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0Wd-00056D-8c; Fri, 21 Jan 2005 10:16:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0Tk-0003Hq-II for simple@megatron.ietf.org; Fri, 21 Jan 2005 10:13:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17784 for ; Fri, 21 Jan 2005 10:13:38 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs0je-0006If-5l for simple@ietf.org; Fri, 21 Jan 2005 10:30:06 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 21 Jan 2005 07:20:12 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0LFCml2011358; Fri, 21 Jan 2005 07:12:48 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOM69315; Fri, 21 Jan 2005 10:13:04 -0500 (EST) Message-ID: <41F11BFF.6080709@cisco.com> Date: Fri, 21 Jan 2005 10:13:03 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] PIDF "entity" attribute usage References: <1BEC4DA05ABCD34FACFCFC82086AC24704A0D3E1@RED-MSG-43.redmond.corp.microsoft.com> <41E6E9E5.2000305@cisco.com> <41F06F88.8090205@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: 7bit Cc: Tim Rang , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Content-Transfer-Encoding: 7bit inline. Jonathan Rosenberg wrote: > inline. > > Paul Kyzivat wrote: > >> >> >> Tim Rang wrote: >> >>> Paul, >>> >>> You had me until here- >>> >>> >>> So, at least in principle, when using SIMPLE, you can use either sip or >>> >>> pres URIs. However this assumes the specific implementation you are >>> using actually supports this. In practice you should determine what >>> the implementation you are using supports. >>> >>> >>> [Tim Rang] Can a SIMPLE implementation expect that all other SIMPLE >>> implementations support receiving the sip scheme in the entity >>> attribute? >> >> >> >> Probably not. I *think* a SIMPLE implementation must at least support >> receiving an entity attribute containing the URI used to subscribe for >> that presence. (And I suspect many will require that - don't recall if >> the specs require it.) >> >> So the bigger question is whether a SIMPLE implementation is able to >> *issue* a presence subscription to a { sip / pres } URI, and whether >> it is able to *accept* a presence subscription to a { sip / pres } URI. >> >> The issue of accepting doesn't seem like a big deal. The presence >> implementation is responsible for defining what URIs its presentities >> have, so a user should know what uri is supported to access that >> presentity. > > > I don't follow this. Lets consider watchers for a moment. There two > things for a watcher: > > 1. could it issue a SUBSCRIBE request to a pres: URI; appropriately > doing the DNS operations needed to resolve it to a SIP URI I just reviewed RFC3861 to refresh my memory. As I understand it, the domain name from the pres uri is used to select the address where the subscription will be sent, but that the request URI will remain unchanged, in pres: form, when it arrives at the server. > 2. if it receives a presence document in a notification, could it handle > an entity attribute that is a pres URI > > For the presence agent, there are a bunch of cases: > > 1. Could the PA receive a SUBSCRIBE request where the r-uri is a pres > URI, presumably equating it to presence data associated with a SIP URI? From above, this should be possible if suitable DNS entries have been made that reference this PA. > 2. Could the PA receive a presence document in a PUBLISH where one or > both of the r-uri and entity tags in the published document are pres URI? By same logic, it could receive a publish with r-uri being pres: In both of these cases, the operable question is not *could* it, but *should* it. I think I recall from the discussions leading up to 3861 that we concluded that no *normative* algorithmic relationship exists between pres: and sip: URIs. (I.e. even if both pres:foo@bar and sip:foo@bar exist, there is no reason to believe these identify the same presentity.) As a result, a watcher should not be using a pres: uri unless it knows this is valid. This could be because it was explicitly told to use it, or because it is aware of both a valid sip URI *and* a domain specific relationship between sip and pres URIs. (E.g. In the acme.com domain pres and sip URIs may be used interchangably to identify the same users.) The PA needs the same information. It needs to know what URIs may be used to reference the state of a particular presentity. There should be no surprises here. If a PA receives a request addressed to pres:foo@bar, and it has a def for sip:foo@bar but not pres:foo@bar, then it should be free to reject the request. Even if it does have a def for sip:foo.bar it shouldn't use it unless there is domain policy that says these should be equated. > These are complicated questions. I think we should place the burden on > the owner of the domain to really worry about correlation of these > identifiers. Beyond should. MUST. > That would argue for the following: > > 1. If a watcher genreates a SUBSCRIBE request with a pres URI in the > r-uri, and the presence agent is responsible for generation of the > presence document and can thus create one with either a pres or SIP URI > in the entity attribute, it MUST create one using the pres URI. Seems reasonable, *if* the PA believes there is a correspondence. > 2. If a watcher genreates a SUBSCRIBE request with a sip URI in the > r-uri, and the presence agent is responsible for generation of the > presence document and can thus create one with either a pres or SIP URI > in the entity attribute, it MUST create one using the sip URI. Again, seems reasonable, *if* the PA believes there is a correspondence. > 3. If the PA cannot genreate the document or otherwise modify its entity > attribute (for example if covered by an e2e signature), it MUST be > capable of receiving subscriptions to either the pres or SIP URI in the > request URI (thus be capable of equating the two URI) and thus return > whatever it has. *If* the PA believes there is a correspondence. > Rules (1) and (2) also operate under the principle of least surprise; I > should get documents where the entity attribute matches what I > subscribed to. It also means that a watcher which has never even heard > of a pres URI would never see a notification containing a document with > a pres URI in the entity attribute, unless e2e signatures prevents it. > > From a publishing perspective, I think the PA should support any of the > four combinations of pres/sip URI in the r-uri and entity attributes. *If* the PA believes there is a correspondence. The discomforting part of this is that I think it means that I could subscribe to presence of pres:alice@atlanta.com and receive a result where the entity attribute contains sip:bob@biloxy.com. While, based on the logic here this doesn't seem entirely unexpected, is there anything special the watcher should do in this case? Assuming it was alice that was in the buddy list, what should be in the buddylist display? Do we care? > Where does this discussion belong? Since it largely deals with the > construction of presence documents, I'd argue in the data model, but I'm > open to suggestions. Don't know. Paul > Thoughts? > > -Jonathan R. > > > > >> >> The ability to issue subscription requests to one kind or the other of >> uri is probably the big issue. If I tell you my presence URI is >> pres:paul@example.com but your presence client doesn't support pres >> URIs, then you are just out of luck. >> >> I personally don't see any particular value in pres URIs. If I want a >> SIMPLE presence client, it is probably in support of a SIP UA that >> will be doing voice or IM. Both of those require the use of sip URIs. >> If I have all the support for sip, then why not use it for presence >> too? The pres URI is just a 5th wheel. >> >> Paul >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 21 10:44:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20768; Fri, 21 Jan 2005 10:44:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs1DX-0007C7-ML; Fri, 21 Jan 2005 11:00:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0pR-0003ZS-JQ; Fri, 21 Jan 2005 10:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0jh-00024S-3k for simple@megatron.ietf.org; Fri, 21 Jan 2005 10:30:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19870 for ; Fri, 21 Jan 2005 10:30:07 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs0za-0006r5-Eq for simple@ietf.org; Fri, 21 Jan 2005 10:46:35 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0LFS4Yt027697; Fri, 21 Jan 2005 09:28:04 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j0LFS3h04926; Fri, 21 Jan 2005 09:28:03 -0600 (CST) Message-ID: <41F11F84.6000206@lucent.com> Date: Fri, 21 Jan 2005 09:28:04 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: multiple person elements, was: Re: [Simple] presence-rules: Selecting on class References: <41F06687.5010504@cisco.com> In-Reply-To: <41F06687.5010504@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I'll note that we never really concluded on the issue of multiple person > elements in a document. There did appear consensus (though I personally > still disagree) to support multiple person elements in a document in > order to represent conflicting data about a person. Jonathan: Let me back up one step. Multiple person elements can appear where -- in the raw presence document or the final presence document? I think in the final presence document, there should be only one person element. My preference would be to have a single person element even in the raw presence document, especially in the light of what you write below: > 2. what kind of meta-data do we need to provide the watcher the tools > they need to pick a particular source of data? If we go through the trouble of providing meta-data, might as well resolve the ambiguity and present one person element to the watcher. Conflicting data about a person, even if it appears in the system, should be for a short time (my computer at work reports me as being "Away" while my computer at home reports me as being "Available"). The frequency of presence state updates coming from my work computer would be far less than the frequency of state updates coming from devices that I am interacting with in my home. - 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-bounces@ietf.org Fri Jan 21 12:08:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27908; Fri, 21 Jan 2005 12:08:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2We-0001Px-VN; Fri, 21 Jan 2005 12:24:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs26P-0006HC-1S; Fri, 21 Jan 2005 11:57:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs22E-0005NY-6c for simple@megatron.ietf.org; Fri, 21 Jan 2005 11:53:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26706 for ; Fri, 21 Jan 2005 11:53:19 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2I8-0000zq-4V for simple@ietf.org; Fri, 21 Jan 2005 12:09:49 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 21 Jan 2005 12:00:43 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0LGqhoA008952; Fri, 21 Jan 2005 11:52:43 -0500 (EST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOM79169; Fri, 21 Jan 2005 11:52:45 -0500 (EST) Message-ID: <41F1335B.70205@cisco.com> Date: Fri, 21 Jan 2005 11:52:43 -0500 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: "Vijay K. Gurbani" Subject: Re: multiple person elements, was: Re: [Simple] presence-rules: Selecting on class References: <41F06687.5010504@cisco.com> <41F11F84.6000206@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Jonathan Rosenberg wrote: > >> I'll note that we never really concluded on the issue of multiple >> person elements in a document. There did appear consensus (though I >> personally still disagree) to support multiple person elements in a >> document in order to represent conflicting data about a person. You are heading down the slippery slope. We wanted to allow this because we want to allow use of a simple composition policy that doesn't know how to resolve the ambiguity, and so wants to leave it to watchers to resolve. That doesn't mean that smarter composition policies aren't desired. I think that is a slope we want to start down at some point. Just not yet. Paul > Jonathan: > > Let me back up one step. Multiple person elements can appear > where -- in the raw presence document or the final presence > document? I think in the final presence document, there should > be only one person element. My preference would be to have a > single person element even in the raw presence document, > especially in the light of what you write below: > > > 2. what kind of meta-data do we need to provide the watcher the tools > > they need to pick a particular source of data? > > If we go through the trouble of providing meta-data, might as > well resolve the ambiguity and present one person element to > the watcher. > > Conflicting data about a person, even if it appears in the > system, should be for a short time (my computer at work reports me > as being "Away" while my computer at home reports me as being > "Available"). The frequency of presence state updates coming from > my work computer would be far less than the frequency of state > updates coming from devices that I am interacting with in my home. > > - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 21 12:30:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29525; Fri, 21 Jan 2005 12:30:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2s5-000231-FX; Fri, 21 Jan 2005 12:46:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2VG-0005mN-1H; Fri, 21 Jan 2005 12:23:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2I4-0008Ko-HL for simple@megatron.ietf.org; Fri, 21 Jan 2005 12:09:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27982 for ; Fri, 21 Jan 2005 12:09:42 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2Xz-0001RR-ND for simple@ietf.org; Fri, 21 Jan 2005 12:26:12 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j0LH9BcH021277; Fri, 21 Jan 2005 11:09:11 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j0LH9Ah03951; Fri, 21 Jan 2005 11:09:10 -0600 (CST) Message-ID: <41F13737.3050009@lucent.com> Date: Fri, 21 Jan 2005 11:09:11 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: multiple person elements, was: Re: [Simple] presence-rules: Selecting on class References: <41F06687.5010504@cisco.com> <41F11F84.6000206@lucent.com> <41F1335B.70205@cisco.com> In-Reply-To: <41F1335B.70205@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > You are heading down the slippery slope. > > We wanted to allow this because we want to allow use of a simple > composition policy that doesn't know how to resolve the ambiguity, and > so wants to leave it to watchers to resolve. Paul: A composition policy, as its name suggests, should compose; i.e. take something abstract and make it more concrete. If it does not do so, then ambiguous data is propagated further into the system, gumming up even more machinery it touches. IMHO, a watcher would be content to do as less as possible; operational experience in SIP appears to suggest this. Forking, response aggregation and transport conversion are not the domain of proxies alone; SIP endpoints themselves can perform these. However, of all the many endpoints that I have used, not one of them did these things. Personally, I think the presence problem is complex enough without adding another layer (my head hurts as I try to make sense of all of this; but maybe it is just me). As Jonathan said, even if we did allow for multiple person elements, the model itself still revolves around one person. If so, why not just enforce that in the representation of the model? - 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-bounces@ietf.org Fri Jan 21 13:38:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04577; Fri, 21 Jan 2005 13:38:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs3vY-0003vm-0O; Fri, 21 Jan 2005 13:54:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs3Y9-0002ua-K2; Fri, 21 Jan 2005 13:30:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs3OA-00012y-Gx for simple@megatron.ietf.org; Fri, 21 Jan 2005 13:20:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03250 for ; Fri, 21 Jan 2005 13:20:03 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs3e3-0003OA-Vf for simple@ietf.org; Fri, 21 Jan 2005 13:36:34 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Jan 2005 10:24:32 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0LIJUNt027514; Fri, 21 Jan 2005 10:19:30 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOM87396; Fri, 21 Jan 2005 13:19:29 -0500 (EST) Message-ID: <41F147B1.908@cisco.com> Date: Fri, 21 Jan 2005 13:19:29 -0500 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: "Vijay K. Gurbani" Subject: Re: multiple person elements, was: Re: [Simple] presence-rules: Selecting on class References: <41F06687.5010504@cisco.com> <41F11F84.6000206@lucent.com> <41F1335B.70205@cisco.com> <41F13737.3050009@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Paul Kyzivat wrote: > >> You are heading down the slippery slope. >> >> We wanted to allow this because we want to allow use of a simple >> composition policy that doesn't know how to resolve the ambiguity, and >> so wants to leave it to watchers to resolve. > > > Paul: > > A composition policy, as its name suggests, should compose; i.e. > take something abstract and make it more concrete. I disagree with you about what compose means. Its not about going from abstract to concrete. Going from {W,X} + {Y,Z} to {W,X,Y,Z} is a perfectly valid kind of compostion that has no change in abstractness. And going from: {W=A, X=B} + {W=C, Z=D} to {X=B, Z=D} is another valid kind of composition that becomes more abstract (or at least less specific.) > If it does > not do so, then ambiguous data is propagated further into the > system, gumming up even more machinery it touches. Some of us believe that ambiguous data is preferable to wrong data or no data. > IMHO, a watcher would be content to do as less as possible; In some cases. And one solution to that would be for a watcher UA to simply not display ambiguous data. Then at least it is the watcher making that decision for its user. I think what you may really mean is that accurate data is better than a bunch of ambiguous data that might contain accurate data. To the extent that somebody knows how to draw the distinction, I agree. But if my boss' status says both "Out to Lunch" and "In a Meeting", then I think I may well have a better chance of deciding which is right than some stupid composer that hasn't been customized for his ideosyncracies. > operational experience in SIP appears to suggest this. Forking, > response aggregation and transport conversion are not the domain > of proxies alone; SIP endpoints themselves can perform these. > However, of all the many endpoints that I have used, not one > of them did these things. > > Personally, I think the presence problem is complex enough without > adding another layer (my head hurts as I try to make sense of > all of this; but maybe it is just me). As Jonathan said, even > if we did allow for multiple person elements, the model itself > still revolves around one person. If so, why not just enforce > that in the representation of the model? The layer is there already. It got there when we acknowledged there could be multiple sources of presence information. It is designing a composition algorithm that does the "right" thing with this information that makes my head hurt. This is one of those cases where something easy for people is really hard for a computer. I am pretty sure that it will be impossible to devise a compostion algorithm that does the "right" thing without a bunch of presentity-specific heuristics. I think such a thing can be designed and built. And probably used to great success by geeks like us. I have much less confidence that it can be built in such a way that those heuristics can be entered for all of the unwashed masses that use communications devices. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 21 14:14:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07157; Fri, 21 Jan 2005 14:14:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs4Uk-0004xv-6A; Fri, 21 Jan 2005 14:30:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs48f-0001tk-St; Fri, 21 Jan 2005 14:08:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs41K-00007l-UN for simple@megatron.ietf.org; Fri, 21 Jan 2005 14:00:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06226 for ; Fri, 21 Jan 2005 14:00:33 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs4HE-0004ZG-T4 for simple@ietf.org; Fri, 21 Jan 2005 14:17:03 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j0LIxxjW004811; Fri, 21 Jan 2005 12:59:59 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j0LIxwh25227; Fri, 21 Jan 2005 12:59:58 -0600 (CST) Message-ID: <41F1512E.3050109@lucent.com> Date: Fri, 21 Jan 2005 12:59:58 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: multiple person elements, was: Re: [Simple] presence-rules: Selecting on class References: <41F06687.5010504@cisco.com> <41F11F84.6000206@lucent.com> <41F1335B.70205@cisco.com> <41F13737.3050009@lucent.com> <41F147B1.908@cisco.com> In-Reply-To: <41F147B1.908@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > I disagree with you about what compose means. Its not about going from > abstract to concrete. Going from > > {W,X} + {Y,Z} to {W,X,Y,Z} > > is a perfectly valid kind of compostion that has no change in > abstractness. And going from: > > {W=A, X=B} + {W=C, Z=D} to {X=B, Z=D} I actually see this as good composition; in both your examples, we took _two_ sets and composed them into _one_ set -- a good start. We went from abstract to concrete. By allowing multiple person elements, we are essentially doing this to your example: {W, X} + {Y, Z} => {W, X} + {Y, Z} basically, nothing. > The layer is there already. It got there when we acknowledged there > could be multiple sources of presence information. In my email, the use of the word "layer" was not right; I intended to say that "the presence problem is complex enought without adding another potential source of ambiguity in the form of multiple person elements." > I am pretty sure that it will be impossible to devise a compostion > algorithm that does the "right" thing without a bunch of > presentity-specific heuristics. I think such a thing can be designed and > built. And probably used to great success by geeks like us. I have much > less confidence that it can be built in such a way that those heuristics > can be entered for all of the unwashed masses that use communications > devices. I am not sure what the right answer is, if there is one. Unlike you, though, I am not convinced that having the person element recur is advantageous. > Some of us believe that ambiguous data is preferable to wrong > data or no data. Ambiguous data is definitely preferable to no data; I am not sure about its preference over with "wrong" data. Both ambiguous and wrong data tend to condition the watcher into _not_ believing in the presence system. 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-bounces@ietf.org Fri Jan 21 21:11:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14995; Fri, 21 Jan 2005 21:11:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsB0m-0000yn-0h; Fri, 21 Jan 2005 21:28:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsAjV-0001DD-5P; Fri, 21 Jan 2005 21:10:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsAeh-0008Ov-My for simple@megatron.ietf.org; Fri, 21 Jan 2005 21:05:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14615 for ; Fri, 21 Jan 2005 21:05:37 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsAug-0000r2-Hd for simple@ietf.org; Fri, 21 Jan 2005 21:22:11 -0500 Received: from razor.cs.columbia.edu (IDENT:mh3KgYkPvCdCDDURk8JkFgGLX+ov3GaD@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0M25Wir029224 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 21 Jan 2005 21:05:33 -0500 (EST) Received: from [127.0.0.1] (IDENT:EVa0FzDouVE4EteLUmwuFOa+KnTN4Rvx@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0M25Wiw002770; Fri, 21 Jan 2005 21:05:32 -0500 Message-ID: <41F1B4F8.20801@cs.columbia.edu> Date: Fri, 21 Jan 2005 21:05:44 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: multiple person elements, was: Re: [Simple] presence-rules: Selecting on class References: <41F06687.5010504@cisco.com> <41F11F84.6000206@lucent.com> In-Reply-To: <41F11F84.6000206@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.21.7 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Vijay: we had this discussion, at length, in DC. The problem is that the composer is a program, with at best limited rule-based intelligence, while the watcher is often staffed with a real human being that can, in many cases, make sense of conflicting information based on external knowledge ("I know that Alice is on vacation right now, so the location information placing her at home in this person entry must be from the cell phone she left at home.") I'm afraid I don't trust AI enough to force the composer throw away useful information. There's also the issue that composition may be "staged", i.e., my provider has a dumb union-of-inputs composer provided by my cellphone carrier, which feeds a much smarter composer. Forcing the first composer to ditch information is a bad idea then as well. Meta-information is helpful, but not necessary, to make such decisions. The basic rule should be, I believe, "composers are allowed to be smart, but we can't force them to be". Henning Vijay K. Gurbani wrote: > Jonathan Rosenberg wrote: > >> I'll note that we never really concluded on the issue of multiple >> person elements in a document. There did appear consensus (though I >> personally still disagree) to support multiple person elements in a >> document in order to represent conflicting data about a person. > > > Jonathan: > > Let me back up one step. Multiple person elements can appear > where -- in the raw presence document or the final presence > document? I think in the final presence document, there should > be only one person element. My preference would be to have a > single person element even in the raw presence document, > especially in the light of what you write below: > > > 2. what kind of meta-data do we need to provide the watcher the tools > > they need to pick a particular source of data? > > If we go through the trouble of providing meta-data, might as > well resolve the ambiguity and present one person element to > the watcher. > > Conflicting data about a person, even if it appears in the > system, should be for a short time (my computer at work reports me > as being "Away" while my computer at home reports me as being > "Available"). The frequency of presence state updates coming from > my work computer would be far less than the frequency of state > updates coming from devices that I am interacting with in my home. > > - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jan 23 01:04:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07269; Sun, 23 Jan 2005 01:04:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Csb7K-0007nC-KY; Sun, 23 Jan 2005 01:20:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csan2-0005hO-Ol; Sun, 23 Jan 2005 01:00:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csajk-0005LE-QS for simple@megatron.ietf.org; Sun, 23 Jan 2005 00:56:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06734 for ; Sun, 23 Jan 2005 00:56:33 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Csazz-0007f1-8f for simple@ietf.org; Sun, 23 Jan 2005 01:13:23 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 22 Jan 2005 23:04:22 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0N5u3l2013638 for ; Sat, 22 Jan 2005 21:56:03 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-197.cisco.com [10.86.240.197]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHF33025; Sat, 22 Jan 2005 21:56:02 -0800 (PST) Message-ID: <41F33C72.2070306@cisco.com> Date: Sun, 23 Jan 2005 00:56:02 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: 7bit Subject: [Simple] another try at data model compromise regarding unique service URI X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: 7bit I'll be responding to various messages in the threads we had on the modeling dispatchers topic. However, I concluded a few things from my previous compromise proposal (adding an i-belong-to element): 1. there was general agreement that i-belong-to was reasonable, since more information can't hurt 2. even with i-belong-to, there still seemed to be a desire to support non-unique contact URIs, when in fact part of the reason I had proposed i-belong-to was to retain that feature of the data model 3. There was (perhaps) some dispute about whether we need to resolve the issue of unique contact URI or not for the data model. I believe we do. I agree with the approach of pushing off composition for another document, but the issue of how we name and identify a service, and how you can or cannot select those services from a presence document, is central to the data model and needs to be resolved one way or another. 4. I appear to be in the losing minority on the issue of unique URI or not. It appears Aki and Henning still favor allowing multiple tuples with the same contact URI. I believe Markus and Paul do as well, but am not as certain. 5. We've identified several real problems when you rely on things besides the URI to dispatch to the appropriate service: a. it doesnt work with an offerless invite, as in the case of 3pcc. Like it or not, this is a common case b. it doesnt work with cases where my initial SDP does not cause the appropriate dispatch, but a subsequent re-invite would. For example, I want to call your videophone, but I want to start with just audio so I can ask about adding video. 6. We agree to allow simple union-based composition. Henning has indicated that it is possible that the compositor doesn't understand the URI schemes in the contact. Thus, a union compositor might generate presence documents with two URI that are equal. Though I think this is quite unlikely, it is certainly possible. From these things, I concluded that (for reason 6 alone), the data model cannot outlaw two services from having the same URI. However, it begs the question of what does it *mean* when that happens. I think that we are not aligned on this yet. Henning made a statement in one of his notes that I believe captures the essence of the problem: Henning wrote: > There are the following possible cases, all with well-defined > behavior for the watcher: I don't think we want to specify the behavior of the watcher at all. They should be able to do anything they want to with the data. The key to interop is to make the semantics of the data as unambiguous as possible. I think that, in the case of multiple services with the same URI, the meaning is ambiguous, and depending on what a watcher is interested in, might make different choices. Let me give an example. Lets take an example Aki gave during the SIMPLE meeting in November. He was interested in expressing this situation: a user has a multimedia UA that can do audio and IM. They want to indicate that they are available for IM, but not for audio. Let us say that they represent this by including two services in a document (i.e., two tuples) with the same contact (their AOR), but one indicating audio with prescaps, and a basic status of closed, and the other indicating just IM with prescaps, and a a basic status of open. We have touched on several possible meanings for the case of two tuples/services with the same URI: MEANING 1 (CONFLICT): These represent conflicting information about the same service; one or the other might be true MEANING 2 (DISPATCH): These represent different services, but are only reachable by a dispatcher (using unknown dispatch logic), and so an INVITE sent to the (which is the AOR), will reach one or the other MEANING 3 (COMPONENT): These are one service, but the service has been disaggregated because of a desire to provide differing presence status for differing types of communication attempts (this is the meaning in the example) MEANING 4 (OVERRIDE): An attempt was made to override one service definition with another; however, the compositor foolishly placed them both in the document. As such, the more recent one is probably correct. I suspect that there are other meanings. So, let us consider the differing decisions a watcher might make, depending on which meaning it decides to attest to this document. Let us assume the watcher wishes to proceed with a multimedia call using as many media types as possible: MEANING 1 (CONFLICT): The watcher sends an INVITE with an offer including both audio and IM media streams, under the assumption that one or the other is supported and the presentity will reject one of the media streams MEANING 2 (DISPATCH): Since the service supporting IM is the only one available, the watcher wishes to avoid dispatching to the audio service. So, it sends an INVITE with only an IM media stream, hoping that the dispatch works correctly. MEANING 3 (COMPONENT): The watcher sends an INVITE with both audio and IM. It figures that perhaps the presentity will accept the audio stream anyway, and if not, just reject that stream and proceed with IM. MEANING 4 (OVERRIDE): The watcher sends an INVITE with whichever media type is indicated for the most recent tuple. As you can see, there is clearly a difference in watcher behavior, assuming a specific objective, depending on the semantics of multiple services with the same URI. So, in light of this, my specific proposal is that we allow for multiple services with the same URI, but in the data model very clearly define its meaning as *ambiguous*; additional tuple meta-data will normally need to be present to help clarify the actual meaning. As such, the data model would recommend against doing this without meta-data to further clarify. A watcher could NOT assume that constructing an INVITE compliant to the capabilities listed for a tuple would cause a dispatch to that tuple, as Aki has suggested. I think this is the kind of dangerous assumption that, as my examples above show, can be wrong depending on the actual meaning of this case. In the spirit of Robert's proposal, I would further propose not to pursue the extension yet. Let us further study composition and then figure out the right set of dispatcher characteristics we wish to model. At this time, we could then make the following recommendations regarding what a PUA places into the element. Namely, if it has a GRUU, it puts that. If it doesn't, but it has **strong** awareness that its local IP address and port have the GRUU property, it uses that, else it places the AOR. If there are multiple PUA for an AOR, and a compositor in the presence engine, we can consider four cases roughly speaking. We have PUA that support GRUU (or have a local contact that has the GRUU property), or don't, and we have a compositor that just does union, or is smarter and combines the contacts together: GRUU-less PUA, union compositor: This tends to do the right thing. The resulting presence document includes multiple tuples, each of which uses the AOR. The presentity is at least reachable since the AOR is listed. GRUU PUA, smart compositor: The compositor can combine together the tuples, since it knows the GRUUs are all bound to the same AOR. It can thus list a single tuple (if it likes), with the AOR as the GRUU PUA, union compositor: This produces a document that exposes the GRUU to the watcher. Still works fine, though it may not have been desireable to expose the GRUU to the watcher. GRUU-less PUA, smart compositor: The compositor can correlate the tuples together because they each use the AOR as the . However, because there is no GRUU, it can't as easily correlate each tuple with a registration that might exist for the UA that generated the PUBLISH. Such correlation would need to be supported through other tuple data. This is not ideal (the fourth case in particular), but it seems workable. Where does this leave us with override? I still feel strongly that it is a mistake to encode composition policy into the presence document itself. Therefore, the presence document is simply not the place to do anything special in support of override. In further support of Robert's proposal, since override is very much about composition, I propose that we simply defer this until we have properly defined policy documents for defining it. Can we move forward based on this? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jan 23 01:21:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07803; Sun, 23 Jan 2005 01:21:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsbNr-00080u-ID; Sun, 23 Jan 2005 01:38:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csb5d-0008O9-TI; Sun, 23 Jan 2005 01:19:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csb4H-000836-68 for simple@megatron.ietf.org; Sun, 23 Jan 2005 01:17:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07724 for ; Sun, 23 Jan 2005 01:17:48 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsbKV-0007xW-RJ for simple@ietf.org; Sun, 23 Jan 2005 01:34:36 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 22 Jan 2005 22:17:57 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0N6HE1M027785; Sat, 22 Jan 2005 22:17:15 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-197.cisco.com [10.86.240.197]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHF33216; Sat, 22 Jan 2005 22:17:13 -0800 (PST) Message-ID: <41F34169.7000800@cisco.com> Date: Sun, 23 Jan 2005 01:17:13 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Moving the presence data model work forward References: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> <41DF6EF2.2000705@cisco.com> <41E05975.6080308@cs.columbia.edu> In-Reply-To: <41E05975.6080308@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: 7bit Before you read this reply, please read my post just now proposing another potential point of compromise. More inline. Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> Let me try to explain better the root cause of my concern. The issue >> for me is that the meaning of the service tuple is that its a loose >> contract of sorts; it means that if you *select* this service, where >> selection involves invoking that URI, then the nature of the service >> you will receive is defined by the characteristics and status >> associated with that tuple. If you select a different tuple, you click >> on its URI, and you get something different. > > > This isn't quite true. Even if the URIs in services tuples are > different, you may well get exactly the same service, just reached by a > different identifier. Thus, there is no way that a watcher can rely on > the URI identity to know whether it will reach a different service. Fair enough. At least the watcher gets to make a choice. With multiple tuples with the same URI, it can't know what that means or determine what it needs to do to reach one or the other. > > Also, as we discussed in DC and on the list, a basic union composer will > have no way to ascertain, in general, whether two URIs might be the same > unless it is familiar with the URI scheme. I thought there was agreement > that we did not want to require the composer or PA to know the details > of the URI scheme. Yes, as such I do agree we cannot prevent two services from having the same URI. > > Furthermore, we discussed that there are URI schemes which have, today, > well-defined mechanisms to select content based on pieces of the request > beyond the URI. The HTTP content selection mechanism, widely available > in Apache, is one prominent example. > > http://embassy.fr (French version) > note: this is the french version > content-language: fr > http://embassy.fr (English version) > note: this is the english version > content-language: en Here is a great example of the dispatch idea I am talking about. In this particular instance, you REALLY want to explicitly tell the watcher what they need to do in order to reach the french as opposed to the english version. I do not think that prescaps is the right way to do that. Prescaps indicates capabilities of the UA that is reached through the URI. That is NOT the same as saying, "if you formulate your request in this way, it will be dispatched to this service". I would much rather model this explicitly with some kind of information that tells the watcher exactly what it needs to do. That is what you are, in fact, doing above: you're telling the watcher to use content-language of english vs. french to reach the two different services. > >> >> Furthermore, a service tuple is actually something concrete - its a >> software or hardware agent that is listening for requests at that URI, >> and the characteristics and status within the tuple represent the >> whole of its characteristics and status. Its OK if that agent is >> distributed across several components (i.e, a forking proxy and >> several UAs) - the service represents the union of the service they >> provide. >> >> Thus, my beef with having two services with the same URI is that it >> means this contract is no longer meaningful. Indeed, the watcher can >> no longer select a service tuple at all; to reach the service >> indicated in a tuple they'll have to not only invoke the URI, they'll >> need to somehow construct a request which they hope is routed to that >> service, possibly based on creating one matching the capabilities >> listed by this service. >> >> This introduces a lot of ambiguity, and in particular, it really >> wrecks the ability of the watcher to ->choose<-. The PDM spends some >> time talking about why watcher choice is one of the key reasons why >> there are multiple services to begin with. If there are multiple >> service tuples but there isn't choice, then it becomes entirely >> unclear why you have multiple tuples - is it a way to express >> complicated capabilities? Should a watcher render a union of the >> capabilities as one choice to select to call? Is this about >> conflicting information? In other words, a service tuple is no longer >> anything concrete at all; its just a bit of information about the >> service and thus unclear how it relates to other bits about the same >> service. >> >> In my mind, the whole semantic that the PDM is advocating falls apart. >> That is why I find it is anathema to what the PDM is trying to do. >> >> I am fine if we don't try to support override initially. I am fine if >> we have a really simple composition policy documented initially. I am >> even fine to use an opaque token as a tuple ID. I am not fine if we >> return to what I view as the root problem we had all along - the lack >> of a clear meaning to multiple tuples in a document, and I believe >> using the same URI for multiple tuples has that effect. > > > I don't see that forcing the PA to merge or reject or override same-URI > tuples either increases the descriptiveness or, conversely, that not > enforcing this in any way decreases it. You keep asserting that this > would get us back into the wild woods of anything goes, but provide no > evidence for this. I hope I've given a concrete example in my other note. Without additional information to provide guidance on what this means (which of the four cases applies, and if its a dispatch case, how the dispatch works), things are ambiguous. > > In general, there are two cases from a watcher perspective: > > - The service description is meaningful beyond the URI. Well, thats the rub. We have no way at this time of expressing clear ways to make this meaningful. > > - There is no meaningful service description (since, for example, the > service description contains information not understood by the watcher). > > A URI scheme itself provides almost no service information beyond the > mechanics of contacting it, so an enumeration of different URIs without > description isn't any more meaningful than a list of the same URIs. > > URI1 > (some service description 1, D1) > > URI2 > (some service description 2, D2) > > > There are the following possible cases, all with well-defined behavior > for the watcher: Per my other note, I don't think there is such a thing as "well-defined behavior for the watcher". Watcher behavior should never be specified. Rather, we need to have well specified meaning of the presence data. > > URI1 == URI2, D1 == D2 > presumably a mistake, but harmless duplication; watcher drops duplicate > > URI1 == URI2, D1 != D2 > if the watcher knows how to use D1 and D2 to qualify the request to > URI1/2, it does so; This is the "and magic happens" bit that I am nervous about. I think that the meaning of the above two cases cannot be described in the data model in any way but "ambiguous", and it is a mistake to recommend any kind of watcher behavior. We can leave the door open to make this less magical and more explicit, but with everything on the table today (RPID, prescaps, cipid, etc.) it remains ambiguous. > otherwise, the two tuples are the same as far as the > watcher is concerned and the watcher drops one or the other (or > indicates that the watcher might get D1 or D2, based on the luck of the > draw and the mood of the proxy). This is logically no different than > saying "This URI might give you either A or B, but I can't tell you > ahead of time what you'll get", i.e., common behavior for any proxied > SIP URI today. > > URI1 != URI2, D1 == D2 > somewhat confusing to the watcher, but no worse than the common habit > of having a list of phone numbers on a business card, with no > differentiation by function. Not a problem affected by this discussion. > > URI1 != URI2, D1 != D2 > common case; no problem > > > It is then up to the elements contributing to the presence information > to choose the URIs and descriptions that are most likely to work. That's > an operational decision and allows service upgrades without upgrading > the composer or PA, over which I have no control. > > Thus, the meaning and algorithm are well defined *for the watcher*. We > should probably describe this in a bit more detail. > > My concern is that once we "outlaw" equality in URIs, that we lose the > ability to describe and handle such scenarios and require composers that > need to deal with such cases, without having the means to do so in a > predictable and information-conserving manner, given the simple-union > requirement. I still believe URI remains the best way to dispatch, but per my other note, I concede this point that there may be other ways to dispatch downstream, and if people agree to my proposal, I will allow this in the data model. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jan 23 01:35:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08388; Sun, 23 Jan 2005 01:35:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Csbbh-0008C6-Da; Sun, 23 Jan 2005 01:52:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsbKn-0001jS-7f; Sun, 23 Jan 2005 01:34:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsbGw-0001KQ-Ly for simple@megatron.ietf.org; Sun, 23 Jan 2005 01:30:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08113 for ; Sun, 23 Jan 2005 01:30:53 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsbXB-00087D-Pn for simple@ietf.org; Sun, 23 Jan 2005 01:47:42 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 22 Jan 2005 23:38:41 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0N6UKNt022638; Sat, 22 Jan 2005 22:30:20 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-197.cisco.com [10.86.240.197]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHF33479; Sat, 22 Jan 2005 22:30:18 -0800 (PST) Message-ID: <41F3447A.9050606@cisco.com> Date: Sun, 23 Jan 2005 01:30:18 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hisham Khartabil Subject: composition and authorization interactions, was: Re: [Simple] Moving the presence data model work forward References: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> <41DF6EF2.2000705@cisco.com> <7FA467F9-624D-11D9-91E0-000D93C60BA0@telio.no> In-Reply-To: <7FA467F9-624D-11D9-91E0-000D93C60BA0@telio.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit I'm not going to bother responding to most of the responses in here; hopefully they are addressed by my note this evening with another compromise proposal. I did want to address one other point that is quite important (and thus the change in subject lines): Hisham Khartabil wrote: > >> >> That split would allow us, once we address this issue of unique URI, >> to move forward with RPID and the various presence document >> extensions. However, I believe that the authorization policy work >> depends on the modeling in section 7, and would still be blocked on us >> at least understanding the specific way in which authorization policy >> takes place within the context of presence server processing. > > > We don't want to block RPID and the various document extensions. If that > is true, then this whole conversation is mute. Can you elaborate on why > this unique URI issue is blocking this work and the authorisation policy > work? One of the concerns is that unless we more clearly define the logical sequence of operations executed by a presence server (figure 4 in the data model), different servers will execute the authorization policy in different places and in different ways, leading to inconsistent behaviors and thus interop problems. For example, I recall that, during the November meeting, someone said they thought that privacy policy would get applied prior to composition, not after. The order in which these are done will greatly impact the final presence document. One way out of this conundrum might be to specify just a piece of this processing logic in the authorization policy spec itself. A few things we could possibly say: 1. A presence server MUST apply the privacy filtering operation as the final step in its processing. Whatever document it would otherwise send in the absence of privacy policy, it must take that document as input, apply privacy processing, and then the resulting document is what gets sent. The subscription processing aspects of the document get applied by the server when it decides to accept or reject the subscription. 2. This specification does not mandate at what point in the processing of presence data the privacy filtering aspects of the authorization policy are applied. However, they must be applied such that the final presence document sent to the watcher is compliant to the privacy policy described in the document. More concretely, if the document sent to a watcher is D, and the privacy filtering operation applied do a presence document is F(x), then D MUST have the property that D = F(D). The subscription processing aspects of the document get applied by the server when it decides to accept or reject the subscription. I tend to favor something like (2) since it leaves the door most open for a more specific set of definitions on presence server processing for downstream. We could do any kind of alternate flowchart (figure 4 in the model) so long as it results in the property described. Does that work for folks? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jan 23 01:45:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08745; Sun, 23 Jan 2005 01:45:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Csbkq-0008LJ-Ec; Sun, 23 Jan 2005 02:01:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsbSg-0002TW-6i; Sun, 23 Jan 2005 01:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsbQk-0002CJ-0k for simple@megatron.ietf.org; Sun, 23 Jan 2005 01:41:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08574 for ; Sun, 23 Jan 2005 01:41:01 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Csbgy-0008Fq-T0 for simple@ietf.org; Sun, 23 Jan 2005 01:57:49 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 22 Jan 2005 22:41:10 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0N6eS1M000602; Sat, 22 Jan 2005 22:40:28 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-197.cisco.com [10.86.240.197]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHF33563; Sat, 22 Jan 2005 22:40:26 -0800 (PST) Message-ID: <41F346D9.8020108@cisco.com> Date: Sun, 23 Jan 2005 01:40:25 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward References: <41B60EAD.5090504@cisco.com> <41C2997D.9010800@nokia.com> <41DF7495.70204@cisco.com> <41E3D1E3.90702@nokia.com> <41E3F0EE.7020805@cisco.com> <41E83C3E.8060508@nokia.com> In-Reply-To: <41E83C3E.8060508@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Content-Transfer-Encoding: 7bit Cc: ext Paul Kyzivat , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Content-Transfer-Encoding: 7bit Please read my note that I sent this evening with another potential compromise position before reading my response below. inline. Aki Niemi wrote: > Inline. > > ext Paul Kyzivat wrote: > > > >>>> It could do that but it need not; the benefit of a URI and its >>>> definitional characteristic is that you need no other context beyond >>>> the URI to use it. I should be able to make a SIP call to that URI >>>> without having seen the presence document at all, and it works to >>>> the degree that SIP itself would allow the call to proceed. Presence >>>> might help optimize by allowing me to select media streams that work >>>> out of the box, for example, but its an optimization not a >>>> requirment for contacting the URI. If it is, the URI becomes >>>> meaningless. >> >> >> Here I agree with Jonathan. Elsewhere I pointed out the 3PCC offerless >> invite case. But there are other cases as well. Consider the case >> where you have two tuples containing the same AoR. One is just voice. >> The other is voice+video. Because I have a video phone, and anticipate >> using the video, I choose to call your tuple that has video. But I >> start out with my video disabled because I'm polite and want to ask >> before using it. So my initial invite only contains audio. (If/when I >> turn on video a reinvite will add the video stream.) >> >> But your proxy, thinking itself clever, looks at my offer and decides >> to send it to your audio phone. Now when I try to add video (which I >> think I should expect because your tuple advertised it), the attempt >> fails because you have no video. Yuck! >> >>> I agree, but you sound like you would be in favor of AoR contact over >>> a GRUU contact here. After all, a GRUU really needs a context to be >>> all that useful. >> >> >> >> What is your point? Is this "context" needed in the caller or callee? > > > Both. > >> If you mean the callee, then yes, it is possible for gruu to be used >> in a way where the grid parameter indexes context stored in the >> callee, with the gruu useless once that context has been forgotten. >> But that isn't always the case. In some cases all that is necessary is >> that the gruu route to the right UA, with no added context necessary >> at the receiving end. (The grid parameter may be irrelevant.) In other >> cases the context needed at the receiving end may be encoded into the >> grid parameter. >> >> If you mean the caller needs context, then isn't that the caller's >> problem? In the situation at hand the caller *has* context: the >> presentity and all the contents of the selected tuple. >> >>> Without one, e.g., going through my call-logs from last month, there >>> is no guarantee that a GRUU used then would work any more, or indeed >>> work for any other session than the one made back then. >> >> >> >> I recall you brought up this point in private discussion, and I have >> been thinking about it. It is an interesting problem, but one that is >> in no way restricted to presence based calling. It is relevant to many >> uses of GRUU. >> >> In all cases I think the caller has context other than the gruu. We >> may need to find a way to incorporate that into the call so that it >> may be incorporated in call logs. >> >> Another possibility is that we might consider defining an encoding of >> gruus that explicitly exposes the related AoR. This would have to be >> optional, for cases when that info is not intended to be public, but >> in many cases it is not secret information. > > > Yes, this is something I've also thought about. It might be a good idea > to have the presentity include as contact a URI that adds some "magic" > token into the request. Now while the end result is similar to a GRUU, > the mechanism would be different. So you want something with all of the same properties as gruu, but isn't the current mechanism? Sounds like you have a beef with GRUU. I'd like to understand what it is, and ask that you please bring it up on the sip list. > >>> AoR has that property in a sense that it can be expected to work >>> independent of time, place and type of session. >> >> >> >> Remember that the original motivation for gruu was to ensure that >> transfers get to the right UA. That is still an important property. >> The use of AoR didn't work for that. The problem with call logs is >> going to exist in that scenario too. >> >> Also, I don't understand how you are going to solve the whole range of >> problems that gruus address without using gruus. Are you simply >> counting on there only being a single UAS per AoR in your environment? > > > Perhaps I'm not making myself clear. I'm not against putting GRUUs in > presence documents ever (or using them elsewhere). I'm against making > this a *mandatory* thing, and basing composer behavior on assuming > gruuness across the presence documents. There is a big difference. Per my other proposal, if folks agree, the data model will allow this, but you really want to be explicit on how the watcher is making a choice if its not by URI selection. Otherwise, the meaning of the document is ambiguous. > >>> Also, there are always (at least) two participants in a call and both >>> have their preference over which media to use. Surely the watcher >>> also has a say in what sort of media to commit to. This may not be >>> that evident in todays UAs that predominantly offer voice-only. >> >> >> >> How is this relevant? The watcher will be looking at the tuples to >> find ones that are consistent in capabilities (including media) that >> it can deal with. > > > Yes, and (usually) constructs a request that is aligned with those > capabilities. It won't be a simple "clicking the link", as is somehow > been suggested. We also have things like caller preferences to make > these choices affect the routing of a call. This is a big, big assumption. It is one I am loathe to hard code into the data model, since I do not want to ever specify watcher behavior. If you want to tell the watcher that it needs to do something besides clicking on a link (like using caller prefs or setting its SDP in some way), then PLEASE let us be explicit about it! > >>>>> I believe the invoking of a service MUST work using an AoR. If an >>>>> INVITE offering voice ends up served by a chess application, I >>>>> think the system is utterly broken, and needs to be fixed. >>>> >>>> >>>> >>>> This is contradictory. You are saying that two services that are >>>> different have to be able to have the same AoR, but if you have the >>>> same AOR, how can you guarantee that an INVITE to that AOR is >>>> properly dispatched to the right app depending on where it came from? >>> >>> >>> >>> Aren't you forgetting something here, namely an SDP offer that >>> (usually [1]) goes along with the INVITE? To me this sounds like we >>> have systems where dispatching can only work based on Request URI. >>> But surely you can dispatch using a plethora of other handles, such >>> as Require-tokens, SDP parameters and Subject-headers, to name a few. >> >> >> >> I believe there are problems to be worked out before e2e encryption >> can work in the presence of forking. But in theory the contents of the >> SDP body might not be available to the proxy. Building a system that >> depends on routing that way will rule out support for e2e security. > > > Proxy /= dispatcher, I've never said that. A dispatcher is an element > that handles "routing" way after the messages have been decrypted. That is one type of dispatcher. I think a proxy is reasonably described as a dispatcher as well. I am starting to believe that there is definitely some merit in a more comprehensive description of a generic dispatcher concept in the data model. It would allow us to cover several cases: 1. a proxy with any kind of routing logic 2. code in the UA that dispatches to "helpers" 3. getting different versions of some content based on the content-language header (hennings example) The key to all of these working is to allow the dispatcher information in the document to explicitly tell the watcher how the dispatch is done. If you do that, I dont think it matters much whether the dispatcher is actually a proxy, code in a UA, or whatever. > >>> I don't like the idea of making the SDP be a static description of >>> all media available to the wathcer, and base service dispatch >>> (whether done locally at the client or by a proxy) on information >>> "encoded" in the GRUU. This seems to be the direction were heading here. >> >> >> >> I'm not sure of your point here. When making an offer, the offerer >> should offer whatever media it desires to use at that time. This need >> not include every medium that could be used later in the call, or on >> some other call. > > > Then we agree. I do not think we should specify that the watcher should have to adjust its offer in any way just because the prescaps in the document says a capability is there or not. If dispatch is taking place based on some information in the document, we should state it explicitly in the document. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jan 23 03:01:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27220; Sun, 23 Jan 2005 03:01:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cscwn-00013n-Jf; Sun, 23 Jan 2005 03:18:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CscfF-0001WL-FD; Sun, 23 Jan 2005 03:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsceW-0001QF-QQ for simple@megatron.ietf.org; Sun, 23 Jan 2005 02:59:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27159 for ; Sun, 23 Jan 2005 02:59:19 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cscul-00011f-N9 for simple@ietf.org; Sun, 23 Jan 2005 03:16:08 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0N7wcjC029062; Sun, 23 Jan 2005 01:58:39 -0600 (CST) Received: from lucent.com (vkg.lra.lucent.com [135.255.29.136]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j0N7wb214570; Sun, 23 Jan 2005 01:58:37 -0600 (CST) Message-ID: <41F3592D.90208@lucent.com> Date: Sun, 23 Jan 2005 01:58:37 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: multiple person elements, was: Re: [Simple] presence-rules: Selecting on class References: <41F06687.5010504@cisco.com> <41F11F84.6000206@lucent.com> <41F1B4F8.20801@cs.columbia.edu> In-Reply-To: <41F1B4F8.20801@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Vijay: > > we had this discussion, at length, in DC. The problem is that the > composer is a program, with at best limited rule-based intelligence, > while the watcher is often staffed with a real human being that can, in Prof. Schulzrinne: Thanks. I was just seeing if there is any wiggle room left, but since this is a closed issue, I will shut up now. I will like to request though, if possible, that the reason why we are allowing multiple person elements be explained in the draft. Often times, it helps if the reader (or developer) of a protocol knows why decisions were made in a certain manner. Sincerely, - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jan 23 12:40:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27129; Sun, 23 Jan 2005 12:40:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CslzK-00071D-Js; Sun, 23 Jan 2005 12:57:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csli4-0004La-S1; Sun, 23 Jan 2005 12:39:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CslcU-0003rL-VG for simple@megatron.ietf.org; Sun, 23 Jan 2005 12:33:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26859 for ; Sun, 23 Jan 2005 12:33:48 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cslsq-0006tf-1J for simple@ietf.org; Sun, 23 Jan 2005 12:50:44 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 23 Jan 2005 12:33:19 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0NHXGW0029088; Sun, 23 Jan 2005 12:33:16 -0500 (EST) Received: from cisco.com (che-vpn-cluster-2-152.cisco.com [10.86.242.152]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AON54117; Sun, 23 Jan 2005 12:33:15 -0500 (EST) Message-ID: <41F3DFDB.4070303@cisco.com> Date: Sun, 23 Jan 2005 12:33:15 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: composition and authorization interactions, was: Re: [Simple] Moving the presence data model work forward References: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> <41DF6EF2.2000705@cisco.com> <7FA467F9-624D-11D9-91E0-000D93C60BA0@telio.no> <41F3447A.9050606@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > One of the concerns is that unless we more clearly define the logical > sequence of operations executed by a presence server (figure 4 in the > data model), different servers will execute the authorization policy in > different places and in different ways, leading to inconsistent > behaviors and thus interop problems. > > For example, I recall that, during the November meeting, someone said > they thought that privacy policy would get applied prior to composition, > not after. The order in which these are done will greatly impact the > final presence document. > > One way out of this conundrum might be to specify just a piece of this > processing logic in the authorization policy spec itself. A few things > we could possibly say: > > 1. A presence server MUST apply the privacy filtering operation as the > final step in its processing. Whatever document it would otherwise send > in the absence of privacy policy, it must take that document as input, > apply privacy processing, and then the resulting document is what gets > sent. The subscription processing aspects of the document get applied by > the server when it decides to accept or reject the subscription. > > 2. This specification does not mandate at what point in the processing > of presence data the privacy filtering aspects of the authorization > policy are applied. However, they must be applied such that the final > presence document sent to the watcher is compliant to the privacy policy > described in the document. More concretely, if the document sent to a > watcher is D, and the privacy filtering operation applied do a presence > document is F(x), then D MUST have the property that D = F(D). The > subscription processing aspects of the document get applied by the > server when it decides to accept or reject the subscription. > > I tend to favor something like (2) since it leaves the door most open > for a more specific set of definitions on presence server processing for > downstream. We could do any kind of alternate flowchart (figure 4 in the > model) so long as it results in the property described. > > Does that work for folks? Works for me. There is an implication here around privacy filtering in general - of idempotence: F(F(X)) = F(X), for all X This isn't especially remarkable, but something to keep in mind. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jan 23 13:56:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01102; Sun, 23 Jan 2005 13:56:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsnAZ-0008QP-0u; Sun, 23 Jan 2005 14:13:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csmt9-00047B-2W; Sun, 23 Jan 2005 13:55:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csmrj-0003xy-FM for simple@megatron.ietf.org; Sun, 23 Jan 2005 13:53:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01010 for ; Sun, 23 Jan 2005 13:53:38 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Csn84-0008OF-UN for simple@ietf.org; Sun, 23 Jan 2005 14:10:33 -0500 Received: from razor.cs.columbia.edu (IDENT:RSWgWs7ZbGQY5rSJIYjAMB0WZWnjfn48@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0NIrUir029564 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 23 Jan 2005 13:53:31 -0500 (EST) Received: from [127.0.0.1] (IDENT:ofw9iwL9we/UTwkBRuxOUKEK2qxjZ7N6@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0NIrTiw005419; Sun, 23 Jan 2005 13:53:30 -0500 Message-ID: <41F3F2B6.1020309@cs.columbia.edu> Date: Sun, 23 Jan 2005 13:53:42 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] another try at data model compromise regarding unique service URI References: <41F33C72.2070306@cisco.com> In-Reply-To: <41F33C72.2070306@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.23.4 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > 5. We've identified several real problems when you rely on things > besides the URI to dispatch to the appropriate service: > > > a. it doesnt work with an offerless invite, as in the case of 3pcc. > Like it or not, this is a common case This assumes that SDP is used for service selection. This is not a problem if caller preferences or similar mechanisms that do not involve offer-answer are used (e.g., request routing based on MESSAGE vs. INVITE). > > b. it doesnt work with cases where my initial SDP does not cause the > appropriate dispatch, but a subsequent re-invite would. For example, I > want to call your videophone, but I want to start with just audio so I > can ask about adding video. This is either solved by caller preferences or kin, or is a generic problem that even presence can't solve (if I initially select audio-only capabilities). This has little to do with URIs. > From these things, I concluded that (for reason 6 alone), the data model > cannot outlaw two services from having the same URI. However, it begs > the question of what does it *mean* when that happens. I think that we > are not aligned on this yet. Henning made a statement in one of his > notes that I believe captures the essence of the problem: > > Henning wrote: > >> There are the following possible cases, all with well-defined >> behavior for the watcher: > > > I don't think we want to specify the behavior of the watcher at all. I think we're not that far apart. The meaning to the watcher has to be clear - even if that meaning has a "cannot say reliably whether A or B is true". > As you can see, there is clearly a difference in watcher behavior, > assuming a specific objective, depending on the semantics of multiple > services with the same URI. > > So, in light of this, my specific proposal is that we allow for multiple > services with the same URI, but in the data model very clearly define > its meaning as *ambiguous*; additional tuple meta-data will normally > need to be present to help clarify the actual meaning. As such, the data > model would recommend against doing this without meta-data to further > clarify. A watcher could NOT assume that constructing an INVITE > compliant to the capabilities listed for a tuple would cause a dispatch > to that tuple, as Aki has suggested. I think this is the kind of > dangerous assumption that, as my examples above show, can be wrong > depending on the actual meaning of this case. > > In the spirit of Robert's proposal, I would further propose not to > pursue the extension yet. Let us further study composition > and then figure out the right set of dispatcher characteristics we wish > to model. With the GRUU discussion and suggestions ("should generally identify AOR it belong to") by Paul, this may also not be necessary in a subset of cases. > > At this time, we could then make the following recommendations regarding > what a PUA places into the element. Namely, if it has a GRUU, > it puts that. If it doesn't, but it has **strong** awareness that its > local IP address and port have the GRUU property, it uses that, else it > places the AOR. > > If there are multiple PUA for an AOR, and a compositor in the presence > engine, we can consider four cases roughly speaking. We have PUA that > support GRUU (or have a local contact that has the GRUU property), or > don't, and we have a compositor that just does union, or is smarter and > combines the contacts together: > > GRUU-less PUA, union compositor: This tends to do the right thing. The > resulting presence document includes multiple tuples, each of which uses > the AOR. The presentity is at least reachable since the AOR is listed. > > GRUU PUA, smart compositor: The compositor can combine together the > tuples, since it knows the GRUUs are all bound to the same AOR. It can > thus list a single tuple (if it likes), with the AOR as the > > GRUU PUA, union compositor: This produces a document that exposes the > GRUU to the watcher. Still works fine, though it may not have been > desireable to expose the GRUU to the watcher. > > GRUU-less PUA, smart compositor: The compositor can correlate the tuples > together because they each use the AOR as the . However, > because there is no GRUU, it can't as easily correlate each tuple with a > registration that might exist for the UA that generated the PUBLISH. > Such correlation would need to be supported through other tuple data. > > > This is not ideal (the fourth case in particular), but it seems workable. > > Where does this leave us with override? I still feel strongly that it is > a mistake to encode composition policy into the presence document > itself. Therefore, the presence document is simply not the place to do > anything special in support of override. In further support of Robert's > proposal, since override is very much about composition, I propose that > we simply defer this until we have properly defined policy documents for > defining it. > > Can we move forward based on this? Yes, this seems straightforward. > > Thanks, > Jonathan R. > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jan 23 16:24:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10877; Sun, 23 Jan 2005 16:24:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CspTq-00031W-6x; Sun, 23 Jan 2005 16:41:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CspCK-0000oB-7K; Sun, 23 Jan 2005 16:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CspAk-0008TV-Ut for simple@megatron.ietf.org; Sun, 23 Jan 2005 16:21:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10712 for ; Sun, 23 Jan 2005 16:21:24 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CspR8-0002x3-04 for simple@ietf.org; Sun, 23 Jan 2005 16:38:22 -0500 Received: from razor.cs.columbia.edu (IDENT:q1/XhVXqCzF4tDGG/l7qA2eFH4drgJuS@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0NLLMir001835 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 23 Jan 2005 16:21:22 -0500 (EST) Received: from [127.0.0.1] (IDENT:CN2I/99yDgJkNInlM+L/3yEVgiARAn6U@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0NLLKiw006051; Sun, 23 Jan 2005 16:21:21 -0500 Message-ID: <41F41572.3020000@cs.columbia.edu> Date: Sun, 23 Jan 2005 16:21:54 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: composition and authorization interactions, was: Re: [Simple] Moving the presence data model work forward References: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> <41DF6EF2.2000705@cisco.com> <7FA467F9-624D-11D9-91E0-000D93C60BA0@telio.no> <41F3447A.9050606@cisco.com> In-Reply-To: <41F3447A.9050606@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.23.5 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > 1. A presence server MUST apply the privacy filtering operation as the > final step in its processing. Whatever document it would otherwise send > in the absence of privacy policy, it must take that document as input, > apply privacy processing, and then the resulting document is what gets > sent. The subscription processing aspects of the document get applied by > the server when it decides to accept or reject the subscription. > > 2. This specification does not mandate at what point in the processing > of presence data the privacy filtering aspects of the authorization > policy are applied. However, they must be applied such that the final > presence document sent to the watcher is compliant to the privacy policy > described in the document. More concretely, if the document sent to a > watcher is D, and the privacy filtering operation applied do a presence > document is F(x), then D MUST have the property that D = F(D). The > subscription processing aspects of the document get applied by the > server when it decides to accept or reject the subscription. > > > I tend to favor something like (2) since it leaves the door most open > for a more specific set of definitions on presence server processing for > downstream. We could do any kind of alternate flowchart (figure 4 in the > model) so long as it results in the property described. I think this works as long as the composition policy does not add any information, e.g., from non-presence sources. One could argue that even the ideas of likelihood filtering discussed for smart composers, i.e., ditching contradictory elements and retaining the most likely one, add information, at least in an information-theoretic sense. Otherwise, [privacy] | [composition] and [composition] | [privacy] might not be equivalent. I think your D = F(D) is similar (it essentially says that applying F() again wouldn't change the result). My concern is that we have a trade-off, namely that by not specifying the order, we constrain what composition policies can do. Given that we haven't really agreed, even at a fairly high level, what composition can do, it seems less harmful to constrain the ordering of operations to be safe. I see very little additional implementation benefit in leaving the order open. Clearly publish - privacy - compose - privacy is also ok and maybe we can simply also allow the double application of privacy policies. The advantage of the latter model is that the composer doesn't get burdened trying to reconcile information that the privacy policy would have ditched in any event. Note, however, that the latter model makes the composing operation inherently be watcher-specific, which is a large change. > > Does that work for folks? > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jan 23 16:33:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11547; Sun, 23 Jan 2005 16:33:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CspcZ-0003Do-9F; Sun, 23 Jan 2005 16:50:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CspLA-0002po-Cr; Sun, 23 Jan 2005 16:32:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CspKp-0002kR-PM for simple@megatron.ietf.org; Sun, 23 Jan 2005 16:31:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11453 for ; Sun, 23 Jan 2005 16:31:49 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CspbC-0003CQ-V3 for simple@ietf.org; Sun, 23 Jan 2005 16:48:47 -0500 Received: from razor.cs.columbia.edu (IDENT:WgjlJXhHVxIoMkBAso1km2dyx5PoDf0c@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0NLVlir004331 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 23 Jan 2005 16:31:48 -0500 (EST) Received: from [127.0.0.1] (IDENT:qBTia/dHghYtERqXQlwEWs70unKCj/G6@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0NLVkiw006121; Sun, 23 Jan 2005 16:31:46 -0500 Message-ID: <41F417E5.3060302@cs.columbia.edu> Date: Sun, 23 Jan 2005 16:32:21 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Moving the presence data model work forward References: <7C1C86B7-6067-11D9-AA3E-000D93326732@nostrum.com> <41DF6EF2.2000705@cisco.com> <41E05975.6080308@cs.columbia.edu> <41F34169.7000800@cisco.com> In-Reply-To: <41F34169.7000800@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.23.5 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Here is a great example of the dispatch idea I am talking about. In this > particular instance, you REALLY want to explicitly tell the watcher what > they need to do in order to reach the french as opposed to the english > version. I do not think that prescaps is the right way to do that. > Prescaps indicates capabilities of the UA that is reached through the > URI. That is NOT the same as saying, "if you formulate your > request in this way, it will be dispatched to this service". I would > much rather model this explicitly with some kind of information that > tells the watcher exactly what it needs to do. That is what you are, in > fact, doing above: you're telling the watcher to use content-language of > english vs. french to reach the two different services. > General agreement. Since this is fairly abstract, I'm not, in general, convinced that there needs to be more mark-up than, say, Content-* or prescaps, as the information in the presence element translates exactly into request modification instructions (Accept-* and caller prefs). Whether there is a duplicate URI or not, the watcher can, if capable, include these in the request and the right thing will happen. If the watcher doesn't understand the transformation from description into request, the difference essentially becomes unavailable to the watcher for selection. > I hope I've given a concrete example in my other note. Without > additional information to provide guidance on what this means (which of > the four cases applies, and if its a dispatch case, how the dispatch > works), things are ambiguous. See above. However, I think we can easily disagree on this particular item and move ahead as you proposed in your other note. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 24 08:43:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09629; Mon, 24 Jan 2005 08:43:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct4lh-0003cY-Nr; Mon, 24 Jan 2005 09:00:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct4I6-0006rh-4g; Mon, 24 Jan 2005 08:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct4HH-0006d8-NV for simple@megatron.ietf.org; Mon, 24 Jan 2005 08:29:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07523 for ; Mon, 24 Jan 2005 08:29:09 -0500 (EST) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct4Xm-0002zk-F5 for simple@ietf.org; Mon, 24 Jan 2005 08:46:15 -0500 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id BC87EA9705; Mon, 24 Jan 2005 14:28:37 +0100 (CET) Received: from [192.168.1.45] (unknown [82.196.203.62]) by voyager.coretrek.no (Postfix) with ESMTP id A1DCDA96CE; Mon, 24 Jan 2005 14:28:25 +0100 (CET) In-Reply-To: <41F06F88.8090205@cisco.com> References: <1BEC4DA05ABCD34FACFCFC82086AC24704A0D3E1@RED-MSG-43.redmond.corp.microsoft.com> <41E6E9E5.2000305@cisco.com> <41F06F88.8090205@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] PIDF "entity" attribute usage Date: Mon, 24 Jan 2005 14:28:00 +0100 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , Tim Rang , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: 7bit On Jan 21, 2005, at 3:57 AM, Jonathan Rosenberg wrote: > inline. > > Paul Kyzivat wrote: > >> Tim Rang wrote: >>> Paul, >>> >>> You had me until here- >>> >>> >>> So, at least in principle, when using SIMPLE, you can use either >>> sip or >>> >>> pres URIs. However this assumes the specific implementation you are >>> using actually supports this. In practice you should determine what >>> the implementation you are using supports. >>> >>> >>> [Tim Rang] Can a SIMPLE implementation expect that all other SIMPLE >>> implementations support receiving the sip scheme in the entity >>> attribute? >> Probably not. I *think* a SIMPLE implementation must at least support >> receiving an entity attribute containing the URI used to subscribe >> for that presence. (And I suspect many will require that - don't >> recall if the specs require it.) >> So the bigger question is whether a SIMPLE implementation is able to >> *issue* a presence subscription to a { sip / pres } URI, and whether >> it is able to *accept* a presence subscription to a { sip / pres } >> URI. >> The issue of accepting doesn't seem like a big deal. The presence >> implementation is responsible for defining what URIs its presentities >> have, so a user should know what uri is supported to access that >> presentity. > > I don't follow this. Lets consider watchers for a moment. There two > things for a watcher: > > 1. could it issue a SUBSCRIBE request to a pres: URI; appropriately > doing the DNS operations needed to resolve it to a SIP URI > > 2. if it receives a presence document in a notification, could it > handle an entity attribute that is a pres URI > > For the presence agent, there are a bunch of cases: > > 1. Could the PA receive a SUBSCRIBE request where the r-uri is a pres > URI, presumably equating it to presence data associated with a SIP > URI? > > 2. Could the PA receive a presence document in a PUBLISH where one or > both of the r-uri and entity tags in the published document are pres > URI? > > These are complicated questions. I think we should place the burden on > the owner of the domain to really worry about correlation of these > identifiers. I totally agree, a domain offering presence service should decide if it wants to issue a pres URI as well as a sip URI to the same user. Further, it should also decide how to handle PUBLISH and SUBSCRIBE requests to one of the two. How should the PA handle 2 PUAs where one is PUBLISHing to the sip URI and the other is PUBLISHing to the pres URI of that user? This is a question that implementers need to answer. > That would argue for the following: > > 1. If a watcher genreates a SUBSCRIBE request with a pres URI in the > r-uri, and the presence agent is responsible for generation of the > presence document and can thus create one with either a pres or SIP > URI in the entity attribute, it MUST create one using the pres URI. > > 2. If a watcher genreates a SUBSCRIBE request with a sip URI in the > r-uri, and the presence agent is responsible for generation of the > presence document and can thus create one with either a pres or SIP > URI in the entity attribute, it MUST create one using the sip URI. > > 3. If the PA cannot genreate the document or otherwise modify its > entity attribute (for example if covered by an e2e signature), it MUST > be capable of receiving subscriptions to either the pres or SIP URI in > the request URI (thus be capable of equating the two URI) and thus > return whatever it has. These seem fair, but i think the text should be non-normative. > > Rules (1) and (2) also operate under the principle of least surprise; > I should get documents where the entity attribute matches what I > subscribed to. It also means that a watcher which has never even heard > of a pres URI would never see a notification containing a document > with a pres URI in the entity attribute, unless e2e signatures > prevents it. > > From a publishing perspective, I think the PA should support any of > the four combinations of pres/sip URI in the r-uri and entity > attributes. > > Where does this discussion belong? Since it largely deals with the > construction of presence documents, I'd argue in the data model, but > I'm open to suggestions. Well, the first part of this thread talks about how a PA handles SUBSCRIBE and PUBLISH requests to a pres uri and how a domain handles those requests. This should have been in RFC3856, but it's too late now. I guess data model document is good enough. Regards, Hisham > > Thoughts? > > -Jonathan R. > > > > >> The ability to issue subscription requests to one kind or the other >> of uri is probably the big issue. If I tell you my presence URI is >> pres:paul@example.com but your presence client doesn't support pres >> URIs, then you are just out of luck. >> I personally don't see any particular value in pres URIs. If I want a >> SIMPLE presence client, it is probably in support of a SIP UA that >> will be doing voice or IM. Both of those require the use of sip URIs. >> If I have all the support for sip, then why not use it for presence >> too? The pres URI is just a 5th wheel. >> Paul >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 24 11:20:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26709; Mon, 24 Jan 2005 11:20:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7DQ-0001k3-BB; Mon, 24 Jan 2005 11:37:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct6mE-0005gd-TR; Mon, 24 Jan 2005 11:09:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct6j4-0004uR-3r for simple@megatron.ietf.org; Mon, 24 Jan 2005 11:06:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24880 for ; Mon, 24 Jan 2005 11:05:59 -0500 (EST) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct6zX-00014q-1I for simple@ietf.org; Mon, 24 Jan 2005 11:23:07 -0500 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id EA6D1A9714; Mon, 24 Jan 2005 17:05:20 +0100 (CET) Received: from [192.168.1.45] (unknown [82.196.203.62]) by voyager.coretrek.no (Postfix) with ESMTP id CABA2A9710; Mon, 24 Jan 2005 17:05:17 +0100 (CET) In-Reply-To: <41F3592D.90208@lucent.com> References: <41F06687.5010504@cisco.com> <41F11F84.6000206@lucent.com> <41F1B4F8.20801@cs.columbia.edu> <41F3592D.90208@lucent.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: multiple person elements, was: Re: [Simple] presence-rules: Selecting on class Date: Mon, 24 Jan 2005 17:05:05 +0100 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Keep in mind that we are not disallowing composition of elements to happen at the compositor. What we are doing is allowing composition to take place at the UA or even at the user level, if the compositor is not intelligent enough to do so. Regards, Hisham On Jan 23, 2005, at 8:58 AM, Vijay K. Gurbani wrote: > Henning Schulzrinne wrote: > >> Vijay: >> we had this discussion, at length, in DC. The problem is that the >> composer is a program, with at best limited rule-based intelligence, >> while the watcher is often staffed with a real human being that can, >> in > > Prof. Schulzrinne: > > Thanks. I was just seeing if there is any wiggle room left, but > since this is a closed issue, I will shut up now. > > I will like to request though, if possible, that the reason why > we are allowing multiple person elements be explained in the > draft. Often times, it helps if the reader (or developer) > of a protocol knows why decisions were made in a certain manner. > > Sincerely, > > - 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-bounces@ietf.org Mon Jan 24 11:29:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27593; Mon, 24 Jan 2005 11:29:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7Mm-00027C-9A; Mon, 24 Jan 2005 11:47:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct70D-0008OJ-HZ; Mon, 24 Jan 2005 11:23:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct6uz-0007CR-JY for simple@megatron.ietf.org; Mon, 24 Jan 2005 11:18:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26503 for ; Mon, 24 Jan 2005 11:18:18 -0500 (EST) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7BT-0001dv-Sq for simple@ietf.org; Mon, 24 Jan 2005 11:35:27 -0500 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id 809D5A9710; Mon, 24 Jan 2005 17:17:45 +0100 (CET) Received: from [192.168.1.45] (unknown [82.196.203.62]) by voyager.coretrek.no (Postfix) with ESMTP id 40D85A96F7; Mon, 24 Jan 2005 17:17:41 +0100 (CET) In-Reply-To: <41F33C72.2070306@cisco.com> References: <41F33C72.2070306@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <789533EA-6E23-11D9-9191-000D93C60BA0@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] another try at data model compromise regarding unique service URI Date: Mon, 24 Jan 2005 17:17:40 +0100 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Content-Transfer-Encoding: 7bit Jonathan, Thanks for the summary. The proposal seems adequate. I also see no need for the element if your proposal is the way forward. Regards, Hisham On Jan 23, 2005, at 6:56 AM, Jonathan Rosenberg wrote: > I'll be responding to various messages in the threads we had on the > modeling dispatchers topic. However, I concluded a few things from my > previous compromise proposal (adding an i-belong-to element): > > 1. there was general agreement that i-belong-to was reasonable, since > more information can't hurt > > 2. even with i-belong-to, there still seemed to be a desire to support > non-unique contact URIs, when in fact part of the reason I had proposed > i-belong-to was to retain that feature of the data model > > 3. There was (perhaps) some dispute about whether we need to resolve > the > issue of unique contact URI or not for the data model. I believe we do. > I agree > with the approach of pushing off composition for another document, but > the issue of how we name and identify a service, and how you can or > cannot select those services from a presence document, is central to > the > data model and needs to be resolved one way or another. > > 4. I appear to be in the losing minority on the issue of unique URI or > not. It appears Aki and Henning still favor allowing multiple tuples > with the same contact URI. I believe Markus and Paul do as well, but am > not as certain. > > 5. We've identified several real problems when you rely on things > besides the URI to dispatch to the appropriate service: > > > a. it doesnt work with an offerless invite, as in the case of 3pcc. > Like it or not, this is a common case > > b. it doesnt work with cases where my initial SDP does not cause the > appropriate dispatch, but a subsequent re-invite would. For example, I > want to call your videophone, but I want to start with just audio so I > can ask about adding video. > > 6. We agree to allow simple union-based composition. Henning has > indicated that it is possible that the compositor doesn't understand > the > URI schemes in the contact. Thus, a union compositor might generate > presence documents with two URI that are equal. Though I think this is > quite unlikely, it is certainly possible. > > > From these things, I concluded that (for reason 6 alone), the data > model > cannot outlaw two services from having the same URI. However, it begs > the question of what does it *mean* when that happens. I think that we > are not aligned on this yet. Henning made a statement in one of his > notes that I believe captures the essence of the problem: > > Henning wrote: >> There are the following possible cases, all with well-defined >> behavior for the watcher: > > I don't think we want to specify the behavior of the watcher at all. > They should be able to do anything they want to with the data. The key > to interop is to make the semantics of the data as unambiguous as > possible. I think that, in the case of multiple services with the same > URI, the meaning is ambiguous, and depending on what a watcher is > interested in, might make different choices. Let me give an example. > > Lets take an example Aki gave during the SIMPLE meeting in November. > He was interested in expressing this situation: a user has a > multimedia UA that can do audio and IM. They want to indicate that > they are available for IM, but not for audio. Let us say that they > represent this by including two services in a document (i.e., two > tuples) with the same contact (their AOR), but one indicating audio > with prescaps, and a basic status of closed, and the other indicating > just IM with prescaps, and a a basic status of open. > > We have touched on several possible meanings for the case of two > tuples/services with the same URI: > > MEANING 1 (CONFLICT): These represent conflicting information about > the same service; one or the other might be true > > MEANING 2 (DISPATCH): These represent different services, but are > only reachable by a dispatcher (using unknown dispatch logic), and so > an INVITE sent to the (which is the AOR), will reach one or > the other > > MEANING 3 (COMPONENT): These are one service, but the service has > been disaggregated because of a desire to provide differing presence > status for differing types of communication attempts (this is the > meaning in the example) > > MEANING 4 (OVERRIDE): An attempt was made to override one service > definition with another; however, the compositor foolishly placed them > both in the document. As such, the more recent one is probably > correct. > > I suspect that there are other meanings. > > So, let us consider the differing decisions a watcher might make, > depending on which meaning it decides to attest to this document. Let > us assume the watcher wishes to proceed with a multimedia call using > as many media types as possible: > > MEANING 1 (CONFLICT): The watcher sends an INVITE with an offer > including both audio and IM media streams, under the assumption that > one or the other is supported and the presentity will reject one of > the media streams > > MEANING 2 (DISPATCH): Since the service supporting IM is the only one > available, the watcher wishes to avoid dispatching to the audio > service. So, it sends an INVITE with only an IM media stream, hoping > that the dispatch works correctly. > > MEANING 3 (COMPONENT): The watcher sends an INVITE with both audio and > IM. It figures that perhaps the presentity will accept the audio > stream anyway, and if not, just reject that stream and proceed with > IM. > > MEANING 4 (OVERRIDE): The watcher sends an INVITE with whichever media > type is indicated for the most recent tuple. > > > As you can see, there is clearly a difference in watcher behavior, > assuming a specific objective, depending on the semantics of multiple > services with the same URI. > > So, in light of this, my specific proposal is that we allow for > multiple services with the same URI, but in the data model very > clearly define its meaning as *ambiguous*; additional tuple meta-data > will normally need to be present to help clarify the actual meaning. > As such, the data model would recommend against doing this without > meta-data to further clarify. A watcher could NOT assume that > constructing an INVITE compliant to the capabilities listed for a > tuple would cause a dispatch to that tuple, as Aki has suggested. I > think this is the kind of dangerous assumption that, as my examples > above show, can be wrong depending on the actual meaning of this case. > > In the spirit of Robert's proposal, I would further propose not to > pursue the extension yet. Let us further study > composition and then figure out the right set of dispatcher > characteristics we wish to model. > > At this time, we could then make the following recommendations > regarding what a PUA places into the element. Namely, if it > has a GRUU, it puts that. If it doesn't, but it has **strong** > awareness that its local IP address and port have the GRUU property, > it uses that, else it places the AOR. > > If there are multiple PUA for an AOR, and a compositor in the presence > engine, we can consider four cases roughly speaking. We have PUA that > support GRUU (or have a local contact that has the GRUU property), or > don't, and we have a compositor that just does union, or is smarter > and combines the contacts together: > > GRUU-less PUA, union compositor: This tends to do the right thing. The > resulting presence document includes multiple tuples, each of which > uses the AOR. The presentity is at least reachable since the AOR is > listed. > > GRUU PUA, smart compositor: The compositor can combine together the > tuples, since it knows the GRUUs are all bound to the same AOR. It can > thus list a single tuple (if it likes), with the AOR as the > > GRUU PUA, union compositor: This produces a document that exposes the > GRUU to the watcher. Still works fine, though it may not have been > desireable to expose the GRUU to the watcher. > > GRUU-less PUA, smart compositor: The compositor can correlate the > tuples together because they each use the AOR as the . > However, because there is no GRUU, it can't as easily correlate each > tuple with a registration that might exist for the UA that generated > the PUBLISH. Such correlation would need to be supported through other > tuple data. > > > This is not ideal (the fourth case in particular), but it seems > workable. > > Where does this leave us with override? I still feel strongly that it > is a mistake to encode composition policy into the presence document > itself. Therefore, the presence document is simply not the place to do > anything special in support of override. In further support of > Robert's proposal, since override is very much about composition, I > propose that we simply defer this until we have properly defined > policy documents for defining it. > > Can we move forward based on this? > > Thanks, > Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 25 10:26:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11893; Tue, 25 Jan 2005 10:26:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtSqt-00051Z-ND; Tue, 25 Jan 2005 10:43:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtSW7-0003Nk-RB; Tue, 25 Jan 2005 10:22:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrK2B-0002vh-US for simple@megatron.ietf.org; Wed, 19 Jan 2005 12:54:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05829 for ; Wed, 19 Jan 2005 12:54:20 -0500 (EST) Received: from [194.90.168.100] (helo=mail.followap.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrKHe-0000nl-No for simple@ietf.org; Wed, 19 Jan 2005 13:10:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Jan 2005 19:50:55 +0200 Message-ID: <8E5AB0A04458904BB9B079055261033C21600D@mail.followap.com> Thread-Topic: RPID-04 schema Thread-Index: AcT+TrehZiMSA4sdS/mLKNc5IS23/w== From: "Fridy Sharon-Fridman" To: , , , X-Spam-Score: 1.1 (+) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d X-Mailman-Approved-At: Tue, 25 Jan 2005 10:22:06 -0500 Cc: simple@ietf.org Subject: [Simple] RPID-04 schema X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1709796406==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb This is a multi-part message in MIME format. --===============1709796406== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C4FE4F.6CB30F89" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4FE4F.6CB30F89 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C4FE4F.6CB30F89" ------_=_NextPart_002_01C4FE4F.6CB30F89 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In 5.2, the schema for a tuple imports using xs: namespace which is not defined. May need to remove the namespace qualifier. =20 Cheers, --Fridy / Followap ------_=_NextPart_002_01C4FE4F.6CB30F89 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In 5.2, the schema for a tuple imports using xs: = namespace which is not defined. May need to remove the namespace = qualifier.

 

Cheers,

--Fridy / Followap

------_=_NextPart_002_01C4FE4F.6CB30F89-- ------_=_NextPart_001_01C4FE4F.6CB30F89 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhDwAPAHcAACH/C01TT0ZGSUNFOS4wDQAAAAFzUkdCAK7OHOkAIf8LTVNPRkZJQ0U5LjAY AAAADG1zT1BNU09GRklDRTkuMERuJlAzACH/C01TT0ZGSUNFOS4wGAAAAAxjbVBQSkNtcDA3MTIC AQEGiroUzgAh+QQBAAABACwAAAAADwAPAIb/99jAwMD/0BP/1Cf/2Dv/32IAAABSUf94eP+Mi/+f nv/Fxf//8LD/88QFBP8sK///9MT/+Nj/77D/88X/6In/8LH/2tr/v7//sbH/o6P/h4f/eXn/1zv/ 4GL/z8//s7P/pqb/mJf/xMT/qKf/mpr/jIz/cXD/YmL/ra3/kZL/hIP/dXb/Wlr/TEz/oqL/hob/ eHf/amr/Tk7/QUD/lpb/enr/bW3/Xl//0BSfn//Gxf95d/+Li///6Ir/54l5eP94d/9SUv8sKv8r K/8BAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB AgMBAgMBAgMBAgMHh4ABgoOEhYaCBoeDAgMcBQYUFQ0AhjgDBB0GPgyThowEj5sQEZ6XjxQSE6SF lqCQnJQBNDU2N5YcmT0SnQEuLzAxMjMODwYHCDw5OgEoKSorLC0OQsZACQoLASIjJCUmJ9PGCNfZ Hh8gIQbq6+wGFhcYGRobDkPGP9fLhsQGQTs82BQFSFQoEAA7 ------_=_NextPart_001_01C4FE4F.6CB30F89-- --===============1709796406== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1709796406==-- From simple-bounces@ietf.org Tue Jan 25 10:27:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12047; Tue, 25 Jan 2005 10:27:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtSrp-00053B-7J; Tue, 25 Jan 2005 10:44:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtSW8-0003Np-9A; Tue, 25 Jan 2005 10:22:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CswzW-0004km-H6 for simple@megatron.ietf.org; Mon, 24 Jan 2005 00:42:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22871 for ; Mon, 24 Jan 2005 00:42:19 -0500 (EST) Received: from [80.74.106.10] (helo=rvil-mail.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsxFx-0007Zi-VF for simple@ietf.org; Mon, 24 Jan 2005 00:59:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Mistake in PRES-URI BNF Date: Mon, 24 Jan 2005 07:41:49 +0200 Message-ID: Thread-Topic: [Simple] Mistake in PRES-URI BNF Thread-Index: AcTXwq5jMFYycAmnRZSiaazkii9a1AAAGFaAAABwjqAAAAVDMApVNnAgAAv8WWA= From: "Ofra Wachsman" To: "Robert Sparks " X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 25 Jan 2005 10:22:06 -0500 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Hi May be we should emphasize that the 'addr-spec' used to define the mailbox is as defined in RFC 2822:=20 addr-spec =3D local-part "@" domain And not as defined in RFC 3261: =20 addr-spec =3D SIP-URI / SIPS-URI / absoluteURI Don't you think it is confusing to have two definitions with the same name? Ofra -----Original Message----- From: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: Wednesday, December 01, 2004 6:26 PM To: Tamar Barzuza Cc: simple@ietf.org Subject: Re: [Simple] Mistake in PRES-URI BNF Tamar - I don't think that production was what anybody had in mind. The intent was probably to =3D addr-spec. We can put together a correction and figure out how to submit it. Comments from anyone? RjS On Nov 29, 2004, at 5:51 AM, Tamar Barzuza wrote: >> Hi, >> >> I found a problem in the BNF of PRES-URI. >> >> RFC 2396 defined the generic syntax of URI. It explicitly says that=20 >> the following (delims) characters are disallowed within URI: >> delims=3D "<" | ">" | "#" | "%" | <"> >> >> However, in RFCs 3859 and 2822 the definition for PRES-URI is: >> PRES URI =3D "pres:" [ to ] [ headers ] >> to =3D mailbox >> mailbox =3D name-addr / addr-spec >> name-addr =3D [display-name] angle-addr >> angle-addr =3D [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr >> addr-spec =3D local-part "@" domain >> display-name =3D phrase >> Which means that pres addresses can look like pres:"name", >> hence may contain " and <>. >> >> Therefore I believe that the PRES-URI BNF is mistaken. >> >> Thanks, >> Tamar. >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 25 17:05:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17383; Tue, 25 Jan 2005 17:05:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtZ5e-0003jV-LG; Tue, 25 Jan 2005 17:23:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtYGa-0003AW-NK; Tue, 25 Jan 2005 16:30:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtXwL-0008KI-P0; Tue, 25 Jan 2005 16:09:33 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08109; Tue, 25 Jan 2005 16:09:31 -0500 (EST) Message-Id: <200501252109.QAA08109@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 25 Jan 2005 16:09:31 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-package-03.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --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 : An Extensible Markup Language (XML) Document Format for Indicating Changes in XML Configuration Access Protocol (XCAP) Resources Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-package-03.txt Pages : 15 Date : 2005-1-25 This specification defines a document format that can be used to describe the differences between versions of resources managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). Documents of this format can be delivered to clients using a number of means, including the Session Initiation Protocol (SIP) event package for configuration data. By subscribing to this event package, clients can learn about document changes made by other clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-package-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-xcap-package-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-xcap-package-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-25163351.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-package-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-package-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-25163351.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Tue Jan 25 18:33:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25716; Tue, 25 Jan 2005 18:33:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtaSM-0006kj-28; Tue, 25 Jan 2005 18:50:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cta2X-0007ez-5R; Tue, 25 Jan 2005 18:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtZyq-0005sL-On for simple@megatron.ietf.org; Tue, 25 Jan 2005 18:20:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24647 for ; Tue, 25 Jan 2005 18:20:13 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtaFb-0006L1-9Q for simple@ietf.org; Tue, 25 Jan 2005 18:37:38 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 Jan 2005 15:25:31 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0PNJXl2026632; Tue, 25 Jan 2005 15:19:34 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOP19146; Tue, 25 Jan 2005 18:19:36 -0500 (EST) Message-ID: <41F6D408.6080700@cisco.com> Date: Tue, 25 Jan 2005 18:19:36 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] another try at data model compromise regarding unique service URI References: <41F33C72.2070306@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I'll be responding to various messages in the threads we had on the > modeling dispatchers topic. However, I concluded a few things from my > previous compromise proposal (adding an i-belong-to element): > > 1. there was general agreement that i-belong-to was reasonable, since > more information can't hurt > > 2. even with i-belong-to, there still seemed to be a desire to support > non-unique contact URIs, when in fact part of the reason I had proposed > i-belong-to was to retain that feature of the data model > > 3. There was (perhaps) some dispute about whether we need to resolve the > issue of unique contact URI or not for the data model. I believe we do. > I agree > with the approach of pushing off composition for another document, but > the issue of how we name and identify a service, and how you can or > cannot select those services from a presence document, is central to the > data model and needs to be resolved one way or another. > > 4. I appear to be in the losing minority on the issue of unique URI or > not. It appears Aki and Henning still favor allowing multiple tuples > with the same contact URI. I believe Markus and Paul do as well, but am > not as certain. I don't like it. But I find the alternatives worse. My feeling is that this is the way forward. Perhaps composition will advance and solve the problem before anything is fielded that exhibits this problem. If not, then in cases where this is used inappropriately, the results will be disappointing. Then hopefully the offenders will stop doing it. > 5. We've identified several real problems when you rely on things > besides the URI to dispatch to the appropriate service: > > a. it doesnt work with an offerless invite, as in the case of 3pcc. > Like it or not, this is a common case > > b. it doesnt work with cases where my initial SDP does not cause the > appropriate dispatch, but a subsequent re-invite would. For example, I > want to call your videophone, but I want to start with just audio so I > can ask about adding video. As Henning pointed out, those are only problems with dispatching based on SDP. Dispatching based on something like method and event ID doesn't suffer that problem. Dispatching based on callerprefs also doesn't - if the callerprefs are present, and if you can figure out how to dispatch based on them. I think it will be difficult to get them there. > 6. We agree to allow simple union-based composition. Henning has > indicated that it is possible that the compositor doesn't understand the > URI schemes in the contact. Thus, a union compositor might generate > presence documents with two URI that are equal. Though I think this is > quite unlikely, it is certainly possible. > > From these things, I concluded that (for reason 6 alone), the data model > cannot outlaw two services from having the same URI. However, it begs > the question of what does it *mean* when that happens. I think that we > are not aligned on this yet. Henning made a statement in one of his > notes that I believe captures the essence of the problem: > > Henning wrote: > >> There are the following possible cases, all with well-defined >> behavior for the watcher: > > I don't think we want to specify the behavior of the watcher at all. I don't think it has been the intent to normatively specify the behavior of the watcher. I think this has simply been used as a use case to see if what might plausibly be expected to happen has serious problems. So far, the problems have seemed to be limited in nature and more or less expected under the circumstances. But of course it only remains for another use case that is more problematic. > They should be able to do anything they want to with the data. The key > to interop is to make the semantics of the data as unambiguous as > possible. Without invoking miracles. When the semantics are ambiguous, and nobody knows better, best to leave them that way. > I think that, in the case of multiple services with the same > URI, the meaning is ambiguous, and depending on what a watcher is > interested in, might make different choices. Let me give an example. > > Lets take an example Aki gave during the SIMPLE meeting in November. He > was interested in expressing this situation: a user has a multimedia UA > that can do audio and IM. They want to indicate that they are available > for IM, but not for audio. Let us say that they represent this by > including two services in a document (i.e., two tuples) with the same > contact (their AOR), but one indicating audio with prescaps, and a basic > status of closed, and the other indicating just IM with prescaps, and a > a basic status of open. Well, I think this is not a good way to represent this situation. But lets continue anyway, since lots of people seem to want to represent it this way. > We have touched on several possible meanings for the case of two > tuples/services with the same URI: > > MEANING 1 (CONFLICT): These represent conflicting information about > the same service; one or the other might be true > > MEANING 2 (DISPATCH): These represent different services, but are only > reachable by a dispatcher (using unknown dispatch logic), and so an > INVITE sent to the (which is the AOR), will reach one or the > other Or both (forking). This would leave it up to the recipient to choose which one to use. > MEANING 3 (COMPONENT): These are one service, but the service has > been disaggregated because of a desire to provide differing presence > status for differing types of communication attempts (this is the > meaning in the example) > > MEANING 4 (OVERRIDE): An attempt was made to override one service > definition with another; however, the compositor foolishly placed them > both in the document. As such, the more recent one is probably correct. > > I suspect that there are other meanings. > > So, let us consider the differing decisions a watcher might make, > depending on which meaning it decides to attest to this document. Let us Part of the problem may be simply assuming that a correct watcher is free to make this choice as it wishes. I think we should simply require watchers to act on this data as if was ambiguous what the meaning is. Leave it to the watching User to ascribe meaning. > assume the watcher wishes to proceed with a multimedia call using as > many media types as possible: > > MEANING 1 (CONFLICT): The watcher sends an INVITE with an offer > including both audio and IM media streams, under the assumption that one > or the other is supported and the presentity will reject one of the > media streams > > MEANING 2 (DISPATCH): Since the service supporting IM is the only one > available, the watcher wishes to avoid dispatching to the audio service. > So, it sends an INVITE with only an IM media stream, hoping that the > dispatch works correctly. > > MEANING 3 (COMPONENT): The watcher sends an INVITE with both audio and > IM. It figures that perhaps the presentity will accept the audio stream > anyway, and if not, just reject that stream and proceed with IM. > > MEANING 4 (OVERRIDE): The watcher sends an INVITE with whichever media > type is indicated for the most recent tuple. > > > As you can see, there is clearly a difference in watcher behavior, > assuming a specific objective, depending on the semantics of multiple > services with the same URI. > > So, in light of this, my specific proposal is that we allow for multiple > services with the same URI, but in the data model very clearly define > its meaning as *ambiguous*; OK. I agree with this. > additional tuple meta-data will normally > need to be present to help clarify the actual meaning. As such, the data > model would recommend against doing this without meta-data to further > clarify. A watcher could NOT assume that constructing an INVITE > compliant to the capabilities listed for a tuple would cause a dispatch > to that tuple, as Aki has suggested. I think this is the kind of > dangerous assumption that, as my examples above show, can be wrong > depending on the actual meaning of this case. > > In the spirit of Robert's proposal, I would further propose not to > pursue the extension yet. Let us further study composition > and then figure out the right set of dispatcher characteristics we wish > to model. I agree. While there seems to be some value in the proposal, it feels half baked. > At this time, we could then make the following recommendations regarding > what a PUA places into the element. Namely, if it has a GRUU, > it puts that. If it doesn't, but it has **strong** awareness that its > local IP address and port have the GRUU property, it uses that, else it > places the AOR. > > If there are multiple PUA for an AOR, and a compositor in the presence > engine, we can consider four cases roughly speaking. We have PUA that > support GRUU (or have a local contact that has the GRUU property), or > don't, and we have a compositor that just does union, or is smarter and > combines the contacts together: > > GRUU-less PUA, union compositor: This tends to do the right thing. The > resulting presence document includes multiple tuples, each of which uses > the AOR. The presentity is at least reachable since the AOR is listed. > > GRUU PUA, smart compositor: The compositor can combine together the > tuples, since it knows the GRUUs are all bound to the same AOR. It can > thus list a single tuple (if it likes), with the AOR as the How is it that the compositor knows the GRUUs are all bound to the same AOR? It knows they are bound to the same domain, but AFAIK nothing more. > GRUU PUA, union compositor: This produces a document that exposes the > GRUU to the watcher. Still works fine, though it may not have been > desireable to expose the GRUU to the watcher. > > GRUU-less PUA, smart compositor: The compositor can correlate the tuples > together because they each use the AOR as the . However, > because there is no GRUU, it can't as easily correlate each tuple with a > registration that might exist for the UA that generated the PUBLISH. > Such correlation would need to be supported through other tuple data. Hmm. You mention the compositor correlating PUBLISH data from PUAs with registration data. This is the first mention I have seen of that. It is certainly something that is possible in some cases. But seems to need some scoping out. For instance, this assumes the PA knows the mapping from presentity address to registrar AOR. (In lots of cases this is easy, because it is the same. But some people may be thinking otherwise.) Another case comes to mind: If the PUAs are GRUU-less, but know something about the compositor, they might use their contact even though it is not a GRUU, and depend on the compositor to replace it with the AOR, after having used it to correlate with registrations. But this presumes the compositor somehow knows it should do that. This seems like a weak and ugly case, but it might be a pragmatic choice. > This is not ideal (the fourth case in particular), but it seems workable. > > Where does this leave us with override? I still feel strongly that it is > a mistake to encode composition policy into the presence document > itself. Therefore, the presence document is simply not the place to do > anything special in support of override. In further support of Robert's > proposal, since override is very much about composition, I propose that > we simply defer this until we have properly defined policy documents for > defining it. Right. I have always thought that override was of more theoretical interest than practical. > Can we move forward based on this? I think so. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 25 18:53:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26949; Tue, 25 Jan 2005 18:53:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctalh-0007Nr-OZ; Tue, 25 Jan 2005 19:10:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtaTh-0004YX-Sy; Tue, 25 Jan 2005 18:52:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtaFV-0002Zs-V7 for simple@megatron.ietf.org; Tue, 25 Jan 2005 18:37:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26130 for ; Tue, 25 Jan 2005 18:37:27 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtaWJ-0006u4-Qx for simple@ietf.org; Tue, 25 Jan 2005 18:54:52 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 25 Jan 2005 15:44:49 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0PNasl2003628; Tue, 25 Jan 2005 15:36:54 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOP20544; Tue, 25 Jan 2005 18:36:53 -0500 (EST) Message-ID: <41F6D815.8080709@cisco.com> Date: Tue, 25 Jan 2005 18:36:53 -0500 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: "Vijay K. Gurbani" Subject: Re: multiple person elements, was: Re: [Simple] presence-rules: Selecting on class References: <41F06687.5010504@cisco.com> <41F11F84.6000206@lucent.com> <41F1335B.70205@cisco.com> <41F13737.3050009@lucent.com> <41F147B1.908@cisco.com> <41F1512E.3050109@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Paul Kyzivat wrote: > >> I disagree with you about what compose means. Its not about going from >> abstract to concrete. Going from >> >> {W,X} + {Y,Z} to {W,X,Y,Z} >> >> is a perfectly valid kind of compostion that has no change in >> abstractness. And going from: >> >> {W=A, X=B} + {W=C, Z=D} to {X=B, Z=D} > > > I actually see this as good composition; in both your examples, Well, sure it is. The prior one is composition, while this one is an example of the kind of composition Henning was talking about long ago. It takes the position that the two documents have two equally valid conflicting values of reality, and that conflict should be resolved by deciding we know nothing useful. This is a good thing to do in some cases, and a really bad thing to do in other cases. The trick is knowing when it is a good thing. IMO it is not a good thing to do by default. > we took _two_ sets and composed them into _one_ set -- a good start. > We went from abstract to concrete. Your concept of abstraction must be different from mine. The two input sets are both concrete. The result also seems concrete. Maybe it is a bit more abstract because it has removed the specification of an attribute. > By allowing multiple person > elements, we are essentially doing this to your example: > > {W, X} + {Y, Z} => {W, X} + {Y, Z} > > basically, nothing. No. originally there were two published presence documents, but neither was available to the watcher. The compostion makes the contents of both into a single document that can be provided to a watcher. So it has definitely done something. If you like, write it as: {W, X} + {Y, Z} => ({W, X}, {Y, Z}) >> The layer is there already. It got there when we acknowledged there >> could be multiple sources of presence information. > > > In my email, the use of the word "layer" was not right; I intended > to say that "the presence problem is complex enought without > adding another potential source of ambiguity in the form of > multiple person elements." That only changes the words, not the point. The ambiguity is already there as two input presence documents with conflicting information. The composition is not making anything worse. It is simply failing to make it better - not because it doesn't want to, but because it doesn't know how. >> I am pretty sure that it will be impossible to devise a compostion >> algorithm that does the "right" thing without a bunch of >> presentity-specific heuristics. I think such a thing can be designed >> and built. And probably used to great success by geeks like us. I have >> much less confidence that it can be built in such a way that those >> heuristics can be entered for all of the unwashed masses that use >> communications devices. > > I am not sure what the right answer is, if there is one. Unlike > you, though, I am not convinced that having the person element > recur is advantageous. > > > Some of us believe that ambiguous data is preferable to wrong > > data or no data. > > Ambiguous data is definitely preferable to no data; I am not sure > about its preference over with "wrong" data. Both ambiguous and > wrong data tend to condition the watcher into _not_ believing in > the presence system. Nobody disagrees that smart, correct, composition is better than composition by union. We just don't know how to do it yet. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 26 06:10:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11265; Wed, 26 Jan 2005 06:10:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtlKj-0001f1-RQ; Wed, 26 Jan 2005 06:27:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctl2N-0003Jl-RC; Wed, 26 Jan 2005 06:08:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctl1P-000346-AY for simple@megatron.ietf.org; Wed, 26 Jan 2005 06:07:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10913 for ; Wed, 26 Jan 2005 06:07:36 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtlIJ-0001Zv-51 for simple@ietf.org; Wed, 26 Jan 2005 06:25:07 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0QB7VJ22625; Wed, 26 Jan 2005 13:07:32 +0200 (EET) X-Scanned: Wed, 26 Jan 2005 13:03:58 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j0QB3wKx015454; Wed, 26 Jan 2005 13:03:58 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 008qAzIK; Wed, 26 Jan 2005 13:03:18 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0QB3HU05888; Wed, 26 Jan 2005 13:03:18 +0200 (EET) Received: from [172.21.39.180] ([172.21.39.180]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 26 Jan 2005 13:03:17 +0200 Message-ID: <41F778F5.8040004@nokia.com> Date: Wed, 26 Jan 2005 13:03:17 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Simple] another try at data model compromise regarding unique service URI References: <41F33C72.2070306@cisco.com> In-Reply-To: <41F33C72.2070306@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2005 11:03:17.0806 (UTC) FILETIME=[A3CD84E0:01C50396] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Inline. ext Jonathan Rosenberg wrote: ...snip... > We have touched on several possible meanings for the case of two > tuples/services with the same URI: > > MEANING 1 (CONFLICT): These represent conflicting information about > the same service; one or the other might be true > > MEANING 2 (DISPATCH): These represent different services, but are only > reachable by a dispatcher (using unknown dispatch logic), and so an > INVITE sent to the (which is the AOR), will reach one or the > other > > MEANING 3 (COMPONENT): These are one service, but the service has > been disaggregated because of a desire to provide differing presence > status for differing types of communication attempts (this is the > meaning in the example) > > MEANING 4 (OVERRIDE): An attempt was made to override one service > definition with another; however, the compositor foolishly placed them > both in the document. As such, the more recent one is probably correct. I guess you're right. I was hoping we would be able to come to an agreement, picking just one of these meanings (preferably #3) and rule out all others. However, as I read further and as I understand it, your proposal is just a different means to an end -- that is, exact meaning will need to be prescribed through meta-data in each tuple. And that is fine, as long as we define exactly what this meta-data is. > I suspect that there are other meanings. > > So, let us consider the differing decisions a watcher might make, > depending on which meaning it decides to attest to this document. Let us > assume the watcher wishes to proceed with a multimedia call using as > many media types as possible: > > MEANING 1 (CONFLICT): The watcher sends an INVITE with an offer > including both audio and IM media streams, under the assumption that one > or the other is supported and the presentity will reject one of the > media streams > > MEANING 2 (DISPATCH): Since the service supporting IM is the only one > available, the watcher wishes to avoid dispatching to the audio service. > So, it sends an INVITE with only an IM media stream, hoping that the > dispatch works correctly. > > MEANING 3 (COMPONENT): The watcher sends an INVITE with both audio and > IM. It figures that perhaps the presentity will accept the audio stream > anyway, and if not, just reject that stream and proceed with IM. > > MEANING 4 (OVERRIDE): The watcher sends an INVITE with whichever media > type is indicated for the most recent tuple. > > > As you can see, there is clearly a difference in watcher behavior, > assuming a specific objective, depending on the semantics of multiple > services with the same URI. > > So, in light of this, my specific proposal is that we allow for multiple > services with the same URI, but in the data model very clearly define > its meaning as *ambiguous*; additional tuple meta-data will normally > need to be present to help clarify the actual meaning. Exactly, so far so good. > As such, the data > model would recommend against doing this without meta-data to further > clarify. A watcher could NOT assume that constructing an INVITE > compliant to the capabilities listed for a tuple would cause a dispatch > to that tuple, as Aki has suggested. I think this is the kind of > dangerous assumption that, as my examples above show, can be wrong > depending on the actual meaning of this case. All right, but if not capability description, as in method=MESSAGE, what meta-data would one put in a pair of tuples to indicate that indeed a MESSAGE will be appreciated in this AOR, while an INVITation for voice won't (because I'm in a meeting)? ...snip... > Can we move forward based on this? Yes, I think so. Perhaps a rough edge or two to smooth out, but this is an acceptable approach. Cheers, Aki > Thanks, > Jonathan R. > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 26 06:54:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14584; Wed, 26 Jan 2005 06:54:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctm1x-0002ox-64; Wed, 26 Jan 2005 07:12:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctljt-0003uJ-H5; Wed, 26 Jan 2005 06:53:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctlgq-0003QD-6y for simple@megatron.ietf.org; Wed, 26 Jan 2005 06:50:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14269 for ; Wed, 26 Jan 2005 06:50:25 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctlxk-0002ia-H6 for simple@ietf.org; Wed, 26 Jan 2005 07:07:57 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0QBnAJ07620; Wed, 26 Jan 2005 13:49:14 +0200 (EET) X-Scanned: Wed, 26 Jan 2005 13:48:45 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j0QBmj06000989; Wed, 26 Jan 2005 13:48:45 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00QePiwT; Wed, 26 Jan 2005 13:44:12 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0QBi9U21079; Wed, 26 Jan 2005 13:44:09 +0200 (EET) Received: from [172.21.39.180] ([172.21.39.180]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 26 Jan 2005 13:44:09 +0200 Message-ID: <41F78288.2070101@nokia.com> Date: Wed, 26 Jan 2005 13:44:08 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Paul Kyzivat Subject: Re: multiple person elements, was: Re: [Simple] presence-rules: Selecting on class References: <41F06687.5010504@cisco.com> <41F11F84.6000206@lucent.com> <41F1335B.70205@cisco.com> <41F13737.3050009@lucent.com> <41F147B1.908@cisco.com> In-Reply-To: <41F147B1.908@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2005 11:44:09.0638 (UTC) FILETIME=[59356460:01C5039C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: "Vijay K. Gurbani" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Paul, I agree with you 100%. Cheers, Aki ext Paul Kyzivat wrote: > > > Vijay K. Gurbani wrote: > >> Paul Kyzivat wrote: >> >>> You are heading down the slippery slope. >>> >>> We wanted to allow this because we want to allow use of a simple >>> composition policy that doesn't know how to resolve the ambiguity, >>> and so wants to leave it to watchers to resolve. >> >> >> >> Paul: >> >> A composition policy, as its name suggests, should compose; i.e. >> take something abstract and make it more concrete. > > > I disagree with you about what compose means. Its not about going from > abstract to concrete. Going from > > {W,X} + {Y,Z} to {W,X,Y,Z} > > is a perfectly valid kind of compostion that has no change in > abstractness. And going from: > > {W=A, X=B} + {W=C, Z=D} to {X=B, Z=D} > > is another valid kind of composition that becomes more abstract (or at > least less specific.) > >> If it does >> not do so, then ambiguous data is propagated further into the >> system, gumming up even more machinery it touches. > > > Some of us believe that ambiguous data is preferable to wrong data or no > data. > >> IMHO, a watcher would be content to do as less as possible; > > > In some cases. And one solution to that would be for a watcher UA to > simply not display ambiguous data. Then at least it is the watcher > making that decision for its user. > > I think what you may really mean is that accurate data is better than a > bunch of ambiguous data that might contain accurate data. To the extent > that somebody knows how to draw the distinction, I agree. > > But if my boss' status says both "Out to Lunch" and "In a Meeting", then > I think I may well have a better chance of deciding which is right than > some stupid composer that hasn't been customized for his ideosyncracies. > >> operational experience in SIP appears to suggest this. Forking, >> response aggregation and transport conversion are not the domain >> of proxies alone; SIP endpoints themselves can perform these. >> However, of all the many endpoints that I have used, not one >> of them did these things. >> >> Personally, I think the presence problem is complex enough without >> adding another layer (my head hurts as I try to make sense of >> all of this; but maybe it is just me). As Jonathan said, even >> if we did allow for multiple person elements, the model itself >> still revolves around one person. If so, why not just enforce >> that in the representation of the model? > > > The layer is there already. It got there when we acknowledged there > could be multiple sources of presence information. It is designing a > composition algorithm that does the "right" thing with this information > that makes my head hurt. This is one of those cases where something easy > for people is really hard for a computer. > > I am pretty sure that it will be impossible to devise a compostion > algorithm that does the "right" thing without a bunch of > presentity-specific heuristics. I think such a thing can be designed and > built. And probably used to great success by geeks like us. I have much > less confidence that it can be built in such a way that those heuristics > can be entered for all of the unwashed masses that use communications > devices. > > Paul > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From DWDMX@msn.com Wed Jan 26 14:39:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04283; Wed, 26 Jan 2005 14:39:07 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CttHN-0000jT-65; Wed, 26 Jan 2005 14:56:42 -0500 Received: from adsl-64-216-16-123.dsl.snantx.swbell.net ([64.216.16.123]) by mx2.foretec.com with smtp (Exim 4.24) id 1Ctt0J-0006a0-Fa; Wed, 26 Jan 2005 14:39:04 -0500 Received: from turpitude.anu.boor.au ([118.69.64.211] helo=anu.whalen.au) by smtp1.bangle.co with esmtp id 1A5Ys6-785182-75 Message-ID: Sender: freeradius-devel-DWDMX@msn.com X-Mailman-Version: 2.0.1 Date: Wed, 26 Jan 2005 17:30:57 -0200 From: "Carter Willard" To: sigtran-admin@ietf.org, simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-request@ietf.org Subject: SU-per Hu^ge 0ffers Sigtran-admin X-Spam-Score: 3.9 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 The L0west price of all med's is here. Viicodin - $199.95 Codeine - $189.95 V1a'gra - $199.95 Va|ium - $259.95 Cia|is - $189.95 Xa'nax - $233.95 and many m0reeee..... We are the bes't available nowadays http://expedited2u.biz/2/?wid=200007 This is 1 tiime maillling. N0-removalll are requiired DcBo9GKhlMozMT8Fy8lqkZrrHucg3hkSqViPA13x1qEdxDt8tTNqMsFK7qY From simple-bounces@ietf.org Wed Jan 26 16:21:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21399; Wed, 26 Jan 2005 16:21:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtusU-0005f8-Hf; Wed, 26 Jan 2005 16:39:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtuOw-0000Pj-Nz; Wed, 26 Jan 2005 16:08:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtWxy-0000LM-8L; Tue, 25 Jan 2005 15:07:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03024; Tue, 25 Jan 2005 15:07:08 -0500 (EST) Received: from [64.151.105.12] (helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtXEk-0006BE-Bc; Tue, 25 Jan 2005 15:24:30 -0500 Received: from [10.0.1.5] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 25 Jan 2005 15:07:08 -0500 id 000B4085.41F6A6EC.0000520D Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Tue, 25 Jan 2005 15:07:03 -0500 To: "'geopriv@ietf.org'" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 26 Jan 2005 16:08:32 -0500 Cc: Simple WG Subject: [Simple] substitution groups vs. any elements X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit All, There remains one last, unresolved issue with draft-ietf-geopriv-common-policy, and that is with regard to the usage of substitution groups (requiring derivation of elements) vs. any element. Many excellent points have been made for both cases, which leads Allison and I to believe that we are not all on the same page with respect to usage scenarios. Perhaps it would be best if we had some use cases for voice, IM, and emergency call routing to illustrate the need for one approach vs. the other. In each use case we should look to see if the using protocol gives us proper protocol/namespace/schema negotiation as to allow a sender to understand the capabilities of the receiver (which XML Schemas the receiver knows about) and if any privacy is compromised should the sender use elements not understood by the receiver. -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jan 27 04:59:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09472; Thu, 27 Jan 2005 04:59:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu6i3-0005Tx-1L; Thu, 27 Jan 2005 05:17:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu6Jb-0006b9-Ea; Thu, 27 Jan 2005 04:51:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu6I4-00068D-Ol for simple@megatron.ietf.org; Thu, 27 Jan 2005 04:50:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08071 for ; Thu, 27 Jan 2005 04:50:14 -0500 (EST) Received: from [220.117.211.170] (helo=www.nablecomm.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu6ZA-00058R-Fv for simple@ietf.org; Thu, 27 Jan 2005 05:07:57 -0500 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="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jan 2005 18:49:56 +0900 Message-ID: <1BA77CA730953F44B2684FD426A30D65284F1B@WWW.nablecomm.com> Thread-Topic: Presence Event Package..Amount of State to be Conveyed.. Thread-Index: AcUDyqlO3naThqhcTjaeRphRTNPqzwAitsoA From: =?ks_c_5601-1987?B?yLIgyKO/tQ==?= To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Subject: [Simple] Presence Event Package..Amount of State to be Conveyed.. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Hi, I have a question to you about presence event package. ---------------- In RFC3265.. 4.3. Amount of State to be Conveyed There are two possible solutions to this problem that event packages may choose to implement.(Complete State Information / State Deltas) Then.. what is the choice of presence event package? ------------------------ In RFC3856 However, packages are mandated to provide detailed information on when to send a NOTIFY, how to compute the state of the resource, how to generate neutral or fake state information, and whether state information is complete or partial. This section describes those details for the presence event package.IN RFC3856 Where? There is no description about amount of state (complete or = partial). Please let me know.. Hi, I have a question to you about presence event package. =20 ---------------- In RFC3265.. 4.3. Amount of State to be Conveyed There are two possible solutions to this problem that event packages may choose to implement.(Complete State Information / State Deltas) =20 Then.. what is the choice of presence event package? ------------------------ In RFC3856 However, packages are mandated to provide detailed information on when to send a NOTIFY, how to compute the state of the resource, how to generate neutral or fake state information, and whether state information is complete or partial. This section describes those details for the presence event package.IN RFC3856 =20 =20 Where? There is no description about amount of state (complete or = partial). =20 Please let me know.. -----Original Message----- From: simple-request@ietf.org [mailto:simple-request@ietf.org]=20 Sent: Thursday, January 27, 2005 2:16 AM To: simple@ietf.org Subject: Simple Digest, Vol 9, Issue 31 Send Simple mailing list submissions to simple@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/simple or, via email, send a message with subject or body 'help' to simple-request@ietf.org You can reach the person managing the list at simple-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Simple digest..." _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jan 27 05:41:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13532; Thu, 27 Jan 2005 05:41:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu7Mu-0006YM-9c; Thu, 27 Jan 2005 05:59:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu6vm-0003I7-63; Thu, 27 Jan 2005 05:31:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu6rh-0001jW-4V for simple@megatron.ietf.org; Thu, 27 Jan 2005 05:27:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11951 for ; Thu, 27 Jan 2005 05:27:02 -0500 (EST) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu78l-00069X-B0 for simple@ietf.org; Thu, 27 Jan 2005 05:44:45 -0500 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id 40F60A9748; Thu, 27 Jan 2005 11:26:23 +0100 (CET) Received: from [192.168.1.45] (unknown [82.196.203.62]) by voyager.coretrek.no (Postfix) with ESMTP id 6568BA9709; Thu, 27 Jan 2005 11:25:55 +0100 (CET) In-Reply-To: <1BA77CA730953F44B2684FD426A30D65284F1B@WWW.nablecomm.com> References: <1BA77CA730953F44B2684FD426A30D65284F1B@WWW.nablecomm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=EUC-KR; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] Presence Event Package..Amount of State to be Conveyed.. Date: Thu, 27 Jan 2005 11:25:48 +0100 To: =?EUC-KR?B?yLIgyKO/tQ==?= X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable It is complete state information. Other work in progress internet drafts are trying to tackle the partial =20= notification problem: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify=20 -03.txt Regards, Hisham On Jan 27, 2005, at 10:49 AM, =C8=B2 =C8=A3=BF=B5 wrote: > Hi, I have a question to you about presence event package. > > ---------------- > In RFC3265.. > 4.3. Amount of State to be Conveyed > There are two possible solutions to this problem that event packages > may choose to implement.(Complete State Information / State Deltas) > > Then.. what is the choice of presence event package? > ------------------------ > In RFC3856 > However, packages are mandated to provide detailed information on > when to send a NOTIFY, how to compute the state of the resource, how > to generate neutral or fake state information, and whether state > information is complete or partial. This section describes those > details for the presence event package.IN RFC3856 > > > Where? There is no description about amount of state (complete or =20 > partial). > > Please let me know.. > Hi, I have a question to you about presence event package. > > > > ---------------- > > In RFC3265.. > > 4.3. Amount of State to be Conveyed > > There are two possible solutions to this problem that event packages > > may choose to implement.(Complete State Information / State Deltas) > > > > Then.. what is the choice of presence event package? > > ------------------------ > > In RFC3856 > > However, packages are mandated to provide detailed information on > > when to send a NOTIFY, how to compute the state of the resource, how > > to generate neutral or fake state information, and whether state > > information is complete or partial. This section describes those > > details for the presence event package.IN RFC3856 > > > > > > Where? There is no description about amount of state (complete or =20 > partial). > > > > Please let me know.. > > > > -----Original Message----- > From: simple-request@ietf.org [mailto:simple-request@ietf.org] > Sent: Thursday, January 27, 2005 2:16 AM > To: simple@ietf.org > Subject: Simple Digest, Vol 9, Issue 31 > > Send Simple mailing list submissions to > simple@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/simple > or, via email, send a message with subject or body 'help' to > simple-request@ietf.org > > You can reach the person managing the list at > simple-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Simple digest..." > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jan 27 13:28:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09192; Thu, 27 Jan 2005 13:28:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuEei-0002ks-V0; Thu, 27 Jan 2005 13:46:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuEFe-0001lJ-8I; Thu, 27 Jan 2005 13:20:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuE2u-00050g-Oc for simple@megatron.ietf.org; Thu, 27 Jan 2005 13:07:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07575 for ; Thu, 27 Jan 2005 13:07:05 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuEK5-0002G0-Cb for simple@ietf.org; Thu, 27 Jan 2005 13:24:53 -0500 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j0RI75O6000173; Thu, 27 Jan 2005 19:07:05 +0100 Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jan 2005 19:07:13 +0100 Received: from EAEDUMW004.eemea.ericsson.se ([148.135.25.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jan 2005 19:07:13 +0100 Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by EAEDUMW004.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jan 2005 19:07:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jan 2005 19:07:01 +0100 Message-ID: <2DC267ED40568D4F9AA4F5DF955AF16A11597F@esealmw107.eemea.ericsson.se> Thread-Topic: draft-ietf-simple-xcap-package-03 How to indicate that a document is deleted or a new document is added during a subscription Thread-Index: AcUEmwJ+S17zK2OrSLSpU14Pm3ZGsA== From: "Anders Lindgren C \(HF/EAB\)" To: , X-OriginalArrivalTime: 27 Jan 2005 18:07:10.0959 (UTC) FILETIME=[058E6FF0:01C5049B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Subject: [Simple] draft-ietf-simple-xcap-package-03 How to indicate that a document is deleted or a new document is added during a subscription X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Hello all; In the draft draft-ietf-simple-xcap-package-03 I find it hard to see if = and how it is possible to indicate that: 1) A document has been added to a watched user's tree during the = duration of the subscription. 2) A document has been deleted from a watched user's tree during the = duration of the subscription. Is a "deteted document" and an "added document" element missing or is it that every Notify also SHALL contain every unchanged existing = documents with New Etag=3Dprevious Etag and that the Subscriber can at = every Notify shall check the last received Notify to see if the document = baseline has been changed. A Notify will also be send as soon as a = document has been added deleted with all existing or does the draft contain a solution that I have missed? Best regrads Anders Lindgren _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 28 05:12:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14434; Fri, 28 Jan 2005 05:12:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuTOY-0000EO-0G; Fri, 28 Jan 2005 05:30:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuSxt-0002Zd-MI; Fri, 28 Jan 2005 05:02:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuSqT-0001oC-1B for simple@megatron.ietf.org; Fri, 28 Jan 2005 04:55:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13161 for ; Fri, 28 Jan 2005 04:55:14 -0500 (EST) From: krisztian.kiss@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuT7k-0008Ks-St for simple@ietf.org; Fri, 28 Jan 2005 05:13:10 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0S9tD804148 for ; Fri, 28 Jan 2005 11:55:13 +0200 (EET) X-Scanned: Fri, 28 Jan 2005 11:55:06 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j0S9t6lo012526 for ; Fri, 28 Jan 2005 11:55:06 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00Ias2Dl; Fri, 28 Jan 2005 11:54:56 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0S9stx03382 for ; Fri, 28 Jan 2005 11:54:55 +0200 (EET) Received: from sdebe101.NOE.Nokia.com ([172.19.222.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 Jan 2005 03:54:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jan 2005 01:54:44 -0800 Message-ID: Thread-Topic: Presence data model: in Thread-Index: AcUFH2Sc9MlWDlaET+qtPsZaNTHaPA== To: X-OriginalArrivalTime: 28 Jan 2005 09:54:54.0803 (UTC) FILETIME=[6B0C7230:01C5051F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Subject: [Simple] Presence data model: in X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable draft-ietf-simple-presence-data-model-01 allows to include a = or a list of s serving as correlation = identifier(s). Section 5.1.2 contains schema definition for including = , i.e.: I would assume that if appears under , another schema = definition would be required, something like: Should this extension be added to the draft? Thanks, Krisztian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 28 13:45:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28632; Fri, 28 Jan 2005 13:45:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CubOl-0004dQ-4C; Fri, 28 Jan 2005 14:03:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuaww-0003IU-Mc; Fri, 28 Jan 2005 13:34:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuamw-0000py-Ee for simple@megatron.ietf.org; Fri, 28 Jan 2005 13:24:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26696 for ; Fri, 28 Jan 2005 13:24:07 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cub4J-000445-CJ for simple@ietf.org; Fri, 28 Jan 2005 13:42:08 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 28 Jan 2005 10:32:06 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0SINgM8017899; Fri, 28 Jan 2005 10:23:42 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-124.cisco.com [10.86.240.124]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHI84333; Fri, 28 Jan 2005 10:23:43 -0800 (PST) Message-ID: <41FA2C65.4040305@cisco.com> Date: Fri, 28 Jan 2005 07:13:25 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] another try at data model compromise regarding unique service URI References: <41F33C72.2070306@cisco.com> <41F6D408.6080700@cisco.com> In-Reply-To: <41F6D408.6080700@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > > > Jonathan Rosenberg wrote: > >> I'll be responding to various messages in the threads we had on the >> modeling dispatchers topic. However, I concluded a few things from my >> previous compromise proposal (adding an i-belong-to element): >> >> 1. there was general agreement that i-belong-to was reasonable, since >> more information can't hurt >> >> 2. even with i-belong-to, there still seemed to be a desire to support >> non-unique contact URIs, when in fact part of the reason I had proposed >> i-belong-to was to retain that feature of the data model >> >> 3. There was (perhaps) some dispute about whether we need to resolve the >> issue of unique contact URI or not for the data model. I believe we do. >> I agree >> with the approach of pushing off composition for another document, but >> the issue of how we name and identify a service, and how you can or >> cannot select those services from a presence document, is central to the >> data model and needs to be resolved one way or another. >> >> 4. I appear to be in the losing minority on the issue of unique URI or >> not. It appears Aki and Henning still favor allowing multiple tuples >> with the same contact URI. I believe Markus and Paul do as well, but am >> not as certain. > > > I don't like it. But I find the alternatives worse. > > My feeling is that this is the way forward. What is "this" in the sentence above? >> 5. We've identified several real problems when you rely on things >> besides the URI to dispatch to the appropriate service: >> >> a. it doesnt work with an offerless invite, as in the case of 3pcc. >> Like it or not, this is a common case >> >> b. it doesnt work with cases where my initial SDP does not cause the >> appropriate dispatch, but a subsequent re-invite would. For example, I >> want to call your videophone, but I want to start with just audio so I >> can ask about adding video. > > > As Henning pointed out, those are only problems with dispatching based > on SDP. Dispatching based on something like method and event ID doesn't > suffer that problem. It could be an issue there too. One can imagine folks sending SUBSCRIBE on an existing dialog, and using INVITE for setting up the dialog. If dispatch to something that supports SUBSCRIBE is based on the initial request method, this won't work either. > > Dispatching based on callerprefs also doesn't - if the callerprefs are > present, and if you can figure out how to dispatch based on them. I > think it will be difficult to get them there. This is my point - if the watcher needs to use caller prefs to get the dispatch to happen, it needs to SAY that in the presence document. > >> 6. We agree to allow simple union-based composition. Henning has >> indicated that it is possible that the compositor doesn't understand the >> URI schemes in the contact. Thus, a union compositor might generate >> presence documents with two URI that are equal. Though I think this is >> quite unlikely, it is certainly possible. >> >> From these things, I concluded that (for reason 6 alone), the data model >> cannot outlaw two services from having the same URI. However, it begs >> the question of what does it *mean* when that happens. I think that we >> are not aligned on this yet. Henning made a statement in one of his >> notes that I believe captures the essence of the problem: >> >> Henning wrote: >> >>> There are the following possible cases, all with well-defined >>> behavior for the watcher: >> >> >> I don't think we want to specify the behavior of the watcher at all. > > > I don't think it has been the intent to normatively specify the behavior > of the watcher. I think this has simply been used as a use case to see > if what might plausibly be expected to happen has serious problems. I had read some of Hennings notes as suggesting that our objective was to make sure that watcher behavior was well-defined. I think its essential that we be clear that this is not the objective. > > So far, the problems have seemed to be limited in nature and more or > less expected under the circumstances. But of course it only remains for > another use case that is more problematic. > >> They should be able to do anything they want to with the data. The key >> to interop is to make the semantics of the data as unambiguous as >> possible. > > > Without invoking miracles. When the semantics are ambiguous, and nobody > knows better, best to leave them that way. > >> I think that, in the case of multiple services with the same URI, the >> meaning is ambiguous, and depending on what a watcher is interested >> in, might make different choices. Let me give an example. >> >> Lets take an example Aki gave during the SIMPLE meeting in November. >> He was interested in expressing this situation: a user has a >> multimedia UA that can do audio and IM. They want to indicate that >> they are available for IM, but not for audio. Let us say that they >> represent this by including two services in a document (i.e., two >> tuples) with the same contact (their AOR), but one indicating audio >> with prescaps, and a basic status of closed, and the other indicating >> just IM with prescaps, and a a basic status of open. > > > Well, I think this is not a good way to represent this situation. > But lets continue anyway, since lots of people seem to want to represent > it this way. Do you have an alternate suggestion? > >> We have touched on several possible meanings for the case of two >> tuples/services with the same URI: >> >> MEANING 1 (CONFLICT): These represent conflicting information about >> the same service; one or the other might be true >> >> MEANING 2 (DISPATCH): These represent different services, but are >> only reachable by a dispatcher (using unknown dispatch logic), and so >> an INVITE sent to the (which is the AOR), will reach one or >> the other > > > Or both (forking). This would leave it up to the recipient to choose > which one to use. > >> MEANING 3 (COMPONENT): These are one service, but the service has >> been disaggregated because of a desire to provide differing presence >> status for differing types of communication attempts (this is the >> meaning in the example) >> >> MEANING 4 (OVERRIDE): An attempt was made to override one service >> definition with another; however, the compositor foolishly placed them >> both in the document. As such, the more recent one is probably correct. >> >> I suspect that there are other meanings. >> >> So, let us consider the differing decisions a watcher might make, >> depending on which meaning it decides to attest to this document. Let us > > > Part of the problem may be simply assuming that a correct watcher is > free to make this choice as it wishes. I think we should simply require > watchers to act on this data as if was ambiguous what the meaning is. > Leave it to the watching User to ascribe meaning. Without additional meta-data there isn't much of an alternative. However, as I show below the wrong thing can definitely happen, and its prevented by being more explicit. > >> assume the watcher wishes to proceed with a multimedia call using as >> many media types as possible: >> >> MEANING 1 (CONFLICT): The watcher sends an INVITE with an offer >> including both audio and IM media streams, under the assumption that >> one or the other is supported and the presentity will reject one of >> the media streams >> >> MEANING 2 (DISPATCH): Since the service supporting IM is the only one >> available, the watcher wishes to avoid dispatching to the audio >> service. So, it sends an INVITE with only an IM media stream, hoping >> that the dispatch works correctly. >> >> MEANING 3 (COMPONENT): The watcher sends an INVITE with both audio and >> IM. It figures that perhaps the presentity will accept the audio >> stream anyway, and if not, just reject that stream and proceed with IM. >> >> MEANING 4 (OVERRIDE): The watcher sends an INVITE with whichever media >> type is indicated for the most recent tuple. >> >> >> As you can see, there is clearly a difference in watcher behavior, >> assuming a specific objective, depending on the semantics of multiple >> services with the same URI. >> >> So, in light of this, my specific proposal is that we allow for >> multiple services with the same URI, but in the data model very >> clearly define its meaning as *ambiguous*; > > > OK. I agree with this. Great. > >> additional tuple meta-data will normally need to be present to help >> clarify the actual meaning. As such, the data model would recommend >> against doing this without meta-data to further clarify. A watcher >> could NOT assume that constructing an INVITE compliant to the >> capabilities listed for a tuple would cause a dispatch to that tuple, >> as Aki has suggested. I think this is the kind of dangerous assumption >> that, as my examples above show, can be wrong depending on the actual >> meaning of this case. >> >> In the spirit of Robert's proposal, I would further propose not to >> pursue the extension yet. Let us further study >> composition and then figure out the right set of dispatcher >> characteristics we wish to model. > > > I agree. While there seems to be some value in the proposal, it feels > half baked. Right; as Henning points out it may be unneeded depending on where we go with gruu. > >> At this time, we could then make the following recommendations >> regarding what a PUA places into the element. Namely, if it >> has a GRUU, it puts that. If it doesn't, but it has **strong** >> awareness that its local IP address and port have the GRUU property, >> it uses that, else it places the AOR. >> >> If there are multiple PUA for an AOR, and a compositor in the presence >> engine, we can consider four cases roughly speaking. We have PUA that >> support GRUU (or have a local contact that has the GRUU property), or >> don't, and we have a compositor that just does union, or is smarter >> and combines the contacts together: >> >> GRUU-less PUA, union compositor: This tends to do the right thing. The >> resulting presence document includes multiple tuples, each of which >> uses the AOR. The presentity is at least reachable since the AOR is >> listed. >> >> GRUU PUA, smart compositor: The compositor can combine together the >> tuples, since it knows the GRUUs are all bound to the same AOR. It can >> thus list a single tuple (if it likes), with the AOR as the > > > How is it that the compositor knows the GRUUs are all bound to the same > AOR? It knows they are bound to the same domain, but AFAIK nothing more. I was assuming a compositor that had access to registration data. > >> GRUU PUA, union compositor: This produces a document that exposes the >> GRUU to the watcher. Still works fine, though it may not have been >> desireable to expose the GRUU to the watcher. >> >> GRUU-less PUA, smart compositor: The compositor can correlate the >> tuples together because they each use the AOR as the . >> However, because there is no GRUU, it can't as easily correlate each >> tuple with a registration that might exist for the UA that generated >> the PUBLISH. Such correlation would need to be supported through other >> tuple data. > > > Hmm. You mention the compositor correlating PUBLISH data from PUAs with > registration data. This is the first mention I have seen of that. Oh? The whole model we have is based on multiple sources of data... It is > certainly something that is possible in some cases. But seems to need > some scoping out. For instance, this assumes the PA knows the mapping > from presentity address to registrar AOR. (In lots of cases this is > easy, because it is the same. But some people may be thinking otherwise.) I think using the same AOR is definitely the right thing. > > Another case comes to mind: > > If the PUAs are GRUU-less, but know something about the compositor, they > might use their contact even though it is not a GRUU, and depend on the > compositor to replace it with the AOR, after having used it to correlate > with registrations. But this presumes the compositor somehow knows it > should do that. This seems like a weak and ugly case, but it might be a > pragmatic choice. I considered that, but this introduces the possibility of a mismatched client and compositor. If the client puts its contact in, and its something like 10.0.1.1, and the compositor does union, this is a systematic failure. > >> This is not ideal (the fourth case in particular), but it seems workable. >> >> Where does this leave us with override? I still feel strongly that it >> is a mistake to encode composition policy into the presence document >> itself. Therefore, the presence document is simply not the place to do >> anything special in support of override. In further support of >> Robert's proposal, since override is very much about composition, I >> propose that we simply defer this until we have properly defined >> policy documents for defining it. > > > Right. I have always thought that override was of more theoretical > interest than practical. > >> Can we move forward based on this? > > > I think so. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 28 13:46:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28662; Fri, 28 Jan 2005 13:46:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CubPU-0004eF-D6; Fri, 28 Jan 2005 14:04:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuawx-0003Im-LG; Fri, 28 Jan 2005 13:34:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuamz-0000rp-HU for simple@megatron.ietf.org; Fri, 28 Jan 2005 13:24:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26705 for ; Fri, 28 Jan 2005 13:24:10 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cub4L-00044B-4G for simple@ietf.org; Fri, 28 Jan 2005 13:42:11 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 28 Jan 2005 11:33:03 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0SINbNt025024; Fri, 28 Jan 2005 10:23:38 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-124.cisco.com [10.86.240.124]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHI84317; Fri, 28 Jan 2005 10:23:36 -0800 (PST) Message-ID: <41FA2991.9090505@cisco.com> Date: Fri, 28 Jan 2005 07:01:21 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: multiple person elements, was: Re: [Simple] presence-rules: Selecting on class References: <41F06687.5010504@cisco.com> <41F11F84.6000206@lucent.com> <41F1B4F8.20801@cs.columbia.edu> <41F3592D.90208@lucent.com> In-Reply-To: <41F3592D.90208@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit inline. Vijay K. Gurbani wrote: > Henning Schulzrinne wrote: > >> Vijay: >> >> we had this discussion, at length, in DC. The problem is that the >> composer is a program, with at best limited rule-based intelligence, >> while the watcher is often staffed with a real human being that can, in > > > Prof. Schulzrinne: > > Thanks. I was just seeing if there is any wiggle room left, but > since this is a closed issue, I will shut up now. > > I will like to request though, if possible, that the reason why > we are allowing multiple person elements be explained in the > draft. Often times, it helps if the reader (or developer) > of a protocol knows why decisions were made in a certain manner. I think the discussion is similar to the one that needs to be there for services. Why would you have multiple service elements? Why multiple person elements? Well, the answer in both cases is that the meaning is "ambiguous" and there are at least several known reasons why this might occur: 1. conflicting data provided by multiple sources 2. failed override attempt 3. some kind of capability expression the way to disambiguate is through meta-data that needs to be defined in extensions to Pidf, of which we have none at the moment. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 28 13:49:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28881; Fri, 28 Jan 2005 13:49:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CubSo-0004i7-P9; Fri, 28 Jan 2005 14:07:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuawy-0003J4-Et; Fri, 28 Jan 2005 13:34:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuan0-0000sD-7U for simple@megatron.ietf.org; Fri, 28 Jan 2005 13:24:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26708 for ; Fri, 28 Jan 2005 13:24:11 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cub4N-00044B-MG for simple@ietf.org; Fri, 28 Jan 2005 13:42:12 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 28 Jan 2005 11:33:07 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0SINgNt025053; Fri, 28 Jan 2005 10:23:42 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-124.cisco.com [10.86.240.124]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHI84326; Fri, 28 Jan 2005 10:23:41 -0800 (PST) Message-ID: <41FA2A8C.9000109@cisco.com> Date: Fri, 28 Jan 2005 07:05:32 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] another try at data model compromise regarding unique service URI References: <41F33C72.2070306@cisco.com> <41F3F2B6.1020309@cs.columbia.edu> In-Reply-To: <41F3F2B6.1020309@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> 5. We've identified several real problems when you rely on things >> besides the URI to dispatch to the appropriate service: >> >> >> a. it doesnt work with an offerless invite, as in the case of 3pcc. >> Like it or not, this is a common case > > > This assumes that SDP is used for service selection. This is not a > problem if caller preferences or similar mechanisms that do not involve > offer-answer are used (e.g., request routing based on MESSAGE vs. INVITE). Yes. However, the use case of SDP-based dispatch was raised several times. > > >> >> b. it doesnt work with cases where my initial SDP does not cause the >> appropriate dispatch, but a subsequent re-invite would. For example, I >> want to call your videophone, but I want to start with just audio so I >> can ask about adding video. > > > This is either solved by caller preferences or kin, or is a generic > problem that even presence can't solve (if I initially select audio-only > capabilities). This has little to do with URIs. It has everything to do with being explicit vs. making implicit assumptions about what needs to do in order to dispatch. My proposal is that whatever we decide - caller prefs, SDP, or whatever, we make it explicit what the watcher needs to do. > >> From these things, I concluded that (for reason 6 alone), the data model >> cannot outlaw two services from having the same URI. However, it begs >> the question of what does it *mean* when that happens. I think that we >> are not aligned on this yet. Henning made a statement in one of his >> notes that I believe captures the essence of the problem: >> >> Henning wrote: >> >>> There are the following possible cases, all with well-defined >>> behavior for the watcher: >> >> >> >> I don't think we want to specify the behavior of the watcher at all. > > > I think we're not that far apart. The meaning to the watcher has to be > clear - even if that meaning has a "cannot say reliably whether A or B > is true". Right. > > >> As you can see, there is clearly a difference in watcher behavior, >> assuming a specific objective, depending on the semantics of multiple >> services with the same URI. >> >> So, in light of this, my specific proposal is that we allow for >> multiple services with the same URI, but in the data model very >> clearly define its meaning as *ambiguous*; additional tuple meta-data >> will normally need to be present to help clarify the actual meaning. >> As such, the data model would recommend against doing this without >> meta-data to further clarify. A watcher could NOT assume that >> constructing an INVITE compliant to the capabilities listed for a >> tuple would cause a dispatch to that tuple, as Aki has suggested. I >> think this is the kind of dangerous assumption that, as my examples >> above show, can be wrong depending on the actual meaning of this case. >> >> In the spirit of Robert's proposal, I would further propose not to >> pursue the extension yet. Let us further study >> composition and then figure out the right set of dispatcher >> characteristics we wish to model. > > > With the GRUU discussion and suggestions ("should generally identify AOR > it belong to") by Paul, this may also not be necessary in a subset of > cases. Fair point; we seem to be heading that direction in the gruu discussions. > > >> >> At this time, we could then make the following recommendations >> regarding what a PUA places into the element. Namely, if it >> has a GRUU, it puts that. If it doesn't, but it has **strong** >> awareness that its local IP address and port have the GRUU property, >> it uses that, else it places the AOR. >> >> If there are multiple PUA for an AOR, and a compositor in the presence >> engine, we can consider four cases roughly speaking. We have PUA that >> support GRUU (or have a local contact that has the GRUU property), or >> don't, and we have a compositor that just does union, or is smarter >> and combines the contacts together: >> >> GRUU-less PUA, union compositor: This tends to do the right thing. The >> resulting presence document includes multiple tuples, each of which >> uses the AOR. The presentity is at least reachable since the AOR is >> listed. >> >> GRUU PUA, smart compositor: The compositor can combine together the >> tuples, since it knows the GRUUs are all bound to the same AOR. It can >> thus list a single tuple (if it likes), with the AOR as the >> >> GRUU PUA, union compositor: This produces a document that exposes the >> GRUU to the watcher. Still works fine, though it may not have been >> desireable to expose the GRUU to the watcher. >> >> GRUU-less PUA, smart compositor: The compositor can correlate the >> tuples together because they each use the AOR as the . >> However, because there is no GRUU, it can't as easily correlate each >> tuple with a registration that might exist for the UA that generated >> the PUBLISH. Such correlation would need to be supported through other >> tuple data. >> >> >> This is not ideal (the fourth case in particular), but it seems workable. >> >> Where does this leave us with override? I still feel strongly that it >> is a mistake to encode composition policy into the presence document >> itself. Therefore, the presence document is simply not the place to do >> anything special in support of override. In further support of >> Robert's proposal, since override is very much about composition, I >> propose that we simply defer this until we have properly defined >> policy documents for defining it. >> >> Can we move forward based on this? > > > Yes, this seems straightforward. Great, thanks. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 28 13:50:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28955; Fri, 28 Jan 2005 13:50:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CubTh-0004jO-Qp; Fri, 28 Jan 2005 14:08:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuawz-0003Jk-AX; Fri, 28 Jan 2005 13:34:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuan9-0000um-3f for simple@megatron.ietf.org; Fri, 28 Jan 2005 13:24:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26713 for ; Fri, 28 Jan 2005 13:24:20 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cub4U-00044S-HS for simple@ietf.org; Fri, 28 Jan 2005 13:42:21 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 28 Jan 2005 10:24:55 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0SINl1M027768; Fri, 28 Jan 2005 10:23:47 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-124.cisco.com [10.86.240.124]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHI84338; Fri, 28 Jan 2005 10:23:45 -0800 (PST) Message-ID: <41FA2D02.3020008@cisco.com> Date: Fri, 28 Jan 2005 07:16:02 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] another try at data model compromise regarding unique service URI References: <41F33C72.2070306@cisco.com> <41F778F5.8040004@nokia.com> In-Reply-To: <41F778F5.8040004@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit inline. Aki Niemi wrote: > Inline. > > ext Jonathan Rosenberg wrote: > > ...snip... > >> We have touched on several possible meanings for the case of two >> tuples/services with the same URI: >> >> MEANING 1 (CONFLICT): These represent conflicting information about >> the same service; one or the other might be true >> >> MEANING 2 (DISPATCH): These represent different services, but are >> only reachable by a dispatcher (using unknown dispatch logic), and so >> an INVITE sent to the (which is the AOR), will reach one or >> the other >> >> MEANING 3 (COMPONENT): These are one service, but the service has >> been disaggregated because of a desire to provide differing presence >> status for differing types of communication attempts (this is the >> meaning in the example) >> >> MEANING 4 (OVERRIDE): An attempt was made to override one service >> definition with another; however, the compositor foolishly placed them >> both in the document. As such, the more recent one is probably correct. > > > I guess you're right. I was hoping we would be able to come to an > agreement, picking just one of these meanings (preferably #3) and rule > out all others. I think we have a lot of work to do to scope out #3. As Paul hinted as well, I'm not even sure viewing them as separate tuples is the right way to go. But let us debate this later. In the spirit of Robert's proposal, we need to gain some real world usage scenarios and requirements before working this stuff. However, as I read further and as I understand it, your > proposal is just a different means to an end -- that is, exact meaning > will need to be prescribed through meta-data in each tuple. And that is > fine, as long as we define exactly what this meta-data is. Right. And we may or may not define it later... > >> I suspect that there are other meanings. >> >> So, let us consider the differing decisions a watcher might make, >> depending on which meaning it decides to attest to this document. Let >> us assume the watcher wishes to proceed with a multimedia call using >> as many media types as possible: >> >> MEANING 1 (CONFLICT): The watcher sends an INVITE with an offer >> including both audio and IM media streams, under the assumption that >> one or the other is supported and the presentity will reject one of >> the media streams >> >> MEANING 2 (DISPATCH): Since the service supporting IM is the only one >> available, the watcher wishes to avoid dispatching to the audio >> service. So, it sends an INVITE with only an IM media stream, hoping >> that the dispatch works correctly. >> >> MEANING 3 (COMPONENT): The watcher sends an INVITE with both audio and >> IM. It figures that perhaps the presentity will accept the audio >> stream anyway, and if not, just reject that stream and proceed with IM. >> >> MEANING 4 (OVERRIDE): The watcher sends an INVITE with whichever media >> type is indicated for the most recent tuple. >> >> >> As you can see, there is clearly a difference in watcher behavior, >> assuming a specific objective, depending on the semantics of multiple >> services with the same URI. >> >> So, in light of this, my specific proposal is that we allow for >> multiple services with the same URI, but in the data model very >> clearly define its meaning as *ambiguous*; additional tuple meta-data >> will normally need to be present to help clarify the actual meaning. > > > Exactly, so far so good. > >> As such, the data model would recommend against doing this without >> meta-data to further clarify. A watcher could NOT assume that >> constructing an INVITE compliant to the capabilities listed for a >> tuple would cause a dispatch to that tuple, as Aki has suggested. I >> think this is the kind of dangerous assumption that, as my examples >> above show, can be wrong depending on the actual meaning of this case. > > > All right, but if not capability description, as in method=MESSAGE, what > meta-data would one put in a pair of tuples to indicate that indeed a > MESSAGE will be appreciated in this AOR, while an INVITation for voice > won't (because I'm in a meeting)? INVITE > > ...snip... > >> Can we move forward based on this? > > > Yes, I think so. Perhaps a rough edge or two to smooth out, but this is > an acceptable approach. Can you elaborate on those edges? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 28 14:11:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02695; Fri, 28 Jan 2005 14:11:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cuboa-0005QO-QF; Fri, 28 Jan 2005 14:29:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CubUc-00038n-Uo; Fri, 28 Jan 2005 14:09:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CubLx-0001Rt-TE for simple@megatron.ietf.org; Fri, 28 Jan 2005 14:00:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00253 for ; Fri, 28 Jan 2005 14:00:20 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CubdL-00054X-SC for simple@ietf.org; Fri, 28 Jan 2005 14:18:20 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j0SIxmue023526; Fri, 28 Jan 2005 12:59:48 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j0SIxmi05190; Fri, 28 Jan 2005 12:59:48 -0600 (CST) Message-ID: <41FA8BA4.4050903@lucent.com> Date: Fri, 28 Jan 2005 12:59:48 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: multiple person elements, was: Re: [Simple] presence-rules: Selecting on class References: <41F06687.5010504@cisco.com> <41F11F84.6000206@lucent.com> <41F1B4F8.20801@cs.columbia.edu> <41F3592D.90208@lucent.com> <41FA2991.9090505@cisco.com> In-Reply-To: <41FA2991.9090505@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: vkg> I will like to request though, if possible, that the reason why vkg> we are allowing multiple person elements be explained in the vkg> draft. Often times, it helps if the reader (or developer) vkg> of a protocol knows why decisions were made in a certain manner. jdr> jdr> jdr> I think the discussion is similar to the one that needs to be jdr> there for services. Why would you have multiple service elements? jdr> Why multiple person elements? Jonathan: Logically, having multiple instances of the service tuple makes sense. After all, a person _can_ have multiple services. Sure, some of the service tuples may be a result of ambiguity, but others will not, and will represent discrete services available to the person. Whereas, all our lives we are taught that each person is unique ;-) Think of a developer making sense of the PDM and the XML that has to be generated for it; multiple person elements may only serve to confuse the poor developer who may not be fully aware of the implications on why this is so. jdr> Well, the answer in both cases is that the meaning is jdr> "ambiguous" and there are at least several known reasons why jdr> this might occur: jdr> jdr> 1. conflicting data provided by multiple sources jdr> 2. failed override attempt jdr> 3. some kind of capability expression jdr> jdr> the way to disambiguate is through meta-data that needs to be jdr> defined in extensions to Pidf, of which we have none at the moment. I believe that we have some meta-data in the form of prescaps; we probably need to scratch the surface to figure out what other meta-data makes sense. 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-bounces@ietf.org Fri Jan 28 15:02:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07465; Fri, 28 Jan 2005 15:02:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CucbA-0006f8-2M; Fri, 28 Jan 2005 15:20:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CucFE-0006rF-2G; Fri, 28 Jan 2005 14:57:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuc7z-0005IV-HS for simple@megatron.ietf.org; Fri, 28 Jan 2005 14:49:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06585 for ; Fri, 28 Jan 2005 14:49:57 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CucPM-0006Pg-Vr for simple@ietf.org; Fri, 28 Jan 2005 15:07:58 -0500 Received: from razor.cs.columbia.edu (IDENT:nihEV91XXjUZ2fSlJ+TJr/lHLKqVUTAK@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0SJmiir024565 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 28 Jan 2005 14:48:44 -0500 (EST) Received: from [127.0.0.1] (IDENT:BKYUw0FQ5htAm872giScmcVoi+AImqLg@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0SJmgiw006270; Fri, 28 Jan 2005 14:48:43 -0500 Message-ID: <41FA96FD.2010405@cs.columbia.edu> Date: Fri, 28 Jan 2005 14:48:13 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: multiple person elements, was: Re: [Simple] presence-rules: Selecting on class References: <41F06687.5010504@cisco.com> <41F11F84.6000206@lucent.com> <41F1B4F8.20801@cs.columbia.edu> <41F3592D.90208@lucent.com> <41FA2991.9090505@cisco.com> In-Reply-To: <41FA2991.9090505@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.28.4 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: "Vijay K. Gurbani" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit > the way to disambiguate is through meta-data that needs to be defined in > extensions to Pidf, of which we have none at the moment. I'm not sure I completely agree. I would consider notes and timestamps to be 'meta data' in this context which, in some cases, will allow the recipient to make reasonable judgements if presented with conflicting information. I wish we had more such data, but there's a limited supply of "hard" metadata. The only major item we're missing is probably a better description of the source of the data (calendar vs. manual entry vs. a device vs. compositor). Other meta data is likely to be "soft", e.g., indications of likelihood of correctness. Given that people still play PowerBall, I wouldn't put too much stock in people getting probabilities right. > > Thanks, > Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 28 17:11:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25994; Fri, 28 Jan 2005 17:11:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuecQ-0003oF-5X; Fri, 28 Jan 2005 17:29:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cue7F-0004Ab-6t; Fri, 28 Jan 2005 16:57:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cue0S-0006gy-G0 for simple@megatron.ietf.org; Fri, 28 Jan 2005 16:50:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23057 for ; Fri, 28 Jan 2005 16:50:17 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CueHr-0002oR-CH for simple@ietf.org; Fri, 28 Jan 2005 17:08:19 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 28 Jan 2005 16:49:49 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0SLnjW0028572; Fri, 28 Jan 2005 16:49:45 -0500 (EST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOR60725; Fri, 28 Jan 2005 16:49:41 -0500 (EST) Message-ID: <41FAB375.3070108@cisco.com> Date: Fri, 28 Jan 2005 16:49:41 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] another try at data model compromise regarding unique service URI References: <41F33C72.2070306@cisco.com> <41F6D408.6080700@cisco.com> <41FA2C65.4040305@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit Inline. Trimmed out stuff I didn't comment on. Paul Jonathan Rosenberg wrote: > Paul Kyzivat wrote: >> Jonathan Rosenberg wrote: >> >>> I'll be responding to various messages in the threads we had on the >>> modeling dispatchers topic. However, I concluded a few things from my >>> previous compromise proposal (adding an i-belong-to element): >>> >>> 1. there was general agreement that i-belong-to was reasonable, since >>> more information can't hurt >>> >>> 2. even with i-belong-to, there still seemed to be a desire to support >>> non-unique contact URIs, when in fact part of the reason I had proposed >>> i-belong-to was to retain that feature of the data model >>> >>> 3. There was (perhaps) some dispute about whether we need to resolve the >>> issue of unique contact URI or not for the data model. I believe we do. >>> I agree >>> with the approach of pushing off composition for another document, but >>> the issue of how we name and identify a service, and how you can or >>> cannot select those services from a presence document, is central to the >>> data model and needs to be resolved one way or another. >>> >>> 4. I appear to be in the losing minority on the issue of unique URI or >>> not. It appears Aki and Henning still favor allowing multiple tuples >>> with the same contact URI. I believe Markus and Paul do as well, but am >>> not as certain. >> >> I don't like it. But I find the alternatives worse. >> >> My feeling is that this is the way forward. > > What is "this" in the sentence above? this = "allowing multiple tuples with the same contact URI". It seemed obvious to me at the time, but in retrospect it isn't. >>> I think that, in the case of multiple services with the same URI, the >>> meaning is ambiguous, and depending on what a watcher is interested >>> in, might make different choices. Let me give an example. >>> >>> Lets take an example Aki gave during the SIMPLE meeting in November. >>> He was interested in expressing this situation: a user has a >>> multimedia UA that can do audio and IM. They want to indicate that >>> they are available for IM, but not for audio. Let us say that they >>> represent this by including two services in a document (i.e., two >>> tuples) with the same contact (their AOR), but one indicating audio >>> with prescaps, and a basic status of closed, and the other indicating >>> just IM with prescaps, and a a basic status of open. >> >> Well, I think this is not a good way to represent this situation. >> But lets continue anyway, since lots of people seem to want to >> represent it this way. > > Do you have an alternate suggestion? I have a different way to represent the situation in the first place, that I prefer: The UA only publishes one tuple, regardless of its status. It uses prescaps to indicate the availability (or not) of both Audio and IM. It indicates it is OPEN if it is available for anything. Note that there is a case to be made that the tuple should be OPEN if it can do anything - perhaps just respond to OPTIONS. So it may be the case that it is OPEN, but not available for either Audio or IM. >>> At this time, we could then make the following recommendations >>> regarding what a PUA places into the element. Namely, if it >>> has a GRUU, it puts that. If it doesn't, but it has **strong** >>> awareness that its local IP address and port have the GRUU property, >>> it uses that, else it places the AOR. >>> >>> If there are multiple PUA for an AOR, and a compositor in the >>> presence engine, we can consider four cases roughly speaking. We have >>> PUA that support GRUU (or have a local contact that has the GRUU >>> property), or don't, and we have a compositor that just does union, >>> or is smarter and combines the contacts together: >>> >>> GRUU-less PUA, union compositor: This tends to do the right thing. >>> The resulting presence document includes multiple tuples, each of >>> which uses the AOR. The presentity is at least reachable since the >>> AOR is listed. >>> >>> GRUU PUA, smart compositor: The compositor can combine together the >>> tuples, since it knows the GRUUs are all bound to the same AOR. It >>> can thus list a single tuple (if it likes), with the AOR as the >>> >> >> How is it that the compositor knows the GRUUs are all bound to the >> same AOR? It knows they are bound to the same domain, but AFAIK >> nothing more. > > I was assuming a compositor that had access to registration data. The public registration data (available via reg package), or the complete set of private registration data. The current reg package doesn't give info on GRUUs, so you wouldn't be able to figure this out from that. >>> GRUU PUA, union compositor: This produces a document that exposes the >>> GRUU to the watcher. Still works fine, though it may not have been >>> desireable to expose the GRUU to the watcher. >>> >>> GRUU-less PUA, smart compositor: The compositor can correlate the >>> tuples together because they each use the AOR as the . >>> However, because there is no GRUU, it can't as easily correlate each >>> tuple with a registration that might exist for the UA that generated >>> the PUBLISH. Such correlation would need to be supported through >>> other tuple data. >> >> Hmm. You mention the compositor correlating PUBLISH data from PUAs >> with registration data. This is the first mention I have seen of that. > > Oh? The whole model we have is based on multiple sources of data... Sure it has always been a potential. But we had never gotten into such specifics. If it becomes *necessary* to access registration data to make a compositor, then we had better make that very clear. >> It is >> certainly something that is possible in some cases. But seems to need >> some scoping out. For instance, this assumes the PA knows the mapping >> from presentity address to registrar AOR. (In lots of cases this is >> easy, because it is the same. But some people may be thinking otherwise.) > > I think using the same AOR is definitely the right thing. I gather that various people have in mind a Presence Server that is independent of the SIP provider. In that case the registration info may not be readily accessible. Mapping from presentity address to sip AoR may be available of PS is *subscribing* for presence data of the SIP AoR, but may not be if it is relying on PUBLISH to learn this. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 28 17:41:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28056; Fri, 28 Jan 2005 17:41:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cuf5T-0004UL-4g; Fri, 28 Jan 2005 17:59:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuefe-0004hr-93; Fri, 28 Jan 2005 17:32:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cueb5-0003NS-M8 for simple@megatron.ietf.org; Fri, 28 Jan 2005 17:28:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27317 for ; Fri, 28 Jan 2005 17:28:09 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuesV-0004EV-76 for simple@ietf.org; Fri, 28 Jan 2005 17:46:11 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j0SMQSgQ025014; Fri, 28 Jan 2005 16:26:28 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j0SMQRi17809; Fri, 28 Jan 2005 16:26:27 -0600 (CST) Message-ID: <41FABC13.1010108@lucent.com> Date: Fri, 28 Jan 2005 16:26:27 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg , Paul Kyzivat , Henning Schulzrinne , aki.niemi@nokia.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: [Simple] Data model compromise regarding unique service URI: summary so far X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Folks: I have been trying to keep notes on the discussion we have been having on Jonathan's compromise email on the unique service URI and its follow ups. This is the summary of that discussion so far; interspersed with it are some other observations worth documenting. These points, at the very least, indicate how the design of the PDM is influenced by our understanding of the problem. Please look through them for sanity: 1) Everyone agrees on this: we allow for multiple services with the same URI, but in the data model very clearly define its meaning as *ambiguous*; additional tuple meta-data will normally need to be present to help clarify the actual meaning. As such, the data model would recommend against doing this without meta-data to further clarify (JDR). 2) Regarding meta-data, PIDF "notes" and "timestamps" elements are a form of meta-data. We wish there was more meta-data, but there is a limited supply of "hard" meta-data. The only major item we're missing is probably a better description of the source of the data (calendar vs. manual entry vs. a device vs. compositor). Other meta data is likely to be "soft", e.g., indications of likelihood of correctness (HGS). We also have some meta-data in form of prescaps. 3) Watcher behavior: Do we want to define the behavior of a watcher? Yes (HGS), No (JDR, PK). 4) Composition: Composers are allowed to be smart, but we cannot force them to be. The problem is that the composer is a program, with at best limited rule-based intelligence, while the watcher is often staffed with a real human being that can, in many cases, make sense of conflicting information based on external knowledge ("I know that Alice is on vacation right now, so the location information placing her at home in this person entry must be from the cell phone she left at home.") (HGS). 5) Composition redux: We do not know enough about composition to prescribe a certain algorithm or manner of composing. The best we can do right now is to specify a union policy as the default composition policy. Smart composers can do more, but what that "more" is a function of the composer. 6) Composition redux II: Is it a requirement that a compositor have access to registration data? 6) Dispatching: Dispatching is a problem. We cannot do it based on SDP since there may not be an SDP in an INVITE. Dispatching based on something like method and event ID may run into problems as well. One can imagine folks sending SUBSCRIBE on an existing dialog, and using INVITE for setting up the dialog. If dispatch to something that supports SUBSCRIBE is based on the initial request method, this won't work either. Dispatching based on caller-prefs is a possibility, but how would a watcher indicate preference for caller-prefs in a document? 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-bounces@ietf.org Sat Jan 29 05:26:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28179; Sat, 29 Jan 2005 05:26:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cuq61-00007U-N0; Sat, 29 Jan 2005 05:44:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cupl8-0005qR-8b; Sat, 29 Jan 2005 05:23:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cupjw-0005ZY-3n for simple@megatron.ietf.org; Sat, 29 Jan 2005 05:22:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27882 for ; Sat, 29 Jan 2005 05:21:56 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cuq1M-0008UI-Sc for simple@ietf.org; Sat, 29 Jan 2005 05:40:05 -0500 Received: from razor.cs.columbia.edu (IDENT:2mZbbZx0ss02xpx0/0zMZ4iBnXG0p5Di@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0TALrir010946 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 29 Jan 2005 05:21:54 -0500 (EST) Received: from [127.0.0.1] (IDENT:1fzxSciy9/NH4sHxm5kVgCMAOZAzLiVL@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j0TALpiw011329; Sat, 29 Jan 2005 05:21:52 -0500 Message-ID: <41FB63A2.8010509@cs.columbia.edu> Date: Sat, 29 Jan 2005 05:21:22 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <41FABC13.1010108@lucent.com> In-Reply-To: <41FABC13.1010108@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.29.0 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: [Simple] Re: Data model compromise regarding unique service URI: summary so far X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit > 3) Watcher behavior: Do we want to define the behavior of a > watcher? Yes (HGS), No (JDR, PK). I think this is mainly a difference of wording, not opinion. I think we can agree that the information delivered to the watcher should be precise enough so that it can behave predictably. This includes the case where it may simply have to deliver the information to the human watcher with an indication of "I don't know which view is correct". > > 4) Composition: Composers are allowed to be smart, but we cannot > force them to be. The problem is that the composer is a program, > with at best limited rule-based intelligence, while the watcher > is often staffed with a real human being that can, in many > cases, make sense of conflicting information based on external > knowledge ("I know that Alice is on vacation right now, so > the location information placing her at home in this person > entry must be from the cell phone she left at home.") (HGS). > > 5) Composition redux: We do not know enough about composition > to prescribe a certain algorithm or manner of composing. The > best we can do right now is to specify a union policy as the > default composition policy. Smart composers can do more, but > what that "more" is a function of the composer. > > 6) Composition redux II: Is it a requirement that a compositor > have access to registration data? > > 6) Dispatching: Dispatching is a problem. We cannot do it based > on SDP since there may not be an SDP in an INVITE. Dispatching > based on something like method and event ID may run into problems > as well. One can imagine folks sending SUBSCRIBE on an existing > dialog, and using INVITE for setting up the dialog. If dispatch > to something that supports SUBSCRIBE is based on the initial > request method, this won't work either. Dispatching based on > caller-prefs is a possibility, but how would a watcher indicate > preference for caller-prefs in a document? There are probably two options here: (1) Usage of prescaps indicates ability to support caller preferences. (2) Additional flag in prescaps that indicates such support. I think (2) would be better. After all, support of caller preferences is itself a capability. It seems easy enough to add this to the prescaps work. > > Thanks, > > - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jan 30 07:44:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26472; Sun, 30 Jan 2005 07:44:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvEj4-0000FN-Cp; Sun, 30 Jan 2005 08:02:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvEQY-0006qz-NF; Sun, 30 Jan 2005 07:43:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvEOo-0006ed-Cc for simple@megatron.ietf.org; Sun, 30 Jan 2005 07:41:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26251 for ; Sun, 30 Jan 2005 07:41:53 -0500 (EST) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvEgY-0008UB-4v for simple@ietf.org; Sun, 30 Jan 2005 08:00:14 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IB40092PR5482@dns1.cselt.it> for simple@ietf.org; Sun, 30 Jan 2005 13:39:05 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Sun, 30 Jan 2005 13:43:51 +0100 Date: Sun, 30 Jan 2005 13:40:45 +0100 From: Goix Walter Subject: RE: [Simple] Presence data model: in To: krisztian.kiss@nokia.com, simple@ietf.org Message-id: <91C9464F6AFC0647A2D8069E25DBF496A8F570@EXC01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: Presence data model: in thread-index: AcUFH2Sc9MlWDlaET+qtPsZaNTHaPABqYYj1 Content-Class: urn:content-classes:message X-OriginalArrivalTime: 30 Jan 2005 12:43:51.0625 (UTC) FILETIME=[59E43B90:01C506C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Krisztian, The examples in the presence data model draft identify as an = element under , but that's probably what you had in mind.=20 However, I don't clearly see the rationale for multiple = within a single . Multiple devices for the same presentity may = offer exactly the same service, but they probably would need no = element to get the ability to be merged into a single = at the server. In that case, if one device updates its inserting = a element (max 1 in PIDF ), then both tuples will need = to be separated again. Same if another property of a single device = is updated. I personally see more complications than benefits = allowing multiple per . Is there a real requirement = for such an optimization?=20 I agree that no namespace nor schema is defined for this extension. = Maybe the following declaration could be used: Walter -----Original Message----- From: simple-bounces@ietf.org on behalf of krisztian.kiss@nokia.com Sent: Fri 1/28/2005 10:54 AM To: simple@ietf.org Subject: [Simple] Presence data model: in =20 draft-ietf-simple-presence-data-model-01 allows to include a = or a list of s serving as correlation = identifier(s). Section 5.1.2 contains schema definition for including = , i.e.: I would assume that if appears under , another schema = definition would be required, something like: Should this extension be added to the draft? Thanks, Krisztian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 31 10:15:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10750; Mon, 31 Jan 2005 10:15:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvdZF-0005qU-Ra; Mon, 31 Jan 2005 10:34:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvd4q-00087r-Ux; Mon, 31 Jan 2005 10:02:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvd03-00078Z-Ma for simple@megatron.ietf.org; Mon, 31 Jan 2005 09:57:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08639 for ; Mon, 31 Jan 2005 09:57:58 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvdHz-0005Qk-6e for simple@ietf.org; Mon, 31 Jan 2005 10:16:33 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0VEvrc20216; Mon, 31 Jan 2005 16:57:53 +0200 (EET) X-Scanned: Mon, 31 Jan 2005 16:57:39 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j0VEvdB4013829; Mon, 31 Jan 2005 16:57:39 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00g9yrLR; Mon, 31 Jan 2005 16:57:39 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0VEvFU29737; Mon, 31 Jan 2005 16:57:15 +0200 (EET) Received: from [172.21.39.180] ([172.21.39.180]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 31 Jan 2005 16:56:09 +0200 Message-ID: <41FE4707.8030602@nokia.com> Date: Mon, 31 Jan 2005 16:56:07 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Simple] another try at data model compromise regarding unique service URI References: <41F33C72.2070306@cisco.com> <41F778F5.8040004@nokia.com> <41FA2D02.3020008@cisco.com> In-Reply-To: <41FA2D02.3020008@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2005 14:56:09.0158 (UTC) FILETIME=[FF716660:01C507A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit ext Jonathan Rosenberg wrote: ...snip... >> I guess you're right. I was hoping we would be able to come to an >> agreement, picking just one of these meanings (preferably #3) and rule >> out all others. > > > I think we have a lot of work to do to scope out #3. As Paul hinted as > well, I'm not even sure viewing them as separate tuples is the right way > to go. But let us debate this later. In the spirit of Robert's proposal, > we need to gain some real world usage scenarios and requirements before > working this stuff. At this point I'm not too hung up on the idea of separate tuples either. But to me it seems like the cleanest (if not the only) way to enable things like: "I am open for IM, but busy for voice". Since I guess a tuple is still supposed to share the basic status, or will we need to now group all things OPEN into one tuple, and all things CLOSED into one? Yuck! Unless you are disagreeing with me that this is a real world usage scenario? ...snip... > Can you elaborate on those edges? Edge 1: moving from saying "non-unique contacts are forbidden" to "non-unique contacts are allowed but meaningless without meta-data to give explicit meaning" and then not defining this meta-data at this point is not progress. Edge 2: breaking SIP-things into components must still work. I must be able to say that doing SIP IM with me is ok, but voice I'd not prefer (because I'm busy for example). Therefore I'd count the component meaning as something we need to solve in the first stages. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 31 10:38:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13187; Mon, 31 Jan 2005 10:38:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvduw-0006MP-O0; Mon, 31 Jan 2005 10:56:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvdbJ-0007pH-2d; Mon, 31 Jan 2005 10:36:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvdWT-0006sR-JG for simple@megatron.ietf.org; Mon, 31 Jan 2005 10:31:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12455 for ; Mon, 31 Jan 2005 10:31:27 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvdoQ-0006Cy-Nq for simple@ietf.org; Mon, 31 Jan 2005 10:50:04 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 31 Jan 2005 07:39:47 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0VFUrl2003351; Mon, 31 Jan 2005 07:30:54 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOS48435; Mon, 31 Jan 2005 10:30:52 -0500 (EST) Message-ID: <41FE4F2C.8000806@cisco.com> Date: Mon, 31 Jan 2005 10:30:52 -0500 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: Aki Niemi Subject: Re: [Simple] another try at data model compromise regarding unique service URI References: <41F33C72.2070306@cisco.com> <41F778F5.8040004@nokia.com> <41FA2D02.3020008@cisco.com> <41FE4707.8030602@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Aki Niemi wrote: > > At this point I'm not too hung up on the idea of separate tuples either. > But to me it seems like the cleanest (if not the only) way to enable > things like: "I am open for IM, but busy for voice". Since I guess a > tuple is still supposed to share the basic status, or will we need to > now group all things OPEN into one tuple, and all things CLOSED into > one? Yuck! I think basic status is just too crude to be of use for a sophisticated device. So give up on it. Only indicate CLOSED when you can't do anything. OPEN means you can do something, but exactly what is all in other attributes. For a watcher, it means a little extra work to decide whether to make that icon green or red. Instead of basing that on OPEN/CLOSED, green comes from OPEN plus some capability that the watcher can use. For a voice-only watcher, its OPEN+audio. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 31 11:55:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22655; Mon, 31 Jan 2005 11:55:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvf7Z-0008Qf-DK; Mon, 31 Jan 2005 12:13:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvelp-0007ID-M5; Mon, 31 Jan 2005 11:51:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvelG-00078t-PD for simple@megatron.ietf.org; Mon, 31 Jan 2005 11:50:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22285 for ; Mon, 31 Jan 2005 11:50:48 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvf3E-0008Kw-NM for simple@ietf.org; Mon, 31 Jan 2005 12:09:26 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0VGojc06225; Mon, 31 Jan 2005 18:50:45 +0200 (EET) X-Scanned: Mon, 31 Jan 2005 18:50:35 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j0VGoZYm032558; Mon, 31 Jan 2005 18:50:35 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00mlmIdJ; Mon, 31 Jan 2005 18:49:09 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0VGNIx12605; Mon, 31 Jan 2005 18:23:18 +0200 (EET) Received: from [172.21.39.180] ([172.21.39.180]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 31 Jan 2005 18:23:17 +0200 Message-ID: <41FE5B74.3020105@nokia.com> Date: Mon, 31 Jan 2005 18:23:16 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Paul Kyzivat Subject: Re: [Simple] another try at data model compromise regarding unique service URI References: <41F33C72.2070306@cisco.com> <41F778F5.8040004@nokia.com> <41FA2D02.3020008@cisco.com> <41FE4707.8030602@nokia.com> <41FE4F2C.8000806@cisco.com> In-Reply-To: <41FE4F2C.8000806@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2005 16:23:17.0870 (UTC) FILETIME=[2BFF88E0:01C507B1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit ext Paul Kyzivat wrote: >> At this point I'm not too hung up on the idea of separate tuples >> either. But to me it seems like the cleanest (if not the only) way to >> enable things like: "I am open for IM, but busy for voice". Since I >> guess a tuple is still supposed to share the basic status, or will we >> need to now group all things OPEN into one tuple, and all things >> CLOSED into one? Yuck! > > > I think basic status is just too crude to be of use for a sophisticated > device. So give up on it. Only indicate CLOSED when you can't do > anything. OPEN means you can do something, but exactly what is all in > other attributes. I was talking about things that go beyond . The PIDF structure is simple: it has a element, that describes the status of the tuple. It can have OPEN + some. > For a watcher, it means a little extra work to decide whether to make > that icon green or red. Instead of basing that on OPEN/CLOSED, green > comes from OPEN plus some capability that the watcher can use. For a > voice-only watcher, its OPEN+audio. So you're still advocating a black-and-white world (or green-and-red world), where something is either on or off, and can never exhibit finer grained status? Sorry, but my world is not binary, but a service can be in "do-not-disturb", "busy", "inconvenienced", "actively sending" and a host of other non-standard statuses -- including ones that are not standardized, or come in the form of freetext notes. Even further, for some services, audio can be "on" while for others "off". Take for example, push-to-talk, voice, and video call in a single device. How can you describe a different stratus for each of these services using a single tuple? Cheers, Aki > > Paul > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 31 12:59:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00353; Mon, 31 Jan 2005 12:59:07 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvg7L-0001uR-6u; Mon, 31 Jan 2005 13:17:45 -0500 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1CvfpJ-0006lv-HX; Mon, 31 Jan 2005 12:59:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfbT-0002yF-AY; Mon, 31 Jan 2005 12:44:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfTy-0001os-0e for simple@megatron.ietf.org; Mon, 31 Jan 2005 12:37:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27264 for ; Mon, 31 Jan 2005 12:36:59 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvflw-0001B1-PB for simple@ietf.org; Mon, 31 Jan 2005 12:55:37 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 31 Jan 2005 09:45:21 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0VHaRM8001753; Mon, 31 Jan 2005 09:36:27 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOS60474; Mon, 31 Jan 2005 12:36:25 -0500 (EST) Message-ID: <41FE6C99.6060708@cisco.com> Date: Mon, 31 Jan 2005 12:36:25 -0500 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: Aki Niemi Subject: Re: [Simple] another try at data model compromise regarding unique service URI References: <41F33C72.2070306@cisco.com> <41F778F5.8040004@nokia.com> <41FA2D02.3020008@cisco.com> <41FE4707.8030602@nokia.com> <41FE4F2C.8000806@cisco.com> <41FE5B74.3020105@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Aki Niemi wrote: > > > ext Paul Kyzivat wrote: > >>> At this point I'm not too hung up on the idea of separate tuples >>> either. But to me it seems like the cleanest (if not the only) way >>> to enable things like: "I am open for IM, but busy for voice". Since >>> I guess a tuple is still supposed to share the basic status, or will >>> we need to now group all things OPEN into one tuple, and all things >>> CLOSED into one? Yuck! >> >> I think basic status is just too crude to be of use for a >> sophisticated device. So give up on it. Only indicate CLOSED when you >> can't do anything. OPEN means you can do something, but exactly what >> is all in other attributes. > > I was talking about things that go beyond . The PIDF structure is > simple: it has a element, that describes the status of the > tuple. It can have OPEN + some. > >> For a watcher, it means a little extra work to decide whether to make >> that icon green or red. Instead of basing that on OPEN/CLOSED, green >> comes from OPEN plus some capability that the watcher can use. For a >> voice-only watcher, its OPEN+audio. > > So you're still advocating a black-and-white world (or green-and-red > world), where something is either on or off, and can never exhibit finer > grained status? No, I'm not. I thought you were. So I was simply demonstrating how it can be provided if wanted. For devices with the real estate, it would be better to simply display multiple icons for each buddy indicating what capabilities are currently available. (Perhaps icons of phones and cameras can turn from red to green.) > Sorry, but my world is not binary, but a service can be in > "do-not-disturb", "busy", "inconvenienced", "actively sending" and a > host of other non-standard statuses -- including ones that are not > standardized, or come in the form of freetext notes. My world isn't binary either. But I thought that now things like "do-not-disturb", "busy", "inconvenienced" are attributes of the person, not the service. So we don't have a way to say do-not-disturb for a service. > Even further, for some services, audio can be "on" while for others > "off". Take for example, push-to-talk, voice, and video call in a single > device. How can you describe a different stratus for each of these > services using a single tuple? I still don't understand your model of how the device works. You seem to have in mind a "video service" that includes both voice and video, and a separate "audio service" that includes only audio. And then either or both can be available. But how is this better (or even as good as) a single videophone service that is capable of supporting both voice and video, or just voice, or just video, depending on what is negotiated in a call? With such a service, if I don't want to be available for video, I just disable it, so it won't be offered or answered, and then video then isn't advertised in the (single) presence tuple either. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 31 17:24:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12448; Mon, 31 Jan 2005 17:24:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvkFh-0004RF-Jx; Mon, 31 Jan 2005 17:42:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvjIr-0002bk-Sk; Mon, 31 Jan 2005 16:41:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvial-0000XN-Ig for simple@megatron.ietf.org; Mon, 31 Jan 2005 15:56:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20250 for ; Mon, 31 Jan 2005 15:56:13 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvism-0006He-Kf for simple@ietf.org; Mon, 31 Jan 2005 16:14:53 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 31 Jan 2005 14:05:43 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0VKtgM8004915 for ; Mon, 31 Jan 2005 12:55:42 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-35.cisco.com [10.86.242.35]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHK20857; Mon, 31 Jan 2005 12:55:40 -0800 (PST) Message-ID: <41FE9B4C.1070106@cisco.com> Date: Mon, 31 Jan 2005 15:55:40 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Subject: [Simple] Namespaces and XCAP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit Folks, One of the issues that has come up during the last call period for xcap was the way namespaces are used during the URI matching operation. The way it works today is that the namespace contexts for evaluating the xcap URI are constructed as you traverse through the document. The namespace prefixes in the URI therefore need to be defined using namepsace bindings defined in the document itself. This has two major drawbacks that have been pointed out: 1. it requires the XCAP client to have the document in hand ahead of time, just to know the namespace bindings 2. it prohibits the usage of existing off-the-shelf xpath libraries to support xcap. These libraries require namespace bindings to be provided PRIOR to the evaluation of an expression against a document. We have in the past agreed that an xcap client must be able to perform operations like insertion of a buddy into a buddy list, without having the full buddy list document stored locally. The current matching rules make that impossible. That would seem to be a fairly significant limitation and therefore one that we need to address. The alternatives are fairly limited. They are, as far as I can tell: 1. Server defined namespace bindings The server can define bindings between namespace prefixes and namespace URIs in a separate document in the global tree. This requires the xcap server to track namespaces used in each instance document. When a new element, attribute or document is added, the server needs to scan those for new namespaces, and add bindings for them to the global document. Similarly, when an element, document or attribute is removed, the server would have to do reference checking to see if that namespace is still in use. If not, it would then remove the binding. The binding document can be simple. For example, xpointer expressions would suffice: xmlns(prefix1="http://namespace-uri-1") xmlns(prefix2="http://namespace-2-uri") A client would still need to have this namespace document in hand at all times. It is relatively small. However, the xcap client would need to know if it should change. 2. Client defined namespace bindings: separate document Instead of having the server define bindings, each user has a document (in the user tree somewhere) that defines the bindings. The client themself creates this document. Thus, the client need only create bindings for the namespaces it plans on using in queries. We still have the problem that, if multiple clients for the same user write this document, it needs to be kept up to date on the other clients (i.e., would require the config package). Furthermore, it assumes that the user that performs a query is the same as the user that "owns" the document. This need not be the case. For example, my friends might be allowed to read entries off of my buddy list. 3. Implied namespace prefixes Instead of the namespace bindings being obtained from a document, they could be well-known and constructed by algorithm. For example, an MD5 hash of the namespace URI. This approach has the benefit that no synchronization on a document is required. However, whenever the server processes a query against a document, it will need to obtain all of the namespace URIs in use in that document, and then hash them to obtain the namespace prefixes allowed in the queries. Thus, the work on the server is similar to proposal (1). It would also result in extremely UGLY URIs, and long ones too. 4. Allow the namespace URI instead of a namespace prefix In this approach, instead of hashing the namespace URI to obtain the namespace prefix, we simply allow the namespace URI itself to BE a valid prefix. This has none of the drawbacks of approach (3), except that it makes the URIs really, really, really long. Its also definitely a hack and something that is bending the rules a bit on XML namespaces. 5. Allow namespace bindings to be definde in the XCAP URI itself In this approach, bindings between namespace prefixes and namespace URI are present in the xcap URI itself. The xpointer xmlns specification (http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/) provides a way to define these. As an example of how this might work: http://xcap.example.com/services/resource-lists/users/bill/fr.xml/~~/ xmlns(foo="http://foo.example.com")/ resource-lists/list%5b@name=%22friends%22%5d/entry/foo:street-address In other words, right after the ~~ delimiter, the next path segment is actually a namespace definition, binding the namespace prefix "foo" to the URI "http://foo.example.com". That prefix is then used later on in the URI. The only question is where in the URI to place these definitions. Again, we only have so many choices that I can see: CHOICE A: immediately after the ~~/, in the next path segment, which would contain all such definitions as xmlns xpointer expressions. CHOICE B: anywhere in the URI, as a separate path segment CHOICE C: as part of a path segment that corresponds to an element, attribute or document I think the easiest thing is probably A. The main drawback to this approach is that its inclusion in a path segment at all is a stretch to the definition of a path, but conceptually you are navigating into a namespace, and within that namespace, to elements and attributes. It also leads to somewhat long-ish URI. I would further propose that application usages define a default namespace for the xcap URI evaluation, so as to avoid defining those in each and every URI. So, which to use? Considering the issues involved, I think the best option is 5(A). Comments? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 31 17:28:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13613; Mon, 31 Jan 2005 17:28:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvkKJ-0004l2-6C; Mon, 31 Jan 2005 17:47:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvjkm-0005hb-Pr; Mon, 31 Jan 2005 17:10:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvj8V-0003to-MC; Mon, 31 Jan 2005 16:31:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28639; Mon, 31 Jan 2005 16:31:05 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvjQX-0000J7-6X; Mon, 31 Jan 2005 16:49:45 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 31 Jan 2005 13:39:29 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0VLUXNt006328; Mon, 31 Jan 2005 13:30:33 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-35.cisco.com [10.86.242.35]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHK23831; Mon, 31 Jan 2005 13:30:29 -0800 (PST) Message-ID: <41FEA375.7010402@cisco.com> Date: Mon, 31 Jan 2005 16:30:29 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell Subject: Re: [Simple] Last Call: 'The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)' to Proposed Standard References: <003a01c4e103$be9cb8f0$c700a8c0@RW> In-Reply-To: <003a01c4e103$be9cb8f0$c700a8c0@RW> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Pete, Apologies for the delayed response. I am updating the document now. You are absolutely correct that the schema types should instead be emty elements. I have corrected it per your suggestion. Thanks, Jonathan R. Pete Cordell wrote: > I haven't followed XCAP, but I wonder if the following XML schema types > should be empty elements (e.g. ) rather than ur-type (e.g. > blahetc)? > > > > > > > > > If some of them are meant to be empty, then the syntax is: > > > > > > > > > > > > Regards, > > Pete. > -- > ============================================= > Pete Cordell > Tech-Know-Ware > http://www.tech-know-ware.com/lmx > For LMX XML to C++ binding > (or http://www.xml2cpp.com) > ============================================= > > ----- Original Message ----- > From: "The IESG" > To: "IETF-Announce" > Cc: > Sent: Thursday, December 09, 2004 9:26 PM > Subject: [Simple] Last Call: 'The Extensible Markup Language (XML) > Configuration Access Protocol (XCAP)' to Proposed Standard > > > >>The IESG has received a request from the SIP for Instant Messaging and >>Presence Leveraging Extensions WG to consider the following document: >> >>- 'The Extensible Markup Language (XML) Configuration Access Protocol > > (XCAP) ' > >> as a Proposed Standard >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action. Please send any comments to the >>iesg@ietf.org or ietf@ietf.org mailing lists by 2004-12-28. >> >>The file can be obtained via >>http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-05.txt >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 31 17:56:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18118; Mon, 31 Jan 2005 17:56:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvkl5-00064a-NL; Mon, 31 Jan 2005 18:15:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvkPh-0002Sl-Vs; Mon, 31 Jan 2005 17:52:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvkGN-0007Av-UF for simple@megatron.ietf.org; Mon, 31 Jan 2005 17:43:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16007 for ; Mon, 31 Jan 2005 17:43:13 -0500 (EST) Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvkYL-0005Rb-Ol for simple@ietf.org; Mon, 31 Jan 2005 18:01:54 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8954316; Mon, 31 Jan 2005 17:43:11 -0500 Message-Id: <6.1.2.0.0.20050131173043.03d6a118@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 31 Jan 2005 17:42:55 -0500 To: Jonathan Rosenberg , Simple WG From: "Joel M. Halpern" Subject: Re: [Simple] Namespaces and XCAP In-Reply-To: <41FE9B4C.1070106@cisco.com> References: <41FE9B4C.1070106@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e I don't see any other sensible alternatives (one can always create even more contorted answers.) There is one assumption that I think has to be made clear. Namely that the client does know what namespaces are used in the document. This makes reasonable sense to me, since the client will be preparing document fragments, and presumably understands the structure of the document it is working with. Given that assumption, it seems to me that one rapidly concludes that the first four options are non-starters. This leaves us with option 5. 5 A (xmlns() at the front of the path portion) seems to me a good compromise. It covers most (but not all) documents. And it keeps the parsing simple. Allowing xmlns() anywhere would get really complicated. Although I presume it is spelled out in W3C specs, we probably need to be clear about matching rules. For example, suppose there is a namespace http://foospace.example.com. In the document, in some portion of the document, this might be he default name space, and a tag from that namespace is used. I would hope that the matching rules are such that if the XCAP client specified /~~/xmlns(st="http://foospace.example.com")/.../st:bar then assuming the omitted stuff got to the element containing the bar referencing that name space, then the st:bar would match the element. Yours, Joel At 03:55 PM 1/31/2005, Jonathan Rosenberg wrote: >Folks, > >One of the issues that has come up during the last call period for xcap >was the way namespaces are used during the URI matching operation. The way >it works today is that the namespace contexts for evaluating the xcap URI >are constructed as you traverse through the document. The namespace >prefixes in the URI therefore need to be defined using namepsace bindings >defined in the document itself. > >This has two major drawbacks that have been pointed out: > >1. it requires the XCAP client to have the document in hand ahead of time, >just to know the namespace bindings > >2. it prohibits the usage of existing off-the-shelf xpath libraries to >support xcap. These libraries require namespace bindings to be provided >PRIOR to the evaluation of an expression against a document. > >We have in the past agreed that an xcap client must be able to perform >operations like insertion of a buddy into a buddy list, without having the >full buddy list document stored locally. The current matching rules make >that impossible. That would seem to be a fairly significant limitation and >therefore one that we need to address. > >The alternatives are fairly limited. They are, as far as I can tell: > >1. Server defined namespace bindings > >The server can define bindings between namespace prefixes and namespace >URIs in a separate document in the global tree. This requires the xcap >server to track namespaces used in each instance document. When a new >element, attribute or document is added, the server needs to scan those >for new namespaces, and add bindings for them to the global document. >Similarly, when an element, document or attribute is removed, the server >would have to do reference checking to see if that namespace is still in >use. If not, it would then remove the binding. > >The binding document can be simple. For example, xpointer expressions >would suffice: > >xmlns(prefix1="http://namespace-uri-1") >xmlns(prefix2="http://namespace-2-uri") > >A client would still need to have this namespace document in hand at all >times. It is relatively small. However, the xcap client would need to know >if it should change. > >2. Client defined namespace bindings: separate document > >Instead of having the server define bindings, each user has a document (in >the user tree somewhere) that defines the bindings. The client themself >creates this document. Thus, the client need only create bindings for the >namespaces it plans on using in queries. > >We still have the problem that, if multiple clients for the same user >write this document, it needs to be kept up to date on the other clients >(i.e., would require the config package). > >Furthermore, it assumes that the user that performs a query is the same as >the user that "owns" the document. This need not be the case. For example, >my friends might be allowed to read entries off of my buddy list. > >3. Implied namespace prefixes > >Instead of the namespace bindings being obtained from a document, they >could be well-known and constructed by algorithm. For example, an MD5 hash >of the namespace URI. > >This approach has the benefit that no synchronization on a document is >required. However, whenever the server processes a query against a >document, it will need to obtain all of the namespace URIs in use in that >document, and then hash them to obtain the namespace prefixes allowed in >the queries. Thus, the work on the server is similar to proposal (1). > >It would also result in extremely UGLY URIs, and long ones too. > >4. Allow the namespace URI instead of a namespace prefix > >In this approach, instead of hashing the namespace URI to obtain the >namespace prefix, we simply allow the namespace URI itself to BE a valid >prefix. This has none of the drawbacks of approach (3), except that it >makes the URIs really, really, really long. Its also definitely a hack and >something that is bending the rules a bit on XML namespaces. > >5. Allow namespace bindings to be definde in the XCAP URI itself > >In this approach, bindings between namespace prefixes and namespace URI >are present in the xcap URI itself. The xpointer xmlns specification >(http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/) provides a way to >define these. As an example of how this might work: > >http://xcap.example.com/services/resource-lists/users/bill/fr.xml/~~/ > xmlns(foo="http://foo.example.com")/ > resource-lists/list%5b@name=%22friends%22%5d/entry/foo:street-address > > >In other words, right after the ~~ delimiter, the next path segment is >actually a namespace definition, binding the namespace prefix "foo" to the >URI "http://foo.example.com". That prefix is then used later on in the URI. > >The only question is where in the URI to place these definitions. Again, >we only have so many choices that I can see: > >CHOICE A: immediately after the ~~/, in the next path segment, which would >contain all such definitions as xmlns xpointer expressions. > >CHOICE B: anywhere in the URI, as a separate path segment > >CHOICE C: as part of a path segment that corresponds to an element, >attribute or document > > >I think the easiest thing is probably A. > >The main drawback to this approach is that its inclusion in a path segment >at all is a stretch to the definition of a path, but conceptually you are >navigating into a namespace, and within that namespace, to elements and >attributes. > >It also leads to somewhat long-ish URI. > >I would further propose that application usages define a default namespace >for the xcap URI evaluation, so as to avoid defining those in each and >every URI. > > > > >So, which to use? Considering the issues involved, I think the best option >is 5(A). > >Comments? > >Thanks, >Jonathan R. > > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 >Cisco Systems >jdrosen@cisco.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.cisco.com > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 31 18:12:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20108; Mon, 31 Jan 2005 18:12:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvl0e-0006Sa-D9; Mon, 31 Jan 2005 18:31:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvkWy-00059C-VU; Mon, 31 Jan 2005 18:00:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvkQ1-0002j6-Pp for simple@megatron.ietf.org; Mon, 31 Jan 2005 17:53:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17842 for ; Mon, 31 Jan 2005 17:53:15 -0500 (EST) From: krisztian.kiss@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvki4-0005yn-05 for simple@ietf.org; Mon, 31 Jan 2005 18:11:56 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0VMrD802692; Tue, 1 Feb 2005 00:53:14 +0200 (EET) X-Scanned: Tue, 1 Feb 2005 01:03:34 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j0VN3Y2R015591; Tue, 1 Feb 2005 01:03:34 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00eDGsgI; Tue, 01 Feb 2005 01:03:32 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0VMqsU25725; Tue, 1 Feb 2005 00:52:54 +0200 (EET) Received: from sdebe101.NOE.Nokia.com ([172.19.222.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 31 Jan 2005 16:52:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Presence data model: in Date: Mon, 31 Jan 2005 14:52:52 -0800 Message-ID: Thread-Topic: Presence data model: in Thread-Index: AcUFH2Sc9MlWDlaET+qtPsZaNTHaPABqYYj1ABULzGA= To: , X-OriginalArrivalTime: 31 Jan 2005 22:52:54.0084 (UTC) FILETIME=[994EB840:01C507E7] X-Spam-Score: 0.3 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Hi Walter, > -----Original Message----- > From: ext Goix Walter [mailto:Walter.Goix@TILAB.COM] > Sent: Sunday, January 30, 2005 4:41 AM > To: Kiss Krisztian (Nokia-TP/SanDiego); simple@ietf.org > Subject: RE: [Simple] Presence data model: in >=20 >=20 > Krisztian, >=20 > The examples in the presence data model draft identify=20 > as an element under , but that's probably=20 > what you had in mind.=20 Right. > However, I don't clearly see the rationale for multiple=20 > within a single . Multiple devices for the=20 > same presentity may offer exactly the same service, but they=20 > probably would need no element to get the ability=20 > to be merged into a single at the server. In that=20 > case, if one device updates its inserting a =20 > element (max 1 in PIDF ), then both tuples will need=20 > to be separated again. Same if another property of a single=20 > device is updated. I personally see more=20 > complications than benefits allowing multiple per=20 > . Is there a real requirement for such an optimization?=20 Actually the intention of my previous e-mail was not to debate whether = you can have multiple s under or not, (the current = draft allows more than one at the moment, I think) but I agree with your = analysis and would restrict the number of elements to be one = under . =20 > I agree that no namespace nor schema is defined for this=20 > extension. Maybe the following declaration could be used: >=20 > Looks good. Thanks, Krisztian >=20 > Walter >=20 > -----Original Message----- > From: simple-bounces@ietf.org on behalf of krisztian.kiss@nokia.com > Sent: Fri 1/28/2005 10:54 AM > To: simple@ietf.org > Subject: [Simple] Presence data model: in > =20 >=20 > draft-ietf-simple-presence-data-model-01 allows to=20 > include a or a list of s serving as=20 > correlation identifier(s). >=20 > Section 5.1.2 contains schema definition for =20 > including , i.e.: >=20 > >=20 > I would assume that if appears under ,=20 > another schema definition would be required, something like: >=20 > minOccurs=3D"0" maxOccurs=3D"unbounded"/> >=20 > Should this extension be added to the draft? >=20 > Thanks, > Krisztian >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 > Gruppo Telecom Italia - Direzione e coordinamento di Telecom=20 > Italia S.p.A. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to=20 > MailAdmin@tilab.com. Thank you > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 31 18:13:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20339; Mon, 31 Jan 2005 18:13:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvl1w-0006Uu-1i; Mon, 31 Jan 2005 18:32:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvkX7-0005FF-2p; Mon, 31 Jan 2005 18:00:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvkRT-0003f5-IG for simple@megatron.ietf.org; Mon, 31 Jan 2005 17:54:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18004 for ; Mon, 31 Jan 2005 17:54:45 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvkjV-00061J-VK for simple@ietf.org; Mon, 31 Jan 2005 18:13:26 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 31 Jan 2005 16:04:16 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0VMsCl2008222; Mon, 31 Jan 2005 14:54:12 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-35.cisco.com [10.86.242.35]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHK31649; Mon, 31 Jan 2005 14:54:10 -0800 (PST) Message-ID: <41FEB712.9010908@cisco.com> Date: Mon, 31 Jan 2005 17:54:10 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [Simple] Namespaces and XCAP References: <41FE9B4C.1070106@cisco.com> <6.1.2.0.0.20050131173043.03d6a118@localhost> In-Reply-To: <6.1.2.0.0.20050131173043.03d6a118@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit inline. Joel M. Halpern wrote: > I don't see any other sensible alternatives (one can always create even > more contorted answers.) > > There is one assumption that I think has to be made clear. Namely that > the client does know what namespaces are used in the document. This > makes reasonable sense to me, since the client will be preparing > document fragments, and presumably understands the structure of the > document it is working with. Yes, I agree with that. > > Given that assumption, it seems to me that one rapidly concludes that > the first four options are non-starters. This leaves us with option 5. > 5 A (xmlns() at the front of the path portion) seems to me a good > compromise. It covers most (but not all) documents. And it keeps the > parsing simple. Allowing xmlns() anywhere would get really complicated. Which documents does it not cover? Even if a document has a namespace prefix re-defined in the middle of a document, it is still the case that each element and attribute is associated with a single namespace, and thus it should be possible to construct a URI with a node selector containing a prefix that maps to that namespace. > > Although I presume it is spelled out in W3C specs, we probably need to > be clear about matching rules. For example, suppose there is a > namespace http://foospace.example.com. > In the document, in some portion of the document, this might be he > default name space, and a tag from that namespace is used. > I would hope that the matching rules are such that if the XCAP client > specified > /~~/xmlns(st="http://foospace.example.com")/.../st:bar > then assuming the omitted stuff got to the element containing the bar > referencing that name space, then the st:bar would match the element. Yes. Matching rules are done by expanding the prefixes (and defaults) to the full namespace URI and doing the comparisons that way. The xcap spec specifies this by pointing to XML matching rules defined in the namespaces document. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 31 18:17:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21021; Mon, 31 Jan 2005 18:17:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvl5c-0006cT-SR; Mon, 31 Jan 2005 18:36:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvkXF-0005LR-Dy; Mon, 31 Jan 2005 18:00:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvkVo-0004P0-3U for simple@megatron.ietf.org; Mon, 31 Jan 2005 17:59:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18556 for ; Mon, 31 Jan 2005 17:59:13 -0500 (EST) Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvknp-0006A4-9G for simple@ietf.org; Mon, 31 Jan 2005 18:17:54 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8954614 for simple@ietf.org; Mon, 31 Jan 2005 17:59:11 -0500 Message-Id: <6.1.2.0.0.20050131175725.03e93ec0@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 31 Jan 2005 17:58:52 -0500 To: Simple WG From: "Joel M. Halpern" Subject: Re: [Simple] Namespaces and XCAP In-Reply-To: <41FEB712.9010908@cisco.com> References: <41FE9B4C.1070106@cisco.com> <6.1.2.0.0.20050131173043.03d6a118@localhost> <41FEB712.9010908@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 I had thought there would be coverage problems with reused name space prefixes. But, as Jonathan points out, the XCAP client does not need to reuse prefixes even if the document does. Hence, it seems even more clear that 5A is the right answer. Thanks Jonathan. Yours, Joel At 05:54 PM 1/31/2005, Jonathan Rosenberg wrote: >Given that assumption, it seems to me that one rapidly concludes that the >first four options are non-starters. This leaves us with option 5. >5 A (xmlns() at the front of the path portion) seems to me a good >compromise. It covers most (but not all) documents. And it keeps the >parsing simple. Allowing xmlns() anywhere would get really complicated. > >Which documents does it not cover? Even if a document has a namespace >prefix re-defined in the middle of a document, it is still the case that >each element and attribute is associated with a single namespace, and thus >it should be possible to construct a URI with a node selector containing a >prefix that maps to that namespace. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 31 18:44:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23462; Mon, 31 Jan 2005 18:44:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvlVY-0007CV-E0; Mon, 31 Jan 2005 19:03:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvl0W-00052o-UN; Mon, 31 Jan 2005 18:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvkxZ-0003sk-Vf for simple@megatron.ietf.org; Mon, 31 Jan 2005 18:27:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22285 for ; Mon, 31 Jan 2005 18:27:55 -0500 (EST) Received: from dns2.xten.net ([64.69.76.5] helo=mail.xten.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvlFc-0006qv-2I for simple@ietf.org; Mon, 31 Jan 2005 18:46:36 -0500 Received: from [24.85.92.32] by mail.xten.com (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.5.3)); Mon, 31 Jan 2005 15:31:32 -0800 From: "Nelson Hung" To: "'Jonathan Rosenberg'" , "'Simple WG'" Subject: RE: [Simple] Namespaces and XCAP Date: Mon, 31 Jan 2005 15:27:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUH6KwIyeec/JpwQBGRS5IZYwOq9wAA2TfA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6.1.2.0.0.20050131173043.03d6a118@localhost> Message-ID: X-ArGoMail-Authenticated: nelson@xten.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: 7bit I agree that 5(A) is the best option. But one thing about default namespace, XPath Specification 1.0 explicitly disallows the use of default namespace in an XPath expression... http://www.w3.org/TR/xpath#node-tests "A QName in the node test is expanded into an expanded-name using the namespace declarations from the expression context. This is the same way expansion is done for element type names in start and end-tags except that the default namespace declared with xmlns is not used: if the QName does not have a prefix, then the namespace URI is null (this is the same way attribute names are expanded). It is an error if the QName has a prefix for which there is no namespace declaration in the expression context." At 03:55 PM 1/31/2005, Jonathan Rosenberg wrote: >Folks, > >One of the issues that has come up during the last call period for xcap >was the way namespaces are used during the URI matching operation. The way >it works today is that the namespace contexts for evaluating the xcap URI >are constructed as you traverse through the document. The namespace >prefixes in the URI therefore need to be defined using namepsace bindings >defined in the document itself. > >This has two major drawbacks that have been pointed out: > >1. it requires the XCAP client to have the document in hand ahead of time, >just to know the namespace bindings > >2. it prohibits the usage of existing off-the-shelf xpath libraries to >support xcap. These libraries require namespace bindings to be provided >PRIOR to the evaluation of an expression against a document. > >We have in the past agreed that an xcap client must be able to perform >operations like insertion of a buddy into a buddy list, without having the >full buddy list document stored locally. The current matching rules make >that impossible. That would seem to be a fairly significant limitation and >therefore one that we need to address. > >The alternatives are fairly limited. They are, as far as I can tell: > >1. Server defined namespace bindings > >The server can define bindings between namespace prefixes and namespace >URIs in a separate document in the global tree. This requires the xcap >server to track namespaces used in each instance document. When a new >element, attribute or document is added, the server needs to scan those >for new namespaces, and add bindings for them to the global document. >Similarly, when an element, document or attribute is removed, the server >would have to do reference checking to see if that namespace is still in >use. If not, it would then remove the binding. > >The binding document can be simple. For example, xpointer expressions >would suffice: > >xmlns(prefix1="http://namespace-uri-1") >xmlns(prefix2="http://namespace-2-uri") > >A client would still need to have this namespace document in hand at all >times. It is relatively small. However, the xcap client would need to know >if it should change. > >2. Client defined namespace bindings: separate document > >Instead of having the server define bindings, each user has a document (in >the user tree somewhere) that defines the bindings. The client themself >creates this document. Thus, the client need only create bindings for the >namespaces it plans on using in queries. > >We still have the problem that, if multiple clients for the same user >write this document, it needs to be kept up to date on the other clients >(i.e., would require the config package). > >Furthermore, it assumes that the user that performs a query is the same as >the user that "owns" the document. This need not be the case. For example, >my friends might be allowed to read entries off of my buddy list. > >3. Implied namespace prefixes > >Instead of the namespace bindings being obtained from a document, they >could be well-known and constructed by algorithm. For example, an MD5 hash >of the namespace URI. > >This approach has the benefit that no synchronization on a document is >required. However, whenever the server processes a query against a >document, it will need to obtain all of the namespace URIs in use in that >document, and then hash them to obtain the namespace prefixes allowed in >the queries. Thus, the work on the server is similar to proposal (1). > >It would also result in extremely UGLY URIs, and long ones too. > >4. Allow the namespace URI instead of a namespace prefix > >In this approach, instead of hashing the namespace URI to obtain the >namespace prefix, we simply allow the namespace URI itself to BE a valid >prefix. This has none of the drawbacks of approach (3), except that it >makes the URIs really, really, really long. Its also definitely a hack and >something that is bending the rules a bit on XML namespaces. > >5. Allow namespace bindings to be definde in the XCAP URI itself > >In this approach, bindings between namespace prefixes and namespace URI >are present in the xcap URI itself. The xpointer xmlns specification >(http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/) provides a way to >define these. As an example of how this might work: > >http://xcap.example.com/services/resource-lists/users/bill/fr.xml/~~/ > xmlns(foo="http://foo.example.com")/ > resource-lists/list%5b@name=%22friends%22%5d/entry/foo:street-address > > >In other words, right after the ~~ delimiter, the next path segment is >actually a namespace definition, binding the namespace prefix "foo" to the >URI "http://foo.example.com". That prefix is then used later on in the URI. > >The only question is where in the URI to place these definitions. Again, >we only have so many choices that I can see: > >CHOICE A: immediately after the ~~/, in the next path segment, which would >contain all such definitions as xmlns xpointer expressions. > >CHOICE B: anywhere in the URI, as a separate path segment > >CHOICE C: as part of a path segment that corresponds to an element, >attribute or document > > >I think the easiest thing is probably A. > >The main drawback to this approach is that its inclusion in a path segment >at all is a stretch to the definition of a path, but conceptually you are >navigating into a namespace, and within that namespace, to elements and >attributes. > >It also leads to somewhat long-ish URI. > >I would further propose that application usages define a default namespace >for the xcap URI evaluation, so as to avoid defining those in each and >every URI. > > > > >So, which to use? Considering the issues involved, I think the best option >is 5(A). > >Comments? > >Thanks, >Jonathan R. > > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 >Cisco Systems >jdrosen@cisco.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.cisco.com > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 31 18:44:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23529; Mon, 31 Jan 2005 18:44:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvlW6-0007E9-Ud; Mon, 31 Jan 2005 19:03:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvl0X-00052t-Ee; Mon, 31 Jan 2005 18:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvkxu-00041C-CG for simple@megatron.ietf.org; Mon, 31 Jan 2005 18:28:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22313 for ; Mon, 31 Jan 2005 18:28:15 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvlFw-0006qs-0Y for simple@ietf.org; Mon, 31 Jan 2005 18:46:57 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 31 Jan 2005 15:29:03 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0VNReM8026326; Mon, 31 Jan 2005 15:27:40 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOS96581; Mon, 31 Jan 2005 18:27:41 -0500 (EST) Message-ID: <41FEBEED.7010200@cisco.com> Date: Mon, 31 Jan 2005 18:27:41 -0500 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: krisztian.kiss@nokia.com Subject: Re: [Simple] Presence data model: in References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Walter.Goix@TILAB.COM X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit krisztian.kiss@nokia.com wrote: >>From: ext Goix Walter [mailto:Walter.Goix@TILAB.COM] >>However, I don't clearly see the rationale for multiple >> within a single . Multiple devices for the >>same presentity may offer exactly the same service, but they >>probably would need no element to get the ability >>to be merged into a single at the server. In that >>case, if one device updates its inserting a >>element (max 1 in PIDF ), then both tuples will need >>to be separated again. Same if another property of a single >>device is updated. I personally see more >>complications than benefits allowing multiple per >>. Is there a real requirement for such an optimization? > > > Actually the intention of my previous e-mail was not to debate whether you can have multiple s under or not, (the current draft allows more than one at the moment, I think) but I agree with your analysis and would restrict the number of elements to be one under . So, what should a compositor do if it gets multiple tuples, with different devices and contacts, but it decides to combine them into a single tuple with the AoR as the contact? E.g. suppose there is a cell phone and a home phone, and they both have the same attributes. (Open, voice, ...) It seems that you would require that either all devices be omitted, or else that one be picked. The device isn't terribly useful in this case, since you don't have any choice about what to call. But still it might be useful for deciding if you want to call. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 31 20:36:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04830; Mon, 31 Jan 2005 20:36:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvnGA-0001Pc-7y; Mon, 31 Jan 2005 20:55:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvmtv-0004Re-Q5; Mon, 31 Jan 2005 20:32:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvmrN-0003nA-1I for simple@megatron.ietf.org; Mon, 31 Jan 2005 20:29:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04260 for ; Mon, 31 Jan 2005 20:29:39 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvn9Q-0001He-GM for simple@ietf.org; Mon, 31 Jan 2005 20:48:21 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 31 Jan 2005 18:39:11 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j111T3l2018538; Mon, 31 Jan 2005 17:29:03 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-35.cisco.com [10.86.242.35]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHK43633; Mon, 31 Jan 2005 17:29:06 -0800 (PST) Message-ID: <41FEDB61.6030102@cisco.com> Date: Mon, 31 Jan 2005 20:29:05 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nelson Hung Subject: Re: [Simple] Namespaces and XCAP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: 7bit This particular behavior in XPath 1.0 is IMHO a bug, and appears to have been corrected in XPath 2.0. We are not normatively dependent on XPath, so we can do what we choose. I would propose that the application usage specify the default namespace. Otherwise, every single XCAP URI will need to contain a xmlns() xpointer expression declaring the default namespace for the documents, all of which are likely to use the target namespace as the default. If we specify this, an xcap expression would be compatible with xpath 2.0 I believe. -Jonathan R. Nelson Hung wrote: > I agree that 5(A) is the best option. > > But one thing about default namespace, XPath Specification 1.0 explicitly > disallows the use of default namespace in an XPath expression... > > > http://www.w3.org/TR/xpath#node-tests > > > "A QName in the node test is expanded into an expanded-name using the > namespace declarations from the expression context. This is the same way > expansion is done for element type names in start and end-tags except that > the default namespace declared with xmlns is not used: if the QName does not > have a prefix, then the namespace URI is null (this is the same way > attribute names are expanded). It is an error if the QName has a prefix for > which there is no namespace declaration in the expression context." > > > At 03:55 PM 1/31/2005, Jonathan Rosenberg wrote: > >>Folks, >> >>One of the issues that has come up during the last call period for xcap >>was the way namespaces are used during the URI matching operation. The way >>it works today is that the namespace contexts for evaluating the xcap URI >>are constructed as you traverse through the document. The namespace >>prefixes in the URI therefore need to be defined using namepsace bindings >>defined in the document itself. >> >>This has two major drawbacks that have been pointed out: >> >>1. it requires the XCAP client to have the document in hand ahead of time, >>just to know the namespace bindings >> >>2. it prohibits the usage of existing off-the-shelf xpath libraries to >>support xcap. These libraries require namespace bindings to be provided >>PRIOR to the evaluation of an expression against a document. >> >>We have in the past agreed that an xcap client must be able to perform >>operations like insertion of a buddy into a buddy list, without having the >>full buddy list document stored locally. The current matching rules make >>that impossible. That would seem to be a fairly significant limitation and >>therefore one that we need to address. >> >>The alternatives are fairly limited. They are, as far as I can tell: >> >>1. Server defined namespace bindings >> >>The server can define bindings between namespace prefixes and namespace >>URIs in a separate document in the global tree. This requires the xcap >>server to track namespaces used in each instance document. When a new >>element, attribute or document is added, the server needs to scan those >>for new namespaces, and add bindings for them to the global document. >>Similarly, when an element, document or attribute is removed, the server >>would have to do reference checking to see if that namespace is still in >>use. If not, it would then remove the binding. >> >>The binding document can be simple. For example, xpointer expressions >>would suffice: >> >>xmlns(prefix1="http://namespace-uri-1") >>xmlns(prefix2="http://namespace-2-uri") >> >>A client would still need to have this namespace document in hand at all >>times. It is relatively small. However, the xcap client would need to know >>if it should change. >> >>2. Client defined namespace bindings: separate document >> >>Instead of having the server define bindings, each user has a document (in >>the user tree somewhere) that defines the bindings. The client themself >>creates this document. Thus, the client need only create bindings for the >>namespaces it plans on using in queries. >> >>We still have the problem that, if multiple clients for the same user >>write this document, it needs to be kept up to date on the other clients >>(i.e., would require the config package). >> >>Furthermore, it assumes that the user that performs a query is the same as >>the user that "owns" the document. This need not be the case. For example, >>my friends might be allowed to read entries off of my buddy list. >> >>3. Implied namespace prefixes >> >>Instead of the namespace bindings being obtained from a document, they >>could be well-known and constructed by algorithm. For example, an MD5 hash >>of the namespace URI. >> >>This approach has the benefit that no synchronization on a document is >>required. However, whenever the server processes a query against a >>document, it will need to obtain all of the namespace URIs in use in that >>document, and then hash them to obtain the namespace prefixes allowed in >>the queries. Thus, the work on the server is similar to proposal (1). >> >>It would also result in extremely UGLY URIs, and long ones too. >> >>4. Allow the namespace URI instead of a namespace prefix >> >>In this approach, instead of hashing the namespace URI to obtain the >>namespace prefix, we simply allow the namespace URI itself to BE a valid >>prefix. This has none of the drawbacks of approach (3), except that it >>makes the URIs really, really, really long. Its also definitely a hack and >>something that is bending the rules a bit on XML namespaces. >> >>5. Allow namespace bindings to be definde in the XCAP URI itself >> >>In this approach, bindings between namespace prefixes and namespace URI >>are present in the xcap URI itself. The xpointer xmlns specification >>(http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/) provides a way to >>define these. As an example of how this might work: >> >>http://xcap.example.com/services/resource-lists/users/bill/fr.xml/~~/ >> xmlns(foo="http://foo.example.com")/ >> resource-lists/list%5b@name=%22friends%22%5d/entry/foo:street-address >> >> >>In other words, right after the ~~ delimiter, the next path segment is >>actually a namespace definition, binding the namespace prefix "foo" to the >>URI "http://foo.example.com". That prefix is then used later on in the URI. >> >>The only question is where in the URI to place these definitions. Again, >>we only have so many choices that I can see: >> >>CHOICE A: immediately after the ~~/, in the next path segment, which would >>contain all such definitions as xmlns xpointer expressions. >> >>CHOICE B: anywhere in the URI, as a separate path segment >> >>CHOICE C: as part of a path segment that corresponds to an element, >>attribute or document >> >> >>I think the easiest thing is probably A. >> >>The main drawback to this approach is that its inclusion in a path segment >>at all is a stretch to the definition of a path, but conceptually you are >>navigating into a namespace, and within that namespace, to elements and >>attributes. >> >>It also leads to somewhat long-ish URI. >> >>I would further propose that application usages define a default namespace >>for the xcap URI evaluation, so as to avoid defining those in each and >>every URI. >> >> >> >> >>So, which to use? Considering the issues involved, I think the best option >>is 5(A). >> >>Comments? >> >>Thanks, >>Jonathan R. >> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 >>Cisco Systems >>jdrosen@cisco.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.cisco.com >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 31 21:01:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06866; Mon, 31 Jan 2005 21:01:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvne1-0001w0-I3; Mon, 31 Jan 2005 21:19:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvnKL-0008RB-DD; Mon, 31 Jan 2005 20:59:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvnEd-0007JH-7c for simple@megatron.ietf.org; Mon, 31 Jan 2005 20:53:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06074 for ; Mon, 31 Jan 2005 20:53:41 -0500 (EST) Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvnWg-0001mM-5P for simple@ietf.org; Mon, 31 Jan 2005 21:12:23 -0500 Received: from [69.170.17.195] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8956314 for simple@ietf.org; Mon, 31 Jan 2005 20:53:36 -0500 Message-Id: <6.1.2.0.0.20050131205207.03961208@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 31 Jan 2005 20:52:55 -0500 To: "'Simple WG'" From: "Joel M. Halpern" Subject: Re: [Simple] Namespaces and XCAP In-Reply-To: <41FEDB61.6030102@cisco.com> References: <41FEDB61.6030102@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Sounds like a good idea to me. It makes the normal case efficient, and matches the human expectation. Yours, Joel At 08:29 PM 1/31/2005, Jonathan Rosenberg wrote: >We are not normatively dependent on XPath, so we can do what we choose. I >would propose that the application usage specify the default namespace. >Otherwise, every single XCAP URI will need to contain a xmlns() xpointer >expression declaring the default namespace for the documents, all of which >are likely to use the target namespace as the default. > >If we specify this, an xcap expression would be compatible with xpath 2.0 >I believe. > >-Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple