From simple-bounces@ietf.org Tue Nov 01 11:43:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWzE3-0006XX-7U; Tue, 01 Nov 2005 11:43:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWzDu-0006UE-VZ; Tue, 01 Nov 2005 11:42:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00965; Tue, 1 Nov 2005 11:42:38 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWzSJ-0004tm-VN; Tue, 01 Nov 2005 11:57:53 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jA1GgkKg000133; Tue, 1 Nov 2005 10:42:47 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id jA1Ggj504604; Tue, 1 Nov 2005 10:42:45 -0600 (CST) Message-ID: <43679B05.9040304@lucent.com> Date: Tue, 01 Nov 2005 10:42:45 -0600 From: "Vijay K. Gurbani" Organization: Wireless Networks Research and Development User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List , SIPPING LIST , Simple WG X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: Subject: [Simple] Get the aggregate PDF file for all I-Ds in a session X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1935404023==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1935404023== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060202090609010809070108" This is a cryptographically signed message in MIME format. --------------ms060202090609010809070108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks: In preparation for the SIP, SIPPING and SIMPLE WGs in the upcoming Vancouver IETF, I have collated all the I-Ds to be discussed in a session into an aggregate PDF file. You can access the PDF files from: SIP WG I-Ds (2 PDF files, each corresponding to a session) ----------- http://www.iit.edu/~gurbvij/SIPWG-Session-1.pdf http://www.iit.edu/~gurbvij/SIPWG-Session-2.pdf SIPPING WG I-Ds (2 PDF files, each corresponding to a session) --------------- http://www.iit.edu/~gurbvij/SIPPINGWG-Session-1.pdf http://www.iit.edu/~gurbvij/SIPPINGWG-Session-2.pdf SIMPLE WG I-Ds -------------- http://www.iit.edu/~gurbvij/SIMPLEWG-Session.pdf You have 2.17 MBytes of data to read and digest ... but who's counting ... ;-) Enjoy. Thanks, - vijay -- Vijay K. Gurbani, Ph.D. vkg@{lucent.com,research.bell-labs.com,acm.org} Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 --------------ms060202090609010809070108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTExMDExNjQyNDVaMCMGCSqGSIb3DQEJ BDEWBBQXvDbkmJyJSqfH5dLkBZD8eLUwOzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGALmSIuPqZpiFPTyH07H0hYc4kf9EQM8L3O6sg2aIcdRI3zR2pzxRe TYRjmFcRgActyFcC9ww0orRJ4F88OxVIzfCQakZPU1s3CjuJpnQ6/T46bZyN6MuzFi2M4kkM PnBEv7NzmQhDVSZwl5Z2f/8ehVkGsIEekaz0Fh7hHm5VZnAAAAAAAAA= --------------ms060202090609010809070108-- --===============1935404023== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1935404023==-- From simple-bounces@ietf.org Tue Nov 01 22:29:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9K0-00037Z-Pe; Tue, 01 Nov 2005 22:29:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9Jv-00036u-KN; Tue, 01 Nov 2005 22:29:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03734; Tue, 1 Nov 2005 22:29:31 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX9YR-0000DZ-Kg; Tue, 01 Nov 2005 22:44:51 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EX9Jv-0006WB-3T; Tue, 01 Nov 2005 22:29:51 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 01 Nov 2005 22:29:51 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: simple@ietf.org Subject: [Simple] Last Call: 'CIPID: Contact Information in Presence Information Data Format' to Proposed Standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG to consider the following document: - 'CIPID: Contact Information in Presence Information Data Format ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-11-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-06.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 01 22:33:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9NV-000483-RP; Tue, 01 Nov 2005 22:33:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9NR-00046d-4q; Tue, 01 Nov 2005 22:33:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04081; Tue, 1 Nov 2005 22:33:08 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX9bx-0000Ni-5H; Tue, 01 Nov 2005 22:48:29 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EX9NQ-0003NY-Jf; Tue, 01 Nov 2005 22:33:28 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 01 Nov 2005 22:33:28 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: simple@ietf.org Subject: [Simple] Last Call: 'Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals' to Proposed Standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG to consider the following document: - 'Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-11-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-future-04.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 01 22:35:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9Pg-0004wB-E2; Tue, 01 Nov 2005 22:35:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9Pb-0004vP-PW; Tue, 01 Nov 2005 22:35:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04445; Tue, 1 Nov 2005 22:35:23 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX9e7-0000XU-Pf; Tue, 01 Nov 2005 22:50:43 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EX9Pb-0003cB-72; Tue, 01 Nov 2005 22:35:43 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 01 Nov 2005 22:35:43 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: simple@ietf.org Subject: [Simple] Last Call: 'RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)' to Proposed Standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG to consider the following document: - 'RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-11-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-09.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 01 22:36:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9Qn-0005OB-Lf; Tue, 01 Nov 2005 22:36:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9Qi-0005MF-6L; Tue, 01 Nov 2005 22:36:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04682; Tue, 1 Nov 2005 22:36:31 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX9fD-0000hD-S1; Tue, 01 Nov 2005 22:51:52 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EX9Qh-0003fL-8e; Tue, 01 Nov 2005 22:36:51 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 01 Nov 2005 22:36:51 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: simple@ietf.org Subject: [Simple] Last Call: 'A Data Model for Presence' to Proposed Standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG to consider the following document: - 'A Data Model for Presence ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-11-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data-model-06.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 02 09:11:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXJKf-0000xR-B7; Wed, 02 Nov 2005 09:11:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXJKd-0000xE-JD for simple@megatron.ietf.org; Wed, 02 Nov 2005 09:11:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08206 for ; Wed, 2 Nov 2005 09:10:53 -0500 (EST) From: Martin.Hynar@tietoenator.com Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXJZD-00038C-E4 for simple@ietf.org; Wed, 02 Nov 2005 09:26:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Nov 2005 15:10:42 +0100 Message-ID: <3ACC9A25264A684F82C71840111F9798C2E36B@carrera.eu.tieto.com> Thread-Topic: RFC3857 clarificartion needed (Watcher Info event package for SIP) Thread-Index: AcXftzXWHNwwGKnGR6GF7t3YJ1B+0A== To: X-OriginalArrivalTime: 02 Nov 2005 14:10:45.0015 (UTC) FILETIME=[37536A70:01C5DFB7] X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Subject: [Simple] RFC3857 clarificartion needed (Watcher Info event package for SIP) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0337600870==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0337600870== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DFB7.367AF252" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DFB7.367AF252 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello,=20 =20 I have question about rfc3857 - A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP). Could you please help me finding answers to it? =20 I am trying to find out how is one-time fetch handled when reactive authorization should be used. I found following note on page 9 where state machine for subscriptions is defined: =20 "The waiting state is also needed to allow for authorization of fetch attempts, which are subscriptions that expire immediately." =20 The questions for which I am unable to find answers: 1/ Which response code is sent to the watcher? Is it 202 Accepted? 2/ What is in the following NOTIFY? Is it empty and the state indicated as "pending"? 3/ When the subscription (currently in waiting state according to the RFC) is authorized and consequently terminated, is notification sent to the watcher? =20 If these questions are not applicable, could you please let me know where can I find the behavior described, or how it should work? =20 Thank you for your time =20 =20 Martin Hynar=20 Software Specialist TietoEnator Czech Software Centre Direct +420 59 732 5901 Fax +420 59 732 5903 E-mail martin.hynar@tietoenator.com =20 =20 Vystavni 292/13 CZ-709 16 Ostrava =20 www.tietoenator.com =20 =20 =20 ------_=_NextPart_001_01C5DFB7.367AF252 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have question about rfc3857 - A Watcher = Information Event Template-Package for the Session Initiation Protocol (SIP). Could = you please help me finding answers to it?

 

I am trying to find out how is one-time fetch handled = when reactive authorization should be used. I found following note on page 9 = where state machine for subscriptions is defined:

 

"The waiting state is also needed to = allow for authorization of fetch attempts, which are subscriptions that expire immediately."

 

The questions for which I am unable to find = answers:

1/ Which response code is sent to the watcher? Is it = 202 Accepted?

2/ What is in the following NOTIFY? Is it empty and = the state indicated as “pending”?

3/ When the subscription (currently in waiting state according to the RFC) is authorized and consequently terminated, is notification sent to the watcher?

 

If these questions are not applicable, could you = please let me know where can I find the behavior described, or how it should = work?

 

Thank you for your time

 

 

Martin = Hynar 

Software = Specialist


= TietoEnator

=

Czech Software = Centre
Direct +420 59 732 5901

Fax +420 59 732 = 5903

=

E-mail martin.hynar@tietoenator.com=

 =

Vystavni = 292/13

=

CZ-709 16 = Ostrava

=

 

www.tietoenator.com=

=

 

 

