From stpeter@stpeter.im Wed Nov 10 23:42:09 2010 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FEA3A6827 for ; Wed, 10 Nov 2010 23:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfv8F6FyxnX9 for ; Wed, 10 Nov 2010 23:42:08 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 07F8A3A68A7 for ; Wed, 10 Nov 2010 23:42:05 -0800 (PST) Received: from dhcp-710a.meeting.ietf.org (dhcp-710a.meeting.ietf.org [130.129.113.10]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 87C5640BB9 for ; Thu, 11 Nov 2010 00:51:56 -0700 (MST) Message-ID: <4CDB9E64.6070704@stpeter.im> Date: Thu, 11 Nov 2010 15:42:28 +0800 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: sixpac@ietf.org X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040207050605030706070302" Subject: [sixpac] charter proposal X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 07:42:09 -0000 This is a cryptographically signed message in MIME format. --------------ms040207050605030706070302 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To kick off discussion, here is the charter as I sent it to the dispath@ietf.org list a while back, with removal of a clause about working on user configuration, which I think is a large rathole. Let's discuss and get busy! /psa =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SIXPAC (SIP Integration with XMPP in Presence Aware Clients) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Problem Statement Both the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) are widely deployed technologies for real-time communication over the Internet. In order to offer a complete suite of features as well as communication across multiple networks, several user-oriented software applications support both SIP and XMPP, and more software developers have expressed interest in building such "dual-stack" solutions. Unfortunately, it is difficult to provide a good end-user experience in such applications because SIP and XMPP are not "aware" of each other. For example: - XMPP presence does not include availability states related to a SIP voice call or video call (e.g., "on the phone"), thus preventing an a dual-stack endpoint from showing presence-based communication hints - There is no correlation between an XMPP IM session and a SIP voice or video session, thus preventing a dual-stack endpoint from providing integrated user interfaces and communications history - SIP accounts and XMPP accounts are not directly correlated in contact lists or vCards (and not all deployed services support storage of such information), thus preventing a dual-stack endpoint from knowing that a contact has both SIP and XMPP capabilities Although some proprietary solutions exist to the foregoing problems, it would be preferable to define standardized solutions for the sake of improved interoperability. Objectives Because both SIP and XMPP are easily extended through new SIP headers and XMPP elements, it should be possible to provide tighter integration within dual-stack SIP/XMPP user agents to improve the user experience. Any such extensions should meet the following criteria: - Be completely optional and backwards-compatible for all endpoints - Work without changes to deployed infrastructure such as existing SIP and XMPP servers, B2BUAs, firewalls, etc. The SIXPAC WG will define a small number of SIP and XMPP extensions to solve the following use cases in dual-stack endpoints: - Including SIP-based availability states in XMPP presence (limited to basic presence and availability states only, not the full range of PIDF extensions) - Correlating an XMPP IM session with a SIP voice/video session, and vice-versa - Advertising a SIP account address over XMPP and an XMPP account address over SIP Additional use cases are out of scope, including anything related to or requiring server integration, multiparty communication, SIP-based IM and presence, XMPP-based voice and video, file transfer, generalized service discovery and capabilities exchange, full protocol translation in communication gateways, shared credentials across both SIP and XMPP accounts, rich presence extensions for features such as geolocation, etc. Although such topics are important and interesting, they are out of scope for this group. However, in addition to the protocol extensions explicitly mentioned above, the group may also define best practices related to the implementation and deployment of dual-stack SIP/XMPP endpoints. Deliverables - Use cases and protocol requirements - XMPP presence extension for SIP-based availability states - Media session correlation extensions for SIP and XMPP - Contact address advertisement extensions for SIP and XMPP - Best practices for implementation and deployment of dual-stack endpoints Milestones Feb 2011 Submit use cases and protocol requirements document to IESG (Informational) Oct 2011 Submit XMPP presence extension document to IESG (Standards Track) Oct 2011 Submit media session correlation extensions document to IESG (Standards Track) Oct 2011 Submit contact address advertisement extension document to IESG (Standards Track) Oct 2011 Submit best practices document to IESG (Informational) --------------ms040207050605030706070302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEx MTA3NDIyOFowIwYJKoZIhvcNAQkEMRYEFLX7glGy31SjzSJw7dUHyjJzQgUvMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAjxvNIgIxQ5DcBeFu67Garn07evG5SVgXgK6U9hqSwpsE2jrbQ1rY5Pfxy sNNBmQhx+M7C5Wq9RCmTxV/HgYx6yocegpN9ueSz9PA9InQxqAIwoicaLCT8CeWtRfOSlUEN XGz4UMmQKdQWmWhBzBve5mvk0RPAaEWQZgJ9xrj0jkwMSQIhi00ggAxEJsJGEjziKT/56gxD PKcAr91UU/e01YC54CnSaoiKSb8lKiOxgXtmcAAcmbnJ/2CZMT1akNRNYYWriibrwyYgtJ2q TQEuV3mW2PLqwpK4U8S0p9+voj5ldVuS/Ekv1FsrLg34PDwEx1IIuYYiv4RWZ/BnxW5YAAAA AAAA --------------ms040207050605030706070302-- From Simo.Veikkolainen@nokia.com Thu Nov 11 00:05:40 2010 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD7E3A69AD for ; Thu, 11 Nov 2010 00:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.849 X-Spam-Level: X-Spam-Status: No, score=-6.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iScnTWgBsdwf for ; Thu, 11 Nov 2010 00:05:39 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id EA1F83A6882 for ; Thu, 11 Nov 2010 00:05:38 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id oAB85gh2018857 for ; Thu, 11 Nov 2010 10:06:06 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 10:06:01 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 10:05:56 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 10:05:51 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 11 Nov 2010 09:05:48 +0100 From: To: Date: Thu, 11 Nov 2010 09:05:42 +0100 Thread-Topic: Drafts on SIP-XMPP combined use Thread-Index: AcuBdzyqM6VrCKMIRsai1BrTOtnxeg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Nov 2010 08:05:52.0078 (UTC) FILETIME=[422196E0:01CB8177] X-Nokia-AV: Clean Subject: [sixpac] Drafts on SIP-XMPP combined use X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 08:05:40 -0000 Thanks Peter for setting up this list! Just as a reminder, the relevant I-D for this work is=20 http://tools.ietf.org/html/draft-veikkolainen-sip-xmpp-coex-reqs-01 We had an earlier draft containing also the protocol extensions, but that o= ne has been expired. However, you can find it at=20 http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im For our first target, I think we should concentrate on getting a set of req= uirements which is agreeable for all. Regards, Simo From emcho@sip-communicator.org Thu Nov 11 08:46:56 2010 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80BC53A6952 for ; Thu, 11 Nov 2010 08:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhzqD7YwM9qV for ; Thu, 11 Nov 2010 08:46:54 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id D02783A69FC for ; Thu, 11 Nov 2010 08:46:53 -0800 (PST) Received: by gxk27 with SMTP id 27so1468516gxk.31 for ; Thu, 11 Nov 2010 08:47:23 -0800 (PST) Received: by 10.151.103.14 with SMTP id f14mr2041213ybm.319.1289494043433; Thu, 11 Nov 2010 08:47:23 -0800 (PST) Received: from porcinet.local (nsc64.16.130-178.newsouth.net [64.16.130.178]) by mx.google.com with ESMTPS id v9sm7613ybe.21.2010.11.11.08.47.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 08:47:22 -0800 (PST) Message-ID: <4CDC1E19.7090208@sip-communicator.org> Date: Thu, 11 Nov 2010 11:47:21 -0500 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <4CDB9E64.6070704@stpeter.im> In-Reply-To: <4CDB9E64.6070704@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sixpac@ietf.org Subject: Re: [sixpac] charter proposal X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 16:46:56 -0000 Hey Peter, =D0=9D=D0=B0 11.11.10 02:42, Peter Saint-Andre =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: > To kick off discussion, here is the charter as I sent it to the > dispath@ietf.org list a while back, with removal of a clause about > working on user configuration, which I think is a large rathole. Well, I thought we had agreed on this and was quite surprised to find out that for some unknown reason it was once again _the_ issue with the sixpac charter :). Frankly, I never really understood what people were so worried about. What harm could it cause to have a statement that advises implementors how to lookup the SIP and XMPP services for a sixpac account? Besides, how else would you make this work in generic clients? Should users always manually configure the XMPP server address and the SIP proxy address, port and transport? Cheers, Emil >=20 > Let's discuss and get busy! >=20 > /psa >=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=3D=3D=3D=3D=3D > SIXPAC (SIP Integration with XMPP in Presence Aware Clients) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =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 > Problem Statement >=20 > Both the Session Initiation Protocol (SIP) and the Extensible Messaging= > and Presence Protocol (XMPP) are widely deployed technologies for > real-time communication over the Internet. In order to offer a complet= e > suite of features as well as communication across multiple networks, > several user-oriented software applications support both SIP and XMPP, > and more software developers have expressed interest in building such > "dual-stack" solutions. Unfortunately, it is difficult to provide a > good end-user experience in such applications because SIP and XMPP are > not "aware" of each other. For example: >=20 > - XMPP presence does not include availability states related to a SIP > voice call or video call (e.g., "on the phone"), thus preventing an > a dual-stack endpoint from showing presence-based communication hints= >=20 > - There is no correlation between an XMPP IM session and a SIP voice > or video session, thus preventing a dual-stack endpoint from providin= g > integrated user interfaces and communications history >=20 > - SIP accounts and XMPP accounts are not directly correlated in contact= > lists or vCards (and not all deployed services support storage of suc= h > information), thus preventing a dual-stack endpoint from knowing that= > a contact has both SIP and XMPP capabilities >=20 > Although some proprietary solutions exist to the foregoing problems, it= > would be preferable to define standardized solutions for the sake of > improved interoperability. >=20 > Objectives >=20 > Because both SIP and XMPP are easily extended through new SIP headers > and XMPP elements, it should be possible to provide tighter integration= > within dual-stack SIP/XMPP user agents to improve the user experience. >=20 > Any such extensions should meet the following criteria: >=20 > - Be completely optional and backwards-compatible for all endpoints >=20 > - Work without changes to deployed infrastructure such as existing > SIP and XMPP servers, B2BUAs, firewalls, etc. >=20 > The SIXPAC WG will define a small number of SIP and XMPP extensions to > solve the following use cases in dual-stack endpoints: >=20 > - Including SIP-based availability states in XMPP presence (limited to > basic presence and availability states only, not the full range of > PIDF extensions) >=20 > - Correlating an XMPP IM session with a SIP voice/video session, and > vice-versa >=20 > - Advertising a SIP account address over XMPP and an XMPP account > address over SIP >=20 > Additional use cases are out of scope, including anything related to or= > requiring server integration, multiparty communication, SIP-based IM an= d > presence, XMPP-based voice and video, file transfer, generalized servic= e > discovery and capabilities exchange, full protocol translation in > communication gateways, shared credentials across both SIP and XMPP > accounts, rich presence extensions for features such as geolocation, > etc. Although such topics are important and interesting, they are out o= f > scope for this group. >=20 > However, in addition to the protocol extensions explicitly mentioned > above, the group may also define best practices related to the > implementation and deployment of dual-stack SIP/XMPP endpoints. >=20 > Deliverables >=20 > - Use cases and protocol requirements >=20 > - XMPP presence extension for SIP-based availability states >=20 > - Media session correlation extensions for SIP and XMPP >=20 > - Contact address advertisement extensions for SIP and XMPP >=20 > - Best practices for implementation and deployment of dual-stack > endpoints >=20 > Milestones >=20 > Feb 2011 Submit use cases and protocol requirements document to > IESG (Informational) >=20 > Oct 2011 Submit XMPP presence extension document to IESG > (Standards Track) >=20 > Oct 2011 Submit media session correlation extensions document to IESG > (Standards Track) >=20 > Oct 2011 Submit contact address advertisement extension document to > IESG (Standards Track) >=20 > Oct 2011 Submit best practices document to IESG (Informational) >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > sixpac mailing list > sixpac@ietf.org > https://www.ietf.org/mailman/listinfo/sixpac --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France SIP Communicator emcho@sip-communicator.org PHONE: +33.1.77.62.43.30 http://sip-communicator.org FAX: +33.1.77.62.47.31 From Markus.Isomaki@nokia.com Thu Nov 11 08:54:01 2010 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04693A6A87 for ; Thu, 11 Nov 2010 08:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWYoBKAJRkeq for ; Thu, 11 Nov 2010 08:53:56 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 50F153A6A15 for ; Thu, 11 Nov 2010 08:53:54 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id oABGsARf018464; Thu, 11 Nov 2010 10:54:20 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 18:54:18 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 18:54:06 +0200 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 11 Nov 2010 17:54:05 +0100 From: To: , Date: Thu, 11 Nov 2010 17:54:02 +0100 Thread-Topic: [sixpac] charter proposal Thread-Index: AcuBwCoC68RxvpOzR/WbO1DNa+ormQAACj1g Message-ID: References: <4CDB9E64.6070704@stpeter.im> <4CDC1E19.7090208@sip-communicator.org> In-Reply-To: <4CDC1E19.7090208@sip-communicator.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 11 Nov 2010 16:54:06.0627 (UTC) FILETIME=[0D8DF730:01CB81C1] X-Nokia-AV: Clean Cc: sixpac@ietf.org Subject: Re: [sixpac] charter proposal X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 16:54:01 -0000 SGkgRW1pbCwNCg0KV2UgaGF2ZSBkaXNjdXNzZWQgYWJvdXQgdGhlIGNvbmZpZ3VyYXRpb24gYSBj b3VwbGUgb2YgdGltZXMgdGhpcyB3ZWVrLiBUaGUgcHJvYmxlbSB3YXMgdGhhdCBuby1vbmUgaGVy ZSBjb3VsZCBhbnltb3JlIGV4cGxhaW4gd2hhdCB3ZSBhY3R1YWxseSBtZWFudCBieSB0aGF0IHN0 YXRlbWVudCBpbiB0aGUgY2hhcnRlciBwcm9wb3NhbC4gQm90aCBTSVAgYW5kIFhNUFAgY2xpZW50 cyBoYXZlIHdheXMgdG8gZ2V0IHRoZWlyIGNvbmZpZ3MgYXV0b21hdGljYWxseS4gSW4gU0lQIHRo ZXJlIGlzIG5vIHdpZGVseSBzdXBwb3J0ZWQgc3RhbmRhcmQgZm9yIHRoaXMsIGluc3RlYWQgYSBu dW1iZXIgb2YgcHJvcHJpZXRhcnkgc29sdXRpb25zIGFyZSB1c2VkLiBOb3cgd2UgZG8gaGF2ZSB0 aGUgU0lQIEZvcnVtIHdvcmsgYXMgYmFzaXMsIG9mIGNvdXJzZS4gDQoNCkJ1dCB3aGVuIGl0IGNv bWVzIHRvIFNJWFBBQyBjbGllbnRzLCB3aGF0IGl0IGlzIHRoYXQgd2UgY291bGQgZG8gYmV5b25k IHNheWluZyB0aGF0IGZvciB0aGUgU0lQIGNvbmZpZyB0aGV5IHVzZSB3aGF0ZXZlciBpcyB1c2Vk IGZvciBTSVAgYW5kIGZvciBYTVBQIHdoYXRldmVyIGlzIHVzZWQgZm9yIFhNUFA/IEl0IG1heSBi ZSBwcm9ibGVtYXRpYyBidXQgaXMgaXQgYSBiaWdnZXIgcHJvYmxlbSB0aGF0IHNheSBjb25maWd1 cmluZyB0d28gc2VwYXJhdGUgU0lQIGFuZCBYTVBQIGNsaWVudHM/DQoNCk1hcmt1cw0KDQoNCj4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHNpeHBhYy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86c2l4cGFjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPk9mIGV4dCBFbWls IEl2b3YNCj5TZW50OiAxMSBOb3ZlbWJlciwgMjAxMCAxODo0Nw0KPlRvOiBQZXRlciBTYWludC1B bmRyZQ0KPkNjOiBzaXhwYWNAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3NpeHBhY10gY2hhcnRl ciBwcm9wb3NhbA0KPg0KPkhleSBQZXRlciwNCj4NCj7QndCwIDExLjExLjEwIDAyOjQyLCBQZXRl ciBTYWludC1BbmRyZSDQvdCw0L/QuNGB0LA6DQo+PiBUbyBraWNrIG9mZiBkaXNjdXNzaW9uLCBo ZXJlIGlzIHRoZSBjaGFydGVyIGFzIEkgc2VudCBpdCB0byB0aGUNCj4+IGRpc3BhdGhAaWV0Zi5v cmcgbGlzdCBhIHdoaWxlIGJhY2ssIHdpdGggcmVtb3ZhbCBvZiBhIGNsYXVzZSBhYm91dA0KPj4g d29ya2luZyBvbiB1c2VyIGNvbmZpZ3VyYXRpb24sIHdoaWNoIEkgdGhpbmsgaXMgYSBsYXJnZSBy YXRob2xlLg0KPg0KPldlbGwsIEkgdGhvdWdodCB3ZSBoYWQgYWdyZWVkIG9uIHRoaXMgYW5kIHdh cyBxdWl0ZSBzdXJwcmlzZWQgdG8gZmluZA0KPm91dCB0aGF0IGZvciBzb21lIHVua25vd24gcmVh c29uIGl0IHdhcyBvbmNlIGFnYWluIF90aGVfIGlzc3VlIHdpdGggdGhlDQo+c2l4cGFjIGNoYXJ0 ZXIgOikuDQo+DQo+RnJhbmtseSwgSSBuZXZlciByZWFsbHkgdW5kZXJzdG9vZCB3aGF0IHBlb3Bs ZSB3ZXJlIHNvIHdvcnJpZWQgYWJvdXQuDQo+V2hhdCBoYXJtIGNvdWxkIGl0IGNhdXNlIHRvIGhh dmUgYSBzdGF0ZW1lbnQgdGhhdCBhZHZpc2VzIGltcGxlbWVudG9ycw0KPmhvdyB0byBsb29rdXAg dGhlIFNJUCBhbmQgWE1QUCBzZXJ2aWNlcyBmb3IgYSBzaXhwYWMgYWNjb3VudD8NCj4NCj5CZXNp ZGVzLCBob3cgZWxzZSB3b3VsZCB5b3UgbWFrZSB0aGlzIHdvcmsgaW4gZ2VuZXJpYyBjbGllbnRz PyBTaG91bGQNCj51c2VycyBhbHdheXMgbWFudWFsbHkgY29uZmlndXJlIHRoZSBYTVBQIHNlcnZl ciBhZGRyZXNzIGFuZCB0aGUgU0lQDQo+cHJveHkgYWRkcmVzcywgcG9ydCBhbmQgdHJhbnNwb3J0 Pw0KPg0KPkNoZWVycywNCj5FbWlsDQo+Pg0KPj4gTGV0J3MgZGlzY3VzcyBhbmQgZ2V0IGJ1c3kh DQo+Pg0KPj4gL3BzYQ0KPj4NCj4+DQo+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+PQ0KPj4gU0lYUEFDIChT SVAgSW50ZWdyYXRpb24gd2l0aCBYTVBQIGluIFByZXNlbmNlIEF3YXJlIENsaWVudHMpDQo+Pg0K Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KPj0NCj4+DQo+PiBQcm9ibGVtIFN0YXRlbWVudA0KPj4NCj4+IEJv dGggdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBhbmQgdGhlIEV4dGVuc2li bGUNCj5NZXNzYWdpbmcNCj4+IGFuZCBQcmVzZW5jZSBQcm90b2NvbCAoWE1QUCkgYXJlIHdpZGVs eSBkZXBsb3llZCB0ZWNobm9sb2dpZXMgZm9yDQo+PiByZWFsLXRpbWUgY29tbXVuaWNhdGlvbiBv dmVyIHRoZSBJbnRlcm5ldC4gIEluIG9yZGVyIHRvIG9mZmVyIGENCj5jb21wbGV0ZQ0KPj4gc3Vp dGUgb2YgZmVhdHVyZXMgYXMgd2VsbCBhcyBjb21tdW5pY2F0aW9uIGFjcm9zcyBtdWx0aXBsZSBu ZXR3b3JrcywNCj4+IHNldmVyYWwgdXNlci1vcmllbnRlZCBzb2Z0d2FyZSBhcHBsaWNhdGlvbnMg c3VwcG9ydCBib3RoIFNJUCBhbmQgWE1QUCwNCj4+IGFuZCBtb3JlIHNvZnR3YXJlIGRldmVsb3Bl cnMgaGF2ZSBleHByZXNzZWQgaW50ZXJlc3QgaW4gYnVpbGRpbmcgc3VjaA0KPj4gImR1YWwtc3Rh Y2siIHNvbHV0aW9ucy4gIFVuZm9ydHVuYXRlbHksIGl0IGlzIGRpZmZpY3VsdCB0byBwcm92aWRl IGENCj4+IGdvb2QgZW5kLXVzZXIgZXhwZXJpZW5jZSBpbiBzdWNoIGFwcGxpY2F0aW9ucyBiZWNh dXNlIFNJUCBhbmQgWE1QUCBhcmUNCj4+IG5vdCAiYXdhcmUiIG9mIGVhY2ggb3RoZXIuICBGb3Ig ZXhhbXBsZToNCj4+DQo+PiAtIFhNUFAgcHJlc2VuY2UgZG9lcyBub3QgaW5jbHVkZSBhdmFpbGFi aWxpdHkgc3RhdGVzIHJlbGF0ZWQgdG8gYSBTSVANCj4+ICAgdm9pY2UgY2FsbCBvciB2aWRlbyBj YWxsIChlLmcuLCAib24gdGhlIHBob25lIiksIHRodXMgcHJldmVudGluZyBhbg0KPj4gICBhIGR1 YWwtc3RhY2sgZW5kcG9pbnQgZnJvbSBzaG93aW5nIHByZXNlbmNlLWJhc2VkIGNvbW11bmljYXRp b24NCj5oaW50cw0KPj4NCj4+IC0gVGhlcmUgaXMgbm8gY29ycmVsYXRpb24gYmV0d2VlbiBhbiBY TVBQIElNIHNlc3Npb24gYW5kIGEgU0lQIHZvaWNlDQo+PiAgIG9yIHZpZGVvIHNlc3Npb24sIHRo dXMgcHJldmVudGluZyBhIGR1YWwtc3RhY2sgZW5kcG9pbnQgZnJvbQ0KPnByb3ZpZGluZw0KPj4g ICBpbnRlZ3JhdGVkIHVzZXIgaW50ZXJmYWNlcyBhbmQgY29tbXVuaWNhdGlvbnMgaGlzdG9yeQ0K Pj4NCj4+IC0gU0lQIGFjY291bnRzIGFuZCBYTVBQIGFjY291bnRzIGFyZSBub3QgZGlyZWN0bHkg Y29ycmVsYXRlZCBpbg0KPmNvbnRhY3QNCj4+ICAgbGlzdHMgb3IgdkNhcmRzIChhbmQgbm90IGFs bCBkZXBsb3llZCBzZXJ2aWNlcyBzdXBwb3J0IHN0b3JhZ2Ugb2YNCj5zdWNoDQo+PiAgIGluZm9y bWF0aW9uKSwgdGh1cyBwcmV2ZW50aW5nIGEgZHVhbC1zdGFjayBlbmRwb2ludCBmcm9tIGtub3dp bmcNCj50aGF0DQo+PiAgIGEgY29udGFjdCBoYXMgYm90aCBTSVAgYW5kIFhNUFAgY2FwYWJpbGl0 aWVzDQo+Pg0KPj4gQWx0aG91Z2ggc29tZSBwcm9wcmlldGFyeSBzb2x1dGlvbnMgZXhpc3QgdG8g dGhlIGZvcmVnb2luZyBwcm9ibGVtcywNCj5pdA0KPj4gd291bGQgYmUgcHJlZmVyYWJsZSB0byBk ZWZpbmUgc3RhbmRhcmRpemVkIHNvbHV0aW9ucyBmb3IgdGhlIHNha2Ugb2YNCj4+IGltcHJvdmVk IGludGVyb3BlcmFiaWxpdHkuDQo+Pg0KPj4gT2JqZWN0aXZlcw0KPj4NCj4+IEJlY2F1c2UgYm90 aCBTSVAgYW5kIFhNUFAgYXJlIGVhc2lseSBleHRlbmRlZCB0aHJvdWdoIG5ldyBTSVAgaGVhZGVy cw0KPj4gYW5kIFhNUFAgZWxlbWVudHMsIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBwcm92aWRl IHRpZ2h0ZXINCj5pbnRlZ3JhdGlvbg0KPj4gd2l0aGluIGR1YWwtc3RhY2sgU0lQL1hNUFAgdXNl ciBhZ2VudHMgdG8gaW1wcm92ZSB0aGUgdXNlciBleHBlcmllbmNlLg0KPj4NCj4+IEFueSBzdWNo IGV4dGVuc2lvbnMgc2hvdWxkIG1lZXQgdGhlIGZvbGxvd2luZyBjcml0ZXJpYToNCj4+DQo+PiAt IEJlIGNvbXBsZXRlbHkgb3B0aW9uYWwgYW5kIGJhY2t3YXJkcy1jb21wYXRpYmxlIGZvciBhbGwg ZW5kcG9pbnRzDQo+Pg0KPj4gLSBXb3JrIHdpdGhvdXQgY2hhbmdlcyB0byBkZXBsb3llZCBpbmZy YXN0cnVjdHVyZSBzdWNoIGFzIGV4aXN0aW5nDQo+PiAgIFNJUCBhbmQgWE1QUCBzZXJ2ZXJzLCBC MkJVQXMsIGZpcmV3YWxscywgZXRjLg0KPj4NCj4+IFRoZSBTSVhQQUMgV0cgd2lsbCBkZWZpbmUg YSBzbWFsbCBudW1iZXIgb2YgU0lQIGFuZCBYTVBQIGV4dGVuc2lvbnMgdG8NCj4+IHNvbHZlIHRo ZSBmb2xsb3dpbmcgdXNlIGNhc2VzIGluIGR1YWwtc3RhY2sgZW5kcG9pbnRzOg0KPj4NCj4+IC0g SW5jbHVkaW5nIFNJUC1iYXNlZCBhdmFpbGFiaWxpdHkgc3RhdGVzIGluIFhNUFAgcHJlc2VuY2Ug KGxpbWl0ZWQgdG8NCj4+ICAgYmFzaWMgcHJlc2VuY2UgYW5kIGF2YWlsYWJpbGl0eSBzdGF0ZXMg b25seSwgbm90IHRoZSBmdWxsIHJhbmdlIG9mDQo+PiAgIFBJREYgZXh0ZW5zaW9ucykNCj4+DQo+ PiAtIENvcnJlbGF0aW5nIGFuIFhNUFAgSU0gc2Vzc2lvbiB3aXRoIGEgU0lQIHZvaWNlL3ZpZGVv IHNlc3Npb24sIGFuZA0KPj4gICB2aWNlLXZlcnNhDQo+Pg0KPj4gLSBBZHZlcnRpc2luZyBhIFNJ UCBhY2NvdW50IGFkZHJlc3Mgb3ZlciBYTVBQIGFuZCBhbiBYTVBQIGFjY291bnQNCj4+ICAgYWRk cmVzcyBvdmVyIFNJUA0KPj4NCj4+IEFkZGl0aW9uYWwgdXNlIGNhc2VzIGFyZSBvdXQgb2Ygc2Nv cGUsIGluY2x1ZGluZyBhbnl0aGluZyByZWxhdGVkIHRvDQo+b3INCj4+IHJlcXVpcmluZyBzZXJ2 ZXIgaW50ZWdyYXRpb24sIG11bHRpcGFydHkgY29tbXVuaWNhdGlvbiwgU0lQLWJhc2VkIElNDQo+ YW5kDQo+PiBwcmVzZW5jZSwgWE1QUC1iYXNlZCB2b2ljZSBhbmQgdmlkZW8sIGZpbGUgdHJhbnNm ZXIsIGdlbmVyYWxpemVkDQo+c2VydmljZQ0KPj4gZGlzY292ZXJ5IGFuZCBjYXBhYmlsaXRpZXMg ZXhjaGFuZ2UsIGZ1bGwgcHJvdG9jb2wgdHJhbnNsYXRpb24gaW4NCj4+IGNvbW11bmljYXRpb24g Z2F0ZXdheXMsIHNoYXJlZCBjcmVkZW50aWFscyBhY3Jvc3MgYm90aCBTSVAgYW5kIFhNUFANCj4+ IGFjY291bnRzLCByaWNoIHByZXNlbmNlIGV4dGVuc2lvbnMgZm9yIGZlYXR1cmVzIHN1Y2ggYXMg Z2VvbG9jYXRpb24sDQo+PiBldGMuIEFsdGhvdWdoIHN1Y2ggdG9waWNzIGFyZSBpbXBvcnRhbnQg YW5kIGludGVyZXN0aW5nLCB0aGV5IGFyZSBvdXQNCj5vZg0KPj4gc2NvcGUgZm9yIHRoaXMgZ3Jv dXAuDQo+Pg0KPj4gSG93ZXZlciwgaW4gYWRkaXRpb24gdG8gdGhlIHByb3RvY29sIGV4dGVuc2lv bnMgZXhwbGljaXRseSBtZW50aW9uZWQNCj4+IGFib3ZlLCB0aGUgZ3JvdXAgbWF5IGFsc28gZGVm aW5lIGJlc3QgcHJhY3RpY2VzIHJlbGF0ZWQgdG8gdGhlDQo+PiBpbXBsZW1lbnRhdGlvbiBhbmQg ZGVwbG95bWVudCBvZiBkdWFsLXN0YWNrIFNJUC9YTVBQIGVuZHBvaW50cy4NCj4+DQo+PiBEZWxp dmVyYWJsZXMNCj4+DQo+PiAtIFVzZSBjYXNlcyBhbmQgcHJvdG9jb2wgcmVxdWlyZW1lbnRzDQo+ Pg0KPj4gLSBYTVBQIHByZXNlbmNlIGV4dGVuc2lvbiBmb3IgU0lQLWJhc2VkIGF2YWlsYWJpbGl0 eSBzdGF0ZXMNCj4+DQo+PiAtIE1lZGlhIHNlc3Npb24gY29ycmVsYXRpb24gZXh0ZW5zaW9ucyBm b3IgU0lQIGFuZCBYTVBQDQo+Pg0KPj4gLSBDb250YWN0IGFkZHJlc3MgYWR2ZXJ0aXNlbWVudCBl eHRlbnNpb25zIGZvciBTSVAgYW5kIFhNUFANCj4+DQo+PiAtIEJlc3QgcHJhY3RpY2VzIGZvciBp bXBsZW1lbnRhdGlvbiBhbmQgZGVwbG95bWVudCBvZiBkdWFsLXN0YWNrDQo+PiAgIGVuZHBvaW50 cw0KPj4NCj4+IE1pbGVzdG9uZXMNCj4+DQo+PiBGZWIgMjAxMSAgU3VibWl0IHVzZSBjYXNlcyBh bmQgcHJvdG9jb2wgcmVxdWlyZW1lbnRzIGRvY3VtZW50IHRvDQo+PiBJRVNHIChJbmZvcm1hdGlv bmFsKQ0KPj4NCj4+IE9jdCAyMDExICBTdWJtaXQgWE1QUCBwcmVzZW5jZSBleHRlbnNpb24gZG9j dW1lbnQgdG8gSUVTRw0KPj4gKFN0YW5kYXJkcyBUcmFjaykNCj4+DQo+PiBPY3QgMjAxMSAgU3Vi bWl0IG1lZGlhIHNlc3Npb24gY29ycmVsYXRpb24gZXh0ZW5zaW9ucyBkb2N1bWVudCB0byBJRVNH DQo+PiAoU3RhbmRhcmRzIFRyYWNrKQ0KPj4NCj4+IE9jdCAyMDExICBTdWJtaXQgY29udGFjdCBh ZGRyZXNzIGFkdmVydGlzZW1lbnQgZXh0ZW5zaW9uIGRvY3VtZW50IHRvDQo+PiBJRVNHIChTdGFu ZGFyZHMgVHJhY2spDQo+Pg0KPj4gT2N0IDIwMTEgIFN1Ym1pdCBiZXN0IHByYWN0aWNlcyBkb2N1 bWVudCB0byBJRVNHIChJbmZvcm1hdGlvbmFsKQ0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2l4cGFjIG1h aWxpbmcgbGlzdA0KPj4gc2l4cGFjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpeHBhYw0KPg0KPi0tDQo+RW1pbCBJdm92LCBQaC5ELiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA2NzAwMCBTdHJhc2JvdXJnLA0KPlByb2plY3QgTGVhZCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRnJhbmNlDQo+U0lQIENvbW11bmljYXRv cg0KPmVtY2hvQHNpcC1jb21tdW5pY2F0b3Iub3JnICAgICAgICAgICAgICAgICAgICAgUEhPTkU6 ICszMy4xLjc3LjYyLjQzLjMwDQo+aHR0cDovL3NpcC1jb21tdW5pY2F0b3Iub3JnICAgICAgICAg ICAgICAgICAgICBGQVg6ICAgKzMzLjEuNzcuNjIuNDcuMzENCj4NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNpeHBhYyBtYWlsaW5nIGxpc3QNCj5z aXhwYWNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np eHBhYw0K From Markus.Isomaki@nokia.com Thu Nov 11 09:06:25 2010 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A33553A69E9 for ; Thu, 11 Nov 2010 09:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzcnyvAWDQ56 for ; Thu, 11 Nov 2010 09:06:24 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 6BEEA3A6970 for ; Thu, 11 Nov 2010 09:06:24 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id oABH6D1j028753; Thu, 11 Nov 2010 11:06:54 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 19:06:34 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 19:06:22 +0200 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 11 Nov 2010 18:06:21 +0100 From: To: , Date: Thu, 11 Nov 2010 18:06:18 +0100 Thread-Topic: charter proposal - correlation between SIP and XMPP Thread-Index: AcuBdBTof9MKI3nOSPyUtHiXE8PY2AATQGlg Message-ID: References: <4CDB9E64.6070704@stpeter.im> In-Reply-To: <4CDB9E64.6070704@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 11 Nov 2010 17:06:22.0575 (UTC) FILETIME=[C436B7F0:01CB81C2] X-Nokia-AV: Clean Subject: [sixpac] charter proposal - correlation between SIP and XMPP X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 17:06:25 -0000 SGksDQoNClRoZSBjaGFydGVyIHNheXM6DQoNCj4tIFRoZXJlIGlzIG5vIGNvcnJlbGF0aW9uIGJl dHdlZW4gYW4gWE1QUCBJTSBzZXNzaW9uIGFuZCBhIFNJUCB2b2ljZQ0KPiAgb3IgdmlkZW8gc2Vz c2lvbiwgdGh1cyBwcmV2ZW50aW5nIGEgZHVhbC1zdGFjayBlbmRwb2ludCBmcm9tIHByb3ZpZGlu Zw0KPiAgaW50ZWdyYXRlZCB1c2VyIGludGVyZmFjZXMgYW5kIGNvbW11bmljYXRpb25zIGhpc3Rv cnkNCg0KSXQgaGFzIGJlZW4gcG9pbnRlZCBvdXQgdGhhdCBpbiBTSVAgd2UgbWF5IGhhdmUgcHJh Y3RpY2FsIGNoYWxsZW5nZXMgdG8gYWNoaWV2ZSB0aGlzIHdpdGggYSBoaWdoIGxpa2VsaWhvb2Qu IFRoaXMgbWVhbnMgdGhhdCBpZiBvdXIgc29sdXRpb24gaXMgYmFzZWQgb24gc29tZSBraW5kIG9m IHRva2VuIHRoYXQgaXMgZXhjaGFuZ2VkIGJldHdlZW4gdGhlIHR3byBTSVhQQUMgY2xpZW50cyBv dmVyIFNJUCAoc28gdGhhdCB0aGV5IGNhbiByZXBsYXkgaXQgbGF0ZXIgb24gb3ZlciBYTVBQIGZv ciBjb3JyZWxhdGlvbiksIGFuZCBpZiB3ZSBwdXQgdGhhdCB0b2tlbiBpbiBzb21lIGtpbmQgb2Yg YSBuZXcgaGVhZGVyLCBpdCBpcyBwb3NzaWJsZSB0aGF0IEIyQlVBJ3Mgb24gdGhlIHBhdGggd2ls bCAiZWF0IiBzdWNoIGhlYWRlcnMgb3V0LiBTbyBhcyBhIHByYWN0aWNhbCBjb25zaWRlcmF0aW9u IHdlIGhhdmUgdG8gdGhpbmsgYWJvdXQgd2hhdCBoYXBwZW5zIGlmIHRoYXQga2luZCBvZiBleGNo YW5nZSBmYWlscy4NCg0KQXMgYSBtYXR0ZXIgb2YgZmFjdCwgSSBkb24ndCB0aGluayB0aGF0IHN1 Y2ggYSBjb3JyZWxhdGlvbiB0b2tlbiBpcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeSBmb3IgYSBnb29k IHVzZXIgZXhwZXJpZW5jZS4gQnV0IHdlIGRvIG5lZWQgdGhpczoNCg0KPi0gQWR2ZXJ0aXNpbmcg YSBTSVAgYWNjb3VudCBhZGRyZXNzIG92ZXIgWE1QUCBhbmQgYW4gWE1QUCBhY2NvdW50DQo+ICBh ZGRyZXNzIG92ZXIgU0lQDQoNCkkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYSByZWFzb24gdG8gY2hh bmdlIG91ciBjaGFydGVyIGF0IGFsbCBiZWNhdXNlIG9mIHRoaXMsIGJ1dCB0aGlzIGlzIHBlcmhh cHMgc29tZXRoaW5nIHRoYXQgd2UgY291bGQgY292ZXIgaW4gdGhlIHVzZSBjYXNlcyBhbmQgcmVx dWlyZW1lbnRzIGRvY3VtZW50Lg0KDQpNYXJrdXMNCg0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj5Gcm9tOiBzaXhwYWMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpeHBhYy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj5PZiBleHQgUGV0ZXIgU2FpbnQtQW5kcmUNCj5TZW50 OiAxMSBOb3ZlbWJlciwgMjAxMCAwOTo0Mg0KPlRvOiBzaXhwYWNAaWV0Zi5vcmcNCj5TdWJqZWN0 OiBbc2l4cGFjXSBjaGFydGVyIHByb3Bvc2FsDQo+DQo+VG8ga2ljayBvZmYgZGlzY3Vzc2lvbiwg aGVyZSBpcyB0aGUgY2hhcnRlciBhcyBJIHNlbnQgaXQgdG8gdGhlDQo+ZGlzcGF0aEBpZXRmLm9y ZyBsaXN0IGEgd2hpbGUgYmFjaywgd2l0aCByZW1vdmFsIG9mIGEgY2xhdXNlIGFib3V0DQo+d29y a2luZyBvbiB1c2VyIGNvbmZpZ3VyYXRpb24sIHdoaWNoIEkgdGhpbmsgaXMgYSBsYXJnZSByYXRo b2xlLg0KPg0KPkxldCdzIGRpc2N1c3MgYW5kIGdldCBidXN5IQ0KPg0KPi9wc2ENCj4NCj49PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCj49DQo+U0lYUEFDIChTSVAgSW50ZWdyYXRpb24gd2l0aCBYTVBQIGluIFBy ZXNlbmNlIEF3YXJlIENsaWVudHMpDQo+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+PQ0KPg0KPlByb2JsZW0g U3RhdGVtZW50DQo+DQo+Qm90aCB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVAp IGFuZCB0aGUgRXh0ZW5zaWJsZSBNZXNzYWdpbmcNCj5hbmQgUHJlc2VuY2UgUHJvdG9jb2wgKFhN UFApIGFyZSB3aWRlbHkgZGVwbG95ZWQgdGVjaG5vbG9naWVzIGZvciByZWFsLQ0KPnRpbWUgY29t bXVuaWNhdGlvbiBvdmVyIHRoZSBJbnRlcm5ldC4gIEluIG9yZGVyIHRvIG9mZmVyIGEgY29tcGxl dGUNCj5zdWl0ZSBvZiBmZWF0dXJlcyBhcyB3ZWxsIGFzIGNvbW11bmljYXRpb24gYWNyb3NzIG11 bHRpcGxlIG5ldHdvcmtzLA0KPnNldmVyYWwgdXNlci1vcmllbnRlZCBzb2Z0d2FyZSBhcHBsaWNh dGlvbnMgc3VwcG9ydCBib3RoIFNJUCBhbmQgWE1QUCwNCj5hbmQgbW9yZSBzb2Z0d2FyZSBkZXZl bG9wZXJzIGhhdmUgZXhwcmVzc2VkIGludGVyZXN0IGluIGJ1aWxkaW5nIHN1Y2gNCj4iZHVhbC1z dGFjayIgc29sdXRpb25zLiAgVW5mb3J0dW5hdGVseSwgaXQgaXMgZGlmZmljdWx0IHRvIHByb3Zp ZGUgYQ0KPmdvb2QgZW5kLXVzZXIgZXhwZXJpZW5jZSBpbiBzdWNoIGFwcGxpY2F0aW9ucyBiZWNh dXNlIFNJUCBhbmQgWE1QUCBhcmUNCj5ub3QgImF3YXJlIiBvZiBlYWNoIG90aGVyLiAgRm9yIGV4 YW1wbGU6DQo+DQo+LSBYTVBQIHByZXNlbmNlIGRvZXMgbm90IGluY2x1ZGUgYXZhaWxhYmlsaXR5 IHN0YXRlcyByZWxhdGVkIHRvIGEgU0lQDQo+ICB2b2ljZSBjYWxsIG9yIHZpZGVvIGNhbGwgKGUu Zy4sICJvbiB0aGUgcGhvbmUiKSwgdGh1cyBwcmV2ZW50aW5nIGFuDQo+ICBhIGR1YWwtc3RhY2sg ZW5kcG9pbnQgZnJvbSBzaG93aW5nIHByZXNlbmNlLWJhc2VkIGNvbW11bmljYXRpb24gaGludHMN Cj4NCj4tIFRoZXJlIGlzIG5vIGNvcnJlbGF0aW9uIGJldHdlZW4gYW4gWE1QUCBJTSBzZXNzaW9u IGFuZCBhIFNJUCB2b2ljZQ0KPiAgb3IgdmlkZW8gc2Vzc2lvbiwgdGh1cyBwcmV2ZW50aW5nIGEg ZHVhbC1zdGFjayBlbmRwb2ludCBmcm9tIHByb3ZpZGluZw0KPiAgaW50ZWdyYXRlZCB1c2VyIGlu dGVyZmFjZXMgYW5kIGNvbW11bmljYXRpb25zIGhpc3RvcnkNCj4NCj4tIFNJUCBhY2NvdW50cyBh bmQgWE1QUCBhY2NvdW50cyBhcmUgbm90IGRpcmVjdGx5IGNvcnJlbGF0ZWQgaW4gY29udGFjdA0K PiAgbGlzdHMgb3IgdkNhcmRzIChhbmQgbm90IGFsbCBkZXBsb3llZCBzZXJ2aWNlcyBzdXBwb3J0 IHN0b3JhZ2Ugb2Ygc3VjaA0KPiAgaW5mb3JtYXRpb24pLCB0aHVzIHByZXZlbnRpbmcgYSBkdWFs LXN0YWNrIGVuZHBvaW50IGZyb20ga25vd2luZyB0aGF0DQo+ICBhIGNvbnRhY3QgaGFzIGJvdGgg U0lQIGFuZCBYTVBQIGNhcGFiaWxpdGllcw0KPg0KPkFsdGhvdWdoIHNvbWUgcHJvcHJpZXRhcnkg c29sdXRpb25zIGV4aXN0IHRvIHRoZSBmb3JlZ29pbmcgcHJvYmxlbXMsIGl0DQo+d291bGQgYmUg cHJlZmVyYWJsZSB0byBkZWZpbmUgc3RhbmRhcmRpemVkIHNvbHV0aW9ucyBmb3IgdGhlIHNha2Ug b2YNCj5pbXByb3ZlZCBpbnRlcm9wZXJhYmlsaXR5Lg0KPg0KPk9iamVjdGl2ZXMNCj4NCj5CZWNh dXNlIGJvdGggU0lQIGFuZCBYTVBQIGFyZSBlYXNpbHkgZXh0ZW5kZWQgdGhyb3VnaCBuZXcgU0lQ IGhlYWRlcnMNCj5hbmQgWE1QUCBlbGVtZW50cywgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIHBy b3ZpZGUgdGlnaHRlciBpbnRlZ3JhdGlvbg0KPndpdGhpbiBkdWFsLXN0YWNrIFNJUC9YTVBQIHVz ZXIgYWdlbnRzIHRvIGltcHJvdmUgdGhlIHVzZXIgZXhwZXJpZW5jZS4NCj4NCj5Bbnkgc3VjaCBl eHRlbnNpb25zIHNob3VsZCBtZWV0IHRoZSBmb2xsb3dpbmcgY3JpdGVyaWE6DQo+DQo+LSBCZSBj b21wbGV0ZWx5IG9wdGlvbmFsIGFuZCBiYWNrd2FyZHMtY29tcGF0aWJsZSBmb3IgYWxsIGVuZHBv aW50cw0KPg0KPi0gV29yayB3aXRob3V0IGNoYW5nZXMgdG8gZGVwbG95ZWQgaW5mcmFzdHJ1Y3R1 cmUgc3VjaCBhcyBleGlzdGluZw0KPiAgU0lQIGFuZCBYTVBQIHNlcnZlcnMsIEIyQlVBcywgZmly ZXdhbGxzLCBldGMuDQo+DQo+VGhlIFNJWFBBQyBXRyB3aWxsIGRlZmluZSBhIHNtYWxsIG51bWJl ciBvZiBTSVAgYW5kIFhNUFAgZXh0ZW5zaW9ucyB0bw0KPnNvbHZlIHRoZSBmb2xsb3dpbmcgdXNl IGNhc2VzIGluIGR1YWwtc3RhY2sgZW5kcG9pbnRzOg0KPg0KPi0gSW5jbHVkaW5nIFNJUC1iYXNl ZCBhdmFpbGFiaWxpdHkgc3RhdGVzIGluIFhNUFAgcHJlc2VuY2UgKGxpbWl0ZWQgdG8NCj4gIGJh c2ljIHByZXNlbmNlIGFuZCBhdmFpbGFiaWxpdHkgc3RhdGVzIG9ubHksIG5vdCB0aGUgZnVsbCBy YW5nZSBvZg0KPiAgUElERiBleHRlbnNpb25zKQ0KPg0KPi0gQ29ycmVsYXRpbmcgYW4gWE1QUCBJ TSBzZXNzaW9uIHdpdGggYSBTSVAgdm9pY2UvdmlkZW8gc2Vzc2lvbiwgYW5kDQo+ICB2aWNlLXZl cnNhDQo+DQo+LSBBZHZlcnRpc2luZyBhIFNJUCBhY2NvdW50IGFkZHJlc3Mgb3ZlciBYTVBQIGFu ZCBhbiBYTVBQIGFjY291bnQNCj4gIGFkZHJlc3Mgb3ZlciBTSVANCj4NCj5BZGRpdGlvbmFsIHVz ZSBjYXNlcyBhcmUgb3V0IG9mIHNjb3BlLCBpbmNsdWRpbmcgYW55dGhpbmcgcmVsYXRlZCB0byBv cg0KPnJlcXVpcmluZyBzZXJ2ZXIgaW50ZWdyYXRpb24sIG11bHRpcGFydHkgY29tbXVuaWNhdGlv biwgU0lQLWJhc2VkIElNIGFuZA0KPnByZXNlbmNlLCBYTVBQLWJhc2VkIHZvaWNlIGFuZCB2aWRl bywgZmlsZSB0cmFuc2ZlciwgZ2VuZXJhbGl6ZWQgc2VydmljZQ0KPmRpc2NvdmVyeSBhbmQgY2Fw YWJpbGl0aWVzIGV4Y2hhbmdlLCBmdWxsIHByb3RvY29sIHRyYW5zbGF0aW9uIGluDQo+Y29tbXVu aWNhdGlvbiBnYXRld2F5cywgc2hhcmVkIGNyZWRlbnRpYWxzIGFjcm9zcyBib3RoIFNJUCBhbmQg WE1QUA0KPmFjY291bnRzLCByaWNoIHByZXNlbmNlIGV4dGVuc2lvbnMgZm9yIGZlYXR1cmVzIHN1 Y2ggYXMgZ2VvbG9jYXRpb24sDQo+ZXRjLiBBbHRob3VnaCBzdWNoIHRvcGljcyBhcmUgaW1wb3J0 YW50IGFuZCBpbnRlcmVzdGluZywgdGhleSBhcmUgb3V0IG9mDQo+c2NvcGUgZm9yIHRoaXMgZ3Jv dXAuDQo+DQo+SG93ZXZlciwgaW4gYWRkaXRpb24gdG8gdGhlIHByb3RvY29sIGV4dGVuc2lvbnMg ZXhwbGljaXRseSBtZW50aW9uZWQNCj5hYm92ZSwgdGhlIGdyb3VwIG1heSBhbHNvIGRlZmluZSBi ZXN0IHByYWN0aWNlcyByZWxhdGVkIHRvIHRoZQ0KPmltcGxlbWVudGF0aW9uIGFuZCBkZXBsb3lt ZW50IG9mIGR1YWwtc3RhY2sgU0lQL1hNUFAgZW5kcG9pbnRzLg0KPg0KPkRlbGl2ZXJhYmxlcw0K Pg0KPi0gVXNlIGNhc2VzIGFuZCBwcm90b2NvbCByZXF1aXJlbWVudHMNCj4NCj4tIFhNUFAgcHJl c2VuY2UgZXh0ZW5zaW9uIGZvciBTSVAtYmFzZWQgYXZhaWxhYmlsaXR5IHN0YXRlcw0KPg0KPi0g TWVkaWEgc2Vzc2lvbiBjb3JyZWxhdGlvbiBleHRlbnNpb25zIGZvciBTSVAgYW5kIFhNUFANCj4N Cj4tIENvbnRhY3QgYWRkcmVzcyBhZHZlcnRpc2VtZW50IGV4dGVuc2lvbnMgZm9yIFNJUCBhbmQg WE1QUA0KPg0KPi0gQmVzdCBwcmFjdGljZXMgZm9yIGltcGxlbWVudGF0aW9uIGFuZCBkZXBsb3lt ZW50IG9mIGR1YWwtc3RhY2sNCj4gIGVuZHBvaW50cw0KPg0KPk1pbGVzdG9uZXMNCj4NCj5GZWIg MjAxMSAgU3VibWl0IHVzZSBjYXNlcyBhbmQgcHJvdG9jb2wgcmVxdWlyZW1lbnRzIGRvY3VtZW50 IHRvIElFU0cNCj4oSW5mb3JtYXRpb25hbCkNCj4NCj5PY3QgMjAxMSAgU3VibWl0IFhNUFAgcHJl c2VuY2UgZXh0ZW5zaW9uIGRvY3VtZW50IHRvIElFU0cgKFN0YW5kYXJkcw0KPlRyYWNrKQ0KPg0K Pk9jdCAyMDExICBTdWJtaXQgbWVkaWEgc2Vzc2lvbiBjb3JyZWxhdGlvbiBleHRlbnNpb25zIGRv Y3VtZW50IHRvIElFU0cNCj4oU3RhbmRhcmRzIFRyYWNrKQ0KPg0KPk9jdCAyMDExICBTdWJtaXQg Y29udGFjdCBhZGRyZXNzIGFkdmVydGlzZW1lbnQgZXh0ZW5zaW9uIGRvY3VtZW50IHRvDQo+SUVT RyAoU3RhbmRhcmRzIFRyYWNrKQ0KPg0KPk9jdCAyMDExICBTdWJtaXQgYmVzdCBwcmFjdGljZXMg ZG9jdW1lbnQgdG8gSUVTRyAoSW5mb3JtYXRpb25hbCkNCj4NCg0K From emcho@sip-communicator.org Thu Nov 11 09:22:54 2010 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3483A6A80 for ; Thu, 11 Nov 2010 09:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKdAXxCuYWMT for ; Thu, 11 Nov 2010 09:22:52 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 0AEE03A6A69 for ; Thu, 11 Nov 2010 09:22:48 -0800 (PST) Received: by yxi11 with SMTP id 11so78706yxi.31 for ; Thu, 11 Nov 2010 09:23:19 -0800 (PST) Received: by 10.90.14.39 with SMTP id 39mr1746017agn.23.1289496198897; Thu, 11 Nov 2010 09:23:18 -0800 (PST) Received: from porcinet.local (nsc64.16.130-178.newsouth.net [64.16.130.178]) by mx.google.com with ESMTPS id s36sm1659214yhg.26.2010.11.11.09.23.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 09:23:17 -0800 (PST) Message-ID: <4CDC2683.1000005@sip-communicator.org> Date: Thu, 11 Nov 2010 12:23:15 -0500 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <4CDB9E64.6070704@stpeter.im> <4CDC1E19.7090208@sip-communicator.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sixpac@ietf.org Subject: Re: [sixpac] charter proposal X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 17:22:54 -0000 Hey Markus, =D0=9D=D0=B0 11.11.10 11:54, Markus.Isomaki@nokia.com =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0: > Hi Emil, >=20 > We have discussed about the configuration a couple of times this > week. The problem was that no-one here could anymore explain what we > actually meant by that statement in the charter proposal. Both SIP > and XMPP clients have ways to get their configs automatically. In SIP > there is no widely supported standard for this instead a number of > proprietary solutions are used. > Now we do have the SIP Forum work as > basis, of course. OK, well it seems to me that people are interpreting this as something far scarier that it actually needs to be. We are absolutely _not_ talking about creating a provisioning framework here. This is simply about explaining how to look up the SIP and XMPP server of a sixpac account. I thought we could achieve this by simply stating that sixpac clients should use 3263 and 3920[bis] for the sixpac domain in order to discover the SIP part of the service. We could also advise service maintainers to make sure that clients would be able to authorize users against the SIP and XMPP sever with the same set of credentials, so that it would be safe for clients to actually try this. Of course clients would need to be prepared to also handle the the case where credentials turn out to be different. This is probably all there is to it ... > But when it comes to SIXPAC clients, what it is that we could do > beyond saying that for the SIP config they use whatever is used for > SIP and for XMPP whatever is used for XMPP? It may be problematic but > is it a bigger problem that say configuring two separate SIP and XMPP > clients? The point is that users won't know what SIP is, what XMPP is and why it is that they need to configure two accounts for (what appears to them as) a single service. Email has been crippled by this very problem for years. Of course no one really knows what SMTP, and IMAP, and POP are which is why when configuring your e-mail client you very often get presented with a list of providers to choose from. Of course, while this works to some extent for GMail and Yahoo! it does nothing to address the issue for all the other providers out there. Cheers, Emil >=20 > Markus >=20 >=20 >> -----Original Message----- From: sixpac-bounces@ietf.org >> [mailto:sixpac-bounces@ietf.org] On Behalf Of ext Emil Ivov Sent: >> 11 November, 2010 18:47 To: Peter Saint-Andre Cc: sixpac@ietf.org=20 >> Subject: Re: [sixpac] charter proposal >>=20 >> Hey Peter, >>=20 >> =D0=9D=D0=B0 11.11.10 02:42, Peter Saint-Andre =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0: >>> To kick off discussion, here is the charter as I sent it to the=20 >>> dispath@ietf.org list a while back, with removal of a clause >>> about working on user configuration, which I think is a large >>> rathole. >>=20 >> Well, I thought we had agreed on this and was quite surprised to >> find out that for some unknown reason it was once again _the_ issue >> with the sixpac charter :). >>=20 >> Frankly, I never really understood what people were so worried >> about. What harm could it cause to have a statement that advises >> implementors how to lookup the SIP and XMPP services for a sixpac >> account? >>=20 >> Besides, how else would you make this work in generic clients? >> Should users always manually configure the XMPP server address and >> the SIP proxy address, port and transport? >>=20 >> Cheers, Emil >>>=20 >>> Let's discuss and get busy! >>>=20 >>> /psa >>>=20 >>>=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=3D=3D=3D=3D >> >>=20 =3D >>> SIXPAC (SIP Integration with XMPP in Presence Aware Clients) >>>=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=3D=3D=3D=3D >> >>=20 =3D >>>=20 >>> Problem Statement >>>=20 >>> Both the Session Initiation Protocol (SIP) and the Extensible >> Messaging >>> and Presence Protocol (XMPP) are widely deployed technologies >>> for real-time communication over the Internet. In order to offer >>> a >> complete >>> suite of features as well as communication across multiple >>> networks, several user-oriented software applications support >>> both SIP and XMPP, and more software developers have expressed >>> interest in building such "dual-stack" solutions. Unfortunately, >>> it is difficult to provide a good end-user experience in such >>> applications because SIP and XMPP are not "aware" of each other. >>> For example: >>>=20 >>> - XMPP presence does not include availability states related to a >>> SIP voice call or video call (e.g., "on the phone"), thus >>> preventing an a dual-stack endpoint from showing presence-based >>> communication >> hints >>>=20 >>> - There is no correlation between an XMPP IM session and a SIP >>> voice or video session, thus preventing a dual-stack endpoint >>> from >> providing >>> integrated user interfaces and communications history >>>=20 >>> - SIP accounts and XMPP accounts are not directly correlated in >> contact >>> lists or vCards (and not all deployed services support storage >>> of >> such >>> information), thus preventing a dual-stack endpoint from knowing >> that >>> a contact has both SIP and XMPP capabilities >>>=20 >>> Although some proprietary solutions exist to the foregoing >>> problems, >> it >>> would be preferable to define standardized solutions for the sake >>> of improved interoperability. >>>=20 >>> Objectives >>>=20 >>> Because both SIP and XMPP are easily extended through new SIP >>> headers and XMPP elements, it should be possible to provide >>> tighter >> integration >>> within dual-stack SIP/XMPP user agents to improve the user >>> experience. >>>=20 >>> Any such extensions should meet the following criteria: >>>=20 >>> - Be completely optional and backwards-compatible for all >>> endpoints >>>=20 >>> - Work without changes to deployed infrastructure such as >>> existing SIP and XMPP servers, B2BUAs, firewalls, etc. >>>=20 >>> The SIXPAC WG will define a small number of SIP and XMPP >>> extensions to solve the following use cases in dual-stack >>> endpoints: >>>=20 >>> - Including SIP-based availability states in XMPP presence >>> (limited to basic presence and availability states only, not the >>> full range of PIDF extensions) >>>=20 >>> - Correlating an XMPP IM session with a SIP voice/video session, >>> and vice-versa >>>=20 >>> - Advertising a SIP account address over XMPP and an XMPP >>> account address over SIP >>>=20 >>> Additional use cases are out of scope, including anything related >>> to >> or >>> requiring server integration, multiparty communication, SIP-based >>> IM >> and >>> presence, XMPP-based voice and video, file transfer, generalized >> service >>> discovery and capabilities exchange, full protocol translation >>> in communication gateways, shared credentials across both SIP and >>> XMPP accounts, rich presence extensions for features such as >>> geolocation, etc. Although such topics are important and >>> interesting, they are out >> of >>> scope for this group. >>>=20 >>> However, in addition to the protocol extensions explicitly >>> mentioned above, the group may also define best practices related >>> to the implementation and deployment of dual-stack SIP/XMPP >>> endpoints. >>>=20 >>> Deliverables >>>=20 >>> - Use cases and protocol requirements >>>=20 >>> - XMPP presence extension for SIP-based availability states >>>=20 >>> - Media session correlation extensions for SIP and XMPP >>>=20 >>> - Contact address advertisement extensions for SIP and XMPP >>>=20 >>> - Best practices for implementation and deployment of dual-stack=20 >>> endpoints >>>=20 >>> Milestones >>>=20 >>> Feb 2011 Submit use cases and protocol requirements document to=20 >>> IESG (Informational) >>>=20 >>> Oct 2011 Submit XMPP presence extension document to IESG=20 >>> (Standards Track) >>>=20 >>> Oct 2011 Submit media session correlation extensions document to >>> IESG (Standards Track) >>>=20 >>> Oct 2011 Submit contact address advertisement extension document >>> to IESG (Standards Track) >>>=20 >>> Oct 2011 Submit best practices document to IESG (Informational) >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ sixpac mailing >>> list sixpac@ietf.org=20 >>> https://www.ietf.org/mailman/listinfo/sixpac >>=20 >> -- Emil Ivov, Ph.D. 67000 >> Strasbourg, Project Lead France=20 >> SIP Communicator emcho@sip-communicator.org >> PHONE: +33.1.77.62.43.30 http://sip-communicator.org >> FAX: +33.1.77.62.47.31 >>=20 >> _______________________________________________ sixpac mailing >> list sixpac@ietf.org https://www.ietf.org/mailman/listinfo/sixpac --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France SIP Communicator emcho@sip-communicator.org PHONE: +33.1.77.62.43.30 http://sip-communicator.org FAX: +33.1.77.62.47.31 From rifatyu@avaya.com Thu Nov 11 11:05:47 2010 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CB53A68DA for ; Thu, 11 Nov 2010 11:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1stmHmVrErdb for ; Thu, 11 Nov 2010 11:05:46 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 1DF4A3A67B2 for ; Thu, 11 Nov 2010 11:05:44 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGfN20yHCzI1/2dsb2JhbACDO54vW3GpMwKII5EWAoEggWIIgUtzBIRaiSM X-IronPort-AV: E=Sophos;i="4.59,184,1288584000"; d="scan'208";a="218169457" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Nov 2010 14:06:14 -0500 X-IronPort-AV: E=Sophos;i="4.59,184,1288584000"; d="scan'208";a="536992677" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Nov 2010 14:06:13 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 11 Nov 2010 14:06:12 -0500 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Emil Ivov , "Markus.Isomaki@nokia.com" Date: Thu, 11 Nov 2010 14:06:08 -0500 Thread-Topic: [sixpac] charter proposal Thread-Index: AcuBxSn+BwWCOGQISEa78aYhAaJNHwADBYPw Message-ID: <6369CB70BFD88942B9705AC1E639A3382201D1BB5F@DC-US1MBEX4.global.avaya.com> References: <4CDB9E64.6070704@stpeter.im> <4CDC1E19.7090208@sip-communicator.org> <4CDC2683.1000005@sip-communicator.org> In-Reply-To: <4CDC2683.1000005@sip-communicator.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "sixpac@ietf.org" Subject: Re: [sixpac] charter proposal X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 19:05:47 -0000 SGksDQoNCkkgdG9vIHRoaW5rIHRoYXQgdGhpcyBncm91cCBzaG91bGQgYXZvaWQgZGVhbGluZyB3 aXRoIHRoZSBjb25maWd1cmF0aW9uIGlzc3VlLg0KDQo+IEkgdGhvdWdodCB3ZSBjb3VsZCBhY2hp ZXZlIHRoaXMgYnkgc2ltcGx5IHN0YXRpbmcgdGhhdCBzaXhwYWMgY2xpZW50cw0KPnNob3VsZCB1 c2UgMzI2MyBhbmQgMzkyMFtiaXNdIGZvciB0aGUgc2l4cGFjIGRvbWFpbiBpbiBvcmRlciB0byBk aXNjb3Zlcg0KPnRoZSBTSVAgcGFydCBvZiB0aGUgc2VydmljZS4NCg0KSSBkbyBub3Qgc2VlIGhv dyBzdGF0ZW1lbnRzIGxpa2UgInNob3VsZCB1c2UuLi4iIHdpbGwgaGVscCwgYXMgdGhlc2UgdHlw ZXMgb2Ygc3RhdGVtZW50cyBhcmUgbW9zdCBvZiB0aGUgdGltZSBpZ25vcmVkIGFueXdheS4NCg0K UmVnYXJkcywNCiBSaWZhYXQNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog c2l4cGFjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXhwYWMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEVtaWwgSXZvdg0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDExLCAyMDEw IDEyOjIzIFBNDQpUbzogTWFya3VzLklzb21ha2lAbm9raWEuY29tDQpDYzogc2l4cGFjQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW3NpeHBhY10gY2hhcnRlciBwcm9wb3NhbA0KDQpIZXkgTWFya3Vz LA0KDQrQndCwIDExLjExLjEwIDExOjU0LCBNYXJrdXMuSXNvbWFraUBub2tpYS5jb20g0L3QsNC/ 0LjRgdCwOg0KPiBIaSBFbWlsLA0KPiANCj4gV2UgaGF2ZSBkaXNjdXNzZWQgYWJvdXQgdGhlIGNv bmZpZ3VyYXRpb24gYSBjb3VwbGUgb2YgdGltZXMgdGhpcw0KPiB3ZWVrLiBUaGUgcHJvYmxlbSB3 YXMgdGhhdCBuby1vbmUgaGVyZSBjb3VsZCBhbnltb3JlIGV4cGxhaW4gd2hhdCB3ZQ0KPiBhY3R1 YWxseSBtZWFudCBieSB0aGF0IHN0YXRlbWVudCBpbiB0aGUgY2hhcnRlciBwcm9wb3NhbC4gQm90 aCBTSVANCj4gYW5kIFhNUFAgY2xpZW50cyBoYXZlIHdheXMgdG8gZ2V0IHRoZWlyIGNvbmZpZ3Mg YXV0b21hdGljYWxseS4gSW4gU0lQDQo+IHRoZXJlIGlzIG5vIHdpZGVseSBzdXBwb3J0ZWQgc3Rh bmRhcmQgZm9yIHRoaXMgaW5zdGVhZCBhIG51bWJlciBvZg0KPiBwcm9wcmlldGFyeSBzb2x1dGlv bnMgYXJlIHVzZWQuID4gTm93IHdlIGRvIGhhdmUgdGhlIFNJUCBGb3J1bSB3b3JrIGFzDQo+IGJh c2lzLCBvZiBjb3Vyc2UuDQoNCk9LLCB3ZWxsIGl0IHNlZW1zIHRvIG1lIHRoYXQgcGVvcGxlIGFy ZSBpbnRlcnByZXRpbmcgdGhpcyBhcyBzb21ldGhpbmcNCmZhciBzY2FyaWVyIHRoYXQgaXQgYWN0 dWFsbHkgbmVlZHMgdG8gYmUuIFdlIGFyZSBhYnNvbHV0ZWx5IF9ub3RfDQp0YWxraW5nIGFib3V0 IGNyZWF0aW5nIGEgcHJvdmlzaW9uaW5nIGZyYW1ld29yayBoZXJlLiBUaGlzIGlzIHNpbXBseQ0K YWJvdXQgZXhwbGFpbmluZyBob3cgdG8gbG9vayB1cCB0aGUgU0lQIGFuZCBYTVBQIHNlcnZlciBv ZiBhIHNpeHBhYw0KYWNjb3VudC4NCg0KSSB0aG91Z2h0IHdlIGNvdWxkIGFjaGlldmUgdGhpcyBi eSBzaW1wbHkgc3RhdGluZyB0aGF0IHNpeHBhYyBjbGllbnRzDQpzaG91bGQgdXNlIDMyNjMgYW5k IDM5MjBbYmlzXSBmb3IgdGhlIHNpeHBhYyBkb21haW4gaW4gb3JkZXIgdG8gZGlzY292ZXINCnRo ZSBTSVAgcGFydCBvZiB0aGUgc2VydmljZS4NCg0KV2UgY291bGQgYWxzbyBhZHZpc2Ugc2Vydmlj ZSBtYWludGFpbmVycyB0byBtYWtlIHN1cmUgdGhhdCBjbGllbnRzIHdvdWxkDQpiZSBhYmxlIHRv IGF1dGhvcml6ZSB1c2VycyBhZ2FpbnN0IHRoZSBTSVAgYW5kIFhNUFAgc2V2ZXIgd2l0aCB0aGUg c2FtZQ0Kc2V0IG9mIGNyZWRlbnRpYWxzLCBzbyB0aGF0IGl0IHdvdWxkIGJlIHNhZmUgZm9yIGNs aWVudHMgdG8gYWN0dWFsbHkgdHJ5DQp0aGlzLiBPZiBjb3Vyc2UgY2xpZW50cyB3b3VsZCBuZWVk IHRvIGJlIHByZXBhcmVkIHRvIGFsc28gaGFuZGxlIHRoZSB0aGUNCmNhc2Ugd2hlcmUgY3JlZGVu dGlhbHMgdHVybiBvdXQgdG8gYmUgZGlmZmVyZW50Lg0KDQpUaGlzIGlzIHByb2JhYmx5IGFsbCB0 aGVyZSBpcyB0byBpdCAuLi4NCg0KPiBCdXQgd2hlbiBpdCBjb21lcyB0byBTSVhQQUMgY2xpZW50 cywgd2hhdCBpdCBpcyB0aGF0IHdlIGNvdWxkIGRvDQo+IGJleW9uZCBzYXlpbmcgdGhhdCBmb3Ig dGhlIFNJUCBjb25maWcgdGhleSB1c2Ugd2hhdGV2ZXIgaXMgdXNlZCBmb3INCj4gU0lQIGFuZCBm b3IgWE1QUCB3aGF0ZXZlciBpcyB1c2VkIGZvciBYTVBQPyBJdCBtYXkgYmUgcHJvYmxlbWF0aWMg YnV0DQo+IGlzIGl0IGEgYmlnZ2VyIHByb2JsZW0gdGhhdCBzYXkgY29uZmlndXJpbmcgdHdvIHNl cGFyYXRlIFNJUCBhbmQgWE1QUA0KPiBjbGllbnRzPw0KDQpUaGUgcG9pbnQgaXMgdGhhdCB1c2Vy cyB3b24ndCBrbm93IHdoYXQgU0lQIGlzLCB3aGF0IFhNUFAgaXMgYW5kIHdoeSBpdA0KaXMgdGhh dCB0aGV5IG5lZWQgdG8gY29uZmlndXJlIHR3byBhY2NvdW50cyBmb3IgKHdoYXQgYXBwZWFycyB0 byB0aGVtDQphcykgYSBzaW5nbGUgc2VydmljZS4NCg0KRW1haWwgaGFzIGJlZW4gY3JpcHBsZWQg YnkgdGhpcyB2ZXJ5IHByb2JsZW0gZm9yIHllYXJzLiBPZiBjb3Vyc2Ugbm8gb25lDQpyZWFsbHkg a25vd3Mgd2hhdCBTTVRQLCBhbmQgSU1BUCwgYW5kIFBPUCBhcmUgd2hpY2ggaXMgd2h5IHdoZW4N CmNvbmZpZ3VyaW5nIHlvdXIgZS1tYWlsIGNsaWVudCB5b3UgdmVyeSBvZnRlbiBnZXQgcHJlc2Vu dGVkIHdpdGggYSBsaXN0DQpvZiBwcm92aWRlcnMgdG8gY2hvb3NlIGZyb20uIE9mIGNvdXJzZSwg d2hpbGUgdGhpcyB3b3JrcyB0byBzb21lIGV4dGVudA0KZm9yIEdNYWlsIGFuZCBZYWhvbyEgaXQg ZG9lcyBub3RoaW5nIHRvIGFkZHJlc3MgdGhlIGlzc3VlIGZvciBhbGwgdGhlDQpvdGhlciBwcm92 aWRlcnMgb3V0IHRoZXJlLg0KDQpDaGVlcnMsDQpFbWlsDQo+IA0KPiBNYXJrdXMNCj4gDQo+IA0K Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogc2l4cGFjLWJvdW5jZXNAaWV0Zi5v cmcNCj4+IFttYWlsdG86c2l4cGFjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQg RW1pbCBJdm92IFNlbnQ6DQo+PiAxMSBOb3ZlbWJlciwgMjAxMCAxODo0NyBUbzogUGV0ZXIgU2Fp bnQtQW5kcmUgQ2M6IHNpeHBhY0BpZXRmLm9yZyANCj4+IFN1YmplY3Q6IFJlOiBbc2l4cGFjXSBj aGFydGVyIHByb3Bvc2FsDQo+PiANCj4+IEhleSBQZXRlciwNCj4+IA0KPj4g0J3QsCAxMS4xMS4x MCAwMjo0MiwgUGV0ZXIgU2FpbnQtQW5kcmUg0L3QsNC/0LjRgdCwOg0KPj4+IFRvIGtpY2sgb2Zm IGRpc2N1c3Npb24sIGhlcmUgaXMgdGhlIGNoYXJ0ZXIgYXMgSSBzZW50IGl0IHRvIHRoZSANCj4+ PiBkaXNwYXRoQGlldGYub3JnIGxpc3QgYSB3aGlsZSBiYWNrLCB3aXRoIHJlbW92YWwgb2YgYSBj bGF1c2UNCj4+PiBhYm91dCB3b3JraW5nIG9uIHVzZXIgY29uZmlndXJhdGlvbiwgd2hpY2ggSSB0 aGluayBpcyBhIGxhcmdlDQo+Pj4gcmF0aG9sZS4NCj4+IA0KPj4gV2VsbCwgSSB0aG91Z2h0IHdl IGhhZCBhZ3JlZWQgb24gdGhpcyBhbmQgd2FzIHF1aXRlIHN1cnByaXNlZCB0bw0KPj4gZmluZCBv dXQgdGhhdCBmb3Igc29tZSB1bmtub3duIHJlYXNvbiBpdCB3YXMgb25jZSBhZ2FpbiBfdGhlXyBp c3N1ZQ0KPj4gd2l0aCB0aGUgc2l4cGFjIGNoYXJ0ZXIgOikuDQo+PiANCj4+IEZyYW5rbHksIEkg bmV2ZXIgcmVhbGx5IHVuZGVyc3Rvb2Qgd2hhdCBwZW9wbGUgd2VyZSBzbyB3b3JyaWVkDQo+PiBh Ym91dC4gV2hhdCBoYXJtIGNvdWxkIGl0IGNhdXNlIHRvIGhhdmUgYSBzdGF0ZW1lbnQgdGhhdCBh ZHZpc2VzDQo+PiBpbXBsZW1lbnRvcnMgaG93IHRvIGxvb2t1cCB0aGUgU0lQIGFuZCBYTVBQIHNl cnZpY2VzIGZvciBhIHNpeHBhYw0KPj4gYWNjb3VudD8NCj4+IA0KPj4gQmVzaWRlcywgaG93IGVs c2Ugd291bGQgeW91IG1ha2UgdGhpcyB3b3JrIGluIGdlbmVyaWMgY2xpZW50cz8NCj4+IFNob3Vs ZCB1c2VycyBhbHdheXMgbWFudWFsbHkgY29uZmlndXJlIHRoZSBYTVBQIHNlcnZlciBhZGRyZXNz IGFuZA0KPj4gdGhlIFNJUCBwcm94eSBhZGRyZXNzLCBwb3J0IGFuZCB0cmFuc3BvcnQ/DQo+PiAN Cj4+IENoZWVycywgRW1pbA0KPj4+IA0KPj4+IExldCdzIGRpc2N1c3MgYW5kIGdldCBidXN5IQ0K Pj4+IA0KPj4+IC9wc2ENCj4+PiANCj4+PiANCj4+ID09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPj4NCj4+IA0K PQ0KPj4+IFNJWFBBQyAoU0lQIEludGVncmF0aW9uIHdpdGggWE1QUCBpbiBQcmVzZW5jZSBBd2Fy ZSBDbGllbnRzKQ0KPj4+IA0KPj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+Pg0KPj4gDQo9DQo+Pj4gDQo+ Pj4gUHJvYmxlbSBTdGF0ZW1lbnQNCj4+PiANCj4+PiBCb3RoIHRoZSBTZXNzaW9uIEluaXRpYXRp b24gUHJvdG9jb2wgKFNJUCkgYW5kIHRoZSBFeHRlbnNpYmxlDQo+PiBNZXNzYWdpbmcNCj4+PiBh bmQgUHJlc2VuY2UgUHJvdG9jb2wgKFhNUFApIGFyZSB3aWRlbHkgZGVwbG95ZWQgdGVjaG5vbG9n aWVzDQo+Pj4gZm9yIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uIG92ZXIgdGhlIEludGVybmV0LiAg SW4gb3JkZXIgdG8gb2ZmZXINCj4+PiBhDQo+PiBjb21wbGV0ZQ0KPj4+IHN1aXRlIG9mIGZlYXR1 cmVzIGFzIHdlbGwgYXMgY29tbXVuaWNhdGlvbiBhY3Jvc3MgbXVsdGlwbGUNCj4+PiBuZXR3b3Jr cywgc2V2ZXJhbCB1c2VyLW9yaWVudGVkIHNvZnR3YXJlIGFwcGxpY2F0aW9ucyBzdXBwb3J0DQo+ Pj4gYm90aCBTSVAgYW5kIFhNUFAsIGFuZCBtb3JlIHNvZnR3YXJlIGRldmVsb3BlcnMgaGF2ZSBl eHByZXNzZWQNCj4+PiBpbnRlcmVzdCBpbiBidWlsZGluZyBzdWNoICJkdWFsLXN0YWNrIiBzb2x1 dGlvbnMuICBVbmZvcnR1bmF0ZWx5LA0KPj4+IGl0IGlzIGRpZmZpY3VsdCB0byBwcm92aWRlIGEg Z29vZCBlbmQtdXNlciBleHBlcmllbmNlIGluIHN1Y2gNCj4+PiBhcHBsaWNhdGlvbnMgYmVjYXVz ZSBTSVAgYW5kIFhNUFAgYXJlIG5vdCAiYXdhcmUiIG9mIGVhY2ggb3RoZXIuDQo+Pj4gRm9yIGV4 YW1wbGU6DQo+Pj4gDQo+Pj4gLSBYTVBQIHByZXNlbmNlIGRvZXMgbm90IGluY2x1ZGUgYXZhaWxh YmlsaXR5IHN0YXRlcyByZWxhdGVkIHRvIGENCj4+PiBTSVAgdm9pY2UgY2FsbCBvciB2aWRlbyBj YWxsIChlLmcuLCAib24gdGhlIHBob25lIiksIHRodXMNCj4+PiBwcmV2ZW50aW5nIGFuIGEgZHVh bC1zdGFjayBlbmRwb2ludCBmcm9tIHNob3dpbmcgcHJlc2VuY2UtYmFzZWQNCj4+PiBjb21tdW5p Y2F0aW9uDQo+PiBoaW50cw0KPj4+IA0KPj4+IC0gVGhlcmUgaXMgbm8gY29ycmVsYXRpb24gYmV0 d2VlbiBhbiBYTVBQIElNIHNlc3Npb24gYW5kIGEgU0lQDQo+Pj4gdm9pY2Ugb3IgdmlkZW8gc2Vz c2lvbiwgdGh1cyBwcmV2ZW50aW5nIGEgZHVhbC1zdGFjayBlbmRwb2ludA0KPj4+IGZyb20NCj4+ IHByb3ZpZGluZw0KPj4+IGludGVncmF0ZWQgdXNlciBpbnRlcmZhY2VzIGFuZCBjb21tdW5pY2F0 aW9ucyBoaXN0b3J5DQo+Pj4gDQo+Pj4gLSBTSVAgYWNjb3VudHMgYW5kIFhNUFAgYWNjb3VudHMg YXJlIG5vdCBkaXJlY3RseSBjb3JyZWxhdGVkIGluDQo+PiBjb250YWN0DQo+Pj4gbGlzdHMgb3Ig dkNhcmRzIChhbmQgbm90IGFsbCBkZXBsb3llZCBzZXJ2aWNlcyBzdXBwb3J0IHN0b3JhZ2UNCj4+ PiBvZg0KPj4gc3VjaA0KPj4+IGluZm9ybWF0aW9uKSwgdGh1cyBwcmV2ZW50aW5nIGEgZHVhbC1z dGFjayBlbmRwb2ludCBmcm9tIGtub3dpbmcNCj4+IHRoYXQNCj4+PiBhIGNvbnRhY3QgaGFzIGJv dGggU0lQIGFuZCBYTVBQIGNhcGFiaWxpdGllcw0KPj4+IA0KPj4+IEFsdGhvdWdoIHNvbWUgcHJv cHJpZXRhcnkgc29sdXRpb25zIGV4aXN0IHRvIHRoZSBmb3JlZ29pbmcNCj4+PiBwcm9ibGVtcywN Cj4+IGl0DQo+Pj4gd291bGQgYmUgcHJlZmVyYWJsZSB0byBkZWZpbmUgc3RhbmRhcmRpemVkIHNv bHV0aW9ucyBmb3IgdGhlIHNha2UNCj4+PiBvZiBpbXByb3ZlZCBpbnRlcm9wZXJhYmlsaXR5Lg0K Pj4+IA0KPj4+IE9iamVjdGl2ZXMNCj4+PiANCj4+PiBCZWNhdXNlIGJvdGggU0lQIGFuZCBYTVBQ IGFyZSBlYXNpbHkgZXh0ZW5kZWQgdGhyb3VnaCBuZXcgU0lQDQo+Pj4gaGVhZGVycyBhbmQgWE1Q UCBlbGVtZW50cywgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIHByb3ZpZGUNCj4+PiB0aWdodGVy DQo+PiBpbnRlZ3JhdGlvbg0KPj4+IHdpdGhpbiBkdWFsLXN0YWNrIFNJUC9YTVBQIHVzZXIgYWdl bnRzIHRvIGltcHJvdmUgdGhlIHVzZXINCj4+PiBleHBlcmllbmNlLg0KPj4+IA0KPj4+IEFueSBz dWNoIGV4dGVuc2lvbnMgc2hvdWxkIG1lZXQgdGhlIGZvbGxvd2luZyBjcml0ZXJpYToNCj4+PiAN Cj4+PiAtIEJlIGNvbXBsZXRlbHkgb3B0aW9uYWwgYW5kIGJhY2t3YXJkcy1jb21wYXRpYmxlIGZv ciBhbGwNCj4+PiBlbmRwb2ludHMNCj4+PiANCj4+PiAtIFdvcmsgd2l0aG91dCBjaGFuZ2VzIHRv IGRlcGxveWVkIGluZnJhc3RydWN0dXJlIHN1Y2ggYXMNCj4+PiBleGlzdGluZyBTSVAgYW5kIFhN UFAgc2VydmVycywgQjJCVUFzLCBmaXJld2FsbHMsIGV0Yy4NCj4+PiANCj4+PiBUaGUgU0lYUEFD IFdHIHdpbGwgZGVmaW5lIGEgc21hbGwgbnVtYmVyIG9mIFNJUCBhbmQgWE1QUA0KPj4+IGV4dGVu c2lvbnMgdG8gc29sdmUgdGhlIGZvbGxvd2luZyB1c2UgY2FzZXMgaW4gZHVhbC1zdGFjaw0KPj4+ IGVuZHBvaW50czoNCj4+PiANCj4+PiAtIEluY2x1ZGluZyBTSVAtYmFzZWQgYXZhaWxhYmlsaXR5 IHN0YXRlcyBpbiBYTVBQIHByZXNlbmNlDQo+Pj4gKGxpbWl0ZWQgdG8gYmFzaWMgcHJlc2VuY2Ug YW5kIGF2YWlsYWJpbGl0eSBzdGF0ZXMgb25seSwgbm90IHRoZQ0KPj4+IGZ1bGwgcmFuZ2Ugb2Yg UElERiBleHRlbnNpb25zKQ0KPj4+IA0KPj4+IC0gQ29ycmVsYXRpbmcgYW4gWE1QUCBJTSBzZXNz aW9uIHdpdGggYSBTSVAgdm9pY2UvdmlkZW8gc2Vzc2lvbiwNCj4+PiBhbmQgdmljZS12ZXJzYQ0K Pj4+IA0KPj4+IC0gQWR2ZXJ0aXNpbmcgYSBTSVAgYWNjb3VudCBhZGRyZXNzIG92ZXIgWE1QUCBh bmQgYW4gWE1QUA0KPj4+IGFjY291bnQgYWRkcmVzcyBvdmVyIFNJUA0KPj4+IA0KPj4+IEFkZGl0 aW9uYWwgdXNlIGNhc2VzIGFyZSBvdXQgb2Ygc2NvcGUsIGluY2x1ZGluZyBhbnl0aGluZyByZWxh dGVkDQo+Pj4gdG8NCj4+IG9yDQo+Pj4gcmVxdWlyaW5nIHNlcnZlciBpbnRlZ3JhdGlvbiwgbXVs dGlwYXJ0eSBjb21tdW5pY2F0aW9uLCBTSVAtYmFzZWQNCj4+PiBJTQ0KPj4gYW5kDQo+Pj4gcHJl c2VuY2UsIFhNUFAtYmFzZWQgdm9pY2UgYW5kIHZpZGVvLCBmaWxlIHRyYW5zZmVyLCBnZW5lcmFs aXplZA0KPj4gc2VydmljZQ0KPj4+IGRpc2NvdmVyeSBhbmQgY2FwYWJpbGl0aWVzIGV4Y2hhbmdl LCBmdWxsIHByb3RvY29sIHRyYW5zbGF0aW9uDQo+Pj4gaW4gY29tbXVuaWNhdGlvbiBnYXRld2F5 cywgc2hhcmVkIGNyZWRlbnRpYWxzIGFjcm9zcyBib3RoIFNJUCBhbmQNCj4+PiBYTVBQIGFjY291 bnRzLCByaWNoIHByZXNlbmNlIGV4dGVuc2lvbnMgZm9yIGZlYXR1cmVzIHN1Y2ggYXMNCj4+PiBn ZW9sb2NhdGlvbiwgZXRjLiBBbHRob3VnaCBzdWNoIHRvcGljcyBhcmUgaW1wb3J0YW50IGFuZA0K Pj4+IGludGVyZXN0aW5nLCB0aGV5IGFyZSBvdXQNCj4+IG9mDQo+Pj4gc2NvcGUgZm9yIHRoaXMg Z3JvdXAuDQo+Pj4gDQo+Pj4gSG93ZXZlciwgaW4gYWRkaXRpb24gdG8gdGhlIHByb3RvY29sIGV4 dGVuc2lvbnMgZXhwbGljaXRseQ0KPj4+IG1lbnRpb25lZCBhYm92ZSwgdGhlIGdyb3VwIG1heSBh bHNvIGRlZmluZSBiZXN0IHByYWN0aWNlcyByZWxhdGVkDQo+Pj4gdG8gdGhlIGltcGxlbWVudGF0 aW9uIGFuZCBkZXBsb3ltZW50IG9mIGR1YWwtc3RhY2sgU0lQL1hNUFANCj4+PiBlbmRwb2ludHMu DQo+Pj4gDQo+Pj4gRGVsaXZlcmFibGVzDQo+Pj4gDQo+Pj4gLSBVc2UgY2FzZXMgYW5kIHByb3Rv Y29sIHJlcXVpcmVtZW50cw0KPj4+IA0KPj4+IC0gWE1QUCBwcmVzZW5jZSBleHRlbnNpb24gZm9y IFNJUC1iYXNlZCBhdmFpbGFiaWxpdHkgc3RhdGVzDQo+Pj4gDQo+Pj4gLSBNZWRpYSBzZXNzaW9u IGNvcnJlbGF0aW9uIGV4dGVuc2lvbnMgZm9yIFNJUCBhbmQgWE1QUA0KPj4+IA0KPj4+IC0gQ29u dGFjdCBhZGRyZXNzIGFkdmVydGlzZW1lbnQgZXh0ZW5zaW9ucyBmb3IgU0lQIGFuZCBYTVBQDQo+ Pj4gDQo+Pj4gLSBCZXN0IHByYWN0aWNlcyBmb3IgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1l bnQgb2YgZHVhbC1zdGFjayANCj4+PiBlbmRwb2ludHMNCj4+PiANCj4+PiBNaWxlc3RvbmVzDQo+ Pj4gDQo+Pj4gRmViIDIwMTEgIFN1Ym1pdCB1c2UgY2FzZXMgYW5kIHByb3RvY29sIHJlcXVpcmVt ZW50cyBkb2N1bWVudCB0byANCj4+PiBJRVNHIChJbmZvcm1hdGlvbmFsKQ0KPj4+IA0KPj4+IE9j dCAyMDExICBTdWJtaXQgWE1QUCBwcmVzZW5jZSBleHRlbnNpb24gZG9jdW1lbnQgdG8gSUVTRyAN Cj4+PiAoU3RhbmRhcmRzIFRyYWNrKQ0KPj4+IA0KPj4+IE9jdCAyMDExICBTdWJtaXQgbWVkaWEg c2Vzc2lvbiBjb3JyZWxhdGlvbiBleHRlbnNpb25zIGRvY3VtZW50IHRvDQo+Pj4gSUVTRyAoU3Rh bmRhcmRzIFRyYWNrKQ0KPj4+IA0KPj4+IE9jdCAyMDExICBTdWJtaXQgY29udGFjdCBhZGRyZXNz IGFkdmVydGlzZW1lbnQgZXh0ZW5zaW9uIGRvY3VtZW50DQo+Pj4gdG8gSUVTRyAoU3RhbmRhcmRz IFRyYWNrKQ0KPj4+IA0KPj4+IE9jdCAyMDExICBTdWJtaXQgYmVzdCBwcmFjdGljZXMgZG9jdW1l bnQgdG8gSUVTRyAoSW5mb3JtYXRpb25hbCkNCj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4+PiAN Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzaXhw YWMgbWFpbGluZw0KPj4+IGxpc3Qgc2l4cGFjQGlldGYub3JnIA0KPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2l4cGFjDQo+PiANCj4+IC0tIEVtaWwgSXZvdiwgUGgu RC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNjcwMDANCj4+IFN0cmFzYm91cmcsIFBy b2plY3QgTGVhZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRnJhbmNlIA0KPj4g U0lQIENvbW11bmljYXRvciBlbWNob0BzaXAtY29tbXVuaWNhdG9yLm9yZw0KPj4gUEhPTkU6ICsz My4xLjc3LjYyLjQzLjMwIGh0dHA6Ly9zaXAtY29tbXVuaWNhdG9yLm9yZw0KPj4gRkFYOiAgICsz My4xLjc3LjYyLjQ3LjMxDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fIHNpeHBhYyBtYWlsaW5nDQo+PiBsaXN0IHNpeHBhY0BpZXRmLm9yZyBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpeHBhYw0KDQotLSANCkVtaWwg SXZvdiwgUGguRC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNjcwMDAgU3RyYXNib3Vy ZywNClByb2plY3QgTGVhZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRnJhbmNl DQpTSVAgQ29tbXVuaWNhdG9yDQplbWNob0BzaXAtY29tbXVuaWNhdG9yLm9yZyAgICAgICAgICAg ICAgICAgICAgIFBIT05FOiArMzMuMS43Ny42Mi40My4zMA0KaHR0cDovL3NpcC1jb21tdW5pY2F0 b3Iub3JnICAgICAgICAgICAgICAgICAgICBGQVg6ICAgKzMzLjEuNzcuNjIuNDcuMzENCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpeHBhYyBtYWls aW5nIGxpc3QNCnNpeHBhY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zaXhwYWMNCg== From peter.musgrave@magorcorp.com Thu Nov 11 15:17:42 2010 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274823A635F for ; Thu, 11 Nov 2010 15:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLs2Sdi8QeJ3 for ; Thu, 11 Nov 2010 15:17:40 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 6DB473A63CB for ; Thu, 11 Nov 2010 15:17:40 -0800 (PST) Received: by yxi11 with SMTP id 11so371653yxi.31 for ; Thu, 11 Nov 2010 15:18:11 -0800 (PST) Received: by 10.150.195.6 with SMTP id s6mr2696876ybf.261.1289517490971; Thu, 11 Nov 2010 15:18:10 -0800 (PST) Received: from dhcp-408b.meeting.ietf.org (dhcp-408b.meeting.ietf.org [130.129.64.139]) by mx.google.com with ESMTPS id v8sm398480yba.2.2010.11.11.15.18.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 15:18:10 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=utf-8 From: Peter Musgrave In-Reply-To: <4CDC2683.1000005@sip-communicator.org> Date: Fri, 12 Nov 2010 07:18:03 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3A9C34EB-A3C6-4247-BFFF-BFAB7F6FB978@magorcorp.com> References: <4CDB9E64.6070704@stpeter.im> <4CDC1E19.7090208@sip-communicator.org> <4CDC2683.1000005@sip-communicator.org> To: Emil Ivov X-Mailer: Apple Mail (2.1082) Cc: sixpac@ietf.org Subject: Re: [sixpac] charter proposal X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 23:17:42 -0000 Hi,=20 I agree avoiding configuration is good.=20 The email analogy does not ring true for me. You need to ask about POP, = IMAP etc. because these are different protocols. We do not have that = issue here...both have AORs intended to be globally reachable. (Ok, I'm = not an XMPP wizard - does it get called an AOR?) Regards,=20 Peter Musgrave On 2010-11-12, at 1:23 AM, Emil Ivov wrote: > Hey Markus, >=20 > =D0=9D=D0=B0 11.11.10 11:54, Markus.Isomaki@nokia.com =D0=BD=D0=B0=D0=BF= =D0=B8=D1=81=D0=B0: >> Hi Emil, >>=20 >> We have discussed about the configuration a couple of times this >> week. The problem was that no-one here could anymore explain what we >> actually meant by that statement in the charter proposal. Both SIP >> and XMPP clients have ways to get their configs automatically. In SIP >> there is no widely supported standard for this instead a number of >> proprietary solutions are used. > Now we do have the SIP Forum work = as >> basis, of course. >=20 > OK, well it seems to me that people are interpreting this as something > far scarier that it actually needs to be. We are absolutely _not_ > talking about creating a provisioning framework here. This is simply > about explaining how to look up the SIP and XMPP server of a sixpac > account. >=20 > I thought we could achieve this by simply stating that sixpac clients > should use 3263 and 3920[bis] for the sixpac domain in order to = discover > the SIP part of the service. >=20 > We could also advise service maintainers to make sure that clients = would > be able to authorize users against the SIP and XMPP sever with the = same > set of credentials, so that it would be safe for clients to actually = try > this. Of course clients would need to be prepared to also handle the = the > case where credentials turn out to be different. >=20 > This is probably all there is to it ... >=20 >> But when it comes to SIXPAC clients, what it is that we could do >> beyond saying that for the SIP config they use whatever is used for >> SIP and for XMPP whatever is used for XMPP? It may be problematic but >> is it a bigger problem that say configuring two separate SIP and XMPP >> clients? >=20 > The point is that users won't know what SIP is, what XMPP is and why = it > is that they need to configure two accounts for (what appears to them > as) a single service. >=20 > Email has been crippled by this very problem for years. Of course no = one > really knows what SMTP, and IMAP, and POP are which is why when > configuring your e-mail client you very often get presented with a = list > of providers to choose from. Of course, while this works to some = extent > for GMail and Yahoo! it does nothing to address the issue for all the > other providers out there. >=20 > Cheers, > Emil >>=20 >> Markus >>=20 >>=20 >>> -----Original Message----- From: sixpac-bounces@ietf.org >>> [mailto:sixpac-bounces@ietf.org] On Behalf Of ext Emil Ivov Sent: >>> 11 November, 2010 18:47 To: Peter Saint-Andre Cc: sixpac@ietf.org=20 >>> Subject: Re: [sixpac] charter proposal >>>=20 >>> Hey Peter, >>>=20 >>> =D0=9D=D0=B0 11.11.10 02:42, Peter Saint-Andre =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0: >>>> To kick off discussion, here is the charter as I sent it to the=20 >>>> dispath@ietf.org list a while back, with removal of a clause >>>> about working on user configuration, which I think is a large >>>> rathole. >>>=20 >>> Well, I thought we had agreed on this and was quite surprised to >>> find out that for some unknown reason it was once again _the_ issue >>> with the sixpac charter :). >>>=20 >>> Frankly, I never really understood what people were so worried >>> about. What harm could it cause to have a statement that advises >>> implementors how to lookup the SIP and XMPP services for a sixpac >>> account? >>>=20 >>> Besides, how else would you make this work in generic clients? >>> Should users always manually configure the XMPP server address and >>> the SIP proxy address, port and transport? >>>=20 >>> Cheers, Emil >>>>=20 >>>> Let's discuss and get busy! >>>>=20 >>>> /psa >>>>=20 >>>>=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=3D=3D=3D=3D >>>=20 >>>=20 > =3D >>>> SIXPAC (SIP Integration with XMPP in Presence Aware Clients) >>>>=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=3D=3D=3D=3D >>>=20 >>>=20 > =3D >>>>=20 >>>> Problem Statement >>>>=20 >>>> Both the Session Initiation Protocol (SIP) and the Extensible >>> Messaging >>>> and Presence Protocol (XMPP) are widely deployed technologies >>>> for real-time communication over the Internet. In order to offer >>>> a >>> complete >>>> suite of features as well as communication across multiple >>>> networks, several user-oriented software applications support >>>> both SIP and XMPP, and more software developers have expressed >>>> interest in building such "dual-stack" solutions. Unfortunately, >>>> it is difficult to provide a good end-user experience in such >>>> applications because SIP and XMPP are not "aware" of each other. >>>> For example: >>>>=20 >>>> - XMPP presence does not include availability states related to a >>>> SIP voice call or video call (e.g., "on the phone"), thus >>>> preventing an a dual-stack endpoint from showing presence-based >>>> communication >>> hints >>>>=20 >>>> - There is no correlation between an XMPP IM session and a SIP >>>> voice or video session, thus preventing a dual-stack endpoint >>>> from >>> providing >>>> integrated user interfaces and communications history >>>>=20 >>>> - SIP accounts and XMPP accounts are not directly correlated in >>> contact >>>> lists or vCards (and not all deployed services support storage >>>> of >>> such >>>> information), thus preventing a dual-stack endpoint from knowing >>> that >>>> a contact has both SIP and XMPP capabilities >>>>=20 >>>> Although some proprietary solutions exist to the foregoing >>>> problems, >>> it >>>> would be preferable to define standardized solutions for the sake >>>> of improved interoperability. >>>>=20 >>>> Objectives >>>>=20 >>>> Because both SIP and XMPP are easily extended through new SIP >>>> headers and XMPP elements, it should be possible to provide >>>> tighter >>> integration >>>> within dual-stack SIP/XMPP user agents to improve the user >>>> experience. >>>>=20 >>>> Any such extensions should meet the following criteria: >>>>=20 >>>> - Be completely optional and backwards-compatible for all >>>> endpoints >>>>=20 >>>> - Work without changes to deployed infrastructure such as >>>> existing SIP and XMPP servers, B2BUAs, firewalls, etc. >>>>=20 >>>> The SIXPAC WG will define a small number of SIP and XMPP >>>> extensions to solve the following use cases in dual-stack >>>> endpoints: >>>>=20 >>>> - Including SIP-based availability states in XMPP presence >>>> (limited to basic presence and availability states only, not the >>>> full range of PIDF extensions) >>>>=20 >>>> - Correlating an XMPP IM session with a SIP voice/video session, >>>> and vice-versa >>>>=20 >>>> - Advertising a SIP account address over XMPP and an XMPP >>>> account address over SIP >>>>=20 >>>> Additional use cases are out of scope, including anything related >>>> to >>> or >>>> requiring server integration, multiparty communication, SIP-based >>>> IM >>> and >>>> presence, XMPP-based voice and video, file transfer, generalized >>> service >>>> discovery and capabilities exchange, full protocol translation >>>> in communication gateways, shared credentials across both SIP and >>>> XMPP accounts, rich presence extensions for features such as >>>> geolocation, etc. Although such topics are important and >>>> interesting, they are out >>> of >>>> scope for this group. >>>>=20 >>>> However, in addition to the protocol extensions explicitly >>>> mentioned above, the group may also define best practices related >>>> to the implementation and deployment of dual-stack SIP/XMPP >>>> endpoints. >>>>=20 >>>> Deliverables >>>>=20 >>>> - Use cases and protocol requirements >>>>=20 >>>> - XMPP presence extension for SIP-based availability states >>>>=20 >>>> - Media session correlation extensions for SIP and XMPP >>>>=20 >>>> - Contact address advertisement extensions for SIP and XMPP >>>>=20 >>>> - Best practices for implementation and deployment of dual-stack=20 >>>> endpoints >>>>=20 >>>> Milestones >>>>=20 >>>> Feb 2011 Submit use cases and protocol requirements document to=20 >>>> IESG (Informational) >>>>=20 >>>> Oct 2011 Submit XMPP presence extension document to IESG=20 >>>> (Standards Track) >>>>=20 >>>> Oct 2011 Submit media session correlation extensions document to >>>> IESG (Standards Track) >>>>=20 >>>> Oct 2011 Submit contact address advertisement extension document >>>> to IESG (Standards Track) >>>>=20 >>>> Oct 2011 Submit best practices document to IESG (Informational) >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ sixpac mailing >>>> list sixpac@ietf.org=20 >>>> https://www.ietf.org/mailman/listinfo/sixpac >>>=20 >>> -- Emil Ivov, Ph.D. 67000 >>> Strasbourg, Project Lead France=20 >>> SIP Communicator emcho@sip-communicator.org >>> PHONE: +33.1.77.62.43.30 http://sip-communicator.org >>> FAX: +33.1.77.62.47.31 >>>=20 >>> _______________________________________________ sixpac mailing >>> list sixpac@ietf.org https://www.ietf.org/mailman/listinfo/sixpac >=20 > --=20 > Emil Ivov, Ph.D. 67000 Strasbourg, > Project Lead France > SIP Communicator > emcho@sip-communicator.org PHONE: = +33.1.77.62.43.30 > http://sip-communicator.org FAX: = +33.1.77.62.47.31 >=20 > _______________________________________________ > sixpac mailing list > sixpac@ietf.org > https://www.ietf.org/mailman/listinfo/sixpac From emcho@sip-communicator.org Thu Nov 11 20:55:16 2010 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D043A68A5 for ; Thu, 11 Nov 2010 20:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXS3AAjx8eAJ for ; Thu, 11 Nov 2010 20:55:08 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 917F43A691F for ; Thu, 11 Nov 2010 20:55:07 -0800 (PST) Received: by gxk27 with SMTP id 27so1920102gxk.31 for ; Thu, 11 Nov 2010 20:55:39 -0800 (PST) Received: by 10.91.188.3 with SMTP id q3mr2585864agp.52.1289537737434; Thu, 11 Nov 2010 20:55:37 -0800 (PST) Received: from porcinet.local (nsc64.16.130-178.newsouth.net [64.16.130.178]) by mx.google.com with ESMTPS id w3sm3196876anw.25.2010.11.11.20.55.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 20:55:35 -0800 (PST) Message-ID: <4CDCC8C6.30404@sip-communicator.org> Date: Thu, 11 Nov 2010 23:55:34 -0500 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Peter Musgrave References: <4CDB9E64.6070704@stpeter.im> <4CDC1E19.7090208@sip-communicator.org> <4CDC2683.1000005@sip-communicator.org> <3A9C34EB-A3C6-4247-BFFF-BFAB7F6FB978@magorcorp.com> In-Reply-To: <3A9C34EB-A3C6-4247-BFFF-BFAB7F6FB978@magorcorp.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sixpac@ietf.org Subject: Re: [sixpac] charter proposal X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 04:55:16 -0000 =D0=9D=D0=B0 11.11.10 18:18, Peter Musgrave =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > Hi, >=20 > I agree avoiding configuration is good. Just so that we are clear there is no misunderstanding: we aren't talking about generic client configuration or provisioning. I guess discovery is probably a better term. SIP and XMPP have discovery mechanisms and I simply don't see why SIXPAC shouldn't, especially given that it could entirely reuse the other two. We just need to state that this how things should happen. > The email analogy does not ring true for me. You need to ask about > POP, IMAP etc. because these are different protocols. The analogy was mostly between SMTP and POP or SMTP and IMAP. From a user perspective there is absolutely no good reason to have to configure one protocol for sending and another one for receiving mails since they are only using a single service: e-mail. > We do not have > that issue here...both have AORs intended to be globally reachable. The issue is: user A wants to connect to example.com using SIXPAC. A's user agent needs to know what addresses it should connect to. As a matter of fact it would almost go without saying that the most reasonable way of doing so is to use each protocol's default mechanism. What we are talking about is a mere reminder and possibly a suggestion of using the same credentials. The whole thing is so natural that I am at a complete loss as to why people are so worried about it. Emil > (Ok, I'm not an XMPP wizard - does it get called an AOR?) >=20 > Regards, >=20 > Peter Musgrave >=20 > On 2010-11-12, at 1:23 AM, Emil Ivov wrote: >=20 >> Hey Markus, >>=20 >> =D0=9D=D0=B0 11.11.10 11:54, Markus.Isomaki@nokia.com =D0=BD=D0=B0=D0=BF= =D0=B8=D1=81=D0=B0: >>> Hi Emil, >>>=20 >>> We have discussed about the configuration a couple of times this=20 >>> week. The problem was that no-one here could anymore explain what >>> we actually meant by that statement in the charter proposal. Both >>> SIP and XMPP clients have ways to get their configs >>> automatically. In SIP there is no widely supported standard for >>> this instead a number of proprietary solutions are used. > Now we >>> do have the SIP Forum work as basis, of course. >>=20 >> OK, well it seems to me that people are interpreting this as >> something far scarier that it actually needs to be. We are >> absolutely _not_ talking about creating a provisioning framework >> here. This is simply about explaining how to look up the SIP and >> XMPP server of a sixpac account. >>=20 >> I thought we could achieve this by simply stating that sixpac >> clients should use 3263 and 3920[bis] for the sixpac domain in >> order to discover the SIP part of the service. >>=20 >> We could also advise service maintainers to make sure that clients >> would be able to authorize users against the SIP and XMPP sever >> with the same set of credentials, so that it would be safe for >> clients to actually try this. Of course clients would need to be >> prepared to also handle the the case where credentials turn out to >> be different. >>=20 >> This is probably all there is to it ... >>=20 >>> But when it comes to SIXPAC clients, what it is that we could do=20 >>> beyond saying that for the SIP config they use whatever is used >>> for SIP and for XMPP whatever is used for XMPP? It may be >>> problematic but is it a bigger problem that say configuring two >>> separate SIP and XMPP clients? >>=20 >> The point is that users won't know what SIP is, what XMPP is and >> why it is that they need to configure two accounts for (what >> appears to them as) a single service. >>=20 >> Email has been crippled by this very problem for years. Of course >> no one really knows what SMTP, and IMAP, and POP are which is why >> when configuring your e-mail client you very often get presented >> with a list of providers to choose from. Of course, while this >> works to some extent for GMail and Yahoo! it does nothing to >> address the issue for all the other providers out there. >>=20 >> Cheers, Emil >>>=20 >>> Markus >>>=20 >>>=20 >>>> -----Original Message----- From: sixpac-bounces@ietf.org=20 >>>> [mailto:sixpac-bounces@ietf.org] On Behalf Of ext Emil Ivov >>>> Sent: 11 November, 2010 18:47 To: Peter Saint-Andre Cc: >>>> sixpac@ietf.org Subject: Re: [sixpac] charter proposal >>>>=20 >>>> Hey Peter, >>>>=20 >>>> =D0=9D=D0=B0 11.11.10 02:42, Peter Saint-Andre =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0: >>>>> To kick off discussion, here is the charter as I sent it to >>>>> the dispath@ietf.org list a while back, with removal of a >>>>> clause about working on user configuration, which I think is >>>>> a large rathole. >>>>=20 >>>> Well, I thought we had agreed on this and was quite surprised >>>> to find out that for some unknown reason it was once again >>>> _the_ issue with the sixpac charter :). >>>>=20 >>>> Frankly, I never really understood what people were so worried=20 >>>> about. What harm could it cause to have a statement that >>>> advises implementors how to lookup the SIP and XMPP services >>>> for a sixpac account? >>>>=20 >>>> Besides, how else would you make this work in generic clients?=20 >>>> Should users always manually configure the XMPP server address >>>> and the SIP proxy address, port and transport? >>>>=20 >>>> Cheers, Emil >>>>>=20 >>>>> Let's discuss and get busy! >>>>>=20 >>>>> /psa >>>>>=20 >>>>>=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=3D=3D=3D=3D >>>> >>>> >> >>>>=20 =3D >>>>> SIXPAC (SIP Integration with XMPP in Presence Aware Clients) >>>>>=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=3D=3D=3D=3D >>>> >>>> >> >>>>=20 =3D >>>>>=20 >>>>> Problem Statement >>>>>=20 >>>>> Both the Session Initiation Protocol (SIP) and the >>>>> Extensible >>>> Messaging >>>>> and Presence Protocol (XMPP) are widely deployed >>>>> technologies for real-time communication over the Internet. >>>>> In order to offer a >>>> complete >>>>> suite of features as well as communication across multiple=20 >>>>> networks, several user-oriented software applications >>>>> support both SIP and XMPP, and more software developers have >>>>> expressed interest in building such "dual-stack" solutions. >>>>> Unfortunately, it is difficult to provide a good end-user >>>>> experience in such applications because SIP and XMPP are not >>>>> "aware" of each other. For example: >>>>>=20 >>>>> - XMPP presence does not include availability states related >>>>> to a SIP voice call or video call (e.g., "on the phone"), >>>>> thus preventing an a dual-stack endpoint from showing >>>>> presence-based communication >>>> hints >>>>>=20 >>>>> - There is no correlation between an XMPP IM session and a >>>>> SIP voice or video session, thus preventing a dual-stack >>>>> endpoint from >>>> providing >>>>> integrated user interfaces and communications history >>>>>=20 >>>>> - SIP accounts and XMPP accounts are not directly correlated >>>>> in >>>> contact >>>>> lists or vCards (and not all deployed services support >>>>> storage of >>>> such >>>>> information), thus preventing a dual-stack endpoint from >>>>> knowing >>>> that >>>>> a contact has both SIP and XMPP capabilities >>>>>=20 >>>>> Although some proprietary solutions exist to the foregoing=20 >>>>> problems, >>>> it >>>>> would be preferable to define standardized solutions for the >>>>> sake of improved interoperability. >>>>>=20 >>>>> Objectives >>>>>=20 >>>>> Because both SIP and XMPP are easily extended through new >>>>> SIP headers and XMPP elements, it should be possible to >>>>> provide tighter >>>> integration >>>>> within dual-stack SIP/XMPP user agents to improve the user=20 >>>>> experience. >>>>>=20 >>>>> Any such extensions should meet the following criteria: >>>>>=20 >>>>> - Be completely optional and backwards-compatible for all=20 >>>>> endpoints >>>>>=20 >>>>> - Work without changes to deployed infrastructure such as=20 >>>>> existing SIP and XMPP servers, B2BUAs, firewalls, etc. >>>>>=20 >>>>> The SIXPAC WG will define a small number of SIP and XMPP=20 >>>>> extensions to solve the following use cases in dual-stack=20 >>>>> endpoints: >>>>>=20 >>>>> - Including SIP-based availability states in XMPP presence=20 >>>>> (limited to basic presence and availability states only, not >>>>> the full range of PIDF extensions) >>>>>=20 >>>>> - Correlating an XMPP IM session with a SIP voice/video >>>>> session, and vice-versa >>>>>=20 >>>>> - Advertising a SIP account address over XMPP and an XMPP=20 >>>>> account address over SIP >>>>>=20 >>>>> Additional use cases are out of scope, including anything >>>>> related to >>>> or >>>>> requiring server integration, multiparty communication, >>>>> SIP-based IM >>>> and >>>>> presence, XMPP-based voice and video, file transfer, >>>>> generalized >>>> service >>>>> discovery and capabilities exchange, full protocol >>>>> translation in communication gateways, shared credentials >>>>> across both SIP and XMPP accounts, rich presence extensions >>>>> for features such as geolocation, etc. Although such topics >>>>> are important and interesting, they are out >>>> of >>>>> scope for this group. >>>>>=20 >>>>> However, in addition to the protocol extensions explicitly=20 >>>>> mentioned above, the group may also define best practices >>>>> related to the implementation and deployment of dual-stack >>>>> SIP/XMPP endpoints. >>>>>=20 >>>>> Deliverables >>>>>=20 >>>>> - Use cases and protocol requirements >>>>>=20 >>>>> - XMPP presence extension for SIP-based availability states >>>>>=20 >>>>> - Media session correlation extensions for SIP and XMPP >>>>>=20 >>>>> - Contact address advertisement extensions for SIP and XMPP >>>>>=20 >>>>> - Best practices for implementation and deployment of >>>>> dual-stack endpoints >>>>>=20 >>>>> Milestones >>>>>=20 >>>>> Feb 2011 Submit use cases and protocol requirements document >>>>> to IESG (Informational) >>>>>=20 >>>>> Oct 2011 Submit XMPP presence extension document to IESG=20 >>>>> (Standards Track) >>>>>=20 >>>>> Oct 2011 Submit media session correlation extensions >>>>> document to IESG (Standards Track) >>>>>=20 >>>>> Oct 2011 Submit contact address advertisement extension >>>>> document to IESG (Standards Track) >>>>>=20 >>>>> Oct 2011 Submit best practices document to IESG >>>>> (Informational) >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ sixpac >>>>> mailing list sixpac@ietf.org=20 >>>>> https://www.ietf.org/mailman/listinfo/sixpac >>>>=20 >>>> -- Emil Ivov, Ph.D. 67000=20 >>>> Strasbourg, Project Lead >>>> France SIP Communicator emcho@sip-communicator.org PHONE: >>>> +33.1.77.62.43.30 http://sip-communicator.org FAX: >>>> +33.1.77.62.47.31 From eckelcu@cisco.com Fri Nov 12 01:14:52 2010 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D1428C129 for ; Fri, 12 Nov 2010 01:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqWCD80BJqeN for ; Fri, 12 Nov 2010 01:14:51 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D44C628C124 for ; Fri, 12 Nov 2010 01:14:51 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOuT3EyrR7Ht/2dsb2JhbACDPJ44WnGiaYozkHSBIoFiCIFLcwSEWokP X-IronPort-AV: E=Sophos;i="4.59,186,1288569600"; d="scan'208";a="285058301" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 12 Nov 2010 09:15:24 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAC9FOL3018187; Fri, 12 Nov 2010 09:15:24 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Nov 2010 01:15:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 12 Nov 2010 01:15:21 -0800 Message-ID: In-Reply-To: <4CDB9E64.6070704@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sixpac] charter proposal Thread-Index: AcuBdA1sFECsEJybS0aIkyBki4pc5QA1N8HQ References: <4CDB9E64.6070704@stpeter.im> From: "Charles Eckel (eckelcu)" To: "Peter Saint-Andre" , X-OriginalArrivalTime: 12 Nov 2010 09:15:23.0764 (UTC) FILETIME=[23101B40:01CB824A] Subject: Re: [sixpac] charter proposal X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 09:14:52 -0000 UGxlYXNlIHNlZSBzb21lIG1pbm9yIGNvbW1lbnRzIG9uIHRoZSBjaGFydGVyIGlubGluZS4NCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaXhwYWMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnNpeHBhYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGV0ZXIg U2FpbnQtQW5kcmUNCj4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDExLCAyMDEwIDM6NDIgUE0N Cj4gVG86IHNpeHBhY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbc2l4cGFjXSBjaGFydGVyIHByb3Bv c2FsDQo+IA0KPiBUbyBraWNrIG9mZiBkaXNjdXNzaW9uLCBoZXJlIGlzIHRoZSBjaGFydGVyIGFz IEkgc2VudCBpdCB0byB0aGUNCj4gZGlzcGF0aEBpZXRmLm9yZyBsaXN0IGEgd2hpbGUgYmFjaywg d2l0aCByZW1vdmFsIG9mIGEgY2xhdXNlIGFib3V0DQo+IHdvcmtpbmcgb24gdXNlciBjb25maWd1 cmF0aW9uLCB3aGljaCBJIHRoaW5rIGlzIGEgbGFyZ2UgcmF0aG9sZS4NCj4gDQo+IExldCdzIGRp c2N1c3MgYW5kIGdldCBidXN5IQ0KPiANCj4gL3BzYQ0KPiANCj4gPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K PiBTSVhQQUMgKFNJUCBJbnRlZ3JhdGlvbiB3aXRoIFhNUFAgaW4gUHJlc2VuY2UgQXdhcmUgQ2xp ZW50cykNCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiANCj4gUHJvYmxlbSBTdGF0ZW1lbnQNCj4gDQo+ IEJvdGggdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBhbmQgdGhlIEV4dGVu c2libGUgTWVzc2FnaW5nDQo+IGFuZCBQcmVzZW5jZSBQcm90b2NvbCAoWE1QUCkgYXJlIHdpZGVs eSBkZXBsb3llZCB0ZWNobm9sb2dpZXMgZm9yDQo+IHJlYWwtdGltZSBjb21tdW5pY2F0aW9uIG92 ZXIgdGhlIEludGVybmV0LiAgSW4gb3JkZXIgdG8gb2ZmZXIgYSBjb21wbGV0ZQ0KPiBzdWl0ZSBv ZiBmZWF0dXJlcyBhcyB3ZWxsIGFzIGNvbW11bmljYXRpb24gYWNyb3NzIG11bHRpcGxlIG5ldHdv cmtzLA0KPiBzZXZlcmFsIHVzZXItb3JpZW50ZWQgc29mdHdhcmUgYXBwbGljYXRpb25zIHN1cHBv cnQgYm90aCBTSVAgYW5kIFhNUFAsDQo+IGFuZCBtb3JlIHNvZnR3YXJlIGRldmVsb3BlcnMgaGF2 ZSBleHByZXNzZWQgaW50ZXJlc3QgaW4gYnVpbGRpbmcgc3VjaA0KPiAiZHVhbC1zdGFjayIgc29s dXRpb25zLiAgVW5mb3J0dW5hdGVseSwgaXQgaXMgZGlmZmljdWx0IHRvIHByb3ZpZGUgYQ0KPiBn b29kIGVuZC11c2VyIGV4cGVyaWVuY2UgaW4gc3VjaCBhcHBsaWNhdGlvbnMgYmVjYXVzZSBTSVAg YW5kIFhNUFAgYXJlDQo+IG5vdCAiYXdhcmUiIG9mIGVhY2ggb3RoZXIuICBGb3IgZXhhbXBsZToN Cj4gDQo+IC0gWE1QUCBwcmVzZW5jZSBkb2VzIG5vdCBpbmNsdWRlIGF2YWlsYWJpbGl0eSBzdGF0 ZXMgcmVsYXRlZCB0byBhIFNJUA0KPiAgIHZvaWNlIGNhbGwgb3IgdmlkZW8gY2FsbCAoZS5nLiwg Im9uIHRoZSBwaG9uZSIpLCB0aHVzIHByZXZlbnRpbmcgYW4NCj4gICBhIGR1YWwtc3RhY2sgZW5k cG9pbnQgZnJvbSBzaG93aW5nIHByZXNlbmNlLWJhc2VkIGNvbW11bmljYXRpb24gaGludHMNCj4g DQo+IC0gVGhlcmUgaXMgbm8gY29ycmVsYXRpb24gYmV0d2VlbiBhbiBYTVBQIElNIHNlc3Npb24g YW5kIGEgU0lQIHZvaWNlDQo+ICAgb3IgdmlkZW8gc2Vzc2lvbiwgdGh1cyBwcmV2ZW50aW5nIGEg ZHVhbC1zdGFjayBlbmRwb2ludCBmcm9tIHByb3ZpZGluZw0KPiAgIGludGVncmF0ZWQgdXNlciBp bnRlcmZhY2VzIGFuZCBjb21tdW5pY2F0aW9ucyBoaXN0b3J5DQo+IA0KPiAtIFNJUCBhY2NvdW50 cyBhbmQgWE1QUCBhY2NvdW50cyBhcmUgbm90IGRpcmVjdGx5IGNvcnJlbGF0ZWQgaW4gY29udGFj dA0KPiAgIGxpc3RzIG9yIHZDYXJkcyAoYW5kIG5vdCBhbGwgZGVwbG95ZWQgc2VydmljZXMgc3Vw cG9ydCBzdG9yYWdlIG9mIHN1Y2gNCj4gICBpbmZvcm1hdGlvbiksIHRodXMgcHJldmVudGluZyBh IGR1YWwtc3RhY2sgZW5kcG9pbnQgZnJvbSBrbm93aW5nIHRoYXQNCj4gICBhIGNvbnRhY3QgaGFz IGJvdGggU0lQIGFuZCBYTVBQIGNhcGFiaWxpdGllcw0KPiANCj4gQWx0aG91Z2ggc29tZSBwcm9w cmlldGFyeSBzb2x1dGlvbnMgZXhpc3QgdG8gdGhlIGZvcmVnb2luZyBwcm9ibGVtcywgaXQNCj4g d291bGQgYmUgcHJlZmVyYWJsZSB0byBkZWZpbmUgc3RhbmRhcmRpemVkIHNvbHV0aW9ucyBmb3Ig dGhlIHNha2Ugb2YNCj4gaW1wcm92ZWQgaW50ZXJvcGVyYWJpbGl0eS4NCj4gDQo+IE9iamVjdGl2 ZXMNCj4gDQo+IEJlY2F1c2UgYm90aCBTSVAgYW5kIFhNUFAgYXJlIGVhc2lseSBleHRlbmRlZCB0 aHJvdWdoIG5ldyBTSVAgaGVhZGVycw0KPiBhbmQgWE1QUCBlbGVtZW50cywgaXQgc2hvdWxkIGJl IHBvc3NpYmxlIHRvIHByb3ZpZGUgdGlnaHRlciBpbnRlZ3JhdGlvbg0KPiB3aXRoaW4gZHVhbC1z dGFjayBTSVAvWE1QUCB1c2VyIGFnZW50cyB0byBpbXByb3ZlIHRoZSB1c2VyIGV4cGVyaWVuY2Uu DQo+IA0KPiBBbnkgc3VjaCBleHRlbnNpb25zIHNob3VsZCBtZWV0IHRoZSBmb2xsb3dpbmcgY3Jp dGVyaWE6DQo+IA0KPiAtIEJlIGNvbXBsZXRlbHkgb3B0aW9uYWwgYW5kIGJhY2t3YXJkcy1jb21w YXRpYmxlIGZvciBhbGwgZW5kcG9pbnRzDQoNClRoaXMgaXMgbm90IHJlYWxpc3RpYyBhbmQgSSBk b3VidCBpdCBpcyB3aGF0IHdhcyB0cnVseSBtZWFudC4gSSB0aGluayBiZWluZyBiYWNrd2FyZC1j b21wYXRpYmxlIHdpdGggYWxsIGFwcGxpY2FibGUgU0lQIGFuZCBYTVBQIHNwZWNpZmljYXRpb25z IG9yIFJGQ3MgaXMgbW9yZSBhY2N1cmF0ZS4NCg0KPiAtIFdvcmsgd2l0aG91dCBjaGFuZ2VzIHRv IGRlcGxveWVkIGluZnJhc3RydWN0dXJlIHN1Y2ggYXMgZXhpc3RpbmcNCj4gICBTSVAgYW5kIFhN UFAgc2VydmVycywgQjJCVUFzLCBmaXJld2FsbHMsIGV0Yy4NCg0KSGVyZSBhcyB3ZWxsLCBpdCBt YXkgd29ydGggZXhwYW5kaW5nIHRvICJkZXBsb3llZCAsIHN0YW5kYXJkcyBjb21wbGlhbnQsIGlu ZnJhc3RydWN0dXJlIC4uLiINCg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQoNCj4gVGhlIFNJWFBBQyBX RyB3aWxsIGRlZmluZSBhIHNtYWxsIG51bWJlciBvZiBTSVAgYW5kIFhNUFAgZXh0ZW5zaW9ucyB0 bw0KPiBzb2x2ZSB0aGUgZm9sbG93aW5nIHVzZSBjYXNlcyBpbiBkdWFsLXN0YWNrIGVuZHBvaW50 czoNCj4gDQo+IC0gSW5jbHVkaW5nIFNJUC1iYXNlZCBhdmFpbGFiaWxpdHkgc3RhdGVzIGluIFhN UFAgcHJlc2VuY2UgKGxpbWl0ZWQgdG8NCj4gICBiYXNpYyBwcmVzZW5jZSBhbmQgYXZhaWxhYmls aXR5IHN0YXRlcyBvbmx5LCBub3QgdGhlIGZ1bGwgcmFuZ2Ugb2YNCj4gICBQSURGIGV4dGVuc2lv bnMpDQo+IA0KPiAtIENvcnJlbGF0aW5nIGFuIFhNUFAgSU0gc2Vzc2lvbiB3aXRoIGEgU0lQIHZv aWNlL3ZpZGVvIHNlc3Npb24sIGFuZA0KPiAgIHZpY2UtdmVyc2ENCj4gDQo+IC0gQWR2ZXJ0aXNp bmcgYSBTSVAgYWNjb3VudCBhZGRyZXNzIG92ZXIgWE1QUCBhbmQgYW4gWE1QUCBhY2NvdW50DQo+ ICAgYWRkcmVzcyBvdmVyIFNJUA0KPiANCj4gQWRkaXRpb25hbCB1c2UgY2FzZXMgYXJlIG91dCBv ZiBzY29wZSwgaW5jbHVkaW5nIGFueXRoaW5nIHJlbGF0ZWQgdG8gb3INCj4gcmVxdWlyaW5nIHNl cnZlciBpbnRlZ3JhdGlvbiwgbXVsdGlwYXJ0eSBjb21tdW5pY2F0aW9uLCBTSVAtYmFzZWQgSU0g YW5kDQo+IHByZXNlbmNlLCBYTVBQLWJhc2VkIHZvaWNlIGFuZCB2aWRlbywgZmlsZSB0cmFuc2Zl ciwgZ2VuZXJhbGl6ZWQgc2VydmljZQ0KPiBkaXNjb3ZlcnkgYW5kIGNhcGFiaWxpdGllcyBleGNo YW5nZSwgZnVsbCBwcm90b2NvbCB0cmFuc2xhdGlvbiBpbg0KPiBjb21tdW5pY2F0aW9uIGdhdGV3 YXlzLCBzaGFyZWQgY3JlZGVudGlhbHMgYWNyb3NzIGJvdGggU0lQIGFuZCBYTVBQDQo+IGFjY291 bnRzLCByaWNoIHByZXNlbmNlIGV4dGVuc2lvbnMgZm9yIGZlYXR1cmVzIHN1Y2ggYXMgZ2VvbG9j YXRpb24sDQo+IGV0Yy4gQWx0aG91Z2ggc3VjaCB0b3BpY3MgYXJlIGltcG9ydGFudCBhbmQgaW50 ZXJlc3RpbmcsIHRoZXkgYXJlIG91dCBvZg0KPiBzY29wZSBmb3IgdGhpcyBncm91cC4NCj4gDQo+ IEhvd2V2ZXIsIGluIGFkZGl0aW9uIHRvIHRoZSBwcm90b2NvbCBleHRlbnNpb25zIGV4cGxpY2l0 bHkgbWVudGlvbmVkDQo+IGFib3ZlLCB0aGUgZ3JvdXAgbWF5IGFsc28gZGVmaW5lIGJlc3QgcHJh Y3RpY2VzIHJlbGF0ZWQgdG8gdGhlDQo+IGltcGxlbWVudGF0aW9uIGFuZCBkZXBsb3ltZW50IG9m IGR1YWwtc3RhY2sgU0lQL1hNUFAgZW5kcG9pbnRzLg0KPiANCj4gRGVsaXZlcmFibGVzDQo+IA0K PiAtIFVzZSBjYXNlcyBhbmQgcHJvdG9jb2wgcmVxdWlyZW1lbnRzDQo+IA0KPiAtIFhNUFAgcHJl c2VuY2UgZXh0ZW5zaW9uIGZvciBTSVAtYmFzZWQgYXZhaWxhYmlsaXR5IHN0YXRlcw0KPiANCj4g LSBNZWRpYSBzZXNzaW9uIGNvcnJlbGF0aW9uIGV4dGVuc2lvbnMgZm9yIFNJUCBhbmQgWE1QUA0K PiANCj4gLSBDb250YWN0IGFkZHJlc3MgYWR2ZXJ0aXNlbWVudCBleHRlbnNpb25zIGZvciBTSVAg YW5kIFhNUFANCj4gDQo+IC0gQmVzdCBwcmFjdGljZXMgZm9yIGltcGxlbWVudGF0aW9uIGFuZCBk ZXBsb3ltZW50IG9mIGR1YWwtc3RhY2sNCj4gICBlbmRwb2ludHMNCj4gDQo+IE1pbGVzdG9uZXMN Cj4gDQo+IEZlYiAyMDExICBTdWJtaXQgdXNlIGNhc2VzIGFuZCBwcm90b2NvbCByZXF1aXJlbWVu dHMgZG9jdW1lbnQgdG8NCj4gSUVTRyAoSW5mb3JtYXRpb25hbCkNCj4gDQo+IE9jdCAyMDExICBT dWJtaXQgWE1QUCBwcmVzZW5jZSBleHRlbnNpb24gZG9jdW1lbnQgdG8gSUVTRw0KPiAoU3RhbmRh cmRzIFRyYWNrKQ0KPiANCj4gT2N0IDIwMTEgIFN1Ym1pdCBtZWRpYSBzZXNzaW9uIGNvcnJlbGF0 aW9uIGV4dGVuc2lvbnMgZG9jdW1lbnQgdG8gSUVTRw0KPiAoU3RhbmRhcmRzIFRyYWNrKQ0KPiAN Cj4gT2N0IDIwMTEgIFN1Ym1pdCBjb250YWN0IGFkZHJlc3MgYWR2ZXJ0aXNlbWVudCBleHRlbnNp b24gZG9jdW1lbnQgdG8NCj4gSUVTRyAoU3RhbmRhcmRzIFRyYWNrKQ0KPiANCj4gT2N0IDIwMTEg IFN1Ym1pdCBiZXN0IHByYWN0aWNlcyBkb2N1bWVudCB0byBJRVNHIChJbmZvcm1hdGlvbmFsKQ0K DQogDQoNCg== From wwwrun@core3.amsl.com Wed Nov 17 14:25:20 2010 Return-Path: X-Original-To: sixpac@ietf.org Delivered-To: sixpac@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id C56A83A67FC; Wed, 17 Nov 2010 14:25:20 -0800 (PST) From: IETF Secretariat To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20101117222520.C56A83A67FC@core3.amsl.com> Date: Wed, 17 Nov 2010 14:25:20 -0800 (PST) Cc: sixpac@ietf.org Subject: [sixpac] New Non-WG Mailing List: sixpac -- SIP Interworking with XMPP in Presence Aware Clients X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 22:25:21 -0000 A new IETF non-working group email list has been created. List address: sixpac@ietf.org Archive: http://www.ietf.org/mail-archive/web/sixpac/ To subscribe: https://www.ietf.org/mailman/listinfo/sixpac Description: The SIXPAC (SIP Interworking with XMPP in Presence Aware Clients) list is dedicated to discussion of dual-stack SIP/XMPP user agents. For additional information, please contact the list administrators. From peter.musgrave@magorcorp.com Wed Nov 17 21:00:24 2010 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51E33A67AE for ; Wed, 17 Nov 2010 21:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-79Fa3vZ2bH for ; Wed, 17 Nov 2010 21:00:24 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id E96AE3A66B4 for ; Wed, 17 Nov 2010 21:00:20 -0800 (PST) Received: by yxd39 with SMTP id 39so1761184yxd.31 for ; Wed, 17 Nov 2010 21:01:07 -0800 (PST) Received: by 10.150.203.1 with SMTP id a1mr315726ybg.94.1290056467232; Wed, 17 Nov 2010 21:01:07 -0800 (PST) Received: from [172.22.12.84] ([220.229.255.7]) by mx.google.com with ESMTPS id w5sm28815ybe.10.2010.11.17.21.01.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Nov 2010 21:01:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: Date: Thu, 18 Nov 2010 13:01:02 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3B319CDD-C6D5-4CCC-B177-1D63C9996D96@magorcorp.com> References: To: X-Mailer: Apple Mail (2.1082) Cc: sixpac@ietf.org Subject: Re: [sixpac] Drafts on SIP-XMPP combined use X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 05:00:24 -0000 Hi Simo,=20 A question about REQ-1:=20 When it says "SIP Contact" information - does this mean literally the = value in the SIP Contact: header?=20 I think it might need to be the AOR - since that is required to be a = FQDN and publicly reachable, whereas a contact header value might not = be. However, in the case where the AOR has multiple contacts registered, = would we require GRUU to specify which one is to be called? Is the requirement that the information provided allow for the specific = UA instance to be contacted when this identity information is conveyed = over XMPP? REQ-3: Can you elaborate on "real time media contact and status" ? I am = not sure what the requirement is asking for. An indication that an audio = or video session simply exists - or details down to the port, CODEC etc. = ??? Regards,=20 Peter Musgrave On 2010-11-11, at 4:05 PM, = wrote: > Thanks Peter for setting up this list! >=20 > Just as a reminder, the relevant I-D for this work is=20 > http://tools.ietf.org/html/draft-veikkolainen-sip-xmpp-coex-reqs-01 >=20 > We had an earlier draft containing also the protocol extensions, but = that one has been expired. However, you can find it at=20 > http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im >=20 > For our first target, I think we should concentrate on getting a set = of requirements which is agreeable for all. >=20 > Regards, > Simo >=20 > _______________________________________________ > sixpac mailing list > sixpac@ietf.org > https://www.ietf.org/mailman/listinfo/sixpac From Simo.Veikkolainen@nokia.com Fri Nov 19 00:26:13 2010 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC0C28B23E for ; Fri, 19 Nov 2010 00:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.799 X-Spam-Level: X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fB16-2US3sDt for ; Fri, 19 Nov 2010 00:26:12 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 14D6D28C0CF for ; Fri, 19 Nov 2010 00:26:11 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id oAJ8QM7k008210; Fri, 19 Nov 2010 02:26:59 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Nov 2010 10:26:46 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Nov 2010 10:26:45 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 19 Nov 2010 09:26:45 +0100 From: To: Date: Fri, 19 Nov 2010 09:26:43 +0100 Thread-Topic: [sixpac] Drafts on SIP-XMPP combined use Thread-Index: AcuG3aOzIyTdD8OLRR2FQvMYctmufgA5PW7g Message-ID: References: <3B319CDD-C6D5-4CCC-B177-1D63C9996D96@magorcorp.com> In-Reply-To: <3B319CDD-C6D5-4CCC-B177-1D63C9996D96@magorcorp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Nov 2010 08:26:45.0908 (UTC) FILETIME=[80C6DD40:01CB87C3] X-Nokia-AV: Clean Cc: sixpac@ietf.org Subject: Re: [sixpac] Drafts on SIP-XMPP combined use X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 08:26:13 -0000 >-----Original Message----- >From: ext Peter Musgrave [mailto:peter.musgrave@magorcorp.com] >Sent: 18 November, 2010 07:01 >To: Veikkolainen Simo (Nokia-MS/Helsinki) >Cc: sixpac@ietf.org >Subject: Re: [sixpac] Drafts on SIP-XMPP combined use > >Hi Simo, > >A question about REQ-1: >When it says "SIP Contact" information - does this mean literally the >value in the SIP Contact: header? No, what is meant here is the information by which a SIP request can be rou= ted to the endpoint, meaning basically an AOR or GRUU. >I think it might need to be the AOR - since that is required to be a >FQDN and publicly reachable, whereas a contact header value might not >be. However, in the case where the AOR has multiple contacts registered, >would we require GRUU to specify which one is to be called? > >Is the requirement that the information provided allow for the specific >UA instance to be contacted when this identity information is conveyed >over XMPP? Yes. >REQ-3: Can you elaborate on "real time media contact and status" ? I am >not sure what the requirement is asking for. An indication that an audio >or video session simply exists - or details down to the port, CODEC etc. >??? The wording is indeed a bit confusing. What we would like is to be able to = indicate via XMPP presence that I'm available for voice or video calls on S= IP, and if you want to contact me, here is my SIP AOR. Also, if I happen to= be off-line, on the phone or otherwise not available for SIP calls, that s= hould be indicated in the XMPP presence as well. Simo >Regards, > >Peter Musgrave > > > >On 2010-11-11, at 4:05 PM, > wrote: > >> Thanks Peter for setting up this list! >> >> Just as a reminder, the relevant I-D for this work is >> http://tools.ietf.org/html/draft-veikkolainen-sip-xmpp-coex-reqs-01 >> >> We had an earlier draft containing also the protocol extensions, but >that one has been expired. However, you can find it at >> http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im >> >> For our first target, I think we should concentrate on getting a set >of requirements which is agreeable for all. >> >> Regards, >> Simo >> >> _______________________________________________ >> sixpac mailing list >> sixpac@ietf.org >> https://www.ietf.org/mailman/listinfo/sixpac