------_=_NextPart_001_01C5DFB7.367AF252-- --===============0337600870== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0337600870==-- From simple-bounces@ietf.org Wed Nov 02 16:24:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXQ5w-0008AQ-4X; Wed, 02 Nov 2005 16:24:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWh9R-0006ne-Mq for simple@megatron.ietf.org; Mon, 31 Oct 2005 16:25:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11484; Mon, 31 Oct 2005 16:24:49 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWhNh-0006g4-IT; Mon, 31 Oct 2005 16:39:53 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EWh9L-000692-KU; Mon, 31 Oct 2005 16:25:03 -0500 Content-Type: text/plain Mime-Version: 1.0 To: Robert Sparks , Hisham Khartabil From: Dean Willis(OMA) Message-Id: Date: Mon, 31 Oct 2005 16:25:03 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA11484 X-Mailman-Approved-At: Wed, 02 Nov 2005 16:24:24 -0500 Cc: Ted Hardie , Scott Hollenbeck , simple@ietf.org, statements@ietf.org Subject: [Simple] Submission of New Liaison Statement, "OMA LS 0051 Proposing Solution to XCAP Issues" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Title: OMA LS 0051 Proposing Solution to XCAP Issues Submission Date: 2005-10-31 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_det= ail.cgi?detail_id=3D144=20 Please reply by 2005-11-12 From: Dean Willis(OMA) To: IETF SIMPLE Working Group(Robert Sparks , Hisha= m Khartabil ) Cc: Ted Hardie Scott Hollenbeck simple@ietf.org Reponse Contact: Lu Chang Jaekown Oh < jaekwon.oh@samsung.com> Technical Contact: Lu Chang Jaekown Oh < jaekwon.oh@samsung.com> Purpose: For action=20 Body: 1 Overview We are seeking your help in resolving the following issues OMA PAG encoun= ters while implementing XCAP: namespace binding and element insertion. OMA PAG kindly requests that IETF investigate the presented problems and = proposed solutions in a timely manner so that these issues can be quickly= resolved and XDM Specifications can be stabilized and ready for certific= ation. =20 OMA PAG kindly requests IETF informing us the result of their investigati= on. 2 Issue 1: Namespace Binding 2.1 Problem Statement During OMA POC and XDM IOP, the following problems were reported: (G1) Namespace (NS) binding for XML fragments sent between XDM clients an= d servers (G2) XML documents in XDM servers cluttered with local namespace declarat= ions=20 In OMA PAG internal discussions, it is noted that considering the nature = of scarce radio resources in wireless domain, it is essential that an XCA= P transaction should be accomplished without multiple queries and all XCA= P queries are constructed in such a way so as to minimize their lengths. = As a result, the following optimization goal should also be considered: (G3) Optimize XCAP queries, i.e. minimizing query length and reducing nee= ds to have additional transactions prior to a GET or PUT 3 Issue 2: Element Insertion 3.1 Problem Statement It is identified that there is difficulty in current XCAP to insert eleme= nts in a sequence.=20 XCAP-07 Section 8.2.3 says, =E2=80=9C=E2=80=A6.If the PUT request is for an element, the server inser= ts the content of the request body as a new child element of the parent element selected in Section 8.2.1. The insertion is done such that, the request URI, when evaluated, would now point to the element which was inserted. If the target selector is defined by a by-name or by-attr production (in other words, there is no position indicated) the server MUST insert the element after any other siblings. If a position is indicated, the server MUST insert the element so that it is the position-th element amongst all siblings whose name matches NameorAny. =E2=80=9C This text is not clear in that; =EF=82=9F The meaning of 'siblings' in element by-name or by-attribute ca= se is confusing. It could be interpreted either as all elements under the= same parent element, or as elements under the same parent element whose = name matches NameorAny. =EF=82=9F It is not described how to insert an element when there is no s= ibling whose name matches NameorAny.=20 The above ambiguities cause the following problems for schema validation: =EF=82=9F When the element insertion request is made, the element can be = inserted either after the siblings whose name matches NameorAny or after = the siblings under the same parent elements. =EF=82=9F When the element insertion request is made against the instance= document that does not contain sibling with same NameorAny, the XCAP Ser= ver behaviour is undefined. This problem applies to any element with or w= ithout attributes. As described in section 7.4 in XCAP-07, it is noted that the positional i= nsertion can ease the above-mentioned problems. However, it is still prob= lematic if there is no existing element with same NameorAny. Other Consideration and Recommendation: Another issue is the unique identification those element without attribut= e yet with multiple occurance.=20 Although it is recommended to design schema such that an element should h= ave attribute for unique element identification, there could exist scenar= ios that elements are defined without such attribute. An example of such = case is the previous common-policy-04 schema design where multiple occurr= ence of element without any attribute was allowed under e= lement. The latest common-policy-05 schema has revised this but, it seems= such scenarios could still happen in the future.=20 4 Requested Action(s) =E2=80=A2 OMA PAG WG kindly asks IETF(SIMPLE) to consider the presented p= roblems. OMA PAG would appreciate IETF informing us the course of action= in regarding to these problems. =20 The OMA PAG would like to thank IETF (SIMPLE) for their consideration and= response to this request and we look forward to future opportunities to = work together. Kind regards, Lu Chang, Ph.D. Jaekwon Oh On behalf of OMA PAG Lu.Chang@sonimtech.com jaekwon.oh@samsung.com Attachment(s): No document has been attached _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 02 17:17:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXQvd-0007XM-9W; Wed, 02 Nov 2005 17:17:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXQvc-0007XH-BS for simple@megatron.ietf.org; Wed, 02 Nov 2005 17:17:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11218 for ; Wed, 2 Nov 2005 17:17:35 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXRAG-0001BB-R4 for simple@ietf.org; Wed, 02 Nov 2005 17:33:06 -0500 Received: from [172.17.2.252] (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jA2MHcuD008540 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 2 Nov 2005 16:17:40 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: <1455A4EC-A012-4D70-B5B8-62EE33807848@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Simple WG From: Robert Sparks Date: Wed, 2 Nov 2005 16:17:37 -0600 X-Mailer: Apple Mail (2.734) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Simple] pdf of drafts appearing in agenda X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org For convenience, I've pdf rendered the drafts listed in the agenda at http://www3.ietf.org/proceedings/05nov/agenda/simple.txt in various formats: http://www.nostrum.com/~rjsparks/simple64-reading-list-1up-a4.pdf http://www.nostrum.com/~rjsparks/simple64-reading-list-1up-letter.pdf http://www.nostrum.com/~rjsparks/simple64-reading-list-2up-a4.pdf http://www.nostrum.com/~rjsparks/simple64-reading-list-2up-letter.pdf Let me know if you see anything there that's messed up. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 03 04:29:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXbPo-0003Av-4o; Thu, 03 Nov 2005 04:29:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXbPl-0003AE-UG for simple@megatron.ietf.org; Thu, 03 Nov 2005 04:29:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17129 for ; Thu, 3 Nov 2005 04:29:22 -0500 (EST) Received: from [80.74.106.10] (helo=rvil-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXbeW-00085n-Gg for simple@ietf.org; Thu, 03 Nov 2005 04:45:01 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Nov 2005 11:29:18 +0200 Message-ID: Thread-Topic: draft-urpalainen-simple-xml-patch-ops-01: ability to replace an element with descendants Thread-index: AcXgWRALs9No/CDMTe6y3oz+Q8C7ZQ== From: "Anat Angel" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 75ac735ede4d089f7192d230671d536e Subject: [Simple] draft-urpalainen-simple-xml-patch-ops-01: ability to replace an element with descendants X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0243138016==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0243138016== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E059.10628076" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E059.10628076 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 I have the following questions regarding the draft: 1. How can replacement of an element and all its descendents be preformed? =20 For example: Is it legal to do the following in order to replace all the contents of tuple 'xyz': open =20 and expect that all the 'old' descendants of 'tuple xyz' be removed and that just the 'new' descendants (that appear in the example) will appear? =20 2. From the draft it seems that is allowed, and that in this case all the descendants of 'tuple xyz' will stay as before. When is this necessary? =20 [Note:=20 The ability to replace an entity with descendants is important for composers: For example: A sends PUBLISH with tuple1 (status "open"). B sends PUBLISH with tuple1 (status "closed" and lots of other descendants). Composer sends full notification to all watchers with tuple1 with state closed (assuming the "last is more accurate" approach). Now A sends MODIFY with to tuple1 from "open" to "gone".=20 In this case the composer needs to update the watchers that tuple1 changed all its information from what B sent before to what A sent ("gone" and no other descendants). Of course, the composer can send and than but this is BW consuming. ] =20 =20 Regards, Anat =20 ------_=_NextPart_001_01C5E059.10628076 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

I have the following questions regarding the draft:

1. How can replacement of an element and all its descendents be = preformed?

 

For example: Is it legal to do the following in order to replace all the = contents of tuple 'xyz':

    &nbs= p;   <p:replace sel=3D"*/tuple[@id=3D'xyz']"><tuple = id=3D"xyz">

         &n= bsp; <status>

         &n= bsp;  <basic>open</basic>

         &n= bsp; </status>

          </tuple>

          </p:replace>

 

and expect that all the 'old' descendants of 'tuple xyz' be removed and that = just the 'new' descendants (that appear in the example) will = appear?

 

2. >From the draft it seems that

    &nbs= p;   <p:replace sel=3D"*/tuple[@id=3D'xyz']"><tuple = id=3D"xyz2">

is allowed, and that in this case all the descendants of 'tuple xyz' will = stay as before. When is this necessary?

 

[Note:

The ability to replace an entity with descendants is important for = composers: For example:

A sends PUBLISH with tuple1 (status "open").

B sends PUBLISH with tuple1 (status "closed" and lots of other descendants).

Composer sends full notification to all watchers with tuple1 with state closed = (assuming the "last is more accurate" approach).

Now A sends MODIFY with <replace> to tuple1 from "open" to "gone".

In this case the composer needs to update the watchers that tuple1 changed = all its information from what B sent before to what A sent ("gone" and = no other descendants).

Of course, the composer can send <remove> and than <add> but = this is BW consuming.

]

 

 

Regards,

Anat

 

------_=_NextPart_001_01C5E059.10628076-- --===============0243138016== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0243138016==-- From simple-bounces@ietf.org Thu Nov 03 06:47:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXdYl-00042D-V1; Thu, 03 Nov 2005 06:47:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXdYj-000419-Kq for simple@megatron.ietf.org; Thu, 03 Nov 2005 06:47:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25605 for ; Thu, 3 Nov 2005 06:46:45 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXdnT-00066v-2Y for simple@ietf.org; Thu, 03 Nov 2005 07:02:24 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA3Bgxk5022307; Thu, 3 Nov 2005 13:43:00 +0200 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Nov 2005 13:46:57 +0200 Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Nov 2005 13:46:57 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id jA3BktL05875; Thu, 3 Nov 2005 13:46:55 +0200 (EET) Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145]) by kusti.research.nokia.com (Postfix) with ESMTP id 669D893B6A; Thu, 3 Nov 2005 13:46:55 +0200 (EET) Message-ID: <4369F8AF.8000108@nokia.com> Date: Thu, 03 Nov 2005 13:46:55 +0200 From: Jari Urpalainen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Anat Angel Subject: Re: [Simple] draft-urpalainen-simple-xml-patch-ops-01: ability to replace an element with descendants References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2005 11:46:57.0932 (UTC) FILETIME=[4B98C4C0:01C5E06C] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Anat Angel wrote: >Hi > > > >I have the following questions regarding the draft: > >1. How can replacement of an element and all its descendents be >preformed? > > > >For example: Is it legal to do the following in order to replace all the >contents of tuple 'xyz': > > > > > > open > > > > > > > > > > > replaces totally. >and expect that all the 'old' descendants of 'tuple xyz' be removed and >that just the 'new' descendants (that appear in the example) will >appear? > > > > so old descendants disapper. >2. From the draft it seems that > > > >is allowed, and that in this case all the descendants of 'tuple xyz' >will stay as before. When is this necessary? > > > So perhaps not clearly enough expressed in the spec, but element replacement means replacing everything that appears in the new refreshed element: attributes, text nodes, ns declarations and all descendant nodes. > > >[Note: > >The ability to replace an entity with descendants is important for >composers: For example: > >A sends PUBLISH with tuple1 (status "open"). > >B sends PUBLISH with tuple1 (status "closed" and lots of other >descendants). > >Composer sends full notification to all watchers with tuple1 with state >closed (assuming the "last is more accurate" approach). > >Now A sends MODIFY with to tuple1 from "open" to "gone". > >In this case the composer needs to update the watchers that tuple1 >changed all its information from what B sent before to what A sent >("gone" and no other descendants). > >Of course, the composer can send and than but this is BW >consuming. > >] > > > > > >Regards, > >Anat > > text node updates are possible as well, as text() function is also allowed, i.e. you can update only text node content with open. However, it is up to the publisher or notifier to choose the granularity level of patches (in other words, what's reasonable). thanks, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 03 17:55:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXnzk-0006jz-7j; Thu, 03 Nov 2005 17:55:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXnzi-0006ju-Rf for simple@megatron.ietf.org; Thu, 03 Nov 2005 17:55:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03076 for ; Thu, 3 Nov 2005 17:55:21 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXoEb-0007ig-Hp for simple@ietf.org; Thu, 03 Nov 2005 18:11:05 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 03 Nov 2005 17:55:31 -0500 X-IronPort-AV: i="3.97,289,1125892800"; d="scan'208"; a="75053518:sNHT25005984" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA3MscdM009004; Thu, 3 Nov 2005 17:55:29 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Nov 2005 17:55:05 -0500 Received: from [161.44.55.207] ([161.44.55.207]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Nov 2005 17:55:05 -0500 Message-ID: <436A9548.3030108@cisco.com> Date: Thu, 03 Nov 2005 17:55:04 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Xiaotao Wu References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2005 22:55:05.0522 (UTC) FILETIME=[A1A99120:01C5E0C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Henning Schulzrinne Subject: [Simple] Re: Does the order of data-model elements and rpid elements matter for data-model and rpid elements? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Xiaotao Wu wrote: > The data-model draft defines and elements which can > be put in a pidf document's element. Does the order of > and matter? The data model spec doesn't say. I don't think it should matter. The inability to clearly specify this is one of the difficulties in using the extensibility mechanism we are using; this is a recognized limitation. However, the data-model spec should state that it doesnt matter. > If the order does not matter, should that be explicitly mentioned in > the draft to ensure the interoperability? Yes. > So, people should not use > device...> to integrate data-model into pidf schema. Well, they should never do that. Firstly, we are generally not recommending validation on receipt for presence documents. Secondly, if you do validate, you should never be modifying the original xml schema to add the extensions as child elements in place of the . > Rather, they should use person...> to > integrate and elements into pidf schema. No, neither. The document should be validated against the specified schema. > > The same question also applies to the rpid I-D. Should we explicitly > mentioned in the draft that the order of , , ... > does not matter in a XML document. Yes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 04 03:23:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXwqk-0002Mf-Vm; Fri, 04 Nov 2005 03:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXwqj-0002KW-57 for simple@megatron.ietf.org; Fri, 04 Nov 2005 03:23:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01227 for ; Fri, 4 Nov 2005 03:22:38 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXx5f-0005jV-Gg for simple@ietf.org; Fri, 04 Nov 2005 03:38:29 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 09:22:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Nov 2005 09:22:56 +0100 Message-ID: Thread-Topic: Comment on draft-ietf-simple-presence-rules-04 Thread-Index: AcXhGO3KR01LUb/TRKKROr+x1jK3uA== From: "MARJOU Xavier RD-MAPS-LAN" To: X-OriginalArrivalTime: 04 Nov 2005 08:22:57.0629 (UTC) FILETIME=[F63880D0:01C5E118] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Subject: [Simple] Comment on draft-ietf-simple-presence-rules-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, I would like to know how to implement an "always ask" authorization policy as in the following case: "A watcher W wants to access to Presentity P's presence information. P wants to receive a confirm notification from the presence server, not only for the first subscription, but for each subscription" One possible way could be: Upon the first reception of the subscription notification, P can create a rule saying "accept" for the W identity. Then it modifies this rule with a "confirm". However, everytime P receives a confirmation demand, it has to modify the rule to "accept" (so the server knows the subscription is not pending anymore) and then back to "confirm". This would work, but is not efficient. Another way could be to add an "allow-once" value in the "3.2.1 Subscription Handling" section in order to tell the server to accept the current subscription request but to move the subscription into the confirm state for next subscriptions. Any thoughts? Xavier _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 04 05:56:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXzF4-0007rM-4C; Fri, 04 Nov 2005 05:56:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXzF1-0007rH-Ue for simple@megatron.ietf.org; Fri, 04 Nov 2005 05:56:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12093 for ; Fri, 4 Nov 2005 05:55:53 -0500 (EST) Received: from rat01038.dc-ratingen.de ([195.233.129.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXzTu-0002Xq-PT for simple@ietf.org; Fri, 04 Nov 2005 06:11:45 -0500 Received: from rat01047.dc-ratingen.de (rat01047_e0 [195.233.128.119]) by rat01038.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id jA4AtrB6013215 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 4 Nov 2005 11:55:53 +0100 (MET) Received: from gpsmxr04.gps.internal.vodafone.com ([195.232.231.115]) by rat01047.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id jA4AtrVk007567 for ; Fri, 4 Nov 2005 11:55:53 +0100 (MET) Received: from gpsmx11.gps.internal.vodafone.com ([145.230.1.15]) by gpsmxr04.gps.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Nov 2005 11:55:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Nov 2005 10:55:22 -0000 Message-ID: <6C742B4BEC7D1D4FB045E74BB625987B050727C1@gpsmx11.gps.internal.vodafone.com> Thread-Topic: Handling of anonymous subscriptions in pres-rules Thread-Index: AcXhLkCA/ELEVvW5RSS1GxcI3fIOrQ== From: "Zisimopoulos, Haris, VF-Group" To: X-OriginalArrivalTime: 04 Nov 2005 10:55:52.0803 (UTC) FILETIME=[530CF330:01C5E12E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Subject: [Simple] Handling of anonymous subscriptions in pres-rules X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hello, I am looking at the handling of anonymous presence subscriptions. After the removal of element from common policy in the new version of the pres-rules there seems to be no defined way to support anonymous subscriptions that will not contain the P-Asserted-Identity, 3GPP in the IMS specification defines particular settings of the "Privacy" header of the incoming request that indicate to any application server (in that case the presence server) that the request is "anonymous".=20 Should handling of these type of requests in IMS domains be provided with vendor specific extensions to common policy (eg in OMA) or is there any plan to define a child element in pres-rules or draft-ietf-simple-pres-policy-caps-00 (I think there was such an element there in the past) for that purpose?=20 Best regards, Haris Haris Zisimopoulos Vodafone Group Research & Development - UK Telephone: +44 (0)7919994709 E-mail: haris.zisimopoulos@vodafone.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Nov 06 02:36:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYf5H-0005R9-Ky; Sun, 06 Nov 2005 02:36:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYf5F-0005R4-Sz for simple@megatron.ietf.org; Sun, 06 Nov 2005 02:36:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12974 for ; Sun, 6 Nov 2005 02:36:34 -0500 (EST) From: krisztian.kiss@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYfKc-0007O1-6D for simple@ietf.org; Sun, 06 Nov 2005 02:52:50 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA67Wg2U031403 for ; Sun, 6 Nov 2005 09:32:44 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Nov 2005 09:36:55 +0200 Received: from sdebe101.NOE.Nokia.com ([172.19.222.105]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Nov 2005 01:36:44 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-05.txt Date: Sat, 5 Nov 2005 23:36:47 -0800 Message-ID: Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-05.txt Thread-Index: AcXbMtdUKFb0gPNASS26wRKjhRjE8gHaefSw To: X-OriginalArrivalTime: 06 Nov 2005 07:36:44.0148 (UTC) FILETIME=[D5EC6340:01C5E2A4] X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Here is a summary about the changes compared to -04 (only minor): - Added sentence to section 4 to explain the meaning if a certain feature tag appears in , , or in neither of those. - Some bug fixes in XML schema and the example=20 - The example updated according to the latest data-model - XML schemas (service capability + device capability) merged into a single schema - Updated references=20 - <100rel> changed to ("100rel" is not a valid NCName, since it starts with a number) - Terminology: service capability element instead of service capability document & device capability element instead of device capability document - Several typo corrections I believe this version is ready for WGLC. Cheers, Krisztian >-----Original Message----- >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]=20 >Sent: Thursday, October 27, 2005 12:50 PM >To: i-d-announce@ietf.org >Cc: simple@ietf.org >Subject: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-05.txt=20 > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. >This draft is a work item of the SIP for Instant Messaging and=20 >Presence Leveraging Extensions Working Group of the IETF. > > Title : User Agent Capability Extension to =20 >Presence Information Data Format (PIDF) > Author(s) : M. Lonnfors, K. Kiss > Filename : draft-ietf-simple-prescaps-ext-05.txt > Pages : 29 > Date : 2005-10-27 >=09 >Interoperation of instant messaging and presence systems has been > defined in the IMPP working group. The IMPP WG has come up with > baseline interoperable operations and formats for presence and > instant messaging systems. This memo defines an extension to > represent RFC3840 capabilities in the Presence Information Document > Format (PIDF) compliant presence documents. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps- >ext-05.txt > >To remove yourself from the I-D Announcement list, send a=20 >message to i-d-announce-request@ietf.org with the word=20 >unsubscribe in the body of the message. =20 >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login=20 >with the username "anonymous" and a password of your e-mail=20 >address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-simple-prescaps-ext-05.txt". > >A list of Internet-Drafts directories can be found in=20 >http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-simple-prescaps-ext-05.txt". >=09 >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 >mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Nov 06 19:59:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYvLh-0007y5-1d; Sun, 06 Nov 2005 19:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYvLf-0007vM-De for simple@megatron.ietf.org; Sun, 06 Nov 2005 19:58:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00951 for ; Sun, 6 Nov 2005 19:58:33 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYvbA-0001jC-QJ for simple@ietf.org; Sun, 06 Nov 2005 20:15:01 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2005 16:58:50 -0800 X-IronPort-AV: i="3.97,298,1125903600"; d="scan'208"; a="227717260:sNHT24861324" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA70wiNn009675; Sun, 6 Nov 2005 16:58:47 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 19:58:45 -0500 Received: from [209.52.109.209] ([10.86.242.55]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 19:58:44 -0500 Message-ID: <436EA6C3.7060008@cisco.com> Date: Sun, 06 Nov 2005 19:58:43 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Zisimopoulos, Haris, VF-Group" Subject: Re: [Simple] Handling of anonymous subscriptions in pres-rules References: <6C742B4BEC7D1D4FB045E74BB625987B050727C1@gpsmx11.gps.internal.vodafone.com> In-Reply-To: <6C742B4BEC7D1D4FB045E74BB625987B050727C1@gpsmx11.gps.internal.vodafone.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2005 00:58:44.0947 (UTC) FILETIME=[67393A30:01C5E336] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org inline. Zisimopoulos, Haris, VF-Group wrote: > Hello, > > I am looking at the handling of anonymous presence subscriptions. After > the removal of element from common policy in the new version > of the pres-rules there seems to be no defined way to support anonymous > subscriptions that will not contain the P-Asserted-Identity, 3GPP in the > IMS specification defines particular settings of the "Privacy" header of > the incoming request that indicate to any application server (in that > case the presence server) that the request is "anonymous". Anonymous subscriptions are supported; what you CANT do is define authorization policies for anonymous subscriptions differently than unauthenticated ones. You can always specify rules that apply to unauthenticated subscriptions by having rules that don't contain an rule. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 07 10:25:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8ro-0008ES-QR; Mon, 07 Nov 2005 10:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8rn-0008DQ-Od for simple@megatron.ietf.org; Mon, 07 Nov 2005 10:25:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16235 for ; Mon, 7 Nov 2005 10:24:36 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ97L-0006sP-HP for simple@ietf.org; Mon, 07 Nov 2005 10:41:10 -0500 X-IronPort-AV: i="3.97,300,1125892800"; d="scan'208"; a="22377400:sNHT30400272" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2005 10:24:49 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470184FE0B@ATLANTIS.Brooktrout.com> Thread-Topic: Issue 1: End-to-End encryption Thread-Index: AcXjLtAqjbugAEHdTx+XE5CpwzFNzg== From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Subject: [Simple] Issue 1: End-to-End encryption X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The draft asserts that IMDN's MUST be end-to-end (S/MIME) signed at the least, and preferably encrypted. Is this OK with everyone? Pro: Only way to ensure end-to-end security Only way to have some modicum of privacy, especially when dealing with B2BUA's. Con: Is the key infrastructure extant to enable end-to-end encryption for EVERYONE? Some more processing at the sender and receiver. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 07 10:25:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8rp-0008FH-Cl; Mon, 07 Nov 2005 10:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8ro-0008Dl-34 for simple@megatron.ietf.org; Mon, 07 Nov 2005 10:25:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16242 for ; Mon, 7 Nov 2005 10:24:38 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ97N-0006t2-IW for simple@ietf.org; Mon, 07 Nov 2005 10:41:12 -0500 X-IronPort-AV: i="3.97,300,1125892800"; d="scan'208"; a="22377404:sNHT55121736" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2005 10:24:49 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470184FE0C@ATLANTIS.Brooktrout.com> Thread-Topic: IMDN Open/Controversial Issues Thread-Index: AcXjLtl3pFtU5q90QvG1KalFWR+8QQ== From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Subject: [Simple] IMDN Open/Controversial Issues X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Since there has been no list traffic, even though there were embedded Easter Eggs / Time Bombs, I'm starting a thread of open issues that we need to resolve. This can be quick (do what I say) or long and drawn out (well, some of my assertions are way beyond the pale, even for me). I doubt we can discuss this in the SIMPLE work group meeting in Vancouver. I would like to see some list discussion before we commit to some high bandwidth interaction. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 07 10:25:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8rq-0008Fr-3g; Mon, 07 Nov 2005 10:25:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8ro-0008Dj-2v for simple@megatron.ietf.org; Mon, 07 Nov 2005 10:25:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16240 for ; Mon, 7 Nov 2005 10:24:38 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ97P-0006sP-B1 for simple@ietf.org; Mon, 07 Nov 2005 10:41:12 -0500 X-IronPort-AV: i="3.97,300,1125892800"; d="scan'208"; a="22377406:sNHT29213856" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2005 10:24:50 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470184FE0D@ATLANTIS.Brooktrout.com> Thread-Topic: Issue 2: Sender keeps state Thread-Index: AcXjL1FPPIG1fj3BRluCHdmKruwl6A== From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Subject: [Simple] Issue 2: Sender keeps state X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org In MDN, the message itself keeps state. In the e-mail world, there is no requirement for the UAC to keep the state of messages sent. When the UAS sends a MDN, it includes the message itself so the user can figure out what the report is about. This has turned into a major SPAM hole. Folks send out SPAM masquerading as a MDN. I'd like to close this hole, which is what the draft does. However, it imposes the burden of the UAC keeping state of messages it sends. My logic is that this is a tiny price to pay to close the SPAM hole. OK with everyone? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 07 10:25:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8rq-0008GL-Rb; Mon, 07 Nov 2005 10:25:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8ro-0008Dh-26 for simple@megatron.ietf.org; Mon, 07 Nov 2005 10:25:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16244 for ; Mon, 7 Nov 2005 10:24:38 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ97P-0006tH-Pb for simple@ietf.org; Mon, 07 Nov 2005 10:41:13 -0500 X-IronPort-AV: i="3.97,300,1125892800"; d="scan'208"; a="22377407:sNHT30344064" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2005 10:24:50 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470184FE0E@ATLANTIS.Brooktrout.com> Thread-Topic: Issue 3: No date/time in IMDN Thread-Index: AcXjL6/HgwGMjQbhQO6jHePvmRiSTQ== From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: quoted-printable Subject: [Simple] Issue 3: No date/time in IMDN X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Since the UAS can lie, this makes the data element useless. Moreover, CPIM, and virtually all CPIM transport protocols, already have a date/time sent stamp. Thus the draft does not have a date/time data element. OK with everyone? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 07 10:25:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8rr-0008Gs-JM; Mon, 07 Nov 2005 10:25:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8rp-0008FA-7c for simple@megatron.ietf.org; Mon, 07 Nov 2005 10:25:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16250 for ; Mon, 7 Nov 2005 10:24:40 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ97R-0006sP-8y for simple@ietf.org; Mon, 07 Nov 2005 10:41:14 -0500 X-IronPort-AV: i="3.97,300,1125892800"; d="scan'208"; a="22377410:sNHT29024232" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2005 10:24:51 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470184FE0F@ATLANTIS.Brooktrout.com> Thread-Topic: Issue 4: Recipient of IMDN can appear different than sender Thread-Index: AcXjMF/vq3xXLv6ZQ7yby6DGbVQOCQ== From: "Burger, Eric" To: X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Subject: [Simple] Issue 4: Recipient of IMDN can appear different than sender X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org To enable scenarios where the "sender" of an IM has a generic address, like "sip:info@example.com", but the user sending the IM has a specific address, like "sip:agent24@agentpool.example.com", as well as to keep state out of B2BUA's and relays, the draft has an explicit Disposition-Notification-To header, with the address for the UAS to send the report to. This has the potential for a bad UAC to IMDN-bomb an unsuspecting third-party. Thus the draft has a bunch of protocol machinery for the UAS to ensure identity of the requestor, if only to enable Level 8 handling of the problem. OK with everyone? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 07 10:25:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8rs-0008HN-5a; Mon, 07 Nov 2005 10:25:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8rp-0008Ff-JB for simple@megatron.ietf.org; Mon, 07 Nov 2005 10:25:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16253 for ; Mon, 7 Nov 2005 10:24:40 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ97R-0006t2-GN for simple@ietf.org; Mon, 07 Nov 2005 10:41:14 -0500 X-IronPort-AV: i="3.97,300,1125892800"; d="scan'208"; a="22377412:sNHT33901176" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2005 10:24:51 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470184FE10@ATLANTIS.Brooktrout.com> Thread-Topic: Issue 5: Deleted State Thread-Index: AcXjML1VEf+so9ouTrin9NYeQDu3Tg== From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Subject: [Simple] Issue 5: Deleted State X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org MDN has a concept of reporting that the UAS automatically deleted the message, versus the user deleting the message. The IMDN draft does not carry forward this concept, as it has not been of much use in the real world of MDN deployment. Does anyone care? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 07 10:25:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8rs-0008Hn-Jq; Mon, 07 Nov 2005 10:25:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8rp-0008Fl-QQ for simple@megatron.ietf.org; Mon, 07 Nov 2005 10:25:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16256 for ; Mon, 7 Nov 2005 10:24:40 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ97R-0006tH-Mn for simple@ietf.org; Mon, 07 Nov 2005 10:41:15 -0500 X-IronPort-AV: i="3.97,300,1125892800"; d="scan'208"; a="22377415:sNHT33314660" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2005 10:24:51 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470184FE11@ATLANTIS.Brooktrout.com> Thread-Topic: Issue 6: Consolidation Thread-Index: AcXjMVLA1agp9ALOR3ag64yRZsaQ1A== From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: quoted-printable Subject: [Simple] Issue 6: Consolidation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The IMDN draft says that whether a B2BUA consolidates responses is a local to the B2BUA matter. Should this be negotiable (via a Requires: CPIM header)? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 07 10:55:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ9L9-0008EP-7l; Mon, 07 Nov 2005 10:55:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ9L8-0008EK-BN for simple@megatron.ietf.org; Mon, 07 Nov 2005 10:55:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18919 for ; Mon, 7 Nov 2005 10:54:57 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ9ak-00083X-F1 for simple@ietf.org; Mon, 07 Nov 2005 11:11:32 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 40A9CD22 for ; Mon, 7 Nov 2005 16:55:09 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 16:53:19 +0100 Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 16:53:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Default namespace for pres-rule was [RE: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-04.txt ] Date: Mon, 7 Nov 2005 16:53:16 +0100 Message-ID: <2DC267ED40568D4F9AA4F5DF955AF16AB3C972@esealmw107.eemea.ericsson.se> Thread-Topic: Default namespace for pres-rule was [RE: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-04.txt ] Thread-Index: AcXaxdAuFHdNuKGiSRGzyzKyFsPyowI6xp/Q From: "Anders Lindgren C (HF/EAB)" To: X-OriginalArrivalTime: 07 Nov 2005 15:53:18.0816 (UTC) FILETIME=[5F57AE00:01C5E3B3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hello, I have a question about which default namespace shall be used for pres-rule. Is it "urn:ietf:params:xml:ns:pres-rules" or "urn:ietf:params:xml:ns:common-policy"? My view is that a chapter ("Default Namespace") is missing in draft defining this. See http://ietf.org/internet-drafts/draft-ietf-simple-xcap-08.txt chapter 5.9 Thanks Anders Lindgren -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: den 27 oktober 2005 08:50 To: i-d-announce@ietf.org Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-04.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Presence Authorization Rules Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-rules-04.txt Pages : 27 Date : 2005-10-26 =09 Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-04. txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presence-rules-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presence-rules-04.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 07 13:58:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCBw-0007oj-V9; Mon, 07 Nov 2005 13:58:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCBt-0007oa-Uv for simple@megatron.ietf.org; Mon, 07 Nov 2005 13:58:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29637 for ; Mon, 7 Nov 2005 13:57:35 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZCRX-0004n3-Qr for simple@ietf.org; Mon, 07 Nov 2005 14:14:13 -0500 Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 2A14919445E for ; Mon, 7 Nov 2005 19:57:40 +0100 (CET) Received: from [209.52.109.174] ([192.168.3.109]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Nov 2005 20:01:02 +0100 In-Reply-To: <330A23D8336C0346B5C1A5BB196666470184FE0D@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB196666470184FE0D@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <347d61204c6b85aa79d7576f4021adb0@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Issue 2: Sender keeps state Date: Mon, 7 Nov 2005 19:57:02 +0100 To: "Burger, Eric" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 07 Nov 2005 19:01:02.0299 (UTC) FILETIME=[98E6CAB0:01C5E3CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I don't agree that state is needed at the client. SPAM will be solved elsewhere. And a UAS does not need to put the actual IM in the MDN. Often enough, the URI of the recipient of the IM is, imo, enough for the human user to know what this MDN is for. Having said that, we should not stop implementations from keeping state if they want to. Also, think of having an inbox and and sent box (just like email or sms in your mobile phone). In those cases, the client is, soft of, keeping state until the user deletes items from the sent box. Matching of MDNs and IMs in this case can be done using message-id- Hisham On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > In MDN, the message itself keeps state. In the e-mail world, there is > no requirement for the UAC to keep the state of messages sent. When > the > UAS sends a MDN, it includes the message itself so the user can figure > out what the report is about. > > This has turned into a major SPAM hole. Folks send out SPAM > masquerading as a MDN. > > I'd like to close this hole, which is what the draft does. However, it > imposes the burden of the UAC keeping state of messages it sends. My > logic is that this is a tiny price to pay to close the SPAM hole. > > OK with everyone? > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 07 13:58:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCCF-0007qh-Or; Mon, 07 Nov 2005 13:58:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCCD-0007qS-VD for simple@megatron.ietf.org; Mon, 07 Nov 2005 13:58:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29685 for ; Mon, 7 Nov 2005 13:57:55 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZCRs-0004oc-VY for simple@ietf.org; Mon, 07 Nov 2005 14:14:33 -0500 Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id B741119445E for ; Mon, 7 Nov 2005 19:58:12 +0100 (CET) Received: from [209.52.109.174] ([192.168.3.109]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Nov 2005 20:01:34 +0100 In-Reply-To: <330A23D8336C0346B5C1A5BB196666470184FE0B@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB196666470184FE0B@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Issue 1: End-to-End encryption Date: Mon, 7 Nov 2005 19:57:37 +0100 To: "Burger, Eric" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 07 Nov 2005 19:01:34.0878 (UTC) FILETIME=[AC51F3E0:01C5E3CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I would make it a SHOULD. Hisham On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > The draft asserts that IMDN's MUST be end-to-end (S/MIME) signed at the > least, and preferably encrypted. Is this OK with everyone? > > Pro: > Only way to ensure end-to-end security > Only way to have some modicum of privacy, especially when dealing with > B2BUA's. > > Con: > Is the key infrastructure extant to enable end-to-end encryption for > EVERYONE? > Some more processing at the sender and receiver. > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 07 14:01:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCEw-0008FE-U0; Mon, 07 Nov 2005 14:01:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCEv-0008Ek-1O for simple@megatron.ietf.org; Mon, 07 Nov 2005 14:01:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00077 for ; Mon, 7 Nov 2005 14:00:42 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZCUY-0004yF-La for simple@ietf.org; Mon, 07 Nov 2005 14:17:19 -0500 Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 62E30194459 for ; Mon, 7 Nov 2005 20:00:58 +0100 (CET) Received: from [209.52.109.174] ([192.168.3.109]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Nov 2005 20:04:19 +0100 In-Reply-To: <330A23D8336C0346B5C1A5BB196666470184FE0E@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB196666470184FE0E@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Issue 3: No date/time in IMDN Date: Mon, 7 Nov 2005 20:00:19 +0100 To: "Burger, Eric" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 07 Nov 2005 19:04:20.0538 (UTC) FILETIME=[0F0FA9A0:01C5E3CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I think we need a date/time stamp, but it should be optional and a disclaimer needs to be put in the draft saying that the date/time cannot be trusted. Hisham On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > Since the UAS can lie, this makes the data element useless. Moreover, > CPIM, and virtually all CPIM transport protocols, already have a > date/time sent stamp. Thus the draft does not have a date/time data > element. > > OK with everyone? > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 07 14:06:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCK9-0000yC-Dt; Mon, 07 Nov 2005 14:06:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCK7-0000xh-3x for simple@megatron.ietf.org; Mon, 07 Nov 2005 14:06:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00683 for ; Mon, 7 Nov 2005 14:06:04 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZCZl-0005DH-2W for simple@ietf.org; Mon, 07 Nov 2005 14:22:42 -0500 Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id BE079194459 for ; Mon, 7 Nov 2005 20:06:20 +0100 (CET) Received: from [209.52.109.174] ([192.168.3.109]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Nov 2005 20:09:42 +0100 In-Reply-To: <330A23D8336C0346B5C1A5BB196666470184FE0F@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB196666470184FE0F@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9341b1e8843d57ca57829a1134a1ff67@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Issue 4: Recipient of IMDN can appear different than sender Date: Mon, 7 Nov 2005 20:05:46 +0100 To: "Burger, Eric" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 07 Nov 2005 19:09:42.0924 (UTC) FILETIME=[CF37DCC0:01C5E3CE] X-Spam-Score: 1.1 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I think having that header is ok. But the reason you give about keeping state out of the B2BUAs and relays is not a good reason. Often enough B2BUAs need to be involved in the MDN generation, but thats a topic for a different thread. Hisham On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > To enable scenarios where the "sender" of an IM has a generic address, > like "sip:info@example.com", but the user sending the IM has a specific > address, like "sip:agent24@agentpool.example.com", as well as to keep > state out of B2BUA's and relays, the draft has an explicit > Disposition-Notification-To header, with the address for the UAS to > send > the report to. > > This has the potential for a bad UAC to IMDN-bomb an unsuspecting > third-party. Thus the draft has a bunch of protocol machinery for the > UAS to ensure identity of the requestor, if only to enable Level 8 > handling of the problem. > > OK with everyone? > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 07 15:55:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZE1W-0004uJ-CR; Mon, 07 Nov 2005 15:55:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZE1V-0004uE-5D for simple@megatron.ietf.org; Mon, 07 Nov 2005 15:55:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07088 for ; Mon, 7 Nov 2005 15:54:58 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZEHA-0008Li-5b for simple@ietf.org; Mon, 07 Nov 2005 16:11:37 -0500 Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 10A7719445E for ; Mon, 7 Nov 2005 21:55:09 +0100 (CET) Received: from [209.52.109.174] ([192.168.3.104]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Nov 2005 21:58:31 +0100 In-Reply-To: <330A23D8336C0346B5C1A5BB196666470184FE10@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB196666470184FE10@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <10776cb20b5216f7c545300d9c395b31@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Issue 5: Deleted State Date: Mon, 7 Nov 2005 21:54:34 +0100 To: "Burger, Eric" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 07 Nov 2005 20:58:31.0421 (UTC) FILETIME=[028172D0:01C5E3DE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > MDN has a concept of reporting that the UAS automatically deleted the > message, versus the user deleting the message. > > The IMDN draft does not carry forward this concept, as it has not been > of much use in the real world of MDN deployment. > > Does anyone care? I don't :) I find this whole delete state useless for humans. I never want anyone to know if I deleted their message or not and I think no one wants to tell me either that they deleted my message. Having said that, I on the fence if we should keep this deleted state in there at all or not. It might be helpful for some automata applications that we haven't discovered yet, but should we clutter the protocol now for future applications or should we leave it for extensions? Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 07 15:59:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZE5D-0005ce-MN; Mon, 07 Nov 2005 15:59:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZE5B-0005cW-Tz for simple@megatron.ietf.org; Mon, 07 Nov 2005 15:59:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07319 for ; Mon, 7 Nov 2005 15:58:47 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZEKs-0008Si-1c for simple@ietf.org; Mon, 07 Nov 2005 16:15:26 -0500 Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id BB139194459 for ; Mon, 7 Nov 2005 21:59:04 +0100 (CET) Received: from [209.52.109.174] ([192.168.3.104]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Nov 2005 22:02:26 +0100 In-Reply-To: <330A23D8336C0346B5C1A5BB196666470184FE11@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB196666470184FE11@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <20e347e80817a23829d8d2c17e8b2df3@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Issue 6: Consolidation Date: Mon, 7 Nov 2005 21:58:31 +0100 To: "Burger, Eric" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 07 Nov 2005 21:02:27.0118 (UTC) FILETIME=[8EFDF4E0:01C5E3DE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Actually, some parts of the draft talks about consolidation of responses and other parts of the draft say that consolidation was removed from the draft. I don't like the consolidation concept, mainly because it creates state in the B2BUA that is not really necessary. I think having individual MDNs delivered to the IM sender is enough. Hisham On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > The IMDN draft says that whether a B2BUA consolidates responses is a > local to the B2BUA matter. > > Should this be negotiable (via a Requires: CPIM header)? > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 07 20:55:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIho-0003Gp-AO; Mon, 07 Nov 2005 20:55:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIhm-0003Gk-Rm for simple@megatron.ietf.org; Mon, 07 Nov 2005 20:55:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00504 for ; Mon, 7 Nov 2005 20:54:56 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZIxT-0001vg-67 for simple@ietf.org; Mon, 07 Nov 2005 21:11:37 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IPM00CLM5OA6X@szxga01-in.huawei.com> for simple@ietf.org; Tue, 08 Nov 2005 10:02:35 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IPM00D9O5O5M7@szxga01-in.huawei.com> for simple@ietf.org; Tue, 08 Nov 2005 10:02:29 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IPM00LSC5QZM0@szxml02-in.huawei.com>; Tue, 08 Nov 2005 10:04:11 +0800 (CST) Date: Tue, 08 Nov 2005 09:54:49 +0800 From: Xiao Wang Subject: RE: [Simple] Issue 2: Sender keeps state In-reply-to: <330A23D8336C0346B5C1A5BB196666470184FE0D@ATLANTIS.Brooktrout.com> To: "'Burger, Eric'" Message-id: <009f01c5e407$66eeb0b0$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7BIT Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Burger, But how long does the UAC keep state of messages it sends? Because we don't know the UAS what time to send IMDN back, maybe an hour, a day, a month, or it dose not send back at all. And before UAS send it back, UAC may restart some times. So I think if have another way to resolve this issue, for example, the summary of message? Xiao > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of > Burger, Eric > Sent: Monday, November 07, 2005 11:25 PM > To: simple@ietf.org > Subject: [Simple] Issue 2: Sender keeps state > > In MDN, the message itself keeps state. In the e-mail world, there is > no requirement for the UAC to keep the state of messages sent. When the > UAS sends a MDN, it includes the message itself so the user can figure > out what the report is about. > > This has turned into a major SPAM hole. Folks send out SPAM > masquerading as a MDN. > > I'd like to close this hole, which is what the draft does. However, it > imposes the burden of the UAC keeping state of messages it sends. My > logic is that this is a tiny price to pay to close the SPAM hole. > > OK with everyone? > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 07 21:27:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJCg-0004RW-QU; Mon, 07 Nov 2005 21:27:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJCf-0004QE-3W for simple@megatron.ietf.org; Mon, 07 Nov 2005 21:27:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02630 for ; Mon, 7 Nov 2005 21:26:50 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJSM-0002np-MK for simple@ietf.org; Mon, 07 Nov 2005 21:43:32 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IPM00LT874NJG@szxga01-in.huawei.com> for simple@ietf.org; Tue, 08 Nov 2005 10:33:59 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IPM00DQP74NM7@szxga01-in.huawei.com> for simple@ietf.org; Tue, 08 Nov 2005 10:33:59 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IPM00M9B77HPX@szxml02-in.huawei.com>; Tue, 08 Nov 2005 10:35:41 +0800 (CST) Date: Tue, 08 Nov 2005 10:26:18 +0800 From: Xiao Wang Subject: RE: [Simple] Issue 2: Sender keeps state In-reply-to: <347d61204c6b85aa79d7576f4021adb0@telio.no> To: "'Hisham Khartabil'" Message-id: <00a001c5e40b$cd3171b0$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7BIT Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a way. But if user delete items from sent box , receiving MDNs don't have matching any IMs. Now, inbox and sent box in the mobile phone are not big enough, So they are often cleaned up. Xiao > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of > Hisham Khartabil > Sent: Tuesday, November 08, 2005 2:57 AM > To: Burger, Eric > Cc: simple@ietf.org > Subject: Re: [Simple] Issue 2: Sender keeps state > > I don't agree that state is needed at the client. SPAM will be solved > elsewhere. And a UAS does not need to put the actual IM in the MDN. > Often enough, the URI of the recipient of the IM is, imo, enough for > the human user to know what this MDN is for. Having said that, we > should not stop implementations from keeping state if they want to. > > Also, think of having an inbox and and sent box (just like email or sms > in your mobile phone). In those cases, the client is, soft of, keeping > state until the user deletes items from the sent box. Matching of MDNs > and IMs in this case can be done using message-id- > > Hisham > > On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > > > In MDN, the message itself keeps state. In the e-mail world, there is > > no requirement for the UAC to keep the state of messages sent. When > > the > > UAS sends a MDN, it includes the message itself so the user can figure > > out what the report is about. > > > > This has turned into a major SPAM hole. Folks send out SPAM > > masquerading as a MDN. > > > > I'd like to close this hole, which is what the draft does. However, it > > imposes the burden of the UAC keeping state of messages it sends. My > > logic is that this is a tiny price to pay to close the SPAM hole. > > > > OK with everyone? > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 07:34:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZSgb-0001Az-Eg; Tue, 08 Nov 2005 07:34:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZSgZ-0001AO-NY for simple@megatron.ietf.org; Tue, 08 Nov 2005 07:34:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02498 for ; Tue, 8 Nov 2005 07:34:19 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZSmq-0001XJ-7W for simple@ietf.org; Tue, 08 Nov 2005 07:41:16 -0500 X-IronPort-AV: i="3.97,304,1125892800"; d="scan'208"; a="22416962:sNHT41175524" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Issue 6: Consolidation Date: Tue, 8 Nov 2005 07:24:44 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664701850527@ATLANTIS.Brooktrout.com> Thread-Topic: [Simple] Issue 6: Consolidation Thread-Index: AcXj3hfHGRUM39FuQNK5JadKGoP55wASE7Yg From: "Burger, Eric" To: "Hisham Khartabil" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This would be an important decision. Everything becomes so easy if we don't have consolidation. Can we punt it? My vote is "yes." Hisham's vote is "yes." Anyone else for "yes" or "no"? -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Monday, November 07, 2005 3:59 PM To: Burger, Eric Cc: simple@ietf.org Subject: Re: [Simple] Issue 6: Consolidation Actually, some parts of the draft talks about consolidation of=20 responses and other parts of the draft say that consolidation was=20 removed from the draft. I don't like the consolidation concept, mainly=20 because it creates state in the B2BUA that is not really necessary. I think having individual MDNs delivered to the IM sender is enough. Hisham On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > The IMDN draft says that whether a B2BUA consolidates responses is a > local to the B2BUA matter. > > Should this be negotiable (via a Requires: CPIM header)? > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 07:34:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZSge-0001DR-Nr; Tue, 08 Nov 2005 07:34:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZSgb-0001Aq-0H for simple@megatron.ietf.org; Tue, 08 Nov 2005 07:34:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02510 for ; Tue, 8 Nov 2005 07:34:20 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZSmp-0001XJ-K0 for simple@ietf.org; Tue, 08 Nov 2005 07:41:15 -0500 X-IronPort-AV: i="3.97,304,1125892800"; d="scan'208"; a="22416958:sNHT41663808" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Issue 3: No date/time in IMDN Date: Tue, 8 Nov 2005 07:24:44 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664701850525@ATLANTIS.Brooktrout.com> Thread-Topic: [Simple] Issue 3: No date/time in IMDN Thread-Index: AcXjzZf8SvFUxBftQdWgSAKOXYftkwAWGpVw From: "Burger, Eric" To: "Hisham Khartabil" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org My pushback is, why bother with a data element that has no value, other than burning bits in the Ether? This is more especially so if that data element is already in the PDU two or three times? -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Monday, November 07, 2005 2:00 PM To: Burger, Eric Cc: simple@ietf.org Subject: Re: [Simple] Issue 3: No date/time in IMDN I think we need a date/time stamp, but it should be optional and a=20 disclaimer needs to be put in the draft saying that the date/time=20 cannot be trusted. Hisham On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > Since the UAS can lie, this makes the data element useless. Moreover, > CPIM, and virtually all CPIM transport protocols, already have a > date/time sent stamp. Thus the draft does not have a date/time data > element. > > OK with everyone? > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 07:34:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZSgg-0001Ej-St; Tue, 08 Nov 2005 07:34:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZSga-0001Ai-Oj for simple@megatron.ietf.org; Tue, 08 Nov 2005 07:34:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02508 for ; Tue, 8 Nov 2005 07:34:19 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZSmp-0001X7-8Q for simple@ietf.org; Tue, 08 Nov 2005 07:41:15 -0500 X-IronPort-AV: i="3.97,304,1125892800"; d="scan'208"; a="22416956:sNHT42963240" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Issue 2: Sender keeps state Date: Tue, 8 Nov 2005 07:24:43 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664701850524@ATLANTIS.Brooktrout.com> Thread-Topic: [Simple] Issue 2: Sender keeps state Thread-Index: AcXkC/+f/n2t5LLfR1WuFzQo37yv3wAGdDTw From: "Burger, Eric" To: "Xiao Wang" , "Hisham Khartabil" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The only reliable way is to have the message shipped around. However, that is a well-known SPAM attack in e-mail, and it would be microseconds before that attack would occur in IM/IMDN if we left open that opportunity. If an instant message is around a line, the Subject (summary) is the message itself... -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Xiao Wang Sent: Monday, November 07, 2005 9:26 PM To: 'Hisham Khartabil' Cc: simple@ietf.org Subject: RE: [Simple] Issue 2: Sender keeps state This is a way. But if user delete items from sent box , receiving MDNs don't have matching any IMs. Now, inbox and sent box in the mobile phone are not big enough, So they are often cleaned up. Xiao > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of > Hisham Khartabil > Sent: Tuesday, November 08, 2005 2:57 AM > To: Burger, Eric > Cc: simple@ietf.org > Subject: Re: [Simple] Issue 2: Sender keeps state >=20 > I don't agree that state is needed at the client. SPAM will be solved > elsewhere. And a UAS does not need to put the actual IM in the MDN. > Often enough, the URI of the recipient of the IM is, imo, enough for > the human user to know what this MDN is for. Having said that, we > should not stop implementations from keeping state if they want to. >=20 > Also, think of having an inbox and and sent box (just like email or sms > in your mobile phone). In those cases, the client is, soft of, keeping > state until the user deletes items from the sent box. Matching of MDNs > and IMs in this case can be done using message-id- >=20 > Hisham >=20 > On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: >=20 > > In MDN, the message itself keeps state. In the e-mail world, there is > > no requirement for the UAC to keep the state of messages sent. When > > the > > UAS sends a MDN, it includes the message itself so the user can figure > > out what the report is about. > > > > This has turned into a major SPAM hole. Folks send out SPAM > > masquerading as a MDN. > > > > I'd like to close this hole, which is what the draft does. However, it > > imposes the burden of the UAC keeping state of messages it sends. My > > logic is that this is a tiny price to pay to close the SPAM hole. > > > > OK with everyone? > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 07:34:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZSgh-0001Fc-VS; Tue, 08 Nov 2005 07:34:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZSgb-0001Bl-MQ for simple@megatron.ietf.org; Tue, 08 Nov 2005 07:34:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02512 for ; Tue, 8 Nov 2005 07:34:21 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZSml-0001X7-Om for simple@ietf.org; Tue, 08 Nov 2005 07:41:14 -0500 X-IronPort-AV: i="3.97,304,1125892800"; d="scan'208"; a="22416953:sNHT41740968" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Issue 1: End-to-End encryption Date: Tue, 8 Nov 2005 07:24:43 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664701850523@ATLANTIS.Brooktrout.com> Thread-Topic: [Simple] Issue 1: End-to-End encryption Thread-Index: AcXjzTUrf3jsBKqLS1GtIiwrKA8iQwAWFxfA From: "Burger, Eric" To: "Hisham Khartabil" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org SHOULD's require explanatory text for when you don't need to do whatever isn't a MUST. Text would be needed here. -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Monday, November 07, 2005 1:58 PM To: Burger, Eric Cc: simple@ietf.org Subject: Re: [Simple] Issue 1: End-to-End encryption I would make it a SHOULD. Hisham On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > The draft asserts that IMDN's MUST be end-to-end (S/MIME) signed at the > least, and preferably encrypted. Is this OK with everyone? > > Pro: > Only way to ensure end-to-end security > Only way to have some modicum of privacy, especially when dealing with > B2BUA's. > > Con: > Is the key infrastructure extant to enable end-to-end encryption for > EVERYONE? > Some more processing at the sender and receiver. > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 07:41:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZSgk-0001H2-56; Tue, 08 Nov 2005 07:34:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZSgc-0001Ce-V9 for simple@megatron.ietf.org; Tue, 08 Nov 2005 07:34:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02506 for ; Tue, 8 Nov 2005 07:34:19 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZSmp-0001X7-QO for simple@ietf.org; Tue, 08 Nov 2005 07:41:16 -0500 X-IronPort-AV: i="3.97,304,1125892800"; d="scan'208"; a="22416961:sNHT42277464" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Issue 5: Deleted State Date: Tue, 8 Nov 2005 07:24:44 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664701850526@ATLANTIS.Brooktrout.com> Thread-Topic: [Simple] Issue 5: Deleted State Thread-Index: AcXj3YwIdZf+AgU2Q5eEoYMpY1R4ZwASLPSQ From: "Burger, Eric" To: "Hisham Khartabil" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Good point - if I read it and delete it, the IMDN will be "read", as there is one and only one IMDN report. Read happens before Delete, so "read" it is. -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Monday, November 07, 2005 3:55 PM To: Burger, Eric Cc: simple@ietf.org Subject: Re: [Simple] Issue 5: Deleted State On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > MDN has a concept of reporting that the UAS automatically deleted the > message, versus the user deleting the message. > > The IMDN draft does not carry forward this concept, as it has not been > of much use in the real world of MDN deployment. > > Does anyone care? I don't :) I find this whole delete state useless for humans. I never=20 want anyone to know if I deleted their message or not and I think no=20 one wants to tell me either that they deleted my message. Having said=20 that, I on the fence if we should keep this deleted state in there at=20 all or not. It might be helpful for some automata applications that we=20 haven't discovered yet, but should we clutter the protocol now for=20 future applications or should we leave it for extensions? Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 09:49:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZUnO-0000VO-BN; Tue, 08 Nov 2005 09:49:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZUnM-0000V3-2f for simple@megatron.ietf.org; Tue, 08 Nov 2005 09:49:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09566 for ; Tue, 8 Nov 2005 09:49:28 -0500 (EST) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZV38-0005nY-7m for simple@ietf.org; Tue, 08 Nov 2005 10:06:17 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA8EnbjJ007325; Tue, 8 Nov 2005 16:49:46 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Nov 2005 16:49:14 +0200 Received: from [172.21.36.225] ([172.21.36.225]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Nov 2005 16:49:14 +0200 Message-ID: <4370BAE9.4060308@nokia.com> Date: Tue, 08 Nov 2005 16:49:13 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext Burger, Eric" Subject: Re: [Simple] Issue 1: End-to-End encryption References: <330A23D8336C0346B5C1A5BB196666470184FE0B@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB196666470184FE0B@ATLANTIS.Brooktrout.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2005 14:49:14.0076 (UTC) FILETIME=[961CA9C0:01C5E473] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Burger, Eric wrote: > The draft asserts that IMDN's MUST be end-to-end (S/MIME) signed at the > least, and preferably encrypted. Is this OK with everyone? Given that the message transport I know of merely states that endpoints MUST implement S/MIME but not necessarily use it, this seems like wishful thinking to me. If the original IM wasn't signed and/or encrypted, why should the IMDN be? Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 13:54:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYc0-0005CO-0b; Tue, 08 Nov 2005 13:54:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYbx-00059I-O0 for simple@megatron.ietf.org; Tue, 08 Nov 2005 13:54:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25508 for ; Tue, 8 Nov 2005 13:53:59 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYrn-0004hm-WB for simple@ietf.org; Tue, 08 Nov 2005 14:10:49 -0500 Received: from [209.52.111.175] (pp111-175.bctel.ca [209.52.111.175]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jA8IsE5j032836 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 8 Nov 2005 12:54:16 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: <330A23D8336C0346B5C1A5BB1966664701850523@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664701850523@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3A943F4E-F285-43C1-9CD3-CB44201B09F3@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Issue 1: End-to-End encryption Date: Tue, 8 Nov 2005 10:54:18 -0800 To: "Burger, Eric" X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 209.52.111.175 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I agree that these things should be SHOULD. I'd love them to be MUST, but I think that a MUST here will be summarily ignored by implementers, or just used as an excuse to ignore the spec. As far as explanatory text goes, I think we are covered if the security considerations describe the implications of not encrypting. On Nov 8, 2005, at 4:24 AM, Burger, Eric wrote: > SHOULD's require explanatory text for when you don't need to do > whatever > isn't a MUST. > > Text would be needed here. > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Monday, November 07, 2005 1:58 PM > To: Burger, Eric > Cc: simple@ietf.org > Subject: Re: [Simple] Issue 1: End-to-End encryption > > I would make it a SHOULD. > > Hisham > > On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > >> The draft asserts that IMDN's MUST be end-to-end (S/MIME) signed at > the >> least, and preferably encrypted. Is this OK with everyone? >> >> Pro: >> Only way to ensure end-to-end security >> Only way to have some modicum of privacy, especially when dealing >> with >> B2BUA's. >> >> Con: >> Is the key infrastructure extant to enable end-to-end encryption for >> EVERYONE? >> Some more processing at the sender and receiver. >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 13:54:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYc4-0005Er-V7; Tue, 08 Nov 2005 13:54:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYc3-0005Dc-9J for simple@megatron.ietf.org; Tue, 08 Nov 2005 13:54:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25519 for ; Tue, 8 Nov 2005 13:54:04 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYru-0004hy-KV for simple@ietf.org; Tue, 08 Nov 2005 14:10:55 -0500 Received: from [209.52.111.175] (pp111-175.bctel.ca [209.52.111.175]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jA8IsE5l032836 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 8 Nov 2005 12:54:27 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: <330A23D8336C0346B5C1A5BB1966664701850526@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664701850526@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65C51625-7B5B-4ECB-AD70-16C922E2145C@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Issue 5: Deleted State Date: Tue, 8 Nov 2005 10:54:35 -0800 To: "Burger, Eric" X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 209.52.111.175 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I think we can leave this as an extension. Any use case I can imagine either leaks private information, or could better be solved other ways. On Nov 8, 2005, at 4:24 AM, Burger, Eric wrote: > Good point - if I read it and delete it, the IMDN will be "read", as > there is one and only one IMDN report. Read happens before Delete, so > "read" it is. > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Monday, November 07, 2005 3:55 PM > To: Burger, Eric > Cc: simple@ietf.org > Subject: Re: [Simple] Issue 5: Deleted State > > > On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > >> MDN has a concept of reporting that the UAS automatically deleted the >> message, versus the user deleting the message. >> >> The IMDN draft does not carry forward this concept, as it has not >> been >> of much use in the real world of MDN deployment. >> >> Does anyone care? > > I don't :) I find this whole delete state useless for humans. I never > want anyone to know if I deleted their message or not and I think no > one wants to tell me either that they deleted my message. Having said > that, I on the fence if we should keep this deleted state in there at > all or not. It might be helpful for some automata applications that we > haven't discovered yet, but should we clutter the protocol now for > future applications or should we leave it for extensions? > > Hisham > >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 13:54:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYc5-0005Fu-SO; Tue, 08 Nov 2005 13:54:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYc4-0005EY-Lu for simple@megatron.ietf.org; Tue, 08 Nov 2005 13:54:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25525 for ; Tue, 8 Nov 2005 13:54:05 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYrv-0004i8-Ob for simple@ietf.org; Tue, 08 Nov 2005 14:10:56 -0500 Received: from [209.52.111.175] (pp111-175.bctel.ca [209.52.111.175]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jA8IsE5k032836 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 8 Nov 2005 12:54:23 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: <330A23D8336C0346B5C1A5BB1966664701850524@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664701850524@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Issue 2: Sender keeps state Date: Tue, 8 Nov 2005 10:54:26 -0800 To: "Burger, Eric" X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 209.52.111.175 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I think the sender should keep the state, for a couple of reasons: 1) IMs are by nature short lived. We are not talking about email lifetimes where the MDN could happen months later. 2) I think most applications are going to be impacted worse by the bandwidth issue of sending the whole message back in the IMDN than they would be by keeping state for short periods. This is also an issue when using SIP MESSAGE, due to the low size limits in RFC3428. On Nov 8, 2005, at 4:24 AM, Burger, Eric wrote: > The only reliable way is to have the message shipped around. However, > that is a well-known SPAM attack in e-mail, and it would be > microseconds > before that attack would occur in IM/IMDN if we left open that > opportunity. > > If an instant message is around a line, the Subject (summary) is the > message itself... > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf > Of Xiao Wang > Sent: Monday, November 07, 2005 9:26 PM > To: 'Hisham Khartabil' > Cc: simple@ietf.org > Subject: RE: [Simple] Issue 2: Sender keeps state > > This is a way. But if user delete items from sent box , > receiving MDNs don't have matching any IMs. > Now, inbox and sent box in the mobile phone are not big enough, > So they are often cleaned up. > > Xiao > >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf > Of >> Hisham Khartabil >> Sent: Tuesday, November 08, 2005 2:57 AM >> To: Burger, Eric >> Cc: simple@ietf.org >> Subject: Re: [Simple] Issue 2: Sender keeps state >> >> I don't agree that state is needed at the client. SPAM will be solved >> elsewhere. And a UAS does not need to put the actual IM in the MDN. >> Often enough, the URI of the recipient of the IM is, imo, enough for >> the human user to know what this MDN is for. Having said that, we >> should not stop implementations from keeping state if they want to. >> >> Also, think of having an inbox and and sent box (just like email or > sms >> in your mobile phone). In those cases, the client is, soft of, >> keeping >> state until the user deletes items from the sent box. Matching of >> MDNs >> and IMs in this case can be done using message-id- >> >> Hisham >> >> On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: >> >>> In MDN, the message itself keeps state. In the e-mail world, there > is >>> no requirement for the UAC to keep the state of messages sent. When >>> the >>> UAS sends a MDN, it includes the message itself so the user can > figure >>> out what the report is about. >>> >>> This has turned into a major SPAM hole. Folks send out SPAM >>> masquerading as a MDN. >>> >>> I'd like to close this hole, which is what the draft does. However, > it >>> imposes the burden of the UAC keeping state of messages it sends. > My >>> logic is that this is a tiny price to pay to close the SPAM hole. >>> >>> OK with everyone? >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 13:54:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYcI-0005Oo-0J; Tue, 08 Nov 2005 13:54:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYcG-0005My-CU for simple@megatron.ietf.org; Tue, 08 Nov 2005 13:54:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25543 for ; Tue, 8 Nov 2005 13:54:17 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYs7-0004ig-LK for simple@ietf.org; Tue, 08 Nov 2005 14:11:08 -0500 Received: from [209.52.111.175] (pp111-175.bctel.ca [209.52.111.175]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jA8IsE5m032836 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 8 Nov 2005 12:54:40 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: <330A23D8336C0346B5C1A5BB1966664701850525@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664701850525@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <592DDB7A-24BD-4E0B-A0E2-B8DAC0A224C4@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Issue 3: No date/time in IMDN Date: Tue, 8 Nov 2005 10:54:50 -0800 To: "Burger, Eric" X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 209.52.111.175 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org My UAS can lie, but it can also tell the truth. There are a lot of other things it can lie about that we do not leave out just because it can lie. The question to me is, is it good enough to just use the timestamp in whatever envelope or transit protocol we use? I'm on the fence here-- if I use a SIP header, it is likely to get lost across gateways. If I use a CPIM header, I require a CPIM envelope when I otherwise might not have needed one--which adds size. So, I think I am slightly leaning towards including an _optional_ timestamp in the IMDN schema. On Nov 8, 2005, at 4:24 AM, Burger, Eric wrote: > My pushback is, why bother with a data element that has no value, > other > than burning bits in the Ether? This is more especially so if that > data > element is already in the PDU two or three times? > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Monday, November 07, 2005 2:00 PM > To: Burger, Eric > Cc: simple@ietf.org > Subject: Re: [Simple] Issue 3: No date/time in IMDN > > I think we need a date/time stamp, but it should be optional and a > disclaimer needs to be put in the draft saying that the date/time > cannot be trusted. > > Hisham > > On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > >> Since the UAS can lie, this makes the data element useless. >> Moreover, >> CPIM, and virtually all CPIM transport protocols, already have a >> date/time sent stamp. Thus the draft does not have a date/time data >> element. >> >> OK with everyone? >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 13:54:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYcS-0005Vy-VO; Tue, 08 Nov 2005 13:54:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYcR-0005Vt-HG for simple@megatron.ietf.org; Tue, 08 Nov 2005 13:54:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25561 for ; Tue, 8 Nov 2005 13:54:28 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYsI-0004j5-Qx for simple@ietf.org; Tue, 08 Nov 2005 14:11:19 -0500 Received: from [209.52.111.175] (pp111-175.bctel.ca [209.52.111.175]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jA8IsE5n032836 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 8 Nov 2005 12:54:51 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: <330A23D8336C0346B5C1A5BB1966664701850527@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664701850527@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Issue 6: Consolidation Date: Tue, 8 Nov 2005 10:55:01 -0800 To: "Burger, Eric" X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 209.52.111.175 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Does consolidation need to be standardized? If we don't say anything about consolidation, do we prevent a list-exploder from consolidating as a matter of local policy? On Nov 8, 2005, at 4:24 AM, Burger, Eric wrote: > This would be an important decision. Everything becomes so easy if we > don't have consolidation. > > Can we punt it? My vote is "yes." Hisham's vote is "yes." Anyone > else > for "yes" or "no"? > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Monday, November 07, 2005 3:59 PM > To: Burger, Eric > Cc: simple@ietf.org > Subject: Re: [Simple] Issue 6: Consolidation > > Actually, some parts of the draft talks about consolidation of > responses and other parts of the draft say that consolidation was > removed from the draft. I don't like the consolidation concept, mainly > because it creates state in the B2BUA that is not really necessary. > > I think having individual MDNs delivered to the IM sender is enough. > > Hisham > > > On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > >> The IMDN draft says that whether a B2BUA consolidates responses is a >> local to the B2BUA matter. >> >> Should this be negotiable (via a Requires: CPIM header)? >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 13:55:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYcd-0005YO-Mv; Tue, 08 Nov 2005 13:55:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYcc-0005YH-2v for simple@megatron.ietf.org; Tue, 08 Nov 2005 13:55:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25577 for ; Tue, 8 Nov 2005 13:54:39 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYsT-0004jX-AZ for simple@ietf.org; Tue, 08 Nov 2005 14:11:29 -0500 Received: from [209.52.111.175] (pp111-175.bctel.ca [209.52.111.175]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jA8IsE5o032836 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 8 Nov 2005 12:55:02 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: <9341b1e8843d57ca57829a1134a1ff67@telio.no> References: <330A23D8336C0346B5C1A5BB196666470184FE0F@ATLANTIS.Brooktrout.com> <9341b1e8843d57ca57829a1134a1ff67@telio.no> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <271202E6-5FE0-4D23-AE2D-3243A55B195D@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Issue 4: Recipient of IMDN can appear different than sender Date: Tue, 8 Nov 2005 10:55:10 -0800 To: Hisham Khartabil X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 209.52.111.175 is authenticated by a trusted mechanism) X-Spam-Score: 1.2 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: "Burger, Eric" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I actually lean towards not having a separate notification-to header. I think it creates more problems than value. On Nov 7, 2005, at 11:05 AM, Hisham Khartabil wrote: > I think having that header is ok. But the reason you give about > keeping state out of the B2BUAs and relays is not a good reason. > Often enough B2BUAs need to be involved in the MDN generation, but > thats a topic for a different thread. > > Hisham > > On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > >> To enable scenarios where the "sender" of an IM has a generic >> address, >> like "sip:info@example.com", but the user sending the IM has a >> specific >> address, like "sip:agent24@agentpool.example.com", as well as to keep >> state out of B2BUA's and relays, the draft has an explicit >> Disposition-Notification-To header, with the address for the UAS >> to send >> the report to. >> >> This has the potential for a bad UAC to IMDN-bomb an unsuspecting >> third-party. Thus the draft has a bunch of protocol machinery for >> the >> UAS to ensure identity of the requestor, if only to enable Level 8 >> handling of the problem. >> >> OK with everyone? >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 14:19:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZ0U-0004xL-Tk; Tue, 08 Nov 2005 14:19:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZ0S-0004wa-N1 for simple@megatron.ietf.org; Tue, 08 Nov 2005 14:19:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27235 for ; Tue, 8 Nov 2005 14:19:17 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZZGK-0005Uf-8P for simple@ietf.org; Tue, 08 Nov 2005 14:36:08 -0500 Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 0891C19446E for ; Tue, 8 Nov 2005 20:19:35 +0100 (CET) Received: from [209.52.109.174] ([192.168.3.102]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Nov 2005 20:22:59 +0100 In-Reply-To: <71D70C9A-425C-4DBE-A241-42755692612E@nostrum.com> References: <330A23D8336C0346B5C1A5BB1966664701850524@ATLANTIS.Brooktrout.com> <71D70C9A-425C-4DBE-A241-42755692612E@nostrum.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <450db1e2eadca673b3734f457b2440ba@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Issue 2: Sender keeps state Date: Tue, 8 Nov 2005 20:18:57 +0100 To: Ben Campbell X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 08 Nov 2005 19:22:59.0953 (UTC) FILETIME=[D4B29610:01C5E499] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Cc: "Burger, Eric" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Nov 8, 2005, at 7:20 PM, Ben Campbell wrote: > I think the sender should keep the state, for a couple of reasons: > > 1) IMs are by nature short lived. We are not talking about email > lifetimes where the MDN could happen months later. Keep in mind we are talking about read reports, not just delivery. Sure the IM is short lived, but that doesnt mean I have to read it immediately. > 2) I think most applications are going to be impacted worse by the > bandwidth issue of sending the whole message back in the IMDN than > they would be by keeping state for short periods. This is also an > issue when using SIP MESSAGE, due to the low size limits in RFC3428. How does your phone work today with SMS? It does not need any correlation information between the receipt reports and the messages in the sent box. Your email client is the same, if there is a match of the message-id, great. If there is not, the delivery report is stand alone and it leaves it for the human user to correlate the MDN and the message. Hisham > > On Nov 8, 2005, at 4:24 AM, Burger, Eric wrote: > >> The only reliable way is to have the message shipped around. However, >> that is a well-known SPAM attack in e-mail, and it would be >> microseconds >> before that attack would occur in IM/IMDN if we left open that >> opportunity. >> >> If an instant message is around a line, the Subject (summary) is the >> message itself... >> >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >> Behalf >> Of Xiao Wang >> Sent: Monday, November 07, 2005 9:26 PM >> To: 'Hisham Khartabil' >> Cc: simple@ietf.org >> Subject: RE: [Simple] Issue 2: Sender keeps state >> >> This is a way. But if user delete items from sent box , >> receiving MDNs don't have matching any IMs. >> Now, inbox and sent box in the mobile phone are not big enough, >> So they are often cleaned up. >> >> Xiao >> >>> -----Original Message----- >>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >> Behalf >> Of >>> Hisham Khartabil >>> Sent: Tuesday, November 08, 2005 2:57 AM >>> To: Burger, Eric >>> Cc: simple@ietf.org >>> Subject: Re: [Simple] Issue 2: Sender keeps state >>> >>> I don't agree that state is needed at the client. SPAM will be solved >>> elsewhere. And a UAS does not need to put the actual IM in the MDN. >>> Often enough, the URI of the recipient of the IM is, imo, enough for >>> the human user to know what this MDN is for. Having said that, we >>> should not stop implementations from keeping state if they want to. >>> >>> Also, think of having an inbox and and sent box (just like email or >> sms >>> in your mobile phone). In those cases, the client is, soft of, >>> keeping >>> state until the user deletes items from the sent box. Matching of >>> MDNs >>> and IMs in this case can be done using message-id- >>> >>> Hisham >>> >>> On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: >>> >>>> In MDN, the message itself keeps state. In the e-mail world, there >> is >>>> no requirement for the UAC to keep the state of messages sent. When >>>> the >>>> UAS sends a MDN, it includes the message itself so the user can >> figure >>>> out what the report is about. >>>> >>>> This has turned into a major SPAM hole. Folks send out SPAM >>>> masquerading as a MDN. >>>> >>>> I'd like to close this hole, which is what the draft does. However, >> it >>>> imposes the burden of the UAC keeping state of messages it sends. >> My >>>> logic is that this is a tiny price to pay to close the SPAM hole. >>>> >>>> OK with everyone? >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 14:22:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZ37-0005gg-UA; Tue, 08 Nov 2005 14:22:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZ36-0005fo-6s for simple@megatron.ietf.org; Tue, 08 Nov 2005 14:22:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27376 for ; Tue, 8 Nov 2005 14:22:01 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZZIx-0005ZE-TT for simple@ietf.org; Tue, 08 Nov 2005 14:38:52 -0500 Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id C796319446E for ; Tue, 8 Nov 2005 20:22:18 +0100 (CET) Received: from [209.52.109.174] ([192.168.3.102]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Nov 2005 20:25:43 +0100 In-Reply-To: <53EFCF8C-74F9-41F5-B9A1-427A55EB51B6@nostrum.com> References: <330A23D8336C0346B5C1A5BB1966664701850527@ATLANTIS.Brooktrout.com> <53EFCF8C-74F9-41F5-B9A1-427A55EB51B6@nostrum.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Issue 6: Consolidation Date: Tue, 8 Nov 2005 20:21:43 +0100 To: Ben Campbell X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 08 Nov 2005 19:25:43.0769 (UTC) FILETIME=[3656EC90:01C5E49A] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: "Burger, Eric" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org You would need to standardise the XML schema that carries the collected MDNs. Also, not subject to standardisation, you need the relay (exploder) to keep state for x units of time. Hisham On Nov 8, 2005, at 7:35 PM, Ben Campbell wrote: > Does consolidation need to be standardized? If we don't say anything > about consolidation, do we prevent a list-exploder from consolidating > as a matter of local policy? > > On Nov 8, 2005, at 4:24 AM, Burger, Eric wrote: > >> This would be an important decision. Everything becomes so easy if we >> don't have consolidation. >> >> Can we punt it? My vote is "yes." Hisham's vote is "yes." Anyone >> else >> for "yes" or "no"? >> >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Monday, November 07, 2005 3:59 PM >> To: Burger, Eric >> Cc: simple@ietf.org >> Subject: Re: [Simple] Issue 6: Consolidation >> >> Actually, some parts of the draft talks about consolidation of >> responses and other parts of the draft say that consolidation was >> removed from the draft. I don't like the consolidation concept, mainly >> because it creates state in the B2BUA that is not really necessary. >> >> I think having individual MDNs delivered to the IM sender is enough. >> >> Hisham >> >> >> On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: >> >>> The IMDN draft says that whether a B2BUA consolidates responses is a >>> local to the B2BUA matter. >>> >>> Should this be negotiable (via a Requires: CPIM header)? >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 16:55:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbQq-0004PU-Po; Tue, 08 Nov 2005 16:55:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbQp-0004PM-LV for simple@megatron.ietf.org; Tue, 08 Nov 2005 16:55:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08370 for ; Tue, 8 Nov 2005 16:54:39 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZbgh-0002AL-NC for simple@ietf.org; Tue, 08 Nov 2005 17:11:32 -0500 X-IronPort-AV: i="3.97,305,1125892800"; d="scan'208"; a="22447045:sNHT42102072" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Issue 1: End-to-End encryption Date: Tue, 8 Nov 2005 16:51:55 -0500 Message-ID: <330A23D8336C0346B5C1A5BB19666647018A7AD4@ATLANTIS.Brooktrout.com> Thread-Topic: [Simple] Issue 1: End-to-End encryption Thread-Index: AcXkldYEXUtxh8d1QrG3rqKQd42LaQAFpi7Q From: "Burger, Eric" To: "Ben Campbell" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org So the text should read something like "The UAS SHOULD encrypt the IMDN, unless it doesn't feel like it."? But seriously, who gets to chose? I care about security. I send a message, requesting an IMDN. The UAS is lazy and doesn't care about security and sends a clear text IMDN. I get pissed off. Conversely, I don't care about security, I send a message, requesting an IMDN. The UAS was written by someone in the Security Directorate, and uses strong encryption. I have to spend cycles to decrypt the message. On the other hand, I don't care about security and I somehow mark the message to be in plain text. I send a message, requesting and IMDN. The UAS honors the request, which pisses off the UAS' user, because now their information is in clear text. So, if we don't go the simple route of all IMDN's are encrypted, we should have: o A mechanism to let the sender insist on encrypted IMDN o A mechanism to let the sender insist on unencrypted IMDN o A mechanism to inform the sender if their request cannot be honored -----Original Message----- From: Ben Campbell [mailto:ben@estacado.net]=20 Sent: Tuesday, November 08, 2005 1:54 PM To: Burger, Eric Cc: Hisham Khartabil; simple@ietf.org Subject: Re: [Simple] Issue 1: End-to-End encryption I agree that these things should be SHOULD. I'd love them to be MUST, =20 but I think that a MUST here will be summarily ignored by =20 implementers, or just used as an excuse to ignore the spec. As far as explanatory text goes, I think we are covered if the =20 security considerations describe the implications of not encrypting. On Nov 8, 2005, at 4:24 AM, Burger, Eric wrote: > SHOULD's require explanatory text for when you don't need to do =20 > whatever > isn't a MUST. > > Text would be needed here. > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Monday, November 07, 2005 1:58 PM > To: Burger, Eric > Cc: simple@ietf.org > Subject: Re: [Simple] Issue 1: End-to-End encryption > > I would make it a SHOULD. > > Hisham > > On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: > >> The draft asserts that IMDN's MUST be end-to-end (S/MIME) signed at > the >> least, and preferably encrypted. Is this OK with everyone? >> >> Pro: >> Only way to ensure end-to-end security >> Only way to have some modicum of privacy, especially when dealing =20 >> with >> B2BUA's. >> >> Con: >> Is the key infrastructure extant to enable end-to-end encryption for >> EVERYONE? >> Some more processing at the sender and receiver. >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 17:07:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbce-0007he-Kt; Tue, 08 Nov 2005 17:07:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbcd-0007hX-8F for simple@megatron.ietf.org; Tue, 08 Nov 2005 17:07:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08993 for ; Tue, 8 Nov 2005 17:06:51 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZbsW-0002Sh-2M for simple@ietf.org; Tue, 08 Nov 2005 17:23:44 -0500 Received: from [209.52.111.175] (pp111-175.bctel.ca [209.52.111.175]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jA8M77gV050018 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 8 Nov 2005 16:07:11 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: <330A23D8336C0346B5C1A5BB19666647018A7AD4@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB19666647018A7AD4@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <22153377-0D2B-47AA-9E77-3D0E3CB6C04F@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Issue 1: End-to-End encryption Date: Tue, 8 Nov 2005 14:07:11 -0800 To: "Burger, Eric" X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 209.52.111.175 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Nov 8, 2005, at 1:51 PM, Burger, Eric wrote: > So the text should read something like > > "The UAS SHOULD encrypt the IMDN, unless it doesn't feel like it."? > Something more like "SHOULD encrypt, unless it determines that the cost of doing so outweighs its need for privacy, or it just can't encrypt because it does not have the necessary cert". I know that is not very satisfying, but from a pragmatic position, lots of deployers are going to ignore this even if it says MUST. > But seriously, who gets to chose? I care about security. I send a > message, requesting an IMDN. The UAS is lazy and doesn't care about > security and sends a clear text IMDN. I get pissed off. > > Conversely, I don't care about security, I send a message, > requesting an > IMDN. The UAS was written by someone in the Security Directorate, and > uses strong encryption. I have to spend cycles to decrypt the > message. > > On the other hand, I don't care about security and I somehow mark the > message to be in plain text. I send a message, requesting and IMDN. > The UAS honors the request, which pisses off the UAS' user, because > now > their information is in clear text. > > So, if we don't go the simple route of all IMDN's are encrypted, we > should have: > o A mechanism to let the sender insist on encrypted IMDN Agreed. > o A mechanism to let the sender insist on unencrypted IMDN > o A mechanism to inform the sender if their request cannot be > honored On the last two: Currently the UAS can refuse to send an IMDN for any reason, without explanation, right? Why is this different? > -----Original Message----- > From: Ben Campbell [mailto:ben@estacado.net] > Sent: Tuesday, November 08, 2005 1:54 PM > To: Burger, Eric > Cc: Hisham Khartabil; simple@ietf.org > Subject: Re: [Simple] Issue 1: End-to-End encryption > > I agree that these things should be SHOULD. I'd love them to be MUST, > but I think that a MUST here will be summarily ignored by > implementers, or just used as an excuse to ignore the spec. > > As far as explanatory text goes, I think we are covered if the > security considerations describe the implications of not encrypting. > > On Nov 8, 2005, at 4:24 AM, Burger, Eric wrote: > >> SHOULD's require explanatory text for when you don't need to do >> whatever >> isn't a MUST. >> >> Text would be needed here. >> >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Monday, November 07, 2005 1:58 PM >> To: Burger, Eric >> Cc: simple@ietf.org >> Subject: Re: [Simple] Issue 1: End-to-End encryption >> >> I would make it a SHOULD. >> >> Hisham >> >> On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: >> >>> The draft asserts that IMDN's MUST be end-to-end (S/MIME) signed at >> the >>> least, and preferably encrypted. Is this OK with everyone? >>> >>> Pro: >>> Only way to ensure end-to-end security >>> Only way to have some modicum of privacy, especially when dealing >>> with >>> B2BUA's. >>> >>> Con: >>> Is the key infrastructure extant to enable end-to-end encryption for >>> EVERYONE? >>> Some more processing at the sender and receiver. >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 17:18:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbnh-0001vR-6M; Tue, 08 Nov 2005 17:18:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbne-0001vF-JE for simple@megatron.ietf.org; Tue, 08 Nov 2005 17:18:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09559 for ; Tue, 8 Nov 2005 17:18:14 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZc3X-0002ih-Ex for simple@ietf.org; Tue, 08 Nov 2005 17:35:08 -0500 Received: from [209.52.111.175] (pp111-175.bctel.ca [209.52.111.175]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jA8MIQdN051204 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 8 Nov 2005 16:18:36 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: <450db1e2eadca673b3734f457b2440ba@telio.no> References: <330A23D8336C0346B5C1A5BB1966664701850524@ATLANTIS.Brooktrout.com> <71D70C9A-425C-4DBE-A241-42755692612E@nostrum.com> <450db1e2eadca673b3734f457b2440ba@telio.no> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <003DDF36-B190-4809-9F8F-5B17B9493F8F@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Issue 2: Sender keeps state Date: Tue, 8 Nov 2005 14:18:31 -0800 To: Hisham Khartabil X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 209.52.111.175 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit Cc: "Burger, Eric" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Nov 8, 2005, at 11:18 AM, Hisham Khartabil wrote: > > On Nov 8, 2005, at 7:20 PM, Ben Campbell wrote: > >> I think the sender should keep the state, for a couple of reasons: >> >> 1) IMs are by nature short lived. We are not talking about email >> lifetimes where the MDN could happen months later. > > Keep in mind we are talking about read reports, not just delivery. > Sure the IM is short lived, but that doesnt mean I have to read it > immediately. > My point is that if I send you an IM and request a read-report, and don't get a report back in a fairly short period of time, I am going to give up. If we expect people to wait indefinitely, then I start to wonder why we don't just use email. >> 2) I think most applications are going to be impacted worse by the >> bandwidth issue of sending the whole message back in the IMDN than >> they would be by keeping state for short periods. This is also an >> issue when using SIP MESSAGE, due to the low size limits in RFC3428. > > How does your phone work today with SMS? It does not need any > correlation information between the receipt reports and the > messages in the sent box. Your email client is the same, if there > is a match of the message-id, great. If there is not, the delivery > report is stand alone and it leaves it for the human user to > correlate the MDN and the message. My SMS client doesn't do receipt requests. But my old phone did. On that one, I just got back something saying that message to X was delivered. I I had more than one messages to X, I could not tell which one. Certainly, it can do that without keeping state. I guess I support saying that the UAC should have the option of not keeping state, but it will not be able to provide much info to the user if it doesn't. But I don't want to require the UAS to include a lot of information in the IMDN to make life easier on a stateless UAC. > > Hisham > >> >> On Nov 8, 2005, at 4:24 AM, Burger, Eric wrote: >> >>> The only reliable way is to have the message shipped around. >>> However, >>> that is a well-known SPAM attack in e-mail, and it would be >>> microseconds >>> before that attack would occur in IM/IMDN if we left open that >>> opportunity. >>> >>> If an instant message is around a line, the Subject (summary) is the >>> message itself... >>> >>> -----Original Message----- >>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>> Behalf >>> Of Xiao Wang >>> Sent: Monday, November 07, 2005 9:26 PM >>> To: 'Hisham Khartabil' >>> Cc: simple@ietf.org >>> Subject: RE: [Simple] Issue 2: Sender keeps state >>> >>> This is a way. But if user delete items from sent box , >>> receiving MDNs don't have matching any IMs. >>> Now, inbox and sent box in the mobile phone are not big enough, >>> So they are often cleaned up. >>> >>> Xiao >>> >>>> -----Original Message----- >>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>> Behalf >>> Of >>>> Hisham Khartabil >>>> Sent: Tuesday, November 08, 2005 2:57 AM >>>> To: Burger, Eric >>>> Cc: simple@ietf.org >>>> Subject: Re: [Simple] Issue 2: Sender keeps state >>>> >>>> I don't agree that state is needed at the client. SPAM will be >>>> solved >>>> elsewhere. And a UAS does not need to put the actual IM in the MDN. >>>> Often enough, the URI of the recipient of the IM is, imo, enough >>>> for >>>> the human user to know what this MDN is for. Having said that, we >>>> should not stop implementations from keeping state if they want to. >>>> >>>> Also, think of having an inbox and and sent box (just like email or >>> sms >>>> in your mobile phone). In those cases, the client is, soft of, >>>> keeping >>>> state until the user deletes items from the sent box. Matching >>>> of MDNs >>>> and IMs in this case can be done using message-id- >>>> >>>> Hisham >>>> >>>> On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: >>>> >>>>> In MDN, the message itself keeps state. In the e-mail world, >>>>> there >>> is >>>>> no requirement for the UAC to keep the state of messages sent. >>>>> When >>>>> the >>>>> UAS sends a MDN, it includes the message itself so the user can >>> figure >>>>> out what the report is about. >>>>> >>>>> This has turned into a major SPAM hole. Folks send out SPAM >>>>> masquerading as a MDN. >>>>> >>>>> I'd like to close this hole, which is what the draft does. >>>>> However, >>> it >>>>> imposes the burden of the UAC keeping state of messages it sends. >>> My >>>>> logic is that this is a tiny price to pay to close the SPAM hole. >>>>> >>>>> OK with everyone? >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 17:31:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZc0N-00063N-Ms; Tue, 08 Nov 2005 17:31:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZc0M-00062p-HD for simple@megatron.ietf.org; Tue, 08 Nov 2005 17:31:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10362 for ; Tue, 8 Nov 2005 17:31:24 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZcGD-00033d-Ec for simple@ietf.org; Tue, 08 Nov 2005 17:48:16 -0500 Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id D1D4F19446E for ; Tue, 8 Nov 2005 23:31:32 +0100 (CET) Received: from [209.52.109.174] ([192.168.3.109]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Nov 2005 23:32:53 +0100 In-Reply-To: <003DDF36-B190-4809-9F8F-5B17B9493F8F@estacado.net> References: <330A23D8336C0346B5C1A5BB1966664701850524@ATLANTIS.Brooktrout.com> <71D70C9A-425C-4DBE-A241-42755692612E@nostrum.com> <450db1e2eadca673b3734f457b2440ba@telio.no> <003DDF36-B190-4809-9F8F-5B17B9493F8F@estacado.net> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <457247375ef5073257dec0bc82e0ffd2@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Issue 2: Sender keeps state Date: Tue, 8 Nov 2005 23:28:33 +0100 To: Ben Campbell X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 08 Nov 2005 22:32:57.0481 (UTC) FILETIME=[5E275790:01C5E4B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: 7bit Cc: "Burger, Eric" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Nov 8, 2005, at 11:18 PM, Ben Campbell wrote: > > On Nov 8, 2005, at 11:18 AM, Hisham Khartabil wrote: > >> >> On Nov 8, 2005, at 7:20 PM, Ben Campbell wrote: >> >>> I think the sender should keep the state, for a couple of reasons: >>> >>> 1) IMs are by nature short lived. We are not talking about email >>> lifetimes where the MDN could happen months later. >> >> Keep in mind we are talking about read reports, not just delivery. >> Sure the IM is short lived, but that doesnt mean I have to read it >> immediately. >> > > My point is that if I send you an IM and request a read-report, and > don't get a report back in a fairly short period of time, I am going > to give up. If we expect people to wait indefinitely, then I start to > wonder why we don't just use email. > >>> 2) I think most applications are going to be impacted worse by the >>> bandwidth issue of sending the whole message back in the IMDN than >>> they would be by keeping state for short periods. This is also an >>> issue when using SIP MESSAGE, due to the low size limits in RFC3428. >> >> How does your phone work today with SMS? It does not need any >> correlation information between the receipt reports and the messages >> in the sent box. Your email client is the same, if there is a match >> of the message-id, great. If there is not, the delivery report is >> stand alone and it leaves it for the human user to correlate the MDN >> and the message. > > My SMS client doesn't do receipt requests. But my old phone did. On > that one, I just got back something saying that message to X was > delivered. I I had more than one messages to X, I could not tell which > one. Certainly, it can do that without keeping state. That's all I'm asking for. > I guess I support saying that the UAC should have the option of not > keeping state, but it will not be able to provide much info to the > user if it doesn't. But I don't want to require the UAS to include a > lot of information in the IMDN to make life easier on a stateless UAC. Agreed. Hisham > > > >> >> Hisham >> >>> >>> On Nov 8, 2005, at 4:24 AM, Burger, Eric wrote: >>> >>>> The only reliable way is to have the message shipped around. >>>> However, >>>> that is a well-known SPAM attack in e-mail, and it would be >>>> microseconds >>>> before that attack would occur in IM/IMDN if we left open that >>>> opportunity. >>>> >>>> If an instant message is around a line, the Subject (summary) is the >>>> message itself... >>>> >>>> -----Original Message----- >>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>>> Behalf >>>> Of Xiao Wang >>>> Sent: Monday, November 07, 2005 9:26 PM >>>> To: 'Hisham Khartabil' >>>> Cc: simple@ietf.org >>>> Subject: RE: [Simple] Issue 2: Sender keeps state >>>> >>>> This is a way. But if user delete items from sent box , >>>> receiving MDNs don't have matching any IMs. >>>> Now, inbox and sent box in the mobile phone are not big enough, >>>> So they are often cleaned up. >>>> >>>> Xiao >>>> >>>>> -----Original Message----- >>>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>>> Behalf >>>> Of >>>>> Hisham Khartabil >>>>> Sent: Tuesday, November 08, 2005 2:57 AM >>>>> To: Burger, Eric >>>>> Cc: simple@ietf.org >>>>> Subject: Re: [Simple] Issue 2: Sender keeps state >>>>> >>>>> I don't agree that state is needed at the client. SPAM will be >>>>> solved >>>>> elsewhere. And a UAS does not need to put the actual IM in the MDN. >>>>> Often enough, the URI of the recipient of the IM is, imo, enough >>>>> for >>>>> the human user to know what this MDN is for. Having said that, we >>>>> should not stop implementations from keeping state if they want to. >>>>> >>>>> Also, think of having an inbox and and sent box (just like email or >>>> sms >>>>> in your mobile phone). In those cases, the client is, soft of, >>>>> keeping >>>>> state until the user deletes items from the sent box. Matching of >>>>> MDNs >>>>> and IMs in this case can be done using message-id- >>>>> >>>>> Hisham >>>>> >>>>> On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: >>>>> >>>>>> In MDN, the message itself keeps state. In the e-mail world, >>>>>> there >>>> is >>>>>> no requirement for the UAC to keep the state of messages sent. >>>>>> When >>>>>> the >>>>>> UAS sends a MDN, it includes the message itself so the user can >>>> figure >>>>>> out what the report is about. >>>>>> >>>>>> This has turned into a major SPAM hole. Folks send out SPAM >>>>>> masquerading as a MDN. >>>>>> >>>>>> I'd like to close this hole, which is what the draft does. >>>>>> However, >>>> it >>>>>> imposes the burden of the UAC keeping state of messages it sends. >>>> My >>>>>> logic is that this is a tiny price to pay to close the SPAM hole. >>>>>> >>>>>> OK with everyone? >>>>>> >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 17:39:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZc7W-0000YQ-7V; Tue, 08 Nov 2005 17:39:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZc7U-0000Xu-Ah for simple@megatron.ietf.org; Tue, 08 Nov 2005 17:39:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10996 for ; Tue, 8 Nov 2005 17:38:46 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZcNK-0003KV-Mg for simple@ietf.org; Tue, 08 Nov 2005 17:55:38 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA8MYg0X018544; Wed, 9 Nov 2005 00:34:43 +0200 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Nov 2005 00:39:01 +0200 Received: from [10.162.253.12] ([10.162.253.12]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Nov 2005 00:39:00 +0200 Message-ID: <43712903.3090500@nokia.com> Date: Wed, 09 Nov 2005 00:38:59 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Ben Campbell Subject: Re: [Simple] Issue 1: End-to-End encryption References: <330A23D8336C0346B5C1A5BB19666647018A7AD4@ATLANTIS.Brooktrout.com> <22153377-0D2B-47AA-9E77-3D0E3CB6C04F@estacado.net> In-Reply-To: <22153377-0D2B-47AA-9E77-3D0E3CB6C04F@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2005 22:39:00.0251 (UTC) FILETIME=[3661A6B0:01C5E4B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: "Burger, Eric" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Ben Campbell wrote: >> So, if we don't go the simple route of all IMDN's are encrypted, we >> should have: >> o A mechanism to let the sender insist on encrypted IMDN > > Agreed. Huh?? You don't currently have any way of insisting that replies are encrypted, and those actually contain sensitive data (in most cases). Why don't you simply say that if the message was encrypted, you need to encrypt the IMDN. Don't over-engineer this. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 18:23:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZcoG-0007Gs-Jp; Tue, 08 Nov 2005 18:23:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZcoF-0007Gn-Em for simple@megatron.ietf.org; Tue, 08 Nov 2005 18:23:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13144 for ; Tue, 8 Nov 2005 18:22:57 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZd48-0004Ox-B8 for simple@ietf.org; Tue, 08 Nov 2005 18:39:49 -0500 Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 8E63119446E for ; Wed, 9 Nov 2005 00:23:12 +0100 (CET) Received: from [209.52.109.174] ([192.168.3.104]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Nov 2005 00:26:37 +0100 In-Reply-To: <43712903.3090500@nokia.com> References: <330A23D8336C0346B5C1A5BB19666647018A7AD4@ATLANTIS.Brooktrout.com> <22153377-0D2B-47AA-9E77-3D0E3CB6C04F@estacado.net> <43712903.3090500@nokia.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <12703564da133b3e9ceed503977c8e15@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Issue 1: End-to-End encryption Date: Wed, 9 Nov 2005 00:22:23 +0100 To: Aki Niemi X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 08 Nov 2005 23:26:38.0002 (UTC) FILETIME=[DDBBD920:01C5E4BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: "Burger, Eric" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Nov 8, 2005, at 11:38 PM, Aki Niemi wrote: > > > ext Ben Campbell wrote: >>> So, if we don't go the simple route of all IMDN's are encrypted, we >>> should have: >>> o A mechanism to let the sender insist on encrypted IMDN >> Agreed. > > Huh?? You don't currently have any way of insisting that replies are > encrypted, and those actually contain sensitive data (in most cases). > > Why don't you simply say that if the message was encrypted, you need > to encrypt the IMDN. Don't over-engineer this. I like that, you make the MDN as secure as IM it is for. Hisham > > Cheers, > Aki > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 18:36:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZd11-0003Wf-L9; Tue, 08 Nov 2005 18:36:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZd10-0003WX-IA for simple@megatron.ietf.org; Tue, 08 Nov 2005 18:36:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13685 for ; Tue, 8 Nov 2005 18:36:08 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZdGt-0004fu-7G for simple@ietf.org; Tue, 08 Nov 2005 18:53:00 -0500 Received: from [209.52.111.175] (pp111-175.bctel.ca [209.52.111.175]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jA8NaF8l058058 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 8 Nov 2005 17:36:21 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: References: <330A23D8336C0346B5C1A5BB1966664701850527@ATLANTIS.Brooktrout.com> <53EFCF8C-74F9-41F5-B9A1-427A55EB51B6@nostrum.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Issue 6: Consolidation Date: Tue, 8 Nov 2005 15:36:18 -0800 To: Hisham Khartabil X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 209.52.111.175 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: "Burger, Eric" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I think that, given all that has been said, I agree that consolidation should go. Thanks! Ben. On Nov 8, 2005, at 11:21 AM, Hisham Khartabil wrote: > You would need to standardise the XML schema that carries the > collected MDNs. > > Also, not subject to standardisation, you need the relay (exploder) > to keep state for x units of time. > > Hisham > On Nov 8, 2005, at 7:35 PM, Ben Campbell wrote: > >> Does consolidation need to be standardized? If we don't say >> anything about consolidation, do we prevent a list-exploder from >> consolidating as a matter of local policy? >> >> On Nov 8, 2005, at 4:24 AM, Burger, Eric wrote: >> >>> This would be an important decision. Everything becomes so easy >>> if we >>> don't have consolidation. >>> >>> Can we punt it? My vote is "yes." Hisham's vote is "yes." >>> Anyone else >>> for "yes" or "no"? >>> >>> -----Original Message----- >>> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >>> Sent: Monday, November 07, 2005 3:59 PM >>> To: Burger, Eric >>> Cc: simple@ietf.org >>> Subject: Re: [Simple] Issue 6: Consolidation >>> >>> Actually, some parts of the draft talks about consolidation of >>> responses and other parts of the draft say that consolidation was >>> removed from the draft. I don't like the consolidation concept, >>> mainly >>> because it creates state in the B2BUA that is not really necessary. >>> >>> I think having individual MDNs delivered to the IM sender is enough. >>> >>> Hisham >>> >>> >>> On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: >>> >>>> The IMDN draft says that whether a B2BUA consolidates responses >>>> is a >>>> local to the B2BUA matter. >>>> >>>> Should this be negotiable (via a Requires: CPIM header)? >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 19:32:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZdsv-0003r1-Et; Tue, 08 Nov 2005 19:32:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZdsu-0003qw-N8 for simple@megatron.ietf.org; Tue, 08 Nov 2005 19:32:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28075 for ; Tue, 8 Nov 2005 19:31:49 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZe8o-0001cY-Ao for simple@ietf.org; Tue, 08 Nov 2005 19:48:42 -0500 X-IronPort-AV: i="3.97,306,1125892800"; d="scan'208"; a="22452397:sNHT41651640" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Issue 1: End-to-End encryption Date: Tue, 8 Nov 2005 19:32:12 -0500 Message-ID: <330A23D8336C0346B5C1A5BB19666647018A7BDE@ATLANTIS.Brooktrout.com> Thread-Topic: [Simple] Issue 1: End-to-End encryption Thread-Index: AcXku2h+0hetiHG3ThOZvqysG0GQPwACWmmA From: "Burger, Eric" To: "Hisham Khartabil" , "Aki Niemi" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I like that idea (if inbound is encrypted, IMDN is encrypted), too. Also, on Ben's point, yes, the UAS can ignore for any reason. However, my idea is the UAC has a Requires: imdn.secure header, so the UAS can reject immediately to let the sender know that they will never get a secure IMDN. -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Tuesday, November 08, 2005 6:22 PM To: Aki Niemi Cc: ext Ben Campbell; Burger, Eric; simple@ietf.org Subject: Re: [Simple] Issue 1: End-to-End encryption On Nov 8, 2005, at 11:38 PM, Aki Niemi wrote: > > > ext Ben Campbell wrote: >>> So, if we don't go the simple route of all IMDN's are encrypted, we >>> should have: >>> o A mechanism to let the sender insist on encrypted IMDN >> Agreed. > > Huh?? You don't currently have any way of insisting that replies are=20 > encrypted, and those actually contain sensitive data (in most cases). > > Why don't you simply say that if the message was encrypted, you need=20 > to encrypt the IMDN. Don't over-engineer this. I like that, you make the MDN as secure as IM it is for. Hisham > > Cheers, > Aki > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 08 19:33:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZdtp-0005vz-Fl; Tue, 08 Nov 2005 19:33:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZdtn-0005uc-Jt for simple@megatron.ietf.org; Tue, 08 Nov 2005 19:33:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28320 for ; Tue, 8 Nov 2005 19:32:44 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZe9h-0001id-K7 for simple@ietf.org; Tue, 08 Nov 2005 19:49:38 -0500 X-IronPort-AV: i="3.97,306,1125892800"; d="scan'208"; a="22452414:sNHT45646176" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Issue 2: Sender keeps state Date: Tue, 8 Nov 2005 19:33:08 -0500 Message-ID: <330A23D8336C0346B5C1A5BB19666647018A7BE0@ATLANTIS.Brooktrout.com> Thread-Topic: [Simple] Issue 2: Sender keeps state Thread-Index: AcXktC376q2+hl83T3WtPFYtXgi3lwAEO0AA From: "Burger, Eric" To: "Hisham Khartabil" , "Ben Campbell" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The UAC *ALWAYS* can decide how much state, and what state, to keep. That is an implementation issue beyond the protocol. -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Tuesday, November 08, 2005 5:29 PM To: Ben Campbell Cc: simple@ietf.org; Burger, Eric Subject: Re: [Simple] Issue 2: Sender keeps state On Nov 8, 2005, at 11:18 PM, Ben Campbell wrote: > > On Nov 8, 2005, at 11:18 AM, Hisham Khartabil wrote: > >> >> On Nov 8, 2005, at 7:20 PM, Ben Campbell wrote: >> >>> I think the sender should keep the state, for a couple of reasons: >>> >>> 1) IMs are by nature short lived. We are not talking about email=20 >>> lifetimes where the MDN could happen months later. >> >> Keep in mind we are talking about read reports, not just delivery.=20 >> Sure the IM is short lived, but that doesnt mean I have to read it=20 >> immediately. >> > > My point is that if I send you an IM and request a read-report, and=20 > don't get a report back in a fairly short period of time, I am going=20 > to give up. If we expect people to wait indefinitely, then I start to=20 > wonder why we don't just use email. > >>> 2) I think most applications are going to be impacted worse by the=20 >>> bandwidth issue of sending the whole message back in the IMDN than=20 >>> they would be by keeping state for short periods. This is also an=20 >>> issue when using SIP MESSAGE, due to the low size limits in RFC3428. >> >> How does your phone work today with SMS? It does not need any=20 >> correlation information between the receipt reports and the messages=20 >> in the sent box. Your email client is the same, if there is a match=20 >> of the message-id, great. If there is not, the delivery report is=20 >> stand alone and it leaves it for the human user to correlate the MDN=20 >> and the message. > > My SMS client doesn't do receipt requests. But my old phone did. On=20 > that one, I just got back something saying that message to X was=20 > delivered. I I had more than one messages to X, I could not tell which > one. Certainly, it can do that without keeping state. That's all I'm asking for. > I guess I support saying that the UAC should have the option of not=20 > keeping state, but it will not be able to provide much info to the=20 > user if it doesn't. But I don't want to require the UAS to include a=20 > lot of information in the IMDN to make life easier on a stateless UAC. Agreed. Hisham > > > >> >> Hisham >> >>> >>> On Nov 8, 2005, at 4:24 AM, Burger, Eric wrote: >>> >>>> The only reliable way is to have the message shipped around. =20 >>>> However, >>>> that is a well-known SPAM attack in e-mail, and it would be=20 >>>> microseconds >>>> before that attack would occur in IM/IMDN if we left open that >>>> opportunity. >>>> >>>> If an instant message is around a line, the Subject (summary) is the >>>> message itself... >>>> >>>> -----Original Message----- >>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 >>>> Behalf >>>> Of Xiao Wang >>>> Sent: Monday, November 07, 2005 9:26 PM >>>> To: 'Hisham Khartabil' >>>> Cc: simple@ietf.org >>>> Subject: RE: [Simple] Issue 2: Sender keeps state >>>> >>>> This is a way. But if user delete items from sent box , >>>> receiving MDNs don't have matching any IMs. >>>> Now, inbox and sent box in the mobile phone are not big enough, >>>> So they are often cleaned up. >>>> >>>> Xiao >>>> >>>>> -----Original Message----- >>>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>>> Behalf >>>> Of >>>>> Hisham Khartabil >>>>> Sent: Tuesday, November 08, 2005 2:57 AM >>>>> To: Burger, Eric >>>>> Cc: simple@ietf.org >>>>> Subject: Re: [Simple] Issue 2: Sender keeps state >>>>> >>>>> I don't agree that state is needed at the client. SPAM will be=20 >>>>> solved >>>>> elsewhere. And a UAS does not need to put the actual IM in the MDN. >>>>> Often enough, the URI of the recipient of the IM is, imo, enough=20 >>>>> for >>>>> the human user to know what this MDN is for. Having said that, we >>>>> should not stop implementations from keeping state if they want to. >>>>> >>>>> Also, think of having an inbox and and sent box (just like email or >>>> sms >>>>> in your mobile phone). In those cases, the client is, soft of,=20 >>>>> keeping >>>>> state until the user deletes items from the sent box. Matching of=20 >>>>> MDNs >>>>> and IMs in this case can be done using message-id- >>>>> >>>>> Hisham >>>>> >>>>> On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote: >>>>> >>>>>> In MDN, the message itself keeps state. In the e-mail world,=20 >>>>>> there >>>> is >>>>>> no requirement for the UAC to keep the state of messages sent. =20 >>>>>> When >>>>>> the >>>>>> UAS sends a MDN, it includes the message itself so the user can >>>> figure >>>>>> out what the report is about. >>>>>> >>>>>> This has turned into a major SPAM hole. Folks send out SPAM >>>>>> masquerading as a MDN. >>>>>> >>>>>> I'd like to close this hole, which is what the draft does. =20 >>>>>> However, >>>> it >>>>>> imposes the burden of the UAC keeping state of messages it sends. >>>> My >>>>>> logic is that this is a tiny price to pay to close the SPAM hole. >>>>>> >>>>>> OK with everyone? >>>>>> >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 09 18:24:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZzJ2-0006AP-QU; Wed, 09 Nov 2005 18:24:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZzJ0-00068w-P1 for simple@megatron.ietf.org; Wed, 09 Nov 2005 18:24:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17279 for ; Wed, 9 Nov 2005 18:24:10 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZzZ4-0005iJ-1R for simple@ietf.org; Wed, 09 Nov 2005 18:41:17 -0500 Received: from [209.52.107.165] (pp107-165.bctel.ca [209.52.107.165]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jA9NOSss085277 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 9 Nov 2005 17:24:31 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <73D0A107-DC51-4BAC-89B1-E8E5C2EE50AC@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Wed, 9 Nov 2005 15:24:34 -0800 To: Simple WG X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 209.52.107.165 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: Subject: [Simple] Agenda tweaks X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Here are some tweaks to the agenda we've planned. I've slightly reduced the time allocated to discussing the impact of the patch-bof meeting (which I'll summarize at the front of the meeting) and have increased the amount of time for IMDN. I've also, at Eric's request, moved IMDN earlier in the meeting. RjS -------- SIMPLE - IETF64 Friday November 11 0900-1130 Please note that geopriv is making a special effort to close out common-policy during their session - please attend that session. 0900-0915 Administrivia 0915-0945 IMDN (Eric) draft-burger-simple-imdn-02 0945-1030 Where we're going with XCAP core (Jonathan) draft-ietf-simple-xcap-08 See the thread "A proposal for fixing the xcap schema problem and related issues" 1030-1040 Adjusting to the geopriv common-policy discussion (Jonathan) draft-ietf-simple-presence-rules-04 1040-1050 Closing on the -partial- drafts (Jari) draft-ietf-simple-partial-pidf-format-05 draft-ietf-simple-partial-notify-06 draft-ietf-simple-partial-publish-03 1050-1100 Closing on a path forward for xcap dif (Jonathan) draft-ietf-simple-xcap-diff-02 draft-rosenberg-simple-xcap-change-log-00 1100-1110 draft-mahy-simple-xcap-profile-00 (Rohan) 1110-1120 draft-wang-simple-presence-ril-00 (Xiao) 1120-1130 draft-ala-kurikka-simple-pidfconn-00 (Jussi) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 09 21:26:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea28e-0005Jm-Kc; Wed, 09 Nov 2005 21:26:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea28c-0005Jh-WD for simple@megatron.ietf.org; Wed, 09 Nov 2005 21:26:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27879 for ; Wed, 9 Nov 2005 21:25:39 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea2Oi-0001zq-RH for simple@ietf.org; Wed, 09 Nov 2005 21:42:47 -0500 Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id AE64119445E for ; Thu, 10 Nov 2005 03:25:41 +0100 (CET) Received: from [209.52.109.174] ([192.168.3.109]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Nov 2005 03:29:10 +0100 In-Reply-To: <73D0A107-DC51-4BAC-89B1-E8E5C2EE50AC@nostrum.com> References: <73D0A107-DC51-4BAC-89B1-E8E5C2EE50AC@nostrum.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <44d5f82fed16af1355f20914fdefdecf@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Date: Thu, 10 Nov 2005 03:25:09 +0100 To: Robert Sparks X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 10 Nov 2005 02:29:10.0327 (UTC) FILETIME=[883DC470:01C5E59E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: [Simple] Re: Agenda tweaks X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org You will also find the agenda and slides on the supplementary web pages http://www.softarmor.com/simple/meets/ietf64/ Slides will be uploaded as they come from presenters. Hisham On Nov 10, 2005, at 12:24 AM, Robert Sparks wrote: > Here are some tweaks to the agenda we've planned. > > I've slightly reduced the time allocated to discussing the impact of > the patch-bof meeting (which I'll summarize at the front of the > meeting) > and have increased the amount of time for IMDN. I've also, at Eric's > request, > moved IMDN earlier in the meeting. > > RjS > -------- > > SIMPLE - IETF64 > Friday November 11 > 0900-1130 > > Please note that geopriv is making a special effort to close out > common-policy during their session - please attend that session. > > 0900-0915 Administrivia > > 0915-0945 IMDN (Eric) > draft-burger-simple-imdn-02 > > 0945-1030 Where we're going with XCAP core (Jonathan) > draft-ietf-simple-xcap-08 > See the thread "A proposal for fixing the xcap schema problem > and related issues" > > 1030-1040 Adjusting to the geopriv common-policy discussion (Jonathan) > draft-ietf-simple-presence-rules-04 > > 1040-1050 Closing on the -partial- drafts (Jari) > draft-ietf-simple-partial-pidf-format-05 > draft-ietf-simple-partial-notify-06 > draft-ietf-simple-partial-publish-03 > > 1050-1100 Closing on a path forward for xcap dif (Jonathan) > draft-ietf-simple-xcap-diff-02 > draft-rosenberg-simple-xcap-change-log-00 > > 1100-1110 draft-mahy-simple-xcap-profile-00 (Rohan) > 1110-1120 draft-wang-simple-presence-ril-00 (Xiao) > 1120-1130 draft-ala-kurikka-simple-pidfconn-00 (Jussi) > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 11 04:45:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaVTZ-0003u0-6g; Fri, 11 Nov 2005 04:45:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaVTX-0003sU-12 for simple@megatron.ietf.org; Fri, 11 Nov 2005 04:45:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26591 for ; Fri, 11 Nov 2005 04:45:10 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaVju-0007Q9-KI for simple@ietf.org; Fri, 11 Nov 2005 05:02:35 -0500 Received: from tehran.clic.cs.columbia.edu (tehran.clic.cs.columbia.edu [128.59.15.67]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jAB9jVho024488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Nov 2005 04:45:32 -0500 (EST) Received: from tehran.clic.cs.columbia.edu (localhost [127.0.0.1]) by tehran.clic.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id jAB9jVx9016908; Fri, 11 Nov 2005 04:45:31 -0500 Received: (from ac2491@localhost) by tehran.clic.cs.columbia.edu (8.13.1/8.13.1/Submit) id jAB9jVjr016907; Fri, 11 Nov 2005 04:45:31 -0500 X-Authentication-Warning: tehran.clic.cs.columbia.edu: ac2491 set sender to ac2491@cs.columbia.edu using -f From: Anurag Chakravarti To: simple@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 11 Nov 2005 04:45:30 -0500 Message-Id: <1131702330.16820.16.camel@tehran.clic.cs.columbia.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-16.3) X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.9 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Subject: [Simple] xcap-list-usage schema doubt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, In draft-ietf-simple-xcap-list-usage-05 the schema for resource list documents contains the following element. ..... ..... Is extending from the base type itself permitted. In the above, element "list" extends from the complexType "listType". If we want recursive lists then should suffice. Particularly my parser throws error "Unique Particle Attribution" in the former case. Maybe it is a bug with the parser (jaxp implementation) Could some please comment on the choice for the former type. -Anurag _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 11 09:16:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaZhB-00033R-V8; Fri, 11 Nov 2005 09:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaZgX-0002tM-Jq for simple@megatron.ietf.org; Fri, 11 Nov 2005 09:15:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06705 for ; Fri, 11 Nov 2005 09:14:51 -0500 (EST) From: Jari.Urpalainen@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaZik-0006kT-7Q for simple@ietf.org; Fri, 11 Nov 2005 09:17:39 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jABE0SSl012798; Fri, 11 Nov 2005 16:00:30 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 16:00:30 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 16:00:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] xcap-list-usage schema doubt Date: Fri, 11 Nov 2005 16:00:29 +0200 Message-ID: <73AAC396CA2F984688914DDBF85E6FE81E606D@esebe105.NOE.Nokia.com> Thread-Topic: [Simple] xcap-list-usage schema doubt Thread-Index: AcXmx4gxoJNjJK4aScKIuSk0ahdl5A== References: <1131702330.16820.16.camel@tehran.clic.cs.columbia.edu> To: , X-OriginalArrivalTime: 11 Nov 2005 14:00:30.0640 (UTC) FILETIME=[46D8FB00:01C5E6C8] X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi ! Good catch, yes this schema violates the infamous Unique Particle Attribution (UPA) constraint (well yet another example that we should switch using RELAX NG ;-)). It is not about recursion it is about overlapping wildcards. So the first definition should be removed. Also there are some processContents=3D"lax" definitions that seem to be missing, 48hours ? btw. feel free to use a w3c schema validation web form tool at which is based on xerces c++ (checks also UPA violations). This tool is also linked from tools.ietf.org website. br, Jari -----Original Message----- From: simple-bounces@ietf.org on behalf of ext Anurag Chakravarti Sent: Fri 11/11/2005 11:45 AM To: simple@ietf.org Subject: [Simple] xcap-list-usage schema doubt =20 Hi, In draft-ietf-simple-xcap-list-usage-05 the schema for resource list documents contains the following element. ..... ..... Is extending from the base type itself permitted. In the above, element "list" extends from the complexType "listType".=20 If we want recursive lists then=20 should suffice. Particularly my parser throws error "Unique Particle Attribution" in the former case. Maybe it is a bug with the parser (jaxp implementation) Could some please comment on the choice for the former type. -Anurag _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 11 12:54:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ead75-0003To-BD; Fri, 11 Nov 2005 12:54:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ead73-0003Tg-9I for simple@megatron.ietf.org; Fri, 11 Nov 2005 12:54:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23263 for ; Fri, 11 Nov 2005 12:54:27 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EadNL-0006W0-J6 for simple@ietf.org; Fri, 11 Nov 2005 13:11:58 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AD17EC5B for ; Fri, 11 Nov 2005 18:54:28 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 18:52:32 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 18:52:32 +0100 Received: from 147.214.118.230 ([147.214.118.230]) by esealmw105.eemea.ericsson.se ([153.88.200.68]) via Exchange Front-End Server mail.eemea.ericsson.se ([153.88.254.168]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 Nov 2005 17:51:07 +0000 Received: from Caliope by mail.eemea.ericsson.se; 11 Nov 2005 09:52:32 -0800 From: Ignacio =?ISO-8859-1?Q?M=E1s?= "Ivars (KI/EAB)" To: SIMPLE mailing list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Organization: Ericsson Research Date: Fri, 11 Nov 2005 09:52:31 -0800 Message-Id: <1131731552.6200.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.5.1 X-OriginalArrivalTime: 11 Nov 2005 17:52:32.0930 (UTC) FILETIME=[B12DD820:01C5E6E8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Subject: [Simple] (Very) late MSRP questions, version number in request? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi folks, I have a question about MSRP that stroke me the last days while implementing some MSRP code: SIP, HTTP and RTSP (for example) signal the version in the header line (SIP/2.0, HTTP/1.1...) for different reasons (compatibility and so...) Wouldn't it be a good idea to do the same with MSRP, say 'MSRP/1.0 transactionID SEND'. I think it would ease upgrading MSRP if need be in the future. Has it been discussed before? Does it make sense? Thanks! /Ignacio --=20 Ignacio M=E1s Ivars Service enablers and protocols, Ericsson Research (EAB/TBG/B) Ericsson AB Phone: +46 8 4045580 Torshamsgatan 23 Fax: +46 8 4049500 SE-164 80 Stockholm, Sweden mailto: ignacio.mas.ivars@ericsson.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 11 13:25:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eadan-0005Ie-FW; Fri, 11 Nov 2005 13:25:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eadam-0005Ht-G8; Fri, 11 Nov 2005 13:25:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25585; Fri, 11 Nov 2005 13:25:10 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EadrC-000821-OO; Fri, 11 Nov 2005 13:42:41 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jABIPYho014082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Nov 2005 13:25:34 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id jABIPVUb014227; Fri, 11 Nov 2005 13:25:32 -0500 Message-ID: <4374E21F.7000702@cs.columbia.edu> Date: Fri, 11 Nov 2005 13:25:35 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'GEOPRIV WG'" , Simple WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Subject: [Simple] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The last remaining open issue in common policy is the format of the domain attribute in common policy. Concrete suggestion: Use RFC 3987 (internationalized domain names): ihost = IP-literal / IPv4address / ireg-name Every URI is also an IRI, so this should work generally. This supports both IPv4 and IPv6. RFC 3987 also provides comparison rules, in Section 5. This has the advantage that the same code would already be needed for the full IRI comparison for the 'id' parameter. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 11 14:03:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeBY-00027l-3l; Fri, 11 Nov 2005 14:03:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeBW-00027T-Pv for simple@megatron.ietf.org; Fri, 11 Nov 2005 14:03:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28079 for ; Fri, 11 Nov 2005 14:03:08 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaeS0-0001E5-1D for simple@ietf.org; Fri, 11 Nov 2005 14:20:40 -0500 Received: from [209.52.106.162] (pp106-162.bctel.ca [209.52.106.162]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jABJ3FFS078429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Nov 2005 13:03:16 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4374EAF3.4090409@nostrum.com> Date: Fri, 11 Nov 2005 11:03:15 -0800 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Ignacio_M=E1s_=5C=22Ivars_=28KI/EAB=29=5C=22=22?= Subject: Re: [Simple] (Very) late MSRP questions, version number in request? References: <1131731552.6200.7.camel@localhost.localdomain> In-Reply-To: <1131731552.6200.7.camel@localhost.localdomain> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Received-SPF: pass (nostrum.com: 209.52.106.162 is authenticated by a trusted mechanism) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nostrum.com id jABJ3FFS078429 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Ignacio M=E1s Ivars (KI/EAB) wrote: >I have a question about MSRP that stroke me the last days while >implementing some MSRP code: SIP, HTTP and RTSP (for example) signal the >version in the header line (SIP/2.0, HTTP/1.1...) for different reasons >(compatibility and so...) Wouldn't it be a good idea to do the same with >MSRP, say 'MSRP/1.0 transactionID SEND'. > This comes up often enough that we might to add some motivating text in=20 the document. I'll quote Ben Campbell from a message dated 6/28/2004: > This was discussed in the working group some time back. The consensus=20 > was that there was no use for a version indicator, since MSRP would=20 > never negotiate versions. > > Since MSRP is _always_ negotiated with an external signaling protocol,=20 > any version negotiation belongs there. Any version updates to MSRP=20 > must describe how to indicate the new version in the sdp exchange.=20 /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 11 14:14:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeLd-0005jd-5i; Fri, 11 Nov 2005 14:14:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeLb-0005jV-Js for simple@megatron.ietf.org; Fri, 11 Nov 2005 14:14:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28841 for ; Fri, 11 Nov 2005 14:13:33 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eaeby-0001j9-NC for simple@ietf.org; Fri, 11 Nov 2005 14:31:05 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 406D35D7; Fri, 11 Nov 2005 20:13:47 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 20:13:46 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 20:13:46 +0100 Received: from 147.214.118.230 ([147.214.118.230]) by esealmw105.eemea.ericsson.se ([153.88.200.68]) via Exchange Front-End Server mail.eemea.ericsson.se ([153.88.254.168]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 Nov 2005 19:12:20 +0000 Received: from Caliope by mail.eemea.ericsson.se; 11 Nov 2005 11:13:46 -0800 Subject: Re: [Simple] (Very) late MSRP questions, version number in request? From: Ignacio =?ISO-8859-1?Q?M=E1s?= "Ivars (KI/EAB)" To: Adam Roach In-Reply-To: <4374EAF3.4090409@nostrum.com> References: <1131731552.6200.7.camel@localhost.localdomain> <4374EAF3.4090409@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Organization: Ericsson Research Date: Fri, 11 Nov 2005 11:13:44 -0800 Message-Id: <1131736424.6200.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.5.1 X-OriginalArrivalTime: 11 Nov 2005 19:13:46.0680 (UTC) FILETIME=[0A291380:01C5E6F4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, inline: On Fri, 2005-11-11 at 11:03 -0800, Adam Roach wrote: > Ignacio M=E1s Ivars (KI/EAB) wrote: >=20 > >I have a question about MSRP that stroke me the last days while > >implementing some MSRP code: SIP, HTTP and RTSP (for example) signal the > >version in the header line (SIP/2.0, HTTP/1.1...) for different reasons > >(compatibility and so...) Wouldn't it be a good idea to do the same with > >MSRP, say 'MSRP/1.0 transactionID SEND'. > > >=20 > This comes up often enough that we might to add some motivating text in=20 > the document. Yes, I agree. Perhaps just adding a a paragraph explaining the decision would help. >=20 > I'll quote Ben Campbell from a message dated 6/28/2004: >=20 > > This was discussed in the working group some time back. The consensus=20 > > was that there was no use for a version indicator, since MSRP would=20 > > never negotiate versions. > > > > Since MSRP is _always_ negotiated with an external signaling protocol,=20 > > any version negotiation belongs there. Any version updates to MSRP=20 > > must describe how to indicate the new version in the sdp exchange.=20 >=20 O.K. sounds fair! It could be good as you suggest just adding exactly *that* to the document... Thanks! /Ignacio >=20 > /a --=20 Ignacio M=E1s Ivars Service enablers and protocols, Ericsson Research (EAB/TBG/B) Ericsson AB Phone: +46 8 4045580 Torshamsgatan 23 Fax: +46 8 4049500 SE-164 80 Stockholm, Sweden mailto: ignacio.mas.ivars@ericsson.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 11 19:04:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eaiss-0000rJ-O5; Fri, 11 Nov 2005 19:04:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eaisq-0000rA-Nk for simple@megatron.ietf.org; Fri, 11 Nov 2005 19:04:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27886 for ; Fri, 11 Nov 2005 19:04:10 -0500 (EST) From: ac2491@cs.columbia.edu Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eaj9F-00016j-NL for simple@ietf.org; Fri, 11 Nov 2005 19:21:45 -0500 Received: from hydra.cs.columbia.edu (IDENT:BR7K5cUs5zeSYtRqlxT1tOJU7lgCZE1y@hydra.cs.columbia.edu [128.59.16.129]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jAC04Tho026638 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 11 Nov 2005 19:04:29 -0500 (EST) Received: from webmail.cs.columbia.edu (IDENT:OdCy9MxtBAB0ojY+tMvS5m6xwCeJKXle@localhost [127.0.0.1]) by hydra.cs.columbia.edu (8.12.10/8.12.10) with SMTP id jAC04Tah029888; Fri, 11 Nov 2005 19:04:29 -0500 Received: from 24.199.92.69 (SquirrelMail authenticated user ac2491) by webmail.cs.columbia.edu with HTTP; Fri, 11 Nov 2005 19:04:29 -0500 (EST) Message-ID: <32810.24.199.92.69.1131753869.squirrel@webmail.cs.columbia.edu> Date: Fri, 11 Nov 2005 19:04:29 -0500 (EST) To: simple@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-PerlMx-Spam: Gauge=X, Probability=10%, Report='PRIORITY_NO_NAME 0.716, HTML_50_70 0.1, NO_REAL_NAME 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_PRIORITY 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 2.1 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 8bit Cc: Subject: [Simple] Respect comments...xcap draft seems amiss X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, Respecting the spaces and comments in the way xcap-draft-08 has defined seems wrong. Consider the given xml doc in the draft . Logically you would put comments on top of the element it belongs to. But after the insertion the old comment now applies to the new element. Is this intuitive on the client side? Am I missing something here? -Anurag _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 11 19:30:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EajHX-00085S-Cw; Fri, 11 Nov 2005 19:30:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EajHV-000852-Sx for simple@megatron.ietf.org; Fri, 11 Nov 2005 19:30:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28988 for ; Fri, 11 Nov 2005 19:29:39 -0500 (EST) From: ac2491@cs.columbia.edu Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EajY1-00020u-BD for simple@ietf.org; Fri, 11 Nov 2005 19:47:14 -0500 Received: from hydra.cs.columbia.edu (IDENT:FF3wizW+9vz6hXUjLnpHQTcK4bw5mtJD@hydra.cs.columbia.edu [128.59.16.129]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jAC0U1ho000999 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 11 Nov 2005 19:30:02 -0500 (EST) Received: from webmail.cs.columbia.edu (IDENT:aqSuC4awAtOiQ6/jkDT76Ww2aTOtUnsO@localhost [127.0.0.1]) by hydra.cs.columbia.edu (8.12.10/8.12.10) with SMTP id jAC0U1ah029991; Fri, 11 Nov 2005 19:30:01 -0500 Received: from 24.199.92.69 (SquirrelMail authenticated user ac2491) by webmail.cs.columbia.edu with HTTP; Fri, 11 Nov 2005 19:30:01 -0500 (EST) Message-ID: <32788.24.199.92.69.1131755401.squirrel@webmail.cs.columbia.edu> Date: Fri, 11 Nov 2005 19:30:01 -0500 (EST) To: simple@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-PerlMx-Spam: Gauge=X, Probability=10%, Report='PRIORITY_NO_NAME 0.716, NO_REAL_NAME 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_PRIORITY 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 2.1 (++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 8bit Cc: Subject: [Simple] XCAP Application Usage Schema template X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, XCAP is application usage cetric and defines loads of rules for development of an application usage. Is there some sort of xml schema template for development of application usages? I think we require one or do we? Please comment. -Anurag _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 14 06:50:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbcrO-0006nY-HM; Mon, 14 Nov 2005 06:50:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbcrN-0006nT-Cp for simple@megatron.ietf.org; Mon, 14 Nov 2005 06:50:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14544 for ; Mon, 14 Nov 2005 06:50:22 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebd8N-0000r6-P2 for simple@ietf.org; Mon, 14 Nov 2005 07:08:29 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAEBlxUE003347; Mon, 14 Nov 2005 13:47:59 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 13:50:48 +0200 Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 14 Nov 2005 13:50:48 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id jAEBolJ13930; Mon, 14 Nov 2005 13:50:47 +0200 (EET) Received: from xitami.research.nokia.com (xitami.research.nokia.com [172.21.50.105]) by kusti.research.nokia.com (Postfix) with ESMTP id AE34E93B6A; Mon, 14 Nov 2005 13:50:47 +0200 (EET) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by xitami.research.nokia.com (Postfix) with ESMTP id 909D72E3; Mon, 14 Nov 2005 13:50:47 +0200 (EET) From: Jari Urpalainen To: ext Jonathan Rosenberg Content-Type: text/plain Date: Mon, 14 Nov 2005 13:50:47 +0200 Message-Id: <1131969047.3695.60.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2005 11:50:48.0966 (UTC) FILETIME=[A7D90260:01C5E911] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] Clarifications of some XCAP (+diff) issues X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi Jonathan! I promised to clarify some xcap issues, first there are some nits in . The current insert logic (xcap-08) is imo inconsistent when a mixed type is used in the content model, i.e. if you have e.g.: and you insert with 'root/foo/bar[1][@a="1"]'. so you end up with: skipping the first whitespace text node of . However, if 's type is mixed (the previous example is valid for that type too) and if the original doc had been text you would insert resulting with: text Now no skipping of the first text node. Anyway, I'm feeling somewhat dizzy about the whole insert logic, as you always end up having some deficiency with it. So I'm now inclined to prefer the logic where you insert a new element to the last possible node position (where get(put(x))=x of course). That's because: 1. appending as the last child is the most logical way, 2. that's the way typical libraries do anyway, 3. it's consistent with the 07-version, 4. it leads to the shortest text in the spec, 5. if you insert with "root/node" or "root/node[1]" and there's no within , the position is the same in both cases. Probably some other reasons, but I'll prefer KISS here (as almost always). The second issue that I was unable to clearly state, was about patching. With XPath you can't locate e.g. xml entities from the xml prologue of the document, e.g. I've used xml entities with patch-ops: . So if the client updates an existing document so that prologue changes, it is not possible to patch that with XPath semantics, so you have to download the whole document again. So this influences xcap-diff, where it should be clearly expressed to the client that reloading is necessary. So my thought was to add e.g. some "state" attribute info to xcap-diff: "created", "modified" (==prologue changed), "deleted". thanks, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 14 11:44:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbhRN-0005BS-JA; Mon, 14 Nov 2005 11:44:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbhRL-0005BI-VU for simple@megatron.ietf.org; Mon, 14 Nov 2005 11:44:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03583 for ; Mon, 14 Nov 2005 11:43:47 -0500 (EST) From: ac2491@cs.columbia.edu Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbhiN-0002aC-14 for simple@ietf.org; Mon, 14 Nov 2005 12:01:58 -0500 Received: from hydra.cs.columbia.edu (IDENT:RrA56ctX09usnS4ewguayCkuhAxq3cQt@hydra.cs.columbia.edu [128.59.16.129]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jAEGiAho006225 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 14 Nov 2005 11:44:11 -0500 (EST) Received: from webmail.cs.columbia.edu (IDENT:Cb/X/I9cxLhCcldkvdBzxlXeL+om8lPt@localhost [127.0.0.1]) by hydra.cs.columbia.edu (8.12.10/8.12.10) with SMTP id jAEGiAah015426; Mon, 14 Nov 2005 11:44:10 -0500 Received: from 24.199.92.69 (SquirrelMail authenticated user ac2491) by webmail.cs.columbia.edu with HTTP; Mon, 14 Nov 2005 11:44:10 -0500 (EST) Message-ID: <32771.24.199.92.69.1131986650.squirrel@webmail.cs.columbia.edu> Date: Mon, 14 Nov 2005 11:44:10 -0500 (EST) To: jdrosen@cisco.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-PerlMx-Spam: Gauge=X, Probability=10%, Report='PRIORITY_NO_NAME 0.716, NO_REAL_NAME 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_PRIORITY 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 2.1 (++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 8bit Cc: simple@ietf.org Subject: [Simple] XCAP default namespaces X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, PUT fragment in XCAP without namespace could be a problem. Eg: Bob Jones Should be: Bob Jones In the former we cannot distinguish between no namespace and default namespace. Similar problem is faced in XPATH default namespace binding, in XPATH unless explicitly specified in the form "namespace:path" no namespace is considered. Regards -Anurag _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 14 13:13:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebipz-0004vC-0O; Mon, 14 Nov 2005 13:13:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebipx-0004v6-BO for simple@megatron.ietf.org; Mon, 14 Nov 2005 13:13:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10771 for ; Mon, 14 Nov 2005 13:13:18 -0500 (EST) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebj71-00064F-1Q for simple@ietf.org; Mon, 14 Nov 2005 13:31:28 -0500 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IPY0000OIMQDQ@dns2.cselt.it> for simple@ietf.org; Mon, 14 Nov 2005 19:13:38 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 19:11:07 +0100 Date: Mon, 14 Nov 2005 19:13:38 +0100 From: Goix Walter To: simple@ietf.org Message-id: <91C9464F6AFC0647A2D8069E25DBF49601E4342C@EXC01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: Questions on draft-ietf-simple-filter-format-05 thread-index: AcXpRyKm2AlT65efQEitdKGmr1Yflg== Content-Class: urn:content-classes:message X-OriginalArrivalTime: 14 Nov 2005 18:11:07.0203 (UTC) FILETIME=[C893A930:01C5E946] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Subject: [Simple] Questions on draft-ietf-simple-filter-format-05 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, I have a couple of questions regarding the handling on filters = in an Event Server: - when only an filter is present (no ), does the = server need to provide the *whole* document but the excluded part, or is = it implicit? In other words, do the server need an filter as = well to consider the whole document or part of it before to apply the = filter? - when the filter asks for removing a mandatory element, which = is nesting elements from another namespaces, what would be the result of = the exclusion process: is it the full content of the mandatory element, = or only an 'empty' (or minimally valid) element. Below is an example: 1. is a mandatory element within with an only, i.e. = it does not have any attribute nor mandate any sub-element 2. document in the server is: something 3. filter contains //root/foo 4. Result of filtering process is (a) or (b) something =20 ? Thanks for the clarification Walter Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 14 14:55:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbkPx-0000Zh-9T; Mon, 14 Nov 2005 14:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbkPu-0000XY-LZ; Mon, 14 Nov 2005 14:55:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18634; Mon, 14 Nov 2005 14:54:30 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebkgz-0001eH-Hy; Mon, 14 Nov 2005 15:12:42 -0500 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 14 Nov 2005 14:54:41 -0500 id 0158805E.4378EB81.00004D29 In-Reply-To: <4374E21F.7000702@cs.columbia.edu> References: <4374E21F.7000702@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Mon, 14 Nov 2005 14:54:55 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Nov 11, 2005, at 1:25 PM, Henning Schulzrinne wrote: > The last remaining open issue in common policy is the format of the > domain attribute in common policy. > > Concrete suggestion: > > Use RFC 3987 (internationalized domain names): > > ihost = IP-literal / IPv4address / ireg-name > > Every URI is also an IRI, so this should work generally. This > supports both IPv4 and IPv6. RFC 3987 also provides comparison > rules, in Section 5. This has the advantage that the same code > would already be needed for the full IRI comparison for the 'id' > parameter. Given Jonathan's comment, I thought he was more focused on actual domain names and not IP addresses. I don't care. I just thought that was what was said. Even if the domain field is limited to ireg-name, I do not believe that solves the problem. I'm not an IRI expert, but it appears that not all ireg-name values are legal domain names. And I still wonder about the IDN case, especially given that this appears to be an exact match. Which form is the exact match performed on, the UTF8, a NamePrepped domain, or an ACE encoded domain. Given that there can be variants of an IDN floating around on the wire, it always seems to me that the comparison should be done on the ACE version. If there is somebody with better IDN-in-IRI clue, please correct me. -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 14 15:18:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebkms-0006lZ-6o; Mon, 14 Nov 2005 15:18:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebkmq-0006kO-4a; Mon, 14 Nov 2005 15:18:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20467; Mon, 14 Nov 2005 15:18:12 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebl3u-0002Y6-5M; Mon, 14 Nov 2005 15:36:24 -0500 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jAEKIZWk004234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Nov 2005 15:18:36 -0500 (EST) Message-ID: <4378F0C6.3060600@cs.columbia.edu> Date: Mon, 14 Nov 2005 15:17:10 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> In-Reply-To: <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org > Given Jonathan's comment, I thought he was more focused on actual > domain names and not IP addresses. I don't care. I just thought that > was what was said. Right; I just want to make sure we don't get into an IPv4 vs. IPv6 discussion. > > Even if the domain field is limited to ireg-name, I do not believe that > solves the problem. I'm not an IRI expert, but it appears that not all > ireg-name values are legal domain names. Sure, but this is not a new problem. example.andy, ccs.columbia.edu or ex$ample.com are not valid domain names, either, even without the I18N problems. Thus, there will always be valid domain-looking strings that don't match any protocol-possible string. This isn't an issue - the rule component just will never match and somebody will have to fix the typo. > > And I still wonder about the IDN case, especially given that this > appears to be an exact match. Which form is the exact match performed > on, the UTF8, a NamePrepped domain, or an ACE encoded domain. Given > that there can be variants of an IDN floating around on the wire, it > always seems to me that the comparison should be done on the ACE version. I may be looking at the wrong thing, but Section 5 of RFC 3987 seems relevant: 5. Normalization and Comparison . . . . . . . . . . . . . . . . . 21 5.1. Equivalence . . . . . . . . . . . . . . . . . . . . . . 22 5.2. Preparation for Comparison . . . . . . . . . . . . . . . 22 5.3. Comparison Ladder . . . . . . . . . . . . . . . . . . . 23 5.3.1. Simple String Comparison . . . . . . . . . . . . 23 5.3.2. Syntax-Based Normalization . . . . . . . . . . . 24 5.3.3. Scheme-Based Normalization . . . . . . . . . . . 27 5.3.4. Protocol-Based Normalization . . . . . . . . . . 28 > > If there is somebody with better IDN-in-IRI clue, please correct me. > > -andy > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 14 16:04:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EblV4-0002w4-3Q; Mon, 14 Nov 2005 16:04:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EblV0-0002ug-EL; Mon, 14 Nov 2005 16:04:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25669; Mon, 14 Nov 2005 16:03:49 -0500 (EST) Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eblm5-00054T-RG; Mon, 14 Nov 2005 16:22:02 -0500 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 14 Nov 2005 16:04:01 -0500 id 0158805C.4378FBC1.00005846 In-Reply-To: <4378F0C6.3060600@cs.columbia.edu> References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Mon, 14 Nov 2005 16:04:14 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Nov 14, 2005, at 3:17 PM, Henning Schulzrinne wrote: >> Even if the domain field is limited to ireg-name, I do not >> believe that solves the problem. I'm not an IRI expert, but it >> appears that not all ireg-name values are legal domain names. > > Sure, but this is not a new problem. example.andy, ccs.columbia.edu > or ex$ample.com are not valid domain names, either, even without > the I18N problems. Thus, there will always be valid domain-looking > strings that don't match any protocol-possible string. This isn't > an issue - the rule component just will never match and somebody > will have to fix the typo. I guess what I'm trying to say is that not all IRIs produce a valid domain name. If you are saying, "it doesn't matter, these are never handed to gethostbyname()" then I agree with you. >> And I still wonder about the IDN case, especially given that this >> appears to be an exact match. Which form is the exact match >> performed on, the UTF8, a NamePrepped domain, or an ACE encoded >> domain. Given that there can be variants of an IDN floating >> around on the wire, it always seems to me that the comparison >> should be done on the ACE version. > > I may be looking at the wrong thing, but Section 5 of RFC 3987 > seems relevant: > > 5. Normalization and Comparison . . . . . . . . . . . . . . . . . 21 > 5.1. > Equivalence . . . . . . . . . . . . . . . . . . . . . . 22 > 5.2. Preparation for > Comparison . . . . . . . . . . . . . . . 22 > 5.3. Comparison > Ladder . . . . . . . . . . . . . . . . . . . 23 > 5.3.1. Simple String > Comparison . . . . . . . . . . . . 23 > 5.3.2. Syntax-Based > Normalization . . . . . . . . . . . 24 > 5.3.3. Scheme-Based > Normalization . . . . . . . . . . . 27 > 5.3.4. Protocol-Based > Normalization . . . . . . . . . . 28 At the very least, common-policy ought to point out which comparison is being done. I would assume that since these are being used as identifiers, that section 5.3.1 is the section that is relevant here. And it might be that I'm just not smart enough to understand something as trivial as internationalized character comparison, but what happens with punycode encoded domain names? As the example from that RFC: if I receive it as domain="xn--99zt52a", do I convert it to domain="納豆" for the comparison? As the RFC states: Implementations with scheme-specific knowledge MAY convert punycode-encoded domain name labels to the corresponding characters by using the ToUnicode procedure. Again, I'm not an expert, but shouldn't something specify what is to happen here for doing this identity comparison? -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 14 16:36:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eblzj-0008Dn-Cd; Mon, 14 Nov 2005 16:36:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eblzh-0008Dd-Kf; Mon, 14 Nov 2005 16:36:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02990; Mon, 14 Nov 2005 16:35:33 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbmGo-0007yW-9K; Mon, 14 Nov 2005 16:53:46 -0500 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jAELa1Wk008461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Nov 2005 16:36:02 -0500 (EST) Message-ID: <437902EC.1040901@cs.columbia.edu> Date: Mon, 14 Nov 2005 16:34:36 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> In-Reply-To: <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I'm probably well beyond my I18N/IDN depth here, so I agree that external advice is called for. My understanding of RFC 3987, Section 5, is that these steps are performed in sequence, starting with the low-cost step in 5.3.1 and progressing to steps requiring more work if there's no match. First, I think we can restrict ourselves to discussing URIs appearing in specific protocols, such as part of a SIP From URI or an XMPP URI. There are probably two cases: Protocols that are clearly specified as using IRIs already (XMPP, say) and those that require discussion (SIP, say). [Discussion is required for SIP since SIP itself allows UTF-8 and RFC 3987 Section 6.3 alludes to the fact that most schemes do not have to be upgraded to support IRIs.] I'll stick to the IRI case. If the IRI shows up in the protocol request, the steps in 5.3.1 would be executed until either a match occurred or the process falls off the ladder mentioned in the spec. Clearly, some of the comparison steps do not apply since they concern the port number or path components of the comparison. From my reading of 3987, the punycode version would be compared as well during the ladder, presumably by converting the IDN to punycode. (I suspect that the conversion from UTF-8 to punycode is unique, while I suspect that this is not true in the other direction. In other words, multiple UTF-8 strings could generate the same punycode.) This is all a bit messier than ASCII comparison, but I don't think we want users to edit punycode into their XML rule files. Henning > At the very least, common-policy ought to point out which comparison is > being done. I would assume that since these are being used as > identifiers, that section 5.3.1 is the section that is relevant here. > > And it might be that I'm just not smart enough to understand something > as trivial as internationalized character comparison, but what happens > with punycode encoded domain names? As the example from that RFC: if I > receive it as domain="xn--99zt52a", do I convert it to > domain="納豆" for the comparison? As the RFC states: > > Implementations with scheme-specific knowledge MAY convert > punycode-encoded domain name labels to the corresponding characters > by using the ToUnicode procedure. > > Again, I'm not an expert, but shouldn't something specify what is to > happen here for doing this identity comparison? > > -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 14 17:30:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebmqa-0007mJ-Lu; Mon, 14 Nov 2005 17:30:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbmqY-0007lb-Bp; Mon, 14 Nov 2005 17:30:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06088; Mon, 14 Nov 2005 17:30:09 -0500 (EST) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebn7c-0001FL-C0; Mon, 14 Nov 2005 17:48:23 -0500 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 14 Nov 2005 17:30:09 -0500 id 01588017.43790FF1.000068D5 In-Reply-To: <437902EC.1040901@cs.columbia.edu> References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Mon, 14 Nov 2005 17:30:22 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.3 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Nov 14, 2005, at 4:34 PM, Henning Schulzrinne wrote: > I'm probably well beyond my I18N/IDN depth here, so I agree that > external advice is called for. Me too. So no argument here. > My understanding of RFC 3987, Section 5, is that these steps are > performed in sequence, starting with the low-cost step in 5.3.1 and > progressing to steps requiring more work if there's no match. I'm not saying you are wrong, but that's not the impression I got when reading that section. Otherwise, whey is step 1 (simple string comparison) a MUST in certain situations if it always a MUST. > First, I think we can restrict ourselves to discussing URIs > appearing in specific protocols, such as part of a SIP From URI or > an XMPP URI. I do not agree with this. If HELD comes to fruition, we'll be talking about HTTP schemes as well. > There are probably two cases: Protocols that are clearly specified > as using IRIs already (XMPP, say) and those that require discussion > (SIP, say). [Discussion is required for SIP since SIP itself allows > UTF-8 and RFC 3987 Section 6.3 alludes to the fact that most > schemes do not have to be upgraded to support IRIs.] > > I'll stick to the IRI case. If the IRI shows up in the protocol > request, the steps in 5.3.1 would be executed until either a match > occurred or the process falls off the ladder mentioned in the spec. > Clearly, some of the comparison steps do not apply since they > concern the port number or path components of the comparison. This sounds right. I don't think we need to worry about the URI case either. > From my reading of 3987, the punycode version would be compared as > well during the ladder, presumably by converting the IDN to > punycode. (I suspect that the conversion from UTF-8 to punycode is > unique, while I suspect that this is not true in the other > direction. In other words, multiple UTF-8 strings could generate > the same punycode.) The word in the RFC is MAY: Implementations with scheme-specific knowledge MAY convert punycode-encoded domain name labels to the corresponding characters by using the ToUnicode procedure. Also, what do you do with the domain attribute? With domain="xn--99zt52a" there is no scheme specific part. Because this is being done for comparison purposes, perhaps common-policy ought to insist on the conversion in domain= with a MUST ToUnicode. The only problem with this is a future scenario where UTF-8 is considered legal in DNS (DNS is 8-bit) labels. Then you have two domain names that are compared as equivalent even though they may not be. Perhaps thats worrying too much. > This is all a bit messier than ASCII comparison, but I don't think > we want users to edit punycode into their XML rule files. You'd be amazed at what end users find to do with cut-and-paste. -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 14 17:35:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebmvd-0000dV-Pd; Mon, 14 Nov 2005 17:35:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebmvb-0000cO-VP for simple@megatron.ietf.org; Mon, 14 Nov 2005 17:35:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06484 for ; Mon, 14 Nov 2005 17:35:23 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbnCh-0001Rr-MU for simple@ietf.org; Mon, 14 Nov 2005 17:53:37 -0500 Received: from [172.17.2.252] (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jAEMZlci087856 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 14 Nov 2005 16:35:49 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <1131731552.6200.7.camel@localhost.localdomain> References: <1131731552.6200.7.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <534BD5A8-7AE6-41C4-89DA-B2CD452AA3B4@nostrum.com> Content-Transfer-Encoding: quoted-printable From: Robert Sparks Subject: Re: [Simple] (Very) late MSRP questions, version number in request? Date: Mon, 14 Nov 2005 16:35:46 -0600 To: =?ISO-8859-1?Q?Ignacio_M=E1s_Ivars_=28KI/EAB=29?= X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hello Ignacio, This topic has been extensively discussed in the past. MSRP is never used without an encompassing signaling protocol. The base doc puts requirements on such a signaling protocol, one of which is =20 to have sufficient feature negotiation capability to deal with future changes =20= that are not backward compatible: The rendezvous mechanism MUST provide mechanisms for the negotiation of any supported MSRP extensions that are not backwards compatible. RjS On Nov 11, 2005, at 11:52 AM, Ignacio M=E1s Ivars (KI/EAB) wrote: > Hi folks, > > I have a question about MSRP that stroke me the last days while > implementing some MSRP code: SIP, HTTP and RTSP (for example) =20 > signal the > version in the header line (SIP/2.0, HTTP/1.1...) for different =20 > reasons > (compatibility and so...) Wouldn't it be a good idea to do the same =20= > with > MSRP, say 'MSRP/1.0 transactionID SEND'. I think it would ease =20 > upgrading > MSRP if need be in the future. Has it been discussed before? Does it > make sense? > > Thanks! > /Ignacio > > > --=20 > Ignacio M=E1s Ivars > Service enablers and protocols, Ericsson Research (EAB/TBG/B) > Ericsson AB Phone: +46 8 4045580 > Torshamsgatan 23 Fax: +46 8 4049500 > SE-164 80 Stockholm, Sweden mailto: ignacio.mas.ivars@ericsson.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 14 19:33:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebolk-0005nt-9v; Mon, 14 Nov 2005 19:33:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eboli-0005jK-11; Mon, 14 Nov 2005 19:33:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13967; Mon, 14 Nov 2005 19:33:18 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebp2p-0005VY-1u; Mon, 14 Nov 2005 19:51:32 -0500 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jAF0XhWk017896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Nov 2005 19:33:44 -0500 (EST) Message-ID: <43792C92.9060509@cs.columbia.edu> Date: Mon, 14 Nov 2005 19:32:18 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> In-Reply-To: <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org > I'm not saying you are wrong, but that's not the impression I got when > reading that section. Otherwise, whey is step 1 (simple string > comparison) a MUST in certain situations if it always a MUST. > I'm not sure which MUST you are referring to, but based on If this range of comparison practices is considered as a ladder, the following discussion will climb the ladder, starting with practices that are cheap but have a relatively higher chance of producing false negatives, and proceeding to those that have higher computational cost and lower risk of false negatives. I take it that you start with 5.3.1 and compare the two IRIs. If the string comparison produces "equal", you're done. If not, it is still possible that two IRIs are equal, after transformation, so you proceed to step 5.3.2, etc. At any step, if you discover equality, you fall off the ladder and declare equality. The steps are set up not to produce false positives, i.e., declaring two IRIs equal when they are not. >> First, I think we can restrict ourselves to discussing URIs appearing >> in specific protocols, such as part of a SIP From URI or an XMPP URI. > > > I do not agree with this. If HELD comes to fruition, we'll be talking > about HTTP schemes as well. 'such as' does not preclude other protocols. For HTTP, the notion of using the request URI as an identifier makes little sense since it identifies the target of the query (the "presentity"). The authorization is clearly based on who is asking, not who is being asked. Thus, for HTTP, you would probably need to use the Digest or other identity string, not the request URI. This is an orthogonal issue, however. > > The word in the RFC is MAY: > > Implementations with scheme-specific knowledge MAY convert > punycode-encoded domain name labels to the corresponding characters > by using the ToUnicode procedure. For our application, it might make sense to make this MUST. > > Also, what do you do with the domain attribute? With > domain="xn--99zt52a" there is no scheme specific part. Because this is > being done for comparison purposes, perhaps common-policy ought to > insist on the conversion in domain= with a MUST ToUnicode. The only > problem with this is a future scenario where UTF-8 is considered legal > in DNS (DNS is 8-bit) labels. Then you have two domain names that are > compared as equivalent even though they may not be. Perhaps thats > worrying too much. I looked at RFC 3490 (IDNA) in more detail just now. For the 'domain' attribute, I think we can simplify the comparison process as follows: --- begin text --- Common policy MUST use UTF-8 to store domain names in 'id' domain attributes. For non-IDNs, lower-case ASCII SHOULD be used. (1) If both domain attribute and protocol domain identifier are in UTF-8 and do not begin with xn--, attempt a string comparison. If the string comparison indicates equality, the comparison succeeds and the remaining steps are skipped. (2) Translate percent-encoding for either string and repeat (1). (3) Convert both domain strings using the toASCII operation described in RFC 3490. (Naturally, if one of the strings already begins with the ACE prefix xn--, the conversion operation has already been performed.) (4) Compare the two domain strings for ASCII equality, for each label. If the conversion fails in step (3), the domains are not equal. --- end text ---- Does this work? Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 14 20:31:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbpfU-0007Bq-NB; Mon, 14 Nov 2005 20:31:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbpfT-0007AM-Eg; Mon, 14 Nov 2005 20:31:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18767; Mon, 14 Nov 2005 20:30:55 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebpwc-0007tw-7j; Mon, 14 Nov 2005 20:49:10 -0500 Received: from [10.0.1.100] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 14 Nov 2005 20:31:06 -0500 id 01588061.43793A5A.00000C57 In-Reply-To: <43792C92.9060509@cs.columbia.edu> References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> <43792C92.9060509@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58F00042-E9D5-43D2-9CE2-C921F96C2E3D@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Mon, 14 Nov 2005 20:31:17 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Nov 14, 2005, at 7:32 PM, Henning Schulzrinne wrote: > I take it that you start with 5.3.1 and compare the two IRIs. If > the string comparison produces "equal", you're done. If not, it is > still possible that two IRIs are equal, after transformation, so > you proceed to step 5.3.2, etc. At any step, if you discover > equality, you fall off the ladder and declare equality. The steps > are set up not to produce false positives, i.e., declaring two IRIs > equal when they are not. My reading of section 5 is that it is a ladder where the lower rungs are least expensive and more common. We'll have to seek guidance on this. >>> First, I think we can restrict ourselves to discussing URIs >>> appearing in specific protocols, such as part of a SIP From URI >>> or an XMPP URI. >> I do not agree with this. If HELD comes to fruition, we'll be >> talking about HTTP schemes as well. > > 'such as' does not preclude other protocols. For HTTP, the notion > of using the request URI as an identifier makes little sense since > it identifies the target of the query (the "presentity"). The > authorization is clearly based on who is asking, not who is being > asked. Thus, for HTTP, you would probably need to use the Digest or > other identity string, not the request URI. This is an orthogonal > issue, however. There are movements afoot to use HTTP URIs as user identifiers. Therefore, I think it is reasonable to foresee HTTP URIs as the "who is asking." > > --- begin text --- > > Common policy MUST use UTF-8 to store domain names in 'id' domain > attributes. For non-IDNs, lower-case ASCII SHOULD be used. > > (1) If both domain attribute and protocol domain identifier are in > UTF-8 and do not begin with xn--, attempt a string comparison. If > the string comparison indicates equality, the comparison succeeds > and the remaining steps are skipped. > > (2) Translate percent-encoding for either string and repeat (1). > > (3) Convert both domain strings using the toASCII operation > described in RFC 3490. (Naturally, if one of the strings already > begins with the ACE prefix xn--, the conversion operation has > already been performed.) > > (4) Compare the two domain strings for ASCII equality, for each label. > > If the conversion fails in step (3), the domains are not equal. > > --- end text ---- > > Does this work? I think it does. What do you mean by "protocol domain identifier" in step 1? -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 14 20:41:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebpor-00042j-Ih; Mon, 14 Nov 2005 20:41:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebpop-00041N-NU; Mon, 14 Nov 2005 20:41:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19553; Mon, 14 Nov 2005 20:40:35 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebq5x-0008Iv-Jo; Mon, 14 Nov 2005 20:58:50 -0500 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jAF1f1Wk021869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Nov 2005 20:41:03 -0500 (EST) Message-ID: <43793C58.1060604@cs.columbia.edu> Date: Mon, 14 Nov 2005 20:39:36 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> <43792C92.9060509@cs.columbia.edu> <58F00042-E9D5-43D2-9CE2-C921F96C2E3D@hxr.us> In-Reply-To: <58F00042-E9D5-43D2-9CE2-C921F96C2E3D@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org > My reading of section 5 is that it is a ladder where the lower rungs > are least expensive and more common. We'll have to seek guidance on this. I think we're in agreement. >> --- begin text --- >> >> Common policy MUST use UTF-8 to store domain names in 'id' domain >> attributes. For non-IDNs, lower-case ASCII SHOULD be used. >> >> (1) If both domain attribute and protocol domain identifier are in >> UTF-8 and do not begin with xn--, attempt a string comparison. If the > I think it does. What do you mean by "protocol domain identifier" in > step 1? I mean the part related to the 'asking' (using) protocol that identifies the domain of the querier. This probably needs a more descriptive term. > > -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 15 00:57:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbtoY-0005vd-US; Tue, 15 Nov 2005 00:57:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbtoX-0005vT-BD; Tue, 15 Nov 2005 00:57:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02134; Tue, 15 Nov 2005 00:56:34 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebu5h-0007hM-66; Tue, 15 Nov 2005 01:14:50 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAF5s85G012991; Tue, 15 Nov 2005 07:54:09 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Nov 2005 07:56:58 +0200 Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Nov 2005 07:56:58 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id jAF5uvJ18827; Tue, 15 Nov 2005 07:56:58 +0200 (EET) Received: from xitami.research.nokia.com (xitami.research.nokia.com [172.21.50.105]) by kusti.research.nokia.com (Postfix) with ESMTP id E405993B6A; Tue, 15 Nov 2005 07:56:57 +0200 (EET) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by xitami.research.nokia.com (Postfix) with ESMTP id CE354369; Tue, 15 Nov 2005 07:56:57 +0200 (EET) Subject: Re: [Simple] XCAP default namespaces From: Jari Urpalainen To: "ext simple-bounces@ietf.org" In-Reply-To: <32771.24.199.92.69.1131986650.squirrel@webmail.cs.columbia.edu> References: <32771.24.199.92.69.1131986650.squirrel@webmail.cs.columbia.edu> Content-Type: text/plain Date: Tue, 15 Nov 2005 07:56:57 +0200 Message-Id: <1132034217.17168.27.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2005 05:56:58.0465 (UTC) FILETIME=[63E56510:01C5E9A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Mon, 2005-11-14 at 11:44 -0500, ext simple-bounces@ietf.org wrote: > Hi, > > PUT fragment in XCAP without namespace could be a problem. > > Eg: > > Bob Jones > > > Should be: > uri="sip:bob@example.com"> > Bob Jones > > actually it could be not should, as default namespace is inherited from the document context (as well as prefixed elements inherit ns declarations from the document). this is an example of a "blind" update which will be clarified in the text. > In the former we cannot distinguish between no namespace and default > namespace. Similar problem is faced in XPATH default namespace binding, in > XPATH unless explicitly specified in the form "namespace:path" no > namespace is considered. > > Regards > -Anurag it is true that using no namespace is somewhat under-specified as e.g. selection "entry/display-name" in XPath means locating unqualified elements. This was purposely made in XCAP such that this means selecting qualified elements with the AU default namespace URI (in order to save bandwidth). In theory this URI could be NULL meaning selecting unqualified elements, but usually AUs define a default namespace. Furthermore, AU extension points usually define "##other" namespace so there are seldom unqualified elements (though unqualified elements are still possible). So the spec should have a few words whether the selection of unqualified elements is possible or not (when there's a non NULL AU namespace URI). From implementation pov it is more complex if it is allowed as then there are two possible interpretations for a non-prefixed element. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 15 01:10:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebu1U-0000C9-4F; Tue, 15 Nov 2005 01:10:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebu1R-0000C1-R1; Tue, 15 Nov 2005 01:10:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03168; Tue, 15 Nov 2005 01:09:54 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbuIc-0008En-Qn; Tue, 15 Nov 2005 01:28:11 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAF67WWX025821; Tue, 15 Nov 2005 08:07:33 +0200 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Nov 2005 08:10:19 +0200 Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Nov 2005 08:10:19 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id jAF6AJJ23015; Tue, 15 Nov 2005 08:10:19 +0200 (EET) Received: from xitami.research.nokia.com (xitami.research.nokia.com [172.21.50.105]) by kusti.research.nokia.com (Postfix) with ESMTP id 122F893B76; Tue, 15 Nov 2005 08:10:19 +0200 (EET) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by xitami.research.nokia.com (Postfix) with ESMTP id 00302369; Tue, 15 Nov 2005 08:10:18 +0200 (EET) Subject: Re: [Simple] XCAP Application Usage Schema template From: Jari Urpalainen To: "ext simple-bounces@ietf.org" Cc: simple@ietf.org In-Reply-To: <32788.24.199.92.69.1131755401.squirrel@webmail.cs.columbia.edu> References: <32788.24.199.92.69.1131755401.squirrel@webmail.cs.columbia.edu> Content-Type: text/plain Date: Tue, 15 Nov 2005 08:10:18 +0200 Message-Id: <1132035018.17168.39.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2005 06:10:19.0609 (UTC) FILETIME=[416A4490:01C5E9AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Fri, 2005-11-11 at 19:30 -0500, ext simple-bounces@ietf.org wrote: > Hi, > > XCAP is application usage cetric and defines loads of rules for > development of an application usage. > > Is there some sort of xml schema template for development of application > usages? I think we require one or do we? > > Please comment. > > -Anurag > there's imo hardly no need for a template, because xcap can patch any kind of xml documents. Sure there are some things that can't be done with xcap semantics, but in principle any schema can be used to describe the aimed content model. Furthermore, doesn't "Guidelines for Creating Application Usages" fulfill your needs ? In addition there are several example AUs available. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 15 01:37:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbuRt-00026g-Lh; Tue, 15 Nov 2005 01:37:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbuRq-00024i-Ht for simple@megatron.ietf.org; Tue, 15 Nov 2005 01:37:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04430 for ; Tue, 15 Nov 2005 01:37:03 -0500 (EST) Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebuir-0000WM-U6 for simple@ietf.org; Tue, 15 Nov 2005 01:55:20 -0500 Received: from cjohn ([192.168.2.244]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id jAF6YKT07692 for ; Tue, 15 Nov 2005 12:04:20 +0530 From: "Chooracken John" To: Date: Tue, 15 Nov 2005 12:09:03 +0530 Message-ID: <006c01c5e9af$45154e60$f402a8c0@cjohn> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Spam-Score: 4.1 (++++) X-Scan-Signature: dc7bd83d90806aed39f33478866e2683 Subject: [Simple] Clarification on XCAP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1255995744==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1255995744== Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01C5E9DD.5ECD8A60" This is a multi-part message in MIME format. ------=_NextPart_000_006D_01C5E9DD.5ECD8A60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, After going though the XCAP draft, I have a query to be cleared. 1. How do I add multiple elements into a document? Is it supported in the current release? For e.g.: Consider that, the following document is available on the server: presence a. How do I add new entries [multiple] in . My XML payload would be something like this: b. What should be the XCAP URI? Thanks, John ------=_NextPart_000_006D_01C5E9DD.5ECD8A60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

        = ;    After going though the XCAP draft, I have a query to be = cleared.

 

1.       = How do I add multiple elements into a document? Is it supported in the current = release?

 

For = e.g.:

 

Consider that, the = following document is available on the server:

 

<service uri=3D"sip:correctname@example.com">

<list name=3D"family">

<rl:entry = uri=3D"sip:vernon.keel@example.com"/>

</list>

<packages>

<package>presence</package>

</packages>

</service>

 =

a.       How do I add new entries [multiple] in = <list name =3D “family”>.

My XML payload would be something like = this:

 

<rl:entry = uri=3D"sip:johnc@example.com"/>

=

<rl:entry = uri=3D"sip:a19500@example.com"/>

 =

            =

b.      What should be the XCAP = URI?

 

 =

Thanks,

John

 =

 

 

 

 

 

 

------=_NextPart_000_006D_01C5E9DD.5ECD8A60-- --===============1255995744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1255995744==-- From simple-bounces@ietf.org Tue Nov 15 03:38:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwKh-0003gg-CJ; Tue, 15 Nov 2005 03:38:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwKf-0003gY-Vj for simple@megatron.ietf.org; Tue, 15 Nov 2005 03:38:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09742 for ; Tue, 15 Nov 2005 03:37:53 -0500 (EST) Received: from rat01038.dc-ratingen.de ([195.233.129.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebwbn-0003uL-1V for simple@ietf.org; Tue, 15 Nov 2005 03:56:12 -0500 Received: from heinz.vodafone-is.de (heinz_e0 [195.233.128.26]) by rat01038.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id jAF8c2i0012390 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Nov 2005 09:38:02 +0100 (MET) Received: from gpsmxr04.gps.internal.vodafone.com ([195.232.231.115]) by heinz.vodafone-is.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id jAF8bvk4003158; Tue, 15 Nov 2005 09:38:01 +0100 (MET) Received: from gpsmx11.gps.internal.vodafone.com ([145.230.1.15]) by gpsmxr04.gps.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Nov 2005 09:37:58 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Date: Tue, 15 Nov 2005 08:38:00 -0000 Message-ID: <6C742B4BEC7D1D4FB045E74BB625987B0569494E@gpsmx11.gps.internal.vodafone.com> Thread-Topic: Comments on draft-ala-kurikka-simple-pidfconn-00 Thread-Index: AcXpv+KqkWOWcfQaS2CgVg1yovInMA== From: "Zisimopoulos, Haris, VF-Group" To: , X-OriginalArrivalTime: 15 Nov 2005 08:37:58.0763 (UTC) FILETIME=[E1E1E3B0:01C5E9BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: Subject: [Simple] Comments on draft-ala-kurikka-simple-pidfconn-00 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hello, First I think that the concept of connectivity as part of the Presence = information should be further exploited and this proposal provides a = good start. I have some comments though for this I-D: - First of all I think it is unclear what is defined as connectivity. = For example it can be (wireless) network attachement, allocation if IP = adress, registration in the SIP domain with that contact? It needs to be = clarified. - Determining the QoS characteristics (eg throughput, delay etc) just = from the type of the wireless technology is very na=EFve. Even wireless = networks that perform over-the-air resource reservation keep these = resources only if there is traffic flowing. Also the allocation of = resources largely depends on the overall congestion in the network and = can vary over time. Therefore here it would be wiser I think just to = indicate the network attachment to a particular network type (eg = UMTS,GPRS etc) which *generally* gives some static QoS characteristics = indication. For example indicating to the watcher that I am attached in = WLAN generally speaking gives the indication that I have better QoS than = GPRS (apart from when I am in IETF :-)). I am very sceptical that you = can go beyond that unless you do some real-time measurements in the = terminal which is something not advisable. - The idea of charging indication in an on/off manner is interesting but = I think it becomes very complicated if you attempt to go beyond that. So = the sentence under 2.3.2.1 that "... followed by any number of elements = from different namespaces for an extended specification of the billing." = is very difficult to be implemented in a real world.=20 Best regards, Haris Haris Zisimopoulos Vodafone Group Research & Development - UK Telephone: +44 (0)7919994709 E-mail: haris.zisimopoulos@vodafone.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 15 03:38:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwKq-0003hf-3B; Tue, 15 Nov 2005 03:38:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwKo-0003hS-4S for simple@megatron.ietf.org; Tue, 15 Nov 2005 03:38:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09745 for ; Tue, 15 Nov 2005 03:38:01 -0500 (EST) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebwbz-0003ut-CH for simple@ietf.org; Tue, 15 Nov 2005 03:56:20 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAF8cNMQ030624; Tue, 15 Nov 2005 10:38:24 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Nov 2005 10:38:21 +0200 Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Nov 2005 10:38:20 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id jAF8cKY03671; Tue, 15 Nov 2005 10:38:20 +0200 (EET) Received: from xitami.research.nokia.com (xitami.research.nokia.com [172.21.50.105]) by kusti.research.nokia.com (Postfix) with ESMTP id 436D093B6A; Tue, 15 Nov 2005 10:38:20 +0200 (EET) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by xitami.research.nokia.com (Postfix) with ESMTP id 3AD94369; Tue, 15 Nov 2005 10:38:20 +0200 (EET) Subject: Re: [Simple] Clarification on XCAP From: Jari Urpalainen To: ext Chooracken John In-Reply-To: <006c01c5e9af$45154e60$f402a8c0@cjohn> References: <006c01c5e9af$45154e60$f402a8c0@cjohn> Content-Type: text/plain; charset=utf-8 Date: Tue, 15 Nov 2005 10:38:20 +0200 Message-Id: <1132043900.17168.59.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-OriginalArrivalTime: 15 Nov 2005 08:38:20.0392 (UTC) FILETIME=[EEC63680:01C5E9BF] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext01.nokia.com id jAF8cNMQ030624 X-Spam-Score: 1.1 (+) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Tue, 2005-11-15 at 12:09 +0530, ext Chooracken John wrote: > Hi, >=20 > =20 >=20 > After going though the XCAP draft, I have a query to be > cleared. >=20 > =20 >=20 > 1. How do I add multiple elements into a document? Is it > supported in the current release? >=20 > =20 No. There's an expired draft called multi-insert, where unions could be used to add several elements at the same time. >=20 > For e.g.: >=20 > =20 >=20 > Consider that, the following document is available on the server: >=20 > =20 >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > presence >=20 > >=20 > >=20 > =20 >=20 > a. How do I add new entries [multiple] in =E2=80=9Cfamily=E2=80=9D>.=20 >=20 > My XML payload would be something like this: >=20 > =20 >=20 > >=20 > >=20 > =20 >=20 > =20 >=20 > b. What should be the XCAP URI? >=20 > =20 >=20 > =20 >=20 > Thanks, >=20 > John >=20 > =20 >=20 with multi-insert it would be (without escaping of course): ...~~/service/list[@name=3D"family"]/rl:entry[@uri=3D"sip:johnc@example.c= om"]|/service/list[@name=3D"family"]/rl:entry[@uri=3D"sip:a19500@example.= com"]?xmlns(rl=3Durn:...) with payload: an alternative with xml-patch-ops if there were a controversial http patch-method: xmlns=3D"urn:..." xmlns:rl=3D"urn:..." So instead in practice, you'll have to resort to multiple, perhaps pipelined requests to do what you want. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 15 13:42:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5kq-0005NJ-8T; Tue, 15 Nov 2005 13:42:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5ki-0005Mb-UX for simple@megatron.ietf.org; Tue, 15 Nov 2005 13:41:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16772 for ; Tue, 15 Nov 2005 13:41:24 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec61z-0006vk-C8 for simple@ietf.org; Tue, 15 Nov 2005 13:59:48 -0500 Received: from algiers.clic.cs.columbia.edu (algiers.clic.cs.columbia.edu [128.59.15.63]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jAFIfpho015905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Nov 2005 13:41:52 -0500 (EST) Received: from algiers.clic.cs.columbia.edu (localhost [127.0.0.1]) by algiers.clic.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id jAFIflj2020941; Tue, 15 Nov 2005 13:41:47 -0500 Received: (from ac2491@localhost) by algiers.clic.cs.columbia.edu (8.13.1/8.13.1/Submit) id jAFIfiwa020940; Tue, 15 Nov 2005 13:41:44 -0500 X-Authentication-Warning: algiers.clic.cs.columbia.edu: ac2491 set sender to ac2491@cs.columbia.edu using -f Subject: Re: [Simple] Clarification on XCAP From: Anurag Chakravarti To: Jari Urpalainen In-Reply-To: <1132043900.17168.59.camel@hed034-145.research.nokia.com> References: <006c01c5e9af$45154e60$f402a8c0@cjohn> <1132043900.17168.59.camel@hed034-145.research.nokia.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Nov 2005 13:41:43 -0500 Message-Id: <1132080103.20896.3.camel@algiers.clic.cs.columbia.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-16.3) X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 1.9 (+) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Looks like the following path as been taken: Single inserts in XCAP would make things simpler for now with the draft cleaner. Extensions I guess could be revived or worked upon for other purposes. Regards -Anurag On Tue, 2005-11-15 at 10:38 +0200, Jari Urpalainen wrote: > On Tue, 2005-11-15 at 12:09 +0530, ext Chooracken John wrote: > > Hi, > >=20 > > =20 > >=20 > > After going though the XCAP draft, I have a query to be > > cleared. > >=20 > > =20 > >=20 > > 1. How do I add multiple elements into a document? Is it > > supported in the current release? > >=20 > > =20 > No. There's an expired draft called multi-insert, where unions could be > used to add several elements at the same time. > >=20 > > For e.g.: > >=20 > > =20 > >=20 > > Consider that, the following document is available on the server: > >=20 > > =20 > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > presence > >=20 > > > >=20 > > > >=20 > > =20 > >=20 > > a. How do I add new entries [multiple] in > =E2=80=9Cfamily=E2=80=9D>.=20 > >=20 > > My XML payload would be something like this: > >=20 > > =20 > >=20 > > > >=20 > > > >=20 > > =20 > >=20 > > =20 > >=20 > > b. What should be the XCAP URI? > >=20 > > =20 > >=20 > > =20 > >=20 > > Thanks, > >=20 > > John > >=20 > > =20 > >=20 > with multi-insert it would be (without escaping of course): > ...~~/service/list[@name=3D"family"]/rl:entry[@uri=3D"sip:johnc@example.c= om"]|/service/list[@name=3D"family"]/rl:entry[@uri=3D"sip:a19500@example.co= m"]?xmlns(rl=3Durn:...) > with payload: > uri=3D"sip:a19500@example.com"/> >=20 > an alternative with xml-patch-ops if there were a controversial http > patch-method: > xmlns=3D"urn:..." > xmlns:rl=3D"urn:..." > > > > >=20 > So instead in practice, you'll have to resort to multiple, perhaps > pipelined requests to do what you want. > br, > Jari >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 16 02:51:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcI4S-0004MU-W9; Wed, 16 Nov 2005 02:51:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcI4Q-0004MP-W5 for simple@megatron.ietf.org; Wed, 16 Nov 2005 02:51:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07268 for ; Wed, 16 Nov 2005 02:50:34 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcILo-00072h-Fk for simple@ietf.org; Wed, 16 Nov 2005 03:09:05 -0500 Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 4A87A194472 for ; Wed, 16 Nov 2005 08:50:47 +0100 (CET) Received: from [192.168.1.9] ([192.168.1.9]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.0); Wed, 16 Nov 2005 08:54:33 +0100 In-Reply-To: <91C9464F6AFC0647A2D8069E25DBF49601E4342C@EXC01B.cselt.it> References: <91C9464F6AFC0647A2D8069E25DBF49601E4342C@EXC01B.cselt.it> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5c16c9af007178974bb6ed1ca696fc00@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Questions on draft-ietf-simple-filter-format-05 Date: Wed, 16 Nov 2005 08:50:20 +0100 To: Goix Walter X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 16 Nov 2005 07:54:33.0499 (UTC) FILETIME=[FB6FE6B0:01C5EA82] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Nov 14, 2005, at 7:13 PM, Goix Walter wrote: > Hi, > > I have a couple of questions regarding the handling on > filters in an Event Server: > > - when only an filter is present (no ), does the > server need to provide the *whole* document but the excluded part, or > is it implicit? In other words, do the server need an filter > as well to consider the whole document or part of it before to apply > the filter? The draft states " The element is used to define exceptions to the set of XML elements and/or attributes selected by the elements." So having an without an seems to be semantically wrong. > > - when the filter asks for removing a mandatory element, > which is nesting elements from another namespaces, what would be the > result of the exclusion process: is it the full content of the > mandatory element, or only an 'empty' (or minimally valid) element. > Below is an example: > > 1. is a mandatory element within with an only, i.e. > it does not have any attribute nor mandate any sub-element > 2. document in the server is: > > > something > > > > 3. filter contains > > //root/foo > > > 4. Result of filtering process is > (a) > > > > > or (b) > > > something > > > ? (b) is the choice. From the draft "if the step in applying the element value to an XML document results in an invalid document according to the schema, that step MUST be reveresed resulting in the elements and/or attributes being re-introduced into the resulting XML document, with their previous values, in order to make it valid." Thanks, Hisham > > Thanks for the clarification > Walter > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia > S.p.A. > > ==================================================================== > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > ==================================================================== > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 16 06:06:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcL7o-0004MN-5k; Wed, 16 Nov 2005 06:06:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcL7j-0004Lw-OG for simple@megatron.ietf.org; Wed, 16 Nov 2005 06:06:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17123 for ; Wed, 16 Nov 2005 06:06:10 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcLP9-0003pd-UU for simple@ietf.org; Wed, 16 Nov 2005 06:24:44 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 16 Nov 2005 03:06:21 -0800 X-IronPort-AV: i="3.97,337,1125903600"; d="scan'208"; a="365929995:sNHT33546814572" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAGB60Qw007334; Wed, 16 Nov 2005 03:06:19 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 03:06:17 -0800 Received: from [10.10.10.47] ([10.21.80.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 03:06:16 -0800 Message-ID: <437A9E39.4030300@cisco.com> Date: Tue, 15 Nov 2005 21:49:29 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anurag Chakravarti Subject: Re: [Simple] Clarification on XCAP References: <006c01c5e9af$45154e60$f402a8c0@cjohn> <1132043900.17168.59.camel@hed034-145.research.nokia.com> <1132080103.20896.3.camel@algiers.clic.cs.columbia.edu> In-Reply-To: <1132080103.20896.3.camel@algiers.clic.cs.columbia.edu> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 16 Nov 2005 11:06:17.0390 (UTC) FILETIME=[C44A5CE0:01C5EA9D] X-Spam-Score: 1.7 (+) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA17123 Cc: Jari Urpalainen , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Correct. This was a concious decision during the design of xcap. There=20 were a limited number of use cases people had for multiple insert;=20 nothing that couldn't be handled by a series of single inserts. -Jonathan R. Anurag Chakravarti wrote: > Looks like the following path as been taken: > Single inserts in XCAP would make things simpler for now with the draft > cleaner. Extensions I guess could be revived or worked upon for other > purposes. >=20 > Regards > -Anurag >=20 >=20 > On Tue, 2005-11-15 at 10:38 +0200, Jari Urpalainen wrote: >=20 >>On Tue, 2005-11-15 at 12:09 +0530, ext Chooracken John wrote: >> >>>Hi, >>> >>>=20 >>> >>> After going though the XCAP draft, I have a query to be >>>cleared. >>> >>>=20 >>> >>>1. How do I add multiple elements into a document? Is it >>>supported in the current release? >>> >>>=20 >> >>No. There's an expired draft called multi-insert, where unions could be >>used to add several elements at the same time. >> >>>For e.g.: >>> >>>=20 >>> >>>Consider that, the following document is available on the server: >>> >>>=20 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>presence >>> >>> >>> >>> >>> >>>=20 >>> >>>a. How do I add new entries [multiple] in >>=E2=80=9Cfamily=E2=80=9D>.=20 >>> >>>My XML payload would be something like this: >>> >>>=20 >>> >>> >>> >>> >>> >>>=20 >>> >>> =20 >>> >>>b. What should be the XCAP URI? >>> >>>=20 >>> >>>=20 >>> >>>Thanks, >>> >>>John >>> >>>=20 >>> >> >>with multi-insert it would be (without escaping of course): >>...~~/service/list[@name=3D"family"]/rl:entry[@uri=3D"sip:johnc@example= .com"]|/service/list[@name=3D"family"]/rl:entry[@uri=3D"sip:a19500@exampl= e.com"]?xmlns(rl=3Durn:...) >>with payload: >>>uri=3D"sip:a19500@example.com"/> >> >>an alternative with xml-patch-ops if there were a controversial http >>patch-method: >>xmlns=3D"urn:..." >>xmlns:rl=3D"urn:..." >> >> >> >> >> >>So instead in practice, you'll have to resort to multiple, perhaps >>pipelined requests to do what you want. >>br, >>Jari >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 16 07:16:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcMCm-0001Zj-St; Wed, 16 Nov 2005 07:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcMCk-0001Zc-HL for simple@megatron.ietf.org; Wed, 16 Nov 2005 07:15:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20439 for ; Wed, 16 Nov 2005 07:15:24 -0500 (EST) Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcMU7-0005gM-TT for simple@ietf.org; Wed, 16 Nov 2005 07:33:59 -0500 Received: from cjohn ([192.168.2.244]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id jAGCBiT22773; Wed, 16 Nov 2005 17:41:44 +0530 From: "Chooracken John" To: "'Jonathan Rosenberg'" , "'Anurag Chakravarti'" Subject: RE: [Simple] Clarification on XCAP Date: Wed, 16 Nov 2005 17:46:27 +0530 Message-ID: <004e01c5eaa7$94f3c990$f402a8c0@cjohn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <437A9E39.4030300@cisco.com> Importance: Normal X-Spam-Score: 4.0 (++++) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: 7bit Cc: 'Jari Urpalainen' , 'Achuth Kamath' , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Jonathan, Let us consider this particular use case: Suppose the user wants to add a set of members to an existing group, say 10 members. Instead of sending a single request we will have to do with multiple requests [10 in this case]. Some of the drawbacks could be 1. The network might get clogged 2. The user experience will be bad due to the delay in responses. Is it feasible to achieve addition of multiple members, if we do it in the following fashion? 1. We create a resource list containing the 10 members. Now with a single HTTP PUT, we upload the document to the shared XDMS with the document URI, say mylist@server.com 2. Now we send a HTTP PUT to PoC XDMS, which takes care of Groups with the reference to mylist@server.com in it's payload as an reference. Using this we can manage with only two requests/responses. Regards, John / Achuth Kodiak Networks -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Wednesday, November 16, 2005 8:19 AM To: Anurag Chakravarti Cc: Jari Urpalainen; simple@ietf.org Subject: Re: [Simple] Clarification on XCAP Correct. This was a concious decision during the design of xcap. There were a limited number of use cases people had for multiple insert; nothing that couldn't be handled by a series of single inserts. -Jonathan R. Anurag Chakravarti wrote: > Looks like the following path as been taken: > Single inserts in XCAP would make things simpler for now with the draft > cleaner. Extensions I guess could be revived or worked upon for other > purposes. > > Regards > -Anurag > > > On Tue, 2005-11-15 at 10:38 +0200, Jari Urpalainen wrote: > >>On Tue, 2005-11-15 at 12:09 +0530, ext Chooracken John wrote: >> >>>Hi, >>> >>> >>> >>> After going though the XCAP draft, I have a query to be >>>cleared. >>> >>> >>> >>>1. How do I add multiple elements into a document? Is it >>>supported in the current release? >>> >>> >> >>No. There's an expired draft called multi-insert, where unions could be >>used to add several elements at the same time. >> >>>For e.g.: >>> >>> >>> >>>Consider that, the following document is available on the server: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>presence >>> >>> >>> >>> >>> >>> >>> >>>a. How do I add new entries [multiple] in >>"family">. >>> >>>My XML payload would be something like this: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>b. What should be the XCAP URI? >>> >>> >>> >>> >>> >>>Thanks, >>> >>>John >>> >>> >>> >> >>with multi-insert it would be (without escaping of course): >>...~~/service/list[@name="family"]/rl:entry[@uri="sip:johnc@example.co m"]|/service/list[@name="family"]/rl:entry[@uri="sip:a19500@example.com" ]?xmlns(rl=urn:...) >>with payload: >>>uri="sip:a19500@example.com"/> >> >>an alternative with xml-patch-ops if there were a controversial http >>patch-method: >>xmlns="urn:..." >>xmlns:rl="urn:..." >> >> >> >> >> >>So instead in practice, you'll have to resort to multiple, perhaps >>pipelined requests to do what you want. >>br, >>Jari >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 16 11:01:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPjC-0001Wc-8x; Wed, 16 Nov 2005 11:01:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPj8-0001Vm-T9 for simple@megatron.ietf.org; Wed, 16 Nov 2005 11:01:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05994 for ; Wed, 16 Nov 2005 11:01:05 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcQ0a-0006US-8R for simple@ietf.org; Wed, 16 Nov 2005 11:19:42 -0500 Received: from [172.17.2.252] (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jAGG14Hd093324 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 16 Nov 2005 10:01:06 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <004e01c5eaa7$94f3c990$f402a8c0@cjohn> References: <004e01c5eaa7$94f3c990$f402a8c0@cjohn> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <377DA779-F7BA-4B91-925F-764B7FA01BE8@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Simple] Clarification on XCAP Date: Wed, 16 Nov 2005 10:01:05 -0600 To: Chooracken John X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 1.1 (+) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Content-Transfer-Encoding: 7bit Cc: 'Jari Urpalainen' , 'Achuth Kamath' , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org John - The group thoroughly went through use cases like this before making the design decision in question. Please look through the archives in spring 2004 (the threads are easy to find). There is a copy of the expired -multiple- draft mentioned below at http://www.softarmor.com/wgdb/docs/draft-rosenberg-simple-xcap- multiple-00.txt that you might also find helpful. We aren't going to change that decision for the base specification. After reviewing the history, if you want to work on an extension, there are several people here that will help discuss it. Thanks, RjS On Nov 16, 2005, at 6:16 AM, Chooracken John wrote: > Jonathan, > > Let us consider this particular use case: > > Suppose the user wants to add a set of members to an existing > group, say 10 members. Instead of sending a single request we will > have > to do with multiple requests [10 in this case]. Some of the drawbacks > could be > > 1. The network might get clogged > 2. The user experience will be bad due to the delay in > responses. > > > Is it feasible to achieve addition of multiple members, if we do it in > the following fashion? > > 1. We create a resource list containing the 10 members. Now with > a single HTTP PUT, we upload the document to the shared XDMS with the > document URI, say mylist@server.com > > 2. Now we send a HTTP PUT to PoC XDMS, which takes care of > Groups with the reference to mylist@server.com in it's payload as an > reference. > > > Using this we can manage with only two requests/responses. > > > > Regards, > John / Achuth > > Kodiak Networks > > > > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf > Of Jonathan Rosenberg > Sent: Wednesday, November 16, 2005 8:19 AM > To: Anurag Chakravarti > Cc: Jari Urpalainen; simple@ietf.org > Subject: Re: [Simple] Clarification on XCAP > > Correct. This was a concious decision during the design of xcap. There > were a limited number of use cases people had for multiple insert; > nothing that couldn't be handled by a series of single inserts. > > -Jonathan R. > > Anurag Chakravarti wrote: > >> Looks like the following path as been taken: >> Single inserts in XCAP would make things simpler for now with the > draft >> cleaner. Extensions I guess could be revived or worked upon for other >> purposes. >> >> Regards >> -Anurag >> >> >> On Tue, 2005-11-15 at 10:38 +0200, Jari Urpalainen wrote: >> >>> On Tue, 2005-11-15 at 12:09 +0530, ext Chooracken John wrote: >>> >>>> Hi, >>>> >>>> >>>> >>>> After going though the XCAP draft, I have a query to be >>>> cleared. >>>> >>>> >>>> >>>> 1. How do I add multiple elements into a document? Is it >>>> supported in the current release? >>>> >>>> >>> >>> No. There's an expired draft called multi-insert, where unions could > be >>> used to add several elements at the same time. >>> >>>> For e.g.: >>>> >>>> >>>> >>>> Consider that, the following document is available on the server: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> presence >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> a. How do I add new entries [multiple] in >>> "family">. >>>> >>>> My XML payload would be something like this: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> b. What should be the XCAP URI? >>>> >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> John >>>> >>>> >>>> >>> >>> with multi-insert it would be (without escaping of course): >>> ...~~/service/list[@name="family"]/rl:entry >>> [@uri="sip:johnc@example.co > m"]|/service/list[@name="family"]/rl:entry > [@uri="sip:a19500@example.com" > ]?xmlns(rl=urn:...) >>> with payload: >>> >> uri="sip:a19500@example.com"/> >>> >>> an alternative with xml-patch-ops if there were a controversial http >>> patch-method: >>> xmlns="urn:..." >>> xmlns:rl="urn:..." >>> >>> >>> >>> >>> >>> So instead in practice, you'll have to resort to multiple, perhaps >>> pipelined requests to do what you want. >>> br, >>> Jari >>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 17 05:43:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EchEy-0002yI-IV; Thu, 17 Nov 2005 05:43:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EchEw-0002xn-Df for simple@megatron.ietf.org; Thu, 17 Nov 2005 05:43:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13059 for ; Thu, 17 Nov 2005 05:43:04 -0500 (EST) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EchWW-0004Jq-O1 for simple@ietf.org; Thu, 17 Nov 2005 06:01:51 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IQ300C78HSDQI@dns1.cselt.it> for simple@ietf.org; Thu, 17 Nov 2005 11:43:25 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 11:43:25 +0100 Date: Thu, 17 Nov 2005 11:43:25 +0100 From: Goix Walter Subject: RE: [Simple] Questions on draft-ietf-simple-filter-format-05 To: Hisham Khartabil Message-id: <91C9464F6AFC0647A2D8069E25DBF496E01747@EXC01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Simple] Questions on draft-ietf-simple-filter-format-05 thread-index: AcXqgoMPUIHqM8VRQo2K6bcDe8te1AA4LulQ Content-Class: urn:content-classes:message X-OriginalArrivalTime: 17 Nov 2005 10:43:25.0632 (UTC) FILETIME=[BD127400:01C5EB63] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: quoted-printable Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Thanks Hisham for the clarifications. For the second question we had the = same understanding of the paragraph. For the first one, it may be useful to clarify the text in the next = version of the draft so that implementers know how to behave in = generating/handling filters, since the XSD cannot express this = constraint. That would also help interop a lot. Cheers, Walter -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: mercoled=EC 16 novembre 2005 8.50 To: Goix Walter Cc: simple@ietf.org Subject: Re: [Simple] Questions on draft-ietf-simple-filter-format-05 On Nov 14, 2005, at 7:13 PM, Goix Walter wrote: > Hi, > > I have a couple of questions regarding the handling on =20 > filters in an Event Server: > > - when only an filter is present (no ), does the=20 > server need to provide the *whole* document but the excluded part, or=20 > is it implicit? In other words, do the server need an filter = > as well to consider the whole document or part of it before to apply=20 > the filter? The draft states " The element is used to define exceptions to the set of XML elements and/or attributes selected by the elements." So having an without an seems to be semantically=20 wrong. > > - when the filter asks for removing a mandatory element,=20 > which is nesting elements from another namespaces, what would be the=20 > result of the exclusion process: is it the full content of the=20 > mandatory element, or only an 'empty' (or minimally valid) element.=20 > Below is an example: > > 1. is a mandatory element within with an only, i.e. = > it does not have any attribute nor mandate any sub-element > 2. document in the server is: > > > something > > > > 3. filter contains > > //root/foo > > > 4. Result of filtering process is > (a) > > > > > or (b) > > > something > > > ? (b) is the choice. From the draft "if the step in applying the element value to an XML document results in an invalid document according to the schema, that step MUST be reveresed resulting in the elements and/or attributes being re-introduced into the resulting XML document, with their previous values, in order to make it valid." Thanks, Hisham > > Thanks for the clarification > Walter > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia=20 > S.p.A. > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 17 07:35:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcizX-0007KF-HW; Thu, 17 Nov 2005 07:35:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcizW-0007KA-Tq for simple@megatron.ietf.org; Thu, 17 Nov 2005 07:35:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19535 for ; Thu, 17 Nov 2005 07:35:16 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcjHA-000864-84 for simple@ietf.org; Thu, 17 Nov 2005 07:54:04 -0500 Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id ECD77194480 for ; Thu, 17 Nov 2005 13:35:34 +0100 (CET) Received: from [192.168.1.9] ([192.168.1.9]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.0); Thu, 17 Nov 2005 13:39:24 +0100 In-Reply-To: <91C9464F6AFC0647A2D8069E25DBF496E01747@EXC01B.cselt.it> References: <91C9464F6AFC0647A2D8069E25DBF496E01747@EXC01B.cselt.it> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <67a85ff32b0395119f458298cf66104e@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] Questions on draft-ietf-simple-filter-format-05 Date: Thu, 17 Nov 2005 13:35:07 +0100 To: Goix Walter X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 17 Nov 2005 12:39:24.0571 (UTC) FILETIME=[F0EC46B0:01C5EB73] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: quoted-printable Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Nov 17, 2005, at 11:43 AM, Goix Walter wrote: > Thanks Hisham for the clarifications. For the second question we had=20= > the same understanding of the paragraph. > > For the first one, it may be useful to clarify the text in the next=20 > version of the draft so that implementers know how to behave in=20 > generating/handling filters, since the XSD cannot express this=20 > constraint. That would also help interop a lot. This draft is in the RFC editor queue, so there will be no next=20 version. But I still have the change to update the text during Author's=20= 48 hours just before it becomes an RFC. Thanks, Hisham > > Cheers, > Walter > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: mercoled=EC 16 novembre 2005 8.50 > To: Goix Walter > Cc: simple@ietf.org > Subject: Re: [Simple] Questions on draft-ietf-simple-filter-format-05 > > > On Nov 14, 2005, at 7:13 PM, Goix Walter wrote: > >> Hi, >> >> I have a couple of questions regarding the handling on >> filters in an Event Server: >> >> - when only an filter is present (no ), does the >> server need to provide the *whole* document but the excluded part, or >> is it implicit? In other words, do the server need an = filter >> as well to consider the whole document or part of it before to apply >> the filter? > > The draft states > > " The element is used to define exceptions to the set of=20= > XML > elements and/or attributes selected by the elements." > > So having an without an seems to be semantically > wrong. > >> >> - when the filter asks for removing a mandatory element, >> which is nesting elements from another namespaces, what would be the >> result of the exclusion process: is it the full content of the >> mandatory element, or only an 'empty' (or minimally valid) element. >> Below is an example: >> >> 1. is a mandatory element within with an only, = i.e. >> it does not have any attribute nor mandate any sub-element >> 2. document in the server is: >> >> >> something >> >> >> >> 3. filter contains >> >> //root/foo >> >> >> 4. Result of filtering process is >> (a) >> >> >> >> >> or (b) >> >> >> something >> >> >> ? > > (b) is the choice. > > =46rom the draft > > "if > the step in applying the element value to an XML = document > results in an invalid document according to the schema, that step > MUST be reveresed resulting in the elements and/or attributes = being > re-introduced into the resulting XML document, with their previous > values, in order to make it valid." > > Thanks, > Hisham > >> >> Thanks for the clarification >> Walter >> >> >> Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia >> S.p.A. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> CONFIDENTIALITY NOTICE >> This message and its attachments are addressed solely to the persons >> above and may contain confidential information. If you have received >> the message in error, be informed that any use of the content hereof >> is prohibited. Please return it immediately to the sender and delete >> the message. Should you have any questions, please send an e_mail to >> MailAdmin@tilab.com. Thank you >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia=20 > S.p.A. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 17 20:25:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecv0C-0005hH-1J; Thu, 17 Nov 2005 20:25:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecv0A-0005hC-8b for simple@megatron.ietf.org; Thu, 17 Nov 2005 20:25:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10493 for ; Thu, 17 Nov 2005 20:24:43 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcvHt-0002gZ-RG for simple@ietf.org; Thu, 17 Nov 2005 20:43:39 -0500 Received: from algiers.clic.cs.columbia.edu (algiers.clic.cs.columbia.edu [128.59.15.63]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jAI1PDho019755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Nov 2005 20:25:13 -0500 (EST) Received: from algiers.clic.cs.columbia.edu (localhost [127.0.0.1]) by algiers.clic.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id jAI1PDpD029984; Thu, 17 Nov 2005 20:25:13 -0500 Received: (from ac2491@localhost) by algiers.clic.cs.columbia.edu (8.13.1/8.13.1/Submit) id jAI1PC4S029983; Thu, 17 Nov 2005 20:25:12 -0500 X-Authentication-Warning: algiers.clic.cs.columbia.edu: ac2491 set sender to ac2491@cs.columbia.edu using -f From: Anurag Chakravarti To: jdrosen@cisco.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 17 Nov 2005 20:25:12 -0500 Message-Id: <1132277112.29883.6.camel@algiers.clic.cs.columbia.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-16.3) X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 1.4 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] IRI-URI XCAP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, Presence Authz Policy draft and geo-priv draft mention about IRIs as one of the ways of identifying a resource. In the use case where an XCAP application usage needs to support IRIs, is the XCAPServer responsible for converting the IRI encoding to an URI (UTF-8 format) by following the steps defined in draft-duerst-iri-11. Or such an use case is not supported by XCAP protocol. I am a bit confused on the above, could someone please comment on it. Regards -Anurag _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 18 02:57:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed17E-00077e-ID; Fri, 18 Nov 2005 02:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed17C-00077Z-Gm for simple@megatron.ietf.org; Fri, 18 Nov 2005 02:56:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28951 for ; Fri, 18 Nov 2005 02:56:22 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed1Oz-0005Tn-P1 for simple@ietf.org; Fri, 18 Nov 2005 03:15:22 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAI7q6P0007287 for ; Fri, 18 Nov 2005 09:52:09 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Nov 2005 09:56:53 +0200 Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 18 Nov 2005 09:56:53 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id jAI7uqJ18486 for ; Fri, 18 Nov 2005 09:56:52 +0200 (EET) Received: from xitami.research.nokia.com (xitami.research.nokia.com [172.21.50.105]) by kusti.research.nokia.com (Postfix) with ESMTP id BBB6393B6A for ; Fri, 18 Nov 2005 09:56:52 +0200 (EET) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by xitami.research.nokia.com (Postfix) with ESMTP id B3AB72E3 for ; Fri, 18 Nov 2005 09:56:52 +0200 (EET) From: Jari Urpalainen To: Simple WG Content-Type: text/plain Date: Fri, 18 Nov 2005 09:56:52 +0200 Message-Id: <1132300612.25660.41.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Nov 2005 07:56:53.0214 (UTC) FILETIME=[A38A37E0:01C5EC15] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Subject: [Simple] xml-patch-ops issues X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi all! In Vancouver BoF some issues were left open: 1. Some folks wanted to have text node patching. I've studied the situation and it seems that it is fairly trivial to add this sort of patching to the framework once a proper algorithm exists. So what I'm proposing is that I'll add a schema type to the framework. As you always need to include this schema with some other spec that defines the mime type, it doesn't harm applications like partial-pidf and xcap-diff which do not need this feature. It is somewhat feature creep, but as it is so simple it doesn't much delay this work. So the new type: [base64 encoded string] RFCs 3229 & 3284 list the algorithm alternatives. gdiff is not a standards track doc and vcdiff has some ipr issues. However, the purpose is to show that it is easy to integrate this feature if some application needs it. 2. There has been a request to e.g. remove multiple attributes at the same time by using an everywhere "//" selector, like . As this operation has performance implications I'm inclined not to include it, some reasoning: Why not limit to attributes only, search elements as well. How about replacing multiple elements with the same new content. With elements you would have to check for nested elements, how it it supposed to work. It isn't that difficult to implement (actually i've done it with xcap-multi-insert), but I'm still hesitant to add any feature creep that it isn't really necessary. This could be added to spec with e.g. a 'msel' selector (multi-selector) and with a new type inherited from the "base" patch operation types. As this adds quite a lot of text and yes something "nice to have", I don't want to add it here. So if this is really must feature it can be added later with a separate spec. Any comments, objections ? br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 18 04:00:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed278-0007G8-MO; Fri, 18 Nov 2005 04:00:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed277-0007G3-Sx for simple@megatron.ietf.org; Fri, 18 Nov 2005 04:00:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02354 for ; Fri, 18 Nov 2005 04:00:21 -0500 (EST) Received: from gw15.rotuaari.net ([212.50.147.115] helo=gw15.virtues.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed2Ou-0007fJ-7n for simple@ietf.org; Fri, 18 Nov 2005 04:19:22 -0500 Received: from AllIPIBM1 (unknown [212.50.147.101]) by gw15.virtues.local (Postfix) with ESMTP id A2873E4640; Fri, 18 Nov 2005 11:00:32 +0200 (EET) From: "Jussi Ala-Kurikka" To: , Date: Fri, 18 Nov 2005 11:00:32 +0200 Organization: MediaTeam/University of Oulu Message-ID: <000901c5ec1e$87df4ea0$3529140a@AllIPIBM1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXpv+KqkWOWcfQaS2CgVg1yovInMACRVLOgAAV7uRA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Simple] RE: Comments on draft-ala-kurikka-simple-pidfconn-00 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hello, Comments inline. > -----Original Message----- > From: Zisimopoulos, Haris, VF-Group > [mailto:Haris.Zisimopoulos@vodafone.com] > Sent: 15. marraskuuta 2005 10:38 > To: jussi.ala-kurikka@ee.oulu.fi; simple@ietf.org > Subject: Comments on draft-ala-kurikka-simple-pidfconn-00 >=20 > Hello, >=20 > First I think that the concept of connectivity as part of the Presence = > information should be further exploited and this proposal provides a=20 > good start. >=20 > I have some comments though for this I-D: >=20 > - First of all I think it is unclear what is defined as connectivity.=20 > For example it can be (wireless) network attachement, allocation if IP = > adress, registration in the SIP domain with that contact? It needs to=20 > be clarified. The draft was not explicit on this, I agree. A connectivity is the = physical layer last-hop technology with which an end-user's device is connected = to a network (e.g. 802.3u, 802.11b, GPRS). In order for the presentity to = convey its connectivity features, it should naturally itself know them first. Without measurements it is typically only possible to know the = theoretical features of a connectivity (if even those). However, as Henning = Schulzrinne pointed out in the SIMPLE meeting, the connectivity is not always the = most constraining part of the end-to-end connection. E.g. in airplanes it = might be the airplane<->Internet connection that is the most constraining one. = Of course, the more accurate the conveyed data, the better the watchers are able to determine which service to use, if any. > - Determining the QoS characteristics (eg throughput, delay > etc) just from the type of the wireless technology is very na=EFve. = Even=20 > wireless networks that perform over-the-air resource reservation keep=20 > these resources only if there is traffic flowing. Also the allocation=20 > of resources largely depends on the overall congestion in the network=20 > and can vary over time. Therefore here it would be wiser I think just=20 > to indicate the network attachment to a particular network type (eg=20 > UMTS,GPRS etc) which *generally* gives some static QoS characteristics = > indication. For example indicating to the watcher that I am attached=20 > in WLAN generally speaking gives the indication that I have better QoS = > than GPRS (apart from when I am in IETF :-)). I am very sceptical that = > you can go beyond that unless you do some real-time measurements in=20 > the terminal which is something not advisable. The reason why we wanted to model the features of a connectivity instead = of conveying the network type directly is that this way we do not need to enumerate the values of the connectivity element for all the possible connectivities. Simply saying "this element contains a name of the used connectivity" will not probably do, as it would likely produce interoperability issues (e.g. a presentity could state either WLAN or 802.11b). We would need to do the enumeration either in the draft or to specify a reference. I could not find any such reference within the = IETF. Of course, the list of connectivities should also be kept up-to-date, = adding all future connectivities. It would perhaps be easier for the presentity to convey just the network type. He would not need to know the theoretical "best-case" features of = the used connectivity but just the type, which could maybe be extracted from = the device name provided by hardware. However, for expressing the network = type to be of any value, the watcher would need to be able to somehow map the network type to its typical features. Therefore, the watcher would = basically need to know the mapping between names and features of the = connectivities of the presentities they are watching.=20 In an implementation based on the current draft, this mapping would not = be needed. Users/software would just need to know for example the = throughput requirements of the sessions they would like to initiate. Presentities = could also convey measured data, e.g. maximum throughput, if they had that information. > - The idea of charging indication in an on/off manner is interesting=20 > but I think it becomes very complicated if you attempt to go beyond=20 > that. So the sentence under 2.3.2.1 that "... followed by any number=20 > of elements from different namespaces for an extended specification of = > the billing." is very difficult to be implemented in a real world. That might be true. However, we did not want to rule that out either. In fact, as commented during the discussion after the SIMPLE meeting, even saying that charge is false or true could be difficult because sometimes there are also flat fees with a limited amount of megabytes per month. = The megabytes exceeding that amount do in fact affect the presentity's = billing. In that case, the value of would need to be updated when = crossing that amount. -Jussi _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 18 05:42:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3hM-0005xi-M6; Fri, 18 Nov 2005 05:42:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3hK-0005vW-Ss for simple@megatron.ietf.org; Fri, 18 Nov 2005 05:42:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08100 for ; Fri, 18 Nov 2005 05:41:52 -0500 (EST) Received: from smtp3.clb.oleane.net ([213.56.31.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed3z4-0002dz-6W for simple@ietf.org; Fri, 18 Nov 2005 06:00:49 -0500 Received: from Pavillonquatre ([194.3.133.88]) (authenticated) by smtp3.clb.oleane.net with ESMTP id jAIAftlk007868 for ; Fri, 18 Nov 2005 11:41:58 +0100 Message-Id: <200511181041.jAIAftlk007868@smtp3.clb.oleane.net> From: "Chantal Ladouce" To: Date: Fri, 18 Nov 2005 11:41:33 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXsLKTYo4+2tIRLQv65PTBdHjenfA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Subject: [Simple] IMS at the International SIP 2006 - Paris - France X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2103535078==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============2103535078== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01C5EC35.06EDB270" This is a multi-part message in MIME format. ------=_NextPart_000_004F_01C5EC35.06EDB270 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Carriers Experience on SIP based IMS Real Size Experiments . Extending SIP IMS Architecture from Wireless to Wireline Networks . Challenges in IMS Testing Everything you need to know on IMS and SIP will be delivered at the International SIP conference to be held in Paris next 21-24 February 2006. Get all details at: http://www.upperside.fr/sip2006/sip2006program.htm#day2 ------=_NextPart_000_004F_01C5EC35.06EDB270 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Carriers = Experience on SIP based IMS Real Size = Experiments

=

. Extending = SIP IMS Architecture from Wireless to Wireline Networks

=

. Challenges in = IMS Testing

=

 

Everything you = need to know on IMS and SIP will be delivered at the International SIP = conference to be held in Paris next 21-24 February 2006.

=

 

Get all details = at:

=

 

http://w= ww.upperside.fr/sip2006/sip2006program.htm#day2

 

 

------=_NextPart_000_004F_01C5EC35.06EDB270-- --===============2103535078== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============2103535078==-- From simple-bounces@ietf.org Fri Nov 18 18:24:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdFaO-0008VV-MR; Fri, 18 Nov 2005 18:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdFaM-0008Ud-JN; Fri, 18 Nov 2005 18:24:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17690; Fri, 18 Nov 2005 18:23:27 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdFsH-0007Jt-JY; Fri, 18 Nov 2005 18:42:34 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 18 Nov 2005 18:23:53 -0500 X-IronPort-AV: i="3.97,348,1125892800"; d="scan'208"; a="76103886:sNHT23961432" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAINNoln003649; Fri, 18 Nov 2005 18:23:50 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 18:23:50 -0500 Received: from [10.242.20.81] ([10.86.240.215]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 18:23:49 -0500 Message-ID: <437E6284.8080900@cisco.com> Date: Fri, 18 Nov 2005 18:23:48 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anurag Chakravarti References: <1132277112.29883.6.camel@algiers.clic.cs.columbia.edu> In-Reply-To: <1132277112.29883.6.camel@algiers.clic.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Nov 2005 23:23:49.0563 (UTC) FILETIME=[217798B0:01C5EC97] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , simple@ietf.org Subject: [Simple] Re: IRI-URI XCAP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Adding geopriv since this is a common issue. It depends on whether the scheme itself supports IRI. For SIP, it doesn't, so the xcap server wouldn't do any conversion. For schemes that support IRI, the common policy draft does need to say which format the IRI is stored in. We are having similar discussions around domain names and IDNs. We should probably be consistent. -Jonathan R. Anurag Chakravarti wrote: > Hi, > > Presence Authz Policy draft and geo-priv draft mention about IRIs as one > of the ways of identifying a resource. > > In the use case where an XCAP application usage needs to support IRIs, > is the XCAPServer responsible for converting the IRI encoding to an URI > (UTF-8 format) by following the steps defined in draft-duerst-iri-11. > Or such an use case is not supported by XCAP protocol. > > I am a bit confused on the above, could someone please comment on it. > > Regards > -Anurag > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 18 18:42:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdFsA-0002kC-0s; Fri, 18 Nov 2005 18:42:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdFs8-0002k7-5t for simple@megatron.ietf.org; Fri, 18 Nov 2005 18:42:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22221 for ; Fri, 18 Nov 2005 18:41:49 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdGA4-0000bL-Be for simple@ietf.org; Fri, 18 Nov 2005 19:00:56 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 18 Nov 2005 15:42:15 -0800 X-IronPort-AV: i="3.97,348,1125903600"; d="scan'208"; a="367442626:sNHT25456280" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAINgCCJ008325; Fri, 18 Nov 2005 15:42:14 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 18:42:11 -0500 Received: from [10.242.20.81] ([10.86.240.215]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 18:42:11 -0500 Message-ID: <437E66D2.9000100@cisco.com> Date: Fri, 18 Nov 2005 18:42:10 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chooracken John Subject: Re: [Simple] Clarification on XCAP References: <004e01c5eaa7$94f3c990$f402a8c0@cjohn> In-Reply-To: <004e01c5eaa7$94f3c990$f402a8c0@cjohn> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Nov 2005 23:42:11.0629 (UTC) FILETIME=[B25985D0:01C5EC99] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: 'Jari Urpalainen' , 'Achuth Kamath' , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Chooracken John wrote: > Jonathan, > > Let us consider this particular use case: > > Suppose the user wants to add a set of members to an existing > group, say 10 members. Instead of sending a single request we will have > to do with multiple requests [10 in this case]. Not likely. This use case was brought up. Xcap is usually driven by a human user. They don't add names in bulk; they're likely to enter one at a time, hitting "add" or "enter" after each one, with each one taking some number of seconds to enter on the UI. In such a case, it is more likely they would get added one at a time with xcap. The only real case that was made for a bulk add of users to a list was if you do the above operation on an airplane, and then your phone tries to sync this when you power on the phone when you land. This was deemed sufficiently corner case to not try to optimize for it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 18 22:30:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdJQo-0006hW-3d; Fri, 18 Nov 2005 22:30:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdJQl-0006h9-QE; Fri, 18 Nov 2005 22:30:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02351; Fri, 18 Nov 2005 22:29:47 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdJik-0005dr-1e; Fri, 18 Nov 2005 22:48:58 -0500 Received: from [127.0.0.1] (razor.cs.columbia.edu [128.59.16.8]) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jAJ3TBX1016646; Fri, 18 Nov 2005 22:30:20 -0500 (EST) In-Reply-To: <437E6284.8080900@cisco.com> References: <1132277112.29883.6.camel@algiers.clic.cs.columbia.edu> <437E6284.8080900@cisco.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <551EE738-255A-4767-9C8B-DEC3CB7CA997@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Fri, 18 Nov 2005 22:25:18 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.733) X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , simple@ietf.org Subject: [Simple] Re: [Geopriv] Re: IRI-URI XCAP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a slightly different topic, but there are indications that SIP URIs can indeed be treated as IRIs, without explicit definition, at least from my reading of the IRI spec. We should discuss this with the IRI authors, as it would avoid having to solve the problem later. On Nov 18, 2005, at 6:23 PM, Jonathan Rosenberg wrote: > Adding geopriv since this is a common issue. > > It depends on whether the scheme itself supports IRI. For SIP, it > doesn't, so the xcap server wouldn't do any conversion. For schemes > that support IRI, the common policy draft does need to say which > format the IRI is stored in. We are having similar discussions > around domain names and IDNs. We should probably be consistent. > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 21 06:38:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeA0M-0001CC-44; Mon, 21 Nov 2005 06:38:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeA0K-0001C7-PI for simple@megatron.ietf.org; Mon, 21 Nov 2005 06:38:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22406 for ; Mon, 21 Nov 2005 06:37:58 -0500 (EST) From: ac2491@cs.columbia.edu Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeAIj-0007yM-Bt for simple@ietf.org; Mon, 21 Nov 2005 06:57:40 -0500 Received: from hydra.cs.columbia.edu (IDENT:FgYDvS6OSpfmQomAkrvudO9RdNHpbYE/@hydra.cs.columbia.edu [128.59.16.129]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jALBcQiP005346 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 21 Nov 2005 06:38:27 -0500 (EST) Received: from webmail.cs.columbia.edu (IDENT:o5vITc9Aq2Ca6BDHBYraHCp60gquv+vo@localhost [127.0.0.1]) by hydra.cs.columbia.edu (8.12.10/8.12.10) with SMTP id jALBcQah007262; Mon, 21 Nov 2005 06:38:26 -0500 Received: from 24.199.92.69 (SquirrelMail authenticated user ac2491) by webmail.cs.columbia.edu with HTTP; Mon, 21 Nov 2005 06:38:26 -0500 (EST) Message-ID: <32780.24.199.92.69.1132573106.squirrel@webmail.cs.columbia.edu> Date: Mon, 21 Nov 2005 06:38:26 -0500 (EST) To: jdrosen@cisco.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-PerlMx-Spam: Gauge=X, Probability=10%, Report='PRIORITY_NO_NAME 0.716, NO_REAL_NAME 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_PRIORITY 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 2.1 (++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 8bit Cc: simple@ietf.org Subject: [Simple] list-xcap-usage default list name question X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, In resource-lists xcap usage, the default name to the list element has not been specified. How should I interpret it from the clients point of view and the servers point of view. Suppose I use client-I, who adds two contacts to his buddy list, in the default list. This update goes to the XCAPServer, and ther server updates the default list. Here the default list might contain a name or might not contain a name (client xcap-uri governs this) Now I use client-II. client-II initially gets the whole buddy list from the XCAPServer. Client-II now treats the default list as a list with "name=default". So any buddy added goes to a new list called default. Again if I go back to client-I, I see a new list not inteded to be there. The default list should have been only one. Is the above understanding right? If so how does the draft deal with it? Regards -Anurag _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 22 07:43:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeXUM-0003ts-DM; Tue, 22 Nov 2005 07:43:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeXUJ-0003sf-VN for simple@megatron.ietf.org; Tue, 22 Nov 2005 07:43:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12024 for ; Tue, 22 Nov 2005 07:42:29 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeXmu-0000m3-CY for simple@ietf.org; Tue, 22 Nov 2005 08:02:25 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 373434F0028; Tue, 22 Nov 2005 13:42:48 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 13:40:16 +0100 Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 13:40:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Default namespace for pres-rule was [RE: [Simple] I-DACTION:draft-ietf-simple-presence-rules-04.txt ] Date: Tue, 22 Nov 2005 13:40:13 +0100 Message-ID: <2DC267ED40568D4F9AA4F5DF955AF16AB3C9C9@esealmw107.eemea.ericsson.se> Thread-Topic: Default namespace for pres-rule was [RE: [Simple] I-DACTION:draft-ietf-simple-presence-rules-04.txt ] Thread-Index: AcXaxdAuFHdNuKGiSRGzyzKyFsPyowI6xp/QAuv81NA= From: "Anders Lindgren C (HF/EAB)" To: , "Jonathan Rosenberg" X-OriginalArrivalTime: 22 Nov 2005 12:40:16.0085 (UTC) FILETIME=[E3B17050:01C5EF61] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hello, I also have another question. In the XML schema in chapter 6 the element has been removed. Is it a mistake or is the reason that it will be defined in another draft? Thanks Anders Lindgren -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Anders Lindgren C (HF/EAB) Sent: den 7 november 2005 16:53 To: simple@ietf.org Subject: Default namespace for pres-rule was [RE: [Simple] I-DACTION:draft-ietf-simple-presence-rules-04.txt ] Hello, I have a question about which default namespace shall be used for pres-rule. Is it "urn:ietf:params:xml:ns:pres-rules" or "urn:ietf:params:xml:ns:common-policy"? My view is that a chapter ("Default Namespace") is missing in draft defining this. See http://ietf.org/internet-drafts/draft-ietf-simple-xcap-08.txt chapter 5.9 Thanks Anders Lindgren -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: den 27 oktober 2005 08:50 To: i-d-announce@ietf.org Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-04.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Presence Authorization Rules Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-rules-04.txt Pages : 27 Date : 2005-10-26 =09 Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-04. txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presence-rules-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presence-rules-04.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 22 14:23:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eedjh-0003X4-BN; Tue, 22 Nov 2005 14:23:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eedjf-0003Wa-Pd for simple@megatron.ietf.org; Tue, 22 Nov 2005 14:23:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28790 for ; Tue, 22 Nov 2005 14:22:44 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eee2M-0006qF-VO for simple@ietf.org; Tue, 22 Nov 2005 14:42:44 -0500 Received: from reykjavik.clic.cs.columbia.edu (reykjavik.clic.cs.columbia.edu [128.59.15.64]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jAMJNIiP015981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Nov 2005 14:23:18 -0500 (EST) Received: from reykjavik.clic.cs.columbia.edu (localhost [127.0.0.1]) by reykjavik.clic.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id jAMJN5ks020731; Tue, 22 Nov 2005 14:23:08 -0500 Received: (from ac2491@localhost) by reykjavik.clic.cs.columbia.edu (8.13.1/8.13.1/Submit) id jAMJN5d2020730; Tue, 22 Nov 2005 14:23:05 -0500 X-Authentication-Warning: reykjavik.clic.cs.columbia.edu: ac2491 set sender to ac2491@cs.columbia.edu using -f From: Anurag Chakravarti To: jdrosen@cisco.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 22 Nov 2005 14:23:05 -0500 Message-Id: <1132687385.20693.4.camel@reykjavik.clic.cs.columbia.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-16.3) X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.9 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] processContents in resource-list schema X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, In resource-list schema in listType definition we find optional elements possible using the following declaration Here processContents has been left out for the default value. The default value is "strict". Should we not allow this to be "skip" (just check for well-formed-ness)? -Regards anurag _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 24 03:38:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfCcq-000378-P1; Thu, 24 Nov 2005 03:38:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfCco-000373-7f for simple@megatron.ietf.org; Thu, 24 Nov 2005 03:38:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01954 for ; Thu, 24 Nov 2005 03:37:58 -0500 (EST) Received: from [80.74.106.10] (helo=rvil-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfCvp-0002ba-8k for simple@ietf.org; Thu, 24 Nov 2005 03:58:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Nov 2005 10:38:08 +0200 Message-ID: Thread-Topic: draft-ietf-simple-partial-publish-03 - composer's treatment of a partial publish requests Thread-Index: AcXw0mP+jXtli8g8RbiJ6D0OUg8Mog== From: "Anat Angel" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Subject: [Simple] draft-ietf-simple-partial-publish-03 - composer's treatment of a partial publish requests X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1117433049==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1117433049== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F0D2.6550D5E8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F0D2.6550D5E8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 The question I have is about the exact meaning of a operation for the composer:=20 =20 When a certain device sends partial PUBLISH that includes to a certain tuple, does it tell the composer that: Option A: This device does not know what the status of that tuple is. Therefore the composer needs to send other information it might have about this tuple from other devices to the watchers? Option B: All other information that it might have about that tuple (from other devices that also send PUBLISH requests) is not relevant any more and future notifications should not include it? =20 The scenario is best explained in the following example: =20 Composer gets 2 INITIAL PUBLISH requests (from 2 different devices) to the same presentity. =20 Device A sends PUBLISH with 1 tuple with id: tuple1. Device B sends (after A) a PUBLISH with also 1 tuple with id: tuple1 The composer sends a first NOTIFY with full-pidf of tuple1 that it got from device B (because it's more recent) This is based on approach that information inside a more recent PUBLISH is more updated. =20 Now device A sends a MODIFY PUBLISH with of tuple1 and tuple2. =20 What should now be the content of a FULL NOTIFY sent by the composer to watchers? The options can be: - Option A: Composer sends the updated tuple2 + the tuple1 information that it has from B. - Option B: Composer sends just the updated tuple2 data. =20 If we remember that the behavior should be equivalent to the behavior of a FULL MODIFY PUBLISH request (instead of the partial request above) that includes just tuple2 (because the intention is the same) - than option A is more logical. =20 The question is not about the composition policy - it's about the "intention" of the publisher when sending PUBLISH requests that are partial. =20 Regards, Anat =20 ------_=_NextPart_001_01C5F0D2.6550D5E8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

The question I have is about the exact = meaning of a <remove> operation for the composer:

 

When a certain device sends partial = PUBLISH that includes <remove> to a certain tuple, does it tell the composer = that:

Option A: This device does not know what = the status of that tuple is. Therefore the composer needs to send other = information it might have about this tuple from other devices to the = watchers?

Option B: All other information that it = might have about that tuple (from other devices that also send PUBLISH = requests) is not relevant any more and future notifications should not include = it?

 

The scenario is best explained in the = following example:

 

Composer gets 2 = INITIAL PUBLISH requests (from 2 different devices) to the same = presentity.

 

Device A sends = PUBLISH with 1 tuple with id: tuple1.

Device B sends = (after A) a PUBLISH with also 1 tuple with id: tuple1

The composer = sends a first NOTIFY with full-pidf of tuple1 that it got from device B (because = it's more recent)

This is based on = approach that information inside a more recent PUBLISH is more = updated.

 

Now device A = sends a MODIFY PUBLISH with <remove> of tuple1 and <add> = tuple2.

 

What should now = be the content of a FULL NOTIFY sent by the composer to = watchers?

The options can = be:

-      =     Option A: Composer sends the updated = tuple2 + the tuple1 information that it has from B.

-      =     Option B: Composer sends just the updated = tuple2 data.

 

If we remember that the behavior should be equivalent to the behavior of a FULL MODIFY PUBLISH request (instead of = the partial request above) that includes just tuple2 (because the intention = is the same) – than option A is more logical.

 

The question is not about the composition = policy – it's about the "intention" of the publisher when sending = PUBLISH requests that are partial.

 

Regards,

Anat

 

------_=_NextPart_001_01C5F0D2.6550D5E8-- --===============1117433049== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1117433049==-- From simple-bounces@ietf.org Thu Nov 24 06:27:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfFGC-00046G-N8; Thu, 24 Nov 2005 06:27:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfFGB-000466-7V for simple@megatron.ietf.org; Thu, 24 Nov 2005 06:27:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17141 for ; Thu, 24 Nov 2005 06:26:45 -0500 (EST) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfFZB-0000TS-7D for simple@ietf.org; Thu, 24 Nov 2005 06:47:08 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAOBRGJE021350; Thu, 24 Nov 2005 13:27:19 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Nov 2005 13:27:19 +0200 Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 24 Nov 2005 13:27:18 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id jAOBRHF16111; Thu, 24 Nov 2005 13:27:17 +0200 (EET) Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145]) by kusti.research.nokia.com (Postfix) with ESMTP id 4A23B93B82; Thu, 24 Nov 2005 13:27:17 +0200 (EET) Message-ID: <4385A395.5030904@nokia.com> Date: Thu, 24 Nov 2005 13:27:17 +0200 From: Jari Urpalainen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Anat Angel Subject: Re: [Simple] draft-ietf-simple-partial-publish-03 - composer's treatment of a partial publish requests References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Nov 2005 11:27:18.0330 (UTC) FILETIME=[072C89A0:01C5F0EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Anat Angel wrote: >Hi > > > >The question I have is about the exact meaning of a operation >for the composer: > > > >When a certain device sends partial PUBLISH that includes to a >certain tuple, does it tell the composer that: > >Option A: This device does not know what the status of that tuple is. >Therefore the composer needs to send other information it might have >about this tuple from other devices to the watchers? > >Option B: All other information that it might have about that tuple >(from other devices that also send PUBLISH requests) is not relevant any >more and future notifications should not include it? > > > >The scenario is best explained in the following example: > > > >Composer gets 2 INITIAL PUBLISH requests (from 2 different devices) to >the same presentity. > > > >Device A sends PUBLISH with 1 tuple with id: tuple1. > >Device B sends (after A) a PUBLISH with also 1 tuple with id: tuple1 > >The composer sends a first NOTIFY with full-pidf of tuple1 that it got >from device B (because it's more recent) > >This is based on approach that information inside a more recent PUBLISH >is more updated. > > > >Now device A sends a MODIFY PUBLISH with of tuple1 and >tuple2. > > > which is equivalent, if device A had sent a full publish only with (which might be even a smaller payload btw). Partial publish updates are always understood in the context of "patching the full pidf", i.e. to save bandwidth. >What should now be the content of a FULL NOTIFY sent by the composer to >watchers? > >The options can be: > >- Option A: Composer sends the updated tuple2 + the tuple1 >information that it has from B. > >- Option B: Composer sends just the updated tuple2 data. > > > >If we remember that the behavior should be equivalent to the behavior of >a FULL MODIFY PUBLISH request (instead of the partial request above) >that includes just tuple2 (because the intention is the same) - than >option A is more logical. > > > right. >The question is not about the composition policy - it's about the >"intention" of the publisher when sending PUBLISH requests that are >partial. > > imo, this is just about the composition policy, so the actual implementation decides whether the A or B option is selected. B is simpler to implement but A might be more reasonable in general. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Nov 26 13:28:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg4mX-00077D-M8; Sat, 26 Nov 2005 13:28:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg4mW-000778-D2 for simple@megatron.ietf.org; Sat, 26 Nov 2005 13:28:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13023 for ; Sat, 26 Nov 2005 13:27:33 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eg562-0002oe-I8 for simple@ietf.org; Sat, 26 Nov 2005 13:48:26 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 26 Nov 2005 10:28:06 -0800 X-IronPort-AV: i="3.97,380,1125903600"; d="scan'208"; a="234534780:sNHT28881592" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAQIS06e002506; Sat, 26 Nov 2005 10:28:04 -0800 (PST) Received: from 10.21.88.159 ([10.21.88.159]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sat, 26 Nov 2005 18:28:58 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sat, 26 Nov 2005 10:26:01 -0800 From: Cullen Jennings To: "simple@ietf.org" Message-ID: Thread-Topic: Addition to security section draft-ietf-simple-message-sessions Thread-Index: AcXyttpHGKxHMV6qEdqKhwARJEEJ/A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Ben Campbell Subject: [Simple] Addition to security section draft-ietf-simple-message-sessions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org During a review of this draft by a security AD, we got feedback that we needed to add more about how to use TLS where there was no relays. I am proposing we add an additional section 14.3 with some proposed text below. If you want to see this in the context of the draft, you can look at what it might look like at: http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-message-s essions.html http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-message-s essions.txt The text I am proposing to add is .... 14.3. Using TLS in Peer to Peer Mode TLS can be used with a self signed certificate as long as there is a mechanism for both sides to ascertain that the other side used the correct certificate. When used with SDP and SIP, the correct certificate can be verified by passing a fingerprint of the certificate in the SDP and ensuring that the SDP has suitable integrity protection. When SIP is used to transport the SDP, the integrity can be provided by the SIP Identity mechanism. The rest of this section describes the details of this approach. If self-signed certificates are used, the content of the subjectAltName attribute inside the certificate MAY use the uniform resource identifier (URI) of the user. This is useful for debugging purposes only and is not required to bind the certificate to one of the communication endpoints. The subjectAltName is not an important component of the certificate verification. If the endpoint is also able to make anonymous sessions, a distinct, unique certificate MUST be used for this purpose. For an client that works with multiple users, each user SHOULD have its own certificate. The generation of public/private key pairs is relatively expensive. Endpoints are not required to generate certificates for each session. A certificate fingerprint is the output of a one-way hash function computed over the distinguished encoding rules (DER) form of the certificate. The endpoint MUST use the certificate fingerprint attribute as specified in [23] and MUST include this in the SDP. The certificate presented during the TLS handshake needs to match the fingerprint exchanged via the SDP and if the fingerprint does not match the hashed certificate then the endpoint MUST tear down the media session immediately. When using SIP, the integrity of the fingerprint can be ensured through the SIP Identity mechanism [22]. When a client wishes to use SIP to set up a secure MSRP session with another endpoint it sends an offer in a SIP message to the other endpoint. This offer includes, as part of the SDP payload, the fingerprint of the certificate that the endpoint wants to use. The SIP message containing the offer is sent to the offerer's sip proxy which will add an identity header according to the procedures outlined in [22]. When the far endpoint receives the SIP message it can verify the identity of the sender using the identity header. Since the identity header is a digital signature across several SIP headers, in addition to the body or bodies of the SIP message, the receiver can also be certain that the message has not been tampered with after the digital signature was added to the SIP message. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Nov 27 08:54:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgMz1-00053M-4U; Sun, 27 Nov 2005 08:54:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgMyz-00053H-HI for simple@megatron.ietf.org; Sun, 27 Nov 2005 08:54:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16737 for ; Sun, 27 Nov 2005 08:53:38 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgNIe-0004vS-RB for simple@ietf.org; Sun, 27 Nov 2005 09:14:42 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 27 Nov 2005 05:54:10 -0800 X-IronPort-AV: i="3.97,380,1125903600"; d="scan'208"; a="234659336:sNHT28309580" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jARDs8Op007287; Sun, 27 Nov 2005 05:54:08 -0800 (PST) Received: from 10.21.88.113 ([10.21.88.113]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 27 Nov 2005 13:55:06 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 27 Nov 2005 05:54:13 -0800 From: Cullen Jennings To: "simple@ietf.org" Message-ID: Thread-Topic: Addition to security section draft-ietf-simple-message-sessions Thread-Index: AcXyttpHGKxHMV6qEdqKhwARJEEJ/AAozIWB In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Ben Campbell Subject: [Simple] Re: Addition to security section draft-ietf-simple-message-sessions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org One change inline due to comment I got ... On 11/26/05 10:26 AM, "Cullen Jennings" wrote: > > During a review of this draft by a security AD, we got feedback that we > needed to add more about how to use TLS where there was no relays. I am > proposing we add an additional section 14.3 with some proposed text below. > If you want to see this in the context of the draft, you can look at what it > might look like at: > > http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-message-ses > sions.html > > http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-message-ses > sions.txt > > The text I am proposing to add is .... > > 14.3. Using TLS in Peer to Peer Mode > > TLS can be used with a self signed certificate as long as there is a > mechanism for both sides to ascertain that the other side used the correct > certificate. When used with SDP and SIP, the correct certificate can be > verified by passing a fingerprint of the certificate in the SDP and ensuring > that the SDP has suitable integrity protection. When SIP is used to > transport the SDP, the integrity can be provided by the SIP Identity > mechanism. The rest of this section describes the details of this approach. > > If self-signed certificates are used, the content of the subjectAltName > attribute inside the certificate MAY use the uniform resource identifier > (URI) of the user. This is useful for debugging purposes only and is not > required to bind the certificate to one of the communication endpoints. Insert something like ... "Unlike normal TLS operations in this protocol, when doing peer to peer TLS, the" > subjectAltName is not an important component of the certificate > verification. If the endpoint is also able to make anonymous sessions, a > distinct, unique certificate MUST be used for this purpose. For an client > that works with multiple users, each user SHOULD have its own certificate. > The generation of public/private key pairs is relatively expensive. > Endpoints are not required to generate certificates for each session. > > A certificate fingerprint is the output of a one-way hash function computed > over the distinguished encoding rules (DER) form of the certificate. The > endpoint MUST use the certificate fingerprint attribute as specified in [23] > and MUST include this in the SDP. The certificate presented during the TLS > handshake needs to match the fingerprint exchanged via the SDP and if the > fingerprint does not match the hashed certificate then the endpoint MUST > tear down the media session immediately. > > When using SIP, the integrity of the fingerprint can be ensured through the > SIP Identity mechanism [22]. When a client wishes to use SIP to set up a > secure MSRP session with another endpoint it sends an offer in a SIP message > to the other endpoint. This offer includes, as part of the SDP payload, the > fingerprint of the certificate that the endpoint wants to use. The SIP > message containing the offer is sent to the offerer's sip proxy which will > add an identity header according to the procedures outlined in [22]. When > the far endpoint receives the SIP message it can verify the identity of the > sender using the identity header. Since the identity header is a digital > signature across several SIP headers, in addition to the body or bodies of > the SIP message, the receiver can also be certain that the message has not > been tampered with after the digital signature was added to the SIP message. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Nov 27 14:21:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgS5z-0000dl-Rq; Sun, 27 Nov 2005 14:21:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgS5y-0000dZ-Bp for simple@megatron.ietf.org; Sun, 27 Nov 2005 14:21:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18480 for ; Sun, 27 Nov 2005 14:21:10 -0500 (EST) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgSPf-0006Jy-1Z for simple@ietf.org; Sun, 27 Nov 2005 14:42:17 -0500 Received: from [131.161.248.92] (open-131-161-248-92.cliq.com [131.161.248.92]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id jARJLKW14719; Sun, 27 Nov 2005 11:21:20 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2159720116c6fb2266c2aa1e3d270cb3@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Sun, 27 Nov 2005 11:21:24 -0800 To: Cullen Jennings X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: Ben Campbell , Rohan Mahy , "simple@ietf.org" Subject: [Simple] Re: Addition to security section draft-ietf-simple-message-sessions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Nov 26, 2005, at 10:26, Cullen Jennings wrote: > > During a review of this draft by a security AD, we got feedback that we > needed to add more about how to use TLS where there was no relays. I am > proposing we add an additional section 14.3 with some proposed text > below. > If you want to see this in the context of the draft, you can look at > what it > might look like at: > > http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple- > message-s > essions.html > > http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple- > message-s > essions.txt > > The text I am proposing to add is .... > > 14.3. Using TLS in Peer to Peer Mode > > TLS can be used with a self signed certificate as long as there is a > mechanism for both sides to ascertain that the other side used the > correct > certificate. When used with SDP and SIP, the correct certificate can > be > verified by passing a fingerprint of the certificate in the SDP and > ensuring > that the SDP has suitable integrity protection. When SIP is used to > transport the SDP, the integrity can be provided by the SIP Identity > mechanism [22] > . The rest of this section describes the details of this approach. > > If self-signed certificates are used, the content of the subjectAltName > attribute inside the certificate MAY use the uniform resource > identifier > (URI) of the user. This is useful for debugging purposes only and is > not > required to bind the certificate to one of the communication > endpoints. The > subjectAltName is not an important component of the certificate > verification. If the endpoint is also able to make anonymous > sessions, a > distinct, unique certificate MUST be used for this purpose. For an s/an/a/ > client > that works with multiple users, each user SHOULD have its own > certificate. > The generation of public/private key pairs is relatively expensive. > Endpoints are not required to generate certificates for each session. Because the generation....., endpoints... > A certificate fingerprint is the output of a one-way hash function > computed > over the distinguished encoding rules (DER) form of the certificate. > The > endpoint MUST use the certificate fingerprint attribute as specified > in [23] > and MUST include this in the SDP. The certificate presented during > the TLS > handshake needs to match the fingerprint exchanged via the SDP and if > the > fingerprint does not match the hashed certificate then the endpoint > MUST > tear down the media session immediately. > > When using SIP, the integrity of the fingerprint can be ensured > through the > SIP Identity mechanism [22]. When a client wishes to use SIP to set > up a > secure MSRP session with another endpoint it sends an offer in a SIP > message > to the other endpoint. This offer includes, as part of the SDP > payload, the > fingerprint of the certificate that the endpoint wants to use. The SIP > message containing the offer is sent to the offerer's sip proxy which > will > add an identity header according to the procedures outlined in [22]. > When > the far endpoint receives the SIP message it can verify the identity > of the > sender using the identity header. Since the identity header is a > digital > signature across several SIP headers, in addition to the body or > bodies of > the SIP message, the receiver can also be certain that the message has > not > been tampered with after the digital signature was added to the SIP > message. do we want to mention response integrity? thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 28 04:41:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgfVq-0005mZ-4h; Mon, 28 Nov 2005 04:41:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgfVo-0005mU-Om for simple@megatron.ietf.org; Mon, 28 Nov 2005 04:41:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06792 for ; Mon, 28 Nov 2005 04:40:44 -0500 (EST) Received: from comversegw.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout2.icomverse.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egfpd-000687-VC for simple@ietf.org; Mon, 28 Nov 2005 05:01:59 -0500 Received: from il-tlv-bridge01.comverse.com (il-tlv-bridge01.comverse.com [10.115.242.136]) by il-tlv-smtpout2.icomverse.com (8.13.4/8.13.4) with ESMTP id jAS9f91S014693 for ; Mon, 28 Nov 2005 11:41:09 +0200 Received: from il-tlv-mail01.comverse.com ([10.115.242.87]) by il-tlv-bridge01.comverse.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 11:41:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Nov 2005 11:41:05 +0200 Message-ID: <045FA14A4C4F904BA2D5BEDC37E16AF803F24B85@il-tlv-mail01.comverse.com> Thread-Topic: Question on Delivery Reports Thread-Index: AcXz/9oeCB6kyTKISBKz9Axf29kgHA== From: "Weingarten Jerry" To: X-OriginalArrivalTime: 28 Nov 2005 09:41:09.0612 (UTC) FILETIME=[DCC64AC0:01C5F3FF] X-Spam-Score: 0.7 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [Simple] Question on Delivery Reports X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0649089692==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0649089692== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F3FF.DCC316C9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F3FF.DCC316C9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, I have a question concerning the availability of Delivery Reports for SIP MESSAGE. Is there a draft or RFC that describes the possibility of requesting and receiving delivery reports or is there a basic underlying assumption that MESSAGE is only used after we have received confirmation of an INVITE and therefore we assume that the message is always delivered? Yaacov (Jerry) Weingarten Comverse - Standards=20 phone: +972-3-645 2392 mobile: +972-52-854 2392 email: jerry.weingarten@comverse.com ------_=_NextPart_001_01C5F3FF.DCC316C9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Question on Delivery Reports

Hi,

I have a question concerning the availability of Delivery Reports = for SIP MESSAGE.  Is there a draft or RFC that describes the = possibility of requesting and receiving delivery reports or is there a = basic underlying assumption that MESSAGE is only used after we have = received confirmation of an INVITE and therefore we assume that the = message is always delivered?

Yaacov (Jerry) Weingarten

Comverse - Standards

phone: +972-3-645 2392

mobile: +972-52-854 2392

email: = jerry.weingarten@comverse.com

------_=_NextPart_001_01C5F3FF.DCC316C9-- --===============0649089692== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0649089692==-- From simple-bounces@ietf.org Mon Nov 28 04:45:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgfZS-0005xa-47; Mon, 28 Nov 2005 04:45:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgfZP-0005xE-Lu for simple@megatron.ietf.org; Mon, 28 Nov 2005 04:45:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07352 for ; Mon, 28 Nov 2005 04:44:26 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgftE-0006GJ-DX for simple@ietf.org; Mon, 28 Nov 2005 05:05:41 -0500 Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id A99411944BE for ; Mon, 28 Nov 2005 10:44:50 +0100 (CET) Received: from [192.168.1.96] ([192.168.1.96]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Nov 2005 10:49:12 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Date: Mon, 28 Nov 2005 10:44:25 +0100 To: Cullen Jennings X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 28 Nov 2005 09:49:12.0046 (UTC) FILETIME=[FC53E0E0:01C5F400] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: [Simple] Re: Addition to security section draft-ietf-simple-message-sessions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Nov 26, 2005, at 7:26 PM, Cullen Jennings wrote: > > During a review of this draft by a security AD, we got feedback that we > needed to add more about how to use TLS where there was no relays. I am > proposing we add an additional section 14.3 with some proposed text > below. > If you want to see this in the context of the draft, you can look at > what it > might look like at: > > http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple- > message-s > essions.html > > http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple- > message-s > essions.txt > > The text I am proposing to add is .... > > 14.3. Using TLS in Peer to Peer Mode > > TLS can be used with a self signed certificate as long as there is a > mechanism for both sides to ascertain that the other side used the > correct > certificate. When used with SDP and SIP, the correct certificate can > be > verified by passing a fingerprint of the certificate in the SDP and > ensuring > that the SDP has suitable integrity protection. When SIP is used to > transport the SDP, the integrity can be provided by the SIP Identity > mechanism. The rest of this section describes the details of this > approach. > > If self-signed certificates are used, the content of the subjectAltName > attribute inside the certificate MAY use the uniform resource > identifier > (URI) of the user. Can you make it clear here that you are talking about the AoR? > This is useful for debugging purposes only and is not > required to bind the certificate to one of the communication > endpoints. The > subjectAltName is not an important component of the certificate > verification. If the endpoint is also able to make anonymous > sessions, a > distinct, unique certificate MUST be used for this purpose. For an > client > that works with multiple users, each user SHOULD have its own > certificate. > The generation of public/private key pairs is relatively expensive. > Endpoints are not required to generate certificates for each session. > > A certificate fingerprint is the output of a one-way hash function > computed > over the distinguished encoding rules (DER) form of the certificate. > The > endpoint MUST use the certificate fingerprint attribute as specified > in [23] > and MUST include this in the SDP. A bit more text on how to include it in SDP would be good. Example would be great. Thanks, Hisham > The certificate presented during the TLS > handshake needs to match the fingerprint exchanged via the SDP and if > the > fingerprint does not match the hashed certificate then the endpoint > MUST > tear down the media session immediately. > > When using SIP, the integrity of the fingerprint can be ensured > through the > SIP Identity mechanism [22]. When a client wishes to use SIP to set > up a > secure MSRP session with another endpoint it sends an offer in a SIP > message > to the other endpoint. This offer includes, as part of the SDP > payload, the > fingerprint of the certificate that the endpoint wants to use. The SIP > message containing the offer is sent to the offerer's sip proxy which > will > add an identity header according to the procedures outlined in [22]. > When > the far endpoint receives the SIP message it can verify the identity > of the > sender using the identity header. Since the identity header is a > digital > signature across several SIP headers, in addition to the body or > bodies of > the SIP message, the receiver can also be certain that the message has > not > been tampered with after the digital signature was added to the SIP > message. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 28 04:47:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgfbK-00065y-VZ; Mon, 28 Nov 2005 04:47:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgfbI-00065n-Pi for simple@megatron.ietf.org; Mon, 28 Nov 2005 04:47:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07416 for ; Mon, 28 Nov 2005 04:46:24 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egfv8-0006IJ-B1 for simple@ietf.org; Mon, 28 Nov 2005 05:07:39 -0500 Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 4D01819454D for ; Mon, 28 Nov 2005 10:46:58 +0100 (CET) Received: from [192.168.1.96] ([192.168.1.96]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Nov 2005 10:51:19 +0100 In-Reply-To: <045FA14A4C4F904BA2D5BEDC37E16AF803F24B85@il-tlv-mail01.comverse.com> References: <045FA14A4C4F904BA2D5BEDC37E16AF803F24B85@il-tlv-mail01.comverse.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <1f174a919cfe9f66087e4de61470e7fc@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] Question on Delivery Reports Date: Mon, 28 Nov 2005 10:46:33 +0100 To: "Weingarten Jerry" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 28 Nov 2005 09:51:19.0677 (UTC) FILETIME=[4866D2D0:01C5F401] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Nov 28, 2005, at 10:41 AM, Weingarten Jerry wrote: > Hi, > > I have a question concerning the availability of Delivery Reports for=20= > SIP MESSAGE.=A0 Is there a draft or RFC that describes the possibility=20= > of requesting and receiving delivery reports or is there a basic=20 > underlying assumption that MESSAGE is only used after we have received=20= > confirmation of an INVITE and therefore we assume that the message is=20= > always delivered? Please check http://www.ietf.org/internet-drafts/draft-burger-simple-imdn-02.txt The next version will be a SIMPLE WG item. Thanks, Hisham > > Yaacov (Jerry) Weingarten > > Comverse - Standards > > phone: +972-3-645 2392 > > mobile: +972-52-854 2392 > > email: jerry.weingarten@comverse.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 28 07:04:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EghkS-0007ar-Lk; Mon, 28 Nov 2005 07:04:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EghkR-0007XW-M0 for simple@megatron.ietf.org; Mon, 28 Nov 2005 07:04:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23657 for ; Mon, 28 Nov 2005 07:04:00 -0500 (EST) Received: from web31804.mail.mud.yahoo.com ([68.142.207.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Egi4E-0002Zy-QI for simple@ietf.org; Mon, 28 Nov 2005 07:25:15 -0500 Received: (qmail 95084 invoked by uid 60001); 28 Nov 2005 12:04:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sbDoFke9HmJyWuYAIeuE6Hk0aAU0nvxYP9QIsK1c2QmSZJjzcXlfoX2XwBO7FewCw+LIuJhe7lyF3BLqz1WcXxPAI+9p/e+jOb1r7PdNHVn8fTp3jlT5bZ14LnYPTHeAkGl8dBHo/mLErnAhn0Id9cxPZgs6xMrIwpq/Meb2aao= ; Message-ID: <20051128120429.95082.qmail@web31804.mail.mud.yahoo.com> Received: from [210.5.196.6] by web31804.mail.mud.yahoo.com via HTTP; Mon, 28 Nov 2005 04:04:28 PST Date: Mon, 28 Nov 2005 04:04:28 -0800 (PST) From: Behrad Zari To: simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 2.8 (++) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 8bit Cc: Afshin Afzali Subject: [Simple] SIP Notification Problem X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Howdy All, We're testing own Sip Presence server with eyebeam softphone and the there's no success in the notify request sent by server. When comparing the message flow to RFC3856 Section 8 Example Message Flow I find no problem! I don't why the NOTIFY is not considered in current dialog by the client!? Any Suggestions? This is our message flow down below: WE RECEIVE THIS: ------------------------------------- SUBSCRIBE sip:afshin@cc.basamad.acc;transport=udp SIP/2.0 Via: SIP/2.0/UDP 192.168.128.30:5081;branch=z9hG4bK-d87543-e777ef57d3723756-1--d87543-;rport Max-Forwards: 70 Contact: To: From: "Behrad";tag=fe05df14 Call-ID: fc511d4e3e719a65@YmVocmFkLmNjLmJhc2FtYWQuYWNj CSeq: 1 SUBSCRIBE Expires: 3600 Accept: multipart/related, application/rlmi+xml, application/pidf+xml, application/xpidf+xml Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Supported: eventlist User-Agent: eyeBeam release 3010n stamp 19039 Event: presence Content-Length: 0 WE SEND A 202 AND A NOTIFY FOR INCOMING SUBSCRIBE: ----------------------------------------------------------------------- 16:53:38.4 RECEIVING FROM: 192.168.128.30:2751 SIP/2.0 202 Accepted To: ;tag=xtbi5e Content-Length: 0 CSeq: 1 SUBSCRIBE Call-ID: fc511d4e3e719a65@YmVocmFkLmNjLmJhc2FtYWQuYWNj Via: SIP/2.0/UDP 192.168.128.30:5081;branch=z9hG4bK-d87543-e777ef57d3723756-1--d87543-;rport From: Behrad ;tag=fe05df14 Expires: 3600 16:53:38.5 RECEIVING FROM: 192.168.128.30:2751 NOTIFY sip:behrad@192.168.128.30:5081;transport=udp SIP/2.0 To: Behrad ;tag=fe05df14 Content-Length: 513 CSeq: 1 NOTIFY Subscription-State: active;expires=360 Call-ID: fc511d4e3e719a65@YmVocmFkLmNjLmJhc2FtYWQuYWNj Event: presence Via: SIP/2.0/UDP 192.168.128.30:5060;branch=z9hG4bKrog33a From: ;tag=xtbi5e Content-Type: application/pidf+xml Max-Forwards: 70 sip:afshin2@cc.basamad.accopen WE GET THIS FROM CLIENT AND ALSO FACE AN EXCEPTION FROM SERVER ------------------------------------------------------------------------------------ 16:53:38.5 SENDING TO: 192.168.128.30:5060 SIP/2.0 481 Call/Transaction Does Not Exist Via: SIP/2.0/UDP 192.168.128.30:5060;branch=z9hG4bKrog33a To: "Behrad ";tag=fe05df14 From: ;tag=xtbi5e Call-ID: fc511d4e3e719a65@YmVocmFkLmNjLmJhc2FtYWQuYWNj CSeq: 1 NOTIFY Accept-Language: en Content-Length: 0 Thanks, --Behrad __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 28 07:52:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgiUQ-0000Xq-Ga; Mon, 28 Nov 2005 07:52:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgiUL-0000Vi-T1 for simple@megatron.ietf.org; Mon, 28 Nov 2005 07:52:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29188 for ; Mon, 28 Nov 2005 07:51:26 -0500 (EST) Received: from smtp12.clb.oleane.net ([213.56.31.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgioD-0004Cl-FL for simple@ietf.org; Mon, 28 Nov 2005 08:12:42 -0500 Received: from Pavillonquatre ([194.3.133.88]) (authenticated) by smtp12.clb.oleane.net with ESMTP id jASCpb01019028 for ; Mon, 28 Nov 2005 13:51:54 +0100 Message-Id: <200511281251.jASCpb01019028@smtp12.clb.oleane.net> From: "Chantal Ladouce" To: Date: Mon, 28 Nov 2005 13:51:24 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX0GnAhW3iTEnURTVOFhCLAK4xeMQ== X-Spam-Score: 0.2 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Subject: [Simple] WiMAX Summit 06 - Paris - France X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0173948484==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0173948484== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0343_01C5F422.D2406C70" This is a multi-part message in MIME format. ------=_NextPart_000_0343_01C5F422.D2406C70 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit WiMAX Summit 06: Incumbent and New Entrant Operators Architectures The WiMAX Summit 2006 will be held on February 21 to 24 at the Sofitel Bercy hotel in Paris. Capitalizing on the 2005 edition success, the organizer, Upper Side plans to welcome more than 200 participants and more than 20 exhibitors, making WiMAX Summit the most important event in Europe. The conference will largely be devoted to case studies presented by both incumbent and new entrant operators who have set up WiMAX infrastructures. Get all details on the following link: http://www.upperside.fr/wimax2006/wimax2006intro.htm ------=_NextPart_000_0343_01C5F422.D2406C70 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

WiMAX = Summit 06: Incumbent and New Entrant Operators = Architectures

 

The WiMAX Summit 2006 will be held on = February 21 to = 24 at the Sofitel Bercy hotel in Paris.
Capitalizing on the 2005 edition success, the organizer, Upper Side = plans to welcome more than 200 participants and more than 20 exhibitors, making = WiMAX Summit the most important event in Europe.

 

The conference will largely be devoted to case = studies presented by both incumbent and new entrant operators who have set up = WiMAX infrastructures.  

Get all details on the following = link:

 

http://www.upperside.fr/wimax2006/wimax2006intro.htm<= /a>

 

------=_NextPart_000_0343_01C5F422.D2406C70-- --===============0173948484== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0173948484==-- From simple-bounces@ietf.org Mon Nov 28 15:58:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egq4t-0002UR-7Y; Mon, 28 Nov 2005 15:58:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egq4s-0002Ty-4Z for simple@megatron.ietf.org; Mon, 28 Nov 2005 15:58:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06317 for ; Mon, 28 Nov 2005 15:57:37 -0500 (EST) Received: from [200.123.145.66] (helo=ad01.voipgroup.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgqOm-0007IR-IQ for simple@ietf.org; Mon, 28 Nov 2005 16:18:58 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 28 Nov 2005 17:58:17 -0300 Message-ID: <1553FEFFDAE48E45B2D0AB20777EB57B2971BF@ad01.voipgroup.com> Thread-Topic: IM thread-index: AcX0XnB4gM27vmomSralb6+vH7HskQ== From: "Fernando BERRETTA" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Subject: [Simple] IM X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0499683592==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0499683592== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F45E.750042D0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F45E.750042D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello, =20 I want to add IM support for our proxy and I would like to know what RFC/s / Draft/s I should should base this service on? =20 I've seen some drafts /RFCs but I'm not sure all is there =20 Could some one guide me please? =20 Drafts / RFC I've seen are: =20 rfc3428 rfc3903 rfc2779 rfc2778 draft-ietf-sipping-uri-list-subscribe-04.txt =20 =20 =20 ------_=_NextPart_001_01C5F45E.750042D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello,

 

I want to add IM support for our proxy and I would = like to know what RFC/s  / Draft/s I should should base this service = on?

 

I’ve seen some drafts /RFCs but I’m not = sure all is there

 

Could some one guide me = please?

 

Drafts / RFC I’ve seen = are:

 

rfc3428

rfc3903

rfc2779

rfc2778

draft-ietf-sipping-uri-list-subscribe-04.txt

 

 

 

------_=_NextPart_001_01C5F45E.750042D0-- --===============0499683592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0499683592==-- From simple-bounces@ietf.org Mon Nov 28 20:24:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EguEL-0001Cc-QT; Mon, 28 Nov 2005 20:24:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EguEG-0001CM-Tc for simple@megatron.ietf.org; Mon, 28 Nov 2005 20:24:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21025 for ; Mon, 28 Nov 2005 20:23:36 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EguYD-0005IC-LX for simple@ietf.org; Mon, 28 Nov 2005 20:45:00 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IQP00KJN04MLT@szxga01-in.huawei.com> for simple@ietf.org; Tue, 29 Nov 2005 09:29:10 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IQP0018L04M0V@szxga01-in.huawei.com> for simple@ietf.org; Tue, 29 Nov 2005 09:29:10 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IQP00DU60D92C@szxml01-in.huawei.com>; Tue, 29 Nov 2005 09:34:21 +0800 (CST) Date: Tue, 29 Nov 2005 09:20:58 +0800 From: Xiao Wang Subject: RE: [Simple] IM In-reply-to: <1553FEFFDAE48E45B2D0AB20777EB57B2971BF@ad01.voipgroup.com> To: "'Fernando BERRETTA'" Message-id: <013201c5f483$271025f0$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0488301972==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0488301972== Content-type: multipart/alternative; boundary="Boundary_(ID_FtpGoyTiQoIc9tZvuI65JQ)" This is a multi-part message in MIME format. --Boundary_(ID_FtpGoyTiQoIc9tZvuI65JQ) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hello, Fernando All of the document in the SIMPLE that you need known. In the particular, IM can be divided to two different main classes. One is page-mode message, other is session-mode message. page-mode message refer to rfc3428, session-mode message refer to 'draft-ietf-simple-message-sessions-12.txt', 'draft-ietf-simple-msrp-relays-05.txt'.Another relative documents are rfc3994, 'draft-burger-simple-imdn-02.txt' and 'draft-ietf-sipping-uri-list-message-04.txt'. Xiao -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Fernando BERRETTA Sent: Tuesday, November 29, 2005 4:58 AM To: simple@ietf.org Subject: [Simple] IM Hello, I want to add IM support for our proxy and I would like to know what RFC/s / Draft/s I should should base this service on? I've seen some drafts /RFCs but I'm not sure all is there Could some one guide me please? Drafts / RFC I've seen are: rfc3428 rfc3903 rfc2779 rfc2778 draft-ietf-sipping-uri-list-subscribe-04.txt --Boundary_(ID_FtpGoyTiQoIc9tZvuI65JQ) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hello, Fernando

       All of the document in the SIMPLE that you need known.

       In the particular, IM can be divided to two different main classes.

   One is page-mode message, other is session-mode message. page-mode message

   refer to rfc3428, session-mode message refer to ‘draft-ietf-simple-message-sessions-12.txt’,

  ‘draft-ietf-simple-msrp-relays-05.txt’.Another relative documents are rfc3994, ‘draft-burger-simple-imdn-02.txt’

  and ‘draft-ietf-sipping-uri-list-message-04.txt’.

 

 

Xiao

-----Original Message-----
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Fernando BERRETTA
Sent: Tuesday, November 29, 2005 4:58 AM
To: simple@ietf.org
Subject: [Simple] IM

 

Hello,

 

I want to add IM support for our proxy and I would like to know what RFC/s  / Draft/s I should should base this service on?

 

I’ve seen some drafts /RFCs but I’m not sure all is there

 

Could some one guide me please?

 

Drafts / RFC I’ve seen are:

 

rfc3428

rfc3903

rfc2779

rfc2778

draft-ietf-sipping-uri-list-subscribe-04.txt

 

 

 

--Boundary_(ID_FtpGoyTiQoIc9tZvuI65JQ)-- --===============0488301972== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0488301972==-- From simple-bounces@ietf.org Tue Nov 29 00:43:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgyHI-0008EJ-1A; Tue, 29 Nov 2005 00:43:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgyHH-0008DY-0N for simple@megatron.ietf.org; Tue, 29 Nov 2005 00:43:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15388 for ; Tue, 29 Nov 2005 00:42:57 -0500 (EST) Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgybF-0004mh-8L for simple@ietf.org; Tue, 29 Nov 2005 01:04:23 -0500 Received: from cjohn ([192.168.2.244]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id jAT5eET02609; Tue, 29 Nov 2005 11:10:15 +0530 From: "Chooracken John" To: "'Behrad Zari'" , Subject: RE: [Simple] SIP Notification Problem Date: Tue, 29 Nov 2005 11:15:03 +0530 Message-ID: <017701c5f4a8$0c53d1b0$f402a8c0@cjohn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <20051128120429.95082.qmail@web31804.mail.mud.yahoo.com> X-Spam-Score: 2.9 (++) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Cc: 'Afshin Afzali' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi Behrad, After going though the flow, I find the following issues: 1. The server is not adding "Contact:" header field in both 202 and NOTIFY. This is mandatory in RFC 3265, section 7.1 2. " transport=udp" is being added in the Request URI. Regards, John -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Behrad Zari Sent: Monday, November 28, 2005 5:34 PM To: simple@ietf.org Cc: Afshin Afzali Subject: [Simple] SIP Notification Problem Howdy All, We're testing own Sip Presence server with eyebeam softphone and the there's no success in the notify request sent by server. When comparing the message flow to RFC3856 Section 8 Example Message Flow I find no problem! I don't why the NOTIFY is not considered in current dialog by the client!? Any Suggestions? This is our message flow down below: WE RECEIVE THIS: ------------------------------------- SUBSCRIBE sip:afshin@cc.basamad.acc;transport=udp SIP/2.0 Via: SIP/2.0/UDP 192.168.128.30:5081;branch=z9hG4bK-d87543-e777ef57d3723756-1--d87543-;rp ort Max-Forwards: 70 Contact: To: From: "Behrad";tag=fe05df14 Call-ID: fc511d4e3e719a65@YmVocmFkLmNjLmJhc2FtYWQuYWNj CSeq: 1 SUBSCRIBE Expires: 3600 Accept: multipart/related, application/rlmi+xml, application/pidf+xml, application/xpidf+xml Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Supported: eventlist User-Agent: eyeBeam release 3010n stamp 19039 Event: presence Content-Length: 0 WE SEND A 202 AND A NOTIFY FOR INCOMING SUBSCRIBE: ----------------------------------------------------------------------- 16:53:38.4 RECEIVING FROM: 192.168.128.30:2751 SIP/2.0 202 Accepted To: ;tag=xtbi5e Content-Length: 0 CSeq: 1 SUBSCRIBE Call-ID: fc511d4e3e719a65@YmVocmFkLmNjLmJhc2FtYWQuYWNj Via: SIP/2.0/UDP 192.168.128.30:5081;branch=z9hG4bK-d87543-e777ef57d3723756-1--d87543-;rp ort From: Behrad ;tag=fe05df14 Expires: 3600 16:53:38.5 RECEIVING FROM: 192.168.128.30:2751 NOTIFY sip:behrad@192.168.128.30:5081;transport=udp SIP/2.0 To: Behrad ;tag=fe05df14 Content-Length: 513 CSeq: 1 NOTIFY Subscription-State: active;expires=360 Call-ID: fc511d4e3e719a65@YmVocmFkLmNjLmJhc2FtYWQuYWNj Event: presence Via: SIP/2.0/UDP 192.168.128.30:5060;branch=z9hG4bKrog33a From: ;tag=xtbi5e Content-Type: application/pidf+xml Max-Forwards: 70 sip:afshin2@cc.basamad.accopen WE GET THIS FROM CLIENT AND ALSO FACE AN EXCEPTION FROM SERVER ------------------------------------------------------------------------ ------------ 16:53:38.5 SENDING TO: 192.168.128.30:5060 SIP/2.0 481 Call/Transaction Does Not Exist Via: SIP/2.0/UDP 192.168.128.30:5060;branch=z9hG4bKrog33a To: "Behrad ";tag=fe05df14 From: ;tag=xtbi5e Call-ID: fc511d4e3e719a65@YmVocmFkLmNjLmJhc2FtYWQuYWNj CSeq: 1 NOTIFY Accept-Language: en Content-Length: 0 Thanks, --Behrad __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 29 01:34:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egz4r-0000WW-RT; Tue, 29 Nov 2005 01:34:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egz4p-0000WM-SC for simple@megatron.ietf.org; Tue, 29 Nov 2005 01:34:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20124 for ; Tue, 29 Nov 2005 01:34:11 -0500 (EST) From: meera.balu@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgzOU-0006Ma-7b for simple@ietf.org; Tue, 29 Nov 2005 01:55:37 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 5254D205E4 for ; Tue, 29 Nov 2005 11:50:42 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 2DF45205E0 for ; Tue, 29 Nov 2005 11:50:42 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Nov 2005 12:03:54 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple] SIP Notification Problem Date: Tue, 29 Nov 2005 12:03:32 +0530 Message-ID: <25BCA7DFCBA19D46B8C519C146430A94011050F2@BLR-EC-MBX02.wipro.com> Thread-Topic: [Simple] SIP Notification Problem Thread-Index: AcX0FCk7+UePTZpXRme24SD1XnU74wAksqSg To: , X-OriginalArrivalTime: 29 Nov 2005 06:33:54.0624 (UTC) FILETIME=[DE9CEC00:01C5F4AE] X-Spam-Score: 0.6 (/) X-Scan-Signature: 0dcdaa57c570c86b2e4beb0ed476393e Cc: afzali@basamadco.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1205440002==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1205440002== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F4AE.DD54F3BD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F4AE.DD54F3BD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 found few odd things in the message flow.=20 1. Contact is a mandatory header in NOTIFY which is missing in the NOTIFY message given here. it should have generated a diff error response (400 bad request ?)=20 2. in the given message flow, 'subscription-state' header value is 'active' in the NOTIFY sent subsequent to '202 Accepted' .=20 '202 Accepted' is used to convey that the subscription is pending and in the subsequent NOTIFY, you may want to send 'subscription-state' header value as 'pending'.=20 Otherwise, you can send 200 ok followed by NOTIFY with the value of 'active' in the 'subscription-state' header.=20 btw, which version of eyeBeam are you using ?=20 I heard that there are problems with beta version of eyeBeam while handling 202 accepted.=20 Rgds Meera=20 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of > Behrad Zari > Sent: Monday, November 28, 2005 5:34 PM > To: simple@ietf.org > Cc: Afshin Afzali > Subject: [Simple] SIP Notification Problem >=20 > Howdy All, > We're testing own Sip Presence server with eyebeam > softphone and the there's no success in the notify > request sent by server. > When comparing the message flow to RFC3856 Section 8 > Example Message Flow I find no problem! I don't why > the NOTIFY is not considered in current dialog by the > client!? > Any Suggestions? > This is our message flow down below: >=20 > WE RECEIVE THIS: > ------------------------------------- > SUBSCRIBE sip:afshin@cc.basamad.acc;transport=3Dudp > SIP/2.0 > Via: SIP/2.0/UDP > = 192.168.128.30:5081;branch=3Dz9hG4bK-d87543-e777ef57d3723756-1--d87543- > ;rport > Max-Forwards: 70 > Contact: > > To: > From: "Behrad";tag=3Dfe05df14 > Call-ID: fc511d4e3e719a65@YmVocmFkLmNjLmJhc2FtYWQuYWNj > CSeq: 1 SUBSCRIBE > Expires: 3600 > Accept: multipart/related, application/rlmi+xml, > application/pidf+xml, application/xpidf+xml > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, > NOTIFY, MESSAGE, SUBSCRIBE, INFO > Supported: eventlist > User-Agent: eyeBeam release 3010n stamp 19039 > Event: presence > Content-Length: 0 >=20 > WE SEND A 202 AND A NOTIFY FOR INCOMING SUBSCRIBE: > ----------------------------------------------------------------------- > 16:53:38.4 > RECEIVING FROM: 192.168.128.30:2751 > SIP/2.0 202 Accepted > To: ;tag=3Dxtbi5e > Content-Length: 0 > CSeq: 1 SUBSCRIBE > Call-ID: fc511d4e3e719a65@YmVocmFkLmNjLmJhc2FtYWQuYWNj > Via: SIP/2.0/UDP > = 192.168.128.30:5081;branch=3Dz9hG4bK-d87543-e777ef57d3723756-1--d87543- > ;rport > From: Behrad ;tag=3Dfe05df14 > Expires: 3600 >=20 > 16:53:38.5 > RECEIVING FROM: 192.168.128.30:2751 > NOTIFY sip:behrad@192.168.128.30:5081;transport=3Dudp > SIP/2.0 > To: Behrad ;tag=3Dfe05df14 > Content-Length: 513 > CSeq: 1 NOTIFY > Subscription-State: active;expires=3D360 > Call-ID: fc511d4e3e719a65@YmVocmFkLmNjLmJhc2FtYWQuYWNj > Event: presence > Via: SIP/2.0/UDP > 192.168.128.30:5060;branch=3Dz9hG4bKrog33a > From: ;tag=3Dxtbi5e > Content-Type: application/pidf+xml > Max-Forwards: 70 > xmlns=3D"urn:ietf:params:xml:ns:pidf"xmlns:pp=3D"urn:ietf:params:xml:ns:p= idf :person"x > mlns:et=3D"urn:ietf:params:xml:ns:pidf:rpid:rpid- > tuple"xmlns:ep=3D"urn:ietf:params:xml:ns:pidf:rpid:rpid- > person"xmlns:es=3D"urn:ietf:params:xml:ns:pidf:rpid:status:rpid- > status"xmlns:ci=3D"urn:ietf:params:xml:ns:pidf:cipid"entity=3D"sip:afshin= 2@c c.basamad. > acc"> id=3D"f1391660"> priority=3D"1">sip:afshin2@cc.basamad.accopen > >=20 > WE GET THIS FROM CLIENT AND ALSO FACE AN EXCEPTION > FROM SERVER > ------------------------------------------------------------------------ ------------ > 16:53:38.5 > SENDING TO: 192.168.128.30:5060 > SIP/2.0 481 Call/Transaction Does Not Exist > Via: SIP/2.0/UDP > 192.168.128.30:5060;branch=3Dz9hG4bKrog33a > To: "Behrad ";tag=3Dfe05df14 > From: ;tag=3Dxtbi5e > Call-ID: fc511d4e3e719a65@YmVocmFkLmNjLmJhc2FtYWQuYWNj > CSeq: 1 NOTIFY > Accept-Language: en > Content-Length: 0 >=20 > Thanks, >=20 > --Behrad >=20 >=20 >=20 > __________________________________ > Start your day with Yahoo! - Make it your home page! > http://www.yahoo.com/r/hs >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple ------_=_NextPart_001_01C5F4AE.DD54F3BD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Simple] SIP Notification Problem

Hi,

found few odd things in the message flow. =

1. Contact is a mandatory header in NOTIFY which is = missing in the NOTIFY = message = given here.  = it should have generated a diff error response (400 bad = request ?) =

2. in the given message flow, 'subscription-state' header = value is 'active' in the NOTIFY sent subsequent to '202 Accepted' . =

'202 Accepted' is used to convey that the subscription is = pending and in the subsequent NOTIFY, you may want to send = 'subscription-state' header value as 'pending'.

Otherwise, you can send 200 ok followed by NOTIFY with = the value of 'active' in the 'subscription-state' header. =

btw, which version of eyeBeam are you using ?

I heard that there = are = problems with beta = version of eyeBeam while handling 202 accepted.

Rgds

Meera



> -----Original = Message-----

> From: = simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of

> Behrad = Zari

> Sent: Monday, = November 28, 2005 5:34 PM

> To: = simple@ietf.org

> Cc: Afshin = Afzali

> Subject: [Simple] = SIP Notification Problem

>

> Howdy = All,

> We're testing own = Sip Presence server with eyebeam

> softphone and the = there's no success in the notify

> request sent by = server.

> When comparing = the message flow to RFC3856 Section 8

> Example Message = Flow I find no problem! I don't why

> the NOTIFY is not = considered in current dialog by the

> client!?

> Any = Suggestions?

> This is our = message flow down below:

>

> WE RECEIVE = THIS:

> -------------------------------------

> SUBSCRIBE = sip:afshin@cc.basamad.acc;transport=3Dudp

> SIP/2.0

> Via: = SIP/2.0/UDP

> 192.168.128.30:5081;branch=3Dz9hG4bK-d87543-e777ef57d37237= 56-1--d87543-

> ;rport

> Max-Forwards: = 70

> Contact:

> <sip:behrad@192.168.128.30:5081;transport=3Dudp>

> To: = <sip:afshin@cc.basamad.acc>

> From: = "Behrad"<sip:behrad@cc.basamad.acc>;tag=3Dfe05df14=

> Call-ID: = fc511d4e3e719a65@YmVocmFkLmNjLmJhc2FtYWQuYWNj

> CSeq: 1 = SUBSCRIBE

> Expires: = 3600

> Accept: = multipart/related, application/rlmi+xml,

> application/pidf+xml, = application/xpidf+xml

> Allow: INVITE, = ACK, CANCEL, OPTIONS, BYE, REFER,

> NOTIFY, MESSAGE, = SUBSCRIBE, INFO

> Supported: = eventlist

> User-Agent: = eyeBeam release 3010n stamp 19039

> Event: = presence

> Content-Length: = 0

>

> WE SEND A 202 AND = A NOTIFY FOR INCOMING SUBSCRIBE:

> ----------------------------------------------------------= -------------

> 16:53:38.4

> RECEIVING FROM: = 192.168.128.30:2751

> SIP/2.0 202 = Accepted

> To: = <sip:afshin@cc.basamad.acc>;tag=3Dxtbi5e

> Content-Length: = 0

> CSeq: 1 = SUBSCRIBE

> Call-ID: = fc511d4e3e719a65@YmVocmFkLmNjLmJhc2FtYWQuYWNj

> Via: = SIP/2.0/UDP

> 192.168.128.30:5081;branch=3Dz9hG4bK-d87543-e777ef57d37237= 56-1--d87543-

> ;rport

> From: Behrad = <sip:behrad@cc.basamad.acc>;tag=3Dfe05df14

> Expires: = 3600

>

> 16:53:38.5

> RECEIVING FROM: = 192.168.128.30:2751

> NOTIFY = sip:behrad@192.168.128.30:5081;transport=3Dudp

> SIP/2.0

> To: Behrad = <sip:behrad@cc.basamad.acc>;tag=3Dfe05df14

> Content-Length: = 513

> CSeq: 1 = NOTIFY

> Subscription-State: = active;expires=3D360

> Call-ID: = fc511d4e3e719a65@YmVocmFkLmNjLmJhc2FtYWQuYWNj

> Event: = presence

> Via: = SIP/2.0/UDP

> 192.168.128.30:5060;branch=3Dz9hG4bKrog33a

> From: = <sip:afshin@cc.basamad.acc>;tag=3Dxtbi5e

> Content-Type: = application/pidf+xml

> Max-Forwards: = 70

> <?xml = version=3D"1.0" = encoding=3D"UTF-8"?><presence

> xmlns=3D"urn:ietf:params:xml:ns:pidf"xmlns:pp=3D= "urn:ietf:params:xml:ns:pidf:person"x

> mlns:et=3D"urn:ietf:params:xml:ns:pidf:rpid:rpid-

> tuple"xmlns:ep=3D"urn:ietf:params:xml:ns:pidf:rp= id:rpid-

> person"xmlns:es=3D"urn:ietf:params:xml:ns:pidf:r= pid:status:rpid-

> status"xmlns:ci=3D"urn:ietf:params:xml:ns:pidf:c= ipid"entity=3D"sip:afshin2@cc.basamad.

> acc"><tuple

> id=3D"f1391660"><contact

> priority=3D"1">sip:afshin2@cc.basamad.acc<= /contact><status><basic>open</basic>

> </status></tuple></presence>

>

> WE GET THIS FROM = CLIENT AND ALSO FACE AN EXCEPTION

> FROM = SERVER

> ----------------------------------------------------------= --------------------------

> 16:53:38.5

> SENDING TO: = 192.168.128.30:5060

> SIP/2.0 481 = Call/Transaction Does Not Exist

> Via: = SIP/2.0/UDP

> 192.168.128.30:5060;branch=3Dz9hG4bKrog33a

> To: "Behrad = "<sip:behrad@cc.basamad.acc>;tag=3Dfe05df14

> From: = <sip:afshin@cc.basamad.acc>;tag=3Dxtbi5e

> Call-ID: = fc511d4e3e719a65@YmVocmFkLmNjLmJhc2FtYWQuYWNj

> CSeq: 1 = NOTIFY

> Accept-Language: = en

> Content-Length: = 0

>

> Thanks,

>

> --Behrad

>

>

>

> __________________________________

> Start your day = with Yahoo! - Make it your home page!

> http://www.yahoo.com/r/hs

>

> _______________________________________________

> Simple mailing = list

> Simple@ietf.org

> https://www1.ietf.= org/mailman/listinfo/simple

------_=_NextPart_001_01C5F4AE.DD54F3BD-- --===============1205440002== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1205440002==-- From simple-bounces@ietf.org Tue Nov 29 09:50:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh6ol-0002hT-W6; Tue, 29 Nov 2005 09:50:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh6oj-0002ff-VN for simple@megatron.ietf.org; Tue, 29 Nov 2005 09:50:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14905 for ; Tue, 29 Nov 2005 09:50:02 -0500 (EST) Received: from [200.123.145.66] (helo=ad01.voipgroup.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh78i-0006F3-Oo for simple@ietf.org; Tue, 29 Nov 2005 10:11:32 -0500 Content-class: urn:content-classes:message Subject: RE: [Simple] IM MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 29 Nov 2005 11:50:37 -0300 Message-ID: <1553FEFFDAE48E45B2D0AB20777EB57B2971C0@ad01.voipgroup.com> Thread-Topic: [Simple] IM thread-index: AcX0g6E1pXSx10YfRYChsNlmx8XhYwAcHN6w From: "Fernando BERRETTA" To: "Xiao Wang" X-Spam-Score: 0.2 (/) X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0242847898==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0242847898== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F4F4.426CA2B0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F4F4.426CA2B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear Xiao, =20 Thanks for your prompt response =20 I appreciate the information you've provided to me. I'm going to analyze it. =20 Best Regards, Fernando =20 ________________________________ From: Xiao Wang [mailto:wangsmile@huawei.com]=20 Sent: Monday, November 28, 2005 10:21 PM To: Fernando BERRETTA Cc: simple@ietf.org Subject: RE: [Simple] IM =20 Hello, Fernando All of the document in the SIMPLE that you need known. In the particular, IM can be divided to two different main classes. One is page-mode message, other is session-mode message. page-mode message refer to rfc3428, session-mode message refer to 'draft-ietf-simple-message-sessions-12.txt', 'draft-ietf-simple-msrp-relays-05.txt'.Another relative documents are rfc3994, 'draft-burger-simple-imdn-02.txt' and 'draft-ietf-sipping-uri-list-message-04.txt'. =20 =20 Xiao -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Fernando BERRETTA Sent: Tuesday, November 29, 2005 4:58 AM To: simple@ietf.org Subject: [Simple] IM =20 Hello, =20 I want to add IM support for our proxy and I would like to know what RFC/s / Draft/s I should should base this service on? =20 I've seen some drafts /RFCs but I'm not sure all is there =20 Could some one guide me please? =20 Drafts / RFC I've seen are: =20 rfc3428 rfc3903 rfc2779 rfc2778 draft-ietf-sipping-uri-list-subscribe-04.txt =20 =20 =20 ------_=_NextPart_001_01C5F4F4.426CA2B0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Dear = Xiao,

 

Thanks for your prompt = response

 

I appreciate the information = you’ve provided to me. I’m going to analyze = it.

 

Best = Regards,

Fernando

 

From: Xiao = Wang [mailto:wangsmile@huawei.com]
Sent: Monday, November = 28, 2005 10:21 PM
To: Fernando BERRETTA
Cc: simple@ietf.org
Subject: RE: [Simple] = IM

 

Hello, Fernando=

       All of the = document in the SIMPLE that you need known.

       In the = particular, IM can be divided to two different main = classes.

   One is page-mode = message, other is session-mode message. page-mode = message

   refer to rfc3428, = session-mode message refer to = ‘draft-ietf-simple-message-sessions-12.txt’,

  ‘draft-ietf-simple-msrp-relays-05.txt’.Another relative = documents are rfc3994, = ‘draft-burger-simple-imdn-02.txt’

  and = ‘draft-ietf-sipping-uri-list-message-04.txt’.

 

 

Xiao

-----Original Message-----
From: = simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf Of Fernando BERRETTA
Sent: Tuesday, November = 29, 2005 4:58 AM
To: simple@ietf.org
Subject: [Simple] = IM

 

Hello,

 

I want to add IM support for our proxy and I would = like to know what RFC/s  / Draft/s I should should base this service = on?

 

I’ve seen some drafts /RFCs but I’m not = sure all is there

 

Could some one guide me = please?

 

Drafts / RFC I’ve seen = are:

 

rfc3428

rfc3903

rfc2779

rfc2778

draft-ietf-sipping-uri-list-subscribe-04.txt

 

 

 

------_=_NextPart_001_01C5F4F4.426CA2B0-- --===============0242847898== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0242847898==-- From simple-bounces@ietf.org Wed Nov 30 11:45:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhV5f-0003sX-V1; Wed, 30 Nov 2005 11:45:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhV5e-0003sP-Od; Wed, 30 Nov 2005 11:45:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08816; Wed, 30 Nov 2005 11:45:09 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhVPw-0001Ah-Li; Wed, 30 Nov 2005 12:06:54 -0500 Received: from [172.17.2.252] (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jAUGioiJ052987 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 30 Nov 2005 10:45:48 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <6C480FF6-4C06-40C1-9E09-942F326AF70E@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "sip@ietf.org WG" , SIMPLE mailing list From: Robert Sparks Date: Wed, 30 Nov 2005 10:45:48 -0600 X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Subject: [Simple] SIPIT 18 schedule X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Folks - SIPIT 18 has been scheduled for the week of April 17, 2006 in Tokyo. JPNIC is hosting the event, with the support of the WIDE project, NiCT, MIC, TTC, HATS and others. Registration will open in a few weeks. www.sipit.net will have details as they become available. I just wanted to let everyone know the date and place as soon as possible. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 30 15:50:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYuO-0001XN-IH; Wed, 30 Nov 2005 15:50:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYtw-0001An-L0; Wed, 30 Nov 2005 15:50:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11366; Wed, 30 Nov 2005 15:49:18 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhZEG-0002eG-Oa; Wed, 30 Nov 2005 16:11:05 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EhYtu-0006sU-5i; Wed, 30 Nov 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 30 Nov 2005 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xml-patch-ops-00.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors Author(s) : J. Urpalainen Filename : draft-ietf-simple-xml-patch-ops-00.txt Pages : 21 Date : 2005-11-30 Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. Updates to this data require transporting of the entire XML document between hosts, unless there's a mechanism that allows exchanging only the updates of XML documents. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. With the aid of these selector values and updated data content a set of patches can then be applied to an existing initial XML document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch-ops-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-xml-patch-ops-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xml-patch-ops-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-11-30114220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xml-patch-ops-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xml-patch-ops-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-30114220.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart--