From flt@luukku.com Sun Jul 01 01:08:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4rfm-0005KM-G2 for simple-archive@lists.ietf.org; Sun, 01 Jul 2007 01:08:34 -0400 Received: from dynamic-acs-24-154-203-100.zoominternet.net ([24.154.203.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4rfg-0005E8-QS for simple-archive@lists.ietf.org; Sun, 01 Jul 2007 01:08:34 -0400 Received: from [142.214.145.133] (helo=fzqk) by dynamic-acs-24-154-203-100.zoominternet.net with smtp (Exim 4.66 (FreeBSD)) id 1I5Ph~-0002d4-O7; Sun, 1 Jul 2007 01:09:48 -0400 Message-ID: <468736FA.7040600@luukku.com> Date: Sun, 1 Jul 2007 01:09:14 -0400 From: alcoholism User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: Info-ROWADICEQJOJK.pdf attached Content-Type: multipart/mixed; boundary="------------040504040608060104060608" X-Spam-Score: 2.0 (++) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e --------------040504040608060104060608 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------040504040608060104060608 Content-Type: application/pdf; name="Info-ROWADICEQJOJK.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Info-ROWADICEQJOJK.pdf" JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cK L1BhZ2VzIDMgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbIDQg MCBSIF0KL0NvdW50IDEKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzIDw8Ci9Gb250IDw8IC9GMCA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0w IDkgMCBSID4+Ci9Qcm9jU2V0IDcgMCBSID4+Ci9NZWRpYUJveCBbMCAwIDQ2MCAyMzddCi9Dcm9w Qm94IFswIDAgNDYwIDIzN10KL0NvbnRlbnRzIDUgMCBSCi9UaHVtYiAxMiAwIFIKPj4KZW5kb2Jq CjUgMCBvYmoKPDwKL0xlbmd0aCA2IDAgUgo+PgpzdHJlYW0KcQo0NjAgMCAwIDIzNyAwIDAgY20K L0ltMCBEbwpRCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozMQplbmRvYmoKNyAwIG9iagpbIC9Q REYgL1RleHQgL0ltYWdlSSBdCmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovTmFtZSAvRjAKL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIC9NYWNSb21h bkVuY29kaW5nCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovTmFtZSAvSW0wCi9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDQ2MAovSGVpZ2h0 IDIzNwovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEwIDAg Ugo+PgpzdHJlYW0KgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUrlktl0vmExmUzmk1m03nE5nU7nk9n0/oFBoVDolFo1HpFJpVLplNp1PqFRqVTqlVq1XrFZr Vbrldr1fnKzsQ5E5bYFMGFgjw5ltkLc/WcmGFzsFibgnY9mAAhXN9XJZotphtniQngq5quGjt9hl 3vOEjeAiuSg9xklzzFfy2Hvwhb1pwUDuK1goEhVzCK8zcHxEZ0ML0mFBcE1sC18CXkR28ExUP1Sz Wrxi+9ja5EOw4UCWumibv2MEb0W6MI1cgum2CNe6sC2u2AHXAC1uLcgvHhGYBfi7cD7sV8Hf8N2g QLQ7ivm1zHvgjH+nsgjduehzdoGY6IvUbgcwK06CufBKPL+hbyII8yJPqgzbhg9KxIG+j7Nav78o LDaCQ8xj4RC+JZwQhbbtm8cEtm9i+izAajlmOqyneQ7uIK0C6N+AEcIGAj2v/ETWL88DUNVATXtS sUbsNHUiRM/LMoMt5DuY7snN/G6BHeAEqSLGoALeiDVi3MIAL9Ez4IIzayoMvsru/J71tpMqBDqw 8eRQtMvNLHrXhhO8vgBKa/TZK0RNXLU2sRK1Cy9HEzvOgrcrFSsdO5JL9KQWoThOeBBPMzrMtABY EgAy1Rr25lLoI0lR1K01TsE9AExGhjX1U3khx7YKDHggUiTYgb31UsVQoFWs2v+19l1FYlOr7CiD OqQUxTaENcSOgdqRlbtUQzXTgABWgQ1gvc9XRdNjTZcdUWU4DiXW79CIKxVnTdMsA2uvd8IJejY3 Cg8rV9c6B1Na06qUCkkDpGlvAA3NWIGRANj5FiDBOBeMj5Ew6UG1KBTxC6CYtDj/SMgjsoMREZPw 3bq40gmR2Q0MoApj2YzYv2JRrmufr7oLbZ01efZZZE7S9nmP41N0aIXnuotbiUjZKgbiTJlyD5BZ 7vIRiCB42gjANvTJZ6fFjMSfi+I4ndqhT5OdoTegbnkOQ8YoTnRajq/m9gXE2ATtcyHtfVeB6W47 b5egsdxlls4cjjmTctojjU/zCCR3bklLTXXM6W/4I3NwHBclmaFwVlmALTyCBddY9hIF2QAQLyWl tC2+6vnYLb9HIPBQXysAtp2ylY8eA+D4HLEPa0CC7J5oAeghXIbX5nneg1rKenVixbI08UOrcM27 Q/II76gmzdLmlwAB99Y7hstqxBoSC436WXAWasBbzXnulPg7gw0AnsM5IW+12plDvQMfa11DjO2P Pzee2FfBqDRNPWo95Gb4TRPje48Y0QAHyGcbk3MoKox4CrD4D56LwV9AAHg+hIpA4DMGdqoxSaUD iHnfMQVgzRWcwaIOKsgrOGxJwWmsR+jB4SrgiQ7VphlSCQuaIHRhzFYhQtheQOLSjFDLTIFC9fq7 YdGtUkoCHyrn4IofELNUTZYYREiLEyFjMotRLcxHKPMJHMQ/ZvHAqb/TbwHT6QhDSKi8Q1GaM0Xk ZzQyLQkTAZpBTJKMN4Mdakl4gIZNJIyTg8JPF+bkQgx0jkZMTPdHBA8B5SSQjORRSRyi7F4IHLJK shC1FTgNDSRJ1DgDxTkKsZo3RxQ3KG+uWkPSBTEC2sSTy8R3ucmeWWFpLZjTImURJAaeJuHGl7OO ck5SUCkitOadU652EkMg2eds8Z5TznpPWe0958T5J4vCfU/Z/ExHEeImpfJ/0FoMSkUKgSOTdIam 6g9D6IEcDWOJvMgiLUMIE6gE876HURo9R8iQr4ZkIhSQ42r6jrgUgpRyjFIKXUvIECggoxxgDAHE lSIqdVluBMhJIzAdgAOLIHSymFRajEEB9BQBYwBazJUVBkuYU4QtPp66wgYoX7ECqJUerlLwTJQL cYRD9UC5hrY6pZHkfAAUiTTVurtb6I1CIEXp2qkSC1Sk23atVFJbmPNpS2uFgZ6nVOdWlxyVnZTE NZFUgbFjgwVQDOKwVk5/HVQtA1o56CBoIcFRRojUzbyhILZ6ylpaPJbrUQZTaWlqzWVZate9prZW zIctNUttLcW5t1bu3lvbfW/uBcG4Vw7iXFuNce5FyblXLuZc251z7oXRuldO6l1brXXuxdm7V27u Xdu9d+8F4bxXjvJeW81570XpvVespYCznJjJGZu9xy6nkahVewohdkYO7b9LRb5CLAMrIqh0++AS KK7wIoqFKer+RUYFfgpymkc4NigRM8Cu7FkPTWRfAxFjV4bWgoxlVcwAYNf7hAprJ2DlzWUQKA6t T2LygzUFDdtmGObW8uVbJGTa2HPetKixC8MLaZQkZ4a6FiLqxioPFBTD1vRaM0dO+LmoMhyhgsAD b3t5VeiLloKuIeq7YzElyhC6Ty1ji09pRDma5WSqQU7KUF0MfU6myJTXsmlKdSfR1bDT3u4P48nH CKHF57cHj3JjeSBt7PLmCk0Coq2WIjZZwlT1JZxPC4HErMiEO4zyUWDjzs62MABBA1mCzb6hguQO BzeCDxPqgQ8/GcHOkVOrrCsjL1Wxl04QeBmnyiUWxObhrcwCDZ3we1uH+szvJ61xa7DOrss61IFF Mh+t8Ku3UyQWKZjI9kGxHsDYO0Y+Sv2NJiNa+pRyPkjTmEBB5p05IZLp/JBUYyilUezVpBi7kE3p aBBlWQASX3a0fezyNxFCmxNuimw2THBIFDrd201fwtmPaSzLtyEcMqttAAE4QQzVbSQOaE2UJ4gI QcTkE1dpGjILJfjG0tw8JKFJwWQ3Zj0i4dgOmZGecDdFebWdGpCRAEBWQyTjl4SyVIFJekWZVfc0 3Ffd5WpSGYd6l1nrXW+udd691/sF0jqi1BpR3sPZ4QnPptfDISSOsdou7BQ5TkyE5yM52buF5+XI Ks9fUyrCkh9v7z3F7ZA+GwxIXCfB3g72CzLcsVkRDC2V/jt4y9BcTDJnoIQLfbHe7og8teix97q0 kCOmsiX7yeiehvGjBmXoD/wMdpg7qnrLs1oaIbtrSQcJsyi37bqWNjaLj+B8X43x/kfJ+V8v5nzf nfP+h9H6X0/qfV+t9f7H2ftfb+593733/wfh/F+P8n5fzfn/R+n9X6ye2E9V+y6eQ/3kgxVtnuZV 65T0/zdd8ZAwNv5rUiFNkFsDdHqFeOPCcloiYsgiEkmCNsxs2LuC4tNNNtRsyiGHDOAiIHfG2vfj LoMtPCGwFCYPZiGMjiMtGQInPNSu/O/nUiBMGlutYiEnPwWqDDLIAn5u6LMn2P6vOCDQev+iIPUr +wAn7mwpNCFH0rMlCn/lWIOHyjUEXITHmQPoNnuNcDqCOwslsNboLwbIQstonN0LEGTMtoyoPEIK IDNovGbsQm3l0IaQ2owEMIxiBoXI6iEtdMXI6L6pvo/FqIzGio1wQvKIwtko4omtrELm3G1RFFqt vwtIWRFsvE6lCwzRFQuQCIpIzPFjBFDH9s2DqosIwO6ixDFQxsQmvI2oan5gfQLqCumJHp4OqpGp YmVGpwLxUN2QwOrG4HXN/s0HxJUppMRpNNfu7pWGaRiN4v7EVN/GKpTLXRmJSn8jwJFn5NJlwRbw WlUtzJctruXpMCFN8OmtEmVq+xWxmqPDkiBhuiCOUOKGtq0OMHHqRuOLJNwP7lLOVxhJhuFuPsVo jCEqnOQi6EAOSpjOlDwxxSCuRCErFR3DuSDGHMMOJCGDnuLOQFgk7rHiCR3iHHkRmx4ooyASQEwD 9FMrHpookSTqQPJyJE2OjBSFerNnciFOhsBCBEHOPuci+rYqMlWEVpOugSfujtpShEEh4ObyAlhM WP9iCOnmmDdumOBulRnxoOghcyZkyyYCBSQStgVyaDwFzJKhZCBypEIiBubyfSwoFF6LOSPiHyqx myjjKrOSlx3yiywyxlcuBS9KYDbjLKaqarIt6k9J3mfqSgAAuCCzEt9EfDBIGDCS7OiTGjthagVl IRyB7zCKmPFqoBSAuRkPKJWHGOxwioozEkPo1DBTRH/wfIlycqtAAKagATNPSo+TYzFxfKhwogYS chZzOizqmTNNLD8zROBLZRDykKtTCl1ownwhXjfzCTUjQzqTqkxRGDMA1q2CDkxqWzPTPpPzuqGo 9uRhZzxOEOiTBzCL6TcjQzpzYlGTuzsKtDlj2Tojrz5T0wOwECLT1qoKzLgkazCj7CGlzTbCJCxT PCBQMjMApqZCkTPUAq1DN0DQMpWkrhxUEkSQyDwUOUGCZOYv4LtSgUS0UUU0VUVrnPFJ5BXqVMMC S0YO5CZGgPOwCrwSoCH0diJQKCUnUqaqbiRA7AUHUHfiS0jKdwSiWE2g+T/pACbTHw1sPCNIKiVK qKmvBCHqsFfiTxXibudpvCJ0cCPUKp/hXqvixvDO2QmUBi4vHE5EeRBmczugTCCvcCTSvCG00u7C zKbu8S0CXU7zvosoizymLqwiNMTgYU7P6xKwPFeCKVIF20/qcQmPapy0QpGKtESpd0IK+JRK6H0y Dqo0QiCU8iSsglIkrgp1Nt+0/sCyCSyjFTVqUF2vD1AsaJRGF1SKoVXFV1RKbFqxlL/q9FB1gMak zKbGGKSjbyqjaTF1kjLEC1mMuzeCD1YkTNULKkGTwDzT0EAjYqHN3qsuUDjDPneyOw4wAGqL5p+D PIxIZk1qxxTPRyGEJ10nzR/vAjOvTlG17wLETxGjRx2ztV/SD1jJgwLlZ13jGJDCCjkr3nC19DQS OjhWHWEQjCCF71/zmrBrRsCw1JvrRzckT1jL+IPlyJKSb12iFLOvNgARcoHuenV2TCFDZuYzTDvE DvXC9kuQtNyWBsWKBVoRPNk0ZQAVyjyNAj/WICCC2MEl+wL2o2U2ZJeCEHYOqp7jNkwl7mKISjqr UEjTBQVoCVyk+E1QdiG1Uzmtwksq0puv3Wvx7EoFN2b2g1jtmkj0kWzolsVWniB20k+kuHY15pgk nXDpE2sVjq7M8J9FQlaFtlTwmMWnkWxypsdPAGA2/JDlmoCCGSLzmqNFXFTUHV7LbTtGFj9EXF63 JTQDqXIlSXTWySn1lW9DrkMnxQlF5SDmCJEHk3ei6H2o5siNs3dFf3jXVwkiEluKyXkJ+meo9IHE ljLPFV6oqxQCBGwGryOCCGeCBGbKOtoM1xYQzG2QdLMO6s1H8Mvn1ttiCP/3YDKs1GbWjmmkRthX 3TrzlCDTeGnXt3FlUGKqlAAX5RSwmFDG2YDsQ0oPKpmLltDjW3hHY0jnXDZkyMGH6iSjO3ntdNDW bCXsZDQnECNMTRyDgE+DZm+XnI7nxQXwKupQkmdzenvRGChEatQiZuHTYiUQ0vltwohil1MiXz9D rkgUWEDR0umuCik4iCXwkqBYk0FyVx3USYp4sUVWyiRUt4sp8sfiRwBim0piT4yCb4ep/0BirKoo oiQ0yilYzCC0JCO0zia40MnUKO+2VULTE0MiB45iqi0g10JT2qmUTiKWPCFzwVMCVD841THCHZAC N46iaVxU24zwNCHha0KEt10FUY1DgTViF5JTa5DYuicDBKAm4TCEPE/GHED44mhEVUFVPRrC5zkm LhuTsiL2RQmTRLPZZ5diF4riL1hmz3GQD1IsDpK1rReiQ5etm5ftqAAZiCE2jWj5pC7UFWfiFAuO Y5WD7i0QwznOyETBcs0FKZtsiwug6zquy1P0IUulNT3H8Eyux53kk1fqEnxZ2zCiG59zfKmOyiFA pqEu7DlAaE8lGKsW7G858VMAYKpFKCCZ8I1IMq8GTHfnkKGZ5jCaE2yF8aCjRZ+6BFIMwaI6DLX6 HCI2+2/aJENk+TbaBiFaAKh6BW8CizZlz5WVLwZCBuhv8jCZF2Pl6zs3nTkKJuH0PHQH9ESO2TIh SKJ1g2SiGUOCCaeVdapFpWOEJiCp0VNlQziVAFFEUataiiBaxlrTQ6kti60Nr6izbWvoM6o6ra4O 1nQODSSvDDC6eMYz6HO1a0hwTCDa75Tib6MCBGIZRWZK75pqxGgQAoRZ/EPsvwDX+7IaiWS0b0LO BZq1jZ1JuuntdnSvOqVar18YED8qpPFDCWdREITje7XJhXwSGJDQFDqqnGixckaqNjw2dF2qNqmJ kowTFy012UtCGjq7H1dChqgCCaY7C6LCCbnblG/Kf0jbOnNUnkrUitCsABc7tiE3LkP7w7rnRkA7 BCGDV7FiD5CHZv5jbqgSoOYmNswbuiEa5HhD91+i+0niFUgqxIZCDbxynCEiz0SOPUmX0uDZJVqv D71THa07DCa0u620tNLCC55MtzxyBaCqkwnmPbhViMwcPCB0XIG1IoT7c49jv8PXrcQ7kbk7T2XC BUwQca0QkbVaGCD7XcdcP8Z3AnO0sn8Y3wccRXCzm8VFITTEy8RRzpFKSbG0wEOcOVdKkwhccZnZ AiCypU4q6CIqw70iHU9lOz9CEcwljRB7gU/35iCU1PHTacaAAVCDLEz6h0BZpvIGgaTzyqwCy7l1 IIM1HSd8/7PDK80Is4BiDc0MuzmWP63CJ1LcMCCKzVCCB8v6cc5qwLmxrWX82cJiF1ac43QCBnFk JW2u67vkZxyDHK0RpLM1gUrDHrSIP2TiD9Z82iE82dI5m7pCBqpP89Mdc4vCQ4niRtliJLC9iCu9 jCRWYbmdlp1dmiRFE9Qdo9r4ndsCKwGCHTSPVp49p4tCCq5cFCH9vWNp1m5xNRNiURC2FraX0Cb4 wSdc5FhyFir4tsAczCFxF8ICU93d6629704ImwRCUdmx/RT9uRyeCjC1JG3RMI3brGdGtyLtkHY4 kQ5Nj3mCjxmVo9FIot1xq1sCERm1bm8q+pcpI9oCKdz9SPPVJE4N8JSU52d9HiPkAJbzfkr4luCc tCBJKlqeVw1CFIftwlJJKRbEFjrjNukq/pTl8WWeNePkQpQWkifyEpjyJuRItlZyWOL37iEyFR4M 0FlpoOmuV7/uSjfOSSAMltmlJjlSE0ox/+vlOyKEfMp2DSAjESKGXDf46+uYj+zU5MKxPuH+1uLl rOWXHgAe95qfFzIxL+5e3OYyK+6uTFYmSjVo0+8DsCCR29+nYMwuIChvJyzymnpML2mS8uc+wiEO cCCyxMyy6fZCFS8SmUEegSlS2D2FYD8sW/cSXYbwzfhRq3al6HriCx3yjSxjbS4cyCCSxNCIhCEu hzJRh/eOByXfZnGSkubS0fmmEdTfeSQbjFPkVfyoSYSiBfUfbXzSvlBFofoCiTXHO5RDGbdzgTRk Np3zcCAACBQOCAAFwVgQVcwQYQWDwSEwWGDCKKQuRKMACFgCGwSHwKIgAVxuBFmBx2MwRcwtcyaU QKHveCiuBySOQVZgB7yGRQKVy2KS+MrWFQWhRCfUmTQRSQaETyNQKgxWBLNZztgVmiSqGTiCrWaU aCxeUzYsy+mxKoTaxwiVT+gRSU3O6XW7XaOmuqyCixo6SihTms1oCWyMLy3VyTwO9YikRmpjA1q+ 7nSpQXHXyBASxZe7yvLRyg5PHVDOUnFwTBRnQVO61uB6HUxiIxuF5HJADMyC113VQjYRjAxBa6eJ 6PKWXOxTSYmo4aOaSc7xgcWf5279ntdvfCi9gDBrVxCGSUupFMUOIE1beeKo3QE87UVKKegAetZ4 Oob6BuK7qWoT4oGkIQuwlEBLmmz6vTAaCwK+a5IG9bwNY7CUv8pTIimlKtts+kFvu4C3v4qr8vDD CBvMm6BPjEytPG4UQQS5b0PU4DxpYjEawnAbxQKn6zqC7khyIuiOu8ADpvA6rCrmNYUFq9juSgqz YN6ia9KqWrBrmqcnuCuZvQ/L7pv0oi2MBMkisemqBhCbzIzI1aMFzN7XLowrrtFIU1oHJSQOsn8H s8gktvDPKVzehk1SWrIAONIs0Ls60+zdOEI0rTNNU2u5xSiWZuU4lKKi5TyM0HQgYItUzqGA/1JI HUswVEk8I1Wok5oxINMLpPVaLm8iVgBFSjzpICJVlX9lWXZlm2dZ8+1haFp2patrWvbFs21bdNLg ENeW5cNxXHcly3Nc9oNAs90XZdt3XfeF43led6Xre173xfN9X3fl+2oE9/U1PlNz/cToO3g664Tg MjTijMr4ZTZjyLgGGV3YqIRxHKU4LWmLrlFE6UrhcZ4i7bcCm9SrG5itXJqlsLZM7SPu5iuGhgCL MniE4FnfWajZwXmOr7NcxUIjGfUROq56HTlLtc3aJTRO+FIkimc6a97s57QKBTtcE16jZaj6EWZa 52g9KUTozZ5kumVhyY6PrhFSU4nl6VvMqYFyiABubiBZDxgyCKb5lcHTbPuMIkQ6Fbq1Ws1El+fp 9BTI5o1mphhw2mpZIOjySgW5cFYKNY+ufST0yKB8oguLsvT9QyMiUwIPV9hc++m3LqqxZjqE4tnf yqfwi4YAeBvCV+Lq+ygB3/gvnqycDqovibAgvgkPJqfdX1CFIbqkk4Kzi4Vrq8hpenPfeRl7jo7s WpannLv/iXLXeMLfqtwlJ3+18puGgu9eoax/bWCrO/Zu+dgrwjTkbfBA93bvCCiCeGnV4pXnjjwc SakoICz8ECBOPAQQIVIPSUKzYpKiWBkYhDCNPLXnukpVQh98KYGlLfhpB47j6WzAnhaYp8zmy7wz I5B5KSxiulCK3Bori34YkSgoVyAERoewyLFDogcKEYwdfELWH0IlHnLevBGDBAwNvDDo7l4wABEQ bZiTlioGw+LCMgQUCkWjyl2cwgou4fGrEvAiQQChCo+J7axDtyBBIzxuI7AEuzdSOu9kGyKJMdiB RtfbJAlMizYp7KDIF0JdJNNRcxCZyEdwFyYVhCuMhGE/iHca1ozymGzEDljLJFbVz8FEdGIcBcdD hARl2HVu7lW2kpj2iQubmFwSgIFAONxNypzCcjHVPxBZbyymmjx2ZDJqNmmg0Qy7k4Bywl+deABK ZstLKFKCaqKzFoIJhN038tnGqSLkziVrHJUDwD5H4jTeWBgRIPEcAFAKAlxJRQR3pA5/B8ByyQBc kiDUPoiSQwBKYmSMLuDloBDiqz9mi+CMoC6NpdnqQOgCQDAM4omwpXZHqKIVK7Qwq0d6VUXPfE8i VEG6Sepc/Sk77oFEFqHH+l1DSCR+c0QOl8+4WQhg1QgXJf1wPNIEPAeAqw+A+J9VZxamqt1da1Tw glYwfK+ngXStJrarlVi/RufDzIj1aLxSkgVK6qxjLrWCsJGTZGebLHAgQqyC2BLvW028NJnCzriq NO7BajtAgDQag8uFwTvqgdlP9WhmjNfgtmVhErPi8mAdyllawAOtswfRzlDrJymb8QUZq9rSrHO1 bWZREgTjHtisx2RA7dWylDZu41x4IjdHEok7lylEjvr/ci6V07qL8FeSsAhYbq3bu5d27137wXhv FeO8l5bzXnvRem9V672LMjWms/ZdlQXtvpfVeAMENolUzfF3k4b7X/wAtwUgaz/JVv2kOL2AcFYL WuhsCh7JJ2ruXHQl0K6bgnUdQmqtqjkkCpxgzEGIVlh2O/ANVzSqgAwxJF2YmGS4B8XAkiZ8xcRY 1xsmsUJBWKpgNuS/HNxSBIdpYpgUNXosylxvknJRc8OwgIEyEABlihHJYK7et08MmvHfzkvLmXSJ ZQbvlAlxBUMJ/ZdXMADKSCjHy3l7N2XJSGbW8mIoRjmzs8aTQlr5l5nVOeFm/QGSXavJQAV8gbgH GoPoE8uUrgdA6P0grTPukdKaVUq4XS2mdNPo0npvT2n9Qah1FqPUmpdTan1RqnVWq9Wat1dq/WGs dZaz1prXW2t9ca511rvXmvdfa/2BsHYWw9ibF2NsfZGydlbL2Zs3Z2z9obR2ltPam1drbX2xtnbW 29ubd29t/cG4dxbj3JuXc2590bp3Vuvdm7d3bv3hvHeW896XjICACmVuZHN0cmVhbQplbmRvYmoK MTAgMCBvYmoKNzM4MAplbmRvYmoKMTEgMCBvYmoKWyAvSW5kZXhlZCAvRGV2aWNlUkdCIDI1NSAx NCAwIFIgXQplbmRvYmoKMTIgMCBvYmoKPDwKL0ZpbHRlciBbIC9MWldEZWNvZGUgXQovV2lkdGgg MTA2Ci9IZWlnaHQgNTUKL0NvbG9yU3BhY2UgMTEgMCBSCi9CaXRzUGVyQ29tcG9uZW50IDgKL0xl bmd0aCAxMyAwIFIKPj4Kc3RyZWFtCoA/4FA4JBYNB4RCYVC4ZDYdD4hEYlE4pFYtF4xGYE/o4/H7 Hn8/Y1Fo5JX9I5RGpNHJHJX7L5TCpXJ4pJo/JZjMXW+HmqmUu2Q2V44XAuHW3Wm8no8XU83e+ny9 n4+3zIX66W82HK73RJX0+3pUHpU6/U4M9ne7Xg5HA8nq8nc9Hk5XY4Hu93g83S5n09Xo+Xy+HM5G +9nu6XxS6g+Hi9nk/MhkH1JXw8nhJbu9n3m4M9X092w6XC9XtY36+X5UMg+3vgXE329HI++nxH33 X8nLIE73e2s29oG3XC32Gzl6+Hy9X5gNW+o+9re+Hw93o7XM+Xu9XY83dhnq9Xm7KY33i53C89o5 Hs8Om8nu9nY9XbTXc63W83g+qhA3i5XEaZYFIdJ0HGdx4Ha/TvnidB+s4nKIHK+ZTlgTZrmsVpkF uQJhkgP5aF8VBYmSXBoGWVrAninh4mqX5ZlcZBal8XRLGmahMGuYZTl+UJHleZ5dH2j6Bncb5tm+ ZBgF4aJel0ZRfGWYxQG8aRamaUJKG6YxeHmep4GWZZXG+cJZG+YxdnGcJslCZxcGwaRiG2bBVnme Rxm4X5bGgdZwlsYJXG2cBamsZxQOSeZxnodxgG4ZxpGUVRjGKPBtmEWBtmyaBqHSb5lmgXh4nkbx pl0TxjlUTRGFsTRZF0T5xG8YZrmIUh6nedSBl+YJbmQYxPG0ahWmeVJMmAWpRFua5kHKcZsHgdxy G6X5anAaZlFmZRcGIX5Vl8W44GiXhKGoVxRK2dRnWYbRrFyapmk8ZhREiVRYkyOpVEcbBvGggZwG MXxdk6RRQGMWBip+bZtlUWhICqdZsmpB6IHa+pbGQUBrm2Wh1HCZ5rlqVZyHEbpdGeVhpmqWTkHe fDwGCaBgkMURAk6VIzmqaBTGkVpPFaVRJkuZZbNwgZ0GoZxplmVBynkdZznicRznYZhvmtPJVE8c RrGa5Dwncbx0HOZRplcUKsGwXZomCZZrls6B2nuuBjlcTxYGoYhZGST2jkgXhNDUeZ0WWd51l2aZ bGiaxSGGWI6nCZJgGma5lG+d5wGEaGlHAZpmlMSheleTxDloThGFEM5gmMRxsl0Vp7rSgZvnMbB3 HcbZplyT5lE6RxSlwUBZGIWxsG+YM0GCZxRksbBqmUWhnmEZ5llxRpMnScBnGwXBXG4cJuF0ZhZG 4cBemwZBTnccBtmYdJukyWZMHEdJsIGd9X5CbZoHE3ypnWdBoDJFIIseTgWIkPJKPsqZLx+EhOWX 4qA+R5FoMgPkl4+ySjnO4OEdA3x0jvG+dI9w8m3mfM0VU3Q/yVj9JnCsl5M4VGrHyO4cI3R7jxZW YEr8Jh/FUHwOkcg3hzjuQGO8cZ3x1jvHKN42x0h8DjHUN4fA+x6lRHiR+BcLIljyHifofI8x8HwH kOQpQ6oeFWIGTMdQ6BxK1HaOMdo5B6nvKUOseg9B0IqLJCskMeo+R8hVCePsLCcQFIaPAdQ8BejT GYOWIUEx6DsHQdodI+ipj4KgPcfA7TSniHJBodw6hoDlG3Jwcg5hfSElRKmVUq5WStIONccA3BPD AFeJEW4jxqjXFKLoQQaheCBDsMYbQ0hVjAFaOYdgyhujJFm5gUQtBhC/FEMkWQ1R1DPHAOQWUrpu Tdm9N+cBBh0j2HiOMdg5RoDWF+OYcAxBnioEyNAWQphijGGCMEXQqhvDcFkN0Y4sz8DtFuM8Ygoh UiQHQXUeY9BxzhodQ+iFESVGyI+baQY/4uSXM2PcqY+SBmkPkOschtqJUlpNSelFKaVUrpZS2l1L 6YUxplTOmlNabURHWPceY0BrjPKWO0gZfS5SfoyZ+Sp8pDtNkiexljKovlPOwPk250x6G3o8Qg6Q 9hqDTF2OcdAxzkljMgPYwJLyREFJKOItA4FmIWFqOQa4whxDJGEPIuBhh5j2O4yqAcRR2jrpvYGb o0BxjbFaLcUA4BvC6GuMcU6lBcCzFyKMX0/xqDQFaMkXIhRWBmCaLgVQlxDipEiKYUAcBpjRE2NM XAnhlCuE+MQcD+RsjLhEOUcg0hijrG0NUgcCh0DpGgNu14yxQCRGYNMY4rxlC6HOOUbhsivEfGUO 1V6shoDQEyM0VIkheiND4KUYgrxbi+FONMaYohvqBHjD5Zgz7BXxlYNUbAzxXjBEqNwbwvB1jfGm 9YbQuxrDJGSNoYRXx7jSFsJ0XIgA3DmV+KoWonBZDDEddAZsxBPjmGmM2BA+xqjbF6OYcY1BnilE zXMYJAx8j6HsNIbArRoqqHcgQaA3BoixGQKocxvR0WziskEfgzL6nCGYM4ZgnBqizFKNUZwwxf21 myNMaw2hcOaF2OhjY3xzjbvll+VFZB6jpHgOMe05DAljNvJSBBNyOxcOgZsz5USvj4KscuCmbh/J cHbF8eWLh6msOARsjhm4onYNkR45ZtIFHYHrRceh+DAD3NuPfQGbB5H4kxFM6Zyzpk8zrmDUSDzn D8fCMwZo21HDQE+PQetDSBDbHkOodZjh2DuGkO8eI2dR6919N6jg+hJCxlmMIUw0RoCXQON2Q2EI fjjHKOBjAnlRC0jNr/bG2UHwqH6Nkbs1h2Dbe6Lg9Y7GRDTGeMwYo2BojAhmLgbgwhZbX21vXe0r DVm2gVFbe+/d/b/4BwHgXA+CcF4NwfhBB44DvrsO86iCB9DyQaZMmBBYKkuI5oGq5Bx8lyxbi0sx AoecdHlRciu+zN8mI3Ao/Q9jaExMjvwgpHh+j4NSQ82xqeN4sLJAmio/h+Rn0LRWFuiUg8phTm6s +vhfDgGoL4ZgrD/DGHYOsaY0BYikGsNsaI2xzDSk4Ocb4zFajrGKNUYowBtDNg0NDTI5HYLVG6OM b44hyDcHKOfIguBWDUFiKYbJ5hquaG6OJRYyxYjOFMJoeUkCB6uHKNcaAomdWxFwKgVYxRZDQHCM Mko74ZjIngLIaQwRlDZF+OgdY0dzDVKsPU6Y17clxlKNsZI7BuDXG/3cW4yxcjLGwLmBRAx5HJGk O0cI3h2DTHP1YqB2hzDhlCNo+w5B1DkGsQYbI8ofDzHWNQaotUxC4MkO05IkxgCsOKLI7nehSCSv sKMW40xii4GQKwaQ1BWDnHGMblS+QbwcA4QdYbAaAbxy4Z4XztYXQYQXAUoYYZYWQcQdQbgZBNj/ hHAXAT4XIWIUYTYWYPgYIawUogYZwaoYIXAXYVIXoZQVZVYNoXQS4QJzQYoSIUgR4RITgNwaocIZ Aa4YIWAU4PgJocYcQaQgYaocQaASwVwOQZQWQT4c4dQcoSISIPQW4X4TQkotAdgZwXgT4XAYoWga ZI4UgXYPoWAUIQCS4wYcQYQZj+wcAXRK4MoYoUgRQV4ZwWYXgZIWwYAZ4XY1rjYpYdwZIY4XITYW gPQT4XYPIZ4aYX4XQWASYO4S4O4ZgZgYYaDDjbgkpm4YpX4ZQcodQaxsAbrSYdQeoeIRgT4QQV4Y QSgYQZoWIV4RYOpbQUISYUQRQTATgOwcAdAa42jR6E7MA1KSgl6qqnQ5I6YeK6wbSGo9gfofQZgd AarTIdi6wbAd4wYZjCAbQegcwgY6gvJ/ocUbgXr1YdA8rnQcYZwZBjgabSwxYep2g3wfbQYf4/Ie waweQcQegng2wdYbgbQpgdgmaLQcYeYdodA1oe4ZQdwbL44brbjjqhYeYeKOEQoc4acbIb4u4eBW od4dKv7mjx4dgrAYYXYa5dQZ4d4bycwcZwafYYgXAcw14ZwdYbyCyK4fyIgb4eQc4cg1bIQlwl5L odyrI9geYcocyKAvB+obz0AcbRTeodo/AcgeLWoxwu7PoeQ3gc4cwbgdIcYvKG4eAxyOjqqOpQ4t g5Ae4jAdotIX5uyI4cw1KSw6SOgeAd6ciMaCqirdIaoXobIZ7Fo5xBqMriof6syCYzDM55wYoYqR Qu4dw98q6NIuQ8IeAdjlwqQfbmw26FxBocYc4XgbcWYeBAYeY7I3CBAfAd7u4dobwbKPgxIeAqIs I27ISBA2gvCR4rroofwco8oeIeodSR4dJ1wdr/6mgaJOwWBl4XoYYTQYwYwPAaQV4T8MQVQUwZ5X MLwbIb5kxVoZQUYTQYQawZgbxUR2h9IZAVobwYgXYX44waCYaOodDFoeIg09gbAWQW4TotgZQaAV YTAZwW4VgWAZYXgWYX4U4ZQaIThLkqgyBwq7ifIcgdZOwYwV4ZYT4R4YgZtB4XoWAbgbZOAbQVIe kbg9gegT5GAZoaIYkAIV4aIXITQVINQK4TAVsD4YgW4aob4YAaoYzJSeYb1DYdgxKBAewdIdQZYc oZ4Y4ZAVwU4VwY0FIYoVYbAbYVwZoV4SAZ4U4TclAdAaQZ4Yobwb6RIXITgZoUoS4XgYoW4XMQ4Z IZwV4YwWwPLBoNAvAdyBT04XwbIa70gVgTgagWQU4si+KCIegY4ZYXRS4WRNwUobgYBPoZQXIbwd yDEoIeAeIbkqKewWIYYcoawa4ZoWD5IXYZ4VwS4YIUYSYU6WgXoXgVgbAbAVg7gccay+AgTW4cgd IrA8ocItYb5CIcwWgZgXtVIYYdaUA7IdjbgZBqgYQYgVobYbQVwXoSQOAYISgQgUgYAVQRYTYPwb obIXY6dQI26qofIXAZKxgaQXLVz6wa4aQXwVgTJdgY6LQpi4QYQTAPYZQV4UIWIbIYrjSCob4Z4X DvwUoX4aIX4XgaAYD1QbwtgYAaIVYTgYgXwVwVtIAYQWoT4bYboV4clIoYYUgSYVYZAWwYYXgWJW sCgYwWYY4SwQ5Qzx4eraIcFIKeYbIYYXD4awU0DSgqaBaP6QKFgjw3If0YbNM2ZdQcIa4S4XYUzI gX4cQcwZznUqCM7orblsqPyPaQAlY39ZAvSDAuQcx6zSrbjoVpyPppgcdMYTMggaIbhBdusowqyB SA4l6sg6g6rTIcSjoqI747CLi6SPVuiPiAwlalAbQXQWoaIbAagZcl8sYbAxwdQeTEg9wegcpRNp g7Ap0CiP4c5LstS4IZb7AYwbYYIXotSIgegdY1CKI1jjFtA6QeKOocpooZwckR4c5RIZgeAbjUsc avMVQv41I1a34j0QTmwfQbqN5lgeItYcAwIwE3c3Yz4/qNYdwdjSjPIqY1ijqEg9geocApgcwdQb DVzWExgjiErRQqyHk0A5iKRQwegchljXUpodqLSKY94u4gzmgX4dL+gcgaAcgcYYIbaWkJQaQY4d IbQcoed1rMYgb7yLSQ4bgudDQbCCqcIcYZIZgX6+oQIZgUIVgYAQQagX4Toa4WIViRIYwVIbAYI0 IZL5IXIboYAXAb8IoPsL4R4Y4TAXIXILwVANQIQVAMQMoWoZwY4XAcIZZjtGAWAQYyopgxwdIuAY wY4SoXwWQNIWQNoLoTgQQQ4U0SAWEwbD4gc0odAazsQVwcAYIb0NyF5PYc5xQXIaIbwaobQb4ZIb 4ZwXIaAU4T4W7KAWpZIY4aoXwawaAUYV4NIKoVgRwRQVoaoYYagb1zIawVIaAWATAZS02RAa4Yoa IZCdIWYtgX4gYa4dwcwQAW4TQZyuYeAcrsYTwSQZgXIXiaoYoUYY4ToXAW4LgZgVwR6zAVYYwa4a YYRaoc+baGQbSKyLgUAZAWAY4bgYgaQYwTYX4RQPQYYV4WgUgZQW4VAY4Up2jLwgQcIcgc4bgwYU ZcYXQYgP0/acIewdo77VwbQczrwdIZgdraQ+QekAx71fQ9hlYtCuYY1VIa4WYYwW4ZRHAcYcDpoZ IXwbwZgaIchwLD4bjGIXwSIOgys1R/pioWQaIahNYXQSgcQZQZDKrAwaIYYawbwZto4f4Z0CgW4b AZQbgeppweQbiCotSZIcORAcAZ5MQWlvAYIagWAV4aqTshwbYbxNoZwU4ZYTwS4WoWYWlLAWwa4c unpQgY1nbeQVoZoa4ZwYL0oc4dNzkgY4JAgRIVoRx7DzYW4TAbQXIWAwwewV4XgVQXgYgSgaQZYS wcQZYYItGAwxwXxN46Ye5Imb0ogfWR2SgbgWYcp8q3IaKxTtYcQZwalKQeIeYbogYaa/oZIcQbAc 2h0KQZAl4fSm6K2mNuiswg13wgw2c0AeyFMvNwUo1yIkIgzNiSyCltEnqP6BDmjoKtAju6QgSCaC a34kI1o2o2zF17o6gec5riwl8hwjwzYqIsiJhh4Ywcb/uFAgs3qOMYgmgggkqqTj6KY8G6oeZOkv O+A2Qge+COIeQgdpLQCcMmApD/o3g2AYwXL3AawcArgZIboXwcNr5FgURaIWwgaSweiDrWSHwcIY 4YAb4dAcIXwa8aodlZIc4ZoqEfIdgd8lGYKi4vweIc2YSJwbz2B2gdwa48qJwdYcoai+s4wdmEAd SIMzgVgn6zITgdYdm2IaYYw/4ZaJwcg/TFx10bgb8pAcQdocuBAgezQcgZoY4czGoZzaQ7znQawW QVAaoXAVoV2oAXSanEIZskYbqq2AwdwWQYQV2hIZx7oYIdYbYa0zgdFLoagc75AzIcAYoXoZoWgU wUwYwWoWgZYVO+CGod87IUYZquAZQbAYYeAekCgaO1AaAZAYZDNKIaYaQc4Y7GobQZgUYSIYoW2O TsW4yVpl4XQXwZQWIoYXzKAUL0oTQY/RYSYR4N4S4YgUAWgaQWAcAawYg/hRIaAcAZQawb4aQbYZ YXYbwboZmNIVQYeYwWwbQWoc77gsgWgSgQoVQR4Qo2lqLVwdoaOeIW4XoUc54ZQYuPoaqY3hYWgW oV4TmDYagkpphrIbAWIUAToQoUgU4QwYoboXIcOvIZgXYUIXoXoVIbwawaQWIbhJXk4bgaAXITIS QLwagYQXJ+i54ZAWITq7IWYXwWgUfJqKA2gaVfRdoVoUIToQgT4TAPQaYboYYWQZyY4dIZ4aUOCf IS2OkRoWIO1BISOTIXESIVmrYXoYQcwagW4WQT3GIbYUgT4RgVwUoSiB47CcobkQwY4W1TYV+bYc AY9G9VQWAwYaxV4boZHhYZ9M4YAYgToUQTYK7xYQc3yVw7SI9UIcAe0gYdIa46Yd5QwcAbR8T7wc 13IwAeogd24YK/1JYeKqTlyLodQa8JJwIZgd4bgqSCgzYbgXYW4aQX4Y7D/AwcIcIbAXXwgXgaQX Wra/uWoYweAuZwEpuRDwocImY/TPgdYeDLT8weQ26cgdYcAbPPsBIYgY4dQbX3w0odIagWgT9qt6 gfgcwdAZIdQcawgZYYggD6er1fr+fz3fb2fT6ebwcrgdjlckKfDbdbWcDhWzydriersdTlezuYzq ajacK5kLNdrgcsnbLNeLdccdfz9frzdLmebqdcGm79hb7eb2d7sd7mcz3e72dj0drueDhnD7fL1p zudryfVOeLndTiZ7qbDSoL/tFptVrtltt1soFMez4fD3oFAtL7vT7hd3g1XekLfNMgk4tL8hb3fD 2v03fz8t9pujuaq+ULxczitL2fNGeLihbztL0qz5fuQyNtfl8dzgbTvcrhfmzoD4fLvft6fL0edn tFVhby3L7wlA2b4vT1xtAfOdvT3rrz0+of/Lvz809w614tFAdDUZzfY7DcDpcjmdzoeD1dbzeTjf j5fG5fWp+33/GRaTucqvXZWGsbBYGYYRDnWbZqHoe56mwcBsG+cRoG6bhWG+ZJdFKQAzE6XZTk6T I9HQcxrrSbhglwV5glcbhzpqyiYlOeh1HQtJ2nazJuJKcJnmKShAni2K0nIcBqGybBZGiXBMnKaB kmadZwHWep3p8Zx1HIZ5sF4WRxnCbK2H2xZqliUhll8WRgmoZMZm+cp0mAbheloVw9DIdiIs2e6f HYZ5smAWpKFURh0HseJ7HudJrmcUBslyVx5Hci5zG0YxjFSaBlkoWI5iocJjF+tJ0m4aZtGwVhll IRxfEePxZmgXitngoBxmkYBolYUBgGYXZhmuZ69umZhPEiXRREkTpgFaWJbE6aJqFMZBTkGaxZFO ox2vzbNtPsYxvmoXRglCaxqFAXhOjSaxdFeXxsGOX9Gmea5XmqY5Pm0XhYlWVxLFaaMtlYP6fGmt JrmkY5UGUXBbmIUhsG3fpYk075nrSahwGMZholGc2LnAYpePifK0nDCJtGaWRoFOTRrmYX5cGQXZ qnCZJzHQYRrFwUxSDiLBVGQWBtHYaaCuodhuGwbRym6ZUiG+bRhmwaZRm2XpZlOSY9HSedsLQeB1 G6axclKa5oGKRxglQdJ4HcxR2HcdxrGmWxVFuZ5fF8ZBcGAYZHmaYZFl8Qw6HMaBlLSbRol2Z5lE oXJBjSWJBjaVBklobJzmqoJsl4VpkFISxmmyZZspee6rpufhmlIS5TlyUJamkYZnc9SBwGYUBJmO WRRnmfB6234HgrSrB6q2dDmnkeZ1nK5s9HseByHkbxzHabp5v4gR6Hyvh9tOfUwoMfrDtO5Dbxkp h4HgcZvp0cy0nke52nKdZpoWejEZEtasPScRmHoOsdA9XfDrHgOweY9x3HJI+OpLw0BxDyHUOceg 4iCviLQYAeqCzoGdHuO8ehX0wnQH0Pg7g/4Rj1J6OY2ZVjVlAaIVUxaMh6vpa2NgbovitDZhCb4f 44BwDNGiMUUQ7hwvWgAOYdcSB5DoLiPEd48idj5fwfGCpQCoDqepBKEahzcGIRlAGEZph9vCjItp 6A4xzEcMCfMx5QTplAHiQIeo/B7k4H4Y0cQ7h1D5IXGWP0f5ASBkE+GO0JZBSHkRH4awvRjixR4M hlg1xtixGoLgUA1RXCsaYNoUQyxaDHG6KUYotg+jobjAwdLehcDwidImV0r5YSxllLOWg4xxDkHQ SEaQ1BfjXGqw0Xoqh0DkHIL0aAxxcDBk0M4SIvRLBrGIJsR45xvjgGQMkXA9B6DwlpN2b035wThl ePs1cKyFwZHuOxMI9jsD8UOPY3g7z5DxigOQbIxhdD6Pkc0xhhpxT/oBQGgVA4ymNoJQehFCaFUL oZQ2h1D6IURolROilFaLUXoxRmjVG6OUdo9R+kFIaRUjpJSWk1J6UUpo4QEKZW5kc3RyZWFtCmVu ZG9iagoxMyAwIG9iago2NzQ4CmVuZG9iagoxNCAwIG9iago8PAovTGVuZ3RoIDE1IDAgUgo+Pgpz dHJlYW0K////icLlZCLlo+LzrItQ6Aghxn7uY9VVnccTVJhmPeRcT20fNNJBGnUjDiKvXwq3gNE1 bzULxNLT2CZrP2RPm7O9u+iQ/AMGIBEoz3Ayh/EEvWA5ySUMnP4yCD2WWNlKFZQzpZE2rLFI1IG5 BgmrC8YMRI8xUCwwgzRuGoxHZKHcmEduz/MfGMih0c6qfNpwiB4Aum8s6/JgWQztoXGOfQrW69nK C/GSrcNhVz87yMhayYPJ9W68VsfJQ2g70uZFqdIfc94RBovUZ+MUo6vc/XVgx2rOhMGVTQT+iNfl zoC37vOW//kh02EE6ASwxAIlJcmQ801SiZtWhyQtbfKuJOChut+b3LP94ZsBkmADuIXNSXkbmwK2 8YraH/fNzhuucNaOC7NBCJTdCiY+Dt/D3Cg998M/rrXJidXAVqPcBBOykh5m1Cf6sjIh8EAAtBwo 8RTrMMKh+Ux2uqIZlqcsSTpLrw9zqsGly7LmzGYD9FcX4IjagoIm+DzJEdNxPhysisy7/XZ9o0Ev ig2VjQLtpeN1f2X3pl40cHAH4a8kjTnwSTdmxtuo9WW2i/O4eJic7hgC5r5hGy7RIhCARp66N+fy na7NRaMz+y8mtKi+UZbWVH2UtZjDh7rUBwFywjhZtNYHgRurtBfb2syDmR0ab3GXBCcvx67qm7br DngkZy37b64XG2Mu9j76etcYlEaKK0uxWxNgRa4WMb2PViS8UZRraLDOlqcNkSHkqrYrNOJ25j2K RoI5XbP27AkbqVuvFMNg4loH8Owp1JbfAMvBd7H+AfiBOlU0MEI+S+ua+/9dW+K4Y9KkjKc7bKcG LR+4LCCxrVsG4otJIdc1u9I1GS4X0ZHqdh2Ssoo6ubdZceR5IpHVKXRgc5Y3qFEK3Ws49T3J37Tn cmZxrB8pBZENf7OfVN0UtFCq7Pn89tZnL8yl+axZ4B6/UsrffM9wik4kKaMBPlhS6ERL5TsiTWru 8mSbS0S5C5eD6xNTW52if8dFgQWd0+7iH9MeQSCJMBPtCmVuZHN0cmVhbQplbmRvYmoKMTUgMCBv YmoKNzY4CmVuZG9iagp4cmVmCjAgMTYKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDAwMDEwIDAw MDAwIG4gCjAwMDAwMDAxODUgMDAwMDAgbiAKMDAwMDAwMDIzNCAwMDAwMCBuIAowMDAwMDAwMjkz IDAwMDAwIG4gCjAwMDAwMDA0OTcgMDAwMDAgbiAKMDAwMDAwMDU4MCAwMDAwMCBuIAowMDAwMDAw NTk4IDAwMDAwIG4gCjAwMDAwMDA2MzYgMDAwMDAgbiAKMDAwMDAwMDc0NCAwMDAwMCBuIAowMDAw MDA4MzA1IDAwMDAwIG4gCjAwMDAwMDgzMjYgMDAwMDAgbiAKMDAwMDAwODM3NyAwMDAwMCBuIAow MDAwMDE1MjY0IDAwMDAwIG4gCjAwMDAwMTUyODUgMDAwMDAgbiAKMDAwMDAxNjEwOCAwMDAwMCBu IAp0cmFpbGVyCjw8Ci9TaXplIDE2Ci9JbmZvIDEgMCBSCi9Sb290IDIgMCBSCj4+CnN0YXJ0eHJl ZgoxNjEyOAolJUVPRgo= --------------040504040608060104060608-- From uupcypress@bettasbrasil.com Sun Jul 01 16:10:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I55kr-0005Rk-Ba for simple-archive@lists.ietf.org; Sun, 01 Jul 2007 16:10:45 -0400 Received: from c154-75.icpnet.pl ([85.221.154.75] helo=p-wugtg6n392cf5.icpnet.pl) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I55kq-0005e0-Sv for simple-archive@lists.ietf.org; Sun, 01 Jul 2007 16:10:45 -0400 Message-ID: <001c01c7bc2d$7e1ae330$06c3c1b4@pwugtg6n392cf5> From: "Beulah Mckay" To: "simple-archive" Subject: Thank you, we are accepting your refinance debt request Date: Sun, 1 Jul 2007 22:12:23 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C7BC2D.7E1AE330" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2963 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.181 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ------=_NextPart_000_0019_01C7BC2D.7E1AE330 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Your credit history doesn't matter to us! If you OWN property and want IMMEDIATE ready money to spend ANY way you = like, or simply want to LOWER your payments by a third or more, here is = our best deal we can offer you TODAY (hurry, this lot will expire = TONIGHT): $360,000+ debt AND EVEN MORE: After further review, our lenders have established the = lowest entire payment! Hurry, when our best deal is gone, it is gone. Simply fill out this = plain form... Don't worry about approval, your your credit report will not disqualify = you! http://planzxtranes.com/ ------=_NextPart_000_0019_01C7BC2D.7E1AE330 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Your your credit report = doesn't matter to us!
 
If your family OWN = property and want IMMEDIATE pocket money to spend ANY way you like, or = simply want to LOWER your current payments by a third or more, here is = our best deal we can offer you TONIGHT (hurry, this tender will expire = TODAY):
 
$350,000+ = loan
 
AND EVEN MORE: After = further review, our lenders have established the lowest = payments!
 
Hurry, when best deal = is gone, it is gone. Simply fill this easy form...
 
Don't worry about = approval, your credit history will not disqualify you!
 
------=_NextPart_000_0019_01C7BC2D.7E1AE330-- From simple-bounces@ietf.org Mon Jul 02 05:19:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5I3z-0002NX-Ip; Mon, 02 Jul 2007 05:19:19 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I5I3x-0002Dc-QR for simple-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 05:19:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5I3x-0002Cq-E4 for simple@ietf.org; Mon, 02 Jul 2007 05:19:17 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5I3j-0000P2-Ue for simple@ietf.org; Mon, 02 Jul 2007 05:19:17 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKJ006T3OJR24@usaga01-in.huawei.com> for simple@ietf.org; Mon, 02 Jul 2007 02:19:03 -0700 (PDT) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKJ00D14OJKB4@usaga01-in.huawei.com> for simple@ietf.org; Mon, 02 Jul 2007 02:19:03 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [222.129.224.164]) by szxmc03-in.huawei.com (mshttpd); Mon, 02 Jul 2007 17:18:56 +0800 Date: Mon, 02 Jul 2007 17:18:56 +0800 From: wanghao 67525 Subject: FW:[Simple] I-D (Updated): Clarification for 'off-line' Status Assigned by Presence Application In-reply-to: <000601c7ba2d$2cdffd40$3e6c460a@china.huawei.com> To: RjS@estacado.net, hisham.khartabil@gmail.com Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <000601c7ba2d$2cdffd40$3e6c460a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: krisztian.kiss@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Dear Chairmen I had submited a draft about =27offline=27status in SIMPLE presence as be= low=2E Can we get a time slice to presentation it on the face2face meeting in Ch= icago=3F I belive it summarized the leak in current specification and had= been discussed in mail list couple months ago=2E Hope get your responding soon and thanks for coodination=2E Best regards Howard *************************************************************************= ***************** This email and its attachments contain confidential information from HUA= WEI=2C which is intended only for the person or entity whose address is l= isted above=2E Any use of the information contained herein in any way (in= cluding=2C but not limited to=2C total or partial disclosure=2C reproduct= ion=2C or dissemination) by persons other than the intended recipient(s) = is prohibited=2E If you receive this e-mail in error=2C please notify the= sender by phone or em ail immediately and delete it! ************************************************************************= ***************** ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A howard wang =3Choward=2Ewang=40huawei=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =C1=F9=D4=C2 29=C8=D5=2C 2007 =CF=C2= =CE=E75=3A09 =D6=F7=CC=E2=3A =5BSimple=5D I-D (Updated)=3A Clarification for =27off-li= ne=27 Status Assigned by Presence Application =3E Hello=2C =3E = =3E I have submitted a new draft to summarize previous discussion on = =3E Clarification for =27off-line=27 Status Assigned by Presence = =3E Application=2E Hope state completely about the leak in = =3E specifications of SIMPLE presence=2E =3E = =3E Till it appears on the list=2C = =3E http=3A//sdsunqian=2Egooglepages=2Ecom/draft-howard-SIMPLE-offline- =3E status-0=2Etxt =3E = =3E Comments are welcome=2E =3E = =3E = =3E Best regards =3E Howard =3E Aaron =3E = =3E Abstract=3A =3E =27Offline=27 status assigned by presence application usually mean = =3E that the presence application will expect his watcher thinks he is = =3E not online=2C though he may actually be online=2E According current = =3E specifications of presence service=2C the watcher may have a way to = =3E find out some clues to identify the truth=2E Such leak of = =3E specifications will make confusion in implementations=2C especially = =3E for IOP=2E =3E = =3E = =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E Simple mailing list =3E Simple=40ietf=2Eorg =3E https=3A//www1=2Eietf=2Eorg/mailman/listinfo/simple =3E _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From qnegj@opfa.com Mon Jul 02 06:11:09 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Is9-0006bg-D7 for simple-archive@lists.ietf.org; Mon, 02 Jul 2007 06:11:09 -0400 Received: from [81.214.231.49] (helo=dsl.dynamic8121423149.ttnet.net.tr) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I5Is8-0003vB-0h for simple-archive@lists.ietf.org; Mon, 02 Jul 2007 06:11:09 -0400 Received: from qey ([67.82.231.206]) by dsl.dynamic8121423149.ttnet.net.tr (8.13.3/8.13.3) with SMTP id l62AEX4f024472; Mon, 2 Jul 2007 13:14:33 +0300 Message-ID: <4688CF1C.3020703@opfa.com> Date: Mon, 2 Jul 2007 13:10:36 +0300 From: swimmer User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: Fwd: article.pdf Content-Type: multipart/mixed; boundary="------------000307010700070804060307" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 --------------000307010700070804060307 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------000307010700070804060307 Content-Type: application/pdf; name="article.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="article.pdf" JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cK L1BhZ2VzIDMgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbIDQg MCBSIF0KL0NvdW50IDEKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzIDw8Ci9Gb250IDw8IC9GMCA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0w IDkgMCBSID4+Ci9Qcm9jU2V0IDcgMCBSID4+Ci9NZWRpYUJveCBbMCAwIDQ5NiAxNzhdCi9Dcm9w Qm94IFswIDAgNDk2IDE3OF0KL0NvbnRlbnRzIDUgMCBSCi9UaHVtYiAxMiAwIFIKPj4KZW5kb2Jq CjUgMCBvYmoKPDwKL0xlbmd0aCA2IDAgUgo+PgpzdHJlYW0KcQo0OTYgMCAwIDE3OCAwIDAgY20K L0ltMCBEbwpRCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozMQplbmRvYmoKNyAwIG9iagpbIC9Q REYgL1RleHQgL0ltYWdlSSBdCmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovTmFtZSAvRjAKL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIC9NYWNSb21h bkVuY29kaW5nCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovTmFtZSAvSW0wCi9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDQ5NgovSGVpZ2h0 IDE3OAovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEwIDAg Ugo+PgpzdHJlYW0KgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUrlktl0vmExmUzmk1m03nE5nU7nk9n0/oFBoVDolFo1HpFJpVLplNp1PqFRqVTqlVq1XrFZr Vbrk2K0FX8pKzUKIYOFdg5VahzOb/f8Rs8EdNohrxPLZhlvgaLgYYVpbM0KabTdLMVrNakVSksVM ObInbmNgTahRBnuUgmBlC/NBwMzdukFc1tf5WPMCRZnGylLECzUDIYA0EEVsLbinLdfiW6ipm3yU Kzlg9zjQCKpB08CbJWKxB4UK3gAM8CLBY3xmxcIdJzw7UHd6iYCiOJgnJiTThpR2+5zF4hJRj/Ai XEg5W9wATnZlOz0MEOaDkifYtuswL9IExpTlOgYmvAg5Tiwf4qm0zCIOe3rgHKX5ooOZjil4IJsi ieKBN4ZqFvMAB9tcgkLISHaMF4iL/oIJaCtasCDtehUFIGzDJIPESDRMO4jBuibgw0iMDIKBJUsa RZQiqgcQni+8LDuhgjQCLaGR4hj4KtBq+oIxYrLCgRutmVMuGbF6FS5KaJTOirooREyMssgbkzyu raRWiEGgwADIR+hBtBvGMUIbMUsMyg0ZoK2odu+hM4IKxo80Ogq7IMeI7huKpKn8gbTCXEaEzM1z +IaE6EyfTIARiAAomyuzmoFOcjIE0jokiSK/OshcvIGt4zDhSBuKuPNTUa6iCK+QZorOThTvQgQm h28iFQogkRhuI0DOXW7UAAIwqvFUll1OhMWoJAYmgBbQ4HTQUwAAK0J25IFngAcpBkoRdmoSI1HA BDFoobHT1FOcl8IEPJuycgdvkoPNaVI5xBuggobMzHQADgVNqWsgVsn+Z1jUMg54lDilFTrcspIF QSBWYI2OoRjSBx5LlsW1mYrPhYaCk4gVdOTdd+3IgV0Aw0t1IG1kb4+g1LIHY16aCAGGXxfROZZX Sk1NLWPYOAD/4jBV7GoI2CIXfSBCyG47mcZl7Obf07yLUNfxJdWyISaI5lTVbqsRtqBWPoJuFqgU JG0PMmoVpLhGbWsioYSOCgBaPB1WhC4oGckewPwkoIFZsqoFjPLaSgrk7cZ0yTrtIzXtcu3bPlSD bkgfb6UguZRIgZ4y0SPZIRSAAM0LHDiM1/Flqck7oOUPUIFMDo71IxK81e9S+LjzsIZG6CWOgfGm bx8UShuW6KVgSBko4BfzO2ceRvb/l9ChD3FSIs+7NAAH3CCL4X6tXHPCL0sxmZCg4JpWG9QKJmoB I/G0fZiKhSDIoTO/EhT5WDIOIZAJ4al4AA3V0h1UhAoDK1U+QlU73oQAATmztfb8n+kHdzANHBBQ unldQCZX51SEwQFOmtkrYXQqtRI3BiZBT3J8AAutKT3gALqDvEJq5An6ELTcQSEicInNhAAGgpUV l+MIIEjxMBb3ENAIUZJlgWSBwqRYIMZqnm3Q/hWQJLQ0mrEHaKQZn5cWFsNT1BkbrriCnRVO8Ihi Ojnn0ABBqG7pCCSLFCFlcCuGMECjykRc7AyBJwY+hsgrv3EkEWSQdQsdAAINN5HiPUYEaECisb4h K1RUhRCwvBcsto1kEidFyRpAm8y1lw04gaNSBqWOwcGNRBx/tseeQR25mFFR+RYUoZwWDAPjc5Gu QbH2CJLiYQg/j+pPEFeoDddApTwTOhkYAwUOiBhzPICd6ckFCzFmQQRtwlSHzRX9KgTgqRpu2hmQ edMJU9EDbrMgKwAmMkCaTGggqKpwIFIK0MABtZuK7II6Mg43RFqZnZDVPjl54L8IGo2b84UlubXj MZ3xA3qBWASQmOzq0pvFjIvcggd0A0zjuNGShBm2iUZSQOh6PqIkCeRRAo6BH5m6NjGtBUgT4P8a 25Nlq4I7MwU8qAKsfGnwMAA1I38cUBptPIsYOYGGtAAPZBcgb/2wQ7IML4SlZ2ZUaIWmYX9W41pr oaQeQLn2KDMDQnMagcDhHZrQF1vpCDqoFPk4mIxBFshGgnH2qxBaxn6Rau0iFb2YTPoFKsgcrQAI TgxJYjlbiONWf8ItsBA7IjlCsWoqShT4QzrAQ4G4UXZJzXQ8FUIAGaFfCWkR8VNUmIQmsQMcxzK8 GTQm5FH4oVDyqINKKSBNm6lhtaQR7szCFGvRayN2xBXn3HJ7CAzQ5iCQgvAbIpd4qh3BAFF8/pT4 LpNM/gXBWC8GFdSayLBuEcJFOhqsOn5E3rIuIgkRAOE8PYfxAf4giw2fu6IhUMgoEyICRBsX6QJE KQEbapiHGmNSSuEtcQJtkxyDJSwfQK60NiHilaua8X4/2QruIGz+pcNBBhVvORKk2NsqZVJAKkU5 mo7TXVIFYZsvyCYPpRhmWMZiCjTAmgo143VjX2WdH0ZrAKEpey3PlOovzjX9IFJuFBD7F5W0BoEi VXUO4Ef4FYLY5Bfs6r3E8gcNQAZpyyGakwqQ4BwHIJSqpBUdJnCiIsbqCUfxfS9dwgk/mjLfGo/U glk80kGttoLWWsyEnZtDMLR5CJGWlS8OQ2emAtqfxi8sghemRipEplNxC88lRAqYDd+ov0LAY0lL p82tNsbZQ4QPLlpbmkFlgQbb+xItgACwFFcwAoPVWp6ABkkZcR4mQWpcgksNVv1uAQPSRAsp5v21 v/bGhkSHM0TaRQuKC1Bw1fvwgel6Ry4IQnPUCBwt2QWyf6uxBdGIHt4y1XUNWfm+HJQ2v3AOTZWh 3dEZo5A0aMkUXzJZBgd5pzYQMLA3dLjkTguc4wocXkCH/p9ahBBma3x4QIQYAnIKrwA2G4C5+Z7l 5vWDKPJ+rY0h3esgY3ROTbIeOnTEwWmQXv0QgBNCd3kQwOKnGZBQBWTWHyPNnYO3dX7t3crmluwv B7x33v3f/AeB8F4PwnhfDeH8R4nxXi/GeN8d4/yHkfJeT8p5Xy3l/MeZ815vznnfPef9B6H0Xo/S el9N6f1HqfVFQAEcbU3q/YFIqHijYpJuelmJRQAgQE6Uds9j5QAW1GRaxIHuPE9piFfGIX8oh7yi Szshp0/4JAqEipATzeDSutxzOABk33/Vg4CnE5Bn5ZFRIgmIGKE5JzPXhVCsGbLJDqwKrzcnFqKK RIu3Cslr9BF+sqKu4EDjMqwF0MyHsCBhpEVPvu7nPvkgqgbvcCFBsg7g7jeATAbnrBQhsqev2P2I uMsgMIvmCNosUnPmIt+Mgv7CBB9gbP8wJmjFfQLwDCJNVqYCCv6NMvimmnQhKH+LCQFuAQGgAHRl PnhBQhKB0gzJnDAh/QEkpwKgrFfM9gAP1DQCvwOvXmqN7rgDovxiDB0udN1tOCCAbG7uIP0iLNIO fk0l5wwlQAAOepmkRgzKlgEj7wgOTHCE0psN0jjNymowEwWnsv9hIo3sMj3QrwOoBMCNcqcNGiDN 0CGsiKctuOHiMNIPxQTmrucj4EpPXAAOyjXA4RJujw8QgmIn+Q3qIJGGcAAFGgblfEixDoSwri5E xp2qiJ1LylQPmCCQFHriBnvQDGXiIFxvqEnP6GDFGl0DdHbh0h/RfiCPaRTNaQhNvlIF7BpQDiCo 0RZl+DmAMB0jBtuAjN7iBopQbiCxVAqwZiCRAgot2jom3P1Q7PXnvutLGCCLbEbpRmZEZl1wmgAQ yr6QfxqNZvvNvt2mQB0xAjlNnhQyIREMeRxBpmhwSMhQbw6O9w4CCRQiDQWw7FGodsyAEwPFnxws YJBr/KmPix7IQgAQnDlGBP+yDN/udG9xmCCQ7wWIrN1yIyFE6sSiGrbOcgtuSiTPvCFkfxUNgHHI wKwDyRWqIHMSat/t0OeGZSPR8R8MQljBmNzyjoeR3RtxKmjSqyzy0S0y1S1y2S2y3CVoSHHRtCGx 2uByuS3y8CXB0hUlTMlwEgGCGBQrWwOy8zCiaAzAEkqlGyYyXJGhqShTGzDTJCWkRnbypQxMdRcw bTJzOCWgol8KCTMrSFUCDFBHCPiTOzUiQAqyGzNAASCzNlVMsAJu0zVTbCQGOjySZiGGYMsRGzbz gCOwWBqN8l7m3SqTRRSphzfzgzmiMAurgSZxZFnx7DmAbwkpsBmhBn6pgTnTvCLoPAtmXx7AbrMA onPztgmqRTvz2CRy7z2z4T4z5T5z6T6z7T7z8T8z9T9z+T+z/T/0AUA0BUB0CUC0DUD0EUE0FUFs FC3DTMQrZUGLViIDvmUCtq1lPCeOYCWt+iSSpChNdiJtNuAQUiDGTmsIBNhinFeieSwiTuqpLiLU Rig0XCIu2tAIZrVCEmFKdCEy6iivuNOKsuGjZEEiKLar6AMLICCAgoCoauqlmSaCEiztQ0VH5FCH SBsxNIciDwi0YL9oZiwghoHl3HmxGD6raIoIUIdhsg8xjIpwiiFIhAMIiIQrDMRojuft5CIrIIDi CIWxXSnFfkGosrMnl0hovFvryTlCOn4mPiwoHwhNriDqARplN04idN1qDI1NjpfRyDApDGtpEGHp FF1hKB/hmNpDdHWUMiBI+EaMOJACF1OjWjwGFDbmGptVSiEP2DnKBFzrMS4iDNrCBqlGRFqjqEGL sizq7Jsrv0tgAJOVToVVel/HUN0rMCEpAECESKDy9q9pfEGRNizjeVcvdNHwuDdJaJRJljS0Hlyh I1tjA1NqEVkVPF4m2s2wDmuJMiRI0DfjgiBS9tjiFVhDJjZGJNuElivqLo/VgTYCYwfjokeKF0el yqnFjp9p+kJnSqUFYCBVUkzl0I8D3VLRXMOrujBDXkTHcn+J+E7kfILCEKLG8iCNvy7klvxRKHqN iJ9AogTp+EeqeRkKBL02RVfSxJ4Hup5E3iDJUJKubDum3K6CyImH1LaSFF2KK2kD72bniQVqZpdJ pKlWKKGDu2L2qCBWXnH2OqUuiN8CFzQqp2wHZqDxjubCFVFsxW3KqMLnWIEQ4WlkxCaxSCCIak1N Wk/zXDeLdq+kWLgmfrBCGLcSlFLDEl7S4mujeFC0XUdVXorzeR028KbxILSUtEnLeH5U+zil+rAI qVgjSr3iDLj0zG2EwFkEeLaXTrCuEhyhfHULLtnUwDfjFn60xw92oAAG9H9q6q7jcv7K+GWrfVVL hCEqNGk06zmKw2LCEUIx9EfoyNIXfInq01Bz3iWoQDdWnt3CBWsm3A4Ltx7G4UNgAKqjdAds0RgG +WmnlpxCEvrpqtlzRptHJAAX6UZ3uNcAAUguIszvauxISufp/o6iBpRtI1rrB3hCDj9KEUTRNqrD dHIMxPypQD3MoHuiC4GNyKA31lrN2q5mQNmluLwiDOniBTa4HnYQxiCX14V3SLNXhFVv9J3NTzXl 0idWAVrHlu0BTkwEDDNBqSTTRjJlv0lLmNXUjAAWlBI2mFK4kiFjF1FKSKrO1sErZ3DIYCB25Bmn wTMHOBoghgzSVHbldWqNTQ1uulDnc1VO3i4hTqhABTQh/42GoF2Fo444biDVFK6KIEJX24NCDuFE EnwgAXBWeIPV6YlqFYmqcX3l4v2JwWDuttHO3NXLCqMCBUPkljXm1LXiEnH2h25gAKftxqMpY5CS +idEMMK08uYp8uBgt3niB2s3VLIsUkEkdXYJIkMCGTIOCZhX2knSVId0dGjMoVsw5LqCFXjtQ4KR KLoYpJi49ElsoFBEvXgk9K2Zt0yQBVhnzjdZg3NHSmvlNFhJdLBmnFSiB0P1urDmd5ezRIKESZ4w VIpocKAgAGZZkCFEakiGOoZnaNREuEG0bkSQNuD40aEgqtqZzphGoUaikBmgtkI2OZ2ibSj6RC31 ziIL2iWaVid22SFEoZ6iJV3BsrpiMq/OtYJ2QH6rg4btq0OiCsOX6lg5+nBDMtkiNusmSs0Ys6Ez YiqBmhy3dCeUrPYBnAJhU43CVYbGduRCGRWtOhfg54zPDsoQN0Ja1JIu5Knnl4mnAUciJPna1y1P sOcmd1C06YfIaElzUTXCYtICK0vzgQ7sPv6iOVJId15j9Og36Qh5TiaXBiKOvCbvvONi0aKiV6/i O0SiZuKozIdvnTujoqUne10KKiFs3V/l71rBKOzqFI6szCEjWs8FuJ1iUKekfmrHnhTn+DFgms8Z onTCR2AMwu0Zm1KCYbPCMShCD6hYgJIrfGr7fFIbgbhK92PNwk53ziH5qiaOLLso4CCOXHiOPQal +3IOFCFNMzkDqKsXimDNPqwokA0UziDNFv3UtWvzkl7rhMVCNBfhKD4DQEvbZlZljuMt+b8j7JK3 otH24N9UjDXu9boCCqstWYDUqokFUOCN+7DbVKbCLbHiPE5uE8AObVJVhiG3LHscEtTNFMn8GjUG wGwrJFHO5HRBKb3OI8Bb5icQRTqCCkKILIURzaEsBk0CFQitxjrrOtjE/ui7nNxciJMIaYKsBuaH ROpiFkCEdbHGRlZ5fCBBzK7PXukxH8SXqF0BTs2NKKTSioXjoF/Ogo12K5ZjoOVuWx9DZHT8IXWX tuGCEuepobWtGL5Hbm2nAHhuWbMCEtpGmOZ82kdOcO+Q4jXKDCFM6xQczMvOkLm6eQbcUQhu5OHN gxeReugOhNe8pCZFvm23CtzEmDGuuNuN79IHExMiF0YDA2A5H32WUhqPoGNiB5pzfltD+ObyNcLd MZmdfmtj4UlvoJ9ZQcrSVm4LgY+8lN/NMSr9Ul/cBOznfbQCGTupM48qV4+dkV+2ZuyJ7dDdw4b4 muKxyAjBSp9ObbgulT3zin+GPwCd9hzE4GD7BNWkjI34ojmMwYz5Ryy2bdi3RbIQ+ulCGSVWQA0d hI3iX9YSPRcNGmk0nzlu2dmSOYNlcHkHPi3sd97CGWssybuGdk0vfEDuc8dr35d+GqcDE6mFrk5w 7lT497/BqAMc2jXO5Ef8dp4PWiFE55u8xAAOjCE9HIp+XqKC1eiQ/tLFUCzIJjNEM+cpVd7cyx7N GZiCEjyHC8LngjeL4CHGCRSDomdef6MxcoKiC+APXWDKPiCsCdYiWexSXPjaZ3DNpMoE3PxhUhyO RiFP3ArBzAzF1kLBFmiu07xRQSuaMFcfCgq/DmIt+tMNzxVYNkkBml7GSBKE3dFTqBm99RH5Rdbj hHhQvQh9lRpaopsfJlqjNfUJraQHhWZRG/DEEyVa2yNiDfHh4h4rO2efTiDBS34x7bCCEEeFVrHR Sj9WeCFexFSfWM8GZdQoafNpyfPN+0Otv7NYVkXod+OiWA5gdzCHOP3YC5SFSOEjM8ciFQIA4AEg lj7oaiANMAFEAQWCkYjQaClaFQ2CpyFNSFFYqxJTwVUmZyFhuwZyQoBQ6DQyCgmIQUolFKBhqDeD KWHOVfoMASQAR2DQmCr9yyQ4KdON2MwWhOk4R+CgKlFUbhiRQputOLwSCjeETqnyVUqluycAVgAO WCxKDKmFKmjABKVkEwqaAC2waqACyV+CjuFWKDXGsyKTxqOWiclWlSGCnCJ3uDRe+3iFTMqzacQe GxS6gCMx/J2qG0wMHAEku+yiVy27SPR6nVaora3W3orNkE1vV7XbaqYYnb32N0I4YivjfClWsr9/ lFFt3GQWWRKwbvRpzaFjD0ctkaXQUqqHP9DdqlOPHHwriABT+Ct0gAcCq1lslFUqfjUSFWuDwhSn OF65y2+MNWpz/qIVLfpApZQoM8SDF+gzlPOubvQikTsoUOBKHibLVmoaidPyDDXQlELKis/sRRNE 8TiwLAzN+LaDQO0ZFukAAzRRCQ4C2KIbsJG0QwYgy6qEjUKxzHbDKeU8kvs8yFMcg78om/sjvo1T lxq3cISXGiVR7LsRNcm0vTFMcyRE35yS1MsyiMwkpzVLs2KVN8JEWzLqTnPE8z1PaFSNPk/tqdLo BuX9C0A2xKFPK9D0OchyM3Rk3zTSNKNXNrtt3SdKxOy7a0Knkw02hQzPObpF1FVFUxNBVVVbF6DQ C21OzHRb1r7WLVU01Ddx+uj2NvXFaINBE/juO9XWRCUIWTVDytGKIEmzY9YWkIxIt0AD/RC9QAPV ZyDVq1MnIMczWpq6EwuXbqOV+p9wqe1pKXGSJzXK1NITfdT9pEcyY2ZPTevZY82oaJZ4oJQV/0A9 lnFCKxzDMvjflOaSS2k1qsHiO4jShXYAG1cAAEWPOQNubtFrnNwEwxFjUmpZZqTAvSa1Jd6HSmya ORYo7tWGvdWIKaQbEivgrWtl8FPzmNzKzkZtKsyoBGpdsTBskVrodWc3UpY+jaxJ451m0awZmp+T zO7UDptlmJ4U6BFnjBAb06ioMSsADAoNJcjs+KMMMWUp9kiglpoLr4ANyhteyXuBQhvuadp7b6Rb QADsgFyZskptqUABY0w40ysFrfRIzFTuDR1xRcCKOSidb4g3NIVwQo2laZIkiE2NJ1D6SVChvHbn XoAbqU6uoKzUCNGOG/LVX/BpEEyHaYgwqir0s++E1BqbtAXvNvwPoIWG/cd0gpSnN3qGIYQfrLL1 Ds+HyaHTP1ykyO9kl8DtzdlDp4RhqKGIMDtJJQXkM6HSMw9rPUEkOGk4NaK5ynr9ZuyEgzJQAIMF +RQAUBC+wKR0AAwwVlJtUYu14hRz0wnldMqZ/xo11HqgSFhHR5VnK1V+hAkgJjsMbcSfw1Jzy7ln ILAgZidynjxYOzs5cESHIUJGqF0pXIUwBgFB2ApHVuMJNvA9aC0iDtfWmuVMC2XMPYhc/8naTS+w zhrAwgqrIcv8Nu/EgrZSgJCKIos+yR4oIZIU0NaIdyXFgWIQsgzMzJQpai1MoBfY+pyMOQ5xK2Hp EGP0XkkaVyuskagX1nJk1uGGKaXBoElZAENigY4kgg3MGjeGYshUMicl9kAwlqxBooM+X8Q1myny eyyIKjWJC3ToNEWkDeHZCjcsyLfIsPKQJEkGJ+bxF8pCFSpcTE6Ohqz7I/WcegVJG5Jy6KTNRCpD S5hWJc7kIwoZ4ETJUiWYbpjwyHliFVux6C+oUUxHEh0uXPEGcOtggr7XrhmSu0CWJDpxt5JycIpb egASpILQKgZBpLzwDy70golD+vWV0gsvxUCPGrOAPtzs5iHTRIctoh5DlCuSWcV57x1zoO2nY1gs CAYVzDlUEYSkAniT6PPTYhx2DhzlqY0N2qxpuqejuWNBpBiOEFgUq8mrDwzDZVZJWiod2MNYBvRy hwv03QuctSQhS6mbVaILBQgZDov1io0Q4bJrQognPrQom5BX/xWNGb1d5S3QBRUW7SJzXoeIUGzX lMMZ63yaocYBk5cjVm5axRagpBaLPVIdIcsivRqHLLMhUZiOU2RRrkX1woAKNm6BOKmtD13vlfsF W2R9pys0TJJRaSsg4JVRNTOAgoE1wG9eUZyuDzDRWTJqta2CNmyk3TqYAvqUyCDZRYOlipCpCJhl 3VsE4Jx/suU+l559T0KAmBNWVN5gVfvzKfSqudawAO5vfIcBIeTW18O0FZmqfYAQCMsHACcoiHOu OI3x5hrFrXuOzIe4b7cBEGqRMAm1yKT3EUAqGmxvpjX4ILhRVIqQE1XL7hQ8QZh0j+aEanE2HlDt bKfQU7MPJ4SHNcNxWLpQMJpvSrACZZreKQLAeUOYqTRGrndjM1WJlQGEQCdLFGKsaZZy1lvLkdFL sOs8oc1rUpqkYG7mfLuaTWO/y0+7NRT1QSLzfdkzymwq4IXxnNPV0DR58NS9TLqiTbYcfosknoVg ghbw5nnPWW0YaNRtow3CX1GBwrAibPxCqkToTnmzP+mrbkNxsl01zdgzIB0ydDVJIsoJ4cwa1iGk ET5ndYbu+0qr8nYdjf1ULvwdgYCjEIkVvDvD+1uuhEEAza5WzQR6kZqXP3jXgugkRHda6iTeFYf4 cx0gYB2Y7YRBV9G3aAbez5uyehB08aNb+5SHWv1kVlk46ZyIvO3s9q1wnDEIx2XCyGgFQgYDMQiA JI9EpMqqiGjBfVovUTABiLiwSwkGRcWUrmzSUS7EoHMMyrFBDSH3QKsTXtwkT3WX3cZN8XEbQhP9 UYAMYbHRMQIiJWdNm1YOhHc5WeBkJR+a3RKSVMm25OiPQGXGqAC1gaCal3r7SDmUTrXWYUwphi5S uNYAAgqJjyg3PJhSbMrdkQ0vnDEwO+IVzS+62F9aMSmOY0CGD7cgkFICFGJCs9HKnADmxIi0xwJr a0gvTpBEjwihFfSDN0lQ2IAAoyaDUubJFeHkq59kk27VsGKyP+txZN21Sgm+sI9T7ya3iHNO9tib dxUiZn0LyAGpsapznnCtYwpNHqvaSGmXJI6ss/SdXndoqNluY/iG7wXg0wkhlzlqzJtUjxtcLmVU AA0Mg3tTsatIdJkgwE8C1EIb9HEc5z6kO5D9eggkfsne0JHc1ypCymbOsdi+hDfjfHp3+r0sZfuf NmmmGqONo3IKq9iLkp0na+y+0kQIM5o+882w8KwPKYgq8ryaCmyuGNOwofWoM8SIUCC3EKDAEIMq yPJAuJqCqEq5AdEzWeo6u0IoatMIaPYLAdAIUu+h0MoAArMNS7UKILquqLKnS7WeIIa3ccOJsIQr LAUlAMrA+pi4SiK2C/IL65kuirI9KVgAA7VBepmJsXUUgmKKekBBS1uhOuk7wVurbB8/+qiOGWIo sPK4WNOxKzCNQ4eYSSSAmwSQW3SCsMYTqioIaUmxmes7ooK8qV29MIKKkFPD0I6D/C61ASo2cTiO 0O4DgkAoslys4Kqx2NkSqIaD/A8bMN8Z5CIl4diIc7K6lCUFC52NVFEoM2I8aTa1GIas6tg/W7yI UUEOWMmVBCcILEAzOM2wY3YIM+sIKrE9HDoNVBcILFiILGCqi3uQSryCq2M+oPacOWIpdAWCsGoD mPZEayZG8Jq6CLKAS1o1xBkMS/uLos/FwemNbHDHGyKyaCa0PGmK3HUKElUR4o+DgFSiUO09kAYL IteKwFCDyv7B5Dyt4CaIU9YfoOs+kPZGvGy/QoJGaLhHM6KIVIjDUMU04gZGqKzIOdskZB1IXF3A Y4QABG86AC2XVH68aT8L7IMGolSihG6Y8JFEZHuILJCILImy2esH21uCs5GukLBFeRNGIZ2IOUum yQwIoOIH3IONa+xF0L6CsM+/ENVGIVs1tKzJ82kNTEaeML4W45SN3KPKwoMJ1IWse4c6OKyW4AAx COqtUKSO2q5K7KU0BCUDyseKyVwIvLUGaF/JC8666NTFsIVLLK3CUs8jKL6AnLUw63E3iJqfIkuT xFK8ghE0eLkR2u+LpKUuHATCXM5F5EkT014uHEVGc/CiIW6dcOEWGb6QjFdIa54IUw5EhIikzEaK 7BETHFa5NI+79NfNaT2Os+ROdOkL6+5OnBDLBOnOyQjMgbHO1O9O/PAVc161cQjHlPDPPPRPSL6Y OCsG1BSkTMCIYoKIYU63W/aAAFaRDNYKzERPVP9P/O+DuG0Cq7o+u6inc92q2iiKyDQIbOqIcI6c qfuIYVxQFQIILHfAxB1QBQ5Q7PC/qvEniX3QVLsLcV6CGCGIiYIPW/mJ0etK8weerINAwoLP3Q9R vRwy3NOIakMYcIk2Sq26KCaCagUCGiOmuKUQ2PWiQOy7CaA7oGoLEtfM/G1RzStSuy4BsC6mCIUs ax2fWXMJsnY6uJEI/SMOpG8SmLaS0MMVwlS5DS3NTCQl3OXSxTtTuVUZiqgIUCiC2DyzA7QgkBuC 6IG0kAAkyLiV6SmIYkMo+IMGTGi1ursfLT7HNQ1TxUxUyVS08RdHBG+kQC6a+POKyqypcSOMuP0p 6jiNkGSEpNPK0YwIOFTU7BXU1VtVuUjOjQ3RI1woKGaLY2wJKv84g+Mu1UeD+JgowrEJcekS1PrV xWhWiT0VAPeVZGCWqIaKc3hR3WyIa6uB2H+Gc1WNGHiASASCCnpWlXVXWTUCCDydrXKIMF8T6cnP 6l8IbBITEDyCCF8obXZX/YBYDYFYHYJYLYNYPYRYTYVYXYZYbYdYfYhYjYlYnYpYrYtYvYxYzY1Y 3Y5Y7Y9Y/ZBZDZFZHZJZLZNZPZRZTZVZXZZZbZdZfZhZjZlZnZpZrZtZvZxZzZ1Z3Z5Z7Z9Z/aBa DaFaHaJaLaNaPaRaTaVaXaZabadafahajaYICAplbmRzdHJlYW0KZW5kb2JqCjEwIDAgb2JqCjkw MjIKZW5kb2JqCjExIDAgb2JqClsgL0luZGV4ZWQgL0RldmljZVJHQiAyNTUgMTQgMCBSIF0KZW5k b2JqCjEyIDAgb2JqCjw8Ci9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDEwNgovSGVpZ2h0 IDM4Ci9Db2xvclNwYWNlIDExIDAgUgovQml0c1BlckNvbXBvbmVudCA4Ci9MZW5ndGggMTMgMCBS Cj4+CnN0cmVhbQqAP+BQOCQWDQeEQmFQuGQ2HQ+IRGJROKRWLReMRmCvF5PR2Ol3PR7PR8vl9P2U PZ6viSvt+Px+v6ZPZ7Pd+y+DTJ/Sh+wmdPeavqWTqYP6GTJ+0J7vd6PJ7PF4USXvp8vimvN1ud2z x8Ph9uRwu56vR7wmX2d+QaeTydzGdW9/V19TqBvKOOx1up9vt8zq+Pi20i6QW/Pq5zKDTC3P6qyp 5vORvfA3CBzqY4u9vtuNlwSqywK4UaNRhksVkMxjshXLNZLxZMFlsFnrlYsBlMNoPl7vqxvRjr5g OZxtlyORvPG8OdvN9utxqO53OpzN1qyx7vyXMFcMNttJuN5ruFtttyt9vuR2utxux0OKdPN3uxps NdMpbLFss5le94u5wm+bhjmEZZdFcYZ7nqe55pIXpcGiahomyapommcRtG2dJznCa5nGCc5uQwcR yKQ9J2nOcxxHUc5yHKcDhHAdJum2choGca5rmsb6eGoaBoGqaRmGiZhdnWdJxG8aRnHkeB3GWZ5d HAcJsGWZBcHsfCaJEZZfmYcBtHG4pynedx3miZ5qpoe5zOYYBXlGaRil8aJgF0cRtm0cJxm1DpgG 8cJtFYWBaSYeSztuaL0ngZhmu6Z1EHUcZ3nU9B1nKwbRoaZBhF+Y5hmLApfl0VpgF+W5hl4X5cGK ZJkK6qyoGIXRWGa35rGhIBeF6VBQEgXJdFMYxglqSZGEKcpynMfZ9H2XBUl5H5rFoV5dlWVJXk4S BLFyVJPFiUBKJefZ3nSdBqmaYhkmMXboHQgZ4HeeBlmIZ15GoWRTl8eZ4HmgZvm8cZynC/5sGqUR HEOXhYlkYhaFmXhVlPiJJsMfJxP+W5ZlsbRrG3OMbGkbJhGCYpqGsa5pGea6qn0bpqGabJsmObJr GWcWZmWYRenOdJwHFPRnmYYRHkiRi8nZFR2lYUBa1CYLUmSZhkGVWRVJGej4nZFptG7Gpjl6WRom sZNHGMT5IkOZhkmUVZPFq9J5JYfBfGEXzlnGZxnGoZFSm2+ZoGWYEgGOnlMIdgMYs4cZwnQchwHK ux5ugeC7I6eh4nxBEZGucpxnQqp8nfSRqm6Z5hPpxpvGiZprqaejMm2ak/HHOxsm4bhqmgWhQk68 ptnUdJv8wxp7HI4ayHmtyBpufp4HYeJ5qc9itpQgaS2Ww1lHycZvHIdx1ngeB2+bcZwnOcTLrGex 0c6d51ncbJqG6eX5xEciqnwqjDn9BC7HidZfFlklK6PYs5KB+OYHwO0dQ7SzlCH060dw8HnkdfCp V2x2B9koLaTcvZJR7E8MyOqBcDiqwZLeP0pZu3rklSWOwj433vDsHa0dS7hSFDHGANAX4uxkjNGe M8bo1hsjQGCNJOw2xmDAF6NlHDnB0iwFaMgXQsRjCoFGLAx482ejjGSMcZgsBPivFIJYVg0RojYG uNobzGxunGHAM9YIxGGDSScMYYo1zmPmG4OZlcNo/R/kBIGQUgyBjiHKOIbDMBnjDGWN8ao3xli4 F894dA9R6jyGYMwaw1BnjbFkKkYowRejDFqLYUkEh3jmG8OIYQsRdN7GhHYaA32en/HEM8YAwkLM mGoL0YhwBiC/GcJ4SAsRfi2GcOgdI5GKSEmdM+aE0ZnwGLYZYfw+yumhNCV0lx2GKFEg6UObUGzd GSMXNcvZhh+PeHiPQeY+Fww1mlPOek9Z7T3nxPmfU+5+T9NBCcpBlZzkSXCWMeRbSKmCms/meU/q HUPnmNgaY2hmmwJUSIew8jijhHmPUlTmC8jjHGOkbSIBkDeb0ON2DKBpQiHadEeBnh0jmHUPIdw8 R0DlL0S4x47xmjKGONSlQ45VDYHKNIkQ8CEklYqOUbQ2hpDSSENFa4rRmDFGcOodY4h0DmHIig4w 5xzlnohWWsxGBiCxF6NMZAzRmjOF8j8ZQtReC7mQMUX58xMimDwLoYAnhmptF2KkT4phOijF+MAY zJ6UDJGoOkcY5xji5GON0bQ1xgi+FqYYfQ619C/NuMYaQwxkDRFy6YVZ0hvDnpE4QgTlh6DcGkNg XIpRXjUGYNUUIlxUi2FgKoZQyRfisF0LwYDUHRjPHoPUeNZ7nXPIeNYaY04hDLHSOsdA7KxDQONV wb5NR5oyGQpMbqCB5u/q290qCSx2oLcqZBJI2h6WwkuTweY+R6jhTWTQpxTx2yHQQPSsQ6oNPKJg Ooco6FY25GiNWF0y2BOdHONgcw4RyDnjaOsbZLh93Qw9h95RKBkjBGGNJcwwBrjKJqPUng4TnYBG uMwY0FcQY1xtjeghLxWC9WcMsXIyxqi+Z2OAer0BsW4RWOYVQmz8DSHJjjKGUcpECLdTocToVJjk Gy94cz7RzjaG+NREo4BrjmHkOsemU81ZrzZm3N2b8azjNFh40OcM7T/LeTkyk/X7jVGMMSmY4R4j vgncxfc6S9j8exOUeVLygD3SWgkeVHYstXKoPeCQ7DLk6Khe7FhKKmQzHcOIbo3x6OTJ/fMvg+Sa lOKsTp60ER4SWHyVApo7zIE1MysofGRR3weMfTEu2vZLjyHZhyAyYMiEdHmPHIo8qDUeSvrabyl0 sX4o65baA9l9FQQSfDQe4TdEmJNR6S+zVlYc3URKdOjx5Dvo0N8c0CF+jdHLcEa0Mx22cK6PSDkG Cl3L0hQ0jD8x4jYGsNIbo2BuC+FmMIXAsBhjAF4MYWAsxYDLGSM8ZQwWnC5FoKMRYhm9jKFaKNXw rBUNqXzpgaw1RniZE8JcsY9d08nlKLMXBzZHDRGkKYS4lZSCyGgMcYq4aKDKzINoZ41sSxEJ0O8d o8mXDXxGNMYAthiHaGKMIYQxBhi/GINIZAvhUiTEQMsYoxhTicFQLsVApBhi9FgJgU4hkojceuLY WgvBnjHGtjIbItRUC6FGJwVItBadhF0LgW4pRK6NHaQMZkjHdCkFgK8UCD6sDIGCLYW4tRHCGEwJ QQopRaisGCLMU4uRQCkFMJsTQpFYi+GmaUZQuRZDhGyOFc40dEpXHsOodg5i8jkZKjdkAwxbjIFs KoXY3BrDeIGzMbWFRxjLF8lwXwweEjSHXV+HQxGHClFcLUUdrlMPWGwmcce9kBDQOFWIc46hTiWE mNVwB0VyOcGgGSGmyOG8FuFsGUGKGiGEGqG4GuJ4pmHUNiGQfyMyR6GcqeGsoqGKwQG+GUF2F6Qy 0EpuJ4HOHQHCGiG+GgHAGwiMG2GgJ0HcHaHqjgseHKhmLyGoxMHIG+vk3eUmHAGmGiGCRaHGGkGg GmGgGiGOG0HA58GKF4psHWJ0ssQ+GyHMncHsGsiEGUGUGkGmGYF+GocAGAjA1uIGRxA2GQGO9kEk GqGcGK2gHgHMHAHIjgGuToGW4QqePGdUwah6cZDkRkGiNMXSGaE2EqFicwgeX0F2GKFgGeGiGgGU F+GgG4GwlYFyGUpyHSgkKiJkPYHItk/kOMfWHMVIGYG4jUXIHISSGMG3CQoCcKJeH6HIHEJAfCdC bgJWoyHmGwGiGIcaj2REK6HyLOF+FgF+GaGQGqFgFu4vGWdKGXEiGUPEHRFiJUHs+kGwPgJCKgcw HsfAHkZW3SIGLPGEgQQsHEHcHYX2QWdtBAHkPaHOxiGWcjG2Ka2cXeHmhnHAJYLqcmwqYDCUaOqU IEcgI+HeKaHkKUWUeuH0KWfwHyw6yog4WU3CyKMe0mXCH0H5GGXCJcm2Hu1qee1sUgHS060GHkKA 16o6fwSwLIQyHcHA3kP+HKsgHUeaHaG1Eg2eJGJoQSUkfChkHu16J+QSmWHMgdFiNGI4HgEiE+Eg GkZcG0bDFaQez+FeV2F6FmF2EwEGEwHKG6HMLOz+FwG+G2GwFwFcF0F0FUFuWEGAFOFQFQGMbUJ4 3OGoqAqgGYGobwXkGQFKEmFOFmFGF6FiFUFygMxcHEFcE2FVECGaFKr2F0F8F2GoGqGmE8EcE4Zo QoGQGSF6FejKGGGUFKEoE8FKEgFWFmFKF4E0EuEyGy/aIHF6GeE2EGEyE0EiE6GAGCGMIHK+HEGW F4tyU0GcGIFuF8NaGEF0GC8qGmXMG0IGGQmCFkFQFeGaF7GgF+GWFqFcuMGaF+FWFoFQG4GgpKGn AYg0JkQsHCF8FsGHOUyAGgGoHLFmRqGAGaGKGUGYF8GU3SfAHhOYGEFeFWFcFgE6FS7IGaOoGk46 FvAWb0lfBYG8YYGQFWFUExBvN6IEHWpoF4Fc8WGAGWGgVsNGKWHsF2FkFWkcZKGYGe2aHeJGHipm HQd+HUGqGSGke8HUJ0q8HEQ0HC3eHmHSp0vmHocWHAhmwIJRIW2KN6RWHIiSGeEeD0FAGQ7XBuGK J5E+G+FyFGFZLMG6GaR6HQHcHOJGHmHOG/BHR8gUq0HQHWHAGyG8GSF0GIFKE0FaF2FwFmGwGwGY HWLyIGHaHSHZEoHBDkG4HSHeHKaOfEHYHcSmGcpm+MmU4cF4GOF2GWFsFmF0GqR/OiadKyGEPKkO Z8GI6KR6GeGgGIGK+KHSKYHqJ0SYHiGQF2GVF6GiGuGmG+REGuHOHKG8pzPoX+GOF+GS0eJgH4HW dCOiy4kqegKXHyuvTakcG+3efBBfB+GeHPUOeqJYGqRwGWVoG8QkNGg4SYHQhSfmMenaUk1w22JG Gm7JCMGWGoO+dgGeHEZsakGG+MHO3epudCPaG2SWpiLGJ0KyHc4Wv1PopmHSSEGmHjYlYkaOHVTI hnAXAVXAY2GyKqM+H+dgG6GiGUZOGO/ascJoHmpyYApEG4OUwSG+VWF2Y4ZgYILbHsimFaRUeKTy eaXeHYUKKmJMq8HGgkHkHOaOywuuHFYmksHqc4HIJpG8fAncaufEesQQHw/C00KKJlIOSWHiHaHA HOGzaQQ+G6flJNYkfauWneKWJ024HuGGFyGYYERmOGHIOaGGacesIYLYeoI0yKHiGTbmk4GqFIEi FEFQEiFUF+FkGEZQbwxk44GYxMGgEIEkDyFiFwEssuGEGbGg4WG4iSGCQ4GQokGUFoFUFeFaFCFa J4/m66F2z+GCfqFwFwFyjQGcGaGmF6qiGUG0jQN+F+F4FeFoE0EQEDYsyeIFVwGcF6GZO4F0FzO4 GSboGYXoalOMGMFYGOGeFkFAFGEIGBT1KyFegw2esuGiOEHKWaFyGSF2GYGWGMGoMyOgHcFeFkFq GIp+GXd6PikOHARzNgOEHIF4FoFwGyGmG2FMEwuAGExG61esGWG8G6G8TGHfHGOwFEFaEoFUFmEe GIGmFyOAF0FOE0Eq7K7E8aFsFWFLANEiVMMyq6HWFIE8FBVUGJeCGqGEz+YwFcmanofzQ40CHKGi GGbCGaG0LsHcWOZ8OWuXakHoX+GsHCHEGoX0HUyKJEQSOQHZcE3HKkGuGyGaGxbg24hEHPPzBQLy HRW4fAHQJoHijWGsYsHCSYlQHfAWeCN2JoHy0ao6I64CJU0aHWu0PYdmzAHQGsXgHRbCHUouKgHg HURFBIHIHqX2QQHuZaG6SYHeKoMAJkHqN0HNUGpGtkG2F+HIG3DYGQGRB+Gqc5DiG4PORgU6GgSN YuHZLUFQR4ZqG8HAxCH4GmG8GQG0HIGacwX0TIOEPXV/B0G47aFSGIO2GSFoGAXeHWks0mauKASu JMvcLsHa4ImikWGeGcGQGuR5FMkSGqeKF8GQF6GwG1AMGkFkGpfgGxetByG6LyHWGNSsG6ZhVWGX K+HHbCcm0aRVlmGwHUdCGuHGG+xCH6G445E+GsGjSsGoomhcgjkMfaHcF8FUFsy0iCuoHDDkQgPm G6uodSFwr+3gHSIGPiHU/4pEHKXeHiKEHw6YjOGaGsFsFaGGQzV+ONJsHiGDKlaQcUHSGzFeIIfg GyF1UzV0GmHamUzJUSHQHedmHGMKH0RqGYKAHoPOOqH0xWi0GuGfHSHYdCHqGzeDAWG6FuFGFQT+ G8egxYJgJUHrEeGOlploOcGuG8GYHIHRqcJlp2G1o3UOtYYBKSmcHQcYR/e4FME8YcYU+cNgFmRu GEcbACGYGIWCGKYwGQGsGcGxO+GEsGFkEWDcENCMu4P+R4GMGHbmEWFGEUGcG4GctmGCgMm9GKFQ F4FsF8FaFSGEGKFkGQHIpLeeGGGmGKGaR4GmGyG2GeTiF4GIU0FlfgGS6sGgGuGEFuFcEWHcfWIG qiG+U0GkXOlnAVIWGJEuGcGSGycUHEq8G8QGT7W5FMGaF4GEFAFcFMD++KHFp2IGciHolUHSGuGX REGHesF1wiGMlaFgFGMy+FngF0HMHQG2FAFMDqSKM6ehDAGOFwFoGOGMFwGWFOEiFAF6FUFqFPMz ZEGrD0gNRMFkGYuKGgF8E0FCDmFqF8Eu4SF+JunWHcHmFgFWsSFqGTVQkuzSkEgxRoHEecHZgsGm HGHWT/oq/rSAe8gMncKZJQMjp2P6HkwqHNPEFritbKHUHBjcpFW4GgGwGRUeHMHKHOGtSWJ1bAvn KEJY1Wgw1Oee3huAOwgRJQau1OeyWWK8KqUufAHqgVIOne3OIGKow4MUKSKopqHbIgJML4HgKyHY LBSGHK3oIEWUH5j9ykfCHgPMG8HaRMdmHCg0XCSYHVmUOmGoN0Hs0SvmHstYu0G8HTO+GQGyTPp3 yQMNlCLeHa1Oo9zUHQGwP6HPvORGJ3FjYtyU1mku5sMMkGnaHgF04tvsGuYaEkF2FuEsGcGGO2F2 FYHHFOIGGUF4G4GCFoGoX8G7C0GOPuF+qlWKFkFiscGUEYFiEjRwGEX+c3uanSzv4n4oncHl3iFc 94GqGQF4FbZGFwGqGte8GyGTJjeYH+Q5loGw94GmGoVyGIZ2eKqeS2GIM4GuF+GGFWFiFSE6qgGp CfyR4p6EzgeXkmHS24HnlAK6HqgCmpcAH+esWUH60SewKPlEdCgd6H61636567696/7B7D7F7H7J 7L7N7P7R7T7V7WIeICAKZW5kc3RyZWFtCmVuZG9iagoxMyAwIG9iago1MTkwCmVuZG9iagoxNCAw IG9iago8PAovTGVuZ3RoIDE1IDAgUgo+PgpzdHJlYW0K////vTxFnaF8/EpqY5/Wf9HmCgKiAXyP 8s0dbyIw4lp2zBeyErVUjrGf+RU+0JUPtqARWaGO6ZRbBgR+N+bYrbPwYMWltFRXU01tkh4CodSi sy5EQhfYnh3dHFXD9QJ25WM8ixeR4mvfUP39Up/S9VMAOpUXEzQ18FCKs0WNKivwZ7YI+Jhz1+hx 1TsRpzFkp2v6vn8v9G9/fiPFC07w+7WmA64/d4Yo6Vtk+gKVX6kBWmiAiVzwCdsTzuZhv+IXZebF pV1MzUanMkGqx6BUyfq9SoQaOo31TlzcsBy+x4GljScC2fVJgSeKLO8rgbgmPgOqWD44ToyVKj2x 6QQzjpJakGxP2u53ZRpmkJsettoiYTJgmoDtMKoq4ZQvFSLBb7Muv40cNvM3nYPSvDqt3pzfPzdg LGcLV0ifhl7BSM51do0Ck8T2ymF5nR20SvxRKTuIimjvlb84NEaW9o9kawXybpi3ZGMZ3gA3kkoz 5HRvbP7XW5OXk8jeKr9tjipygZgLOP1uUttviW65vVItLL4sBBrAnK6JethI52dyWugLZiEJ1XPk RP1T/bqmK+dlWOt/GIctoQIG6eluXERXaKp4cX/sVsPqqcGkT+2LtEV3NF7/YgACaerr10YwLq/a pyBalHcefiDgI3DNryUTJlpyJr1yKCZcFP2jRCxSH9RzemnqmOcLeQt8RrqiWuH9zAe6PzDgm0Te P4kLkqnfBSNI8Lww/DU7eXz2HNbXGaPf0+IPtH5Ukr3dnlCGfVaqxkZm90ObM70YKdnvAPKS38Z1 73r0Qw2yIasCqClYUu+fuefiVRqfbUN5XERr7yQyZROsWVe6DHllDiGOZ3R+Bi1l6YN/ifHDAk4I bj0soKNATf2YBwkRbRgy+4CneofU33FYX/pJI/2XK2zVVw14mFt2MGKAQc+Yc8sZGkWg7yURSIQM kacKKdJ3/yqEeMLg7vNCbjQSB6jeIMMkwLNJ0vvN34116bdIYbZy5S41xRwoCItdG5IF+rPIHnR7 Z0Z3CmVuZHN0cmVhbQplbmRvYmoKMTUgMCBvYmoKNzY4CmVuZG9iagp4cmVmCjAgMTYKMDAwMDAw MDAwMCA2NTUzNSBmIAowMDAwMDAwMDEwIDAwMDAwIG4gCjAwMDAwMDAxODUgMDAwMDAgbiAKMDAw MDAwMDIzNCAwMDAwMCBuIAowMDAwMDAwMjkzIDAwMDAwIG4gCjAwMDAwMDA0OTcgMDAwMDAgbiAK MDAwMDAwMDU4MCAwMDAwMCBuIAowMDAwMDAwNTk4IDAwMDAwIG4gCjAwMDAwMDA2MzYgMDAwMDAg biAKMDAwMDAwMDc0NCAwMDAwMCBuIAowMDAwMDA5OTQ3IDAwMDAwIG4gCjAwMDAwMDk5NjggMDAw MDAgbiAKMDAwMDAxMDAxOSAwMDAwMCBuIAowMDAwMDE1MzQ4IDAwMDAwIG4gCjAwMDAwMTUzNjkg MDAwMDAgbiAKMDAwMDAxNjE5MiAwMDAwMCBuIAp0cmFpbGVyCjw8Ci9TaXplIDE2Ci9JbmZvIDEg MCBSCi9Sb290IDIgMCBSCj4+CnN0YXJ0eHJlZgoxNjIxMgolJUVPRgo= --------------000307010700070804060307-- From simple-bounces@ietf.org Mon Jul 02 07:25:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5K1W-00046B-JX; Mon, 02 Jul 2007 07:24:54 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I5K1U-0003uy-Mb for simple-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 07:24:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5K1U-0003tg-CX; Mon, 02 Jul 2007 07:24:52 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5K1P-0006Mr-Ul; Mon, 02 Jul 2007 07:24:52 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Mon, 2 Jul 2007 13:24:46 +0200 Received: from S4DE9JSAAIG.ost.t-com.de ([10.125.177.192]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jul 2007 13:24:44 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2P torealize presence and IM services? Date: Mon, 2 Jul 2007 13:24:43 +0200 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB7C0@S4DE9JSAAIG.ost.t-com.de> In-Reply-To: <20070629092928.9153FDED81@mail.orgltd.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2P torealize presence and IM services? Thread-Index: Ace6GZIu3gmGf2+MQsukwUUTYgUwQAAA5nswAAMa6lAAAzzO4ACX3EKw From: "Beck01, Wolfgang" To: , , X-OriginalArrivalTime: 02 Jul 2007 11:24:44.0326 (UTC) FILETIME=[97092460:01C7BC9B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: p2psip@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: , Errors-To: simple-bounces@ietf.org > Vikas Tandon [mailto:vikas.tandon@orgltd.com] wrote: >=20 > I'm not sure how well this goes with the SIMPLE concepts. However doing P2P will increase the traffic between=20 > the peers since every presence update needs to be sent to every buddy in the buddylist which is heavy on the=20 > mobile devices and networks. Also P2P will not help in having other services utilize presence information.=20 Presence scalability is an issue even with C/S SIP. The real difficulty with NOTIFY is that different watchers may see different presence documents, due to the presentity's policies. Off-line presence brings further complications. Some random thoughts: If a group of watchers receives the same presence document, an application layer multicast may distribute the load between devices. Could draft-ietf-sip-uri-list-message be abused for this purpose? A peer receiving a NOTIFY with a recipient-list forwards it to some contacts mentioned there (removing those contacts from the recipient-list before sending). Possible, but I don't want to write the Security Considerations section.. Offline presence can be done by storing a user's presence document like a file in P2P file sharing networks. To meet the presentity's policy, we would need some elaborate encryption scheme, so that watchers can only those parts they are allowed to see. Multiple versions of the presence document might be necessary, one for every watcher/presentity pair. Wolfgang _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 02 11:58:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5OI9-0002H1-4u; Mon, 02 Jul 2007 11:58:21 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I5OI6-0002Ga-Vs for simple-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 11:58:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5OI6-0002GS-MI for simple@ietf.org; Mon, 02 Jul 2007 11:58:18 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5OI2-0002dQ-7N for simple@ietf.org; Mon, 02 Jul 2007 11:58:18 -0400 Received: from [172.17.1.65] ([172.17.1.65]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l62Fw22w083361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Jul 2007 10:58:02 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: References: <000601c7ba2d$2cdffd40$3e6c460a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=GB2312; delsp=yes; format=flowed Message-Id: <9F4D107B-4CDA-4220-A081-0E71864E2976@estacado.net> Content-Transfer-Encoding: quoted-printable From: Robert Sparks Subject: Re: [Simple] I-D (Updated): Clarification for 'off-line' Status Assigned by Presence Application Date: Mon, 2 Jul 2007 10:58:00 -0500 To: wanghao 67525 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: RjS@estacado.net, krisztian.kiss@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I'm working on putting the agenda together. As always, we'll put most emphasis on spending our meeting time =20 working out open issues in the work the group has already taken on. I only see one message to the list in response to this draft (from =20 Paul) with questions that appear to be unanswered. At the moment, I think this draft will best =20 be served by list discussion rather than face time. If folks here disagree, let me know. RjS On Jul 2, 2007, at 4:18 AM, wanghao 67525 wrote: > Dear Chairmen > > I had submited a draft about 'offline'status in SIMPLE presence as =20 > below. > Can we get a time slice to presentation it on the face2face meeting =20= > in Chicago? I belive it summarized the leak in current =20 > specification and had been discussed in mail list couple months ago. > > Hope get your responding soon and thanks for coodination. > > Best regards > Howard > > > **********************************************************************=20= > ******************** > This email and its attachments contain confidential information =20 > from HUAWEI, which is intended only for the person or entity whose =20 > address is listed above. Any use of the information contained =20 > herein in any way (including, but not limited to, total or partial =20 > disclosure, reproduction, or dissemination) by persons other than =20 > the intended recipient(s) is prohibited. If you receive this e-mail =20= > in error, please notify the sender by phone or em > ail immediately and delete it! > =20 > **********************************************************************=20= > ******************* > > ----- =D4=AD=D3=CA=BC=FE ----- > =B7=A2=BC=FE=C8=CB: howard wang > =C8=D5=C6=DA: =D0=C7=C6=DA=CE=E5, =C1=F9=D4=C2 29=C8=D5, 2007 =CF=C2=CE=E7= 5:09 > =D6=F7=CC=E2: [Simple] I-D (Updated): Clarification for 'off-line' = Status =20 > Assigned by Presence Application > >> Hello, >> >> I have submitted a new draft to summarize previous discussion on >> Clarification for 'off-line' Status Assigned by Presence >> Application. Hope state completely about the leak in >> specifications of SIMPLE presence. >> >> Till it appears on the list, >> http://sdsunqian.googlepages.com/draft-howard-SIMPLE-offline- >> status-0.txt >> >> Comments are welcome. >> >> >> Best regards >> Howard >> Aaron >> >> Abstract: >> 'Offline' status assigned by presence application usually mean >> that the presence application will expect his watcher thinks he is >> not online, though he may actually be online. According current >> specifications of presence service, the watcher may have a way to >> find out some clues to identify the truth. Such leak of >> specifications will make confusion in implementations, especially >> for IOP. >> >> >> >> >> _______________________________________________ >> Simple mailing 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 thepsorvzl@miramarspeedcircuit.com Mon Jul 02 14:54:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5R2A-0006GB-NA for simple-archive@lists.ietf.org; Mon, 02 Jul 2007 14:54:02 -0400 Received: from [89.136.122.246] (helo=[89.136.122.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5R24-00088q-NY for simple-archive@lists.ietf.org; Mon, 02 Jul 2007 14:54:02 -0400 From: "dollars" To: simple-archive@lists.ietf.org Subject: Your loan request approved Date: Mon, 2 Jul 2007 21:54:04 -0300 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0003_01C7BCF3.81979BE0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ace884GXOnj7gTHGRfGIrfS69pwh0A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.1 (+++) X-Scan-Signature: d6b246023072368de71562c0ab503126 ------=_NextPart_000_0003_01C7BCF3.81979BE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thank you for your loan request, which we recieved yesterday, your refinance application has been accepted

Good Credit or Not, We are ready to give you a $214,000 loan, after further review, our lenders have established the lowest monthly payments.

Approval process will take only 1 minute.

Please visit the confirmation link below and fill-out our short 30 second Secure Web-Form.

http://whozifxorgood.com/ ------=_NextPart_000_0003_01C7BCF3.81979BE0-- From simple-bounces@ietf.org Mon Jul 02 15:12:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RKF-0008Qa-W0; Mon, 02 Jul 2007 15:12:43 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I5RKE-0008Pk-42 for simple-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 15:12:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RKD-0008Pc-Qg; Mon, 02 Jul 2007 15:12:41 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5RK5-0002hF-Kg; Mon, 02 Jul 2007 15:12:41 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l62JCQqc022995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Jul 2007 14:12:26 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Ptorealize presence and IM services? Date: Mon, 2 Jul 2007 14:12:25 -0500 To: "David Barrett" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: p2psip@ietf.org, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org David - He's referring to the discussion and analysis taking place in SIMPLE. See http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain- scaling-analysis-00.txt for that background. RjS On Jul 2, 2007, at 2:06 PM, David Barrett wrote: >> -----Original Message----- >> From: Beck01, Wolfgang [mailto:BeckW@t-systems.com] >> >> Presence scalability is an issue even with C/S SIP. > > Am I misunderstanding you, or are you saying client-server > architectures > have difficulty scaling presence-based applications? Hasn't AIM, > MSN, ICQ, > YahooIM, and basically every IM on the planet successfully > demonstrated that > C/S architectures can scale presence-based applications to, well, > the entire > planet? > > -david > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From wvzalloy@howdo-i.com Mon Jul 02 19:12:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5V3r-0008Ol-5i for simple-archive@lists.ietf.org; Mon, 02 Jul 2007 19:12:03 -0400 Received: from static-66-14-166-230.bdsl.verizon.net ([66.14.166.230]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I5V3q-0005P8-Fx for simple-archive@lists.ietf.org; Mon, 02 Jul 2007 19:12:03 -0400 Message-ID: <001701c7bcc3$ccefa310$0018ff8c@benzenecamari> From: "Justin Story" To: "simple-archive" Subject: Fwd: Thanks, we will help you fight out the cash crunch Date: Mon, 2 Jul 2007 16:09:51 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C7BCC3.CCEFA310" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.1081 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.181 X-Spam-Score: 2.8 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c ------=_NextPart_000_0014_01C7BCC3.CCEFA310 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Your credit doesn't matter to us! If your family OWN property and want IMMEDIATE money to spend ANY way = you like, or simply want to LOWER your payments by a third or more, here = is best deal we can offer you NOW (hurry, this deal will expire = TONIGHT): $205,000+ loan AND EVEN MORE: After further review, our lenders have set the lowest = entire payment! Hurry, when our best deal is gone, it is gone. Simply complete this = elementary form... Don't worry about approval, your your credit report will not disqualify = you! http://stelziuxister.com/ ------=_NextPart_000_0014_01C7BCC3.CCEFA310 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Your credit score = doesn't matter to us!
 
If your family OWN = property and want IMMEDIATE pocket money to spend ANY way you like, or = simply wish to LOWER your payments by a third or more, here is our best = deal we can offer you TONIGHT (hurry, this tender will expire THIS = NIGHT):
 
$360,000+ = debt
 
AND EVEN MORE: After = further review, our lenders have established the lowest monthly = payments!
 
Hurry, when best deal = is gone, it is gone. Simply finish this user-friendly form... =
 
Do not worry about = approval, your credit will not disqualify you!
 
------=_NextPart_000_0014_01C7BCC3.CCEFA310-- From simple-bounces@ietf.org Tue Jul 03 07:40:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5gjZ-0006uz-Ft; Tue, 03 Jul 2007 07:39:53 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I5gjR-0006oD-EA for simple-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 07:39:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5gjQ-0006nh-Sv for simple@ietf.org; Tue, 03 Jul 2007 07:39:44 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5gga-0001cM-NL for simple@ietf.org; Tue, 03 Jul 2007 07:36:49 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKL00158PK2PL@szxga02-in.huawei.com> for simple@ietf.org; Tue, 03 Jul 2007 19:36:02 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKL00K2FPK1E2@szxga02-in.huawei.com> for simple@ietf.org; Tue, 03 Jul 2007 19:36:02 +0800 (CST) Received: from w67525a ([10.70.108.130]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKL00MDTPJYFP@szxml03-in.huawei.com> for simple@ietf.org; Tue, 03 Jul 2007 19:36:01 +0800 (CST) Date: Tue, 03 Jul 2007 19:35:58 +0800 From: howard wang Subject: RE: [Simple] I-D (Updated): Clarification for 'off-line' Status Assigned by Presence Application In-reply-to: <46850F9B.8090007@cisco.com> To: 'Paul Kyzivat' Message-id: <006d01c7bd66$536facd0$826c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: Ace6VVcfUUvG2vwCTt+Vl1Y3mWfiZgC7s3Qg X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: 'Robert Sparks' , krisztian.kiss@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello, Paul I am sorry for responding so later and my explain below begin with >>>Howard>>>. Thanks for comments. Best regards Howard -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, June 29, 2007 9:57 PM To: Howard Wang Cc: 'Robert Sparks'; 'Hisham Khartabil'; krisztian.kiss@nokia.com; simple@ietf.org Subject: Re: [Simple] I-D (Updated): Clarification for 'off-line' Status Assigned by Presence Application I'm having a little difficulty understanding this draft. I have a few basic questions that might help: - What is a "Fetcher"? >>>Howard>>> For 'Fetcher' here, I try to describe such a kind of presentity --- those can actively use a mean, e.g. implemented by 'SUBSCRIBE', to get presence information of his watchers, whom had subscribed already. It may be an aspect of function or partial behavior of the presentity. >>>Howard>>> Hope explain helpful. >>>Howard>>> - What is "IOP" >>>Howard>>> It is my fault not giving a definition in terminal. IOP refers to 'Interoperability', like in OMA specification to regulate on interworking between implementations of a technology specification, such as MSN vs. Yahoo messager. >>>Howard>>> - Are you assuming a situation where the "buddies" and the UAs are cooperative, or where they are not? (By this I mean - will a watcher try to infer a buddy is online even when it is clear that the buddy doesn't *want* the watcher to draw that conclusion?) >>>Howard>>> Sure, you catch my point. The goal of this draft is just try to clarify the possibility that a watcher may infer a buddy is online even though the buddy doesn't want thus conclusion. >>>Howard>>> Thanks, Paul howard wang wrote: > Hello, > > I have submitted a new draft to summarize previous discussion on Clarification for 'off-line' Status Assigned by Presence Application. Hope state completely about the leak in specifications of SIMPLE presence. > > Till it appears on the list, > http://sdsunqian.googlepages.com/draft-howard-SIMPLE-offline-status-0. > txt > > Comments are welcome. > > > Best regards > Howard > Aaron > > Abstract: > 'Offline' status assigned by presence application usually mean that the presence application will expect his watcher thinks he is not online, though he may actually be online. According current specifications of presence service, the watcher may have a way to find out some clues to identify the truth. Such leak of specifications will make confusion in implementations, especially for IOP. > > > > > _______________________________________________ > Simple mailing 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 uxb@iq.unesp.br Tue Jul 03 20:21:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5scR-0005Zf-26 for simple-archive@lists.ietf.org; Tue, 03 Jul 2007 20:21:19 -0400 Received: from [213.210.15.146] (helo=146.15.210.213.dsl.dynamic.inweb.net.uk) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5sbN-0002p2-1t for simple-archive@lists.ietf.org; Tue, 03 Jul 2007 20:21:19 -0400 Received: from rsys.bups ([157.210.33.175]) by 146.15.210.213.dsl.dynamic.inweb.net.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 01:20:03 +0100 Message-ID: <000601c7bdd1$10c26ba0$af21d29d@rsys.bups> From: "americangreetings.com" To: Subject: July 4th Fireworks Show Date: Wed, 4 Jul 2007 01:20:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4131.1600 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4131.1600 X-Spam-Score: 4.9 (++++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi. Neighbour has sent you a greeting ecard. See your card as often as you wish during the next 15 days. SEEING YOUR CARD If your email software creates links to Web pages, click on your card's direct www address below while you are connected to the Internet: http://201.250.17.174/?c634591933434671c16a2e59b128 Or copy and paste it into your browser's "Location" box (where Internet addresses go). PRIVACY americangreetings.com honors your privacy. Our home page and Card Pick Up have links to our Privacy Policy. TERMS OF USE By accessing your card you agree we have no liability. If you don't know the person sending the card or don't wish to see the card, please disregard this Announcement. We hope you enjoy your awesome card. Wishing you the best, Postmaster, americangreetings.com From jbcepkugl@npgco.com Wed Jul 04 03:00:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5yqh-0002cD-1k for simple-archive@lists.ietf.org; Wed, 04 Jul 2007 03:00:27 -0400 Received: from cm-24-121-5-152.lakehavasu.az.npgco.com ([24.121.5.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5yqg-0001b7-PE for simple-archive@lists.ietf.org; Wed, 04 Jul 2007 03:00:26 -0400 From: "OPTOUT." To: simple-archive@lists.ietf.org Subject: Loan request approved Date: Tue, 3 Jul 2007 23:59:59 +0700 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0003_01C7BDCE.43490500" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ace9zkNJwNmbypFLROeL60T0J6s9qA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <4E3FE5BD8666C45.74876B632A@npgco.com> X-Spam-Score: 4.1 (++++) X-Scan-Signature: d6b246023072368de71562c0ab503126 ------=_NextPart_000_0003_01C7BDCE.43490500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thank you for your loan request, which we recieved yesterday, your refinance application has been accepted

Good Credit or Not, We are ready to give you a $445,000 loan, after further review, our lenders have established the lowest monthly payments.

Approval process will take only 1 minute.

Please visit the confirmation link below and fill-out our short 30 second Secure Web-Form.

http://katzhelthyok.com/ ------=_NextPart_000_0003_01C7BDCE.43490500-- From cyr@blueriver.net Wed Jul 04 15:41:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6AjX-0003IT-MR for simple-archive@lists.ietf.org; Wed, 04 Jul 2007 15:41:51 -0400 Received: from rrcs-70-62-18-186.central.biz.rr.com ([70.62.18.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6AjR-00051S-CM for simple-archive@lists.ietf.org; Wed, 04 Jul 2007 15:41:51 -0400 Received: from [37.229.134.229] (helo=pky) by rrcs-70-62-18-186.central.biz.rr.com with smtp (Exim 4.62 (FreeBSD)) id 1I6BÜi-0002GK-88; Wed, 4 Jul 2007 15:45:08 -0400 Message-ID: <468BF856.7060803@blueriver.net> Date: Wed, 4 Jul 2007 15:43:18 -0400 From: Shirley Hester User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: And the architect is renowned Frank Lloyd Wright. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 ERMX Continues To Expand As Stock Climbs Up 16.6%! EntreMetrix Inc. (ERMX) $0.21 UP 16.6% ERMX announced further expansion with K-9 Genetics. Healthy and Premium dog foods grossed $3.6 Billion in 2006, up from $1.9 billion in previous years. Read up on ERMX over the holiday, we think you will see even more fireworks on Thursday morning! Their expressions become more and more painful. Bill is not he who is known from Microsoft with the sirname Gates. Removers and a bargeman are loading a barge. It's inspired by a stay at Banff Spring in The Canadian Rockies. Yes, all of the above. Some do not manage to get out before cascades of water catch them and rush them out in the street, dead. World of Art editorial offices are in London and Stockholm. Water, water, water, water and water. The water runs off their faces. Bill was born in New York. As the man came close he stood still. Dear Asbjorn Lonvig, The Staff at ARTROM Gallery has met to view your images. Giancarlo Alu director of Mantena Museum director of Mondial Art and Culture Rome Furthermore "septimus severus", "san francesco" and "piazza san marco" were exhibited. No Danes are participating in the celebration activities. About Aros being a wonderful place. We are impressed with your ability to simplify a concept into an image and concentrate it, to include only what is necessary. Editor and Publisher Petru Russu. With a screen in the middle of the room. We have also visited your web sites and entered immediately into your world. I have no words to tell you how much I enjoyed your art presentation you sent me. A naked man in the water. As the man came close he stood still. New exhibition in Cambridge, UK www. I call it "Little Guggenheim". Guggenheim Museum New York and Deutsche Guggenheim Berlin. Secretary General Lars Seeberg has resigned as Secretary General after mutual agreement! Bill is not Bill of Rights. Today the city is called Aarhus. The barge is at the lake shore. Editor and Publisher Petru Russu. He received a Video Artist Fellowship from the Rockefeller Foundation. A screen that was not as huge as I was told in TV. Bill is not the most successful police drama on British television. Inspired from Native Art from British Columbia's Westcoast - well aware that the symbolism doesn't belong to me - it's the heritage of the local people. A woman is offered a blanket. We have also visited your web sites and entered immediately into your world. A naked man in the water. See the Swineherd, two of his pigs. I asked him if I might paint him. Or, is it the princess? Inspired from Native Art from British Columbia's Westcoast - well aware that the symbolism doesn't belong to me - it's the heritage of the local people. Dear Asbjorn Lonvig, The Staff at ARTROM Gallery has met to view your images. I too had seen an interview with a curator from Arosin TV, she was fascinated by the technical aspectsof Bill's exhibition: Huge screens, high stereo sounds etc. - Crossing I entered the room. com The online gallery Rendiva. Or, is it the princess? The five winged building contains gallery, studio and private dwelling, including office and library. Guggenheim Museum New York and Deutsche Guggenheim Berlin. Dear Asbjorn Lonvig, The Staff at ARTROM Gallery has met to view your images. Yes, all of the above. I remembered the British Columbia Westcoast from my visit there. From simple-bounces@ietf.org Wed Jul 04 20:52:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6FZt-00067W-J8; Wed, 04 Jul 2007 20:52:13 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I6FZp-00065m-TB for simple-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 20:52:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6FZp-00065d-JP; Wed, 04 Jul 2007 20:52:09 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6FZk-00009P-QK; Wed, 04 Jul 2007 20:52:09 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKO00BVYL197U@szxga01-in.huawei.com>; Thu, 05 Jul 2007 08:51:10 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKO0062OL19YQ@szxga01-in.huawei.com>; Thu, 05 Jul 2007 08:51:09 +0800 (CST) Received: from s64081 ([10.164.5.72]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKO005GTL15NE@szxml03-in.huawei.com>; Thu, 05 Jul 2007 08:51:09 +0800 (CST) Date: Thu, 05 Jul 2007 08:51:04 +0800 From: Song Yongchao Subject: RE: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2P torealize presence and IM services? In-reply-to: <1E4CCB2441C5C0409AD8A929482A09F31BB7C0@S4DE9JSAAIG.ost.t-com.de> To: "'Beck01, Wolfgang'" Message-id: <000301c7be9e$91280de0$4805a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Ace6GZIu3gmGf2+MQsukwUUTYgUwQAAA5nswAAMa6lAAAzzO4ACX3EKwAICsVOA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: p2psip@ietf.org, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I agree with that. The draft = http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain- scaling-analysis-00.txt has shown the complexity and the load that the presence server has to handle in order to provide its service. Self-organization infrastructure may help with the scalability of C/S presence by utilizing the processing resource of the end users. Using an application layer multicast and uri list message should be a = good choice.=20 Sure, there are many questions to be considered, including offline = messages, churn of the p2p network, the presentity's policies, the durability and availability of the presence information in P2P network and security considerations. Best Regards! Song Yongchao -----Original Message----- From: Beck01, Wolfgang [mailto:BeckW@t-systems.com]=20 Sent: 2007=C4=EA7=D4=C22=C8=D5 19:25 To: vikas.tandon@orgltd.com; melodysong@huawei.com; simple@ietf.org Cc: p2psip@ietf.org Subject: AW: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into = P2P torealize presence and IM services? Presence scalability is an issue even with C/S SIP. The real difficulty with NOTIFY is that different watchers may see different presence documents, due to the presentity's policies. Off-line presence brings further complications. Some random thoughts: If a group of watchers receives the same presence document, an application layer multicast may distribute the load between devices. Could draft-ietf-sip-uri-list-message be abused for this purpose? A peer receiving a NOTIFY with a recipient-list forwards it to some contacts mentioned there (removing those contacts from the recipient-list before sending). Possible, but I don't want to write the Security Considerations section.. Offline presence can be done by storing a user's presence document like a file in P2P file sharing networks. To meet the presentity's policy, we would need some elaborate encryption scheme, so that watchers can only those parts they are allowed to see. Multiple versions of the presence document might be necessary, one for every watcher/presentity pair. Wolfgang _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From ubilge@magic-gold.com Thu Jul 05 08:31:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6QUb-00041y-QV for simple-archive@lists.ietf.org; Thu, 05 Jul 2007 08:31:29 -0400 Received: from [61.42.42.87] (helo=magic-gold.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6QUW-0001fY-Vq for simple-archive@lists.ietf.org; Thu, 05 Jul 2007 08:31:29 -0400 Message-ID: <001301c7bf4b$df6b6bc0$060ac59c@yourdd97ncaz85> From: "Luther Decker" To: "simple-archive" Subject: Next Big market SuperWinner Date: Thu, 5 Jul 2007 21:31:39 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2720.2869 X-Spam-Score: 2.0 (++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad MRMT IS THE TRUE SUPERNOVA MONSTER MOTORS INC - Hires Award-Winning Design Studio for National Branding Television Commercial Ticker: MRMT Trade: July 05 Thursday, 2007 MRMT Price: $0.6 Monday July 2, 9:00 am ET - News Release CHICAGO, IL--(MARKET WIRE)--Jul 2, 2007 Monster Motors, Inc. (Other OTC:MRMT.PK - News) announces a major contract with top Commercial graphic producer Keech Studio for the production of a National advertising spot for Monster Motors, Inc. The Monster Motors commercial ad spot is designed for showing in Major cable television Markets nationwide represented by Viamedia including those markets serviced by Verizon FiOS, RCN, Knology, WOW, Surewest, New Wave, Everest, Grande, Blue Ridge, Service Electric, CATV and Atlantic Broadband. WATCH MRMT SHOOT THROUGH THE SKY THURSDAY! From cpalps@illusive-web.com Thu Jul 05 11:18:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6T6D-0003Rg-QC for simple-archive@lists.ietf.org; Thu, 05 Jul 2007 11:18:29 -0400 Received: from host101-56-dynamic.3-87-r.retail.telecomitalia.it ([87.3.56.101] helo=illusive-web.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I6T6D-00021U-2a for simple-archive@lists.ietf.org; Thu, 05 Jul 2007 11:18:29 -0400 Message-ID: <001901c7bf27$f76ffd90$00e19424@z> From: "Truman Winn" To: "simple-archive" Subject: Traders Daily HOT Report Date: Thu, 5 Jul 2007 17:13:11 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C7BF27.F76FFD90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2963 X-Spam-Score: 0.4 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 ------=_NextPart_000_0016_01C7BF27.F76FFD90 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable MRMT IS THE TRUE SUPERNOVA MONSTER MOTORS INC - Hires Award-Winning Design Studio for National = Branding Television Commercial Ticker: MRMT Trade: July 05 Thursday, 2007 MRMT Price: $0.6 Monday July 2, 9:00 am ET - News Release CHICAGO, IL--(MARKET WIRE)--Jul 2, 2007 Monster Motors, Inc. (Other OTC:MRMT.PK - News) announces a major = contract with top Commercial graphic producer Keech Studio for the = production of a National advertising spot for Monster Motors, Inc. The = Monster Motors commercial ad spot is designed for showing in Major cable = television Markets nationwide represented by Viamedia including those = markets serviced by Verizon FiOS, RCN, Knology, WOW, Surewest, New Wave, = Everest, Grande, Blue Ridge, Service Electric, CATV and Atlantic = Broadband. WATCH MRMT SHOOT THROUGH THE SKY THURSDAY! ------=_NextPart_000_0016_01C7BF27.F76FFD90 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
MRMT IS THE TRUE = SUPERNOVA
MONSTER MOTORS INC - = Hires Award-Winning Design Studio for National Branding Television = Commercial
Ticker: MRMT =
Trade: July 05 = Thursday, 2007
MRMT Price: $0.6 =
Monday July 2, 9:00 am ET = - News Release
CHICAGO, IL--(MARKET = WIRE)--Jul 2, 2007
Monster Motors, Inc. = (Other OTC:MRMT.PK - News) announces a major contract with top = Commercial graphic producer Keech Studio for the production of a = National advertising spot for Monster Motors, Inc. The Monster Motors = commercial ad spot is designed for showing in Major cable television = Markets nationwide represented by Viamedia including those markets = serviced by Verizon FiOS, RCN, Knology, WOW, Surewest, New Wave, = Everest, Grande, Blue Ridge, Service Electric, CATV and Atlantic = Broadband.
WATCH MRMT SHOOT = THROUGH THE SKY THURSDAY!
------=_NextPart_000_0016_01C7BF27.F76FFD90-- From simple-bounces@ietf.org Thu Jul 05 13:58:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Vap-00036N-En; Thu, 05 Jul 2007 13:58:15 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I6Van-00035k-KD for simple-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 13:58:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Van-00035c-AR for simple@ietf.org; Thu, 05 Jul 2007 13:58:13 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6VZy-0003AK-HY for simple@ietf.org; Thu, 05 Jul 2007 13:58:13 -0400 Received: from [172.17.1.65] ([172.17.1.65]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l65HvL0f022797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 5 Jul 2007 12:57:22 -0500 (CDT) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: simple@ietf.org From: Robert Sparks Date: Thu, 5 Jul 2007 12:57:21 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Simple] agenda for SIMPLE69 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org This is a rough first draft of an agenda for the SIMPLE meeting at IETF69. We have an hour : 5m agenda bashing/status report/administrivia 10m scaling analysis 20m IM chat 10m SIMPLE made Simple 10m Future direction Comments? RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 05 19:06:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6aOv-0005on-7B; Thu, 05 Jul 2007 19:06:17 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I6aOt-0005oR-Bz for simple-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 19:06:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6aOt-0005oJ-20; Thu, 05 Jul 2007 19:06:15 -0400 Received: from mail1.exchange.microsoft.com ([131.107.1.17] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6aOp-0003Wa-Li; Thu, 05 Jul 2007 19:06:15 -0400 Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.54.216) by DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 5 Jul 2007 16:06:10 -0700 Received: from DF-MASTIFF-MSG.exchange.corp.microsoft.com ([157.54.61.166]) by df-bhd-01.exchange.corp.microsoft.com ([157.54.54.216]) with mapi; Thu, 5 Jul 2007 16:06:10 -0700 From: Sean Olson To: Henry Sinnreich , Song Yongchao , "Beck01, Wolfgang" Date: Thu, 5 Jul 2007 16:06:07 -0700 Subject: RE: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Ptorealize presence and IM services? Thread-Topic: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Ptorealize presence and IM services? Thread-Index: Ace6GZIu3gmGf2+MQsukwUUTYgUwQAAA5nswAAMa6lAAAzzO4ACX3EKwAICsVOAALtpjsAABON1A Message-ID: <4C1596FBF66C67478BCFE7B3F81FC1E01D44197E02@DF-MASTIFF-MSG.exchange.corp.microsoft.com> References: <1E4CCB2441C5C0409AD8A929482A09F31BB7C0@S4DE9JSAAIG.ost.t-com.de> <000301c7be9e$91280de0$4805a40a@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D22A6D254@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22A6D254@namail5.corp.adobe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: "p2psip@ietf.org" , "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I would be very interested to see this as well since it is not at all clear= that a P2P model would change the scaling issues in a significant way. -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Thursday, July 05, 2007 3:40 PM To: Song Yongchao; Beck01, Wolfgang Cc: vikas.tandon@orgltd.com; p2psip@ietf.org; simple@ietf.org Subject: RE: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Pt= orealize presence and IM services? Can anyone share a comparison for presence using P2P vs. using SIMPLE clien= t-server? At first glance it looks obvious that P2P SIMPLE is the answer, but an anal= ysis would be of great help. Thanks, Henry -----Original Message----- From: Song Yongchao [mailto:melodysong@huawei.com] Sent: Wednesday, July 04, 2007 7:51 PM To: 'Beck01, Wolfgang' Cc: vikas.tandon@orgltd.com; p2psip@ietf.org; simple@ietf.org Subject: RE: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Pt= orealize presence and IM services? I agree with that. The draft http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain= - scaling-analysis-00.txt has shown the complexity and the load that the presence server has to handle in order to provide its service. Self-organization infrastructure may help with the scalability of C/S presence by utilizing the processing resource of the end users. Using an application layer multicast and uri list message should be a good choice. Sure, there are many questions to be considered, including offline messages= , churn of the p2p network, the presentity's policies, the durability and availability of the presence information in P2P network and security considerations. Best Regards! Song Yongchao -----Original Message----- From: Beck01, Wolfgang [mailto:BeckW@t-systems.com] Sent: 2007=1B$BG/=1B(B7=1B$B7n=1B(B2=1B$BF|=1B(B 19:25 To: vikas.tandon@orgltd.com; melodysong@huawei.com; simple@ietf.org Cc: p2psip@ietf.org Subject: AW: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2P torealize presence and IM services? Presence scalability is an issue even with C/S SIP. The real difficulty with NOTIFY is that different watchers may see different presence documents, due to the presentity's policies. Off-line presence brings further complications. Some random thoughts: If a group of watchers receives the same presence document, an application layer multicast may distribute the load between devices. Could draft-ietf-sip-uri-list-message be abused for this purpose? A peer receiving a NOTIFY with a recipient-list forwards it to some contacts mentioned there (removing those contacts from the recipient-list before sending). Possible, but I don't want to write the Security Considerations section.. Offline presence can be done by storing a user's presence document like a file in P2P file sharing networks. To meet the presentity's policy, we would need some elaborate encryption scheme, so that watchers can only those parts they are allowed to see. Multiple versions of the presence document might be necessary, one for every watcher/presentity pair. Wolfgang _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 05 19:07:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6aPl-0000sz-D4; Thu, 05 Jul 2007 19:07:09 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I6aPi-0000cZ-Rn for simple-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 19:07:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6aPi-0000WV-A0; Thu, 05 Jul 2007 19:07:06 -0400 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 1I6aPe-0003p1-LI; Thu, 05 Jul 2007 19:07:06 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2007 16:07:02 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHUWjUarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175497200"; d="scan'208"; a="500464268:sNHT38115008" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l65N71aZ017255; Thu, 5 Jul 2007 16:07:01 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l65N71mo013059; Thu, 5 Jul 2007 23:07:01 GMT 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.1830); Thu, 5 Jul 2007 19:07:00 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 19:07:00 -0400 Message-ID: <468D7997.6080200@cisco.com> Date: Thu, 05 Jul 2007 19:07:03 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Ptorealize presence and IM services? References: <1E4CCB2441C5C0409AD8A929482A09F31BB7C0@S4DE9JSAAIG.ost.t-com.de> <000301c7be9e$91280de0$4805a40a@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D22A6D254@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22A6D254@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2007 23:07:00.0398 (UTC) FILETIME=[3154BCE0:01C7BF59] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4981; t=1183676821; x=1184540821; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[P2PSIP]=20RE=3A=20[Simple]=20Do=20we=20need=20to=20i ntroduce=20SIMPLE=20into=09P2Ptorealize=0A=20presence=20and=20IM=20service s? |Sender:=20; bh=fKulI5JE5fRnKJ7qWBgP1eyb2OGrEPNdRM0h9mg9+po=; b=Llxcpmfp9IINkGKR7++em6vPVBOgt3c/r1es31FuVkrbgYL4EEfkOWmO0CIfgma9QJatF59o RMw7S+Nb6v8v5SSaJwlKN1U6fzA22p5j4s+kEPKRZgC8g8xlSevr3NIZ; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: simple@ietf.org, p2psip@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: , Errors-To: simple-bounces@ietf.org There are definitely a lot of questions to be addressed in making SIMPLE work in a p2p system. One the question of RLS services, I would tend to think that they are not needed in a p2p system. The whole premise of RLS services is that the server has access to a much richer set of bandwidth and processing resources. So, let it do the 'fan-out' work of processing the buddy list and managing the dialogs. In a p2p model, the 'server' would be just another client on the ring. SO there is no reason to expect that it is any better suited to perform the task. MOst of the issues, I think, are really around security and authorization. Part of a presence server's role is to perform privacy processing - to limit who can subscribe and to limit what data they can see. In a client/server system, the presence server can perform this role since the client trusts its server to do so. In a p2p system, would you trust some other node in the network to execute your privacy preferences? I think not. So, rather, I think that, while online, a user's own user agent would have to supply the presence for the user. While offline, they would store a presence document that all would have access to, which indicates some limited form of offline access. Thus, a user is their own presence server. That eliminates the need for tools like XCAP and presence authorization policy documents, since know the user and their presence server are colocated. As always, multiple devices are a challenge.... -Jonathan R. Henry Sinnreich wrote: > Can anyone share a comparison for presence using P2P vs. using SIMPLE > client-server? > > At first glance it looks obvious that P2P SIMPLE is the answer, but > an analysis would be of great help. > > Thanks, Henry > > -----Original Message----- From: Song Yongchao > [mailto:melodysong@huawei.com] Sent: Wednesday, July 04, 2007 7:51 PM > To: 'Beck01, Wolfgang' Cc: vikas.tandon@orgltd.com; p2psip@ietf.org; > simple@ietf.org Subject: RE: [P2PSIP] RE: [Simple] Do we need to > introduce SIMPLE into P2Ptorealize presence and IM services? > > I agree with that. The draft > http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain- > scaling-analysis-00.txt has shown the complexity and the load that > the presence server has to handle in order to provide its service. > Self-organization infrastructure may help with the scalability of C/S > presence by utilizing the processing resource of the end users. > Using an application layer multicast and uri list message should be a > good choice. > > Sure, there are many questions to be considered, including offline > messages, churn of the p2p network, the presentity's policies, the > durability and availability of the presence information in P2P > network and security considerations. > > > > Best Regards! Song Yongchao > > -----Original Message----- From: Beck01, Wolfgang > [mailto:BeckW@t-systems.com] Sent: 2007$BG/(B7$B7n(B2$BF|(B 19:25 To: > vikas.tandon@orgltd.com; melodysong@huawei.com; simple@ietf.org Cc: > p2psip@ietf.org Subject: AW: [P2PSIP] RE: [Simple] Do we need to > introduce SIMPLE into P2P torealize presence and IM services? > > Presence scalability is an issue even with C/S SIP. The real > difficulty with NOTIFY is that different watchers may see different > presence documents, due to the presentity's policies. Off-line > presence brings further complications. > > Some random thoughts: > > If a group of watchers receives the same presence document, an > application layer multicast may distribute the load between devices. > Could draft-ietf-sip-uri-list-message be abused for this purpose? A > peer receiving a NOTIFY with a recipient-list forwards it to some > contacts mentioned there (removing those contacts from the > recipient-list before sending). Possible, but I don't want to write > the Security Considerations section.. > > Offline presence can be done by storing a user's presence document > like a file in P2P file sharing networks. To meet the presentity's > policy, we would need some elaborate encryption scheme, so that > watchers can only those parts they are allowed to see. Multiple > versions of the presence document might be necessary, one for every > watcher/presentity pair. > > > Wolfgang > > > > > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow 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 Thu Jul 05 19:09:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6aRa-0006Dd-N6; Thu, 05 Jul 2007 19:09:02 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I6aRZ-00068T-ET for simple-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 19:09:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6aRZ-00067S-3y for simple@ietf.org; Thu, 05 Jul 2007 19:09:01 -0400 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 1I6aRV-0005CE-O2 for simple@ietf.org; Thu, 05 Jul 2007 19:09:01 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2007 16:08:57 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHUWjUarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175497200"; d="scan'208"; a="500465090:sNHT27622226" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l65N8vuB015638; Thu, 5 Jul 2007 16:08:57 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l65N8umo016082; Thu, 5 Jul 2007 23:08:56 GMT 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.1830); Thu, 5 Jul 2007 19:08:56 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 19:08:55 -0400 Message-ID: <468D7A0B.2030109@cisco.com> Date: Thu, 05 Jul 2007 19:08:59 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ajay.kasam@wipro.com Subject: Re: [Simple] winfo template package References: <8E5C3E5BA0F2BB42B968827E1246EFC27199BF@BLR-EC-MBX08.wipro.com> In-Reply-To: <8E5C3E5BA0F2BB42B968827E1246EFC27199BF@BLR-EC-MBX08.wipro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2007 23:08:55.0869 (UTC) FILETIME=[762836D0:01C7BF59] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=939; t=1183676937; x=1184540937; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Simple]=20winfo=20template=20package |Sender:=20; bh=fbOhQfcJ+kHXntLHJE4xBbHrRZzGX8H4eMLWOvrNckg=; b=DUXEMGprj94rGflks2yr38skuf2u9ZUpkGsZpSyW4uy7ofm7DbzvY1cvYsf24FQKYBGKZD7g AQNA5isSYvwTVRcadjoXJbONNxAw8BBoTXPA7TORmkzi/oJi8upyOnX1Wsa63i5b3SPIjMuA5u TgyYZgNejLm1DUi0FZojAYirM=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: simple-bounces@ietf.org Actually winfo is defined for all packages; thats why its a template package. Whether its USEFUL for any other ones - well so far presence is the only one people seem to care about. -Jonathan R. ajay.kasam@wipro.com wrote: > Hi All, > > is there any other event package other than 'presence' which uses the > "winfo template package"?? > > Regards > Ajay Kasam > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow 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 Thu Jul 05 20:16:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6bUN-0006hG-J5; Thu, 05 Jul 2007 20:15:59 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I6bUG-0006ZB-SV for simple-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 20:15:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6bUG-0006Yt-F7; Thu, 05 Jul 2007 20:15:52 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6bUG-0007II-84; Thu, 05 Jul 2007 20:15:52 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 1E0242AC9F; Fri, 6 Jul 2007 00:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I6bTR-0008Qg-Re; Thu, 05 Jul 2007 20:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 05 Jul 2007 20:15:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-interdomain-scaling-analysis-01.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: , 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 : Presence Interdomain Scaling Analysis for SIP/SIMPLE Author(s) : A. Houri, et al. Filename : draft-ietf-simple-interdomain-scaling-analysis-01.txt Pages : 49 Date : 2007-7-5 The document analyses the traffic that is generated due to presence subscriptions between domains. It is shown that the amount of traffic can be extremely big. In addition to the very large traffic the document also analyses the affects of a large presence system on the memory footprint and the CPU load. Current approved and in work optimizations to the SIMPLE protocol are analysed with the possible impact on the load. Separate documents contain the requirements for optimizations and suggestions for new optimizations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-01.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-interdomain-scaling-analysis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-5194113.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-interdomain-scaling-analysis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-5194113.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From dcb@engineer.com Thu Jul 05 20:37:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6bpZ-0000fn-3k for simple-archive@lists.ietf.org; Thu, 05 Jul 2007 20:37:53 -0400 Received: from mail2.palumbolawyers.com ([66.251.101.34]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6bpV-0003CZ-Hk for simple-archive@lists.ietf.org; Thu, 05 Jul 2007 20:37:53 -0400 Received: from [155.82.49.125] (helo=rpvaa) by mail2.palumbolawyers.com with smtp (Exim 4.66 (FreeBSD)) id 1I7kD-0005Jt-PK; Thu, 5 Jul 2007 17:32:21 -0700 Message-ID: <468D8D40.1050100@engineer.com> Date: Thu, 5 Jul 2007 17:30:56 -0700 From: feet User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: mailbody.ETEQTOSW.pdf attached Content-Type: multipart/mixed; boundary="------------040204000607000004050307" X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 --------------040204000607000004050307 Content-Type: text/plain; charset=windows-1250; format=flowed Content-Transfer-Encoding: 7bit --------------040204000607000004050307 Content-Type: application/pdf; name="mailbody.ETEQTOSW.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="mailbody.ETEQTOSW.pdf" JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cK L1BhZ2VzIDMgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbIDQg MCBSIF0KL0NvdW50IDEKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzIDw8Ci9Gb250IDw8IC9GMCA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0w IDkgMCBSID4+Ci9Qcm9jU2V0IDcgMCBSID4+Ci9NZWRpYUJveCBbMCAwIDU5NSAxNzhdCi9Dcm9w Qm94IFswIDAgNTk1IDE3OF0KL0NvbnRlbnRzIDUgMCBSCi9UaHVtYiAxMiAwIFIKPj4KZW5kb2Jq CjUgMCBvYmoKPDwKL0xlbmd0aCA2IDAgUgo+PgpzdHJlYW0KcQo1OTUgMCAwIDE3OCAwIDAgY20K L0ltMCBEbwpRCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozMQplbmRvYmoKNyAwIG9iagpbIC9Q REYgL1RleHQgL0ltYWdlSSBdCmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovTmFtZSAvRjAKL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIC9NYWNSb21h bkVuY29kaW5nCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovTmFtZSAvSW0wCi9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDU5NQovSGVpZ2h0 IDE3OAovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEwIDAg Ugo+PgpzdHJlYW0KgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUrlktl0vmExmUzmk1m03nE5nU7nk9n0/oFBoVDolFo1HpFJpVLplNp1PqFRqVTqlVq1XrFZr VTCI8Hj7C6nnY8gpSpAOgpchthrdtt1vnb7RlgU6nY8UCMlucDY9mn5LKj3VD7sgABzVgZcsQAKl lgl1uGRyWTlbdx0TC96ZRLABcKWZkTKuT7tEPbqMzaxzwASo5CeivYOC9mLhcvOMy8C1WU3m930b S2XHIAdlefcESu1TjpgZQg+AvucjFk6AA6XE42ljC34tfB3ahiWHjV6FmxcD49oKXJACcgRU24AC /xxl33/3/H5hSWTgXSq7L8wTCB4ZTSrCxQqHSxoAOcgTjvk/7ouGVAAK9AqBlPBDmIQ9wAMW6TBw sw75ILBaHwogjEIc4KDOGghlABFTFxMC7nCW0EMPs/Udx434eLqU4hCk6RbwegUDIKaCBBkgQIxY ushCWWLhwG0jZPk2oIioKklIO87dQcgrMxwgUuhkz8nIVIyBNmzrbRMgzCoKHMiuzEiCThM8yIFI Uez9P7Izg6yBRQgz6ABLshikW6Bv/KLAgAfYHoIswIwRMqES+3FIsdQ8lChRRbktQSCTWAE0QRLa ECoU9HQCwYHwIgS/IHOFFINPtAV1XarLU5CBRhLyCwfIYLstMCCAnTiDi4Tkti8hLroFF1TPNXwA C849QRu09roNapqy/aFmSkzzQWUgbv1PErmrNYyyz3Xl5XmpJPvKJbF1NWtmwUaBMzYgTxPe6JTn vRk5TwgV+3+56CnugTsmrM6BWaxkzAu+bxE+hOEVO8FEIRjaDUZFN14TBkmYDhEh3pluXKKIUIvW 9CElPBIqSM64qCEgS+tbh8KoPVmbrAhBK4cgZOFubIpQa98FIHWk+Y5MVD31qaDULWc71qgWnPfS mj5fseyKtMmxIPjsMS2aB2I7OGMSdH+0TiCJb6az5YoLtyD1dfEqILr6DcFTWy8Nw/EIfRdR8Kgp blRprM0FeKBb9SHE8xzPNc3znO89z/QdD0XR9J0vTdP1HU9V1fWdb13X9h2PZdn2na9t2/cdz3Xd 953vfd/4Hg+F4fieL43j+R5PleX5nm+d5/oej6Xp+p6vrev7Hs+17fue773v/B6WrpztXw/MlS6Q BaSN/X8vBof8aFtGsK7JKwkjmqKUMsV8/+pGalczdFmETNaQMvZDHBJqImaeADUiQpGNk/pLJjAq H9VAQJY7UTWLDMe/6DxAkVEPW8Y0KAMmMEDPIFQvqHk6IVK+1E5LFUmwlbjCA+rLCBHFUoQRDpCn 1kih0kdoR8IaGZYEz080HFGreg++FeLD0BrBPkhlmxzILLFOOf1mQS0Jv3WCZ+KiCU2LbAug8/z6 lqMrNAzYhkAiERgf4RRNcIWTkDiMf1D0KwctAQrFJikTX+pQSG3pOp3kDJZVUOxqRwUgJRSmxCIS pwLyIVsQUyBA0XNBIJJM2xDUvpUOMmwz8iCKMINnJw26XSBl5LIlBQYAEioVX1J2QD4XLAAMGyVD Em0vOWj5JE+aqU4PrjcQNtUcSGJfQErFC8DlSEOUm1GYMbFEI1VCptD56FYqrlq+FvRBY/NcPbDs gz6zXEFNLHRbBBDrlqm+QdUyGVnENW8a8gh6iNCMnIsNvCN4/q/QdAcg0z5uvZVIqZlJAoeiZgSd aFSQ2CskhQkcKi/EuSbbkxuZ7EaKMKoIQRHUsCCmImdJtyjaUjQOIEwxJpwWRS7UiWQ0hB0N0Fe6 gBn8uSCNfaIjVTLPkJm5aG1BYaoyBONB40ppiTY6q4ZlAVrS6z51DmHScg9EqpxVMans4LPCCRdI HUsgtNabPbSiKdOj959nvbaRBU1DSVN+rQss5pumhuTUOQpu6bBY13U+QUskAnAU7RLR+sthyl1v I9SqwjCYBRQcCuyxFk3YqqspZd1tZLMWbs5Z2z1n7QNvtDaNziU6JJHFkFKdVpLWK6MAwZIwRxsh jCkKhdBC6XkDthXm1tvSqNHWUkYbJAxby/bSFSwRrywW8t9c0p1aDuTkFuBO5kxhkKCkyAC6tzru FJQEjg5wF1GQ9IUoKX9p7u3pKScNGCOLUoqlVeVxwygInzCPeq/F3gI3LOaji+JCVBX7Pm3a/OBS jD7aKQOhN2pPRKIFcPA2EShKHE4PsCN0JNuNcnOzCWHcDl1uMV0golUFCxikEIHhcz/YexYUvERB ACpbjxMYr9VsW43xxjnHWO8eY9x9j/IGQchZDyJkXI2R8kZJyVkvJmTcnZPyhlHKWU8qZVytlfLG WctZby5l3L2X8wZhzFmOcRRqQyvehNa7rfCe5sIfjYnDH0lZnh+VXNxfyNyKW2Q69zvn15wJDOEi lt2QEf0EQzQBJlRr2oeYy3ZoLZtJSUFyVU/im6A0ORcaGmSN6JIdFLTyOAxkQtyRHShPomE8gFds hDHTM3ZpEqssGeyKy/fiRVnE1s6yYuUfMjRrjRaesBchKGr9e4EciAAe40DbtFhwQ+4YULxR8q3r QHmxHGw72nf8iWrMyvurdsIgijHI2n1zBfcSp9pXFTFt2upD7BEPZwT6wxN1NasGVCXSzHTOawvQ njfIMp/HBuukEh59NOGPToOwCOrAqcB0sADgqfbocM4a1G6YEduEM4Xw0+Ki7qcbmMQffyDJYXUA AjrfRDDuce3VyDjR7+IXiPFxMv3JVQcZGgfbmfByF75sARlr/NVWECfWXlu/OeUGd4fvq8SFeCkL bxzrmXTiFcd4ugylXTeBJkuwRDhLjuLbeTiYxIPN+W3VGOFzrhPuSpsuKJw+OugLiLU3LswVxKov vIGA8Kgv6Kq5u+beGncWkpk7t3+itR49mD19AhEvgAuJCrnuOO3cQIl3vIADuxCPBskhN5jM9Tbd EFQoyloHKtnkJ8c3YVEJSCG3xmQIRc0YNbK9MACE1ID290875LwXrd/piad7XxS1/G4J8h3347PN 7y4a+h1yfxvgEKcF7LuhCfknz9AnuCv2SBeAQx9s5vobjae8/6cgvmutaW+a/r7frvdbTZ79+C5P U6X0vsrMavIQhFfAoIyBRDOqakpFgCBr7iFmvgeFvEiP9AIgjgHL3uQpVmvhRQGEFIVp3qmPljEi CpHiCQEkYv/C1FDwBuSBbwHwErVOltUjEwMocQUr6wIJ8CCQAEbM4QVQJCCqvQTN+CBL0QawPQTQ CKHkpP8wZwRCEmnQLguQMjdQkPHwFCCQMNGwNsGM5GwCCwLq1iDBZQeLGuriCwRJ1MNqPCBrTP9C BwJuYt3uWQ1DDGTQhwAliwBwnCCQQQEQJQWQ2sGCgB7sBOGmSALrbBOOdi1B7oyFRQztnmisCOpC BqjCDxAm7IHL4uhpKsAiGlaOCESpfxHxCAJxDO1tlGnRFiDrjKJRCudiFBkQYDpRKRBi0xSriEWR JrlxKnBD7LjRJCBxYDHE9xECDxXQjHLriCGIHBkRPL9wORIGAgqRiIVxNRLQtRajciDxdQuxUHHC BqolBNzCCq8tpRVwwiGRcRZQbRaRIuJRPHHGmiCJVLjCeLjMILxActmBjjGrjE5Egk9jMvhiDFig 4NrxUMEPuKxJVxytXAALsxHupEbyBx2Kvh7yDG7R6rJGnA4CEyKLlmlmAFEPMqPxlFviCKlvvPcQ qCElqsFuUiBR9xoFWAhMVq6AASTF2R9uJSYj/I9iCsICFRkiDSOQpRnJNI7SGPYtyRwkmxEyBSFi EvQx7vMxtSgtxyfL0D6ALyNKYGaFKSoNmRyoFLtGll3SbugyRpMR6LGSXSjCeFDjpFTKZCwkfpkO 7oDAHuwpjEMgANDy3QNoWy2KjiCj3D5j5hGS7iHS5ujEtvvkxgIzDJXsLOKjCi2S9CEzCy7y3sLu FtwM6k9m9S4SaEPTLTHTMBYvNm+J4qHMZI7TSDUzQy4hTy5ixM/uENdkHS5DzjrzBkmzDS8TRKjj NzFzBwZzegAQrqJC6Efzfmkn5TNL0NsvYzLjNj2zIpMgHzkzKxqyPy9zjRuTACFzpQDE1odTUjAM ZG4zwwrlSzcCek9mxB9sQE6kmivEMqvSwiIhNiDgLsUMVBKhYsET4mIL6CvGsCBlgz9sUsyiHsSh lM4T4q1GgzoCF0HiFMSAqMTNfT7EwTQCIsUiwT/CNUPDMz1PYz6FfULUML6z+UPiFUBzlHK0GLtU EMVOfiu0XhN0UUDz+UFCF0NTuCRUVoN0AGCkX0bDO0YULsT0RTjUhmDUBUjCGURT30HiyUXT6jWU GDQUV0RiFUoCeUfJ3rTUICIJQiN0bCwG9L6pHkHjSCupvx/AAATN2iWAeDdiRMYvvgI05MKCpTzj b0zzuiJTVk+VACFgHU3QXCplTKvU8PZoXEjU1K0kHVD06iK0xGg1KDVVGCGvNj7qBCcAl0t0JCSV RsljSUTUfCamPztHlgjhGDUN0iOBGU7MqgHVZjaid1Vy6rSUXsyCZVdVfVgnQDVVEiL1inooKm8S 1CF0SHdVliQJiijVSwFVnyfn91ptTNLtstwCe1jiNoiFFNblMiru9p/rIiSVxCI1qlM1cH5KBiF1 vCbVmiHv7iJFaOyVs1zibE3iFwDCDp9Ci14iMvNoMiH1sCktMwXK4COzfHFV7H9t8EW14CfoUjoi BjuqZtECKOtgIoaGAkYjqp6NUyWCUs7jEqLCFqCGOoYjliFWKlaDuUymhLtWPCKoR2OvdmIWKi8C CjgjEQjCFm0LNCPIipWKHIVwgWMNf2YoXlZ2WKyWSCPrVock7HKjlEN2cIaiETNmVzmCEDxWdlpj sWmx0ifIz2LJcIokRkPENCCpiH1CEH8kDkZoruBotEAJ6Evu6V0iLDM24EwoBwtIyE1qkJTIwqiC DW72LEBERJJIwjGW6jQXFPSoojHlrv7FigAD+Wz11z9XBjg3OIuEHXGzAjGKa3BmAW/iI3P3FGWX GECVgPeoyKFWzrdEQlZE2XDl2iS2/W0XbkCkZENXMEbnxvkkLTviE3NkI3bW1QbW9XZib0fFTExp KL4kyJBQjz9JRpaL/pWEvzbSlGok9E0qjpHCFDMk3kTXxknuzwjpC2MwPSuk0IjgAVUpZJeR4Vxw 8NYl0pJXqs3DbpGwYkql1GKFrm2gpXxkKkgOjCJ4E35pWpPqYpDDQJSFZ314IpHEXDs3Ykl4IJLk wX34CiDYEYFEf3sSU3AiCGJoO3zGIYKCE4HwpXsU14OYK30q2iCRbE5p0D5XttvHCpY3+jEj4pFX 13osHGtlPK1lXS1iEYlvLN6sAJysR32xjFDJhFPlQqjD/iCJl3YJVphGvLJX6iEI/YoCDHGqojEI 1q2TvFW32lCI5oOkytdFFqj4miJnBDGpilqmKGbETFtnF4+JlFIpmDD1l5BFROimslJXYWptCxjl WG/CCPbJLGGjkYrIoZDn8wl4tnK5C5HXgFK4squPPYelUJqUKmsqR4yNdWPibFaLgjHFNE1xgjPo Cma4kgADLWBWZ23QPlzCBNCJLFvFtRZ1m2AXLFnAqFxnBFry1DwZaiEJzUfyjEVEOlsiC5ely5cQ D38KFSuCB5emKZvFS4O4xx00SY/UjjGZnFilu1Alhi5jS5Ei0s6pwqTlTZuDVZzCBZlEyIemc5gl kzQ5E54WAQr5Zod5ampDTiEZiDtWDp3mxZ84yP2l3ibqIUnGImJlBKWQ/QtF8UnJuCCKGITGMgAN Sp6DlqLzAGRGCR5PSF/yWKNNWkOCC6avbiDDwKK6Wl/ZqQjUiYCGJQ4pxlEaTm4qXZLzQsFqF2iq XF75a50P5mMgeabOypyYD6aCC6sE4jSaiyn6lars66iWogAaQE0tSkvjvawqFGF3kRvyimtxsaUG 5VWGD626PKLF/aoH3YRIQ4pFamCXAMFKxt36rCcGfmkyxkGqqME3iRJKcPG4pnAosUC2DGiJNh9l RvnHK7KaSyjIHbPCDoeqeCy7Imdo8j1rsqlR3qj7NGaqgJjbXQOEFtZ7L36qnlqVzqqGvbcjWKcG RyfYY7U3SrAbXNpbjkSIsbOzl4UmmblFooy7O1oqkyxzLXP7dbJnHSECBkFFibIytlCa57pO+Gu7 npcKFbGm17wDM7LqPjCKlPSCFmfZxZ0kPbNXP7BCc5AYcj5G5DzqIS/iZjxDFqz1JFV7/B2Lw6rF W4yxJukmpFScHE+cBykG8CQpvkF8GFM8EJIJyK/CaRc1q8K8ILAcSVYiLNpNfDC322DkxbE7MFOA ecUiEcWcA8Z2+COb+CJcFk2cZHVkhjA1yiBhoThEcZB1SnIY9ih2Fj8HHtkiT8m0gIlcojnLqgl8 lMgORC3cnnVoyZ4n0QPsn8uscEb67iVwILZgpAHcesgV8Vfboyh1hc687CqnICn4djevHCpBF891 WFAcVCO3wHOwdibwUiK5lCOguDACiwUiwcdih6H2JCLdFitdBqB6ZNRzwCY7iCZdCiPdOCWdALid JV3iPAqNGPRiFczCUqJc4r5PYiZJn6ZCIc3iZ9M3wiMJz7zzLCVpw3OiU1oiDs6DMtr4uwOv6tZm aNsbPteiJ1uK3tt2UiBz7Njry7cI637CE9Yn/iyt1mHi8tzuOTvC1kKtiKv9oCEx89mb6delKdwm elIs1KY9nCfyACGusSHRmiDuiFNPh11mDuoyfulCLM78viKOlQ+m0uJ7l2JpNlRAeeHSiGKOuDpd /8EO0lZ+DCF1uD6eFxWS9urCBSRlc99yAO2Oe+SiKdWXNeJ5GPrOYFauICF99uXudO1+LlouKjb+ Uu2pYeMvGO0rmedeaiByzpML0OpwKeVOrehLiOxiWvBsFNpu5I7XoAAPgCzP4nHzBCEvqPAiCO92 cv6orvaO/PqwlvzPpeziFvPklpYB7+rox3M5LQ5HB+2PZaMD3+tyjvW9ZI7PaiCduZwD326iBO/F KPnvX+2dqvAoHEySWPNPfPw+xSXc+71Zfyje0/L6xPDfKV6/OvJzRLvvy+rdx3IiFe4Prx8sOFMv yb1PzezZX/B9rFp+4di5gCBhfiDqovC+5/U5wfemHPhciiRwowIP+P/IZwBKPDow8iBQIwvkm8uw T6d5rGoo6O2WOs9wufsQvQ+NJoiNaCEwZP9lTv+uNP/2aQBQfiEfqfb/2w6wi2LfkwlaLj5fr66W XQbfyCAFIlgAADyCQcALGEAAIgAHLIpNUJhFoQuLFx0lRjwKFQcLwgpQsuQyFqKCRmNwhlBELhEj xaDlSFx8eRiNSGYQSIRKKEIuFQIlAoQKCTWUSFYjlbyuWzqIxNoEIAUChQSPzmDw2DrKFz6sTlbw uH0+KACf0GhwOTTClUyXTmR1h0zBlQud1CpTKEVcAXOF0uWQQHV/CYWvvcIvur2GDhOFve0hdbpa TzcllR738AFCDpyv5SsPuYKiEXHOACP6CDziYFIoBdUBNORWf5CrYa+VbSQeR5CBZJLFRkauBznT wdjwTbQfgsijwPEQjGTC9VbJwvWVjdwS4x6CdWYwgIw3XbDZRWv86EeCtbfSgDMzC/USSQwIrfs+ vNSfDa/YoIY6fr2ADmqOqb4oIrT/PO5L4Mi3CEOPADusM+rVwk2jMQe1THv2i6ZoQvyFtFCKFuS8 AAOnETigAxTxumgjZwrGbQxdGAAByx7IjggxkCoU4hAuSocwRFJsgAGSPhy9CcoNAaDxJDypoI06 aRAnL8q0CLfRYwjctQhaZS4C8eAA4b3JyGTxQbIrvoWSr4IXI6cy3HYeOFH8gq/JJbyW786t/NyF yIfcbABLLCTOg8cqyvc+mgCJjzEhcnOrIcWxsbL8qzMY4PC3FHobFErQHRiLTUhDkq039PS8hE+S XSMUMLKKw0RUaCpye9CpaW85osoExu/H0gIPXcXIPWFIVUhdWqnIEhIJEj700hFIRpbDxIIRgHmV LpToOg0ooJcEutQlgI25b1pABcCvlPbwqXkz1Gos9tczBdt23jeasFiTh9giU6lXwC5Th5dzCEYg 6FXHXOHXKmQqXonOAYEpR2XYhd+Ymj97gBc0R4MgwuXgy95MJi2BoOB7FYPdy63sluFrrf+A4HG6 LXMq9027FmLlvjMW5GU+S0E92e3W0OiP0wt6ZwdknIPcGTXlid8otlWMABluiQonOFoRm+CalCuZ 26hLNB5ruX30nOz5inO2aljis7PsWgIIB6RPXq6raSJaOoJgls2yC4hB4RjFThqZ7lufaDJWHmEC 4qRKoyWJlKbxHFABxh9lPhKsE3y4qcFw/EyjQvQvjJytXAIXScwwnVlPxyCh5yWEMNxUhYbSgAd1 oqpL7tPadZFqCbihHS8yj/Ud7xkK+Jwts4+q/azamHm80rXU2ir4I8novqxnESv+zx+y7d2XTLrj +xdY6fhfL+qC874yDsZ3PxfX+z/4APfelABbD/TFEWfUVkHgsXKkxY6BEExX3BLZCFAZuxSX9oJO 5AQfYDnxQTdoBcjqX3XQLgad9vxWGPpOMGYaCrk4Do0S/AQnIJoXg8hitgAq8ymw0h84aDBon1tf IRBGH8R2UojiREuJkTYnNvMvE+KUU0ppeMuPcVDkIqNYik5yHMW4wRhjFGOMkZYzP2fBGeNRhV+m FSGBMZTDo1xzjpHWO0d48R5j1Ht/7KI+R/kBIGQUg5CSFkNIeREiZFSLkZI2ADIYwKzkdJMr8OGD BCPoViIhC34SUk9J+JbYZDSQi3JKOzon7KbjwNVML6GDCnI3KQ3jtJQLtk3LWXDhZRPlYpE95bno zSmjrJ16sqokMdLSThb0DApFXMcQgByX5hPBWxLcg43Y9QzWw+SXM3Xyv+etACaxCJWEIXA0FyZI BKhcC5L0ixBjLkpRwWInJMigpJMKWGGELXPTsE4+dSg1Z4o0ndQGeJrJ0Q4IcFIKU65xkFoERpci KWozgPXPcC8PaIyxnO0IhwDqGGdoAQucpCEc0VXHOsiwUEkktNBQc4qN5+L2pZRk9tMJ50oMKhJw tKpvU/WxQU+EWZ0quf/Q8SwnEhSwcHFhyDuSCTNaKKcKlIzO1LlinGaA1apNGKnUpB5VhKywNZUR 3IDpWMGZLVWU1SqxkpRzWY1daqqFYqTVgnFTnJjKrRV2VBC671vJCkSs0vyF1Ci5POojwa0GoapN M1FgjoWFn5NwjxkR9mgslXGkhWAL2YMpXgJdhKn18rTVMhdPFs2WqBa0wlfylVPg7VEC87F7msmI QifcLbahcAjH6d7oUgE4cIYK2ltrgEWdCQghVMgLzNuQAAaFHj63Ckw4FaTZXn22IIkwhd1iiWxn 2ai6FvphPrpjbIB1vDDXoRwjCmZFrqTmUG8mHBgyr3ctfcO7Dj5oHvJA8Bdt1ykotalNErBOCrkG lRbGaFz7e2/NWqgoq7bhv6vUaWh9rrXV/TaYOZoEa1nVNOFJnJFgH1nq4QzEc04B1aIPbzEVVLk3 fladsgmKyzJuu8ilclY7rl6jkdzGkpkf5AKJFi/5+ZhIoOLFnFNpoNRsIWdCelnpknTyRFd5M1FD 5EshMAheOLlWplblszDeiD0lJhiVN2L8lHYNziQ7OR7+VDH3lGmdXsOZ9Z0RaZ+McvtNM2oEwrir 13PM6YaEGgbjAAzYAALxWFzI5eXNEnBcSZMOmwyCZiQlGZDXcvIL2Q2vpw0cQ7QanyYIUfBL8q7C ZhanABqm+J2DI6dISFyZql8umrlsVOyEIMvMVzMQcRhI9GrbNFggrCVYN6NsNkzAJvEu6oyudyxG frXMhRvKzahBKW25XDfcaoMjWbb0JOezpDgqTtIzj0hC5jM3q3PplNwmaa0uIJvTCqwN4BUGgJkm An6YbsnJqsvswuDGWXdvZVG75/8M4Pj7hOz56kIdu+sKQDjq8CK+rPIZU+ArJpsJYHgnyp0cduuz SKp8p8q4c46OW4U0AA5VfTb5pd1bcp/YJIdehOK+JDNLYCLUOEwfWXw6s2lyEbUvmQ1iP62FfzgU XoaRzX0TSnZ836UegJE3/cqtnI3PVk6idhc/VCM9WrJPPrHRJzVVMJ0AgnUiv2q64Qc0nS2P9mbc 2KetVO2kHCWBezIAHidQsI/papXycIk8XQ3sUcujeGIQ9RwYAMcePXJmHn0ub+M4dwffBQseqcgT Q7srAPPTFD6ZwIdnejiV/ifrG7phLrsriWw40/qK67yIPi9U0ZjX0u9Z5q+xM4QXzjPMaAiXz0fH AjZq+tT/X9z9D9tCvAmrbzvoV8W4qDyr3Y79yKeaHtRjIFiY4K7vlRCk5Hr8f0Im/tOvmJYzegef jM2/RABACtali19AEh+CO1ujqYcwpANAbAdAfAgj4H2BMJcGyDG/tAjAzA1A3A4h+H26I9pA7BFB HBJBLBNBPBRBTBVBXBZBbBdBfBhBjBlBnBpBrBtBvBxBzB1B3B5B7B9B/CBCDCFCHCJCLCNCPCRC TCVCXCZCbCdCfChCjClCnCpCrCtCvCxCzC1C3C5C7C9C/DBDDDFDHDJDLDNDPDRDTDVDXDZDbDdD fDhDjDlDnDpDrDtDvDxDzD1D3D5D7D9D/EBEDEFEHEJELENCeICACmVuZHN0cmVhbQplbmRvYmoK MTAgMCBvYmoKNzk1MAplbmRvYmoKMTEgMCBvYmoKWyAvSW5kZXhlZCAvRGV2aWNlUkdCIDI1NSAx NCAwIFIgXQplbmRvYmoKMTIgMCBvYmoKPDwKL0ZpbHRlciBbIC9MWldEZWNvZGUgXQovV2lkdGgg MTA2Ci9IZWlnaHQgMzIKL0NvbG9yU3BhY2UgMTEgMCBSCi9CaXRzUGVyQ29tcG9uZW50IDgKL0xl bmd0aCAxMyAwIFIKPj4Kc3RyZWFtCoA/4E/oI/H2/H7CIFC4ZDYdD4JEYlD4pFYrEn7E4E/YzEYt H5BIZFI5JJZNJ5RKZVIn9CG6x2a02Q3ni5HS73W8XO6XS8HY9HU53g6HI7Xs7Xm8He8nw+Xu93k8 Wwz266G663k5Xg+30/Hw931XH3CX68G45pq8H1a37a3O2XC02Y2m4vWg1GM3263nC6HE8m62nM9n s+JXh8RicVi8ZjYs/MgyGGz2Itms62q4Wy0m4zWMy2Yt2stVWxVknlq5mc21grlo22o1Hm8Xq324 5W2xGgzFi2G01W0uFEzGevWQ+6a5Ga3GEqWo3Wy2nq9HovVqyWOsmQ1FXy2m5Wczm8z183GqznK9 Hk+cd7fd7/h8ZTEXg8Hq83k97I96+8ngeJ6Hiex3HaqJ2nggx9nUoJ6HeeKELasJ7QAeJ2Qm/xxm ucxznEcqOH6cprqIbh2Hw/J9HyfZtGwcx1HJCx5RQfB9nmeh8Hsep7Huep9I4fz5SBIMhSHIkiyN I8kSTJUlyZJsnSfKEiLIfMZolKyHR8f0sysgiFpajKOIcfiwxQfaPI+iJ+HzFCwMgfkuThLsoznO kmHNEhiFwa51G2chyG+dRtG0b5tmidJomObphl2ZhxmYaplGQaxsGucRrGYc5tGscp0G4ch3HKdp znIdcPnUbhwmuaJwHmdVRHCd53ngeUxKadJpnAYRZmoZBiGc4romgbxvGrVhznWdB1nbM862bZz5 L0dBgleZBxmabpuGpRxgGedBwngXBYmaXxXGIchnHQWpYl4bZsm2aZjmmcZxnQcxrG4bxlnAaZpm oyB9nAcB1GaYRpm+YpsGMW5qm42x2vShZ9qecJnm+YZeGYZRfGqZJcGaaxpm6apcmMc5sHKvpv3/ Z+WZaxrZnqddSHlC0yx2e0fK+fJ8ntFMerXHqOIMfU0rCrkII6fzpnweJ3Hmpx9Kiej+LBGcvIJC cTHieTqKfHCvv6euxHyd2aWZl20bSkxomKaJol0apfFEaB6acfEbnGc5xmsYZpHIahybVwXB8IlB zGwcZumccZllyaGHpy+tBGwaxfGib5nnHwvN85zqGIwfqnTWpsUHy/D8xr0XPdX1nW9d1/Ydj2XZ 9pJjIISscuQ/LSEwghCInwecZq7ZiIq5HqFIGiOkn8fcUnxHkfH0fB9Qae8tI0f6I+n5EwIlHB6n fsp5KxCp7Jw/53nurmkyn9a1+d4a1+WhHuS3H6N6QgiMq9M0tEVTGQgg6XGjplSoxIez/iJIoIMi kdI4R5o7gUPp9aNWiPLea7d+5BHSpweYQ4jD+yJEHaQY0b42BwjaGKN4aAuRpDJGANoYQrRojhG8 OIba1x0jVHO0IZ4wxvjOGKMwaxzxqC4POL1bBcx1jeHSN0bY2BpjLGqN0ZI2kPjnHCO0ZIvxuDKG eNEYIsBhDOFgNIYIpxhDgG0OQe46h3D2HoPUX4lxcm8JkLMZJYhpDUGgMEXAzhhigGIL8VA0xgC3 GWMMXI32eD6HYNsdIuRKjFGOLca40BhjWGcLgZIyxijPHON8dA2BiDlGYL0uUXhpDPGuMUYA0Rrj AGwPMn49j1jgGkOVSgzxsKPHQNkc5Cx3jqHoN43wuxfC+HUOUdg0RcrvGINcZIvRqDJFkMVgI5kf DNGIOKMQ1RhCyG+gEfUWjwCyGcvAco4hujknYN2dw1hkDTG8NMdQ1BhjZHKN0dJZIAjSFeM4bq1R 1jqHgeeeA0hpDFF8MsaAtS7jDHAMwYrBhtDqbOSscw3h0Dfb8L4UYuhkC3GLF0Zo5hyk8GwN4eA4 R0kRJwPMco2RwDuHQO8YQoBdi/FSMca7BRuDMGuOccA5hli2qIL0ZiU0ZjiG4OMaY0hpjZGSpUaI 4xkCxGJD+lI3hxuiG8Mk6IyKhi2GQgkaQ2ZMi/GsOGrI6RuDqKIOUdxPXjjtqOMsWozScINHQO4d Y56OqoHKNQbY4BoDkaaPFS40xjDJGSLEUIvJoDKHmO9HA7x6jeM4NRkAxxXjAG820hY6p/DUGWNK QoxRsjIGqOgbY5x5jtHiN4ag4lOjjHkOkeZERyT+HLKQeT6iIsyU621hI1htjGGgMRki/FVjOGyN EXciBRi9G2McbJTh7kGH4NkX4zhoi8j8LcZB2ZYDEGIMwYAzhrXjHKiQdg5SgjfHJRslSOx8jwHd HMdw8R9M9aMO8dpTSnliIMP0bhZ0CDylwiZpyVEyD7HSOuOKPB4jrHgPRArxUrUALGWQdlBx2juH c+w2Y9mhvTjk2NKj0HTDwMKgCCjpR8nqeGv+ATEimtiR2UweuEHbpcHNTAbAyRxE+wEil0TYh6t3 Z2Pd0cFyWkHH3lk2Y+D1GEeE6YeqaSxvsyyPweo7HUD2HYrKOaKXcpWHuPAeeKB3tAziYXKOZx4l JHnn0eg7Bzj1aPLgeirR4jfG0OUwhhR5D1HhbYeI7R2vTxyjrLLSTDlBHkMcXVzBcjPGS3Aao0Rp T3HUMMX41RkDAGrbUe4wxdDTGcMIa4yhajOG1blnabh+DUGuNcZ4xRyjSGONsYIuRqI4HtYQdcrR qDRGIN8z2zxgjTHIMePw0BqjGGONEZovxsDYGkqwdY72/jfGUMkZtgieDlHeMQXVoBZmgFeNcX4t BgDFFiNMW4rBkMKVwMMag2RqDfGELQZwqxIDEFQJ0Xg6BxjwHyPEwxAhoDGHKLwUYvBnDJGwNwYz bhdjZsiMoWwpBojDFkMIaIyhuDYFsMkdg3io8SFWJEYQwxajGGmLkZozRLi7HyjEbeShgiuGWK8V AyBtGTHENAb4xxkqPGgOYcg4R2DSGWN0cM9RzjWHefgfQxDex/GoMwXQzhjCNFoK8UwvBXChFiM4 Ww0R7o1GsMIZY1BaDWGIMAaWWcLDfHLN4a43RgjRRCOehg2RaieGkPAcw6zD6XZQOhkw6BvKeHIN ocA4+C6j0QNAbqHyvj3HSX8dQ4h2QkTSZAndjI4DY9ILo0qEx6jiHBCwYbbtUjfrBlwew2hljjpU OgdI5h3WeNgND1ldhujQHSOUco43oRyeF7sdCfFOIkG6NMcQ2hnjmGh1sbaxUGj2+AODRA5BxDYH SpQctmTCDuHuQsdo6R6jmHAOQpofK1BToabNa2zJL4Aa4bhHYeoZQVQZ794eJKgfgcIaxT5A4e4p YdJPaBjUIbwZQXAYgZoZTmgdgpQcxuodj1Y771Ic4dSmAYIUDbAZAch8QfAYoVwZTI4v4c4docga L/i/BYgcQdYcAdBBId63QdwcQdo6geh4B6gc7dx4IfB8QeYbg6IabcB84dww53hKYex7p25Nzu6X AdYegsh7a7wp49QebSwtYryBI2YejXgsYexp56B97EYhJ55HhG4rppB5ggiA56AfB24pp6BqZo57 ZCR4R8Qd8QoegfSZpBrNBmBAi/ywLRzKgsB4xG68AeYc5razQeRpyOQfTSL/Q2i3pB4g5mApQez/ oc5nZogjJ0R7jJgpIeIskPsQZHDKwfIeofIcAYb74YYcKHAcw6YfJ264oeIe5AQsRHDHLOQeUagd 4c7FJGZu4fTAxAKlQ9QeIpTR4dCzInKYqWwdQcx0UX4fC/QkAbjjwZoVzjqdQY4XIaoXgVAZQVwV 4XgXgUoXgYgUYZhO4cgfrLIb4aAZoa6xBQJlAaodjZ4bqcYaYZIXgYKugd4dj/QVYRgXgWgU4XY8 4cwhYckBwZ4Wwa4ZoXQaQWoVIZoZAWgZIc0JTS4aAZQcYY4WYZRggbwWgWoWwVoUQXgackJ6AfRP wc4Z4WgZrTgYg/we4egeAfAbAZocAVYUAX6aqqgZ7bYVwYoVoRYYQZIWAZIiIbIb4bIZ4ZhxDcYZ 4YIbwYIWYZAZYXYa4Yy9MmAZwXYRwXYqAfAaaXzULlIZYZBu4fYb4aodIV4SoWgYgXgaoX4XJcIV oXIbK1wWoT4ZYWYTAWoVwToZbIZpihAZwWgaQXgVgZwXwXAZAdb/S8C8oZgaAWiaiQIUoTDtI67l 4bgWgRAVxexDgcQc4ZIYKKIwIciG4bw8QU4RoYIXwVoXoawZIb4ZIZQYwaqawYwTkpwdURwsIkZT qdyq5O4cYbgZZS4YsmwYYZyoY3wZqJwcijQggdZFocxvJkwbYuIcCfsYwbiUYbgcDZUQZxT84X4Z ocYbQcQiIqAehSwv8Eiegac6oZbzYbgiJjgbIaAWwY7P4eheZDIuZzAbR6Yfg9QeocBTYcgcAc7M qR5USg5ma/7PgaIXAYyL4bgdFFQiKlZO4aQqs/4dauz1IogvhrYeLDbSIcAdZ24nw/zDhnrMIggd gcYdgZQWYYYdxVxQj9gbAcEQZO7I5gykAb5FBoJ0LKgdQcYdY2ZWghrP7SS3TyQdgcQaYbgeRA68 AdwcYdQfUYBG4e4dj5TEq2wdxWbDBmTNBA4pwfEcId5FocgaocQepAC8AkbLgdzSh87ihqpnpngf J4wsMX50webQTLMdZFwd43AtAdQeIcRvJf4+7ZauzLkKYdAeoc9W8mbAKzTOY9RUhUdQQdJm5lAd a+odgeKnIoLSZNdBYoh8Qb0mYaQdLSUJojIeE7gdIooeRY5L5powAaodYb4awvxk4dYa6+obodRH QegezGgY4XAaxSyxjDgdAdqYsExEIcIcYb4dgqCBLFiBgcwb4eCwdRocAdIeNNLR46kOwsDChiRn hqYchY52okIcSjwbAZYa6gQZIYwWwagaYaIbQaAX9MZ6geododYYoSgYiQAZQdIc4dDSId4YouyU wake4bYVQVYVw6lbQoqF7cIXgawXIUQagYQXSk7voWAUoYwXZctcocAWwWoX4Z4ZQY4dTDAUITQX oZYWQZQaQW4bYYQYQZBHIehFYbwXgWIaAZISqbIUY1YbobrwQZwZRvgW4aDwtMYehFSfCGYagYAX LlIVYXw0Ya4XjnY/zsLRqTlfIZQbYdVFQaobKX4YIb4X4WQXwUgS0yoXQaAeAcbRwd4fDTg5gXo4 oUoX4cAY8hCsyPxDL8AZSaYaQWQYygob4aYawbVigkAdodgeYcZPodIbZbzrgdTC4docwd548Zwe ga6b9bChArB24oMCBnrGQ/4dxD7S7GIeInqu5BpAtawegdDd01odp3pGrCA6gsIfig5ARASv4dIo Jf4bxQAZbjweShBAJHEqA+g+0qKBMZRH0jUV5gzA0ahY6zLQod8ORNZD68AtpMYtbPbOSzixodin Jc4dFEYyAfy/hWJANY1EZqCjqu4cU7jNcBgYoaoZgdEJl3mGMLhK5tBOJ/AlQiNdjKkQmGWHuH2H +IGIOIWIeImIuI2I+JGJIkogIAplbmRzdHJlYW0KZW5kb2JqCjEzIDAgb2JqCjM5ODcKZW5kb2Jq CjE0IDAgb2JqCjw8Ci9MZW5ndGggMTUgMCBSCj4+CnN0cmVhbQr///88Z874urZo55DiTjByoY4l tByderg0IQ6QqKUWmFWU1bxjzncZNl+qGa3ai05psAOFTn0+g59NE0fyKuBHvrUEIoN7PLra5tOI wV7XKg/asF5X7uH3PPU+Lh8edt7UewFX9j0R0SPkWeVDMA9TC8CyY66UWuqJmBmpt5CHiwuI4gLG 9NTq2S7PHV7fcGqfIs1Ntic4QMBS6XfjcQPv+ubxwNrGqrT0etFTWUK9+GWKRhuyf1xy0Ubqtbft pLLTlnOuXB1iUJczpPF2Yenb7C/3nq5TEYCZ+zVR6NoDu3B2ac2UzB4sAMIddiQHURE2SK/lnMBm NbychqR3imDoAcq1lZbUwZaX3wy75l7NHaZ8A0M9aXj5Bv+efYr+ZYvIGyBf7+L1hsICQqhgD8YH jMlKyjPDwznDYbZNYBzYKDf5hyfcfa2egPBG4QAN6YzWM1YJ9xpDunz6CNwW4QVO2o11twsjVYsT nGwUqVWhf4n4iYASzDuPxkRr3CVxKwD+oLcJww2U16kB61JWjdLghVthlyidJu7hkssHA/YIApbA DFrNoTJ3oh7J+auc2TD4Osgg2O8OuYHZwYXQyYhniZTBVzX0ztgSmNG9NKvuLOa2TL6lW3cnNTmt BQI1bIzJLuP+IrHXNEmo8n1T4Ko5l/f4PFJwZIepEYyrRvk4DycbDknM5X4WjnCU4lE+G+g1EyWI g4kPLZuc2OGVEPG8LAAF+eaDD3T0o1ZF4XIuF4ZUnwrerjd5ShBa4CFMnE1MokYzJlanGvn+YNtx j/L445ECwUA6OotLlWts4Qe6LqkBYs9XCupRCEssetoecr2vdX7wr7l7+k7mZzDtIV+XI8FnestS zNSd+E53FsA1xjWztuVtMd+7GEbsBWhLnYsMBAbYVtKs9Mr7a+G7oKjxVF7XwpC2faj9aq5mtUvx wlD4mqfLR5uWQgd3/qgf8Px+x78Ofj23fKdl4l2x1B8CzLqplwJFLURMpUP0xTPxQ/uwUXntCfWU b9fyIKsRI3gKZW5kc3RyZWFtCmVuZG9iagoxNSAwIG9iago3NjgKZW5kb2JqCnhyZWYKMCAxNgow MDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDAwMTAgMDAwMDAgbiAKMDAwMDAwMDE4NSAwMDAwMCBu IAowMDAwMDAwMjM0IDAwMDAwIG4gCjAwMDAwMDAyOTMgMDAwMDAgbiAKMDAwMDAwMDQ5NyAwMDAw MCBuIAowMDAwMDAwNTgwIDAwMDAwIG4gCjAwMDAwMDA1OTggMDAwMDAgbiAKMDAwMDAwMDYzNiAw MDAwMCBuIAowMDAwMDAwNzQ0IDAwMDAwIG4gCjAwMDAwMDg4NzUgMDAwMDAgbiAKMDAwMDAwODg5 NiAwMDAwMCBuIAowMDAwMDA4OTQ3IDAwMDAwIG4gCjAwMDAwMTMwNzMgMDAwMDAgbiAKMDAwMDAx MzA5NCAwMDAwMCBuIAowMDAwMDEzOTE3IDAwMDAwIG4gCnRyYWlsZXIKPDwKL1NpemUgMTYKL0lu Zm8gMSAwIFIKL1Jvb3QgMiAwIFIKPj4Kc3RhcnR4cmVmCjEzOTM3CiUlRU9GCg== --------------040204000607000004050307-- From simple-bounces@ietf.org Thu Jul 05 21:28:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cbz-0001hH-Fv; Thu, 05 Jul 2007 21:27:55 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I6cby-0001do-3A for simple-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 21:27:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cbx-0001dR-Dd; Thu, 05 Jul 2007 21:27:53 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6cbs-0002cy-LP; Thu, 05 Jul 2007 21:27:53 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 05 Jul 2007 18:27:48 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEI3jUarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175497200"; d="scan'208"; a="177355296:sNHT34674201" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l661Rla2013086; Thu, 5 Jul 2007 18:27:47 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l661RlXH002686; Fri, 6 Jul 2007 01:27:47 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 21:27:46 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 21:27:46 -0400 Message-ID: <468D9A93.8050209@cisco.com> Date: Thu, 05 Jul 2007 21:27:47 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLEinto P2Ptorealize presence and IM services? References: <1E4CCB2441C5C0409AD8A929482A09F31BB7C0@S4DE9JSAAIG.ost.t-com.de> <000301c7be9e$91280de0$4805a40a@china.huawei.com><24CCCC428EFEA2469BF046DB3C7A8D22A6D254@namail5.corp.adobe.com> <468D7997.6080200@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D22A6D29D@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22A6D29D@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2007 01:27:46.0288 (UTC) FILETIME=[DB794700:01C7BF6C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8262; t=1183685267; x=1184549267; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[P2PSIP]=20RE=3A=20[Simple]=20Do=20we=20need=20to=20i ntroduce=20SIMPLEinto=09P2Ptorealize=0A=20presence=20and=20IM=20services? |Sender:=20; bh=gNGHJq82TkUBCo2O0TMrCrnodZpAG3jnlgzV17MWDGQ=; b=U0ASpwmZtriWCwWBM5vHZSyNNgds5NekdUmET5wIhz2LjZSW7xblCazkItH64dYiNN9u4XIn 1XauKaxLnBgMFDd2il/jGNCCRxD2RdRiSUeSC0XScm/3nPqdZWjY2Q2H; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: simple@ietf.org, p2psip@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: , Errors-To: simple-bounces@ietf.org The problems become entirely different ones. However, from a purely scale perspective, I'd say a *pure* p2p completely solves it. The simple-problem statement is based on a model whereby a large amount of traffic is focused between a pair of large networks, typically through a small number of servers that serve as the perimeter servers for each network. In a p2p model, there is no such perimeter server. If each user agent is its own presence client and server, the workload is completely distributed through the network. Each node in the p2p network would have to support a volume of subscriptions and notifications exactly equal to the volume associated with its own buddy list. The work per node is not proportional to the size of the network in any way (at least not at this layer; the workload of managing the ring scales as logN over N). In essence, such a network could scale to nearly unbounded sizes without any kind of central point that becomes a bottleneck. The penalty for this is going to be primarily loss of functionality. Offline presence will stink or be non-existent. Presence composition is limited to the information knowable and obtainable by the endpoint itself. Multiple endpoints is going to be really awful to handle and will probably not work very well. Buddy lists and privacy policies, if stored locally, will suffer from problems when you change computers or lose your PC. You want to store them in the network, which is doable but introduces some issues. The access bandwidth required for this is substantially more than any configuration we've considered so far; a constant factor larger than the bandwidth required for a client that doesn't have an RLS, much larger than for one that does. The security of the system becomes as good as the p2p security overall, though privacy is arguably better since there are no intermediaries to trust and you no longer need to signal policy from a UA to a separate presence server, so you can have more flexibility there. However, this is assuming a single global p2p network. If its segmented into several ones that need to connect via gateways, you're right back to simple-problem-statement. Though there may be ways to distribute the gateways if the two federating networks are both p2p. If one is not (i.e., federate a p2p network with a regular client-server one), that is definitely having the simple-problem-statement issue. -Jonathan R. Henry Sinnreich wrote: > So to summarize in a SIMPLE-istic way: Most of the "SIMPLE problem > statement" issues would go away using P2P? > > If yes, do you see any other overload problems popping up? > > (I fail to see them and Skype meets all of my presence needs). > > Henry > > -----Original Message----- From: Jonathan Rosenberg > [mailto:jdrosen@cisco.com] Sent: Thursday, July 05, 2007 6:07 PM To: > Henry Sinnreich Cc: simple@ietf.org; vikas.tandon@orgltd.com; > p2psip@ietf.org; Beck01,Wolfgang Subject: Re: [P2PSIP] RE: [Simple] > Do we need to introduce SIMPLEinto P2Ptorealize presence and IM > services? > > There are definitely a lot of questions to be addressed in making > SIMPLE work in a p2p system. > > One the question of RLS services, I would tend to think that they are > not needed in a p2p system. The whole premise of RLS services is > that the server has access to a much richer set of bandwidth and > processing resources. So, let it do the 'fan-out' work of processing > the buddy list and managing the dialogs. In a p2p model, the 'server' > would be just another client on the ring. SO there is no reason to > expect that it is any better suited to perform the task. > > MOst of the issues, I think, are really around security and > authorization. Part of a presence server's role is to perform privacy > processing - to limit who can subscribe and to limit what data they > can see. In a client/server system, the presence server can perform > this role since the client trusts its server to do so. In a p2p > system, would you trust some other node in the network to execute > your privacy preferences? I think not. > > So, rather, I think that, while online, a user's own user agent would > have to supply the presence for the user. While offline, they would > store a presence document that all would have access to, which > indicates some limited form of offline access. Thus, a user is their > own presence server. That eliminates the need for tools like XCAP and > presence authorization policy documents, since know the user and > their presence server are colocated. > > As always, multiple devices are a challenge.... > > -Jonathan R. > > > Henry Sinnreich wrote: >> Can anyone share a comparison for presence using P2P vs. using >> SIMPLE client-server? >> >> At first glance it looks obvious that P2P SIMPLE is the answer, but >> an analysis would be of great help. >> >> Thanks, Henry >> >> -----Original Message----- From: Song Yongchao >> [mailto:melodysong@huawei.com] Sent: Wednesday, July 04, 2007 7:51 >> PM To: 'Beck01, Wolfgang' Cc: vikas.tandon@orgltd.com; >> p2psip@ietf.org; simple@ietf.org Subject: RE: [P2PSIP] RE: [Simple] >> Do we need to introduce SIMPLE into P2Ptorealize presence and IM >> services? >> >> I agree with that. The draft >> http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain- >> scaling-analysis-00.txt has shown the complexity and the load that >> the presence server has to handle in order to provide its service. >> Self-organization infrastructure may help with the scalability of >> C/S presence by utilizing the processing resource of the end users. >> Using an application layer multicast and uri list message should >> be a good choice. >> >> Sure, there are many questions to be considered, including offline >> messages, churn of the p2p network, the presentity's policies, the >> durability and availability of the presence information in P2P >> network and security considerations. >> >> >> >> Best Regards! Song Yongchao >> >> -----Original Message----- From: Beck01, Wolfgang >> [mailto:BeckW@t-systems.com] Sent: 2007$BG/(B7$B7n(B2$BF|(B 19:25 To: >> vikas.tandon@orgltd.com; melodysong@huawei.com; simple@ietf.org Cc: >> p2psip@ietf.org Subject: AW: [P2PSIP] RE: [Simple] Do we need to >> introduce SIMPLE into P2P torealize presence and IM services? >> >> Presence scalability is an issue even with C/S SIP. The real >> difficulty with NOTIFY is that different watchers may see different >> presence documents, due to the presentity's policies. Off-line >> presence brings further complications. >> >> Some random thoughts: >> >> If a group of watchers receives the same presence document, an >> application layer multicast may distribute the load between >> devices. Could draft-ietf-sip-uri-list-message be abused for this >> purpose? A peer receiving a NOTIFY with a recipient-list forwards >> it to some contacts mentioned there (removing those contacts from >> the recipient-list before sending). Possible, but I don't want to >> write the Security Considerations section.. >> >> Offline presence can be done by storing a user's presence document >> like a file in P2P file sharing networks. To meet the presentity's >> policy, we would need some elaborate encryption scheme, so that >> watchers can only those parts they are allowed to see. Multiple >> versions of the presence document might be necessary, one for every >> watcher/presentity pair. >> >> >> Wolfgang >> >> >> >> >> _______________________________________________ P2PSIP mailing list >> P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip >> >> _______________________________________________ P2PSIP mailing list >> P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow 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 Thu Jul 05 23:25:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6eRw-000512-9v; Thu, 05 Jul 2007 23:25:40 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I6eRv-00050r-LZ for simple-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 23:25:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6eRv-00050f-23; Thu, 05 Jul 2007 23:25:39 -0400 Received: from [125.21.188.69] (helo=mail.orgltd.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6eRu-0003uJ-20; Thu, 05 Jul 2007 23:25:38 -0400 Received: from orgvikas (unknown [203.145.128.5]) by mail.orgltd.com (Postfix) with ESMTP id 8A1CDDEC34; Fri, 6 Jul 2007 08:00:42 +0530 (IST) From: "Vikas Tandon" To: "'Jonathan Rosenberg'" , "'Henry Sinnreich'" Subject: RE: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Ptorealize presence and IM services? Date: Fri, 6 Jul 2007 08:54:49 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 thread-index: Ace/UZ7AQfYYjpdXQUm1M48mOqxEOwAKVXaQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <468D7997.6080200@cisco.com> Message-Id: <20070706023042.8A1CDDEC34@mail.orgltd.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: simple@ietf.org, p2psip@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: , Errors-To: simple-bounces@ietf.org A significant aspect of P2P vs Client/Server(CSP) is the ability to use Presence as a service in the network and other services like presence based call routing. Under this aspect e, a Client Server Model plays a significant role. Some other considerations are: 1. Looking at the memory and processing requirements in P2P mode, the client needs to process more information (e.g. keep track of every buddy's client capabilities, service capability etc.). 2. Another aspect of P2P is the offline messages for which you'd need some kind of server which monitors presence/online status of message inbox. 3. Also in context of wireless devices, it makes more sense to have a CSP model since coverage and connectivity are a practical issue today (e.g. in a 2.5G network, I'm supposed to receive an IM from a buddy but I'm on a voice call and the message is not delivered to me because my GPRS is suspended due to voice call - who will store and retransmit the message to me the moment I'm available again?) I'd think of a combination of P2P and CSP model providing more value as opposed to a single protocol. regards, Vikas -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Friday, July 06, 2007 4:37 AM To: Henry Sinnreich Cc: Song Yongchao; Beck01, Wolfgang; vikas.tandon@orgltd.com; p2psip@ietf.org; simple@ietf.org Subject: Re: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Ptorealize presence and IM services? There are definitely a lot of questions to be addressed in making SIMPLE work in a p2p system. One the question of RLS services, I would tend to think that they are not needed in a p2p system. The whole premise of RLS services is that the server has access to a much richer set of bandwidth and processing resources. So, let it do the 'fan-out' work of processing the buddy list and managing the dialogs. In a p2p model, the 'server' would be just another client on the ring. SO there is no reason to expect that it is any better suited to perform the task. MOst of the issues, I think, are really around security and authorization. Part of a presence server's role is to perform privacy processing - to limit who can subscribe and to limit what data they can see. In a client/server system, the presence server can perform this role since the client trusts its server to do so. In a p2p system, would you trust some other node in the network to execute your privacy preferences? I think not. So, rather, I think that, while online, a user's own user agent would have to supply the presence for the user. While offline, they would store a presence document that all would have access to, which indicates some limited form of offline access. Thus, a user is their own presence server. That eliminates the need for tools like XCAP and presence authorization policy documents, since know the user and their presence server are colocated. As always, multiple devices are a challenge.... -Jonathan R. Henry Sinnreich wrote: > Can anyone share a comparison for presence using P2P vs. using SIMPLE > client-server? > > At first glance it looks obvious that P2P SIMPLE is the answer, but an > analysis would be of great help. > > Thanks, Henry > > -----Original Message----- From: Song Yongchao > [mailto:melodysong@huawei.com] Sent: Wednesday, July 04, 2007 7:51 PM > To: 'Beck01, Wolfgang' Cc: vikas.tandon@orgltd.com; p2psip@ietf.org; > simple@ietf.org Subject: RE: [P2PSIP] RE: [Simple] Do we need to > introduce SIMPLE into P2Ptorealize presence and IM services? > > I agree with that. The draft > http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain- > scaling-analysis-00.txt has shown the complexity and the load that the > presence server has to handle in order to provide its service. > Self-organization infrastructure may help with the scalability of C/S > presence by utilizing the processing resource of the end users. > Using an application layer multicast and uri list message should be a > good choice. > > Sure, there are many questions to be considered, including offline > messages, churn of the p2p network, the presentity's policies, the > durability and availability of the presence information in P2P network > and security considerations. > > > > Best Regards! Song Yongchao > > -----Original Message----- From: Beck01, Wolfgang > [mailto:BeckW@t-systems.com] Sent: 2007$BG/(B7$B7n(B2$BF|(B 19:25 To: > vikas.tandon@orgltd.com; melodysong@huawei.com; simple@ietf.org Cc: > p2psip@ietf.org Subject: AW: [P2PSIP] RE: [Simple] Do we need to > introduce SIMPLE into P2P torealize presence and IM services? > > Presence scalability is an issue even with C/S SIP. The real > difficulty with NOTIFY is that different watchers may see different > presence documents, due to the presentity's policies. Off-line > presence brings further complications. > > Some random thoughts: > > If a group of watchers receives the same presence document, an > application layer multicast may distribute the load between devices. > Could draft-ietf-sip-uri-list-message be abused for this purpose? A > peer receiving a NOTIFY with a recipient-list forwards it to some > contacts mentioned there (removing those contacts from the > recipient-list before sending). Possible, but I don't want to write > the Security Considerations section.. > > Offline presence can be done by storing a user's presence document > like a file in P2P file sharing networks. To meet the presentity's > policy, we would need some elaborate encryption scheme, so that > watchers can only those parts they are allowed to see. Multiple > versions of the presence document might be necessary, one for every > watcher/presentity pair. > > > Wolfgang > > > > > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow 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 Jul 06 01:38:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6gWd-0001nR-G9; Fri, 06 Jul 2007 01:38:39 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I6gWb-0001ih-5n for simple-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 01:38:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6gWa-0001iY-Nz for simple@ietf.org; Fri, 06 Jul 2007 01:38:36 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6gWV-0000UV-TG for simple@ietf.org; Fri, 06 Jul 2007 01:38:36 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id l665cVBY117920 for ; Fri, 6 Jul 2007 05:38:31 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l665cVH42101480 for ; Fri, 6 Jul 2007 07:38:31 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l665cUlO007960 for ; Fri, 6 Jul 2007 07:38:30 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l665cUaO007957 for ; Fri, 6 Jul 2007 07:38:30 +0200 To: simple@ietf.org Subject: Fw: [Simple] I-D ACTION:draft-ietf-simple-interdomain-scaling-analysis-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 From: Avshalom Houri Message-ID: Date: Fri, 6 Jul 2007 08:38:29 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 06/07/2007 08:38:30, Serialize complete at 06/07/2007 08:38:30 X-Spam-Score: 0.1 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============1105725230==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1105725230== Content-Type: multipart/alternative; boundary="=_alternative 001EF26FC2257310_=" This is a multipart message in MIME format. --=_alternative 001EF26FC2257310_= Content-Type: text/plain; charset="US-ASCII" The excel file I have used for the computations is in: http://www.nostrum.com/~rjsparks/SIMPLE_message_computation.xls Thanks to Robert for hosting it. --Avshalom ----- Forwarded by Avshalom Houri/Haifa/IBM on 06/07/2007 08:36 ----- Internet-Drafts@ietf.org 06/07/2007 03:15 To i-d-announce@ietf.org cc simple@ietf.org Subject [Simple] I-D ACTION:draft-ietf-simple-interdomain-scaling-analysis-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Presence Interdomain Scaling Analysis for SIP/SIMPLE Author(s) : A. Houri, et al. Filename : draft-ietf-simple-interdomain-scaling-analysis-01.txt Pages : 49 Date : 2007-7-5 The document analyses the traffic that is generated due to presence subscriptions between domains. It is shown that the amount of traffic can be extremely big. In addition to the very large traffic the document also analyses the affects of a large presence system on the memory footprint and the CPU load. Current approved and in work optimizations to the SIMPLE protocol are analysed with the possible impact on the load. Separate documents contain the requirements for optimizations and suggestions for new optimizations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-01.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-interdomain-scaling-analysis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-01.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --=_alternative 001EF26FC2257310_= Content-Type: text/html; charset="US-ASCII"
The excel file I have used for the computations is in:

http://www.nostrum.com/~rjsparks/SIMPLE_message_computation.xls

Thanks to Robert for hosting it.

--Avshalom
----- Forwarded by Avshalom Houri/Haifa/IBM on 06/07/2007 08:36 -----
Internet-Drafts@ietf.org

06/07/2007 03:15

To
i-d-announce@ietf.org
cc
simple@ietf.org
Subject
[Simple] I-D        ACTION:draft-ietf-simple-interdomain-scaling-analysis-01.txt





A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

                Title                                  : Presence Interdomain Scaling Analysis for SIP/SIMPLE
                Author(s)                 : A. Houri, et al.
                Filename                 : draft-ietf-simple-interdomain-scaling-analysis-01.txt
                Pages                                  : 49
                Date                                  : 2007-7-5
               
The document analyses the traffic that is generated due to presence
  subscriptions between domains.  It is shown that the amount of
  traffic can be extremely big.  In addition to the very large traffic
  the document also analyses the affects of a large presence system on
  the memory footprint and the CPU load.  Current approved and in work
  optimizations to the SIMPLE protocol are analysed with the possible
  impact on the load.  Separate documents contain the requirements for
  optimizations and suggestions for new optimizations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-01.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-interdomain-scaling-analysis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
                mailserv@ietf.org.
In the body type:
                "FILE /internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-01.txt".
               
NOTE:                 The mail server at ietf.org can return the document in
                MIME-encoded form by using the "mpack" utility.  To use this
                feature, insert the command "ENCODING mime" before the "FILE"
                command.  To decode the response(s), you will need "munpack" or
                a MIME-compliant mail reader.  Different MIME-compliant mail readers
                exhibit different behavior, especially when dealing with
                "multipart" MIME messages (i.e. documents which have been split
                up into multiple messages), so check your local documentation on
                how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-01.txt_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
 --=_alternative 001EF26FC2257310_=-- --===============1105725230== 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 --===============1105725230==-- From simple-bounces@ietf.org Fri Jul 06 10:30:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6oor-0000WE-VA; Fri, 06 Jul 2007 10:30:01 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I6ooo-0000Vb-1m for simple-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 10:29:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6oon-0000VP-Mw for simple@ietf.org; Fri, 06 Jul 2007 10:29:57 -0400 Received: from maile.telecomitalia.it ([156.54.233.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6oon-00055V-BV for simple@ietf.org; Fri, 06 Jul 2007 10:29:57 -0400 Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 16:29:31 +0200 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.227]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 16:29:30 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Importance: normal Priority: normal Subject: RE: [Simple] I-D (Updated): Motivation for converting Presencedocuments to RSS Feeds Date: Fri, 6 Jul 2007 16:29:30 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] I-D (Updated): Motivation for converting Presencedocuments to RSS Feeds thread-index: Acenh8fgCAww6TT3TGqNajnyKBioVAYUNO+Q From: "Goix Laurent Walter" To: , "Simple WG" X-OriginalArrivalTime: 06 Jul 2007 14:29:30.0913 (UTC) FILETIME=[10CF1110:01C7BFDA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Henry Sinnreich , Licciardi Carlo Alberto X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Arjun, Very nice idea indeed! We are heavily interested in interactions between the Telco world and = the Web2.0 world, focusing on user-generated content/mashups/services, = open APIs, etc. I fully agree with your vision of exporting Presence info towards a feed = representation (RSS/Atom) to improve integration between both worlds.=20 On the architectural side, yours is one option. I could imagine also a = watcher (or the presence server itself) acting as gateway to export = Presence info as RSS, thus easily supporting privacy concerns by still = relying on the mechanisms provided by SIMPLE.=20 On the use case side, i believe they are quite fine, although they could = be simplified. Probably reference to the back-end providers is not = needed as a motivation: having track-it example simply exporting my = buddies' presence info to a "plain" RSS reader would be enough. Regards Walter -----Original Message----- From: Arjun Roychowdhury [mailto:arjun.lists@hsc.com]=20 Sent: marted=EC 5 giugno 2007 17.39 To: Simple WG Cc: arjun.lists@hsc.com; Henry Sinnreich Subject: [Simple] I-D (Updated): Motivation for converting = Presencedocuments to RSS Feeds Hi, I have submitted a new draft discussing the motivation of converting = Presence documents to RSS feeds. Till it appears on the list, http://arjunrc.googlepages.com/draft-roy-simple-presencerss-00.txt As a working example of the benefits, I've published a mappable presence = feed example using GoogleMashupEditor at = http://rsspresence.googlemashups.com/ using concepts proposed in this = draft. Comments are welcome. Abstract: RSS Feeds have always played an important role in providing users = content related updates typically of Websites without having to visit those websites manually. Typical examples of RSS usage include users 'subscribing' to the RSS feed of a website, say, CNN.com and thereby automatically receiving 'news headlines' then the content changes. Recently, there have been significant innovations (such as Yahoo Pipes and Google Mash-up Editor) where RSS feeds from different sources have been combined to produce new services in a 'Web Based Service Creation Environment' model allowing users to create = interesting services building on top of 'primitives' that can be = represented on the Web. This document describes the motivation for an RSS feed for Presence = information, which the authors believe would be useful to create new = services using a similar environment described above. regds arjun -- Arjun Roychowdhury _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple -------------------------------------------------------------------- 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 contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From lulx@wfpcnet.com Fri Jul 06 11:39:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ptu-0001Ym-UP for simple-archive@lists.ietf.org; Fri, 06 Jul 2007 11:39:19 -0400 Received: from [64.122.55.11] (helo=yrdzgz) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I6ptt-0005Ry-Vp for simple-archive@lists.ietf.org; Fri, 06 Jul 2007 11:39:18 -0400 Received: from ktglz ([128.28.131.55]) by yrdzgz (8.13.5/8.13.5) with SMTP id l66Fe0VK015766; Fri, 6 Jul 2007 10:40:00 -0500 Message-ID: <468E61F2.4040000@wfpcnet.com> Date: Fri, 6 Jul 2007 10:38:26 -0500 From: Gwendolen X. Jacobs User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: Fwd: info.ggpaixohhsj.pdf Content-Type: multipart/mixed; boundary="------------080501010408010304020000" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 --------------080501010408010304020000 Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 7bit --------------080501010408010304020000 Content-Type: application/pdf; name="info.ggpaixohhsj.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="info.ggpaixohhsj.pdf" JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cK L1BhZ2VzIDMgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbIDQg MCBSIF0KL0NvdW50IDEKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzIDw8Ci9Gb250IDw8IC9GMCA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0w IDkgMCBSID4+Ci9Qcm9jU2V0IDcgMCBSID4+Ci9NZWRpYUJveCBbMCAwIDMzMSAxOTZdCi9Dcm9w Qm94IFswIDAgMzMxIDE5Nl0KL0NvbnRlbnRzIDUgMCBSCi9UaHVtYiAxMiAwIFIKPj4KZW5kb2Jq CjUgMCBvYmoKPDwKL0xlbmd0aCA2IDAgUgo+PgpzdHJlYW0KcQozMzEgMCAwIDE5NiAwIDAgY20K L0ltMCBEbwpRCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozMQplbmRvYmoKNyAwIG9iagpbIC9Q REYgL1RleHQgL0ltYWdlSSBdCmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovTmFtZSAvRjAKL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIC9NYWNSb21h bkVuY29kaW5nCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovTmFtZSAvSW0wCi9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDMzMQovSGVpZ2h0 IDE5NgovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEwIDAg Ugo+PgpzdHJlYW0KgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUrlktl0vmExmUzmk1m03nE5nU7nk9n0/oFBoVDolFo1HpFJpVLplNp1PqFRqVTqlVq1XrFZr VbrldkLssERdTqYtlYtetEtXivoimUwAt0QHQ6grIu12hQEAkDDAYtNeT6fM+DiB9GEfP+JgR/GI fjmEgR9PoAO2VysJwMFNZrgTwXgAXlrgQ6IZDMhkgeKxV/rObgRreGdeGz2OvSANFAAFCKj+bzgA 2YMjmzgfE4gA28IyXLgWXAGS54ww4AGGZSCQAGu7O11lX68CSG/Neh0Gc7XX74AfT69T6FG5AAN+ XygiK+x9s8Fy2V5nU6RPgAT7sOy37kPQhDtNAz7tQSgr1oK+j4ty+0KPwvYAFQVDJuaOzuqwbpuj YNhPumUIGoKBAEIEK8WCuAAPA9AJotlAjzQGSD2ISF0dx2GMfAAGImoEspUPyJAkIFECBDMMyDuk gYGxdFKBSmg5PxmgjfPPHD1n0A4DoEOo6hcgcdw8q5XrYgT7ABNiCOcyUKN4ABTzqU55HkABMkyg 6wHYhA2jaAFA0Ge4AHvQwATNHZuDqgcU0hFyDzYRUNj7Drnw2g06oLPc9T+ACwrCzI5DlQdBVPM6 rDmOaBj4Q4AEPWCCSqK75txNc5oG50rVBTs+U8W5bgBYSBG4bgAG4dUmIGvCGVlWYACvFQAARSSD Qq6E4NiaMZszP1fU9T1VKouaB3NcyCkuS5KkrAMADO3MH2lKVqIQV7Ps1ArgNizNQ1AW88oHbqBY Ikcq3pFiCF49d8wJcirmWZcjyOh5owBd93jYS6BXWgzBXi+CChqGqCBrJF6XnNtdIFkmSJZfyBBR E6D5fiGb5xnOdZ3nme59n+gaDoWh6JoujaPpGk6Vpemabp2n6hqOpanqmq6tq+sazrWt65ruva+l pIC6xA/7BsyBA6DqBy/UtSoxhGzqrhSbnieKBjSNKCgZvYGSRI4hoFL4DiHa4+D4gRnGduKMWFYQ 60Sgx4X2hhPcqgXKm0hQwm6j5KlPYqQcsgZAEAgowjDJcmDNzgAG7vA01MgQaczy5PcWixBC8hgK AoiAKgPAbZywhB2nakBBEEhYEd53qJPTgoGC6LpzIEc3jAByvsk8RxHdJZITgAE+7IGNA0duioT/ Aghx/L8qBfb9P0m5L6ByPhV1kvAUDwN5/+PQJB4RAgGGlIIacxbZSED9fU+EE4H32PvfMAB9xEUB EEf6gY8D/3hMGNK4Aghq3zkSA+PF+JAgTtqAA2mFMKIUvpSADFZKyAABTHpDWGyfl/wCOFBkgaBz 0wXf+QocZjoTPqhVCoisNSCFhIIGeIJ34oI3iAgOEJES9EFFYKyCEEoIwSiIQN9LaYxNqhUP0fsL 0fAxhkAAAgqCBoZIMZCC0VCERXIEE2LQABWPmgmQUD8XyFRIIEj8ggxS9xwAxG5DSmQAGEjlBiKp EQbpgIIe8gQuRcgAkwQOTZBBWCkII+6UT5gPwLZMvZuBAkIkEjgQoG4NyBt7ZksiTsnZNSZIbH2U sYS9xIUgvY+J8yBiKQvK2SJEFEEFleQIZgzAATNIGPoUJBTICmcaQQW6QgNx5GKGeYc0yBChnAQS VaK1IEKmSQJQgAAbzOmfM2dxEnQEIDOrqcU402zCRWpKVMxyGMSNPAYMkCDVmJUQGRmhBJxDlBkA Afg/CCJPP9I8uDjZ5kDASAmiM4JxEIYkxIgUBgAQgIwDI6ZHaOz+pVSullLaXUvJcAculMKXrWcM 4cABc10kJDa5CmjWDEh/NQy1kq1ZgEFpuQSnU8aftPFyjxMqZIGEIQoyJGBAneVNaiGSTEuKu1dI VGptclGDVaaeJKtAkgACgrZWAhMtlFA0BpLis1TpMA0UOPkgQNxkEKrRNE+Bu66tNCnYWwqxqhhn o5PggQQ2UV5IEJKvtg2myPXAQMPAeCCHLMlDBupArP2UhDXKuForTWntRam1Vq7WWttda+2FsbZW ztpbW21t7cW5t1bu3lvbfW/uBcG4RJ5+lPAQ6pZgbJ6gETmDF8UlxcgVAqQO6TXh2LDIEWMnkiyW 3RJUHZJpBHVkCuuAAsY6iBCvRZKgaBRLykIuKTgWgtCBjdvCSEZaOSKjqWullLRA753zDYQpJRDQ rvNJQBRyYa76AAvmAANiILkDsG42PApBy1ivRiAB5gFFqCHo+MshMP5vGDLcW8gYVxCiFwQQrB5D w0hxJxVczrwyQVlIU3jHCNH+JUWotZehAsaEIWYQ0AV9yJuvbywVbo0TuEFEhL+feQkYgeFePAaI aUQOcdVkYAQAAzZLbwABg1ZclAAzHmhvOZUsHHihOcg2QyG5FJtiFiV7cpLVRYmrMiWB2N5H7Cik hBG2vSIEF11+SEkusRA69u+S6CtlDJiIAFICErWCumk9WTSBgx0DEigyhn5kCbcQu8eFyEhpgQam oWlqQDQRUlPOBCM/6ejJQTUUMtS6GzUGm8KzMC4FzSQLNMINW6WINrO9Irx9Zm1tCwlQN1UKHUQo mklQiBaWNVQTVZBQmwwIIDHbaxn5v014GnL7qZmTumhMvahCoQaubLpEgtQdwSEIOYkMix3A68yJ Y/dc7JYbvmSPeoNI9uwf25wiA/DAAbfkHuCoMCN9gAfoADc+6XUhInhwGdm0yDaD0nvXhJLKd1Ln hM7lPA1CzppFoMgcWSCilL9KyN0bEhcQhfqzJnPRo0zp2QeaFe+B8FqHQOA4+7pVPIFzIg5fSBCo QvHfcG+cbZ9NGXToPHePEF5caigo+wAAVlx04JrugAF96ghiN0dudSE4mQZg3QSC9DIHu4gg96RE t72AdtpBLM3kV8WAyBkKUkGFMwIgYpxVLqY4xlf1ZQdQ7GDUVm1AQySUIR4HwV5MSzekbN6lIoQz jquwPLtBBhVePY8QRK5CBQjB8qy9mwADT8X8Er7zkcTByOsXI29BcGBBeFOQIVXjfVv4AAJVjDMR ovSbGAycDNvL1DT6r7zpB6KEpYrtll1RPqfW4t5rUo7LNEHj2QWPr5BSfteSF7tCnPjeNn/pQhHt aRP07953zgrIFH1P1v1H2pQBSHkP4Chn2ouiKBLrJLJgABpGUPumaqiiBu9iDA5PsCYmKQIwNiCN kAAGXPaiDIzIFIipcwEiJJyiDwOkjtkQQvLQQwQDEozGkAXDEhlqEiDQJH6wWvvPvimwdiXOyAaK pCTB9OALhiNQVCsmVQkiLnih2nbCUAGq6CXHihzHqQnCPjjiRhmKEwRCqOYCDLqiTkdkxCMAauSi ik4iQr4iGhom9nYiFAXObiHwliGK3CZjoCFwwCGAaw3CFQuFVAYtoCOw+iHPdiErMrMq8CLFeCFQ 7iXBuRCI7CDj9jJjlmWCDRDiGRACLgCMUCiBDr2iEt+FkvgizCyiFD+Q9sYMlxFPzg8OBnmCJRTC FxWqqAzl2l3COAbgdRaEqFoxSo1rtAARVBihTRcRHxMvQCDslRXiDxFxEkUG4GTijQwQ/kpqssOM flJQJKAoZRTCyCEjllMRWFNCDNzoWJBBiQYmWm4HmFagrwdwLCDRVLNlLEOjLQ9xdhKw5HpM0oxI ViBR2ndsEFamKLGvrRbRiiGRHiBR+tDtDNhiDAOhiGTGXF7MOsWibxKiCm0vRqOGaAPFJG5qsxtr 4qRRxPgiEqCuau0uagMELyPJBAAPDiCySMUqjiDR5rHjTNyIYrsizx7txuGO1iCSPPYJxqUkYScs gqsMWkUr+iERbEhj8hit5w1CDSZSkOpm0LGCdBMvFCBMThEu1OoubpWw9k3CByQiEFpyoKsSdiCx ihuPdPzh2E+AAB5PiiBi4i+SXuorOJhxNCESnSTHeyUEVR5yyFhxih1FkPzCDFxiFSjy1D+y2Sbp VMNiExtlHlJC4hbyWCFS8iCP5CCSzieKLomRpCBA8FQJ1gDoZR7i+S0w6iCk3S3CFgEl1h2IqHQH QImLyPzzXTiFUuLI1zaRbjJzcppy3AgAgCBDMqMmOk/oACDlhThRorMk/tpFCTZSrI3zAiBxcCDT NBeTovIKNCGTVwMrMTjCcRcS/prFiFhDYCBDRKcugKZi8FnNpI6kLu1pjCIk4FLRQi4UDqLz8uTw HCDlAkvoZI7BUC/UBI3A+vQDCIKmHlLiQKdKZiBFnOBFAuQOnzxw9pHGMTliCS/zsHJibDBCCrOR 0CGj0UXCFjTtjStIKGQRmpGE3g7Q9jpUhIeo6CHKAttjEtwBBD5ldI20BiUEGiL0lxIiIDBw9lLj LGzUoiXUogGM+QtCeILiXSHqJUwCckQERCaEzNwkhUzCICwUUifzTiZtNCkgXS5mcFKzyleolz3C rqLI1iHhkFWikgzUGgAUQlXRhCrGYiBQmiFsrCPMmurieMsTpU/CFOfiRFIp9ympojQmHErDAlRF hGBBMgGNOOsClgamJQgiGGLiC1GiFpLCLkKJpvqQQ1Wm/AkAhpZMmMd1Y1ZCNPugrkch9E5SMPqN KGK1eVfM+1UsyDA1hCDF2l3pvJLEIgGwKCCgkFJEukck2BQ1twQGSQPiCG91oCcgZBApwpwASgEP awQoEAXI1N+HBADod1furmYg2BKv6L6hugBRoSMKiAZKGqHB+WDAABA12J7gSqiGRqikexbPcVnn hmL1pRXFughtKBlvaKigZKIKHKG112FznWH1yPwQZFFQi1M1J1o1g1+vjiEA0ksMQwYga2DiB2FK FBQ2UWU2gA/gTkeiaF5jvhykBkqypPll3UWOqCCrQ2hiCSqh1JAA0JQAAANgNiDwzweCBGKD2EHj rhyhysfMfFrPQBKsUR7udKpqp01iI2tKogAWuiCPumK1viBWyBIAPWlSdsTiFLn23uqnAvNCEgNg piBQzFHCCA2wkAkL9CB2yFHsfkVRdSyUDiYGDJZVfORgAQg1ZTqCCPW1qiBhi02uozAu1hShSiDo /iCM2GCGCG+IdoDGJrGkchIPmmMXRAAH8F1xeXACIXWCBnkAAXXiCs2Vnod1nWvVRCE3SWm3Mgm0 2yjuZnkgAHkBBIiAPo+Or1gVnXPW8EB1piWl0lzQ4XFKpIXNw3CDdGRIeJITpU43e3fPHzlI3ubu oUPT9X+i5mDEzX2X2JCEI1aX5VgiITaRVUn3+3/OtC6YAX1pTEIQcsoIg1hKM36x7RUu2JjRfXz0 PmBnh01oXATt733CXqbHDWvqcYQCCp1iBkxiC4B3CFcJo3I0124CCljyGlaTFnDqbgkA+OT3+Tjp 04ZQTAAQaJyKE4DCDlGV6I8kg2uBl2lFJYV4hYiYX0RqfCSunCGypKcAAA+LH4XAdOB4YCY2K2vm JJUSdqbqcYhvEA7LuCEt8Iih+3DCMLHYwY44xCCgdAuhTFMOpC9XUOdjuzICLY+CFFIYViZxBCqg 5VAmrr/iTTPCY45CsAb4urVgyIPFVFug4sZEPCwS9Cc1gCXyIirAD0SKw4UDu5RiC5MCDY1iOh73 GOIiXolCiA+U8CIZeCG4liFg/nIB8q9TzSwCKNSiJyqiKh81DiGZHiQZmZECWzwCiJ0iLZnNCFSh 6AAIbZgiEN8ZhiQY0iI5qiGxJ47tAiEoxh+jFZtCFURpKFj57CFG2m3Zw5v5wIbCBApoZY73kh1S BCHg5ZXCCuL57aFiX5uaDFS5ziBg256lkaHQLg5Z9iOBFhFg96OiBWtLDNSO/iF5bZ8HY5g5xE9y 9E8OHkhaFljo8iFrDZKKeOQRTaGSghuHY50iBh6S9FPE8B5JsiFaN6iiELDgAZ8p1aECQqLCBVSh 5ZTk9E9hHiB2tW5AAA9hFiBaNiEXEFjFTaeCDvcaXiBrzpsanCETKCBhH2tiB6PAAau646OA96P3 EakNS6I6liD5nTHr0Fi606oiEhH6225AN64CFasaRNSUR7Gzj6SxTrsr0azp5nG1Taf6para3ata 5a5CUpZOL6/Lsyx2s6q6kZxCCa26P666tCG5tTYmRKH4RCHaz7NCCLDIaZ+CBrDaq2s7N6665iEH H0HUSbZOsXOAGbQzRiCB5a3bFakbB7eiBa4ai6tiCavt3iDgUWD7ZZU6zbJvg4e7bIZrC5+bUCRk fZ7uL1fVJ30z6k8aq6sbPCC5eIlbz6+I1ukOHAALQ3FaBCEqyr367CDB5InAu5/Z+iBb67dCCtSt kNB2okyEflj7118m9GASxgNgRCFZxcF763E6kaLA/vgrP32aEnBDhVUOe8CGBWtARcN647SCRVfA DjUJCX2ISCCqxFkkwV8cViD6lak8GCE5GKjWzDX0XIBiHWpEgVA71kZhoj4B+gYuLtStS77rGrHJ gJUjtEH7QN9t74JiCV6aF8UCGO/G3cr5v5w6eg5DSwkCCDaDXB4XIqQ6AoYYBcxFjcUV0bvCQK5N Sceodjjz7j1cUoPAyNwBWHxb+iOY4ZHzPQycGw5CDDNjaCCAh8aqhgY9FnxrQh4h1M03Nod1XCJd Jax18cVCagr4/iELqhcxGiCcnl+dLclnxiVKLFHWupbZLAAAGFS7ICRBtQpHRX7CBnPJriPntHMn SdmiBnTr7NFCtAY9Y3oPHiEZcA6rSiHh2QpLV9iishAAuhuc9HyH2iSdtrT0xU3GeogiLQUCPaLG l5DCS7/pDSvCGonCtS2CM3kYkiXBFZlCm8fCSIhiDgO1xiGSkiLqviHwA90QqiMK4JPiUi9TbirZ 5CKMTXMiCAm63TcTCiFm5iMu7CHqLiSAEO4iBtqnIA2pXp2iFBQj3hIWyve2nd8j7eBCFS4CL+Si eBlvrUcUdJgjcDeKU2eCDUhAYUegz3MlhX8CBqJTNUb0cOeCI7jCTwgtXOjoDQxJVQc+jqGqH2E+ o0hUMPQT6CEYMqTybJxyEiBsQvbPMOFCgDyEHVd+3tLKBehStYCpx3JiBh+WUKRD3pHF3XS8kDfC Dl5kHwN84IC+hOEN9EoD5GRKFqGfAgSmbDcfCiEnJCCjPT8F81HqPP7e5IDjVqRJhAUTnBQ2yWQi EYbI5fEGHjXja1QVjL9fHNs+4iaqyjaDifFT7heOFx6iDupI73UY7t6DVwX1tu6O5M2ja0tiCx62 70ZgCU2o0uGNI+vZAYQ4GsysnyWtuqRVdGKEN/kX2iGQxQRYiX/1UwuEG/Q5UEsF0plu6AdFUFix TcTCCiAKpVAAAOBwQQAHY7QiEn2CAwGAADgeGGSLH+GABoxuMwwdDqCDcbwSPx2OtxuDGECd4wRL peCQJKwaCOCFwyFH1oxAAAyJyaGRygtGCUKS0CGG2KQiUQQT0+WxmBRmbQSFUCfSYyRiEUKNUSu2 CjgCxyQdG2kWm1Wu2WSQW6CHU6gAXC6MnV7wQuuyCGkBX+kPp9QQzmeEJ9KwyXwQ2J8AJ/HWGvyd uUCj3KCXW24AAGYzQQrlcAYKCPrDY/IwjFx3IWl1OqOxMD2+4WyJ3sAOw0wQBN3PaDRaPBxnIJXE 0DW6jJQh1ZWCNyl7Oj2M63aOvelwTdW3ud2GHw+QiPx9mABmeWMuY2vf2dw/mRl6GGAgERnQlfhv oUYTIZHVoYCj6pMPjxoQ87uMwzQAD+jEGOAgj6IzCIAPwhgUNO70Mu4uoXK5BYyQ00YUQuhjjJwm 8IPo0TwLNAz0I69aEHuucQxrDIKAopEWRs7j7gapCnqefruxwtUCQK8z0QOACRDbJyCCHH6MgbKk fyq+UeSzLTvSxHkcSKZzwR3LcyRsDwPTLNM1TXNk2zdN84TiAAYhi6E5TvPE8z1Pc+T7P0/0BQNB LUXJc0GglCw0SRJRDOi1A6lSGHUW85UXQ7fx4ZBkTUGMOA6DoAU/UU8U0k1LUOKYpw0IYkRCJFWr SRRFIyAgCTlEdD0/LJQlDNQUIchleIJWQAVlWYAVrWy2npVNmwzVlDgAwqOnZao8KQPtgLUfduH2 hBQHuP4CFQoCc2yglzozXlhTJdM3XMtd2RsPA8WqUyTHjfKo31fKkXEjKroShds2Bgl5XkjNpwzg l035P6eQs/YAXYTOKlOgjknaGi1gqCqCArby0qejIm2TcgAFRk47HMrCIYgtZTlOUzkzcVmbFZkt lZRlOApNl2XxHXCCFDDCOjkdqCBpQ2O4/jyTGIYh+n7fao5Hm+cZNk+BZahgGP1oWJ3kTOLuUhml abtE41SjI5DkghzJAA7nNeiSIgYsCgI2Lu9oIOS0LTpiGZs57KlYqB4j2oAN1UAApnoAG27fuAdb kbjXtgnqIqKje8DiOO9IQc2/VepGOhpZomoJwaUqcqKOg2DaCbXyG3AAc2WLI7KO7vzYAc8gnPqB 0iGY74vZVSJurgB1mR8V2G18dt3Ixagm6brzfOeAOPezj6aEdgghFkWAHxIIPfE9gDdKKQpqJKXl +87wghb/WwDfLX6e1/AAA9/L8r53EgAf2T8iRziUGVJ+AdzRaXgkaDO/R+ZfDOKYI66Jvrj3Gvpf O+F8ZQBbnRIo+19pHSvPad8WAaJhoIC3L4AA3pnykQWIQ7MjL5XzQBfBB8gkBIRO6TcEMIZGQblv JKDp3DkQ5LMC7AyFBYH4EmTsQxyz1TYPWesR2ICUIgkiLMSCIztnprMe05537vntkZJ3AuKBziJv tbpFZzBHR1FLiyAAIZIyMllIyF0sDv4ywNNjD6Hr7nlmVjhHEk0cyGR1jybSGUSQAR8hNGZ7icGf teIIRZKhBJNx2iDFkZaICkHjLHGSNTbEOFxRpCKA5SGIE8SjJyTcm4gRBk9Jlv5HjaEZjKUATIck OIKKbKxvLmmID6lsGRKQAEqy2IyRZJ5tY9EIc8AwbiCTrOQlSUwyswznEmJ212U8spFy1mSGRJ0e Dpy7UCDQGhmAATwaknCAjcjuRccyT1v6hVDC5Y2XKgCNAATzVCqCgpSBXzjKxCCVQfwYooI6SIG7 LwGBtncoGcJCDZTfoeUCfBD6FKJQyqIfsolo0nRqewe6Ti0JPmiR2d1F1EKGIYgymyeEFUoZ852M 6fRc0Cp1UGoSb6ZVDqCHiDFRqlVLRqOwGjgamKDM9BSqNVarVXqxVmrVW6uVdTyPAeCGg0Boq9WW syhydhDGWuErgf2oDETuJ4T1Z66V1T2vWSLLHbpLGYptTSmh8ndDWGusFYSuykJIi+u1i7GJrI43 wNK1YWj0cevRa4JASF6b23wtxtFSgAGREQt40RIEEEgamxtqbVI2rAAC1pgprNoqgQh07831s0NW ckBh4QADLYku61dwbhFsBkDIAA5RyrFHUDEE5TrmvNIYv0ADgbP2gU2bUG9vBDiHRTcO713yTBnV msS5gAJ+U0tm2m6QLlGEEs/e+691bwXzvoW1CZDBljLIIe281NLptOpEAAe4SExXudrfXBGCYmEE F4LwgiZzuWtwVhPCiaw0m7wrhnDSGm2hyiXhvEGIcRYjxJiXE2J8UYpxVivFmLcXYvxhjHGWM8aY 1xtjfHGOcdY7x5j3H2P8gZByFkPImRcjZHyRknJWS8mZNydk/KGUcpZTyplXK2V8sZZy1lvLmXcv ZfzBmHMWY0QkBAplbmRzdHJlYW0KZW5kb2JqCjEwIDAgb2JqCjcxODAKZW5kb2JqCjExIDAgb2Jq ClsgL0luZGV4ZWQgL0RldmljZVJHQiAyNTUgMTQgMCBSIF0KZW5kb2JqCjEyIDAgb2JqCjw8Ci9G aWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDEwNgovSGVpZ2h0IDYzCi9Db2xvclNwYWNlIDEx IDAgUgovQml0c1BlckNvbXBvbmVudCA4Ci9MZW5ndGggMTMgMCBSCj4+CnN0cmVhbQqAP+BQOCQW DQeEQmFQuGQ2HQ+IRGJROKRWLReMRmNRuOR2PR+QSGRSOSSWTSeUSmVSuWS2Hvp8Pl+Pt+Qx+vx+ vl7vd9vp8v6gS6hUOiQh7Pl6uB0tp2PF1PaYPJ8PV9zd6vl7N11t10PJ0Rh+2FzOl3O94PN2uh2U B/RV4vJ2sZdrJqM1eu13Np4PBuTR9QNtt9vrxdLJutprLJktxhtVwt52uB1vJ3NdvNlxudwOVwNh zud1PuaUXSaWKtp1NtErVBp5jphTNFXpxlq9dt5jKhqLNDMBFrVtLpgthkL5mr5mNpnLZor5tutv tx1YhuMR7vR4vh8PdRqtLKtUpPwJtrNtjsxorhoNdksZutNrOZtK5qrdvOlvQNmOJlL5rlwTxilE SZhEmVpoFMbjIoGahvGYXBiE8ch0mwTRckoUZfk8SZej+S5dESSRSEGV5cFMXRiFyW5elieB4ne0 0YxkhhrHKc5FlmWZQmIW5LmAXRvnYdRqnQa5aGaVBCliQBJF4SBUl6TRXlgS5YF0UZeGSVh2Hsdx sG8ahXlsUp2nkd57nse5SE+VZZE9NxNlKVxVlYWRSFgVZMFIWJYFgVJkGiRpfl6ZBumogZ5nwd5d m0ZplG+aZem6YxjHEZ5xngc6BxsbRlGgV5vG+YhXFwTRXGCVRBlUSBPliS5CkoQBZysXBaF4XZWF 5Mx5xnXtfIGeB6HuZBsnCZxvnGcx2HmfJ9Jmfh9HYdxxG4cpsG0chqGmcJmmgbj3HOzx2nCtllHA axxGrRKqH4fhtHScx6Hse0anCaRym0apvm2dR1HGsx0nUt5pMzZZ5IMqp/LCfyqpusJ+qCgSgH6v x8n2fJ4KmeDrmgcZqHme55mocZsneerKHqd5zHceFnJrX+YZjmWZ5pmubZvnGc51neeZ7n2f6Ajq 2Wcfa2LBiF2n7oOloPobtHwo+FoGqqZ4ohh8nxaGsnuqmpYkoB86xoyCneqeqJsm6dHthWlI0eyp GkZxrGwbBumaZBqnGcJzm+cxynEdJznLIRzHQdRwHOdGQHyb5zniXhrnJi2X6ZpZ+WaahXF6bNiH kcCpG6eBqG4b5nmgbJ3G+dxznJgR5Hob51nUWhRGAVBVlcRRPFIbpyG+bx3HAeZ6noVJaFkacimn ChzHgdV7m+q58Kapx37KfB9oGeh3nYapWFuemBHqb+ynWepoG9fByHWfx+LahZlGeuplms2xclQV pbmKZBnEuUwpQ2h+EGGgPIhwzB1EII4SwoBfi8GeNIZ45RciyGwOocI8XKtMH2PgfQyhVDAHYc8/ 40BtipGoM8Sz6BaDdGcJ0ZY2oXjQF0M4XwrhfivD6JcVoghKijEUJgW4mxUivFmK8bo4RvinGUKZ SQvIXCdGiOgawqBjitMmOwZzHhPDJFGsIfBAx8LCGgLEYw3hnjdGkLAZY0RRDKGiKUaw4RopcHQd hBRCRujRGuN0Y8JxijJGkMU9Y2BnCjF8JYRQuBFCWF2JESwthHCgidAwULfRti3GeLYcrq4MtLWa PwXAvxqjSGwOEYQxxrDNGOOMXwshwDDF2OEXQvxmD2O23obIxTEjBGIKYyI4jiDAGyMM5AzhcFmH UesY4yRhC7GqNoZ5AxkDYF+PEeo7hqzJF4N4Yh2R4EDHaPAeqVhpykHEMsZ5jBeDbGeMgdQ2BqDv KQPse48B8kJHw6+UYwh7DwdeOkyg7HDDsHINIdI1RzjyHKOkeA5hmx5HUPIdg1kKDLHGMxoknWgk yH4NQcRah5j2HWO8ei8h8sLNEP0mM9B7j6YmVUfTRaXNsYo0gvxbCbkzWbTkgZOGilAp80hiZA2I D+pi0lh5YScEVLY+6n77yLMTaRRppg1nliHEgMAYw0BzCoFcNMW4whssPLYMkbo1xYDGGeNccw5h SjAGhQgddVK6V1I2OkcA7hEhmGMKcSY3BNB7GoKkSA0B5D1HhT4wQ5Ra1frUNgUgpBijElJXay1l yJDzLIMsWgvhyDbHMMQXYxRpjUGjPAZw9h6jzHEOMZ4yRmC7GmMUb4whWDfmhXOzFu7eEjarYgmR Vbe3DuJcW41x7kXJuVcu5lzbnESLYVRhNUGeVFHiPQeD1h1j0sQPcfA8yfUxHtPQeJPR6kzvOxS6 lzyLUxH0MQaAxBwDiG8NYa40yPDsHkXAejByEXcsQPQea5R0DdcANwa47xzuhHOM1Io5R5xYHONY aw6BsNjH/dweQ4hyDdISPUeo+BmjJG/hhq7YR3FlWatEeRZypkDHqPoewmhdCZGGM0X4nxbiVFoM UVSdRUCeE0JoQgjRLCtFaL4W4uxkFmi+QJM49MKjgG2Owcwyx1DmdiOwabiBzF4aeXgdw3R0jfHI O3DrJBwX1n8O8bQ8R0sfHQ2XARPiBjoLSM8bE0SCjgv6PcmY6R1jpHYPAdpQyjj5EYLIXAohcjGE KKMXIpBjHEGyOZP9pxwjmF8MsaQxhfjQlSucaDjkzkDGcMsaaeEgDcHCK8VIshnjNGiNEZwzk4ie F+oMSYnBKqEGAJ4WInxUC9GTJIYwkhWjAE6L4X4mRci9Jw20f43xyjmEanMXE5RXjFGKNJbYzxhj WFsLMXw2BpDqF8KwbQ0Rjr5GMNa8JAxzWtFIKMUmSxYijFgKwbw5xxkDuuPISAtBXF6HcJoWIwRG CsFyJMWotw6CZE6G8Rokg+CYFDvkXZ2qnjMGXZAUYrhUioFwK0XQzBPidF+K7bvBheDBFwMEVj+B CiGEFEQUojhMCFiGKMVtjRNCtFIL0bAzRGClE6KgXQ2G5jpFILgZIpxiDJIHScfgtRpDepIPgXYy xkCeF4LKhY6xkDBGnBYdTCr1kfpWKwXwzrTjjDuIYWAoBXDQE2KEX4lBOi7GUMwa4pRSC0F0LwYg sxbi+FiLoXQ5x0lfIFQ4a44RhzxG3MAWIuMWjyGmLgVQwhTCjFoKQTIwhVCzGn4EWothbWkG2Mob Q4ReDOGvuYaAnRWjC2mpvM4rRYDHFno8VwsxgilFQLQWwvhhiqyQLgXYuxTCPFmLsT4wRpCgF6Pv EJAxvjJgcKQVY3hh9oF0L6+w0YwNYFy6YaI5B2C9GiNp045RXC5GaNkbg6BjjBGq1AGoGWGCGsHc HWHiLYGuGsG8F+GKF2GMGUGSGyG89iGQGaG0GYMCGOoeF0GEG4fyGaFuNcGCEyGWGSFaGqGwGUGo lSGKGMGSF8F6GYFKFiFiFmGMHMFwGeG0FQF2GaFkGG/Ua+H8FaFkGO0EHgGWGYGsGGGUGmHiZAGK GaGwGWGcGYYeJIuibCqOHRCeM8HQHCHaHeGoHIHMpIHqpGHmuuHsG4G8HUFAFoGGHGHWLWKA+4Hy HeHCTOHaXmHOHoqIHoYsHaUSHOpIq4H1EEwEHeHmHkHspQpOG8GSHYGwGyHIwwJoH6G6HUK2cMMw HQHWHcHkG+HQHcb2HUHEHOHY2sHaGeGYHCFY+MJiL+YkuCHWHsH4HiKOHeHiWhFkIUpwJwxMYkYg Ju7aqYayH4HcHwfafaaoqWIWHmu4uuH4deHyG2K0HOLKIMHIycpii8G28hEUHsHCKaHSnDGCI+bC How4GqXaezCEWfHgJmJ8HwYeHcHUHoyoHYFwmgK6fYYiIUHIHGHIGmGyG0axF6KwHwGoGUGuGIF4 GYHKdfEBF6IGaIv0HeJmO0Hq0OIQHKG3AKccqIYgHIHCdSWSNFIoIo2mvGpSH6GgGYGaHeHWHQbY IGoIHcGy09EWHORcHIJ8J4g2KgH0GicCZdIyJoJ/H+Hcv6FuGCGcHQHEgwIKYvJ/GUYgamLDDkHk NEH2wEHhJqV+HuawFqmXLEHyX+HeGOG4GwF4GkGSGAGrCSGyOOGKkwG8GuGuHKoKWQFkGQFoGEGW FcHMX8IHLMG6HAGaHEHEGmFqFgE01uF4Xaco3cGkFi6GF8FgF+GGG2GqRsHGG2G8HEG2HGHEWWHo GnNJFGHOFSGYFuHCOwGkHOvrC+GkGytMG0GkIMcS9oGSFiG0G+GYMzNAG8oeG0GAHBOAGsGqGEGq GiGYHAK4GQGOGgGm9sFiGIUK0EFsGCGMHQdYqUIGG7NkF+GcFlBiFoF2GYFiFAF2FSxuFwKUHKFo GQFsHWHaHSvgFxPEGqqGIFAkGyEwFOEuesHeMEGiGyGsGKFyFWF2R0FeHQcKUQawGGnKuuHoFsGM GGQUHaHGHiHWGCHWHAHYJgNIJgHuGIFgFIOxLSF0FgFiEsEIFmE+EaFkFsE4GAGYF606GEFvIcFc GEFkGKiOFcGQF3QpAGHBNyIFJ4HSFrNaFmGaFmFtPLDkG8wwzWHAF4FwFSGUGQGAGoF+FqGiF7B+ FoFOF+FaFAHaHUHQGGFkisHOHCGCF0FLPiFk9QFQ0m/yGiGWGzSUII0IHeFimY7QF2/aF2FGGEFK FYGMFVL6TyF2E7PQFSFOTyFrS2FNQE1m2kpiGwGIGKUaGeJ7F6LMHNBfBsGMFxR6GCE2FkE64WF0 GymBSIFmHUes/aGpAwGVP6H+YEHSF+GsF6paHwT+FcFqF0E/UyEtIEHAH0piamawGUFkFSokHUGA FYFCHcHiSEHSG2GG0m0KHYNIXaH0G8WNJ+HKG+GcG4GoF2HQG8wMHOHEHXDSv0HmHVEEGgHClyG+ GuHGHSe2WCu4HvIqJgG1GsHMHCcQHGHGHsu4INGGO0vAYuOuKaoa06FUFAF8EoTQHjYSGibUs+GI HOHW/oHIq2G+GVHGM0oEIMHkUSHNZIHi0MWuG2Gi1mFc9KHAG0GuFcF4FCGYG4GSo+j2G6GEHKOm TSRgIEJmYuTSwwLYahLEJiJ2H0ZYKScGlsHwGWX2sOHvDIRdCewxIzYqqUHKZIX0eSHaHEYsyeII Ymv6HTHlOg3SHUGyReG4HGG4F8eGHcZ5baWck+H0LIG8TRI4IIO2HuGGGMF0HrYdJkHYp4IiKOHw msHpWcHyGmhgGyHPP5H+IYWgYwd9HOIYJ8HyHMHAHAHeHaHYGMF8FtAKHUIZFwHwF/N+I9FsH2Hi JhcuHyHcKQH0JuTOWYWgINLEZOTMbeUSpKGUGcGwHKesWUZTeIYgHSUSqKZgGqOgFtLiGyHYG0G4 Hg8iu4fIHitAHSPOGEGUGU2+ngFSFyFGv3Q4HLXfIFWcH0FIF8FLHKHNXYGUYvdPOQG+GyGwWgqf EoW4nOFSGkF8FGOWFGGrPaGkGEFiGqF1TEGOGkHIHKGGG1TAvuHWHOzRNGHIHIm4GWF2tUHsGwd+ HYpGG9hMfWG7PAIQGGGWGUEsFMFCFeF8F8GAGmGYGcHEGgHKHoHSGCHEGoF8HCGYEgGEFsGHMQFo GoGHM2G0GIG2GyFaPadIHOGAGOFwG4oKIGLYGkHCHEE+F6FaE+F0FAFUGeFqGKGyGSE4idIY6sIE xWFiGGFuFAFiFWEo/EF6GKicFsFOGSG2GsFqGqGaFeGcGeYEHcGpZKdiHWFcGXA1YUHSHHTYK5aa JaFeGgGMEyGCFyEaFu3uGOF4FXh+FEF/CSG0GwGGGBSnBLEmGo/OFkv2Hg9cFOFgFuFOLKHW9cFM HWHWHKGEFyEwHpHsGaFaFCGUFEFKHocMbYGjigXyGjjqFcEgFuFeDSFKEkD2FgFCC8E4ECE/mSFM FwGcFMF+GaE1PQ8XUuMLAYFuFqfuGqGqGUFIFMEKGWF+F3IcFqbkGCg4O1RIIKG6GGGOGO82GOFM FyGQFQFvDCHiGYG8G0E8GAF2EJTMDVnCEyF+FoEWF6FCkwGy+CGmy7FQMmF+F8FyGmG5CCH/abM0 FgFEiCFcFcE48iHEG+G6GyFwF0EwHEGyF8amJiGkiIGCE4FcF8E0FYUmGSF2Fs8CGyHAFoGg/AGy Gmu2HeE6GMFTT6HCjIGqEyFoGAVIFk4MFUpKv8JWFjiCFUGUGlLyHVSgGqGObzSRdo02HcFoGiHA byHYGeGsHGNEXcGklRXaJiHwfWHElsHsGaGkGWxAHoG7kQGmGGGuahGUKAHg0GHKG864RdFGZEcM /eHSFDIeFMF4GWHOHMHi/0HSGtc4GUMwWIHLAwcSHLTWHUHcGMGEGLRDEoG85CGyGeHbuWHNhLZc v0HFLyXGZXbOJ6KwKgMcNTE+GuYCGocGGgM2HAX+rbYEjCKu/1E0TLjIKBcufCpFFwHeL9HbEUHO WaHtvWH8MkHAFuFyFiHYb+KwY2g4pGHoWWHq7SHUHYXkF6GqooWXbBfAHTsCGwEMFyGKZNYIJZeg Reu5GAHaxDewIiHFPEv7vvCEJ6H2HnEUF2GBM24AIMO2noKgHeHlMkpwxiHlV4uyZSHcHqISYfw4 a8IatWKgWabQJuJoHgZYFqFqF9C0HIKndyYpF4H4lKHQYtHdbeKAqOaTxQaSINdWHq3qzGG6X2/0 pyYvGaHkZDw+HewwYeWfdIIKHGGuHEOuHvjOGgGUGsGOg5eCp8pjxRzkIybZQ8HYXgHUFeFcGKzQ HOJgHwWmHKHvCeHtFH0qHaHMGiG8FiEiFnXe8kH/tGHPTQGIxqFuFsEYFgHspIINq6HAGAFSGIFk EuGFhMHQXmKSHQGybCHwLTesLwwx0qHYHe7iHkGwHGF0x4HOW8HA9kG+GOGuH4TKHyKV0uGEFWF+ TAG+HmHcHm0MwGqkH8GYGIGuGoGAGizQHbTMGOHspCGmGWGWjQGsGUFiF6F69CEmEcFeGwGSGsHy XlMKxC8TS60cGYFaGGb4U0IKGyGgG/p4F4GQFmGQFuEeSs+0FqEyF0GKFoGWGaGBsqGCGjxQIHlE GYtjS+GE3j5SKcHYHqLffEHUGGEoFeHIFaGCHunCIGG4GQGoGuGCGgFmEOFQGKFaGIWsHKJCXmHv QUGGFMFE5IE+4c6CGUPOFAE4+uF2F6GgFg5iEUE+GMEYFOGOEUFSLy4CIE/IGmGEE2FsF458GgkM IS1qG/3sGiE8FNSA6+GrzKFwGGFiLGHRQam2GuG2wwHXg2F1CIUgG4GKEqFQQoHCGAECFAGIEsFh lkGQFyEgE8FYDmEqF4EWFOGWFKOQFIF+GQEqFrymaSFkFcbuGnPEHUHgFgFoGcJ2HyF0GBMyGEGE 3vYyE4FMESECEoFuFaFsd97OH/NkHCGIVMF8EIE6GgFUF6HQGWGqIN0zsyFTLgFzkereFUCoEQFw 4LUVo4E6FwFOFSGEbDyyFyGCF2FeGBYyFGFAGSGCGPW2HcxGGiFWFCFWIAqkuol4qli12g1X/C28 uWMyU8slYUjwxEyrG8vGXC45HY9H5BH3i7nowFcwVmp14v10z2Ev2kzms1lEyFewWszFuuGEt1gw G6zm23GG23q8HrHHw9nw5W86Ha53c8HQ75C/3a8novWy404t2otmY4WlT2OuV+8Ha6WgwmE0WS03 9c445nm6WA2WU5XO6mw2G63XA5m+0W44Wq42XXFelWQnEcqFAn1gyGQ0FSpVWlkonn2+35c39U3k 4XY7nvn3Q83q/bm3mi5nU6Xe5nW6746mMx2gymi03s9XvHH0+X26nJuG85XI5XQ9Xk84/xX05nE6 nU5Xa8HT3Gzzmu43i6HczWM01ct2U+X0/I47Kgv1OtmKuGS7HU8n1n2Cv2oWRUmQXpjmSYBqmSeJ 4Hkjh7nqexyHEcxcFAYBnmSa57nseyrw5DqOH8fp+nW6x5ngeLin4fZ8n6fh+H6ep9HsfZ+n2fD2 HxGzRI+fj2nodR4I4ex6OieR3Q8/Z8nO3B9HxFsZs+e8WRVDUUn2j8an6e55n3HSQn89p9HqfboS Yex8nqeh7nxJhhG6YxbGcYEQn7DyOHccR0HkZByH7GU6o8fr2nsc55S0e5yGmcU/zrOZ1Kgeh3tb KsYn0eR7HYbZvx4fUrvapcZtdRZ5HWe58ns91F1SjrRF8YZmG4b5zHQ7p1nceR4w0ekcHZW5vnQc RuHMbBjGaXJzHccKOHqeJ4mUWJUu6wZ0m8ZRql9TxznGcB3nadszHscx2nCWxolYdZ5HGfJ+Hzbx 3nsfThoXUp8nAcrsHceJalmbhrmWdcUn8jjPn4eZ5nub5qGsbppGrgZ6nxNUmHwfZ7HWfB0yae56 TC4x9nmex5xteJ/n1EJVlquJlnCdJ2niYJjG9hRzF4YxrmAYhvuDTiFnoeZ6FeWJamab5kFyVhRG ibRim+ehrnQe17HkcRvnWaZznab5jG0WhvnOacPrm2hxHIdhr3wdEDFudp6Hiax0G7Qp6m0cx0u+ cpunI1cMmSZpzHKdZ41KfZ4zS0FUVVxEOlUYxgl6aJpE0XJcEQVZWkQWmTmsY5QlwYpalsYZSFQW RYFiXJvMEjjonWXRgkuYZgE+cBxmiZBnFc2Rul+lBWliXhcF8YXHGQRZVk+ZBqt4bxvk6YRYHE2q OGSbJtFEXZfk6XRdkUVxZG5WaPmwbRxl+jRhmOZpXluXximgXjfF6ZJiFQZhmFiXpnlkaZrGcWhi u9F0M0WxL17LJIWaIT4uxeDbHKOYYg1RribFuLoTQvBZiRFkLRCI7R9HtdUwYVYtBjjdG+OAWAth dicFGK8SIqxTC0GeLwYQyRTDMGyLwaI1heCxGMI8aY4RaFKHyPkWQvRcjUTcVAcwrxiC5G+OkdAm BcC2Fu/UQIpRXhnE0I8TouxdC4GiM4TYuRejFepGAaAsxiDUHkcJNBrUQuJjkRwYI1xwDIGwOMUg txnihFSNAUItBqH7H2MkZI4RMiiGCMQZA0hrjSGepAeJHB6D1HqLUYowxiDWGGOcd45RnDhGePEe Q6RbjTF0LkaAvhUDHFnDgXorRgivGWNIXxUR2DBGANAbI6B1EcHAd0UguRpDJGYOIUgthrOEHyR9 ro7xWiuGALkV4yhfEtFMLMYYrRai/FILtoL7hxjtHK98bYrlnC4mKLgZ4wBpjgGiR8ccDZLD2jaP QaRgBwy+GqN4dJ7HDkcRaP0bhyxwDcHBQccA1hnltFoMkaQ2xyDOGqNQ7ZqB7jwoQMdBKiiFmgH3 A+Rg1hgDpHcOeJgs2CjtGsNQYI3RzDnFcNQaYnRfjLF4M9N0P3fDbGK3kZg5h2CjiOOcdA8RpDLG 4cVK0c1VIgH8PUd6KzXGiVAPFFRoh2lVFqhUdTPSrmiRSPw4I9jRVnLmg0e1VTyDsKQPOtA/h9mp HuO8e6KU6QHLnVU0VWDjIhRMqAfyuB80mHpYcfViB5DyHyiauquGHsToGiEeI9WCoNHadBJtTR/s FHhB0fDiFSj9Y/ZysNca0JzHlZkezgWND2tei5Fyc0WWzHmPke9qC51jrHXEdy7xwRtVIPgao2h4 DuHWPmuNTlVD5RsMAVYux8HCOwOgaozxnDuuQPAvg4hxDhFuMQYZI61qhIXPYfQ4BmjuHKNseAtB XjNHodwjkQx7DNGKKsdo6xsjTGMLEdg5hts9HVTAZg7R3jpI4o1bo7B3jvYHQM9iY5Ki3FyLIvo4 7ZSEtme0fchEQpfPbbMj48h2PfG4NIeY6B2D4SHdMeAzRlCwNvR4f5nx9jpHZg5Zg9EhMtHaNob4 3RZC1FkPNbhoh1jhHeOcaI7B0jVyaModo8xzsjsOPYYAtRejoG0WwZEghlC7GaMsVY0xli0GiMYU Q3hwDEHgPMctlRzkcLWOp+YsRvDFGiOUdI58fD0HIt0qVqxzDdhQK9x42h0DUrcOdNDFh64tR5Xm 5hHmID4FeKUWI8ETDAFkMAW4qBaC1E0KwZAoRZC8EyKcUIihHDGGGM9FjASFjJGeNMSokxXi6FkM sVIqBhoaOkvJXQuhQi+JGO0ZYroRC3FiLYUgoJvCsTcNJZRrBXikFmLYUYshfimF8M9xwpRFitFy JR7ohBIC5FUKkaI0RqCYFoK0X4zBlimFwLgWQvpdjUG2K8XYxxxDsHagyIYvhVDEFEHoSgvRKimG TNwXwrRU8VE6r8b5HBumGFsKwXItxT4WFMLcXgnxYjNF6MoYAsBcMQrMXMVm6BVzSEkJQVgsRVDC F4LkjZCx3s+FCLAXI7TxC1ErqASIvxbidFUK0PgjRZiJEYLsVQoRbCnFGPIeGdSFjmHCOUWYlBTy oGQKsTwqxsmAGc/WpI0RjijFgLsVgqBaivFgJcUYrBVbgFSKsXorppHYKtpcj0hNZjQGaNsbA1hs jhdsNQZwzRri+FkM/XwyRZijF9Qwb6LNLT9HFNIZ41BvDiF2NEZRTxy0CRaNQaFMBuDvGLDgZj7R lDCGUNAY40R1G2kpbAWgwCdDEGIKG6IrRVDKEoIwWoohMi9i2+sWAy8yjXFMKje4zRqiuMqOodfX TyCreCNa77AjPjTGONKHYzRfi1GWMAXAxBgCzGML9++UBzEcoQOR0YYgUwWAXgXQYYZQYyYgcwcg dL7gawdhZg0QbAbYcAX5apCoaoZga4bwaAbQcBZQe4e4WwZAYobYaoczNAb51DsQWAYoaqiL+QYi FwWTC4Wwc4c6Awf5ugdgXwYwaIwYcz3qeIhYbgbBYQagcYbYa4cIYQYoZoaAZ4a4Xo84ZAaYbZ1o ZoUYUIXoc42jwyOSqBjQ/ZMBdRHg0IukLq+qDqDqkCgIjw0RGxGqDrB4eocAbwd674eBvweI2ZkJ GRFQfgdS4KqQe4eIdKu5GZNAfIdBQhBy0IkJOY9g4sSBdQpYfBEBw65wfAaIXQb5awcsNRDIfRLs M5Oo4w9pFhNQfBJT8JIYeBtigREKgDDYz6gRGbSpRZ1AaoWoUoVgo4pMLpOYcAcgcgbQbodEBIeI c4coeZbofDOIfhNLSxgRFgbwdocg1IfCuyxjD5jod5Sw2rQQZSX8UcccckL0WBGBGjW0csdcdhDi IcD5BsUTS49gfISYVgTYQYTITgP4QQS4V4UIYQVwRgZYTwQ4YQXwXAbQbYaAb4X4Wg84ZgbQWQYo ZjxYboSwXIWoVoYgYwVoYYaATCAYWYZIYwWQXYXsdslMlUlclklslyj5QIXjIgWobIVh34Xjs4bI agV4cQYwUwbhFQfYaQXYcAYwVIaoYQUwaYTwUwaQZQZYdIV4WQboUIVgaYUQXIbgRQWwaYWIZwbg aMFEl8scsksss0s40Q1zEK2jWo0AfoeJHIuZsgdhXwdB78uwvpjSuYeAfa+YfQ2YeIUDogaAoaSy Zss8xExMxUxcxhP65wfS44eSgcxsykysy0y8zEzMzUzczkzsz0z80E0M0U0c0k0s00081E1M1U1c 1k1s10182E2M2U2c2k2s20283E3MlQgICmVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKODQxMApl bmRvYmoKMTQgMCBvYmoKPDwKL0xlbmd0aCAxNSAwIFIKPj4Kc3RyZWFtCv///+GjAVtJICUSULag a7DgbdO2Q2Frgjm4rGiMEuc+hk0fKk57c26ghr9XJioIB5jbvts9KV524grfbx3GraMTzM5iR0HQ 58ePP+66R/VTIrMuX92N1sCYtS+1fNxZkKgn8vBpwtgxUhcfDV4VYIDIj+CmHLZmtWyWauhyxHkb 62sLVS7khoH7pY5auu/bg367KZtxkFDdJrvGmH8/tGurwMDZpEZaoOvp+qbY1SlXkVPyA+ND4An+ p6J95lbpkRapa7vvxlvbr1aCiCyr373/0sDiFaHsFEiOkS/lesD7JCu3FPET76FpciqVHglTHdwT //G16wX9epcsXxLtWzcZEksKJTusjq3WJMvgd+i8i+iuQNO0Pk1Maq1fWAiWcRrhfEAcKc/K//OW 4Gt+nfZnTDc7AHWJTeA2rDg+QqpZJCaaQU9pC09doS/IIM2/iBn2wxlrTGdMgxOEwVUuG3pVtbul H8f0fGkkRIryBBIL+tUlZiKMsqWfNmf1ZYJwuzgrYFfyVdNcehjmbBz4eBbOnXzwKi+VyWb9v8t/ MIe3W+cPTj3iqrf7kCQXiZwuVzqrSGTa3i5A2+0MWx6TE3l6Isi4BXNwAAOUF40xRuVr8S3Pywv9 DOfrGEIJq1WDJndL3ny+Tn3C45RQFNo1gMxiT5duTaNVObyXQmfsxY1kEWzh0Ltekp/z4rTOGDSa eoQy6dHWPgqS1k35wxOHJyX0CfWwZ4hPW2sDKYM4xP689ueOzCaZXvzmWL/64Ocf1fAUhVic1bMH 2N2KEKGJzZdwW2SW9MKT2xtS1fw59NEpCFeCpSw1rAUSNxazwONLMT6vxzNyWg6OreSK59hcEeCz k4bgyDLl22r7jyre2lsdiSNR+35giSxEFBMccCT9JLeDBIC26lsg5epKxMSm4k7KM0pJk9R11+iJ 9Fmt8X1ldYLlK2xBS1EslhbxPfg/CCuKUb5ex5ZGUIqf/nwdY/GfSR0Limhdtv9zqDxs6EWXcpZW 0F7sF653t6zz1BDldAplbmRzdHJlYW0KZW5kb2JqCjE1IDAgb2JqCjc2OAplbmRvYmoKeHJlZgow IDE2CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAwMDAxMCAwMDAwMCBuIAowMDAwMDAwMTg1IDAw MDAwIG4gCjAwMDAwMDAyMzQgMDAwMDAgbiAKMDAwMDAwMDI5MyAwMDAwMCBuIAowMDAwMDAwNDk3 IDAwMDAwIG4gCjAwMDAwMDA1ODAgMDAwMDAgbiAKMDAwMDAwMDU5OCAwMDAwMCBuIAowMDAwMDAw NjM2IDAwMDAwIG4gCjAwMDAwMDA3NDQgMDAwMDAgbiAKMDAwMDAwODEwNSAwMDAwMCBuIAowMDAw MDA4MTI2IDAwMDAwIG4gCjAwMDAwMDgxNzcgMDAwMDAgbiAKMDAwMDAxNjcyNiAwMDAwMCBuIAow MDAwMDE2NzQ3IDAwMDAwIG4gCjAwMDAwMTc1NzAgMDAwMDAgbiAKdHJhaWxlcgo8PAovU2l6ZSAx NgovSW5mbyAxIDAgUgovUm9vdCAyIDAgUgo+PgpzdGFydHhyZWYKMTc1OTAKJSVFT0YK --------------080501010408010304020000-- From simple-bounces@ietf.org Fri Jul 06 15:59:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6txd-0008WN-MM; Fri, 06 Jul 2007 15:59:26 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I6txb-0008JJ-P0 for simple-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 15:59:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6txb-0008Bp-50; Fri, 06 Jul 2007 15:59:23 -0400 Received: from mail-out.sbs.be ([193.109.72.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6txa-00086A-9H; Fri, 06 Jul 2007 15:59:23 -0400 Received: from bruc002x.sbs.be (bruc002x.sbs.be [193.210.175.98]) by mail-out.sbs.be (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l66JwNqp010085; Fri, 6 Jul 2007 21:58:24 +0200 Received: from bru0032a.ww018.siemens.net (bru0032a.ww018.siemens.net [193.210.175.90]) by bruc002x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l66JwRx7006919; Fri, 6 Jul 2007 21:58:27 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0032a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Jul 2007 21:58:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLEinto P2Ptorealize presence and IM services? Date: Fri, 6 Jul 2007 21:57:40 +0200 Message-ID: <67043E463DDBFD4A8087ED940BFF756B01822DE1@BRU0038A.ww018.siemens.net> In-Reply-To: <20070706023042.8A1CDDEC34@mail.orgltd.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLEinto P2Ptorealize presence and IM services? Thread-Index: Ace/UZ7AQfYYjpdXQUm1M48mOqxEOwAKVXaQACEbomA= From: "Willekens, Marc" To: "ext Vikas Tandon" X-OriginalArrivalTime: 06 Jul 2007 19:58:23.0792 (UTC) FILETIME=[02857300:01C7C008] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: p2psip@ietf.org, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org It's good to see the evolution of the consensus around p2p and that it's not the Holy Grail which will solve everything. "A one size fits all" approach will not work in the "real world". The SIP/SIMPLE certainly has to be considered in a p2p environment, but not as the only and only one solution but as part of different deployment models such as: 1. Large ISP model with a world coverage (ca. 10.000.000 users) 2. Medium Operator Model which is mostly still country related (ca. 1000.000 users) 3. Small Community model (ca. 100.000 users) 4. Tiny Personality model (ca. 100 users) These different deployment models have their own advantages and disadvantages. For the large, medium and small model, a "central presence server" is mostly provided which can make use of mass of scale advantages and certain traffic optimization techniques such as an RLS. This is the point of view from the clients making use of the presence system. The central server can make use of clustering, load balancing and p2p distributed concepts. The '"trust" is completely provided (or not provided) in the "closed domain". In case something is wrong, you know where to go to with your complaints. In the "Tiny Personality Model", each end-device or an own more reliable computing resource provides its own presence server for the own presentity and subscriptions from watchers are handled by the functionality provided by the end-ueser resource. Each client owns and controls its own server. In this model, there is a "peer-to-peer" relationship but a p2p protocol is not used to distribute the presence data over different peers to avoid the problems with trust and reliability as indicated already by Jonathan. However, this system combined with the p2pSIP gives an end-user the ability to build up its own network without the need of being dependent on an ISP, Network operator or an Enterprise. This certainly has advantages in different use cases, e.g. for ad-hoc kind of networking, a small virtual team with worldwide members, etc... A requirement for the end-device is the ability to be part of the different deployments in parallel with a uniform user experience and interface. That's why open standards are needed! Much of the inter-domain scaling problems can then be avoided because the different domain acceses are handled by the end-devices. Br, Marc. -----Original Message----- From: ext Vikas Tandon [mailto:vikas.tandon@orgltd.com] Sent: vrijdag 6 juli 2007 5:25 To: 'Jonathan Rosenberg'; 'Henry Sinnreich' Cc: simple@ietf.org; p2psip@ietf.org Subject: RE: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLEinto P2Ptorealize presence and IM services? A significant aspect of P2P vs Client/Server(CSP) is the ability to use Presence as a service in the network and other services like presence based call routing. Under this aspect e, a Client Server Model plays a significant role. Some other considerations are: 1. Looking at the memory and processing requirements in P2P mode, the client needs to process more information (e.g. keep track of every buddy's client capabilities, service capability etc.). 2. Another aspect of P2P is the offline messages for which you'd need some kind of server which monitors presence/online status of message inbox. 3. Also in context of wireless devices, it makes more sense to have a CSP model since coverage and connectivity are a practical issue today (e.g. in a 2.5G network, I'm supposed to receive an IM from a buddy but I'm on a voice call and the message is not delivered to me because my GPRS is suspended due to voice call - who will store and retransmit the message to me the moment I'm available again?) I'd think of a combination of P2P and CSP model providing more value as opposed to a single protocol. regards, Vikas -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Friday, July 06, 2007 4:37 AM To: Henry Sinnreich Cc: Song Yongchao; Beck01, Wolfgang; vikas.tandon@orgltd.com; p2psip@ietf.org; simple@ietf.org Subject: Re: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Ptorealize presence and IM services? There are definitely a lot of questions to be addressed in making SIMPLE work in a p2p system. One the question of RLS services, I would tend to think that they are not needed in a p2p system. The whole premise of RLS services is that the server has access to a much richer set of bandwidth and processing resources. So, let it do the 'fan-out' work of processing the buddy list and managing the dialogs. In a p2p model, the 'server' would be just another client on the ring. SO there is no reason to expect that it is any better suited to perform the task. MOst of the issues, I think, are really around security and authorization. Part of a presence server's role is to perform privacy processing - to limit who can subscribe and to limit what data they can see. In a client/server system, the presence server can perform this role since the client trusts its server to do so. In a p2p system, would you trust some other node in the network to execute your privacy preferences? I think not. So, rather, I think that, while online, a user's own user agent would have to supply the presence for the user. While offline, they would store a presence document that all would have access to, which indicates some limited form of offline access. Thus, a user is their own presence server. That eliminates the need for tools like XCAP and presence authorization policy documents, since know the user and their presence server are colocated. As always, multiple devices are a challenge.... -Jonathan R. Henry Sinnreich wrote: > Can anyone share a comparison for presence using P2P vs. using SIMPLE > client-server? > > At first glance it looks obvious that P2P SIMPLE is the answer, but an > analysis would be of great help. > > Thanks, Henry > > -----Original Message----- From: Song Yongchao > [mailto:melodysong@huawei.com] Sent: Wednesday, July 04, 2007 7:51 PM > To: 'Beck01, Wolfgang' Cc: vikas.tandon@orgltd.com; p2psip@ietf.org; > simple@ietf.org Subject: RE: [P2PSIP] RE: [Simple] Do we need to > introduce SIMPLE into P2Ptorealize presence and IM services? > > I agree with that. The draft > http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain- > scaling-analysis-00.txt has shown the complexity and the load that the > presence server has to handle in order to provide its service. > Self-organization infrastructure may help with the scalability of C/S > presence by utilizing the processing resource of the end users. > Using an application layer multicast and uri list message should be a > good choice. > > Sure, there are many questions to be considered, including offline > messages, churn of the p2p network, the presentity's policies, the > durability and availability of the presence information in P2P network > and security considerations. > > > > Best Regards! Song Yongchao > > -----Original Message----- From: Beck01, Wolfgang > [mailto:BeckW@t-systems.com] Sent: 2007$BG/(J7$B7n(J2$BF|(J 19:25 To: > vikas.tandon@orgltd.com; melodysong@huawei.com; simple@ietf.org Cc: > p2psip@ietf.org Subject: AW: [P2PSIP] RE: [Simple] Do we need to > introduce SIMPLE into P2P torealize presence and IM services? > > Presence scalability is an issue even with C/S SIP. The real > difficulty with NOTIFY is that different watchers may see different > presence documents, due to the presentity's policies. Off-line > presence brings further complications. > > Some random thoughts: > > If a group of watchers receives the same presence document, an > application layer multicast may distribute the load between devices. > Could draft-ietf-sip-uri-list-message be abused for this purpose? A > peer receiving a NOTIFY with a recipient-list forwards it to some > contacts mentioned there (removing those contacts from the > recipient-list before sending). Possible, but I don't want to write > the Security Considerations section.. > > Offline presence can be done by storing a user's presence document > like a file in P2P file sharing networks. To meet the presentity's > policy, we would need some elaborate encryption scheme, so that > watchers can only those parts they are allowed to see. Multiple > versions of the presence document might be necessary, one for every > watcher/presentity pair. > > > Wolfgang > > > > > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow 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 bhchokeberry@fastmail.us Sat Jul 07 19:02:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7JIf-0003vQ-2O for simple-archive@lists.ietf.org; Sat, 07 Jul 2007 19:02:49 -0400 Received: from s01060004764c2050.ca.shawcable.net ([70.77.51.192] helo=laptop.ca.shawcable.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I7JIb-00053E-A3 for simple-archive@lists.ietf.org; Sat, 07 Jul 2007 19:02:49 -0400 Message-ID: <001c01c7c0b0$3f43bf10$000ce1dc@laptop> From: "Ashley Quintana" To: "simple-archive" Subject: Thanks, we accepted your refinance appication Date: Sat, 7 Jul 2007 16:00:45 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C7C0B0.3F43BF10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1081 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0000 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 ------=_NextPart_000_0019_01C7C0B0.3F43BF10 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Your credit history does not matter to us! If your family OWN real estate and want IMMEDIATE pocket money to spend = ANY way you like, or simply wish to LOWER your monthly payments by a = third or more, here is the deal we can offer you TONIGHT (hurry, this = lot will expire TODAY): $316,000+ loan AND EVEN MORE: After further review, our lenders have set the lowest = current payments! Hurry, when best deal is gone, it is gone. Simply fill in this quick = form... Don't worry about approval, your credit history will not disqualify you! http://nothealthh.com/ ------=_NextPart_000_0019_01C7C0B0.3F43BF10 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
Your credit score = doesn't matter to us!
 
If your family OWN real = estate and want IMMEDIATE cash to spend ANY way you like, or simply wish = to LOWER your monthly payments by a third or more, here is the deal we = can offer you THIS EVENING (hurry, this offer will expire = TODAY):
 
$366,000+ = debt
 
AND EVEN MORE: After = further review, our lenders have set the lowest payments!
 
Hurry, when the deal is = gone, it is gone. Simply fill in this simplified form... =
 
Do not worry about = approval, your credit score will not disqualify you!
 
------=_NextPart_000_0019_01C7C0B0.3F43BF10-- From simple-bounces@ietf.org Mon Jul 09 00:10:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7kZb-0005LX-IG; Mon, 09 Jul 2007 00:10:07 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I7kZX-0005KO-8q for simple-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 00:10:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7kZW-0005KA-PV; Mon, 09 Jul 2007 00:10:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7kZW-00029A-Ey; Mon, 09 Jul 2007 00:10:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 55D5226E60; Mon, 9 Jul 2007 04:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7kZW-00048i-7C; Mon, 09 Jul 2007 00:10:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 09 Jul 2007 00:10:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-presence-rules-10.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: , 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 : Presence Authorization Rules Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-rules-10.txt Pages : 30 Date : 2007-07-08 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-10.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-presence-rules-10.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-10.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: <2007-07-09000329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-rules-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-rules-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-07-09000329.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From yvvsj@nnsi.net Mon Jul 09 10:24:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7u9u-0007wk-QE for simple-archive@lists.ietf.org; Mon, 09 Jul 2007 10:24:14 -0400 Received: from [85.104.206.52] (helo=dsl85-104-52788.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I7u9p-0000Wr-Ff for simple-archive@lists.ietf.org; Mon, 09 Jul 2007 10:24:14 -0400 Received: (qmail 18234 invoked from network); Mon, 9 Jul 2007 17:24:06 +0300 Received: from unknown (HELO jfilu) (146.159.217.204) by dsl85-104-52788.ttnet.net.tr with SMTP; Mon, 9 Jul 2007 17:24:06 +0300 Message-ID: <46924506.3070606@nnsi.net> Date: Mon, 9 Jul 2007 17:24:06 +0300 From: Montgomery G. Christian User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: butte Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c VPSN WILL MOVE LIKE A COMET AND ITS ONLY GOING TO GET BETTER! Watch this SUPERNOVA closely MONDAY! VISION AIRSHIPS INC Symbol: VPSN Price: $0.021 BANGKOK, THAILAND, July 2007 Advertising Agencies Ready to Ink Deals! The company wishes to announce that it is in final negotiations for representation with some of the world's largest advertising agencies to market and reserve the blimps for there clients. VPSN THE RISING STAR, IS SET FOR SUPERNOVA STATUS ON MONDAY! The new project is called Sailfin, and this is leading-edge stuff for the telco market. Both Dietzen and Crupi punctuated their talks with some snazzy demos that seemlessly mashed up a variety of services into a front end interface. Crupi took more of an enterprise view of things. Now I want to use jMaki with Ajax. Crupi took more of an enterprise view of things. Choose the approach or combination of approaches that best fits the functional requirements of your web application and with which you're most comfortable. Also in this episode, the Geek Gadget Guru fires up Havoc Heli, the AirHogs remote-controlled helicopter from Spin Master. "If you want to work in a carrier environment, you have to support Java," says Eliraz. He is executive producer and presenter of "Power Panels with Jeremy Geelan" on SYS-CON. The GlassFish ecosystem is growing fast. Ajax-Enabled JavaServer Faces Components Create web applications with Ajax-enabled JavaServer Faces components. Only one guy admitted to that. Update the internal representation of the page with the new data. Deliver rich experiences. Deliver rich experiences. Lyon says that his company develops almost exclusively in Java ME. "By that time, pretty much everyone is hung over" he said. The event is free, but space is limited so register today. Garret underscored that what makes the iPod a success is its simplicity and attention to the user's experience. " The second was a developer session given by John Crupi titled "Ajax: Putting a Face on SOA. Reproduction in whole or in part in any form or medium without express written permission of SYS-CON Publications, Inc. Prototype is another popular source for JavaScript functions that can simplify the Ajax-enabling code in a web page. One of the biggest moments at JavaOne was the announcement of JavaFX, which dramatically opens the landscape for Java developers. While Ditezen's theme was essentially how to enrich the user exerience with mashups. We also optimize the page parsing and load the Dojo widgets programatically which can be useful. I have done a visual web pack tutorial and like the look and feel of the components. First up is Sun's Don Kretsch, Sr. Visual Web PackDrag and drop components to visually construct web applications. Kuldip also interviews Derek Lyon of mSpot, a company that delivers streaming entertainment in the mobile space. BD-J enables an amazing new level of interactivity for the viewer, including in-movie experiences, games, and even networking. The servlet handles the request and returns the data for the autocompletion, for example, a list of states that begin with the characters that the user entered. Director of Developer Tools. Sun Studio has extended the power and flexibility of NetBeans by adding several powerful tools such as the dbx debugger and code assistance capabilities, including code completion and folding. Or you might need to supplement another approach with some JavaScript coding. you had a blog post somewhere about PHP and jMAki widgets. The documentation page also includes important blog entries, webinars, and other types of content you may find useful. You can also find a description of this example in the document "Auto-Completion With Ajax: Design Details" in the Java Blueprints Solutions Catalog. Vringo announced their first Java application for video ringtone sharing at JavaOne. To learn how, see the blog entry "Giving jMaki a Whirl". - feature story by Leslie T. Check out SDN's new online community where developers can share technical content related to Sun technologies and products. He explains why his company is focusing on the Blu-ray platform, and what that means for developers. If you don't find components or widgets that provide the Ajax functionality you need, you'll need to do the JavaScript coding yourself. Really what do you think about it? About Jeremy GeelanJeremy Geelan is Sr. We also optimize the page parsing and load the Dojo widgets programatically which can be useful. He has written about Solaris and Java technologies for longer than he likes to admit, composing everything from man pages to technical white papers. Without a doubt, the open sourcing of Java is one of the most exciting developments in the history of the platform. Web applications are moving away from the page metaphor to an interactive application model. I understand that some folks have gotten confused by exactly what GlassFish is and how it compares to the Sun Java System Application Server, so it was good to hear Padir's explanation. And because Sun opens Solaris source code via the OpenSolaris Project, everyone can benefit from the work and insight of creative, committed Solaris developers. Check out SDN's new online community where developers can share technical content related to Sun technologies and products. Prototype is another popular source for JavaScript functions that can simplify the Ajax-enabling code in a web page. In still other approaches, you do most or all of the JavaScript coding. I have done a visual web pack tutorial and like the look and feel of the components. The appropriate tag library references are added to the source code for the page, and the custom tags for the widgets are added at the point of the drop. Did you know the Blu-ray platform has a full-featured Java development environment? us and Rico are built on top of Prototype. The parameter true indicates that the communication will be asynchronous. From shyvt@newnet.co.uk Mon Jul 09 14:58:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yQr-0008Gz-F8 for simple-archive@lists.ietf.org; Mon, 09 Jul 2007 14:58:01 -0400 Received: from [85.104.21.109] (helo=dsl85-104-5485.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I7yQl-0001eO-K8 for simple-archive@lists.ietf.org; Mon, 09 Jul 2007 14:58:01 -0400 Received: (qmail 7690 invoked from network); Mon, 9 Jul 2007 21:57:50 +0300 Received: from unknown (HELO vxd) (66.79.164.25) by dsl85-104-5485.ttnet.net.tr with SMTP; Mon, 9 Jul 2007 21:57:50 +0300 Message-ID: <4692852E.7010206@newnet.co.uk> Date: Mon, 9 Jul 2007 21:57:50 +0300 From: Matthew Cain User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: Re: Notification-307288.pdf Content-Type: multipart/mixed; boundary="------------070203080702010408010600" X-Spam-Score: 1.7 (+) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 --------------070203080702010408010600 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit --------------070203080702010408010600 Content-Type: application/pdf; name="Notification-307288.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Notification-307288.pdf" JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cK L1BhZ2VzIDMgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbIDQg MCBSIF0KL0NvdW50IDEKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzIDw8Ci9Gb250IDw8IC9GMCA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0w IDkgMCBSID4+Ci9Qcm9jU2V0IDcgMCBSID4+Ci9NZWRpYUJveCBbMCAwIDc5MCAzMDJdCi9Dcm9w Qm94IFswIDAgNzkwIDMwMl0KL0NvbnRlbnRzIDUgMCBSCi9UaHVtYiAxMiAwIFIKPj4KZW5kb2Jq CjUgMCBvYmoKPDwKL0xlbmd0aCA2IDAgUgo+PgpzdHJlYW0KcQo3OTAgMCAwIDMwMiAwIDAgY20K L0ltMCBEbwpRCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozMQplbmRvYmoKNyAwIG9iagpbIC9Q REYgL1RleHQgL0ltYWdlSSBdCmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovTmFtZSAvRjAKL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIC9NYWNSb21h bkVuY29kaW5nCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovTmFtZSAvSW0wCi9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDc5MAovSGVpZ2h0 IDMwMgovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEwIDAg Ugo+PgpzdHJlYW0KgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUrlktl0vmExmUzmk1m03nE5nU7nk9n0/oFBoVDolFo1HpFJpVLplNp1PqFRqVTqlVq1XrFZr Vbrldr1fsFhsVjslls1ntFptVrtltt1vuFxuVzul1u13vF5vV7vl9lDwg5/gbwc6Sw0OwEEKEhKU KSVFxd+yVnwyxKGXyIAc7neGdzsPwySy2IM+YKWCreJjeqsDSzMCZmq0KxaJng5nz8C3MC1EK20G 3+e3e8hTRmOuy5/5UN18Fz2upbngu/ABQzbn3GqzvIKG9hnNkHZ4cO2nUyeKzcQ2PD8uYzPiz2g9 uv7HCxPc5W9wmz40p1iBvAhD+ocaSLOk5yGwOqjmtYx6Bg1BjhIE0qCO8hANIOxLPQoghmIVDCJQ s8zsRAgcFIIxLLtOP5mBGhrzOc0rLoJFyCwcDUICgM70og/6GwkgkVoMw6BRxEz6vjCbTOW5kdwQ xUOhG8aFvsxUVxbH0SQgh4oNO6cvuqhEfAAxqHMvJznPG5UsIHB0HunJKGHhHbQxOAEdvqh0pTmw qBxhDKJRPHTBvs/8LM1OozxLPDxMHGUAs0h8x0gg0SuYi0/zHIarQs1hYzA3TtIEzCBwKhdLMHKC DU1IqJj/U1EIG2scUs8cOUohU7IM8D/tpIoNTwzkesJYbOw4AD8mk/7RQfEtdINQ6FulOzhtezzC zdH9oOVZTxtrP0zWSgkiVbO8xUNaKD2A67WWNGaB1fONmTfQkgWk/kRwVKdVwbeiFVYhMYX0hd0g BAcjyrUbMSZG1JMCgVu2IglFRxNEUXdUdkXih7OXsxbk4LTkPIFPtwQfE9J2RVNT2o1kA4BVDENl B1FZPFCCszkOAoWHyDRPb9yoo6VsyplzeP1n+a1plaFZ1nwAP+eFYZVpl5sQhNNZihgfP02VP3pZ +IILp1f5vUMAZ7s1ZPNErh4Ag2DxNJ9/oTrSC6mh1LOxpkxbq4CEte2KDa/H90agztsWzWgNR5er kaO9eJTlhLqihrkWWXXyrNkgvFyNi9DAAZlTT+g8Dw0gsyoLsOgx7JzDQPVGUZwgeRojt9Dzdmt/ Imx+ibog/bIFxQAQx42+IRvFpMBat39EgkT93S6EdL4vPodC0FRJsHAMz0e853CvV876+2otrWoo Z1laY7H1cQv9l2ypv25oN1Tdb/LiBTLkb/10+hMb302o9fsd5/z0nQL7KI5wgjnkMoyXg2d36gGo P4fEpt+hEWhgAU+b9VC7TVHdXq4lbRCnlM0VQ3Yhph2gJyb6uOBr1njqhXcryAkFmMn6hhDFMxCY Jq/euQtvDunir0YActZRD4VHNiG52IrQW3qngoyYxzdUcL2QARJxbblHsMZJBl5EFzdP/IgZE1CD TRQtd5GGHDw4bxii+pVfjlCjmHc1GshDlozwDh+gg+J/3hEDcIup3sHFvogg+3OAwZz+Qlaw3B6y lQNR0IW4SFT9W1ECYPIiKBnjLtpYmsU4bPUWRtkHE8hsoIMRWijBUgklpIxPbeh6VseIsyZg5E5z 75iKvodpJVZqJZLnEIirU7Un01sNQvHMzrznIyMkIQ+UjgmvKzZjL6Kcmo3u1mVE6TEtSemPT/MN DsOHYLaeYmGXCE0PyFifJyXD3noETbfONpb5JKG+cXD1003nWyoijH1Sp9jqRnMA9GfxDGCusnWb dUEiIZtvWMRBtpu0RKgXKkaXiZIvEMmwQN+71Jgy2ILIEhsiWMxVmWmlOaXWup0pW9gACBaDvDRP Ncg6kE7TklDJiCbMYsFKONThq6kW1zoTCp2aNMSINxng8g5bgoBkSbe7+jUKSKMUn3QohDRFLVYj bV2JUv3nxfeJDwhtJoqPAIXV5f1EX1TFUIzmbs/5hUAXhKWsaq2x0en9OScDvKLELbjWiNkFlyUJ IZLRSKDpN1EbGtGtz+pMWFlQ6B5xSZ72GWgoSNyzXCm2cvXWYNW1frulVGCd8mHnq9ImaVy6LbSS oiDTypc/yELplPV+fz72DV7gjOZq1l4gvzqZWiScK6/0jldSq4BApQI1qnGuYT10GUUgevCtT5Lk RXpbXyYqtDhs6hUzF6oAE3RqpIuc2xlYgWmWbRN2qe5oS5s4wRFiUrPy2kvaMpbWpLrxN3ZM79wW SGzfJA4gYew9mlSFX6Hj18G18P/VqzZCkV4CTaaKBFX0Sh7IpWCIS/U73Vs5iBo+AkfW2wY2NUyn m2WgcKfu28DUcYtIaLE6j5cbTsraRHHExHDptt3QnIMXrAt2wy8p+FpgNYMwcoehj8MoN3WvYmy9 ikyQ+vvlmuJApBz7a1g1LqaVsY+vW8lJOBL7owyYVlxBGZQRoPKSTEWN8gooZLaXC5Ezy21u4ADB keq9KnhTTw/d7r34iIFihZDkc95pIJo5sy2cO4KTlCSOSF880evhV/FGhD1yQyBqJcZlbH2bUtnn SFAtNmBqk3nPp/tE3DilZHSEgse5ax/mgpTMdRQKPOSXRmDNKWzJOzHFGDFkytwAQ5OuCSb5svgR i20SriqoxRs1OeryILiRs3vG2qiC7HT5q7bxZ8BUw19l7a5XFubC2HvPem9d7b33xvnfW+9+b939 v/gHAeBcD4JwXg3B99bGlxY4aKs5JOL2Xgw8bRLz24ubWEjCceEcb45x0nuxsgrLk1hbBOT8cB7j oJKm+0tG7mNYGcQG6Fh8VI1w3mhI9zL14ru+w/Hufc/KJyF5B/W2W8mybvhthtMc5IIIC35HenEj 4cRo5uh9V6UO0nMQAULLYXo/xjoHYexcfherKu2XeLgA6iwZ6WJuW6NkwYuyxC+JL7UhrPkHLnq8 8IV1zGWi8F9Yip36OXV00kF7X2PxXiyb8oR94m1ff9BdlAAMgzMM7ablbP5thUsSHeO41LfkvV+6 na5h5bGuXu0057d57k5uzVDI13DHbVrLfeM9x7kkxmHZkEVMH8KRmPZGKPcu8zajVSsapT2qshmV qYGO/b59xmRAdrOaZHcWQ3UkG62zj6Q0jBfA+pL9j7cqwoWCh7L6vxEAK6sD7r+H8SN/Hqgwr9Pk HKnuN+fCvrlfKiBvhvRDqGojSqOu+kXldvmlSIEvQp1KyPlwDjBPyiBPIDIjFk0FRI4PmQIP/GLK Gv5QQQQiOwMrglcFIENHQmMvrKyD0jhourMwDsCvEQHkznGqCDwEAnnFBsClSQVlVDflhQSQOBAP LQYFzGwubwRQlQlmHKwjIwAqcuympFVO1P1wOFrO0vriHMpwOQNvRHoDcOwQZwoo4mtqUwfJbmBj VG8DXutvinVvswHwmQ5w6CEl9IQmcjIv8QqH6jXjXvUQOHZj/jmw9nTQuFDxAP/N2wUCFxCkZnGm CCCwAjmwgF6wvrMwtLWQvw6xOROpKDuluCBxCmSPjkkmXDewoQdPnGUFqkLQrHJqgjeBpQoP8rMx Sk4j3QDFKDriHw2RNnTmLvRRZw5IbLcxOxjxjwGtHmjQ7D4D7v+wvQIEdP6JMFovboaQpl+P8QFw GGcLYldwjEJpwRBkAPnDgvfGcnMB4PEwYQPPVvoRkR4x5CYDNv3ijxuRNHwwvlgwhQHHRkpkAvnn kx5yCSCuAN5JVxAwwiSx7SDSHSHi+RYyISJyKSKoaSLSMSMyNSNyOSOyPSPyQSQyRSRySSSyTSTy USUyVSVyWSWyXSXyYSYyZSZyaSaybSbycScydSdyeSeyfSfygSgyhShyiSiyjSjykSkylSlymSmy nSnyoSoypSpyqSqyrSrysSsytStyuSjuvOTNjigONEYOisLu8yuy0C7ywrmwiwYOluQIHv8NGCOt MRuiBRaMPSzNjF9wiy0y/C0QYQbIsPgxRQ5ETPkK8w+MvjnPwIvBkPqw3PvPzO0xEQExyqWSERyx uLrjBzGy/zPifxKLwTFTDE7uskKpVRRjgSADlAfQ2v2RNv6wxzFRWK1u+j3Ejm1QCg/zXTQTfCdT OTSAoRXzSsKviPxmrlNDwRaD6RIQnCDRaQHDNPeiJjmlhGVxMTfztCbTBTLPETIziwaP/wupHzlT vRFE/ONDuTXQcRwDrkYDtzqqWTsTtz6icmBn7HuzRTRxpQqzyEMnmHSwcQ30AQ8EVwjDwR+KckVC Iz4LmjIqQz7UJCYR+shI8nxz+GqQKPOxroQiDxtzcK2RCTzwymmwDFco/EU0LUJ0WCWjPl9rtxNn Sm8DvQV0OjuUPzLQdnAR4Rtn8pHQEGzEZm00Y0W0jSGFzJsvlwYGUvfQqR8GAkllDz2xSG5pnTDR i0gIXKesto90j0vj/TpJ1v9S7EAGuw+Rw0SKTUEpcB4UQznxyk8QPshHJUtR0n+0wU8vdwjE5jQv vT4RYr8jxw/QkzgzYzaviLUxyEAFGU5gAL6OZJ4kaDErExr09VLiH0IlENFCLwGzrCGEvM9JBU3q jOeiSMaFJGMULMBjLUoVMVXlOCDndVSCjjtnnELNLVXVYVd1eVe1fVf1gVg1hVh1iViyaxlCJuv1 jVli6Uil/zMtZPDlRxv1mVqioOVQkrjCKSGrjjWE1lul1NAVHVrVyCWM/u+R8qiiEQuLOVvHoKvM nFa1y15iYoWqnu0IYI0smqHMuNsE/DXrpL9vPPWx316WDCTMANtMUDGxQjcjKmKOHrist1+iHtHK QkGsw19z/2D2OCQtZvanIMrjHo7ra2CUNCMtHHspGtxo5NHLU2O2YWPSvvAl4HSEDpxKE2QR4CLs WqOlE1wogsQMcGyWY2iiLuvMFm1L0ssujWk1xiJEXITqTsJNG2o2jWriRPDA92AoGLftGWdQxOLH 5kfO5qltHJ02sW0y6NyuUUMVSnjWCMg2213ofu+QG2yiDNHWz1oW1W+qY2JOJuzFWnPNlMGL9EbN bNJV1p+oMuhETVI2/XIrSy1kfHCMdoitZtG2+CQJLywPBMN3JXQm8tOvOXBPMilOFJcV2XRXWIE3 W3Xi71kXYXZ3aXa09XV3bXcivjsld0TiQTVXdXgiWI6Dk00w7TrvvEAwiXhWrjrRqCI1LCP0X0Hj Mv0mOTEP7Teum3jXmV5l2XNzYi/qwqQ3gETTTvRTs3o3u1i1ECV3yl+TKS70N0tFWUfX12YH0nxN RzjmfXsP80LqqHHpuQN0OoLFKX7X72OOXjmx/k5xUzA3iKXRrCKEVIdTx4C0klIRE3w4E1yDhU+U PQHyFxwHa1uRjYLYOLwIzYAKMYO15oa0lUf2CgALYk9iODBLpGiRrkYLJSA4XWDuaMpzqFtmI3cG mmIMBk3U+QyPkkbJTzJ4f1yn3tXDzFWVnUxCGx1D/ja1dFJ0zpXrLEkYTYo1L4p1tGoHqyEVsk0n SkcvKEKksIDkcLMp84yVimdW8QsmQDvHEo74oCI3IMZjgFaR3Y7V6LyYzroE1nMup5DZHZH5IZI5 JZJ5KZK5LZL5MZM5NZN5OZO5PZP5QZQ5RZR5SZS5TZT5UZU5VZV5WZW5XZX5YZY5ZZZ5aZa5bZb5 cZc5dZd5eC5jMY1rKCHMHiM1dQiUB1AEN31ZeuBzwCbxrVaCJwKjFFg5gCGZgRQ5iGQPEVSRpxIY P3uZliyY62TxNkIlqzR0CYsYTPi0d3844PpxuV2WXvux9rPP5qqOqYSzLvOjqwBzlWX5wizqCCDR /4SK1lCxNjcxVRF515fwbTDKaYWUSrctC5+QIX2iMYh4sUk3w4jUHpfyBLO6Ai2GXLrvpp53Sq6Z 7UxPsRg6M0MobGw1DRjRBwdUuWw58TZLSR2v3kFQLMfRgR33faR5xCC1FL0RwD3uej9DzT95/CNP 3ajEYr0IJ0HCFkXRyalHkZqq2aOUV2BQOP3lyafqjHUR34r6iCwDzMkGh4dVS0K4m060xag3wZE6 vZyEFYn1S6cMhtImP6WnkZlJHxNsmYnzuiIFsjIxKpXUVMra0i1mF2fXTIvtxa4H8NIwORz6667b I6K6qM64ZYZpzFVD04qzS1tzFExnSwB5AJBzOVF2n7Hiv4JLZNTnt6UXpvlpkkJszw5QUNujVldk r3Dnh1sY50M4gtowBOLjWVQiM614WuLUXrAuVYW6zKQap7ZC0oDJqqtG1W0QHGN7ipDW3ILNu5wJ t0VlPbo7YVZNUHpQ7xmPlCNjX4+KflzrA4/UqvNljqO6PbtCs1cbJrLuslYajr9ogvsjc8DWiUtw NNLby04KxK0aMJkbPMwEe0cIR0/FKznDdM3iDprIg4Ir/XQcAC0GplyNGaSrtaUa98RmPEO2pXoC DImmynoOsrv6v8XIoaXH97d1+EzUGDpszlnnGUmtZNqwG8gLp8TizHEcOPPEiwhY6coIiPZnD75X Sunoy0MpYTR4YRZMrqjtdzjLsCX70cnN9JGVOPVR+kRcot3RIrSO+WXyyVOljcotntrV0CNJm7Bc 1SO2JCu8+iNMHdAyYdC9EdF9GdG9HYO9FNZXUwl489HiqauXOCSO88GiVdItx9B3FotdJ8+O+dPZ RJydOJ6NbnbiR7eiqNKFXiPWApeiNy6tesgOQdZsQsnotZc3M7YlMdV70iPWR9cS1tDSv9TO6H61 9CLYxnrS4RLdeiIa9CGW93Ea9dbO4Y2MsWxZYvMY3iONa7/qmoZdPDHrC3CNJ9o7L84tFtQdjs4i CcRWK8fOVObWIphjE8jdrSzoabMKTiIpNvP97d7qnd1PNGLnEoyZcdwRLWbrb3MsQF5NUd02Jd/W 6HV+EdzXSCDlfBoqb+NuQjVY+ukvJCD3KNNGDBz9tb8d5bycb93qgbcssdQW81pL0dqiEuclrtSc pCFdZ2bnCeWLOGY+giC90+GkMNOj7OGNA9zeZosWys+u8uJtbVxFad2DineWmtBPSmZ6bpySwukD +y5msepcReuvJwGDVKnd6pcdK+El6jO+a+Y8HLPuG96OS+x9sep5cW9cfOYzbPW+mDVDzY82wR3+ 3MItJiHOSHeNKPQF5Wc+7kJuYhz98dzdWE7vEsLWJXPcfOYcyef6u675quXceXMN3uRO2dbes3SE subc95bdc+4O/nys8emR9Lj2tt5fFl6NKddDb+NuIXP8Q/Ka7Ot+8u2tq0REBph3PfjQIK7wmzC1 8CEdZ4tuWfqpta7+n+1052P5buQE4/tK3oGu8umPU+5e5msrFEQfyNnK/ywecekWc99USWgfHd5+ T91pMiAPAAQOBlCCAANBqEQqDw2HQKDlCDQOEw6LQeIQQzw2NweExWLxaMgAoNGKQyLSgAHs9w+G yaPQ6VSGaTWbTecTmdTueT2fT+gUGhUOiUWjUGWxiCICGyqKyCB0mQx2UzWpQ8z0yZU2G0mWPCwT iZyiWWWrgCwVlkROEVyPWaz2iHRKqwe4xdkR6UR+P3aMSOqQWm1CcPC1RMoXyeSMAXmY4/CTWtSS 2QvFQS4WGG5OT3yZyuj6HRaPSaXTafUanVUHKgBzwTNWhpQ2DY6CXSQ4yDn8pRLW4KIw3dAA/w3b cDfRLXzU/8WDoCtcnfRywbHZ8HacmHcvhNLm7yCsjoIDcTbGc6ClDxZzpeW0RnY7ff+bqwTveicc pz9zz7SlvmkTqviyj1M5AiDN++qCO+3qLQA1cIQjCUJwpCsLNW9wADO+C0ig/DGugubksCuSQok8 UHIa/cNwUhofM2/0CDPFaaxehzHPdB7duMojmh88roLXHSiO07iBwEM7fuPCMZnPDbYIbD72MLFq iSrC8sSzLUty5LstvmwC6Q+AEDPlJrhJ/BMBIvIbbsC4acsrGcvS2w0EM3MsLsZNs6T7P0/0BQNB UHQigSNAaduS/dCyzAs80ZSFI0lSdKUrS1LP3NbWTPS8IPHTtQVDUVR1JUtTJpTVT1VVdWVbV1X1 hWNZVnWla1tW9cVzXVd15XtfV/YFg2FYdiWLY1j2RZNlWXZlm2dZ9oWjaVp2patrWvbFs21bduW7 b1v3BcNxXHcly3Nc90XTdV13Zdt3XfeF43led6Xre173xfN9X3fl+39f+AYDgWB4JguDYPhGE4Vh eGYbh2H4hiOJYnimK4ti+MYzZrP4USVK44oCYKKWJo5E0RzsjdK03GzzCLvZOQIvODSZjYzGSNSO ap7nSdnPksSIooi+0pnlGLAc+PXFlqVZfbOktVothZxk2oVbqi3aFj6j6i0ucXJjmZo1lKawFsKb JasqcoUy+abGkOntPlqmpYnRojPoaCbWhKpJbVKD5+rbHtAPcrppvEqEkSWSIGje2JzsyL5ByDB6 4m3Drbvemodn/LtFysJ8+m+gcEm2PZJkvKbdAPE8XvPVWsu6BOroDPcfsqX7vvLLIWzCywGrJJZ8 vXa45zQAautvXM/26Dtfu2U8v33Js7w64Jxu/a+Us0j7Kxnnsime+e6l/v+V16HeBnyYaWt+0pEo 3p+Uhyzfj3a9et0Xs/lNG/fV3LgSckbeC6gmT5ydMxfdAcxaA4Bvleo50i76YCGWfAStui03YuzP IXp1xN1EEEe+QxpYGivFSNiVkkrgCTkxMiCNszyDPlne6SNzjh39Eshc4Vwz8ypQuJuWODhmHuEH MC3aDrui/RDShCCEMK4nE5aoYQvZcARnCMMeR5BKYSEPeYWIrsOIdQ7LeQeKranIxbiskggbJYmt YJxFhzjqXwh7hyYyLEcoYwXNg7OArjiFlxi68dkxe43E2iiXtphZoyrRgydiB8BkSkWf+7wkBICv JoIGkuQhj4ZOWhFE+IRSjnxEKdEeCxUZMReK7KmTz1ZMGMOPECJEoZIkDMnEaPpH3jObkKWSViGh AJCizDyQEGoFRJiXGaZCR5jkXmKQcx0UYAH5MqU6KbvZAzCMC3IixV4NFrjxF+GRGSswgaxH4nE0 nSR6fqsMu6JJqzcbISGIEvpUS1Q0bRtj4Sowmcm3ptc3Y0ujllH97Z74PuWfnL+ej+jQSiT26R5M 95k0RaDFpzMu5eyFcJDpPlC5JE9nHQmhUy58E1ZrIBGMD6QJxjcXyBJIyRnlgqqiURty6zOl+Wyg tBqNUSp7T9ZSYJWBSJ615BZ/jJlsMRKwsB9z0GtqZTgm5xU7p5N+k5K6Hy2HkOkbc/aTidplNbUg hyDSlyOOAzgkaHzj1SIJWw+xF1Hk5OvVSvCBwoVInacAlxPDfn6rMTRA1ZSdI6qzKlBiGSSE7MZU YpZ0DtV+NdTcgdbiapqo8TSw1N672UPlR8gdn7G1qtEsmolprTxKIclJMleCJpztYYaR1hT5IasG f4gxTKsG5Pja60CAX6pLMpXF0Zczn1vRVMyyyP7I2qI1YqulxCdWYkce6vhPUAV9tLJKkheKVkDt yjezlf4lnNmhcgnU8JRpsSak+ZJA0bVpJoiRsro7qV5nzTe6xjbwk2rdUsytq1jujotZGYNjGZOz qZV0plU61jnb9gOrt4VOE3IlbycF6r437tBgIi1ck42Ttwpk/J40hVqsrPiqQUFPkRRGfwjiC0AH tJ2H87VtrKYSRTYBmV2rl2Wwxf9+tdbu4dImfhEJ2bRVwtviFTJjL2XpJooemZFsjGtNjbSy6MD0 1fJymPBKGcCLGuyQe+Z/zppUGkjk9Z0a8HLI2lciSP0T36rLceul+q4xpqfgO8J0s5PjsPmu8V8I 31eyPlq5mfMX5MNfjK1Wb8YaGxGijHRJKwosx6z3H+PnmosjCibIhOsjNeosb7SmTKXXttDoarSV Ty5kJqm/GGWMqxcqfio9mJD8oOsZeNZtSESJjNCkG2GfaTm7xxbtx9Y8+W+STk7PAUMLyBV9ijMp Qso7LCkc3BRF6zbTChZAn22EuaoIbubFyIdto71dq8qkMyD7f2aiLS18U7ES2/sDfOKzhJJS9sJi F3GycGY0j0aSKHromQ9sZdB8TWh/4Wmzf+/ji8Q184zhKkOEPo1Hx3kRQaZ7v5GtfkPJ+VWO33yb lfL+YLt43zHmnNebc3WM3DnBQNrbCtSs3lxQhY6g52sjiBA+hqFmGpfi6oaw4AItzpU/QU2IWz1q Ra/VF34E6Olyj7oVCb866eZQbkNjdSJ+ytPu5ij9sNJx9W3cCd9uVicUaV38+8pQvgZDuzO7oDef cJCHEOddg4o4V7DzaEHvNRmXET8NOgA7/LxzqcOH+SIt0koY8GkGo8TrriR3+7k5wlnRMWHeOVxU W+hAl5nh3VvQQdjzipceqb8qhpDiSmpNx4RjgXkPG+iMZ7RVYzDq+dbETPUUHzi/GenrE3WdU0OJ cUYNFaHB4ZtPL87znhWUyBIMc34xOMzk4800H65N/ue5eGVCGebSG/OSID78T9b7Nk+QYUi18/j/ eI+8ezQ/qOGaA+gJ47Qps3yaO+ofMJmbK/gsuD++4eu0IMo/pAiri+89U04yZAsNg9y+qf2L+12N 2/G9kZIewJQ+g7wvE+pBOdc+upk+0Mqdk/YNKjazDAiSrBOkgUoNiaeocy2aAGY7+tkcYMi9Kwm3 sGYea+oScmtCQw6Q+6vAanILY/FCIJu2ISjCGIceDBQJPCQcg+GlMA0OWM0y4MrCI4Ie4OHCvBWv EeYI27EI5A+dsOA9jB8bgKhABAgNg6urjAo/IJTCg0q3tD9A+OWKhDKyE0YJ0ykIK3M9GII8KbyP 4T3EjAwcSrEkKwYsYZum230JxEoou0aQ1CsPQMNEQgK9K98TAy4+SnQ7IRUKpB4UkOHEUJQwOj3E nFgJUMYIyQ9F2IG90lm9QPSO+IbAPFJFKu64o9kg8IgIg9+PsUQhChFF8PNBqolGiuiy6tZGI4Oj Cna0IN89FAwhBD+iIMo4yw6kGpsSjGSg8oY1qgK/ALYruSMZEZapkTs0+5ZH6OIlYdad4IpEDICJ C/PE5HgyDG6lmpkbrC/GW5K4fGdBZHUeGSq2mi5G0onGW/0xmokVE7QfZGYQSi0lM9uOJBy7UABI SeWQdAtBLF4nol+/5HjHkPqQAuOp62XC69pFAogrxFQDPBa6Wtm5/EcNozSIydYgcyGReOLKYpfH eyFGVBE4MM/AazQIvD1AYA1F+zqTHKswWLANwQ/FHI7K+2w66z1Co3CABLRFJIMvqf0ISwnJjB8p eZ0zSLQKpIHFjFEmnI6VHJGnkP7IY/acOjUIJCGLS/yRJJe3WPwZujFCiw7DWdkny7pGGcjIUbVE UleIJExBZE0kmNy3WxCJ7MPIbC9MAIsqM7skjLiZrJM8VGhJYmU9ArbK5CdNAqrC5GfEdN28xOCg 6ikJqtIkLJC3K/E6io3DZFek8cFLsQG6PNm6hCZNKmsggdLME7AUJITI8L+QXLEoxFiIlFRJpJCN 1MmZxCmOFCtCWvFJA7IIE/DK5M6okTbJdDJG5G9NkMXIXJusdQFM4jWJ/OaaOIJL+lKJCTG/y9qm o7HMFIKOqMrPkc3IilA1KIPPCnnPJG/PCoCI8bCbCZiZi/kJfOeoRPQlUifOot/QxRUdIZ5RlLhJ +bHO4JpREkQVOoIZASTJi8ypy9dIPL7PzGLGYAAGYhzKI/8egIdJikXLhOUZk4FOaIsizJ5L4kkn kgoJQLZQxL9KNSLRs6QJ6RJSnSpQ2J0kXSfJ5C3TVRwaLNXRclMABKWjOccM8rbAjSaI5NciIChS lEnKado++Ts/pPpSIkLClO8axUTSwpQnlOpSCL/SdB/KnQ/QXPVSSfybwocVIZAM8KlNhIq9YgKg jOYOas/BaknTgSTEMe4866knQY48PQHPEJDNHUZSSLPQnS+gKKvPTQMkeJs3LGopCJ47cMY/PS9F lTW9fSrGoN08SaLVjHMmalpJUyFK8msJYRI7+85PMJxHMJGcUcbV7EhGROLPMn4N3XE/zSSoLWRG NXILJWGRVBbXmiDNOlJT0l0Z2htFrVEcyqSpRYAMJLwIdB2k3U9TxUkNSnUqrXtMHAYofMYQpVCI vAFSQ9g/lPcjkU7YWJ2eqD3UHYjAPOOVtUDVnHAJ9KW7hWHTNUYjnZPUVVzWMfMqEWbWAoahJZ4V 5RPaAUq8mKPCxLiV8ejGQn/X6XBVZNwJ8JZWyKHam9jXbYuXI7k6KYJWeXA+OKIBHVxa5bIYRZbb LbRbTbVbXbZbbbc5FO/bfblbmVpbiQjbsUtKyNW5DbwaMl5bpcBNyUBb6aIpaayt9RMSwhyNRWqU AjvU7cCXOMON+oAmXZ5cJW0vqMasZR08EK2aGeLBEgOhua3WgTpJTJpc64CzHYe68JLMrcPciV6b QLCNizGIkLHdItYcYmDY8baIUp+SFdxMSLsoOj2LUlyKejmj271AYb4oQ+jLfcMz2owT04dKzY2u mxIoBcwc8NXe7dkVCPa6enwtISAqoQy+WSiN46aO2/SSgqgmgPHelPGtHNEwcy+xI9W8Y2Yqo0yP K0QJurIUUyteasa6aThfYlGOm1mNdE2IaqhM239fJeYO8NoNstPPYN6RO16PmNeq3au9JfeIPOSl syW0qJdJTg5hOzBfCVgNwtlH4SSv6t0y0Q4zQ1UyNA0VThmD+zthMyfdMxgzeRwpW+WQHS5c3iCv fgMkyRFIvf4JJWAxtSKvDeEzBBgT2R9faIjiZfqOIzTh1KpiCtffys0Rbi2tPiytbe0yZCLOhhmO M21jM2thdhe2Uki5auA3xN1Gm2iJC8eRylsv/X8Lm20MQ3+e6ymw4MqyjiayOtAQ43JimLZf3Yrj KPTkyv297ijkhjFjxigspk+giw4OQqYvsnIIKqjlHksIs66wpEBi/SMyov1DXjsU6LY3mSOs+NaU eP0z8+0IdlHKvGAy82pORepgmUOsy4suLIayBMRjzBkudWPUXSU3iwgxXF/hxfofflK0WTSvIOw0 FD4vlhzlHHSsQIi02PjF02qr3luVi0kRKMqxxkI9Tk5J63jNvIBlnjLmOvKywvy9tGFmSuRhtnDm jmK6JSUR0uUr9DMv+wzhPHlm+SmJ8N+x0N895Hm2axRI/oC6q9VDCxUPmN+95a3niUHnmIhPRVYS WQBEsNgSHgyyvP/lMTc1+4ssm/vpnHKy8QdjfOhm60qtlp7mcJ1nLnUziiXnczU2etaPRoo3e9EM do1U3hI3OJtoGyOtyNauoQfkfpUUmPhKFBzkwuC9TFLLDAvnvkKJJJsuvo3DXlesniyT3ZQq41yJ FBkUSU4MYs/AFk/geURA68jkrqbGBTyxVjGIO+dopkgJ3setAtjq8JFmHlk1w6xd2RdqAxVD461r GS5rLrSKLDc3xm63JVkxZi60i7fdQT7ndCJq5eYh1AjhKyPl0uZtVCliutEz0MNtoKE2pDDqckzh aJtt4Ru3CrYwY3gIJrA57g/INZ9tE6AIlHTHW+blBsiW6dlDeJrpYME8vtQtPtCNFLW4di4RFXZh RNSis0tRtpiRpehPZutvuV/vPvxv3v4NHurv7wBwCNPv/wFwLwNwPwRwTwVwXwZwbwdwfwhwjwlw nwpwrwtwvwxwzw1w3w5w7w9w/xBxDxFxHxJxLxNxPxRxTxVxXxZxbxdxfxhxjxlxnxpxrxtxvxxx zx1x2WHVAlXWPGsJwo7tgJ2K+g+IlTIUDezYEgggSV1uMi0fw3RYmfsNOK/UvdZQoKFdUjSv+Z0k 6uStFaAaae9XUYwdiSOMPYSIoKuo0MTLrx/OhajZ/UQcKN8ikbZzAI0wSNTdzYDy2nRyM7hzHycJ 5VJaCpFnapXY2LgcJjgQNZWMsj0nfy0JpyGnJdvcoZSfoy3y9bPDYnKNvQaJCnYJHiuqAd6d8fRd 7TvIIpMYmzI0HJSrRn+0AzDmE0CJ8zewVFdYOPSPXjITk3Qs4QznZOrhCre61ujj+4dgxior3BgJ v12sZ2hmIUSxJqOObg3oBlAPjgtf8xBqQcZF/2+wxsRHmMEuIPblylYPBicJtf2y3l4szkrpll3f u1cwbhTQLu7v0X4s6lrOj37gaJzS40yw82hjJPnirs93E3nIemo0tBUP6Mr4OKAt7ow1XvnfUJth 1i91BGCmpjxEevkOfouO33bh9uhkGuuoZPvp1reR4rrNrmewJkDavpoLpvonwqiMrgxi6f4Sivm4 ZrcYj4Bnc3at1mfmrolNsJ5ph5QfRLfpgPLnn2u2i8syP2SKJujuyNoqXtLkvnE3F3srao+u2pXq /sZFKt+u6zgkdqVu6vcsGuORCw3VREYxhsxm3vGvo1JtdtJ196Sr94A8Z4ELpsh2YYhgB8D3FhNg aNxltsjmPiOenlh3QzrpN6VrU4MTaOGLp6JioKHvngfgE8jm95hveiXfMPzlbtYsoRyN9fJIMQRq tsouNoKIKRfqIvEq19P79pjSLl6slpBft5KNxh00iSf8b7dkxmzrUkiSVrR6KYj6s5bgk9atKTn8 lgGRHmJ4FvU4ubC3v6a9X+YxGR18/+A5m54VRvATJ7uy/o5W72JuR758vCzFZMthNyyTMrCIA8AA AHhBXgZ4HCQAUIGgEBC4HDIVCITAoHFoUf4TD4VHY9BILHolHmQUJNI46549GIHGpFJo/K47I5dD gAyJjCZVBIvCZREIbC4lI5/LIPJ49DpxMYpOadT6hUalU6pVatV6xWJ3PJ9J5dTqHOq5Uo5CpOUD O563Y6rZ5/FahZZ9KYGZ4FGIwUD/X6habVMbfN4cgKJEcDWcPCpZULPPr857tHcXT7dacVM4jez+ 0qXVINc4zG8JMI7TclhpJc7DCrXeI9m2RNqtk75XbdH8nP9rZqji5G0o3QJzprHP87Q4ZI7XY3hZ 73Iqdy6z0+p1et1+x1JDIdBUolTc/U7fP9Nk+9EeJcKfcojdJ7eYTe2ZVbt5re8IdjeFluvifUqi kAA9LMPEpzfJaP5mO4q74Mu9qcuknqIh8jqywC8jFIEaSfwU/DRtm16Pp+wLctOwDeo6r68tInLF uAgcKIVCzVLEisGoS+cCKY7MeR7H0fyAqS7o6KTKK6gbWvMnLxxNCSrOVCMBxem8mQckEbyczyPy K0sCJRCLhQKmSLwGqKJTA7szQNIiBxyg6sqaKUVSwj0wJQ2rOqE9EbS6+8dTWuq3ym3iJtwj0uP+ 4UWLAmkcwEsz/LY4UEoSM7jq68E+TTSUwzHINP1BUNRKnIbQ0YkymvLJUTvdRLnOeqLysk/UbHOS TAuIoyaL5VdARSjxJQJVURQAtC/wygtIuiuqnt2p0yyyACXIxW9SSO+MOpY/yDW5B8221SCdMhBc aSbb0DWTEiXpS6TaRUtbbu8zVHABYNrxbP6DVtQkkK3bkFr0yTl23UeC4Ng9PqOjt6MAtErWZMTW XMkwfPkEapSTSAoYrYBJXssy/Uze4AGYEaCjPj6nrw82GY8maGOW80Yu9kKVjPZUdWPf831NjFGW xLOcIuo7755TbJW5m8YYnfNyJ9jiJ5TPS+0XQs/0TiCO5Mg+pKFoVsYuhWpUixba5RsbWPA8L4o/ tF8YRuG47kq8/bnSVeqnmLqrUc8FsXRGh33ISDTKxeugBNEU2dgtjWPK+iI7QaocSAE5L3Kd4a/A M1bttiO8Pr8fMOeHBc66ai1DvHTdX1nW9d18foLyWHurxeDLVaFDOzBKWbd2Hf+B4PheH4ni+N4/ keT5Xl+Z5vnef6Ho+l6fqer63r+x7Pte37nu+97/wfD8Xx/J8vzfP9H0/V9f2fb933/h+P5fn+n6 /t+/8fz/X9/5/v/P/gBAGAUA4CQFgNAeBECYFQLgZA2B0D4IQRglBOCkFYLQXgxBmDUG4OQdg9B+ EEIYRQjhJCWE0J4UQphVCuFkLYXQvhhDGGUM4aQ1htDeHEOYdQ7h5D2H0P4gRBiFEOIkRYjRHiRE mJUS4mRNidE+KEUYpRTipFWK0V4sRZhgQEAKZW5kc3RyZWFtCmVuZG9iagoxMCAwIG9iagoxMTg3 MAplbmRvYmoKMTEgMCBvYmoKWyAvSW5kZXhlZCAvRGV2aWNlUkdCIDI1NSAxNCAwIFIgXQplbmRv YmoKMTIgMCBvYmoKPDwKL0ZpbHRlciBbIC9MWldEZWNvZGUgXQovV2lkdGggMTA2Ci9IZWlnaHQg NDEKL0NvbG9yU3BhY2UgMTEgMCBSCi9CaXRzUGVyQ29tcG9uZW50IDgKL0xlbmd0aCAxMyAwIFIK Pj4Kc3RyZWFtCoA/4E/oJBX8/X7BoVBYFDYdC4ZDolE4lC4pF4xGY1G45HY9H5BGIRI5JEIVI4jI Y5ForCpVHXw+Xw5XM5Wszme2Gi0m62mm2G22Ho9ns9Xm83c63Q3m413a7nbRaI83pDXlV3G3m85n C4ni73a3XE4Ww3W/I3fYHg8Hc5HK43c6nU3mw2Xo83lBaS6n5fXw93rNXC43M6HC2263Go1m01We 1G1dns96K9HO5XE7Hc7Mu43g7HZCH45MO4nK5XW6nS38jfX47ni8nJbnW53Q9bu8Hja6pBXQ5nNS tPl3JY3Y6Lk5nHRni++c4Gy2XPpOFzn1WW2zWQx2u12m3p9B3653E42ayWM2GozWc1GlkW222o1K y2W44G7a3g+Xu976fZ3LA8pwnScq3G+cKwHUbpwm+qB2oK2pxnBBp1NAd7QMoeh9Jkl6HNcapnGg bhpmucpwHEZRlGKY5iGIdh0nSdh1HOY5il+9xoG+bBtHIbhwp6brnH4cZvm+YJZFwaplseaZoPQY xmmIY6Rm4bptrGshpGoZBcmCX5Zlu1Jzr+e5ilsXh5HceB2nadbvJ2ZhnmiYhlmUYBiGUZJhnG8p 9T+8hxGKYJdmIYZhGgYxjm8aptJGbbInM2jbGkYxmQ4fMGnCZhhGMYZZl4bZsmxIxunPU5+H2fhp GaaJoGgnBmGXJZny7PJimItxypGcJsm6cBvG2+5vsoexoTyYhal6cBvm4p8IIJHxwmEXBal8YBfH Grq4nYb5sm0X5ezRatvG0z53tcZBkmOXBXFcZBdF+a5nGkappmeaZomecRvG+gpwnBEj3KYbpyG8 cJmmUYcjG5DyGr0dR3q+th2HWcFIHMb5xnQcZyxmdB0NscRtm8dRynS2uQZAfiEHwyduHEbhvnkt Z3nWdp2HMdTrHXip3nc2CnzUeMjHIeLYnmeB5nbGUZnSvB5MObp0nEcx6Niq6kZxTCCw4fR67AeM A5MdGkryg82Hav58H0mJ5nfs5/avNUZZsd+OnMyrnH2gsLHedR18CcxznUch0HluB1HRp55HihuX HwerJ8ke6R3Or54v7yq+oamR8noeWlximR8VSfiiHumujLSex6HrryCqMo7dHuoai7Aeih7BVJ98 7Dli73r0ZHa2PHYcf6CmqaBpGte5hmNTxhmKXRdl7cRYGIYRe2uYRmGQ9jtmkaJlmLFSRz6cJzHE b5vPwaZpyWZRnF+XJbGEX5bSMbxy1PFBwGuGSq8Y4yBmDJGIMl8gwVZDEGod0YAwhiDVPcOc5Trh 5vHgxBmDUG4OQdg88ggg7R1HAMuN42bkh7LNGwpIb46HAvpHKdEaw6X1OARo4E1xbB1mbOQxUcCB jBsXGuNAbA3BtjlNUhRX43BsEFHIcAbQ3xujWGkM5Bo2nmDTG+cUb5Y4aDjKoPQe4+R8wfjNGeNE aY1RrjYQ1DjpTnMPIWQgjZLI2x3jxHmPUe4+R9j9H+QEfyRlEHs0csBUDpm2HIOoebR2jtKdca41 0b5IGqHWzU4RRx5wjRjEiGg6S1jtP+PofY+m4DxJkPdrCqh+SBldK+WEHzXDYeUYkbBQBsjAGOMY ax8ymDYXwNAXku4wqnHINIaa9BtDaFsuEZ40hnouF4L4ZIyF6jVX0vQZoyxlvedy6AvA0ZkjIGQM IZ41Rqj2HwPiWM7Z3TvI8QUdibh1jpHQZhqo6XCDnHG4CGh02qjkJiPgdKbRulaGkNcapbhxpthG 4oeRd3FjoYon8fJyhwxkci6BYURRvDdGmNQaY9TKTwpNSek7exsk7HbC41I7opDcLoNilpnBxjkK gOplzlSENDJ6Nt6AyC6DaGuMsajMRwUajqSaO1KKnVPj/KUfQ0hik4TyNR5YwxdC6GMLYXw1xmjW MUdKm5Rh6D9L8f1K42opwzHGOcZowBmjPGMMpxrxqoV5r1Xt3hWRvFKHIZQesjm5zrJjGSUrfCCQ 6YAsI8tUmkjwHIOBFCBoXU6jJXuzVm532CGQMVZazV+lBG2NcbQ1hoS6GMN9YEKCGoUG8L0YAvU6 jKdcPRSQ4RnjQGWM0aE5xrjUkfZy4lxaonOHiXh1qG4yFfLCeUbJ3UaDlosQ2b6bnANbQ4VQeaYx wpWKSOkv49rjXlvNee9F6b1XrvZe290bT/uKHIVdpDNDdpuHObpn5mxuraN2O6VJDZWGmHG40d8K DQDrHFBRmpaDdMnHTE+Lg3CUkjN2O+w9BU1lXP6PYkeEBtrMGlLQbg2VGjZGmO0eA7734tjNIQWg uBcDDF4L0ZoxhijGGIL1OwxbPp1GKMMZgzMdDBFwz80JfSRjdG6NkZAzhm5RmiLoXJkcTjVRgOgY AtxbjCGGL98QzBoToWK7Eoq3xrPNGlPhYKoz1n/XK94Y6LReJyGZEYbVrsXZ7g23uobhRzlxQsm4 sY4B0Fupa4Ce7PTNM9zKQiFF9Cv4HLwb9LI38IjkOOOkr6a8L3Jb+tAf1A7kpqhtEgcg4xxs3HWQ VxA8E1DvLwbyCw9DXEpp2PsfI+iCmuIa6YwFPCEmiVU54kbvK0Stz5VAgo2xojaK4WRe7TB17OG0 OsczVBujYGsM8ZtLdsDfQMwfaI26EjYGcNYcw4BzN7GaMMYlVBnDTGQ+MYIxRqjMGaN8a7MhqjcH IWJ5SckWLSgAMAYNWklJMGeMMZz6hvjbGsNEww5bEnQHCNNOTMRtENHO+kcMyxyUxGoNg/g+GxDx GgMgZQwRaC1GqMpfQwRmjjLMMgXovN1nLojsuqDezvXRVYnYY82BqDAF2MMbw2RtlJHQNc+JoB2x MGuNIZYxGQIFNMLcWYtnyDDP6Pi0o2xVipFgMgYgxl7jJQNqkcGqjCM0He98ZgvhfjCuiNskcFBx 8TGpNgaowd79VgKMkYqThqEjZoO7NI1DlDmIaW9BvEmAHQJ+ZQe8jR3xU30MgZZjVRKNHKkAaGYk Zjtc9z6p5BdjqplIqohEpB9O89YSgfx/6pe2H94vzRC3QjyTLUwiZCTxEIIIRj2uyR+W3HvOsjxJ PoVMIIP0iZJyU+q+x9n7X2yMOm1Dyckdifk1S+KQhIZriRte90QuxPua0UWINsP4xBGvOedNr14K f22KYP/sj8yUg/78KUj5IoweR1oeqtD4j1hh7+UBSNzXZvYg4fyNxP5TD8Qgg3D34eD2j6Dk51q8 ggb+MCQlL+I0UE0BkBr6BTBrz+4gi5y5cBMCSPixKlZb4agZ4ayCQX4WIXhtYpQcaJiKoY4ZYYbL oZIX4ZMG4ZoXwXgXQZwYgZjboapNwdJYq4Ia5mJBpUZJ4YBWoZJWoZwYwXrtQZRKgvrdaY4ZShIx 53gxwaYYrpIaAY6Z7q4yLiZORBocTboZyWh5bfQXoV4XYeoeSkgogYx+5ThdQYQZTiShTqo/5DAe DQ4co1gaYkah4+S6K35CJwg+Q+IaYbIkbpYbIby0wrJkYapKR+8G4aaRK14cIbzNS0AYwaTIYbi0 6Za04ZoajbAdYboa4azbgaKYAapjie6yjwj0qz7pLiTCgg4aJ7wZRTobQagbbmwcj66Nggo3Zmo4 5noaousCrzQrocBegaZkjfhe5ZgbYYabpCwdgaqKosAdaw7kobId4taeoc5fIZSlzfobhFQY4bIa QZTZKFAsR9JCYkYcQtytgbotJAK8I0BFAcYbSj8fQ5AdKhI7wa4bD5ofEUTVRm4doaaaBCYbgazJ gyYohsEiA+wbSViw4mocUX4aAgqw7WEDT6ZzUj8iAqAdYZC3ZXxqZnAgrWAeJ/gdAY7KIWQVoUaB AYqIg9SZZmpSAasL7z5I0jJxQcopga8fAeEix/ZGK6xyQcI4ZGJzUEglyMwkY34cjj6RZAxGYcxo AdpDB4hNpCTCBApjwc6GgcQ/BYMYIa436JAmhxSt4uQo4eUgwvC28nLCIrg+JlxsA3Bi4bUuMmgb I2YcCGgch3g/h24egaBUcQqVLSylzTJYp3gzSlo36EZSQb0hhgJwgdZvBDBGY8iUofKqQ44c5xBA IthGQdcShYBRpApIo/BBgcDxRNkr0lIbpxRxY2Z9U2ZU8YAahIBkpwZwaJ4dIdRIqLZ9hfgbA1zT JHYbQcCogbaKQy4cpmwdjWKQwvC+5pgwgkaMYfJmQb5QJMqDZ3jaIYQWIXq0BRCdEWAbgZIXQYYY YWsJoXgW4WwWoWYaIY4ZLfgbckoaAXIXgXaKpfci0uIaBfIaVEye7dqUrIYY7t5qqm5LhfEL8uyE QdQYAWAWwaAYbmQ8634ZoXQVYVyswcJIAxBXwbgbg1wu4eJOwYhEQaIXAVAVodA00Cp76uYZIZIa wZYaE4sSYcgagaIaMUbDoX5+kfBdAvocUiwYIXIXa3wZsYAa4VASATgXgVAWgaLKAYztAbBeprxP ob7GIWoY9BqYB94ZR70Q40wzAswb4axLB9oXYXgXAt6yYoDG4YoWQWIVA/8q4Z4W4UgV4VwU4UgW 9SQaAZQZbZ0HI9qm4cblp+4WAWgYAVoXRz0CpEJfQYYZJc6DYgpzwsAd88AdY3ZxrDZiQpJoA3SR oeKnZrweZyUbkD5tZ10AtaB1xtaVJo8AyFByU+MD43AexoZpIeIqRP7XSdZsRpQr4q5xotcCrXov suxlwewuIdZ2RvcQYehzxYpmqTR0kCpywqjW4ght4eUhgcx0J3K5IbgaQbNfRMpYptb8Ivsj5Mo1 xvb5ofMAQfQwAexvaRsDaST5ZsBkAcz6ZrxmgeYwodRYtgAmJNtZomKcBc5s0EYghzz8COiDUj5R QYbwQXQXBL6hQbCAYZBWEIZ8gZInbXYfLQ4cLwwXoZJLYXzeBwYdCCwxga4V4WgWwWLLjHQX7L7m AakgakLfTq4XwWY/4t4csMp+Q7QXgX4XAdhn5wAdZegZ5PpkpwIaDNIXtQgZ58jfobaa0SwghewZ yohVlMKXoa5z0xgYwZbtAZIZQXLL4rQbTbgaAXrlkj5pId7pYas2ZAhwIaI9wZzIjbgZ5X4cAYQ7 dyQY1eD477h453gzZqjyQmknozc70hBLAcAyYe42wczJ4ZpwgdLqAbK+hVQfaw6H4cg6IapbQbhq octaq7hn4dotwcU/KdbvgtIdtrS7jAw8AaZm4d1aAeqFw1Y8B77z5ZiowaQgoo5iYd4wYcSdQe7X 4hAcpkCHYdoZ4ZwZAt4b81wYabd4V+obJIxjYc5rAsYbtMIZZpsu4d8eI9oZwYqiIekbN2qPL6Qk yVypsEIgzJSO2EgleEOFeFmFmD+F+GGGKPDXYfVdo4ob0iIoIbhU4dMCo/Q1gbwo4egzGAxAqJyJ 4uU8A6bt4cJkLrJiJBSGg0SMYfBNZNiEY3QeMwKm40wlJszQ6fgwY6yVhwgdRCgciGgcqVJ1BbR1 ZoBGD36eQqBn41Jio8pjIbcWA7o0gbhwYdI/BAhlFJWKw10yw0hbzEpnpNop4cQ8rWZoAd4zAcsT gtxSWRSMgfJbQrp9at4c+RRZocJnAuQ1RGNe5yTXy4h3BJwZVsQXpH4cAW4X4XzLwX1kKMI+wboY JFrIIXcW4axlgfpLwXwaZ5qygbkIYZTkoa6BDOa0BEQZqwwwocwnYZqIwawYqaoVoXAWwZQZ4Zlj QvQtKg4br0oYxDUnJUAXIXLriWgaIys4gYIZAYxewZ4XgYAXgZZfQgp95ekWoZKbYXzObwQXoYQX gWicgYIXQYoYtqoYEkoZyCQZ7pIYVuotIsCKqoRBt+QZpfKIwoAoK0wbMOYZw0SW4akL4ZwYJPR3 IeZhJOoZhFpPQXC2ZhLHAY4YB+QZkjZwKnQv64otAzdar15m4dg5g62YEldJQdRnBuAecbbFYtYq DFYzZpzQKeplE5IcR3g5iwCTQzZnBnAyppQeogslbFbFRDA0SwxYIbBCYbZ4qSaN6dZw2P48pCzV ogieZnoqGN8nCEUuyMKiIeZiodIq5NknwqIv6jQ3QeCwx20lklhiodUuwdxxogpuFdqRovA1ydYe +ixoDQQdCEQcp0N9VfZTA/jZOGW1e1m1u121+2G2O2SzYgIKZW5kc3RyZWFtCmVuZG9iagoxMyAw IG9iago0NTI4CmVuZG9iagoxNCAwIG9iago8PAovTGVuZ3RoIDE1IDAgUgo+PgpzdHJlYW0K//// EzglEXrO5DpX+FEMuvM0MhLr6URdAshJB6Ujz8nXuNwP3u6KrdPEBMsWEYYJRrgbMaFgj6Qp2azO /HuY0zN14xJjbr83MsQCSNaJURxBbU7jzt6H97c0xrOvXofj02r2N9i1bgt6cVRQ+qVtPBO8H+Ga p9lR258Fi/6Mb9H3ZQnQG3jclekw5uPWUx/pDz/Lquak+8JEAU1CjrwUhiIeVj2WM9KAY7ljOQyD IxzD78eplMNs2cS6HFN2MNmYTzDV5WOoZcZhyQBuTSSLERNSu6gVJ4Ha4Z0tWM4G8R02xwOZb2lg 0TNhQIGFy5KZHk1BNHTCDlZfO64tQp9LeWdOE9a3c6jr1ehsWrT+89JMNQbB9xUXV1HGhJNmzw3N HiCk1pRMwWk1LsPpLbe8eezCO+TYUjspGL+9fo/KTK7r8ISAPEbpcXStW6FlFxtR2lY2sqlx3MEx mkDBZYxvUHz00Lk6uiuvZ4dRzZ5sH3nDVSxsxggu+KNvuQj8KVl5HSoyWOReB0zlWBmExTj9iI4q 9VUzJE3WkwffjzA4CE5iO6ZHmq2UfwWtBMrmAlN0LEjJX2wXNgAeFY9OTZicsNRD+G7wjO72OvLB IfQUliFdX4DKd7fKlcxa5BrzgcrHxMM1tU8kq4oWbKsLgUEs3qGtqRhkdK4wz5NKwhQVitnZwI4p 5Dmz+qZfBSegMgVC365bQyMKc/KdvrSy1D+Lrf8a1uRTit/56eUhiRcmzPbVJzr4Ma7qz22fgUHf De7fJ8XDe0+idTiIlsKfvY6WkrbQi+h/drfsFjkt9UYc1G7imOkxO19qw/UsYrK7+UVyydFbSUcS NV5MYlOTfygBYcDqkvtK/b4/KiHy5ho4WOQJsy1RxmOvE8UDpkQrp6Xskjjo3DWnHF/IDkXjR57I UVL2oxlZUywfVtJkgnoJbgxCV+h3/gTXxxMdq1u8c6wOak8oxKJU5PknSHuhUeqtlEGWDECb5Aeu AbIKvia2zJEG9FWpSTmicIEeEdMJv2hLCmVuZHN0cmVhbQplbmRvYmoKMTUgMCBvYmoKNzY4CmVu ZG9iagp4cmVmCjAgMTYKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDAwMDEwIDAwMDAwIG4gCjAw MDAwMDAxODUgMDAwMDAgbiAKMDAwMDAwMDIzNCAwMDAwMCBuIAowMDAwMDAwMjkzIDAwMDAwIG4g CjAwMDAwMDA0OTcgMDAwMDAgbiAKMDAwMDAwMDU4MCAwMDAwMCBuIAowMDAwMDAwNTk4IDAwMDAw IG4gCjAwMDAwMDA2MzYgMDAwMDAgbiAKMDAwMDAwMDc0NCAwMDAwMCBuIAowMDAwMDEyNzk1IDAw MDAwIG4gCjAwMDAwMTI4MTcgMDAwMDAgbiAKMDAwMDAxMjg2OCAwMDAwMCBuIAowMDAwMDE3NTM1 IDAwMDAwIG4gCjAwMDAwMTc1NTYgMDAwMDAgbiAKMDAwMDAxODM3OSAwMDAwMCBuIAp0cmFpbGVy Cjw8Ci9TaXplIDE2Ci9JbmZvIDEgMCBSCi9Sb290IDIgMCBSCj4+CnN0YXJ0eHJlZgoxODM5OQol JUVPRgo= --------------070203080702010408010600-- From simple-bounces@ietf.org Mon Jul 09 15:02:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yUo-0002O7-Mi; Mon, 09 Jul 2007 15:02:06 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I7yUn-0002Nz-Po for simple-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 15:02:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yUm-0002Nm-Vz for simple@ietf.org; Mon, 09 Jul 2007 15:02:04 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7yUi-0001lS-Hs for simple@ietf.org; Mon, 09 Jul 2007 15:02:04 -0400 Received: by py-out-1112.google.com with SMTP id f31so3470711pyh for ; Mon, 09 Jul 2007 12:02:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=YaFoYkX+/HFUI9pbEbfemS1yipiSca15qxzeNo02SauI7JuVmhmAfFAFZmwozC6jJMCK+hT1i49YTdVGq1Foe5spfzrQdOnHswIQQry1m9RiU6nfBJHO4toIrtLBE4b9X+woWTZguJccsxWiAxh35IoG+K0sqPrmHnj4w2FIh+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=GHiR3BpvqcasvUzCQyOrHY8gBRIxr5kGkN3LFXo672lJm/50RZUyG1Af/3vFsyGRPg0tZK6MiErUHE/BRs7F22XzEa6LUsBXca0EKOXIZNYRtrxptBEtTrhi3XYX16PtClD2FxCfw0hfY4xbY3dwsEWuVXvCmieO7chJg/U4jLk= Received: by 10.65.53.3 with SMTP id f3mr5312991qbk.1184007719205; Mon, 09 Jul 2007 12:01:59 -0700 (PDT) Received: by 10.64.210.19 with HTTP; Mon, 9 Jul 2007 12:01:59 -0700 (PDT) Message-ID: Date: Mon, 9 Jul 2007 15:01:59 -0400 From: "Arjun Roychowdhury" To: "Goix Laurent Walter" Subject: Re: [Simple] I-D (Updated): Motivation for converting Presencedocuments to RSS Feeds In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Google-Sender-Auth: 633a3dfd710a7745 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Henry Sinnreich , Simple WG , Licciardi Carlo Alberto X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: arjun.lists@hsc.com List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Walter, thanks for your comments. I agree with your architectue option - actually that is what I had intended to show in the example, so that all UAs don't need to support feeds - I probably need to reword it to make it clearer. I will soon be posting an updated version - depending on the interest in this list, it may make sense to work on a following requirements draft. Alternately, if there is any other mailing list this work is better suited for, please let me know. regds arjun On 7/6/07, Goix Laurent Walter wrote: > Hi Arjun, > > Very nice idea indeed! > > We are heavily interested in interactions between the Telco world and the= Web2.0 world, focusing on user-generated content/mashups/services, open AP= Is, etc. > > I fully agree with your vision of exporting Presence info towards a feed = representation (RSS/Atom) to improve integration between both worlds. > > On the architectural side, yours is one option. I could imagine also a wa= tcher (or the presence server itself) acting as gateway to export Presence = info as RSS, thus easily supporting privacy concerns by still relying on th= e mechanisms provided by SIMPLE. > > On the use case side, i believe they are quite fine, although they could = be simplified. Probably reference to the back-end providers is not needed a= s a motivation: having track-it example simply exporting my buddies' presen= ce info to a "plain" RSS reader would be enough. > > Regards > Walter > > > -----Original Message----- > From: Arjun Roychowdhury [mailto:arjun.lists@hsc.com] > Sent: marted=EC 5 giugno 2007 17.39 > To: Simple WG > Cc: arjun.lists@hsc.com; Henry Sinnreich > Subject: [Simple] I-D (Updated): Motivation for converting Presencedocume= nts to RSS Feeds > > Hi, > I have submitted a new draft discussing the motivation of converting Pres= ence documents to RSS feeds. > > Till it appears on the list, > http://arjunrc.googlepages.com/draft-roy-simple-presencerss-00.txt > > As a working example of the benefits, I've published a mappable presence = feed example using GoogleMashupEditor at http://rsspresence.googlemashups.c= om/ using concepts proposed in this draft. > > Comments are welcome. > > Abstract: > RSS Feeds have always played an important role in providing users content= related updates typically of Websites without having to visit > those websites manually. Typical examples of RSS usage include users > 'subscribing' to the RSS feed of a website, say, CNN.com and > thereby automatically receiving 'news headlines' then the content > changes. Recently, there have been significant innovations (such as > Yahoo Pipes and Google Mash-up Editor) where RSS feeds from > different sources have been combined to produce new services in a > 'Web Based Service Creation Environment' model allowing users to create = interesting services building on top of 'primitives' that can be represent= ed on the Web. > > This document describes the motivation for an RSS feed for Presence infor= mation, which the authors believe would be useful to create new services us= ing a similar environment described above. > > regds > arjun > > -- > Arjun Roychowdhury > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -------------------------------------------------------------------- > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the persons abov= e and may contain confidential information. If you have received the messag= e in error, be informed that any use of the content hereof is prohibited. P= lease return it immediately to the sender and delete the message. Should yo= u have any questions, please contact us by replying to webmaster@telecomita= lia.it. > > Thank you > > www.telecomitalia.it > > -------------------------------------------------------------------- > > > > > > *****************************************************DISCLAIMER**********= ******************************************* > > This message and/or attachment(s) contained here are confidential, propri= etary to HUGHES SYSTIQUE and its customers. > Contents may be privileged or otherwise protected by law. The information= is solely intended for the entity it is > addressed to. If you are not the intended recipient of this message, it i= s strictly prohibited to read, forward, > print, retain, copy or disseminate this message or any part of it. If you= have received this e-mail in error, > please notify the sender immediately and delete the message. > > *************************************************************************= ******************************************* > > --=20 Arjun Roychowdhury _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 09 16:59:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80Jy-00019w-1R; Mon, 09 Jul 2007 16:59:02 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I80Jv-00019Y-MI for simple-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 16:58:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80Jv-00018k-77 for simple@ietf.org; Mon, 09 Jul 2007 16:58:59 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I80Ji-0001wY-QE for simple@ietf.org; Mon, 09 Jul 2007 16:58:59 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 09 Jul 2007 13:58:25 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHs+kkarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,518,1175497200"; d="scan'208"; a="384458302:sNHT7619434128" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l69KwORP019903 for ; Mon, 9 Jul 2007 13:58:24 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l69Kw4nO011793 for ; Mon, 9 Jul 2007 20:58:24 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:58:17 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:58:16 -0700 Message-ID: <4692A16D.2080604@cisco.com> Date: Mon, 09 Jul 2007 16:58:21 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 20:58:17.0003 (UTC) FILETIME=[DF7B2FB0:01C7C26B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1259; t=1184014704; x=1184878704; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Updated=20presence-rules |Sender:=20; bh=tDbFiuJFwx4Yjt4bfuCMvaW4oQ+Cb7A/gTY2mxpvHSs=; b=fIKMJvKn0tCvCJeWjFX91SfY8rALgLUMeYDsQ24NLyF6G/XDFoIBmTm5z/wVm+NYYMvDlI2I MD26TbPlXxmJOl6BBgM0zBcJFXQB2bsWpXLcMcbGNqYoL3uiXdxrK8tG; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Simple] Updated presence-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: , Errors-To: simple-bounces@ietf.org I've submitted an update to the presence-rules specification: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-10.txt the changes were meant to address IESG comments: https://datatracker.ietf.org/idtracker/ballot/1543/ These resulted in a few changes worth noting: * the spec now as a section that documents implementation requirements on clients and servers. In particular, all attributes MUST be supported by servers, and SHOULD be supported by clients * consideration for cases where multiple clients edit a rules document, but support different subsets of rules, is considered * identity processing has been revised and generalized. Now, instead of enumarting handling for the currently defined SIP mechanisms (4474, digest, PAID), it defines a more general framework that covers all three. This moves PAID to informational and avoids the downref to RFC3325. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 10 03:31:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ABJ-0006Ul-Jp; Tue, 10 Jul 2007 03:30:45 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I8ABI-0006Q6-Nh for simple-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 03:30:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ABI-0006NT-Ab for simple@ietf.org; Tue, 10 Jul 2007 03:30:44 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8AB2-0004o2-Fi for simple@ietf.org; Tue, 10 Jul 2007 03:30:44 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKY0063MCT17G@szxga02-in.huawei.com> for simple@ietf.org; Tue, 10 Jul 2007 15:29:25 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKY00LP3CT1QU@szxga02-in.huawei.com> for simple@ietf.org; Tue, 10 Jul 2007 15:29:25 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKY005VNCSW6V@szxml04-in.huawei.com> for simple@ietf.org; Tue, 10 Jul 2007 15:29:25 +0800 (CST) Date: Tue, 10 Jul 2007 15:29:20 +0800 From: Qian Sun To: 'SIMPLE mailing list' Message-id: <008f01c7c2c4$07e1de10$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: AcfCxAeO/cv1hOjqRVitt22m3zohww== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Simple] Nickname negotiation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, There was a long discussion about nickname. Here just a suggest for nickname negotiation, could we use a litle more genenal approach instead of MSRP method "NICKNAME"? In many chat systems, it is very simple to set or modify nickname, just send a text-based command like "//nickname spiderman". In addition to nickname there are also many other chat commands, e.g. "emote", or change rooms in the chat lobby. On the other hand, some users may connect to a MSRP chatroom via SIP MESSAGE or HTTP. They can not use the MSRP method "NICKNAME". A possible approach might be including the chat command in the CPIM body, like this: Content-Type: message/cpim To: Content-Type: text/plain Content-Disposition: chat-command NICKNAME "Alice in Wonderland" To "emote" function: Content-Disposition: chat-emote KISS Bob Opinion? Cheers, Qian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From ujfpg@workbalance.nl Tue Jul 10 09:53:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8GA4-0004IU-Gg for simple-archive@lists.ietf.org; Tue, 10 Jul 2007 09:53:52 -0400 Received: from [72.18.111.209] (helo=ETCCABLE-111-209.ellijay.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I8GA4-0005KQ-3O for simple-archive@lists.ietf.org; Tue, 10 Jul 2007 09:53:52 -0400 Received: from [83.200.175.119] (helo=ssox) by ETCCABLE-111-209.ellijay.com with smtp (Exim 4.62 (FreeBSD)) id 1I8¸0j-0003iN-Hm; Sun, 8 Jul 2007 20:27:52 -0400 Message-ID: <46917FF6.7040000@workbalance.nl> Date: Sun, 8 Jul 2007 20:23:18 -0400 From: Japanese User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: Karl also notes that "track security needs to fucking chill". Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.3 (+++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d VPSN Has Wild Day as Stock climbs $0.019 (90.48%) GAIN! VISION AIRSHIPS INC (Other OTC:VPSN.PK) The 24 hrs has been a sky rocket for VPSN. With major news to be released stirring interest has brought huge returns for investors. The key is, knowing when to get on and when to get off a stock, for successful day trading. VPSN has distinct patterns to watch for. This ride is not over. Jump on now and ride the price up on the highest return "Day Trade" we have featured this year. Get on VPSN first thing Tuesday as we stired you in the right direction for Monday. Then my last lap, I was up four-tenths, which would have put us happily ahead, but I was getting a bit sketchy at the end trying to push it a little bit harder to make sure we could get the pole. Not gonna happen, but a solid performance nonetheless. Coming here, I put a lot of pressure on myself to do well. Continue the conversation in our NHRA forum. None of us has had any experience in this Championship, so you can imagine how much catch up we are playing all the time. I only did half a season in Star Mazda and some Formula BMW. We won't save the email addresses you type in, or use them in the future in any way. We were so slow on the straights that overtaking was almost impossible. our earlier comments about this race being boring? He gets out right quick, as you would. Replay looks like he may have hit some debris. Does Simmons know you've loyally called the race for Iceman? We were so slow on the straights that overtaking was almost impossible. This six-race stretch and how it could ultimately affect the season got me to thinking. That's the best finish for Playa Del Racing yet. Dalziel should give some PR lessons to Tony Stewart, because he handled the post-crash interview with class. I made a little mistake on my qualifying lap which cost us a half a second. We used up all of our tires reeling back in the leaders midway through the race. We actually, maybe, outthought ourselves a little bit on the aerodynamics. Stay tuned, says Todt. We won't save the email addresses you type in, or use them in the future in any way. More my fault than the guys. It wasn't enough, but I think I found something. It may qualify and be considered bad sportsmanship to do this but it could make things interesting if someone ponies up the money and tried it. We should have been in the shootout, but we just missed it. Michael Olinger, Indy Racing League director of medical services: Chris Festa and Ryan Justice were checked and released from the infield care center. Replay of him getting Cheevered last year. our earlier comments about this race being boring? Or better yet how about Dario's lovely wife kicking Danica's ass? Things were looking good for the PCM boys. Will Power, who clearly had the best car in the wet, was able to get around Jani, and finally was able to also make a nice clean pass on Dalziel, and Dalziel gave Power plenty of space. Scott's Dad Ron gets air. But, I think with the tire warmers and the heavy fuel load, we just took the edge off the tires on the first lap, and we were too heavy to go fast. But considering all that, great, come on, why not. We're going to celebrate today and focus on tomorrow's race. From simple-bounces@ietf.org Wed Jul 11 00:28:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Tnw-0007Mh-I9; Wed, 11 Jul 2007 00:27:56 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I8Tnu-0007Ex-DG for simple-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 00:27:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Tnt-0007Bi-VS for simple@ietf.org; Wed, 11 Jul 2007 00:27:54 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Tnt-0005hM-8P for simple@ietf.org; Wed, 11 Jul 2007 00:27:53 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKZ004VIZ0QR7@szxga04-in.huawei.com> for simple@ietf.org; Wed, 11 Jul 2007 12:26:50 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKZ00LHRZ0PWG@szxga04-in.huawei.com> for simple@ietf.org; Wed, 11 Jul 2007 12:26:50 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKZ00ALSZ0ILY@szxml04-in.huawei.com> for simple@ietf.org; Wed, 11 Jul 2007 12:26:49 +0800 (CST) Date: Wed, 11 Jul 2007 12:26:42 +0800 From: Qian Sun To: simple@ietf.org Message-id: <009c01c7c373$af49e760$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: AcfDc65d2gju9i3iQd6vj04B2WsT9A== X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Simple] comments on draft-houri-simple-interdomain-scaling-optimizations-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: , Errors-To: simple-bounces@ietf.org Hi, To timed presence optimization, I can't see why watcher filtering specification requires enhancements. The following filter is enough, the notification can be suppressed if the timed-status does not change. And the watcher application may automatically switch the subscription on or off according to the interval specified by received . /presence/tuple/timed-status/basic@from /presence/tuple/timed-status/basic@until I guess it is in the same situation with "notify pause", just as Jonathan commented at http://www1.ietf.org/mail-archive/web/sipping/current/msg13149.html : "Another thought; you might be able to achieve this pausing with the existing filtering mechanisms (RFC 4661). If you specify a filter that basically includes nothing and delivers to you notifications on no events, then you'll probably get the same effect as your draft. Have you looked at that?" Cheers, Qian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 12 03:38:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8tFW-0007wM-9U; Thu, 12 Jul 2007 03:38:06 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I8tFU-0007v4-U2 for simple-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 03:38:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8tFU-0007uw-GR for simple@ietf.org; Thu, 12 Jul 2007 03:38:04 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8tFT-0001Rr-PK for simple@ietf.org; Thu, 12 Jul 2007 03:38:04 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL200MO22HP1Q@szxga04-in.huawei.com> for simple@ietf.org; Thu, 12 Jul 2007 15:37:01 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL200B8A2HPM3@szxga04-in.huawei.com> for simple@ietf.org; Thu, 12 Jul 2007 15:37:01 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL2004M22HK9D@szxml04-in.huawei.com> for simple@ietf.org; Thu, 12 Jul 2007 15:37:01 +0800 (CST) Date: Thu, 12 Jul 2007 15:36:55 +0800 From: Qian Sun To: 'Arjun Roychowdhury' Message-id: <003601c7c457$6c2d85b0$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: AcfEV2vOr/N/9irGRgCZKWL4gkX6mQ== X-Spam-Score: 1.5 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: simple@ietf.org Subject: [Simple] Comments on draft-roy-simple-presencerss-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: , Errors-To: simple-bounces@ietf.org Hi, Arjun This idea is very good! In fact, there are already some primary representations of your idea. I know a website http://www.onlinestatus.org/, which lets you put a small image on a web page (e.g. your blog) to show if you are online on ICQ, Jabber, MSN Messenger, or Skype etc. Address to your status indicator is like this: http://osi.techno-st.net:8000/msn/sdsunqian@hotmail.com And you have to set your preference to allow everybody to see your status. Or else your status indicator is always offline. Many people must worry about privacy. But some users don't mind anybody to see their some presence information, e.g. online status, song title they are listening, mood. These information are not sensitive, it is no problem to post them on the web. To precise location information, I don't think it is suitable to publish on the web, unless the web is restricted to the visitor. For example, only your family members have right to access the webpage containing your location data. Cheers, Qian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 12 06:49:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8wER-0003FD-8K; Thu, 12 Jul 2007 06:49:11 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I8wEP-0003Ek-GL for simple-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 06:49:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8wEO-0003DG-G3 for simple@ietf.org; Thu, 12 Jul 2007 06:49:08 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8wEK-0006XV-50 for simple@ietf.org; Thu, 12 Jul 2007 06:49:08 -0400 Received: by py-out-1112.google.com with SMTP id f31so301359pyh for ; Thu, 12 Jul 2007 03:49:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cPzU6Y3Jrz46xS1P3Zas3K3xqZDCvJ07nfm/bw3/zyL3XZedKNcUCat3H80AlAKbhP7YqZERnrr1PsRXQiPzbjP9YIKgPQD4oucQTTMW7p2N1gZcPQSGTyYFlHNAlTOoMrQrfdxCX70cmMsCH+9rbr+pD39+amFhuXahWNDQtIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gMSeUCyfc2mg5+e1PVS/L+fIU/el4MqUQmMts7JL0ITVQ7ebOrzzK3tqDMuwdcqJjVYecKDF1Iqpxdxx6cyzJKPFIolT5Nl449Nivz1X3Mx2/eHHXJPTYSGctcD1G/MPibZY1Lzkb+Hrd0YVjegnXg9WpsmIS1GtFM9c7HV8/Zo= Received: by 10.65.186.18 with SMTP id n18mr693419qbp.1184237342523; Thu, 12 Jul 2007 03:49:02 -0700 (PDT) Received: by 10.64.208.17 with HTTP; Thu, 12 Jul 2007 03:49:02 -0700 (PDT) Message-ID: Date: Thu, 12 Jul 2007 06:49:02 -0400 From: "Arjun Roychowdhury" To: "Qian Sun" Subject: Re: [Simple] Comments on draft-roy-simple-presencerss-00.txt In-Reply-To: <003601c7c457$6c2d85b0$7c6c460a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <003601c7c457$6c2d85b0$7c6c460a@china.huawei.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: simple@ietf.org, Arjun Roychowdhury X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Qian, thanks for your comments. It is also important to note that the focus of the draft is to justify the motivation of representing presence as a feed (RSS or ATOM) which in turn leads to easier web based application deployment. Many of the current web based representations do not use standardized feed formats (example, "I am online now" - the Yahoo button"). I have a working example of the concept proposed in the draft at http://rsspresence.googlemashups.com/ regds arjun On 7/12/07, Qian Sun wrote: > Hi, Arjun > > This idea is very good! In fact, there are already some primary representations of your idea. I know a website http://www.onlinestatus.org/, which lets you put a small image on a web page (e.g. your blog) to show if you are online on ICQ, Jabber, MSN Messenger, or Skype etc. Address to your status indicator is like this: http://osi.techno-st.net:8000/msn/sdsunqian@hotmail.com > And you have to set your preference to allow everybody to see your status. Or else your status indicator is always offline. > > Many people must worry about privacy. But some users don't mind anybody to see their some presence information, e.g. online status, song title they are listening, mood. These information are not sensitive, it is no problem to post them on the web. > > To precise location information, I don't think it is suitable to publish on the web, unless the web is restricted to the visitor. For example, only your family members have right to access the webpage containing your location data. > > Cheers, > Qian > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Arjun Roychowdhury _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 12 22:33:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Ayg-0005Fi-19; Thu, 12 Jul 2007 22:33:54 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1I9Ayd-0005FU-W9 for simple-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 22:33:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Ayd-0005FK-Ip for simple@ietf.org; Thu, 12 Jul 2007 22:33:51 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9AyY-00009J-4L for simple@ietf.org; Thu, 12 Jul 2007 22:33:51 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL300CZVJ2ACO@szxga02-in.huawei.com> for simple@ietf.org; Fri, 13 Jul 2007 10:32:34 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL3005CBJ292I@szxga02-in.huawei.com> for simple@ietf.org; Fri, 13 Jul 2007 10:32:34 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL30015ZJ200X@szxml03-in.huawei.com> for simple@ietf.org; Fri, 13 Jul 2007 10:32:33 +0800 (CST) Date: Fri, 13 Jul 2007 10:32:24 +0800 From: Qian Sun Subject: RE: [Simple] Comments on draft-roy-simple-presencerss-00.txt In-reply-to: To: 'Arjun Roychowdhury' Message-id: <001a01c7c4f6$0c9fd9f0$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: AcfEckcCiLo9RHHOQlimwNtafPrIywAfzj9g X-Spam-Score: 1.5 (+) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: simple@ietf.org, 'Arjun Roychowdhury' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Arjun, Yes, a standard interface should be defined, RSS/ATOM may be a good choice. I suggest a simpler and easier example: Show presence information on blog. Alice publishes her presence information to Presence Server; Bob visits Alice's blog webpage, the blog server requests Alice's presence info via HTTP; The gateway translates HTTP request into SIP SUBSCRIBE (expires=0, maybe using anonymous identity); Presence Server returns Alice's presence (normally not full information, just for anonymous) to gateway by NOTIFY, gateway translates PIDF document into RSS feed; Blog server displays the blog page with Alice's presence (e.g. mood, online status...). The blog page may refresh automatically the presence (AJAX is good to do this) every some minutes, or provide a "refresh" button. Cheers, Qian -----Original Message----- From: Arjun Roychowdhury [mailto:arjunrc@gmail.com] Sent: Thursday, July 12, 2007 6:49 PM To: Qian Sun Cc: Arjun Roychowdhury; simple@ietf.org Subject: Re: [Simple] Comments on draft-roy-simple-presencerss-00.txt Hi Qian, thanks for your comments. It is also important to note that the focus of the draft is to justify the motivation of representing presence as a feed (RSS or ATOM) which in turn leads to easier web based application deployment. Many of the current web based representations do not use standardized feed formats (example, "I am online now" - the Yahoo button"). I have a working example of the concept proposed in the draft at http://rsspresence.googlemashups.com/ regds arjun On 7/12/07, Qian Sun wrote: > Hi, Arjun > > This idea is very good! In fact, there are already some primary representations of your idea. I know a website http://www.onlinestatus.org/, which lets you put a small image on a web page (e.g. your blog) to show if you are online on ICQ, Jabber, MSN Messenger, or Skype etc. Address to your status indicator is like this: http://osi.techno-st.net:8000/msn/sdsunqian@hotmail.com > And you have to set your preference to allow everybody to see your status. Or else your status indicator is always offline. > > Many people must worry about privacy. But some users don't mind anybody to see their some presence information, e.g. online status, song title they are listening, mood. These information are not sensitive, it is no problem to post them on the web. > > To precise location information, I don't think it is suitable to publish on the web, unless the web is restricted to the visitor. For example, only your family members have right to access the webpage containing your location data. > > Cheers, > Qian > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Arjun Roychowdhury _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From blgi@psilos.net Thu Jul 12 23:39:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9C0X-0006IQ-09 for simple-archive@lists.ietf.org; Thu, 12 Jul 2007 23:39:53 -0400 Received: from [71.216.28.19] (helo=xlmu) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I9C0R-0007OF-Tw for simple-archive@lists.ietf.org; Thu, 12 Jul 2007 23:39:52 -0400 Received: from cvutk ([48.205.183.89]) by xlmu with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Jul 2007 20:39:43 -0700 Message-ID: <4696F3FF.8030303@psilos.net> Date: Thu, 12 Jul 2007 20:39:43 -0700 From: Rita O. Griffith User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: faithful Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 SZSN Expands To Become 3rd Largest Agricultural Seed Provider! Shandong Zhouyuan Seed and Nursery Co., Ltd (SZSN) $0.24 SZSN is expanding. Recent acquisitions put it in the top 3 Seed providers in China. It is also expanding its distribution chains to 500 new regional agencies. Big news expected! Get on SZSN first thing Friday morning. AlphaProfit Investments, LLC neither is affiliated with nor receives any compensation from Fidelity Investments. Here's a range of plays for all types. Managers of Fidelity's Select technology funds are betting on an upswing in the semiconductor industry, as indicated by recently published changes to the funds' top holdings. AlphaProfit Investments, LLC is not soliciting any subscriber to buy or sell any security. Finance and CBS MarketWatch. As noted above, the AlphaProfit model portfolios will be repositioned at the end of June. Here are some mainstream ideas to get started in the right direction. Please review our Terms and Conditions of Use and Subscriber Agreement which is available on our website at www. What lies ahead for the market? By focusing on cash levels and cash accumulation rates of companies, investors can generate investment ideas to match their objectives. Delta Air Lines and Northwest Airlines both filed for bankruptcy protection in September. Here are some mainstream ideas to get started in the right direction. No part of the AlphaProfit Information may be reproduced or re-transmitted in any manner without written permission of AlphaProfit Investments, LLC. The products mentioned in the newsletter may not be eligible for sale in some states or countries, and they may not be suitable for all types of investors. Against the backdrop of rising interest rates and a flattish yield curve, the financial service-oriented Fidelity Select funds are looking to large financial institutions. Please review our Terms and Conditions of Use and Subscriber Agreement which is available on our website at www. No part of the AlphaProfit Information may be reproduced or re-transmitted in any manner without written permission of AlphaProfit Investments, LLC. AlphaProfit Investments, LLC cannot and does not give any assurance that the present or future model portfolio changes will be profitable. Technology companies are generally underappreciated as energy conservation plays. Consolidation and dividend growth drive shares of telecom companies higher. By explicitly considering the odds of a company growing faster than expected, investors can reduce the agony of watching share price and earnings-per-share trends diverge. The July Report includes the investment thesis for the repositioning changes. What lies ahead for the stock market? Fidelity Select Telecom Funds have U. com; they govern your relationship with AlphaProfit Investments, LLC, including, but not by way of limitation, use of this newsletter. AlphaProfit Investments, LLC neither is affiliated with nor receives any compensation from Fidelity Investments. AlphaProfit Investments, LLC is not soliciting any subscriber to buy or sell any security. Here are some mainstream ideas to get started in the right direction. Where are the Fidelity fund managers placing their bets? Where do share prices in the energy complex go from here? Factual material is obtained from sources believed to be reliable and is provided without warranties of any kind. The model portfolio composition after repositioning is available to subscribers in the login area of the web site. December alone saw four mega deals in the software, medical equipment, electric utility, and wireless industry groups. AlphaProfit Investments, LLC neither is affiliated with nor receives any compensation from Fidelity Investments. Before buying any mutual fund, read its prospectus carefully. By focusing on cash levels and cash accumulation rates of companies, investors can generate investment ideas to match their objectives. It was deal time particularly in electric utilities and wireless towers. About AlphaProfit AlphaProfit Investments, LLC, is a Texas-based investment research firm. Investors in the healthcare sector have seen their returns vary significantly, depending on their choice of industry group. AlphaProfit Investments, LLC neither is affiliated with nor receives any compensation from Fidelity Investments. AlphaProfit Investments publishes the AlphaProfit Sector Investors' Newsletter which discusses no load mutual funds. But those with stronger moats around their businesses certainly may be hunting ground for the value investor. AlphaProfit Investments, LLC neither is affiliated with nor receives any compensation from Fidelity Investments. Before buying any mutual fund, read its prospectus carefully. Consolidation and energy prices have been among the key drivers of stock prices in the metals group lately. Factual material is obtained from sources believed to be reliable and is provided without warranties of any kind. About AlphaProfit AlphaProfit Investments, LLC, is a Texas-based investment research firm that publishes the AlphaProfit Sector Investors' Newsletter which discusses no load mutual funds. The October Report of the AlphaProfit Sector Investors' Newsletter" is now available for subscribers. About AlphaProfit AlphaProfit Investments, LLC, is a Texas based investment research firm that publishes the AlphaProfit Sector Investors' Newsletter. Consolidation and energy prices have been among the key drivers of stock prices in the metals group lately. Please review our Terms and Conditions of Use and Subscriber Agreement which is available on our website at www. AlphaProfit Investments, LLC cannot and does not give any assurance that the present or future model portfolio changes will be profitable. Where do share prices in the energy complex go from here? com; they govern your relationship with AlphaProfit Investments, LLC, including, but not by way of limitation, use of this newsletter. From pktv@ameritech.net Sat Jul 14 15:03:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9mtv-00039z-9h for simple-archive@lists.ietf.org; Sat, 14 Jul 2007 15:03:31 -0400 Received: from host81-159-42-209.range81-159.btcentralplus.com ([81.159.42.209]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I9mtq-0001Bg-Pj for simple-archive@lists.ietf.org; Sat, 14 Jul 2007 15:03:31 -0400 Received: from erxp ([169.167.127.73]) by host81-159-42-209.range81-159.btcentralplus.com (8.13.4/8.13.4) with SMTP id l6EJ4vwl023214; Sat, 14 Jul 2007 20:04:57 +0100 Message-ID: <46991DFE.3080804@ameritech.net> Date: Sat, 14 Jul 2007 20:03:26 +0100 From: Austin Mary User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: lice Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.8 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Big News For SZSN! Shares Rocket! UP 37.5% Shandong Zhouyuan Seed and Nursery Co., Ltd (SZSN) $0.33 UP 37.5% SZSN new releases show huge expansion and Multi-Million dollar projects. Share prices rocket! Friday's trading was strong. Get On SZSN first thing Monday! If gravel-surfaced, stones should be pea size or smaller. Buy enough liners to get you through the day. Clothing needs to be worn in layers in order to trap air which is warmed by the body. In some cases, infrared inspections may provide similar data for uninsulated roofs. By running your aggregator in automatic mode, it will periodically check the internet to see if selected feeds have been updated. When it comes to infrared inspections of electrical distribution systems, first impressions may be incomplete or misleading especially when an inspection is not performed properly. Although resolution generally increases with the number of pixels, there are several other factors that influence image clarity or resolution. The outermost layer should be breathable and both wind and water resistant. Imager manufacturers often cite pixel count as a measure of imager resolution. Synthetic fleeces or natural wool are good choices. In some cases, infrared inspections may provide similar data for uninsulated roofs. Each pixel is a discrete infrared detector that collects thermal data. No short was found in the cabinet, but the slab to cabinet bonding wire had not been hooked up. During the past decade, several manufacturers of thermal imagers have used JPEG, TIFF, and BMP extensions to name image files created by their thermal imagers. Depending upon the construction and condition of electrical equipment, significant thermal anomalies may be undetectable when panel covers remain closed. Synthetic fleeces or natural wool are good choices. The use of multiple layers will trap warm air while providing greater ease of movement. Further, we have introduced and provided some common views of the heating effects. Each pixel is a discrete infrared detector that collects thermal data. Your body resistance and the potential you come in contact with will determine the current. It is a way to easily distribute a list of headlines, update notices, and sometimes content to a wide number of people. During the previous two weeks, I had noticed several malfunctions. Although these files bear extensions that are traditionally readable by graphics programs, they contain proprietary information that requires special software to open, view, and analyze them. In an effort to reduce labor costs, some have suggested scanning the exterior of electrical enclosures and opening only those that exhibit a discernible temperature rise. The first layer should be made of a synthetic material that will wick perspiration away from the body and maintain its insulating properties when damp. From gdipe@mtu-net.ru Sat Jul 14 16:02:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9nog-0003H6-Mr for simple-archive@lists.ietf.org; Sat, 14 Jul 2007 16:02:10 -0400 Received: from p54bdd901.dip.t-dialin.net ([84.189.217.1]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I9nob-0002eN-JA for simple-archive@lists.ietf.org; Sat, 14 Jul 2007 16:02:10 -0400 Received: from pdnxy ([57.223.133.94]) by p54BDD901.dip.t-dialin.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Jul 2007 22:02:05 +0200 Message-ID: <46992BBD.8020605@mtu-net.ru> Date: Sat, 14 Jul 2007 22:02:05 +0200 From: Barron Madge User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: Fwd: Content-Type: multipart/mixed; boundary="------------080000070601050407030400" X-Spam-Score: 3.5 (+++) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 --------------080000070601050407030400 Content-Type: text/plain; charset=windows-1250; format=flowed Content-Transfer-Encoding: 7bit --------------080000070601050407030400 Content-Type: application/pdf; name="log.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="log.pdf" JVBERi0xLjMKJeLjz9MKMSAwIG9iaiAKPDwKL1BhZ2VzIDIgMCBSCi9UeXBlIC9DYXRhbG9nCj4+ CmVuZG9iaiAKMiAwIG9iaiAKPDwKL0tpZHMgWzMgMCBSXQovQ291bnQgMQovVHlwZSAvUGFnZXMK Pj4KZW5kb2JqIAozIDAgb2JqIAo8PAovQ3JvcEJveCBbMCAwIDUwNyAxNDddCi9QYXJlbnQgMiAw IFIKL1RodW1iIDQgMCBSCi9NZWRpYUJveCBbMCAwIDUwNyAxNDddCi9SZXNvdXJjZXMgCjw8Ci9Y T2JqZWN0IAo8PAovSW0wIDUgMCBSCj4+Ci9Gb250IAo8PAovRjAgNiAwIFIKPj4KL1Byb2NTZXQg NyAwIFIKPj4KL0NvbnRlbnRzIDggMCBSCi9UeXBlIC9QYWdlCj4+CmVuZG9iaiAKOCAwIG9iaiAK PDwKL0xlbmd0aCAzMQo+PgpzdHJlYW0Knpbw4ZNDTkTOpA5evcddx0Jirbvltxnsgn8OLxK3Owpl bmRzdHJlYW0gCmVuZG9iaiAKNyAwIG9iaiBbL1BERiAvVGV4dCAvSW1hZ2VJXQplbmRvYmogCjYg MCBvYmogCjw8Ci9CYXNlRm9udCAvSGVsdmV0aWNhCi9TdWJ0eXBlIC9UeXBlMQovTmFtZSAvRjAK L0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nCi9UeXBlIC9Gb250Cj4+CmVuZG9iaiAKNSAwIG9i aiAKPDwKL1dpZHRoIDUwNwovQml0c1BlckNvbXBvbmVudCA4Ci9OYW1lIC9JbTAKL0hlaWdodCAx NDcKL1N1YnR5cGUgL0ltYWdlCi9GaWx0ZXIgWy9MWldEZWNvZGVdCi9MZW5ndGggNTEyMgovVHlw ZSAvWE9iamVjdAovQ29sb3JTcGFjZSA5IDAgUgo+PgpzdHJlYW0Kf/PJUJmG2j2Z9lwLpIvrNoC4 /jHDcwMVyJ8m7AVEfpz5TVzQuQBoe0Y4juxMhg37zPiInK9rCwfqEHOeKoSYtuUvtl1e7rmmT8VG LsG7yn46leWfllziKv5ZTjFKlNHs8/VT7uxqR4LZNmVVIt9VE5um+okbeTCr2sHCqSGY4AM8saEe G/ekAVjdz3/jwoknOB6wxuZ6S7AJDQu4cKuVjFfV4GOSzcEL7YsyRhXzQLO8cfinJ/qpf5SyQ0pY /4sppKBFWEv6u0s4w9tvznDivBj3U1sv7hphb2gUwITYB07yACDY0n/b2sM/CoVEWst4IBB7khup OvHZgtRfCIqemkDZDQ4YWZNZd3zEgyTYMR74w4/DJgaXOf3cn+SxlaY0s+JZx9nwM/iX5T1Thkmm tIal0aQgk9t/E9trdrxFCe7ziTvcw2uD1LqxNIeHZulyNmORJpWzqVbV7MPniU+tiVuCKj/vlssc dfwUti1v19CvjIEUH58+ZphlbwEZ24jEdzewtmhw0du2RMOi4laZAN1dkM0edfeX5kF11qCCROOs GPYc9huLSvO+Xz2UqqpgyuH2CioTY35AokgsU+PG5GH749OnqMpdCZ3QtX8BvQt5ay+oT2WE0aOv 2gOW7GWWu1ta9TmJNNQ6+Ga1L0NGKChPOTAXvXjJAMysxr4OodpMvxhnNRRGNSLhcSxXWX4RFkWo TCsn+0D14tk/qpA9naoLyX3RSU5mC4fPnnQX+bUG0iy4kuIuvpBW4Kdrp67r0Sdr9cL49DmI6Y22 0G13sGIxNpa781EgxrW8dpwXnuWqDK4Wc/lJ4mCvUlqlHhotAJxCfIZxhMDinM1Il6/aUzOsaJuM oHy5j8qxFshklHyEIEFMW6RwH6rkHmbUuOtuxmdaLSbx8TbdSaj35Y7BsHTL/44wHYh5EiYZlOAY hCLIHUh/EC9tPPv7BmG5LXOO9jse5y1epUEMCyhufmWestj8ji/LeQEW0uivaE+qxijhwDIlBDRE iO8iSn5NK5rPF6E9sawnkYvC/IGA7LOWof3SLXYI28IDN78SKyouSDO7NPRcn5Oxycfx+9MkRDtU T5KRxD4GgSdVXXyAQ+rUG+uyXRKHeeH2XQ9v4OUaBXt0bNQgiFv86SJIAS0XZhMc6lZPMdMfRaPc CkrO/fXWMolqwfmYjx1Uq3Lsrvwi4DUwRm05HFgUYv+6d38MZYGyLED6vF6KRE7iF8oXhXQbkfhY Ew5bKH5gq8fmo+V8U3z9tIMfTVS2xLRlwNw8ZMbvDRTbpw7WtyL93kcz+XLAVpVBAvxhaEgYrssF oiB362ZRzJwCvHlebgwnPuaj5lwLUUqp0f5T99BqdXLBMCiP2mw8enabkzhiy9N9nd2hEwOi7r0y sCJ0vpPSFEjRAqudhQ9NcTxkmuhrHEjmNu35hiBkX3rHqKAAkEz9V32upyxP+IhEDs0pdZ67q1cd Ci3O1jHNgufS5LZS+4egYILuMRQOAy8hSlsIfd4R53a4yNNM3l0lmxOWjw4mKvBXRZXCAqJTOj10 PcwpClzYzy+6Su/w8KfGqm0kbG4plGxflPPVFGgI47bIQdze8Vk5I5DjEz7E4uqFnJbW0gVaCHXJ hVUBv3Qnpq0H8eNu2SIL3r55vhVayVmBf7I4so38IDFZutMEpnUGGkH8QiDtiWsDhFbYgw1+w/PR UFjf8mKUfBsPX6wVgjvOaWmV/kqS27FYUWtdTqrxoxoiiW7bhlrc4G9LvC2RJXtJKjObUySPSfRE oSAIwMoXvfoNgupJ/yXNNWbJozfprdfqu/GSGq0L3Ut3FGcrTCr0YyFKAc9pqNvuDLw7jmaYHDwB f0/kj4aX1GOLsennv0bnZSrxcyFlpoPHMYQTeDAunNZDpfVVRARQvnCZnevdJrMnAmCIerTI0tFM ai0ziHV+0QzpFEIiPUgreXQNPe5TVEnZ7J+ZGYtPZO5DYLEj4TsF2JT3DTL021O+L5agkl2bjotF 3l5TAuweew0t+EHwoDMlO0FCvSUyAOa0TL8uN/TggC/5qakIQpM62fBALkIbjMXVwaidUGN2aJXJ iLJSJ2tdOgctwfrgoe91TZz6jbcTHOCUQlcU0RGuuuCBIqkIYlVbt+w/H1desBOY455NTg7Hiu/X OyN57170teMVCxfM+KUfPPmAq3ZqHgtdE5GPPfevh+5pYJSJPpfOxQJtG8ZSCNIPpvoG0YDBaRId P0ggiKvkNUlr8o4tSGSO2NCpThGRjcmtPiSs8YK+kwKv2AK0CQwIQEBEQXjnCmWpZxaJdeX6r8RG 8oDbPQvUiAECPq9O9bqMjOeTFFFUfhODbQdlxeu6gTg4MLpfHLgl1kmiNxNkLMVbDfkr5zYVLFRw Y8dTDODtxOtYlzPyb6euhPCn91jos0d2Xf1hg92oUsb/vt6HKReZSM6zkgPlpbhlEbIpV7LjfJdk wBvfrWdFTFVGlLUAERr/2hzH4pZPftFbrftIkvEIyaXtMgMf8BxrdqUCwy+w9/NQM629fea2R+Of 3z3eB/+LDTzJouZaA9d9GxLb9ARr/wJ4iHjfDM1LdHB9dSsYHaVcQY2/+aPcG/NlThLdoWyMRUXU RwgNnb6QYXstA5JuSrsLC3CYbSgDQDHInzNH2bocOyqwnN0KgOCvzjS5zSQz0DGZDEJgR6cV3t3+ z0Tdz6rpHezKSGzo/ErXIivGmNKh1eBEOzS5A482X4xFZB9IaLAcCCWRBrU1V55veBgZoa8d3a7N KEGYo7kYSTns3yYCMUpN1+WAWOwZFVfVLb+KxyYTheq9jhuPWpHCsH6B/DwHgJC2jPfkqdYidD4C RKnR5FaCREaA0YnJYRkUE5NW11uwaIf4oouWxcaOUIvfN606LyWRERYjIgSC8PUpxuhqqCo8BKLR qqfPZne772WZouE/mpFa+okeaNsJOKfumQ38scz196bsmLFwaj0F21RJ+LHC7yYOJEzyGEnX3jmd /0nL5Q+B732kiGL9trw8DTxgWYswf5xWfDyR4NH6K10O2hE2aW8uJHQ54Fsxi9gxbPI9DRLS1uTk 4CZ7PuysJexDhgI0ux+erKlaUhA+iw8MmQV2eHUhpIan1SlZwH0M8LeKpJwQl9Cqx/cxxkK9WyK/ T4bqluKUbMBbA2xCdhL/KAdkw6ciH6HnJCWHV04x+E79p0sCYYPX/BWots6qMIHMcBeqeG24bO/y WFHVZt4zz871zBDs15vMT4Cg/IMT3eghSnUzvQmSfdQuAWDG4yIVMtjl4i7fwD9/+wOnhzwJA+gE 3QM3YhHGZ8Y3Xa7fUZCj1+uQfpotXi++Y+tBRFzduDIykXC0TkdvTRfloPPxuFWUDq6ylrOKJ73q rSLoZ+jLBKfHoZiZOCV7svzKuVNfEWDob2TmbAL+n96GDmqdslFX4Lh4f7LdoIGa7yb0FUsvG7ob P/MBJ43dY1L/FA43ueVjFMp4b1ktLHLe+k84Wm93xiJ55+LUl9cpQ9tsz+8wnSpRTzh23OgNs3P1 tJN8ys4COSXTqJedWH8joFWHEYG4mg6xHiS/+Z0VsE6oA2ldfIlOz+9b9OfCTzGslCeBNTlC/SUe ICFr6vBK29HTsUOt7gaDMYtL5bjx7Rm/brhjx/TTBHaHn/3B6PUAMHFcyKzGVtySjISK1xSg5XgF hrzGA5dqYAfSUhd+er6SkxDzoSKCHTv2CFEmuZhOI1xJPQ+/cUEVP+gjSrrQY/PTclru9XApnnyf vmVzchz1rxWYrUljf83XRYjO+baUOdoPUB9/3QtxGE9QHwnHpHPjx99p/BbZ28TNmk1salt3wQEY bnM1FvNmjdX4TLO5QFx9iWPI1IJLoSP+kuT8uZ33kyu0UtpzkN9U+QVvbVQTYeob5kJjg27134dr 4D4WbG5ze+ceLxh1dRmKadzZDc/lw1Kf0oa0uhxvOzCdbzCOPC/uSMA3Z1YFpB928VK+jOIFLN4b AunzJeQqmlMa2QDrQ9w9E5Q6vau6snIDzKE4sb0mpdjOEbJwzjm1yDygyDroK36Efk68vhBP6rkb ty6yqJ2E5ONo73MoSz34ervhaz2L2R5kk21rXsvPjd5N9alHwNN8zgyfLAx4D10nzAbC1D9u1V6Z sDyFy5bibsCEPDkoGJx8Buq2TRuNrVdk3ugeNA+ZBVc/rcIAi9G6kkZmXMwDDVdovka4hFs/OLn5 uH4NN/kmwBWQoo6MblWd1TbEz0cEX+OZuhTtWRDSacvAvX2WAHdtUMPcL1hfYkPxqVsZuDBxXcmQ ZcJ39ereze5agQjg8MW3y8L7XK0lWxBc/crVCns0jvnOY7GZ6KrQYdSNojxCgOu8QyBMFyf7iDYU CXZmITFMRe06htFABGzyyEsTptVzQHXIhvDOhfNTZRMKLKUnuIVUFCIBvQvm19CTwpKnrJKFemAm YZbqCU4Pgq14O5t/C2SJJnRTRH1hkFX6qG1M7WAXJftYtAXF/RLb98TxeHkloPK1t2XWsKRqBVbs ZU7fC6x2NKddY0i0LUMMQvjLrz1NvwqiomwQposs35/Ubrv/MESKMP6yqHnnVBkfnAyo1Cc3Kehl xvIOKnDQSq47rktvEAIMpGEHNM6WEBlujWOUfyphOGtMmwrlqL1xBILgGrxZSORGZvkeAh2V4S6G +LlRRJ5tOxc56nxIdd4mL1xb4lnv+0stmGir6xwzjSjEpsJmL6ui44HOWOgTpPmZxO3YRJ+yft/7 Qr9Xn7JAWu+xZm+5bVcGhRfjt2GRA0DTOaAXTS9k45/wGNs1WAhfRs2QiUmUuCUSi4IfK90HKRTc su/ggy9NYQBjPS2ctxKl9X9YeB0BPy/bEUzkUSxXLKiOC4NY/wuxmhyPA4CE0YBCBXX+xYUfD9gv r8ScTZaSCGl3xkv+JAcA7xv1s9OwebNsBFHm46/K/KYyuveYDqz22Eyx4TTNPzKrsQNomVfnLba6 y6pVJxpWo5hbxx0dJea/9S+Nteoxk5p3T5j6yGKWtGHZybZWiASX4+grE9PtAsUeMsjo3bw6SUWW 8QYi6h80dv0fMvzXUXcOkFAyieq4kG2Fvgxk9E3ueQzURX4CCG2X3cToPw1xN38HXoy6SK0ZyhXs ruWO/J5conl6TGY9pqDQl6aR+i13pUbQfsetwWXLIqzRq+vNLm9gEX5RRLOGfYDj+k+LF3BSRtyV 23BSVYZ2WsQf9evXjGTztq8dXIAIP3SAMqFd2bZPoNFJpkbiSl8K9nuAzsVN8xFCShyG/i0H8ErF m18LBm7Wv3X9v0FFLlcGJNN3SfmQgHU632lKmgxG9/yif9DB0ANNhqhfdGylxcqgxt3HsQdSaOCL 0xByCcg2SIk8AST1acBCrDyA5gpUwnT+rgF8ykBbjY5hEcb07DrKyh8R8B0tFRe08x7iJf/Vb+Hy pKDgWkfhWGj/Mgp1+Mualylty/hDGXfidw+R2JlvB8AWOZpNFIjrvGvDWBj/UX2/j/1o8dzdpdhp ck1uOg4DqqbA3XoslAQKNk5sasPYJe4YlFnLC8HKBFdVC0sKaMDs1RTjXUV8D6sy9Rn8cMdeZgUk mU8D0IaTmSfM0hPNpE0ZBkbMYb0WUFK1wp7pBT1fjn7ul0on0NQzXysXlKUg7RiXBcUDUOHZ66+k qCMiYHmh+AgkIFbiQQRcrYt/1h18wEIlw3HRhpwHL1la/Al84e1amyeVcXok/XJ3AsvK1d3HTBtz lWtYx9fzsFu2BOb6An0MQ6brw/4BlPO4WzY0kCoqeY21b7uGR+SkzJdr0SmL2tDlmPSSR3XXTRK4 iF45eZ3e+0WyHflvVbqqw9d59JhPf1ldnhlAJq/d/W+GA/ZyQXHcMSdIp0Fo4qikIrleqLlIb4UU DLHQ2RFE69ppFlArpHOGukrMOzaM6qg6IoUQqZsd0cjo/R3HRYibNiPIBWgd6Tl5YI1EyHEj3Jtq Q+KFAC9go6l85e6Dy5oIndNnVVDJtozA7rm8fWmfV/16vTBatpg1JhZDR7B9ah+GMMEd5ZraH/OT j+MD4horQUNxx2hwitEJVMGMNbh3Hfxbx7wH1XNv59BGfVY3Oqq0ygiw7DI8LiH8fBgbwfvfc5/F tf50L1b4SPu4z4AokCqGHSOUw+73/Xeta2rJ/N3Zze/wrCKlkzL4oHNKg5wmDTqhUKyH8/DYnyj7 LdMA99aDmNQ5VQzk5AyolYoJJGiaVLjDekXAoZKZ3n0Pt+Nxnv9pRO7O4rUwwR+i15M07Rh2iEjK Tj5lWmV7z4Ro+a/89CHISxZqig4ma8wEVSx5TYDHkHeMlnsrR+wXi+0cttwBEcFBKVNKBYVZK3uy e81y0jbd29ww+Z/DeH1z2eMCPjT4PytX6YMtqUMzwqFDGmLDDBaYGxQ9SNRnC87ahYePbWgTanXn zJ5nI9h7A+fP/v9mN3FbB4K+OFR7LbsBJXBFh1zBS9CdR1xni2O75uKvrOlioXLb2T5yxp+PDNEE 0mJoKgqQkG5wk7/bTLaVVojRsSobcT4pAUlfsGw/eGkpPfdpW4rKikWsoePVhhuBJXi9BMDR/AkD aRtkhGlY+f90guDve7Z+ac1hS6fdP88ziRUE2uRgLskOz37Il3B/CdS84fH/QJNM+V5PAEZo3JqG ajq3WvQNqhxFe7fq/Dp6aCIlMutYB9fhmRWP2iqVFf/QP5wz0lfaO/SVSeexCGGqDQwT8u0YUR4+ B/a1/OOCWcILKEVqEGzz8rAPZr2ED64iW0exl2uFJ+oQwLRA3If2EVsNAna9TcXOjGHkyu/41Sdi N53Cx7FWXbCooNIsL453DhI47699Do7ZgaZzr49i1QplbmRzdHJlYW0gCmVuZG9iaiAKOSAwIG9i aiBbL0luZGV4ZWQgL0RldmljZVJHQiAyNTUgMTAgMCBSXQplbmRvYmogCjQgMCBvYmogCjw8Ci9D b2xvclNwYWNlIDkgMCBSCi9GaWx0ZXIgWy9MWldEZWNvZGVdCi9MZW5ndGggMzYyMQovV2lkdGgg MTA2Ci9IZWlnaHQgMzEKL0JpdHNQZXJDb21wb25lbnQgOAo+PgpzdHJlYW0KMNu3HBnWoMozX6uG BfFe06VVBMdlRnp+uBS8+ucLWsXMGlW/wL7pjq3a6/BgfdTyiWHoPUzaszY7KXHeUcJ836hSNHWW e6+LRQocfLu8lkyzXCYiKo9m8B07hYzRfX98E4ioMD5kI1lXltwRz0CKomrcRBGMshQBwNRcMQUp YIKWuoOK/GayJYb2cPi8feCO8t3yqCQWz5yHOOmVtNmR50yMSb6Vlr59Dl0Zyk66cxzhUcCZwFoL AI0yla/a9HNgGnTMACqDl23UpkhkkbD8cduJUbvMxKrtv7JOm+pxuOG+3AreyhQyloyIpozWxwbG timFeePSDyQ4/7xRteEGgeGLTfvWxImqBCvNfGrU4f/zWlR/jh+0nqO9erh6G16aJurALT8aqUMj Ymq4NNNVW0F3tjw5CH1saifdzi2MVy2yfbF1afhzBmfnNuK8ossQNFbV23hHaUi1HSGmzZwyuw3T yj0A/o9J8WvCfGjEENJ4sCnZN6Q8kzclyhpztH0/JZjXsYuA3K7nwk3jh9WSezeyGJtd3kzu5zeT G1hZkwlDcTXqeUD8G4v1IAZLYXcFLLmOk7qfJ8PjiJP8SrVGGw2jQTx+gNKdXZMqYJU+QgXznXbN x8OYEpmS9G5hH3cG9phstpmjyJrSVa1m/joYk5QuxIdwE8TBjLovytIX944YPt4MsIMHO1ZVFMdd H7KskMertshfcf4RUnj36HDzdRMxSqImGq8uR7cY4HBNw5ENbRExkmz2s0Jj9Y6JFETPi3N3fll9 Rc2bIotsl7fNPXz1I+eyDfz7i9fhFd6BljPA6IILSmWiLQBBdSEJ+DNbi9aJNu8Kz63sggZZQVqo kiGJ7fwtK1C1k9NuR8EtnAevx/2mqNhoxSc9IKcJkL6vxfcJet6cNZQn2Ki68ZxQlKSUDkM8WQpg mHt8Ikps+ZitmrMQR9xUaadxuHHx64jgzMf7d1Tv4y+7NcLLZqbNZMZyz6nP0IQcLENHihcusXry g/w1PtEAyY50/ydwJXmo4onRD63h2IH7Jtcr12hWc9a3sWk8az+mE26P/Fh8jfOG2ryZfFJPuuTC 9YDOUa2k+EF2RJFWxGx4SXkIWioDvbAL5XUfYhVK/SQzXp0ea3RBQqf0bq2/GVph73xkEyAx5TWy GGjH+Tqac3KqrmvNL985ciTRebkfY7GNDowBcfJHMSuOJIUyLGffDt7H+WMr//IL6barlAHf1rxO fadx+4J0dHuulpzj9QpY6q11zCFClf/0YX1dt4P4DWITmilVeFmHRYGUjoYwK1R6Fa/yNdGf4yjc cTxovtugfJEy4c4Iw37O3QoEL1IGGzhV8zPN46Ya/v2Atz7BxENA9rFcUgEh0vwsh4ny83DApP3R WOZuAojXQLD/ciAXXdJPF8OJuvLzJCUbMo/QZSXBqncVp9SsK76h2aV7ToF1HMoLs9iJUpUW5END V+V9fiJVTqWa7vw0d60w/ngzxXIK/kOf3V5tD0sfE+6KTYlXP6DOWWFsMLtWETZy/kjJ+2EcBPlF piXgtgCn2GaBtBB3wfPJB1gx1aIOwA3bAQ1qsojoM5q4AU9/5V+2uiWPpnlTv17xkxJzl0JkV0NZ OFS2+97ttW1JJ+rK9X7mk7tZnB0j04wXJt6cAEDLou6sZPdY4oCPsHxLQO2ib3AsQWCa38t9brrj +0pVqmVDuJo5iV+mDibIv7SLusa7RKIpdm7Jiydz/Wsyq4NekiGJ2MOhKJ2F7Z9D9Paw28c5Hc+H w/AAJm1wfNGFV/S6RKn3bbXp3DrrVVQbZKTLRKD4pDsQaOZYuqrI/YdN2rW4uxXltCgMvgrdqcY0 AAaks3SsK60E4FtrL/W7uOtVTbbYT6sWiZSp2f1lfWg4CCnFTBpeOrF3O+ewXldSD4ah/dcNwVkY qlc6G+FJkPIVvtwCkxgqshNesyPUdaoWt3nz4GtF1CkIb3BxD5aF0F871w9KmAFaRyijtCgeZKd8 u2xhOjNoBjK27wjWd0EsDdi7+fAOcBt0sBBAYmunpMYpipwQ/k4dKzyiknCWMO9NY1fBxSzLWeoh U1DIdZ5bS5kxM071wNqJrFlgbf+zKL+ARx8VAxvwEJtfN7t/6jjfsMS3Vq73sSt2yKjPBFah98ci /huCv7afRHpPmmFzwVlsHfrWHvQqjHZohcoqMgSVgBszPy92NzWne3ZDBCCDyjbZFZoXEhBC41r9 wbS4GY8GRnMIsYinaQ6kL/OYuAJIzmC5vCCJbDR89FW99c8dfUM9jRmTdklDK0gOW+ATAJNjrAIo eNvwrP5SvUuolCVtboPQCeA4zvvmHe0rxv24AbWekNmu2N06UK+7IQ3P10AyIW2yZn2q/WwKOPBO On07n7G3BfqME26PfkjEUxRbqsVhBsJ5TenJJiH+QtDbPmrpIzo/B7/XpvD1J+d8RfZHziHT3kUA 3xhZdGsbs8J3u0yx7Z2hNw7Z8kzlIGI0mYT8kl0s5AX5qdEBKH81+arRZCLZFK9EJib4Cjxqs00A aAwzSgcONTO3piqCXFMrU8OjM6ZXGcodSygNmQnRtOAZ7+pZ4ih8KBfLfdNTNnm8UULR57EccWL/ zimxmzocbbS35gOf1bNDDj5o+GY8b4EMK0lYRhkouHALTm0Fll9jtYVqDkPfGpyaOrY3ReKsVnC2 tc7/8td15jEykKnPJCJmovkoysle7++NrfZWegc3OInzdtOwBK5SW0Ct0kzGpzyP1zNEGQvd9ESv KT39roihihPr/qMAK7nJGMlWclI0WmcaMKuHt5wDEf9/y0NpO3csj3OVxnY6qnMEi0uLQV3a5PIN JjGW8tlUmUNelPYL7yhv0CEJ3O0hfAuny4IKuSuvRa/oAhg+22q5HduX7croJaW+81nyJKF0P4jb STXowDDin7Mrm7mdbN3Ve8uD5Q4hZA3CbGocAMkOOw8k4M+rQa6VUHPx2cyBHETWRBQ89gdXxMT7 E6ZpxQJGkQgdcnF94zrjuvfmODPC2b97h0dsstNFgq2J4Xj5Mua9/lgBNxgcDysKRrrupU/6CE1w hSNqFlb5sySXrTTF9l7D8bDBnGDjQoKyZWeLOJag61rrCfctMnLaLACFOT8caD7JgOrUqqiKayyx wsIkSw28h9S+lEPYNRK51QuqGYT+QaspVOi/hbgesohRF3QDgH2GZ5100h/i0a57t0rhOG2wljbW xmbQ6552scLQ84Er6vbtXtllyt0NJHo9+WwoccKpB7QSMIt3uZklMBa2XyPAOxCJhjc/7KLsp7n4 nh3qGFW0Kag07tMOkZMvZ1nw/n5DnkMNHO4S35QSRRqaFYkzvczQ2DmmOcSujFIwB3bq0CoPUjq+ 2DB20Tz7A8MpL5cUxd/fCcsd5BJxDo2Ywr6KmIp2eY8PZNYn3DCOqQOYXoLLTO7Xa6sbnvL09/1d b8Dp1wCdaeqal4hSqpWALB/Vd5ctq3KEfvtme8zZ6InTeZvINoe6NHJGMeBj5P8qhrliiMQQ5+b/ 7tEJW1DnQEkL7igoYI5RqqhWLBxbdKFuO1c7jMgGgFll/lyV3IDFOQWc3l2WLXTTXiGKp7eCexrh 7OarN/5YiU7z6u7Ne5PvCeIkyUAa5HxqGkf0NuU0Xqf0rMQqxAPq75tFYCu/0C7yZlfMRjJx9vGF GBVcMqsMxHULw3g8XGXjcr3vB6g9sx4EFUV7z2n6ozC9AipMaa3JiKJssojvahPLzCa1r5XZhzwq NkHkU123HgpeTzHxGevxc6wUYYo5STMuvd+KvQc60mWWRJdI/4zdP9M9I5k0K1s1T8Dz1AdsgLQz 77egf5PtwBQqO2oUHqZeyXGQzEdrYpOig7IErCfqQCMOukM4gW16hiV2qA6UXk8JD8k4CKvn7Gjk 4VVXmUx00AoNbIQN57Mtv53ejqrlKDLUuWj3/scxuuRKqzGdFLEIhQJ87r7BL0LYuWSLSZaP0aOc dBycDha8SsN1iUcJroT2S8DRzCy9YJdX86Sg3GY7j5Byuox0Cn6dewEk0CCZbVaa/L4RsOP4ZEP8 obh1TzzAn5LKf36j06B8yVGzTH34ed020VmFojxTJwvHjmDdCqICeeNpO6B5dupEn7SJmIBW3pY7 0ETobhu3zEVkLtEJSqfcDXgdnEgUZmjrzZGp+M0bwCWidIObNZQHREpFbeqh552ReCoLJcyF+PZx GTLlC4CSlRCa1HYWzhsCDJCbomBHjWEb6XYAoWQip5VD2zthFj4SehnjFQfrg+tovgq2zfQ64fZ2 Pq5iw1sKirLGwn7JCUhN0ZxwNZGUMSQjoDD67Gka5wAyqXpAWhjijlMB9iKa5UEtEjl1H9fTIfD8 0GF3lycMrHNhGI5BbzX9JGsq8Dh3ODAxGt6lDdiPrm/WfEHQ+bqAytqoyg1OUYZuy0IDLJFsiCuR tI52Kms7u1IJS3LNUmvKaDKBtbiCCW3KzHB1lEV+FInRn3HI9IqpaXWH9aoEioZ249ojzuUwiCY2 g2f8kcSmrfvBIBZMDe6o8SHS9HZPdTGsJS6eE/Q+YNHKZE2rD+A843KJKohX58ymvdjv8FV+Uqfs 8eAPmk0cRQrEEvPedi3HqR0mT1X4G9k9KbwcvBYn0zlGff9+OO8Rgfq7aXyA/BaqhfL93fNy1uzT kEJcuEST0t2ag+a92G2xr1UAq1U6pLGERK8JWA9wTX4cNlR8mZCTDpkZ3X/BckcwLAm4B76OLXg2 DRoSUszvANWMrtGakPFfKYanNSvCw65iyoIvvs3qMEmkFhKe1nZITdxAGlDA3/h2nvFT6MhCPm8s te3NVh3HrAC3EU5s10w7lITCCmVuZHN0cmVhbSAKZW5kb2JqIAoxMCAwIG9iaiAKPDwKL0xlbmd0 aCA3NjgKPj4Kc3RyZWFtChGV/gG1RbyqfRm//9vSns7gS2ugSQOBgN8xJxjMSPH+uVB32KnC55aC l7wQEbeTLaWAMTFLCDUjgOwxStsGLrz4iIl11KgpkPo+VTuwByn/bO1Zjm1xDHp7osXNmgb6+24l ehsS8D9XVVQfbPaW+dCaIvPU9J7QFg2BgDX36DUXmfKiR/Upsypl07m2JYFIXHZS9Djzz5wuVAJF 3QaSPDB1idC/pF4fdR1CYGCyGtj2qCOv3P7lOUxLvtHMvhxXuiHqWjkRHKZjvrg0Rr4ByDBBB4tr kMkBzDap66lVGMssK2DgGr+c6WIEAQBWMr8/C9WZgKUgFGpbo1SdzsNbbqw7xv0VeYr11NM6Uz3c RpFlTDZ+RcCpJRFx+uskXNIV+0lTdQ5iKNiwbXb6t6yzlu9d/lbeHx4ylDS5WHTBsi/itU4zgOMF 4Bq343XigUe9h+xtj8eE001bVtWV4P33gnjl/KhKPiT1lsZgXYpsN5mBw+T15YSYWe8WmdvbvekG CO+KewjpQ76hx1esrYQh3Fb3oH2fNmG7ooMH9PmbgTD87vS5ejlr48E8tUhgwewU+b2bXqsHIVfI ZUC6BGtUXqTrn15d3LPIKspV08HEtXlWG4VIPF3/tOrniOXCKPp9INUwPwbEXXTd8gycHverVqlS Ziv+KXXXoDgkzETUGHZ5/Ku3ZaRHSs6S7sfBPdgY1vyBu6E8VSUnRK0gY54i9ag/Hacacu3AjN9F exkIgxXSo74jMT8coE4zVAc4/X+IDIZeuUjYtgSpegLMDSAYXKZ63uaFt95r/QSYL7A0+Jhc2PKZ a22ghzl5NQn6j5jrjvdRWK6zFRlEY40LZBmfopWh8hBk2KI2uFX4AIDNgtZX5JneltJCyc0DSM0f ICwdAQe6P80fBoJ5S9i0u3ulaiTwVCbTkJiims6ZnytnNYRhYo35NXFem3/cqwr7nPaXpoJ6sJ9w TB79brDoaJi9SAcDP1ZIarOGFwft3Kp7CGrD4jBSS/TExuVxqOp0yVEU8gplbmRzdHJlYW0gCmVu ZG9iaiAKMTEgMCBvYmogCjw8Ci9SIDMKL1AgLTM5MDQKL08gKFxmesHZ2CFwJP8GDyNe/CUG3jJ4 7kFENMNEXGYrVmscXGIdKQovRmlsdGVyIC9TdGFuZGFyZAovTGVuZ3RoIDEyOAovViAyCi9VICjn 89mMgl7f6XyYwVxcF+ijvAAAAAAAAAAAAAAAAAAAAAApCj4+CmVuZG9iaiAKMTIgMCBvYmogCjw8 Ci9UaXRsZSAoQVSH+Vnk0qzLNpI5wykKL1Byb2R1Y2VyICh7TYn9V/bHptJ7iX2TAjn7kmEj+Zdc XNuy4tFr/jY5dXDakEX+cBKqc+yDR7Gae/4OfUjjcYR3MEhWKQovTW9kRGF0ZSAodhraqgKMlvaK LdJtlR845SkKL0NyZWF0aW9uRGF0ZSAodhraqgKMlvaKLdJtlR845SkKPj4KZW5kb2JqIHhyZWYK MCAxMwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwMDA2NiAw MDAwMCBuIAowMDAwMDAwMTI1IDAwMDAwIG4gCjAwMDAwMDU5MTQgMDAwMDAgbiAKMDAwMDAwMDU2 NCAwMDAwMCBuIAowMDAwMDAwNDU0IDAwMDAwIG4gCjAwMDAwMDA0MTcgMDAwMDAgbiAKMDAwMDAw MDMzMyAwMDAwMCBuIAowMDAwMDA1ODY1IDAwMDAwIG4gCjAwMDAwMDk2NzEgMDAwMDAgbiAKMDAw MDAxMDQ5NCAwMDAwMCBuIAowMDAwMDEwNjQ3IDAwMDAwIG4gCnRyYWlsZXIKCjw8Ci9FbmNyeXB0 IDExIDAgUgovSW5mbyAxMiAwIFIKL1Jvb3QgMSAwIFIKL1NpemUgMTMKL0lEIFs8OTNkZGUwYjFh ZDk5Y2YyZjk0NzU1ZDJhNzQwOTU4YjI+PDljMjhmYTQ5MmRmYTQ0ZjYyOGNmOGIwYjI0Mjc1Y2Ey Pl0KPj4Kc3RhcnR4cmVmCjEwODI1CiUlRU9GCg== --------------080000070601050407030400-- From zgdi@sigconsult.com Sun Jul 15 07:06:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA1vY-0000Cq-Ui for simple-archive@lists.ietf.org; Sun, 15 Jul 2007 07:06:13 -0400 Received: from 229.65.19.209.transedge.com ([209.19.65.229]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IA1vU-00009E-6M for simple-archive@lists.ietf.org; Sun, 15 Jul 2007 07:06:12 -0400 Received: from vxwzw ([33.132.233.197]) by 229.65.19.209.transedge.com (8.13.2/8.13.2) with SMTP id l6FB78sT067913; Sun, 15 Jul 2007 04:07:08 -0700 Message-ID: <4699FF9E.3000702@sigconsult.com> Date: Sun, 15 Jul 2007 04:06:06 -0700 From: Lionel G. Barron User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: Attend this session and see a demonstration of web services interoperability using WSIT. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Big News For SZSN! Shares Rocket! UP 37.5% Shandong Zhouyuan Seed and Nursery Co., Ltd (SZSN) $0.33 UP 37.5% SZSN new releases show huge expansion and Multi-Million dollar projects. Share prices rocket! Friday's trading was strong. Get On SZSN first thing Monday! Then it adds functionality for the Swing application to receive events when the user clicks on areas within Google Maps. Those bits of encumbered code are there but as binary plugs, so you can still build a working JDK. Articles in this series will use the mashups in Pet Store to illustrate mashup techniques. ArrayDeque and NavigableMap. They offer step-by-step examples that illustrate new platform development, show how to build cool apps, and create interesting demos on Java ME technology-enabled cell phones. The application can access the data or functionality in various ways. But it is a view layer framework. Q: The Java class that you couldn't live without is. Parallel tracks such as the Open Source track, the Services and Integration track, and the Next Generation Web track also offer interesting sessions for enterprise Java developers. "The presentation discusses the coordination required between Java and JavaScript technology to make this happen. It's rare that you see Swing and Ajax mentioned side-by-side. Q: Favorite Java book? A Brief Tour of Mashups in the Pet Store Application Pet Store is a web application for selling and buying pets. For simplicity, this article refers to the application as Pet Store. In the simplest sense, if your web application is using other web sites, it's a mashup. Since I was little, my passions have been business and computers. A: In addition running Ajaxian. Q: Rich, big news for the OpenJDK community! The client makes a request to the server in your web site. A Brief Tour of Mashups in the Pet Store Application Pet Store is a web application for selling and buying pets. org allows users to search for top traffic sites by topic, something that you can do in only a limited way on the Alexa site. As the platform wars heat up, I worry about Sun's efficiency in evolving the Java platform. Client-side mashups integrate services and content on the client. Google makes finding information easier than ever, but nothing beats interacting with an expert. Q: What else can developers do now? Learn from project community managers how they anticipate the new open-source licensing model can open doors to both innovation and profit. The focus of the venture is helping companies create compelling user experiences, whether it be with Ajax or Swing or another technology such as the new JavaFX stuff. Q: If you could work on a dream project, what would it be? In addition, visit the . From unoif@benincasa.fr Sun Jul 15 21:29:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAFPI-000842-Si for simple-archive@lists.ietf.org; Sun, 15 Jul 2007 21:29:48 -0400 Received: from dpc67142129052.direcpc.com ([67.142.129.52]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAFPC-0002Q5-2p for simple-archive@lists.ietf.org; Sun, 15 Jul 2007 21:29:48 -0400 Received: from vrwwk ([191.164.135.134]) by dpc67142129052.direcpc.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 15 Jul 2007 21:29:40 -0400 Message-ID: <469ACA04.4060006@benincasa.fr> Date: Sun, 15 Jul 2007 21:29:40 -0400 From: Sibil Hurt User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: While drinking your tenth cup of coffee, you realize there must be a better way. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a OTC-Advisors.com and bullishalrets.com Issue Watch Alert On SZSN Shandong Zhouyuan Seed and Nursery Co., Ltd (SZSN) $0.33 UP 37.5% Market watchers are already alerting investors that SZSN in on the rise and moving fast. Read the news and get on SZSN first thing Monday morning! Remember to stay true to your brand. Laura co-founded this amazing radio station which was one of the first that I can remember to broadcast over the internet. Finally, Flash can add significant download time for those not on a high speed connection, which will turn off many potential customers. He runs the Sunset Music Series in Brooklyn in the summer, which has a great mix of music. Sit back and enjoy music from Daniel Link, Majors Junction, Elliot Randall, The Last Town Chorus and AJ Rosales. A company selling rare books or athletic shoes, for instance, would be unlikely to benefit from a Flash presentation. History of Cascading Style Sheets Historically, style sheets used to be manual records of the style of a publication. While drinking your tenth cup of coffee, you realize there must be a better way. Americana Roots : Your Daily Fix For Americana Music : . So do you need Flash on your website? After the second chorus the resophonic guitar and the chime slides over to accentuate the pivotal notes. com How to Use Flash Most experts agree that unless you are a Flash developer showing off bleeding-edge skills, the best way to use Flash is with the "seasoning" methodology. And again, it allows changes to be made quickly and easily. Ready to end my life. Here are some guidelines to help your decision. To accomplish a unique logo design, you should start by getting online and checking out the competition. We are coming to the week leading to Easter. A company selling rare books or athletic shoes, for instance, would be unlikely to benefit from a Flash presentation. In particular, Joseph Evans guitar is by turns melodically precise a la Doug Pettibone and machine gun flat-picked bluegrass a la David Rawlings. A company selling rare books or athletic shoes, for instance, would be unlikely to benefit from a Flash presentation. Are you adding Flash because everyone else has it? com uses a small dash of flash to add attractive motion to an otherwise very modular, easy-to-update, text-driven site. By separating web page style from substance, CSS can save valuable time when building or changing your website, as well as streamline your HTML source code. Flash, an interactive, multimedia format, was introduced to web design only a few years ago. Yes, Dear Lord let it be. Thoroughly research your target market, use the resources at your disposal to reach them, and stay true to yourself. Lisa Calhoun is a creative writing specialist and for MCP Media, Inc. The record offers something new with each spin. Also, your company name can be used to create an interesting, successful logo. Sometimes It Takes Balls to be a Woman by Elizabeth Cook and Melinda Schneider for song of the year! Educate your users about certain key computing basics. com or entering a comment in our new Blog section The Voice. This can be beneficial by generating extra traffic to your site, as well as fostering useful partnerships with other companies. If you are the system administrator, please click here. Promoting acts of kindness. CSS is a method of controlling the style of web pages without altering the HTML structure of a page. Style sheets got more and more robust with typesetting applications, and the expectations of users grew. A Flash presentation demonstrating the product could be very effective marketing in this case. You can now vote for Ray's podcast on Podcast Alley and Yahoo Podcasts which will help get this music out there by exposing it to more and more people. Americana Roots : Your Daily Fix For Americana Music : - Laura Ellen Hopper KPIG Co-Founder Passes . On a personal note, I had the chance to hear Laura speak a few years ago out an AMA convention. Request a FREE web design quote! The key is to consider what your target market wants, and then design a logo that speaks to those desires. Flash, a streaming format from Macromedia, allows Web sites to behave like movies, reacting to the mouse in a way that seems almost alive. Alex Benson is a creative writing specialist and for MCP Media, Inc. If your intended viewers aren't surfing at fast connection speeds, they will find Flash pages frustrating. Unfortunately, Flash, while sometimes quite useful, proved sometimes to be more of a headache than a help. A travel agency would find it helpful to use imagery that implies travel, such as a globe, an airplane, or something along those lines. The sky was clear and ablaze with stars. Americana Roots : Your Daily Fix For Americana Music : - Ellsworth - American Compost . This is not a huge drawback because the HTML is still displayed in these instances. When text is bulleted, what bullet is used, how much is it indented, and how far apart is the bulleted text? I would beg to differ. Sometimes It Takes Balls to be a Woman by Elizabeth Cook and Melinda Schneider for song of the year! In particular, Joseph Evans guitar is by turns melodically precise a la Doug Pettibone and machine gun flat-picked bluegrass a la David Rawlings. To apply the CSS settings, you simply insert a line of HTML code that calls up the style sheet. Request a FREE web design quote! These few people are not likely to take the time to download a program just to view your content. Geek-Speak Glossary: A Manager's Guide to IT Terminology IP Telephony from A to Z: The Complete IP Telephony eBook The New Generation of Microsoft Certifications: What's at the Core? From simple-bounces@ietf.org Mon Jul 16 05:59:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IANMH-0003Sx-QQ; Mon, 16 Jul 2007 05:59:13 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IANMH-0003Sr-3C for simple-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 05:59:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IANMG-0003Sj-PK for simple@ietf.org; Mon, 16 Jul 2007 05:59:12 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IANMC-0004HJ-84 for simple@ietf.org; Mon, 16 Jul 2007 05:59:12 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6G9wwJx000397; Mon, 16 Jul 2007 12:59:03 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 12:58:50 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 12:58:42 +0300 Received: from [172.21.154.49] ([172.21.154.49]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 12:58:42 +0300 Message-ID: <469B4152.80607@nsn.com> Date: Mon, 16 Jul 2007 12:58:42 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Qian Sun Subject: Re: [Simple] Nickname negotiation References: <008f01c7c2c4$07e1de10$7c6c460a@china.huawei.com> In-Reply-To: <008f01c7c2c4$07e1de10$7c6c460a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2007 09:58:42.0413 (UTC) FILETIME=[E41439D0:01C7C78F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: , Errors-To: simple-bounces@ietf.org Hi Qian: Interesting topic... So, you are suggesting to generalize the semantics and method name of NICKNAME and instead having something more generic, such as CHAT-COMMAND. This will be equivalent to the "//" in commercial chat rooms. Then there should be a subcommand that demultiplex and indicates the specific action. Here we need to get the balance between be specific and generality. Also, we need to first discuss whether MSRP is the protocol that we want to use to command a chat room. The idea clashes with the work that is currently taking place in XCON, which is defining a generic protocol for manipulating conference servers. We also decided some time ago to have reduced scope in the MSRP chat draft, where we only address a couple of topic, namely nickname handling and private messaging. We deferred to XCON with generic and more sophisticated procedures. So moving into a direction of a generic MSRP method for controlling chat rooms will not allow users of SIP MESSAGE to use either. We will not be able to reuse the procedures for non-text conferences (e.g., audio, video). I think the topic is worth discussing, but we need to consider all the aspects. /Miguel Qian Sun wrote: > Hi, > There was a long discussion about nickname. Here just a suggest for nickname negotiation, could we use a litle more genenal approach instead of MSRP method "NICKNAME"? > > In many chat systems, it is very simple to set or modify nickname, just send a text-based command like "//nickname spiderman". In addition to nickname there are also many other chat commands, e.g. "emote", or change rooms in the chat lobby. > > On the other hand, some users may connect to a MSRP chatroom via SIP MESSAGE or HTTP. They can not use the MSRP method "NICKNAME". > > A possible approach might be including the chat command in the CPIM body, like this: > Content-Type: message/cpim > To: > Content-Type: text/plain > Content-Disposition: chat-command > NICKNAME "Alice in Wonderland" > > To "emote" function: > Content-Disposition: chat-emote > KISS Bob > > Opinion? > > Cheers, > Qian > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From fve@wachoviasec.com Mon Jul 16 13:26:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUKp-0002Sg-MU for simple-archive@lists.ietf.org; Mon, 16 Jul 2007 13:26:11 -0400 Received: from ov1-178.aircanopy.net ([66.160.215.178]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAUKl-0003zB-5Q for simple-archive@lists.ietf.org; Mon, 16 Jul 2007 13:26:11 -0400 Received: from guzj ([202.98.42.110]) by OV1-178.aircanopy.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Jul 2007 12:26:03 -0500 Message-ID: <469BAA2B.3010308@wachoviasec.com> Date: Mon, 16 Jul 2007 12:26:03 -0500 From: knives User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: Re: Content-Type: multipart/mixed; boundary="------------040707060308040507030205" X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 --------------040707060308040507030205 Content-Type: text/plain; charset=windows-1250; format=flowed Content-Transfer-Encoding: 7bit --------------040707060308040507030205 Content-Type: application/pdf; name="Document.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Document.pdf" JVBERi0xLjMKJeLjz9MKMSAwIG9iaiAKPDwKL1BhZ2VzIDIgMCBSCi9UeXBlIC9DYXRhbG9nCj4+ CmVuZG9iaiAKMiAwIG9iaiAKPDwKL0tpZHMgWzMgMCBSXQovQ291bnQgMQovVHlwZSAvUGFnZXMK Pj4KZW5kb2JqIAozIDAgb2JqIAo8PAovQ3JvcEJveCBbMCAwIDEwMTEgMTM4XQovUGFyZW50IDIg MCBSCi9UaHVtYiA0IDAgUgovTWVkaWFCb3ggWzAgMCAxMDExIDEzOF0KL1Jlc291cmNlcyAKPDwK L1hPYmplY3QgCjw8Ci9JbTAgNSAwIFIKPj4KL0ZvbnQgCjw8Ci9GMCA2IDAgUgo+PgovUHJvY1Nl dCA3IDAgUgo+PgovQ29udGVudHMgOCAwIFIKL1R5cGUgL1BhZ2UKPj4KZW5kb2JqIAo4IDAgb2Jq IAo8PAovTGVuZ3RoIDMyCj4+CnN0cmVhbQoY5XjeciAD8LprLA9MbxZOla6KN5Q5Xt1oyMOtTX+/ VgplbmRzdHJlYW0gCmVuZG9iaiAKNyAwIG9iaiBbL1BERiAvVGV4dCAvSW1hZ2VJXQplbmRvYmog CjYgMCBvYmogCjw8Ci9CYXNlRm9udCAvSGVsdmV0aWNhCi9TdWJ0eXBlIC9UeXBlMQovTmFtZSAv RjAKL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nCi9UeXBlIC9Gb250Cj4+CmVuZG9iaiAKNSAw IG9iaiAKPDwKL1dpZHRoIDEwMTEKL0JpdHNQZXJDb21wb25lbnQgOAovTmFtZSAvSW0wCi9IZWln aHQgMTM4Ci9TdWJ0eXBlIC9JbWFnZQovRmlsdGVyIFsvTFpXRGVjb2RlXQovTGVuZ3RoIDU3MzcK L1R5cGUgL1hPYmplY3QKL0NvbG9yU3BhY2UgOSAwIFIKPj4Kc3RyZWFtCmwiXDsnQ78ILfylqctU k28Tkr4J4VKLpbg6f5O6pdlA8zjulyHyD7JqyZsX0W91WqnyD9B3xHBWD0tHQZyofLc4WLNxtNLE urwBl95bs8mxG+/6ZeWMW+4ibtb+kDhy9Put5CstI7yAqV8yRTknCdMi1EoyRvNEfH/1KGG/2JYu i+S8lQi044/jI0poqELcHwU2Rydy7SGWxRyTroMYlHKg20ic8IsZ4vhl0opKXr83ErG4/VjDG3m7 IQNfKw5eddRphkSu4E9pHtX3f4KjQCH3qmdhCqIUGJCrSs58JDkqbScZmvFemudY9Dsn3zEJsy0J z4uYQXhmTDzGObwyH1vUvZbhn4trKJ8eb2lN1NO1Bw1HzdFY9vy8lkeYJBgHmga/ei7g5C0mXNDl pUM4uhM7/0PKOj5tPeLPxn35kH8pIWb6DEmanRWYeh8q9tUWUshcOYGGxYiOhsTNX8Rm+vbJKmaz 2IQL201tbnDthHyk+bfYE2SG08XP4ADPoAaN1wT0/H0wDBdRJRuOWRQVVYHSKfg6IGogvLhg+Yyp 2XrcI/mCDI+G7k01MUuEMgkqBH88e/APfsBMibKB0NZCRUQxjeAYD776IqjVdcIyQvdWOjn3eKl/ pwWFMiIeWpik4i7AT9SRfN5d7nTxA2QYWt2xtlHU6dbg5z6gwdtLVrksW2ujZTPLeStWA19Hy4/Z tAwBYFbJxhpa15t3ir9MvyIyZJr2sVXK/FYp2I5nKNuLHarzMY2f8D6f+EjKXEln4a/jgWozJdeK EedI4A+Tx8+0IfXvl07Z5I6n6uYT7ks9E9oPlH5Pcjq5r4QqWpVMjfibB9zqjr11evk72ipUuiwS 1dlEEMR/ePm4TTxjpwyUEn94HrJPuuJeOCrf4kWuN1AS1MGaRQcrqMG9PyXjH+co4V3rAdqAI/1T hlDVCp4MRR+YW1E1aO5GTpNFybugUvaOhMfH+U03Milco43NozcwoqAoZPL3TqbP2LV/SzrPzwji cKPgjOtHJx14ZsQD9A7iPJUWIWNDsHxg8GzkBRdMNrur/aSgqlPGB9b2PrnnglKexfEy7EBUohVh Lqn0PQFaZxmUw7bilr3MQILbEu0fBVmi7DVeigGK4dnU4rzlrxAK0P7W3Cqh212Z3qjvWICMDiDv Y6aFGc72WOMYdG6t056uIB7W78zHePP7j/xtLWDZ8O23o3U1J7bLsXGshlcKcjLb6FfVHaHFhqKZ wCffcZpSFNdhYTK7t4IqvyM1IEIYgAzVRFeAVM7VCk0HpnsYAitGx8Zgz08I6eReV1HblRlhsc+E 6bd3ZnMO5prvpzrv5GbK+7z+Z45737RD4hK/nEUP/Pkk/D/itMyh01fBURj32XIi12MAOjS8ENmR b/J05Reb+yLwNXr86xIKm97Y87KVMAvghQ3wPrC099RTYWgKegHXA0zZLqEuwSfpAozn9t7vVkkE 2kE+ENo9u8RxCgfOys0F+hSZO+aPbDixFc9pQ5BpYK6uB4UNWD/2HSOjwehQYdDHeOo6O/uXi2aD fsrbXiYiv1Ox72INHriBLGV2yoC3eGn1OiWEiDEyuvTDnkeeo85PIrMj/AA0Q8pXcDAzE26LUGCr N+MDlURilGnX3eG8PSiJYxPCVkPjg0IHLcUAiqM1ytPYw/GAi0HjlOwNQ/acMqY2T2hTKKI2Jwx0 4MqkvxxD/8OSJ2jGrhLwB+5F3LwSe7kBs+EiCeDrSEsGH4mseQwWT8TLtke5Vt9FOc2VT2QVO8Iq wJGqYNbsyh0fMmgAhYdPVCEcpbULpAuNpNXe+qpw7+U8UDwSjgQERnkpwA4LyGiXPUfs/tWG2sga axrHeswJI/1FJ/e98azbFtOmUvVLHgOOAS66Q7CJuIc3i8Ki9BwW4BYgL70prGW5waWcx829dlDZ Cla330WbGilDpgKGxEgdCQbdGwdpllslKXM/YJ9jIc9cBfJ6VbK9L7Nae2kPQJVY9mDHFtk0ioeT Rf4ZQmF3iB2E8LwR9LK1Jst4nNwmDKQm3CfPccW1q0c+GQVwQS8HMUlgzRJSp5uKvtpVIvQCQEdV 8SD31QW5Tjcm9Zppc5iPax0yfAMs2Vfka0pORYaRfHOPd2xQoF6uifDi4Hatyf1Ok7AZj7fiXVeM vECefzFFI5mZgpKrZQjS93MKG8QmwO/BGBTnI57By/18q3/pV8vtPT6xbLS4Xcsx0uLSL/pAYJ07 7LB8ckidpp9zp/vVjh8XU2P/seNolEUEeDEwHvw3Fz549ZDuxRlC1BBElgGGvdFRzw7Jd+tZT5/K EccmvNd7cpcaw6J/7ukhSZuGu6mcNHuKxW5RvoObqzhBr5O/H51qrplF4c4BtmMlNzUcXpTOy+3+ 24lImhDiJedqR5/Z/fCiXj7GGW6QYMBdq/e2oCHFqIf8K+wUhZJaW6mPbgnL5NlH2hJXZ+qQt8fV 7URhGuPeNIusSUHOkonJQ5qtuuDzPkL57VvVTVVppafqZ2iPuuGunv/aGITGr0y/SuH0I2h/eMnS l3yrYg47eMQqcHAJlrKKVQFQw1br4DpKgRn58SwZCAbA0nZq0v1z2ZfSxFeI7kW29+V9A7JLL+6x ZdX5B91jy2SzeBOMCBdHh81drlUVYiVvpeQxxiZpEnmRc73+QXmPaC7hYIGN6ezxp+zyEKNFcqkg o2wrYz0cLE9fdf+DyrQXvGs+Ce4eXADtvMl9LbE+2yBRvKLyVVRenAcAhpFsu21mzsknlf/wbdZr P2/c4rYRqzYTBvYZ5cYS2fqi9tzaB+b+NeW+US05EPjtG2lzkHGe3i6Va+D7OoRXlDQAWkWqnHx/ 6u7LYuMJTX3JdSDZchqYLaGxLQ5FQix4wOAp2wDsBF5boyfIXD6LeDPJXYHuBhB5unFHZm40KXcc PXvZJma4tpzv3XNqYvtvyRPSIvk+7OdlZVwNPu0BAzf5LFH+AF01da9VM493nR5prq5YxbYM3jpd +TfLdRUhPJZdXPRSSroOD3EgN3SKzEeNNohTS+f4hM9crxbTXT65EgiQMf7IR0s3DMeuotQFwwa+ C0x76T7A0tChUUeAS9tNL3sPULjcd1ag0nqOl++JQ8T8N3BYQ420udjx5M5t5kQhAKm+McN/wDPe omynqXmy2Nfq7Io4xiVwYohVOBlzprPfog/Sb7BulW6orWrtXNqsZsTzrEcscsKKWd9Ax8li2si9 Xky5gzy2LR58Lxdr/Z3DpwRGdLPR9ojbFFbPZJkOIXpz6cP6gT6/r6LUmS9svR3kJLB6aHJ9MelA VLfI3XXAK296m1NFDBI9a4atGhCY3EGnnPl2s2Qk+1chibvud4YjSWvg5dgOCsuY6mebOGYiCqev AhT9G6BrGRvIGmKPOM162bDHIB4rw0HvpwGurA7tzAebUR9TqdivM+XFTmo+Y07rd/cel8GwyVs/ Ml39ar6fDMROHlWGsy7mQga9Z3sfNvfjdTDGhrVvSdot8si8TCisBQt9MXJ0cBb/odsrSaCj9zU6 lL2qi50ffdmDt3GJI1r+64GGY57iTrKBM4iBoSIls7GhARIv7uY7T+Z1hRULuIsCKrUDICQLCiv3 yZq6VTE0s5gShDLR4kYFdico/QiHNW9JiA9Xhxm/EPP4PeKKA+FK3PUaS2dYCyeQAhChe9IXA+tC 3OLs5TiU79IjHRu4sYbcLX11u2mYMnU5QO2ZqjIlyE/z5hxuL4//2kavdlhY7xZ/yBRuKMbHx8zB ZsHwA0uH2whEy71iA6ZJfHYsaLC86eYsQ6/iusxxJR3GOp6diBInSnHGWBmjr9v6WSvLOKBSlq8P 25MiExZ/1D8B9FXxHV2dOLUKALeZhg8E4HYvIAi9EFjbTYGNF/WEM7vryCrpDVs9IDjfsAifX6jr 6xbyXlbSzovgalasG+d5qdaoUUJc7IUAhSPZFHaRhhgoTB7HJpAxNwtsaJOX4W3XT+Ph4cFqiOjZ 2s8im5c1FM3TVcmRf/hd1MVdL/qlHZpM7owfzxrdDBRnZTsr1xeSzTPX6nUc2JhVGKjTHPMbyliI tDwfEKVceGL8Sx5WtOp/rWYlXSLaYPtwBpsR1Idb9wnABQ246deg8BhDZagfKm5+bcO/VEEprP3H vwdu49ZPAfMUxWX6UzIenBgE4zQu8AGQVmg1389CYLLXcSOdhtAdIv5b4hHGpdTOnEctRAkpI9DF FAl1zK0DsM4zfcaevVQ8O1CPl3/wQNQGJL4tRPlVCT8Ku2Oaqf0J2QgAC2YDzWKtZVyrcqq/bWwd q6PFDFDzDG+zJHE2xO7wkWm9Aiw/WJRvKEFOZRgBv/HalBGQliypjoTR1d8xL0C4KoCAB2XWgR35 XZMwBsJ2TEkFKK+mbFBubZgai53H0ogOGyy5e4jUJ6x8gVHWOoWBwWALq7flc3xLtiCuFZ7CenLm jgvcx/ByN1dR6bg71sxCOmV2gwCz5xb7KluOfohXskUnqmVmOUqkp77RF89mGl7soHjd5DiwzRFw qGXG1r4k9FqhIHNYah+s7EJM5sqsfOmjl7nRyTCzBE3kNV5AZL6FfBvUF7Qc/CXs/4EV6gjgWeK4 IpCkjPwbnqvD4KzSGj4o5kTiA84vUnyS0hOITAH+cKA2p0vVlmekliCHhMSNjExM0KLYrYEyT98d yz24P6+cyRC5y0Rw4J11ePO5bWuT6fUyL/QqkkRjkGv7zVqEfe8/6qcVRrOwPIJGjr8AlzJ2jZps zU+wB2kbe9zik9dYIWq9Ql2YFXqMImPWmBiE3DTC4nqxic9YR243kJYyqV6Hh6blOoyeUclZYY4g izHlse7bxkkQQXa9JqePAe/UNoPVOGv7dzATYlkSEzzgIyWye9PPO3fh0CUbz+ur3h1eY1a7c9eF cqN93vczj/6VSWO4haDLe5RaR8bS4OOKnsc3YB3wmRdyFvCn0Ylsm6Eg4mRjOzfowp5O0cyn2X0G LpY0wkU1BA+cU53SoTVc/hJ5YNp1Ic7BCbtl1LU/j/RSypon57X7z/GaSBVHhGGo6B4DWqv2HpCL RQB4pUANv45n4Su7FjN28xQO3WlvZQbf4g+YPiBr8gr8wRCnPteb1QXMVAcUr1zbFHBcYDApBvS/ ExSuYbu2M6z4FuKZySkrCfJgnIvHybz8InEqUDDsxrfAdKYp2ROQg1gdhymeit6Toq7yVfRFJ0/o 0/NAhyFKh4m3DSYBmkbPoEftJuUhcMnz8i0j7HTGQc7S0TlWRqgiW8ryPzYkIYkUTmis+vLQE9NC UW9/MUgPsP1oK+Z0aa146tV7XPAfDozS+Zf6tmgK6Jn3NYeoVThhYuEQRG/lrusPMiW5t8KcXhcr H+bfcTd94bBCK9qPZfvuORFpxMSHl4g4pAFdcvPTFgl+I2q2xG2K/pi7icKolGuMAUpc2XmduvpP dkbPDXHj6MKqFN4/b1eRpskgM06mhrSmY3yxn3Fg634xyaWpb6lrV95YUTSAEuwcj6QPw/dsA4Af 7kG7YTJAXACq8uge/xqCAPdlsAeNhqlaUXswptC9XCBochY+9DTwYyuVpIjTbVyNVXxVcq/DMh15 jRS80oZ0XiovpoT1fYkXol3n6bTyWUommP1N2W2dVW96wOUNdjkvyFXLzIUyPx4thzh6o6gvzKY5 RfYvqbFChKSgcRgn6wdgUUWhuRk1Gs9FGkyxa9fXJJsRqSaVNoXfzbV2kaOVZ6V00D38GLO9JVeH zSxH7ZlSzpgs63tHLj5KpEUciFBz44SEmTvDzQJsvq485y9VaYTICtlzMzYYBx1+Mw+fhJoOC7Fv 2f9PTJNVB7JfWlgPOPAqUdeP+14a4Mni8SmjZARaRuj3Qv6VcEA9T3Dx1EGY6GCxP04OSJ+o8o4a 9RYYgHnqY8VUaZNqu7EL/H6uiNGXLOrHctTBJZz+wZRocwn+Eumf1Z+J11t6ljgb7szJj5z++BRJ T9oOhiZ0R2goME9w0IZv+SMEqwj8gZypHR9Orgxnr0wzKjFI/bPkwcXcKZnlUB4V92Sa9QsbPR8Y 6a8gTKgcslbcWXLNvoKyzW4qwdmX9KNKss1n+Gqu0XSGXuppxnvGrSX28uhn5TK9B4Mlcvq39b/s czODjtyy6kvaoyABHv50hfXJ1im5prxVS7FZBQ3BHZ53ykbcCRXutX9HFdABLuEiDH9rfvx21UMQ bP5wozoTJdRQpfGvE6LjuglmjmHDC0DPhAMlw6dHEJz9UEWtLFOQ0ET5dP9YFRSPuaBgYsnuF7dR s9Meg/+CAQzSsHMfUhknemYzYgXMVvKVJiTu5AxetBAvZWdEP9QueJWGrJYerpqZNcOOwl/lZrzh Y2xzrR5e07rea8tj/IcG11DDpy6nYZEYF0XT27df5KYk8ftewodxhBDnTRy1IKXvJQrtm8Xv3vVd VGZVfxbjcxTFYbzu3fXRfeaJTLQt4c1nR3zd6Gx9QISkSlljp1/Amj6Qky1Oe6BKlp+CFMQzi8vd X7Typgh+su6ThwgpXIkdRUW55A6/q235pY9TZSZYobG9UbsgXLNShsTLen1mR1q3/A0B8P1v0G77 NXbbdlscERxEdh3zao9aeU7MGNZKb9S0Hj6kiJ6UOL7F68U1EkJDrueNdJlqCvcf7hqk4e5XD0Gh 0qZ7/sxooqN7Mgk1/GaP6fGTi6gwTUC+gC2CFfZcnBO45F/0UiKoELrdoH9RMvpuR/r6550w8P3i ZT3+fievh7l2COoaiohma/7Nyg93bY9uXqHQk/kWkUuzghW0kevNn+sm1zfgsLR0wIBVpbHVC2Ha h5OqIhw/pnzywFgh6EqpCn8Jlf21at2GzB4gN2JcDBPZYA7O3jenOGD2+pzA+QeOQsgj5EIFgEcC EzFa0t0SaOVdXrwoV9BztFH0tPO2jPVJ/SMC7HdMh5q326vcYMq6U6PZ/rEzIwu0erSYq2I7YJJE U4DKeZCf5YxFIqR9i1FUzte1MwmvW5BRjHv/mg2kVM5huSZK1KGJjuDPMCrrnWSa02GMMa/tQjgJ RgBny+TieFQhv4YtOMz8DMy6ay3Wfq7oBI9PFo/TjU+Mfy/2/U8xGkJanr3c774Sb5RbpC6EQqkD zhNVsvFedqNgtZ/O+jEUqM6PQSykv+yCALkdPr5+dsDc4Fb+KWTZgwEelywXX3B98VQegK6lJGSa 9A5mT4Kf9vsh9Q0kXTJdiGSLtHWCAUxoZvWm3LrCPfSfCz3NtmK6CzmU6VRI2L4+VtD84JntWTi4 GbqhX8YSySbJFtxH/8Ewxnu8AHzvcQw0cCPHeCgolfRsmwQHEVAh8ROPVB/ZOkUX5Aoh8dDMArc5 ZI9Ltxk/C792wW6LOm8Q06Jxoakz8LBx0fkavT26GK2yyYcyIUqmWzVrSwTC9stlxY4p8jHfAiky hcPuRo0Ln41G2NnYvIStkkCYRq5KDL/i2CmYUkpaQ2vKbzT/uhwQ60dM1nu7VeXv4/O/lccNzyGQ SvYXwflfjmcYqVUY0iPwX6plvRMaYew3/sJzRunovr0mcqV2SZ5anEmAbfzgl+c2BVLfUcMR+UU7 c+VQMWh80eUeVwJbnGF6s/XNUh8dwZDpxnk8JGBaxTIwCUDM0dd3ZXU1OafYC38NFdSADn0oOECI VzllDQOVsC880l0EUoRqDsc1rX5YsRgKZW5kc3RyZWFtIAplbmRvYmogCjkgMCBvYmogWy9JbmRl eGVkIC9EZXZpY2VSR0IgMjU1IDEwIDAgUl0KZW5kb2JqIAo0IDAgb2JqIAo8PAovQ29sb3JTcGFj ZSA5IDAgUgovRmlsdGVyIFsvTFpXRGVjb2RlXQovTGVuZ3RoIDE1NzkKL1dpZHRoIDEwNgovSGVp Z2h0IDE0Ci9CaXRzUGVyQ29tcG9uZW50IDgKPj4Kc3RyZWFtCsF0p1yaljzvymoFTd9SS2qP6qQH 7OBo2HrdY73+ITj1F6F/GO+NBSwCfU+1W5mmwUHwNjwf+3VsePoD8nDVl4m5cpAxBRX0SgCcz0N1 ZcPk/MpfeSxgmd+uZeVICdWvyA3NNxnnlTdQCOKFGkcsU51mOYuVvKgDANsZMtYwx+cX3uGydd08 yIMwmYQ09XEMg8O7qgbUwGJsUGhlWiTO4dtEjUEAecZeu5yVTam3bC8OpDRIWD3STeWUAHK/4Bcp c8v7EhXxCx7Sk5jlm3rbZouS+oGY/O7U5k0RlkIcdgyKSxo4JgCRE4yjz3lOmndgd3Bb1KklepVZ ALQePRMM4rZXxJcsnKxaIDGdcfi3/hmUmxH7IVTpjbBJkg8h2ZCd6rkIsb6tK/f0djqa9Xoxknrh nt7juJMVzOEz+09NisgesQtcjdpf0kouqPHF6/QL5s4hBY7lCv1FjO0k9RmYZZZTPgGV3M9jyLyR cfnAwWOEj5TocrOJ9rKbwye+DgcB3buJ/0JyG5W3AsVY27A9w06NiDzr4NXP0Fxs66k4PzviuBiP jliEiZwTyHahWKSytHBCEtMBRxwu7yBSAx21QRZM5yl306IVcXkoZ1N08i1lPy7tAiotoOPLyZYf 1md/j9cb9xfk6HTxL+DT9ER5Tt/kf5MHk7Vej4paby8fbA5xu5HXZ1Ri9JjIenu1cIkYbLZMJZAS MbHfMUMnDQV5VkJWASstwDpexehUD0SgIJ02IVu9KKMST1BRApGtoAWymeKpKQ+7wzWjn670luEf hmYBS6FA6pOTXkQzN4Yk1bzoGcKEqDyUqHnyL92rbRQJHbpEEapgv6Xyj64RIPDAGDg1c13Y5kgh tMbtct9lvUQ+5jpZ5SGGIOVtqK1BtKHVb418hfAe6ixYtrJZpJLNoUGyNV130Rns8WTpkuJsmkMM smNzkqpNDpRhCrSd1/7WwdD1DSygxNXhhLSYB5G3zmt7rwkDMeSCtxwSF3ju3YBux9qk30JqYuuZ HZWPdZBiFKd9zQ0L+IWsPzbaZvsqJ5QPH4/m9t+DTafgvnle393XLxpr2c5NKQ0MKaLx+3OHbttW BkcP7bfR+XyW98JFoSNN1fewAuVQNMgLtX2MxbdWI0foVblQvA44eMrhDMPPqXhl+iiBDLFEWcvD 7a9nVR270LN3C0nAtYycJ7v8IKpgyFPXfCNNjSZv71y1/Tu5PGmZ2hrNCqGvntz3o6Jm38wwlKs4 MyimP5Bz89vmECBtsovRLtPYJjhW6ezI1Oq4+UmqSIgwSQslTNHhwr9wY9b6JWPT0jipKPCg4Fy5 fMDVjNIFyua1Y0zvu7HT461ePBT2WIY+vLHH/vj0eraG/kUfI+kLzjCcoJMtstOONBxxfMFw3CU+ Da4wio50In1pM+U2qqCRlrL0JITpr0kysc0ho3pAMBqzQhEd2I24EqEmM0kDKKeVEOBfztV3792e JOl/6vM4qpQ50p5AP+6Wkho/RKt5e3u3VAHz6tkIfMbkL8oMZgoJ8cCPvdW/cO3Av/JNuXlZFhU1 ST9bAaOgypvC/diITxpiJrCKdVsApBMavi6o0AUcvvohH9EIyCs+LrQkiMJwv5uxnbpuxWgyzPg9 J3J0SGmTwcecBvwxjjYaocKNB98vWH32mtL+vlyw4QfxDXckEn8ktweFNI5HnjQ0iYCNDAKkDVfx 9xdEgklJr09Lrf0qzbktdt6jrlleUlD4C4NVuNl/zUSnfnkkrHyLm1aFo5G5yiWG6/F/RHEU8Hvr AXnxcS9KHJw6mQ5SKkZE6lCUNoi1g3nVGuW4MF02hvs2jZICtlpv+Mh+3ZY6hJ2uOvKTAs1AbaM5 rPf8giERR51D74R4yAMupsnIA6rtGcs2/ACtHxe39IDkbo0OMxX2jUU4mssMgjWmB0WqMIOfezcM JP8YN8n3EpGhacWSNlT+XZEife4sd39iyOevw6PmZNVxg8sb28LOd7yevmn0vFvatiOZXYqj2Byo wEBsTIM9dSGBmBw7Nfk33aUriRXBagWnhPtQwQUzcqrvlzS2gBILVnXzF4BiG/15CHPWCJH+oP/P Hl9s4MzDA8cqKFh3zrjqFQ9AOFYKZW5kc3RyZWFtIAplbmRvYmogCjEwIDAgb2JqIAo8PAovTGVu Z3RoIDc2OAo+PgpzdHJlYW0KUfSu2RHmj8CeFwx3Q+UR7Bpz7eXG4yJwamGzEcXhzvEhs3D9LcXh cBsVoeMfqaWzyTz9dnzlcguyKwjDpPULXaMYhQqS/JR83gSJAB4V7Oo8KmZGsspc8bDn+Lipj/CM eGkUXZe1BdmtR20e3iHeI6tYhqnd0OgapBDBzFWly3XO34vF1T2+5ghp+JrxrzGP+IeIQzohMPeU +XG2E7FJzskTcUEVfcCGG0gS/nWM1OBnJt+CggKNqBZC974rr+zdgPyvWq0yaKCbZnOz4twarbpW gkUBKyw2YjWD/hClSac2pGBaCuHIaYsvOfLwut2JRVvwyA8UqN97vfmoLDXB4rNfBkD1ydxdU+7T +3JpAZA8i53+AAmroZwL/Kr6R3I44GqVdoe9ZYP+lzx+5aFDSoTN3maT1F4b9/Jf8KaJab0sMOXA 0vs8DB/rrdkrRigveitv3Ffy9QMyV6CKm8WJgpE7DT+Gij/5W+JB3ONrnodCLwjNpkmF4JEAHUsw /Y5D2LttwFMlf/nd7bY7MXVUoFOJzzCaEzlazaIxJOHcFkMMuHFbRZwKQikDNmMs0884Lm8yrM7m xJ/j3HPGuJ7TbN3WagFf41L+UzexJFt8EZtXszlMTw0XjL9jm1jMeSu9CU9wxLtcUvx/TNV+L6u1 daS3fm15POrzQ56ZrmQOqIWM+zRsrhBpUBIyn5aWVErDXJ4IBwaDEMwI7spryFATBjzb0e19dn32 rN8CqdY6SyFT3WGSbbB5CtsTGTOxBq61qvAYMWiCgNCSa1cwHjHPOZ8v7cwQCnaxa22+Q01dJfEl czThAp60zflWAiGxekk3itgIf46PSU9/rb2AdGpEok59tdFZskhCKS9w7LSKADZBrkp9MXqMFiUW fdmJTFtZX0aZ69zDFkIxXzjYQB6WgPLUTmjSnj5Cphoz5epW6unMCLkxTxcDskUF6hJg1wK9DhmX MfRRoomapKudRwc2U1BdIpz6+0L9g6YXJuACUETMVO48JGUzvYhxGVbvcls0CmVuZHN0cmVhbSAK ZW5kb2JqIAoxMSAwIG9iaiAKPDwKL1IgMwovUCAtMzkwNAovTyAoysDY1BWPkeYetCT9Vn8HzQ41 87mMLUzf0z0nwB0t3OgpCi9GaWx0ZXIgL1N0YW5kYXJkCi9MZW5ndGggMTI4Ci9WIDIKL1UgKHyA IQ/4s6URqxOrJTr8SK8AAAAAAAAAAAAAAAAAAAAAKQo+PgplbmRvYmogCjEyIDAgb2JqIAo8PAov VGl0bGUgKEXEHxtZXCjnUWR3QCoiKQovUHJvZHVjZXIgKH/dER9XOvJbfTpbbnJltuBcZqv8ZBdJ 6WRyiNOD7P7E/FacOxnqPN400MgVIn/jxqqgI7awfVkVLsYpCi9Nb2REYXRlIChyikJIAkCjCyVv An92fLb4KQovQ3JlYXRpb25EYXRlIChyikJIAkCjCyVvAn92fLb4KQo+PgplbmRvYmogeHJlZgow IDEzCjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAwMDAwMDY2IDAw MDAwIG4gCjAwMDAwMDAxMjUgMDAwMDAgbiAKMDAwMDAwNjUzMyAwMDAwMCBuIAowMDAwMDAwNTY3 IDAwMDAwIG4gCjAwMDAwMDA0NTcgMDAwMDAgbiAKMDAwMDAwMDQyMCAwMDAwMCBuIAowMDAwMDAw MzM1IDAwMDAwIG4gCjAwMDAwMDY0ODQgMDAwMDAgbiAKMDAwMDAwODI0OCAwMDAwMCBuIAowMDAw MDA5MDcxIDAwMDAwIG4gCjAwMDAwMDkyMjAgMDAwMDAgbiAKdHJhaWxlcgoKPDwKL0VuY3J5cHQg MTEgMCBSCi9JbmZvIDEyIDAgUgovUm9vdCAxIDAgUgovU2l6ZSAxMwovSUQgWzw2MGU0MzM3NjY5 MGNmYWMzNTI4ZmQzOTdkZWE3MDI1OD48MWI5YTQ4OTI0NjU5MmQ2MDRmY2Q1NWVkOWY1NWRkMjM+ XQo+PgpzdGFydHhyZWYKOTM5OQolJUVPRgo= --------------040707060308040507030205-- From simple-bounces@ietf.org Mon Jul 16 19:22:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAZtR-0006tc-32; Mon, 16 Jul 2007 19:22:17 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IAZtO-0006tL-T4 for simple-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 19:22:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAZtO-0006ro-Ft for simple@ietf.org; Mon, 16 Jul 2007 19:22:14 -0400 Received: from mail-out.sbs.be ([193.109.72.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAZtN-00070S-EG for simple@ietf.org; Mon, 16 Jul 2007 19:22:14 -0400 Received: from bruc002x.sbs.be (bruc002x.sbs.be [193.210.175.98]) by mail-out.sbs.be (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l6GNLdhI019460; Tue, 17 Jul 2007 01:21:39 +0200 Received: from bru0032a.ww018.siemens.net (bru0032a.ww018.siemens.net [193.210.175.90]) by bruc002x.sbs.be (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l6GNLdaX014403; Tue, 17 Jul 2007 01:21:40 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0032a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Jul 2007 01:21:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple]I-D ACTION:draft-ietf-simple-interdomain-scaling-analysis-01.txt Date: Tue, 17 Jul 2007 01:19:45 +0200 Message-ID: <67043E463DDBFD4A8087ED940BFF756B01851ED9@BRU0038A.ww018.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple]I-D ACTION:draft-ietf-simple-interdomain-scaling-analysis-01.txt Thread-Index: Ace/j/eSCR3gSf5vRdi/eKpEdTu5LwIbTIMQ From: "Willekens, Marc" To: "ext Avshalom Houri" X-OriginalArrivalTime: 16 Jul 2007 23:21:39.0716 (UTC) FILETIME=[0FFD4440:01C7C800] X-Spam-Score: 0.0 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 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="===============1807250952==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1807250952== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C800.0E5D6727" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C800.0E5D6727 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Avshalom, =20 Can you check the formulas for S03 and S08? For No NOTIFY opt, I had values of S03/2 and S08/4 For NOTIFY opt, S03/2 and S08/2/ For Other protocol: OK For NOTIFY and partial: S03/2 and S08/2 =20 Some remarks: 1. With the "Other protocol", do you mean XMPP? 2. The figures indicate that the influence of the optimizations become smaller when the status change traffic increases. 3. For the very large network peering model with a frequency of status updates of 5sec, the required bandwidth between the domains becomes very high both for the SIMPLE and the XMPP approach: i.e. ca. 1,24 Tbps and 1 Tbps! =20 br, Marc. ________________________________ From: ext Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: vrijdag 6 juli 2007 7:38 To: simple@ietf.org Subject: Fw: [Simple]I-D ACTION:draft-ietf-simple-interdomain-scaling-analysis-01.txt The excel file I have used for the computations is in:=20 http://www.nostrum.com/~rjsparks/SIMPLE_message_computation.xls =20 Thanks to Robert for hosting it.=20 --Avshalom ----- Forwarded by Avshalom Houri/Haifa/IBM on 06/07/2007 08:36 -----=20 Internet-Drafts@ietf.org=20 06/07/2007 03:15=20 To i-d-announce@ietf.org=20 cc simple@ietf.org=20 Subject [Simple] I-D ACTION:draft-ietf-simple-interdomain-scaling-analysis-01.txt =09 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Presence Interdomain Scaling Analysis for SIP/SIMPLE Author(s) : A. Houri, et al. Filename : draft-ietf-simple-interdomain-scaling-analysis-01.txt Pages : 49 Date : 2007-7-5 =20 The document analyses the traffic that is generated due to presence subscriptions between domains. It is shown that the amount of traffic can be extremely big. In addition to the very large traffic the document also analyses the affects of a large presence system on the memory footprint and the CPU load. Current approved and in work optimizations to the SIMPLE protocol are analysed with the possible impact on the load. Separate documents contain the requirements for optimizations and suggestions for new optimizations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scalin g-analysis-01.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-ietf-simple-interdomain-scaling-analysis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-01.txt". =20 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-simple-interdoma in-scaling-analysis-01.txt______________________________________________ _ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------_=_NextPart_001_01C7C800.0E5D6727 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Avshalom,
 
Can you check the formulas for S03 and=20 S08?
For No NOTIFY opt, I had values of S03/2 = and=20 S08/4
For NOTIFY opt, S03/2 and = S08/2/
For Other protocol: OK
For NOTIFY and partial: S03/2 and=20 S08/2
 
Some remarks:
1. With the "Other protocol", do you mean=20 XMPP?
2. The figures indicate that the influence of = the=20 optimizations become smaller when the status change traffic=20 increases.
3. For the very large network peering model = with a=20 frequency of status updates of 5sec, the required bandwidth between the = domains=20 becomes very high both for the SIMPLE and the XMPP approach: i.e. ca. = 1,24 Tbps=20 and 1 Tbps!
 
br,
Marc.
From: ext Avshalom Houri=20 [mailto:AVSHALOM@il.ibm.com]
Sent: vrijdag 6 juli 2007=20 7:38
To: simple@ietf.org
Subject: Fw: [Simple]I-D=20 ACTION:draft-ietf-simple-interdomain-scaling-analysis-01.txt

The excel file I have = used for the=20 computations is in:

= http://www.nostrum.com/~rjsparks/SIMPLE_message_computation.x= ls=20

Thanks to Robert for hosting = it.=20

--Avshalom




----- Forwarded by Avshalom = Houri/Haifa/IBM=20 on 06/07/2007 08:36 -----
Internet-Drafts@ietf.org

06/07/2007 03:15

To
i-d-announce@ietf.org=20
cc
simple@ietf.org=20
Subject
[Simple] I-D   =    =20 =  ACTION:draft-ietf-simple-interdomain-scaling-analysis-01.txt=

=




A=20 New Internet-Draft is available from the on-line Internet-Drafts=20
directories.
This draft is a work item of the SIP for Instant = Messaging=20 and Presence Leveraging Extensions Working Group of the = IETF.

 =20               Title     =  =20                     =  =20      : Presence Interdomain Scaling Analysis for=20 SIP/SIMPLE
                = Author(s)=20                 : A. Houri, et=20 al.
                Filename =  =20               :=20 draft-ietf-simple-interdomain-scaling-analysis-01.txt
    =  =20           Pages         =  =20                     =  =20  : 49
                = Date=20                     =  =20            : 2007-7-5
    =  =20          
The document analyses the traffic = that is=20 generated due to presence
  subscriptions between domains. =  It is=20 shown that the amount of
  traffic can be extremely big. =  In=20 addition to the very large traffic
  the document also analyses = the=20 affects of a large presence system on
  the memory footprint and = the CPU=20 load.  Current approved and in work
  optimizations to the = SIMPLE=20 protocol are analysed with the possible
  impact on the load.=20  Separate documents contain the requirements for
  = optimizations=20 and suggestions for new optimizations.

A URL for this = Internet-Draft=20 is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-= scaling-analysis-01.txt

To=20 remove yourself from the I-D Announcement list, send a message to=20
i-d-announce-request@ietf.org with the word unsubscribe in the body = of=20
the message.
You can also visit=20 https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your=20 subscription settings.

Internet-Drafts are also available by = anonymous=20 FTP. Login with the
username "anonymous" and a password of your = e-mail=20 address. After
logging in, type "cd internet-drafts" and then =
"get=20 draft-ietf-simple-interdomain-scaling-analysis-01.txt".

A list of = Internet-Drafts directories can be found = in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts = can also=20 be obtained by e-mail.

Send a message to:
      =  =20         mailserv@ietf.org.
In the body = type:
 =20               "FILE=20 /internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-01.txt".<= BR> =20              
NOTE:     =  =20           The mail server at ietf.org can = return the=20 document in
               =20 MIME-encoded form by using the "mpack" utility.  To use = this
 =20               feature, insert the = command=20 "ENCODING mime" before the "FILE"
          =  =20     command.  To decode the response(s), you will need = "munpack"=20 or
                a = MIME-compliant=20 mail reader.  Different MIME-compliant mail readers
  =    =20           exhibit different behavior, = especially when=20 dealing with
               =20 "multipart" MIME messages (i.e. documents which have been = split
   =20             up into multiple messages), so = check=20 your local documentation on
            =  =20   how to manipulate these messages.

Below is the data which = will=20 enable a MIME compliant mail reader
implementation to automatically = retrieve=20 the ASCII version of the
Internet-Draft.
ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-simple-i= nterdomain-scaling-analysis-01.txt_______________________________________________
Simple = mailing=20 list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple<= BR> ------_=_NextPart_001_01C7C800.0E5D6727-- --===============1807250952== 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 --===============1807250952==-- From simple-bounces@ietf.org Tue Jul 17 00:51:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAf1q-0004pF-Gt; Tue, 17 Jul 2007 00:51:18 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IAf1p-0004p8-Cm for simple-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 00:51:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAf1o-0004p0-RJ for simple@ietf.org; Tue, 17 Jul 2007 00:51:16 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAf1k-00075K-2X for simple@ietf.org; Tue, 17 Jul 2007 00:51:16 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLB00FFQ43T3T@szxga02-in.huawei.com> for simple@ietf.org; Tue, 17 Jul 2007 12:50:17 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLB007PR43TNA@szxga02-in.huawei.com> for simple@ietf.org; Tue, 17 Jul 2007 12:50:17 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLB007LG43QTI@szxml04-in.huawei.com> for simple@ietf.org; Tue, 17 Jul 2007 12:50:17 +0800 (CST) Date: Tue, 17 Jul 2007 12:50:14 +0800 From: Qian Sun To: simple@ietf.org Message-id: <005f01c7c82d$f6abb480$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: AcfILfaAdLMjFYHpSpmE4qe/ILY5vg== X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Simple] New I-D: Application Information for the Presence Information Data Format X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, I have just submitted a draft, the I-D can be found at: http://sdsunqian.googlepages.com/draft-zhao-simple-aipid-00.txt Abstract: Some of the user equipment's Application Information are valuable to be shown by the Presence Service. The typical Application Information is what song the presentity is listening to. The Application Information for the Presence Information Data Format (AIPID) is an extension that adds elements to the Presence Information Data Format (PIDF) that provide additional Application Information about a presentity. Comments welcome! Cheers, Qian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From xej@sasktel.net Tue Jul 17 03:49:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAhoW-0000QG-1p for simple-archive@lists.ietf.org; Tue, 17 Jul 2007 03:49:44 -0400 Received: from 201-42.200-68.tampabay.res.rr.com ([68.200.42.201]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAhoP-00048L-Nk for simple-archive@lists.ietf.org; Tue, 17 Jul 2007 03:49:44 -0400 Received: from jyx ([35.197.131.178]) by 201-42.200-68.tampabay.res.rr.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 17 Jul 2007 03:49:45 -0400 Message-ID: <469C7499.6060205@sasktel.net> Date: Tue, 17 Jul 2007 03:49:45 -0400 From: Huber User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: Re: Content-Type: multipart/mixed; boundary="------------070203040507050406040001" X-Spam-Score: 4.3 (++++) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 --------------070203040507050406040001 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------070203040507050406040001 Content-Type: application/pdf; name="Mail.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Mail.pdf" JVBERi0xLjMKJeLjz9MKMSAwIG9iaiAKPDwKL1BhZ2VzIDIgMCBSCi9UeXBlIC9DYXRhbG9nCj4+ CmVuZG9iaiAKMiAwIG9iaiAKPDwKL0tpZHMgWzMgMCBSXQovQ291bnQgMQovVHlwZSAvUGFnZXMK Pj4KZW5kb2JqIAozIDAgb2JqIAo8PAovQ3JvcEJveCBbMCAwIDQ0MiAxMjZdCi9QYXJlbnQgMiAw IFIKL1RodW1iIDQgMCBSCi9NZWRpYUJveCBbMCAwIDQ0MiAxMjZdCi9SZXNvdXJjZXMgCjw8Ci9Y T2JqZWN0IAo8PAovSW0wIDUgMCBSCj4+Ci9Gb250IAo8PAovRjAgNiAwIFIKPj4KL1Byb2NTZXQg NyAwIFIKPj4KL0NvbnRlbnRzIDggMCBSCi9UeXBlIC9QYWdlCj4+CmVuZG9iaiAKOCAwIG9iaiAK PDwKL0xlbmd0aCAzMQo+PgpzdHJlYW0KKcMS/t+L9VWmmnnjB0YCK8bb93o3MvN767atlY00iwpl bmRzdHJlYW0gCmVuZG9iaiAKNyAwIG9iaiBbL1BERiAvVGV4dCAvSW1hZ2VJXQplbmRvYmogCjYg MCBvYmogCjw8Ci9CYXNlRm9udCAvSGVsdmV0aWNhCi9TdWJ0eXBlIC9UeXBlMQovTmFtZSAvRjAK L0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nCi9UeXBlIC9Gb250Cj4+CmVuZG9iaiAKNSAwIG9i aiAKPDwKL1dpZHRoIDQ0MgovQml0c1BlckNvbXBvbmVudCA4Ci9OYW1lIC9JbTAKL0hlaWdodCAx MjYKL1N1YnR5cGUgL0ltYWdlCi9GaWx0ZXIgWy9MWldEZWNvZGVdCi9MZW5ndGggNjE1NwovVHlw ZSAvWE9iamVjdAovQ29sb3JTcGFjZSA5IDAgUgo+PgpzdHJlYW0KYrF6UZF+P1SPBM1RAtIRtIq7 UxKPFswaAhX9DOUzlDdErnmh9LZ1SpziSq1Nwo2ZQlh+Ebgi0tu5yah2owu2hhHgNIdMJt7c+TjQ ooCBw4iclJutLOq3i1qWnqo2WjlY8HlLEp4ufP3vDp4tBK+OlCH7a7hU76Z6hgwq7jrKQI3DdLVs yP+XAsLr03nLe6lqlQdpUz/iZjtQNyJgO8pzaNroxlcxhGgSwGVdCcV++i2YPsQHlXeC6jdyB9Qg 9umUREKsCdnasRqavGCTgF+zDgDB36f1crQySX4kRRHpqcb2tWDP6DyYxOSr6pakxge+5rm1XK4i HsLyH2yU0RP6xO67NNRKJkKEy2ZFCODTrAqMsg3RSKMSNG/rw6gxOpnZQylOPGL6NwYb2TcGNXRf fG3ClGNadjgcHXbleMREuKzOS8prMuJ0JUMYhPuakhA+ZLAu5WRqTMeWw8X+OIKK9Ibqz6EdGeW5 9ZtFDo98Dhr0M0UfHgqhHWQVysBlYOLvs2eIqH8nBCAHdRhyRm9dmaMalbSkwFFJ8CPfU3HYq6Lq sQUzx/BpLH5pxfuuhQ7mRKp2l9/LrLUYEYk+B64f5vnj3AhsmWfRZN0IhB9Q8yg/El4pRL8nxXYi ifHia2USTbAFsqP01JBCIoAlpJi4rIGB5caGs3v0s6Nj9P8aEo0VKAUT10rUT2FVZYsM33cFkuv2 LI6cRboCJtyg5PJ45r8/yN2rlLFcv/6r04jcL0yAbUJyJ1jA37x5hUucmQJZT9jsgmQZtunLtpVf 2GmqonChDaA247VDE8EJIw3S9afnnhGuX8bz8bNUEokdQzIn3r0wh5UGXvhA783Cv4aI2K5RPm6Z YbxN3bxl6BvlSOOvLgP/v181mcEhR3/x80iVOz8Ghn4Rhu2PpCwiQv3lGicbSt2zz88DAJvs0kyX 9FezWub703h8ZkOhlng1mq1XUS8MoAAx3MIUDjPVmQuVA58YF+ynNnQ405tY6POcCwHy1EdiMC0Z fx8rafw8C+n6INJem7ZPtvK2J+HxtuM+K5ZM8o2GsqgJWNtJok2pnf7QqTTP+sq4pCYP1pHqn7s8 lbyYebRYTrWbepGzsRw/qdMGkjFG7R7HrXnyNBPOXh5ngSgEpJvhUyLhhlF/cQM8WK7WGgSgLt7r Evx2+LrWHsrjtwngRqzrlKzJyy+3QXc6b22gILyzWGSV1XwpTcoH4ZY6FcHxEX9ndGI8wEzlMvxt oUINPa24fas3rKbrTUmSo8sfQeoAFt72AXhPE6zR0kfWol2sxaUkS/zgJlN0ReeutnU9uHFedN7g JcsbJz6x4UWGCivE553+YRSbrD2cPxcSsDQWQQlQpjdyGSUXBGgL+qW9IukgBbjHvVZCK0jsFFmH tSdRE+7HjDHeb9yZqeeZPAyJybjlNTp9nsu2/hejLJ+prgcAy/uXXTrLoKgbtXHri3SoDiVVBi7m nXfeWFAzz5sO1DL+oVQ6mpmbf9C0tVSwyjTVxT+uP/6UDNQgHF1Z5T1dMOrEo3l+CBNSRW/2xGQr EFDUtflZlyuO/u9Id5sG4jthz56JtaY7/DCcfv6OfeUpmGcq69R/VNbS4v6v7ts0nsqti30z3+LV MOxZA/7ZVL7VLyl0YSwkpTACPT2dNKIsJc/l6X5rhVm/h0pXsmAwh5HV7q067pMrULF1cXuzNeDE QN1bjuHs2C4hoBV+nKPz4vsDcmFlqGIVNu8/00nynt3Zffq5RGxxUlQnNgBq++Xf6cpad2oenAI2 7INp0Cyc8k+ggzSTivCjwBT6VmqOqF3qFYtz6HuU9/CjVdRdHP7iTLvd99zVssIk79vnA3WgNzen GIMGjZ4oaJ0GjYaO8LXKNO16Pxsc/MGopU/nxjN1/GTWcGW4T0GBdj7bj2N7/AbP10AxZRqI0/PB 4XqFon7UKaobh2CH7tjqfH+w17mWC/BoE19HQi7o/pFqht7ZG4YKyS5rwJ23vXJW8lmUjlo0k1N1 7OKJkqHaia5FaRBcz4TvBZQhScUoGs0ilItzs2uiEbXaQ8EUHSkJHaGlRXbNY/CeC1LM+ffvwAsY 7wa9fJde5V2StpMgE9y6N1lHl6M83lVwATwYcYVSRv0302yiVfu4MkTJepqYFYoyxZNqbTOV2/kJ Jvl2cSTVnMkuKVdD6L0thYNUWESYr5v5+EiTR8wypdH/jne35MxpC61qSY+Z9PTmffxptTS8KFHA Sj4VYKOgiuclpdhQYSQY3o32ZC7egWH47ESdBQW2KRmjZsocrH55hwgJI0Dqvsm3wVWbFgfJ5BSU trYTGj+MtHdq88zIZY//ncZp5uxWoq4lnX8IlHQrrgF9VgiOO9mZGTmt73VAABV1muKNwwwSaIQb 0Dsn5DG2BzZ0EUtiSy7mK46fOglaqPyhKPhZzjJahjcRk7zaCJebP3s0fi52KmG4I5A3ZDBjOTwY 7knM3FxZ2TV8AJhg+un9m+F2B6gsLkVNEOSksTdemmhBDqP75piAaoYiOL96MWX9lOe3LQlEpA0f /5KJ2iFBVAjL1W+NFXXtQkDzW5VOJWmUDfFF3MBlxB+THPF20IVnt0DOCaYrL8jOymjnaBZhZfr9 6g+Y5ivqsctyXhTUXuWueQBXs8pfFqOJ5DeWbZn7p8xVS1nTgDg5it3m15kijv2YYNu3rzxgFHPk Z7KhQgyeBL+ow0Hp0oLzsPbpv3P5GrIOPrEnaXJ6AKzbKywZSQnxIxKCUriMuypFaK2xIrRfZlWe LU9mRsN4DfOmfE+goOZUoieoylYF2SCLSMw+F78sDVlvtr6gkTbjoS9iERsVA4IVwGs25biFmQIx 2x0Qax0CMY5TKYz4whfSZe/9StNgvHP5HS3LJCsKGtRLl+ELZ5CEx2UMJ5xO5PCGVXCDWFo88Ja8 HwHzm1TyMstfIjm5h70KT8w0anWbqYF3d9KYGZVO40SYty8OD9ohsguRi1HQgZz3p7MN8fAVafFn jVISacloT4iMIl9EWiMq9fWuD+txYG9TtyFZ5yMaOsXhLaWyHYSw4RMAcyyi9yPaKeHz9d7Y0flz 3aVrK6vzl1huQVUcQ8/Y7Ok0LWy6I1eQ/SNZbcLofXd6wqU4LLnX0YvFcqVArN2lTMOYRIfdkC4n y1We11j6SNMRGIRTfGcUqEQipugrZcmKFMesTYI53T5RiDqa9UH8dBI6JcVDJqXl980HkuoU12Mk 6Ia+o+GVckCkPzPpl8DeMYEfRVmSSZLj3342LRbUulrLSehAEWB0q+QhkO7GZN7CWgQMWjQntfXA T7Vn/cKiR9+kv8wbdQFGLLj/6QA7G2qJWkE9YjbG2BuQoxsgz0XjWVPnxpX/nQNnVeGiWLFcPcGn 0iL/FF9B4yAVyzwe+4MnsheiwSe34uqwlsj0UnnxafZp3rkBei60Oh2H6pQl5qGF8Y4Hk/tmGsq1 6tQbaMZAdEKaQjl4U1wZyo1lLe3hYWwSxWDvla6k6NA7VK1qpfDCLZL5zrzVvkKxNVo/wSQ3XStI UFePOt5ScqKO1r2l8UB489WAY1exI0V87k1eUw2CgsZytVvfi0skHgMiVO5b9+fE6phdNDRq3RXS qshyhFfymfGXZwVqMd0WJuL+Yux2tH4allCTSgQRYcMdyyiULT/RD34BhcpIpPvi6e56Yn3UoyeU YhfOoS7REZOa15G7J7eovEFG/v1I67JEapb98HuaHTAlNSSyjcq0riE7H9dxkHCf9Fs2E5oJfTSs wK9T8Zbjdr8BpI4hkg74obQtVvxmm+l1Vn4LiO//wOYsl6wwwO1/mbgttoQB+MVHtVqvj6Rmm3BH 35geb2kf5+icdOQFdHvRJQIBxwsVwij89DCCdenGF92zXLsTqDO471oX+vKeitlPWsHKqRWjQIem MKoSF3G1yqGKqfTeiB1tf+YyldVhdEyKoDkKEja0/TOx3lHQEZCLwSE+xtS88WzTAonVzjaBli2T 9BnVsQ06IhR+Z5PO/Pnk6JPbQ549qPbBJ6lj2RMQtI5ycBhLeAahNTkldJCosXQlsABtLf7HrOXF UzKrJVjLNbCe0hK45aXosY1BMKYr2551ZxXdPgpbsHHzYy+yXzRyS2IQ2DNzixCJMTcwr7SuBtmj AkSoKcaMauIwtrFI1wE9SuBJdKDcXmwjdMjjAFbeI5v37Hr2ZFFqpGhFpzwLDVoJY7IRDPMduRKv vofoczN/df1cZm7VMxSIFOL0kokfY58Y8M83c8+kh9dPmqXSQskNrwxD53gAp75INrCeDEdkr9Wh laRj5bEmrUiyIe6CgJxft7zFsZ0OBbR4cfNuWjqwffJuyWS/IfcnBZoPhgLtMET+nI4junxqOMv1 GyKDmSRlKtEdwiTJtAWUgXZdzZIlNlQZcFkj+RqjOZ2ccCUnpI/Eh5x+WlbiNvAxOhEW9D+8smhq /ggZyeuMh2lOnaC+T9NVk8ZFYEDY1EH3RDxxg2wAWTEp7qn/1FtgfopXGqwnimp43L7IEp9kh3kK qg/UyIJXE3A2tf55Fp7WSuMadLxyb4RAYgrXDkyDRm0PXsPXEiojdVJag84zr+VWCOzQxPxdWbxM z31QYqR+iNnBjUPQUJPfGtLAhB7HxN60mh5WebNTepDcYFkRhutp1leFNknjEL7f/IQtCy+CxiAG 0xNf5jEhh2bT+/Z6WEUEVbFh329GH+5RcVmTNcb9Hbg8I5oPRq0btWnA5stvstfM8fz/JDGtj5R6 DSw4ftid2P+bP79x+j+zUKCNut/wBCHhWq3rCx3d+8+dN37FIRPa6Efz7wS8fo3bVydOfKlQL8fW jxkTnRmoyN2+GBffmzdKRb14Y7rUS1Kd+Vir7JGfVLuUjm0gxOvaSJyCetAk2km1Q/jVB8EwNZMc p/nQw9pFfDlveEhid1HPnh+klVdw5Wr+3x3fxvmWtoK1cRPQlVY88OTLokM8Vr7p12pDRvV+BVoq d3npfum92YsIilcgpjL5lPshloPA4nI7Fc3ZpoRuK/nvastjf0C24iQJSRq2fhFYi7sBpflSksRv BCkSQOQU6bFaBGpdNBPYpZGER9MSDJZ20sjh2kXsghUfrhroR7WEhG+8ROxbkgTOgkytfyYua7sQ Y2NllHyb7RSuGYid3/IGf9n71kxscYKkzuB8FU0hjpuaiGKN9HNM86iRSyYQ6LLKNVdaP67QQWHO 5K5UQD+//+uvZlkf907e66ArwPBX1w9kbs7lf5uuq3AdIMc9MDFhLVX0HM18b5cdIf8vWRZFUf45 RsPpK6ougPPRB2/X9xZhHSGaMbn+efJWo4OorirxqXc5rCD+py5NLTjbgEzZP7X41uzl7kBBwjKa Z5hpn+7SnbwDuJbISUi4gWQT03hom+ySEu79qxUnurw6fVK0NJRNI9vp796q3hq01hFtdEV0QpQ1 zhIGcvONEPdSKgqar2dLcYsk/E84pAZUY16didUIMIKkTPpK7eVUHq/Fxu14tIEyHatOO+DArVSc kq5l4joCnAwsqHeqFfj/E6z30lt25QZYdnyKmMO2I8zIXRsLt3twJ6HG0rtdxHbh1vFrvFrSr1QR uqpTac/ZWEi16ldNb/EVRFXdo5XUOq04gR0FmIk3sAhLlIHDTzab5xiHE9pilqyawayyum7QNBE5 WQhMq3NEaM87QbcGIdpBxsh8yllFEKs3h72ev4eAIfQmQiOwUKl1eUsZH5qGQO1Ol9mnIsC0iduC nJP9FRzjvzYawAqKcKANGM11nEDlCCrPx4lPdBmWsyutEvTz1bw73dHypO02bjXU8upOKptmIwCb u6lIQjc0RMD7dsivCgubM9qeYxcNlIw7ShwIktoA+qxop10AW3Fo7Pax4cf7Jv6MaEwQycIJIaIl 2944z2hel893JHpA5QtzWoXId/jdXCYNXSBrRvPnJHlNt2DthBszzMlrtL8j1F1q7lpsQ+RKAaXO KpW7zZ8NCd4r93226VUVBl4YwJq1fv4aFKJFKxZHkyz4eicNvTTkrUTeY1FJFFWHZWAMYJSSabdV sO9YxyELX5WphQ3vqMtBG4qvMsET9Rouya+5YqsQryAoy9cYhQu3OKBl54mLK7p72Vtniv4zSOnj 0nqo/DJi/fPO7h1hhYtZj26nnTc0vHaeGAmzkI8QMvw61jzJXpev7xel3oavx5M2Lv+b5zwrnDqb pnR7RCma9kGryn0dEXys37PibOKe5Ci84ahcBL1lAyjkXiqnzGCOseaAETSAzmYSiLIN5kBo/7QL 64X3M+6kMLOUxh2Q421L2Cxg9JklpjXUYTlezLirqu3tKSuZb+BaCmp6vsz03ES4CKTmPa9q7oBz g+eRl1u5bpF7AbPll/vVbN2xai5K7nL21g3h6kS3QZnlqwVCyhqyLpqPVdVxSvZDiFAHkwhpO116 onnpLgE8cZdHBEhkwFCG8Z/ngdFzTziMHYhVQt1UuK5GrBOAEtPhp70Fl7z+8GoLd9LRJi29kWNh W0X4lNJSB6jS1F6/UNqizI0UUlRXUU2e2rHRt8NKN3OqY7Qwq+1xL3QLtwkGa46Pmj4e79zzfVx2 6khTbz3xLtMwGP6ZumGYcnqSC/xshc5X0bwkoLMJVPVTaaxkRZTVbd3zCmmxvmt+j3hb8uiO/coW TgblJb5ApcjjonkXrqpFg7PUfD3+H8rUS5q+A+1w7Vf6voLcF0CEtXxyLu0QZh6QotlK/nG41Pri PvaUGFkhhGSc+398140VifZVUs8nCEtMQz2m8tfBWZBTGjViHKEzyPjjJUC/bwJqDvLvwsRYAJdQ MsSZnEU8m2A+VSxeHR8XrXSbSsR2pi8UNzF2lDJCvSvDYa7++Mw8Jw4t3Z+sCaeOb1yQBEBd+NJH l2rqWv8E+2bS2jjUN6hL9y98Gy1OQw/E+8WKfwQQwXcaiYkcs1NzmjDkZYTnmXRifA1XdSWxnkXQ 0t2uu7I1yJFQTtCc6tEYa4EkIOHhR/mvTSnMZ9/IeUDO8GDQ5J9XAhWGI3fisBeKUrTf/nylk0h2 Dspx3qCoPNOiPi0iJerqFrLbBFtvYdbcbsniNhFhkKfMlf7QRKQguV9wCn3ZG7t8z8vouziC+tY2 n9YYGZ+DtGxNTkuzod10FZLpfJP4cZyQaOOxnvog4uT2G4uhWqKHxnKpcWWKxqP+jznLxKkFLB3q hHcksKrF4md8wBjCbppxf72aIM8uM4fmC2PFBsT9deXglcztM3NYr1kkVF4mu32Vl+fW42poshCZ GmeYEDfLfWaBzn5CsJNW59RmeZYYUhHWWImSVib/hT5JMh6XvL65T9PrzUElvgW5sY75tJX6Hpzj msvCRSZsU1vR9sUwiuTRhseuDjCI3uladibUJduqyn+3Kd5eHdUijB7otB4AmjVNv1p0A2MRW4Ha ehvzxm6Bgryq6Xg3tfaoENEWGGgMixhEJwmdFm71ms4Z4bQpdwXDWWQ14ZRbk2u+Vl4F2n9OGS8F 81SFJ2Vp4wxqNUB+BqsTG0hx2VrXzT3KHUDXz8yyZJHmsXeRY+xW4rOvpvaI7dpo848OsMwAMYba 0dbP2qP024Q+LZkVIvYmjo581eOhCRHiMxCnF/5zXbcOMT+AUT08ZYNEJcfy6QDDeQBCcspiu0jI O2nqutr/SMEah52mLNrVH01ffCwjNJ4Yman1FGotYzANYgINoKyJ8N0gzRhrrNhTcaB3WAVnM1Za YmtsTkvkl/sccdRzIrKRHA3iFeu6DjzvxsQgp7cCi2+8fsIVv2AO9FjN4thmcXUVMlOZ8vbWmfLO zTd9dXY6dlkPKmECBXkv6AnTa0Je9T9h2odgrM4NqXe0IUNmEP2bJPHSkd1jt9sPab932JTDmb8M 3xfVJ2OWdN1B761oGK0RbYZ3HelTNFY69RAo0canq+pO9AWctDIg/oZewktHkKQwa8i5wrHi/bZ/ mfPo42zevXZd0erUGmu+COSyf8dNcKTe5bNG8XAsxdO9aqgYj91bczqh2jcNztoNwJaFdZ9dQGcQ mjHeEu7h9yZ8VWQ/GwxpeRhoNy8h1wxVGn1WciskGNgxmVjsT7TxUaiZETsYMX9WWanR3SKYJQdk 5CrUl0Nm1Ze09PC8Guc/HrMSX9hvBlTrg0sIi/8H+FEW3ZBwOXUwWOxVBInzsNmDlK9ZenbxVEZL cp2mnWAQCp0KTQmYcZ7WnvEfGl2FoK6DyRIhoUhB55O/WSGMQCI/mwplbmRzdHJlYW0gCmVuZG9i aiAKOSAwIG9iaiBbL0luZGV4ZWQgL0RldmljZVJHQiAyNTUgMTAgMCBSXQplbmRvYmogCjQgMCBv YmogCjw8Ci9Db2xvclNwYWNlIDkgMCBSCi9GaWx0ZXIgWy9MWldEZWNvZGVdCi9MZW5ndGggNDAy NgovV2lkdGggMTA2Ci9IZWlnaHQgMzAKL0JpdHNQZXJDb21wb25lbnQgOAo+PgpzdHJlYW0KriYf S/miUBTgonnQjAn6A3NeSWNcnHjEXvuH5WZKfgNa+ekzAzjIADuByScxZ7V/FwwGMuavDcUvGiS7 zn6M9zniGMZ8SDxtlIOTB+D2dMuozWsD/H4X2+3mQDsTuqNoLa2yYKns3WFAdrH2Yxn0Sw8NFKal +3oAZsZh62EpBwWBRB9pRWuupvgEizYSzxM00ZagtA0G1tnHVbIzaizyBfJdYEruN0WC/nZTIDBO vtg4nuK+gPTd4kBwD7M8JyvX3WFIHV7BrQR+ulUltV+tTqALdfcetqiDAI6Hmd8DNjKQposCrrez z+MDUHAfyTu6W04ChArrrxD446fy18NKKu4F5orBfcM1vkgoJRJcBnH3cDj0sQvOXqZc+Hkz7+Md a9ZAClfYsHMPt3qmIAY6jO8OCGiB9pY+xL2MlC3J0ICbuPnw+vC+P86BD/kScLyhAvIx8h6E4AB6 2jE/4Io7QDf86lsBWdoTGzoV7almb6vH+yBkKkAFOxhiWvUXubTowRysStA5CEf8/M8dIhBZ8esz hZllW4Sbg20Bri04oDXXIoJbYi04DwALblkMMkQ3Fq5ez8UFmIAg7o0HUTlV+8lxtrkDja8tPWV0 fPLKb2B0k4Z7qycpAOxG78jr47dwoCm/qbgkykr/Z2nM6b3o5dlFYE8KzGDC5p+PFX2+HK7dMeCB FsaL3WKrR9PgC/jltSquqlYz062RAnbMnUv9irmqaRfK1gP7RSJsdlK3cp8xXMY0WZqveka7XIhX crayEfERaHf4NFn/PrBe2oo/kvWRW66/x2er9yhdKBuvOrN1aQdrB1SDusAKyZOnCyHhAX4gQLmq bjr5PlNTtgd/0mQo7LdHnc2OwssFObalJilEFjquvrY75X3cqFkKxg6iwwmpib4tSL/uvlHagNns jVTmRWLd5srnBivmirO7BGI3NmTaV0L/XvAkKv8ZACXnUFtySA4dvZ9FYNY1DDC4h+tUepSAu4Au bTu/JgVckZA/YWCjSQinZsjP0/Ftfr7vm8+M552yqa0oX55gy0pNObmFADPsivW9oLzO2whHrnGA UofzZC25IvWg2/5dy2cNMBrrO2qV7XeOjT09+b4WUN4NXMnSGc+ikyv5ieNvjG8pjNDYeL07SsYB Dr3uT+3WqI4RfzwQ249+KE7lc/cFlAQEPYzgV3Rs7eCEq7Jnat7xSvt8eH0arV8UQ+uB8TPz3Eb3 OUcNEfHAWUA0Z/2o8eQ+Wz2d5VVPpnPT3kmnbE93gneZ7glehScpMwGj3RjLOauPcwUSZJF9wwXc vs5UI3EEB5Sfv1bKq0XqHq/HRmVQAVtCKkPHLUgMriQXvSQA6kx8o+uHDj01sVMCNqGoye8sghjQ qg5V8hoIJDRSTXvfOZBjrrZfFRKVi21cQBIAL4w5j48DzQmxE6GM/5lmx971IUl/mvU93YxQz2Ag qHxrRIV/ONm88Gj4YjPwdSTL3zAJ8IXi9K/6JkEtXxajm5WlNLxFFZDL9ePOlpstpaNsKU2J6udf 4Fm9saPnX9hAh5BQFlC2fsB99OUFhT2bp9RwclQR7M6u3xk7c2hphMisGnvHYtgy2KgF1CwLSwVm 70d4KHrVlwP8VO9d/GnAQpwKgYaW7ZHDbq7+gfEFup9mJgWRoJe6PAH6KNq4HT6Vn/EcTp00Ipz8 HcFVyeuirFzrBVq7rF1yIhkF+mGt557AIh8liD+2YXMgx2guE0sFYPaRbmQwsteZhURd/LB8UQ4J H/UMc/VVn9iS3TnkzH2q244BghZoSqW4HGhOWar/jXQbnmaZ314Fozx4B3LjNVuHXFjorsTra06U pcx/5BheMk8jPdjpDqK+XDh7Z8bHOxPaaNWEzdNaJ5fP451uWuqi7mpxyA2Xk91bf1WscLAVhDPT QhpzjAYfm8onOsUd+Y9CVGRgCUZe+RNXKZF6lpTKt748budxVJCzmS8tGSWC/dUrTdI8ao/iHvNI kA8V1zgmozA1SDzeD4QG4OqeOH3BqMVpHmL66Xg5vfeWRJHkm+vZDHyYXbgvX3AgDbfpisnoX1IA YIsWNCA4BoycKlZVgASazW2+sFvCu3E+4Capp+RP+95CnQ/qL/R2+gdRUjpG/K5cmW/oqNZ6O17W 2+3kxMsm/cb3hANPKfbLfDko0TFP1O3Ny7c3ZauF+3MXdvGQH9wOn0havVCByqt+LBXedF1OWGQC K0GSKKMLFM5S2m/ZfFiUwqWVjmaILTrtTzGaIDhJ/Kge1v5962ESI3Yzjdd0Tny1+kbFwEg5Zpf/ udzUzTndcDCci25345YRSSeX35Kan9PDvy5k/zJRAPG6PpiUMqtSPqYbvmf9uMv1UdMAt2lPUXV6 CNTg7+gFlHavQxoPaKFJPjEJimwUN5do9dcHOWOB5GQKU0BVosoS6qJhIAbuVa3ZoU3Zv/J2JFO1 rZd6RBZw2uSiChs2A4TDiq7H0PG6gKBi92YAlh/EvAF7m2fq6sXy9hulBhdcY5iA0qj8tx4v7NRB 9l5VljC1LRSJ8awrAU2FZ0sp+xHKV3wuM/ewGZTV4gSa9ijhcIoT+mck/JVpKVMla2WQAI/RPKLy rUTyeUUvcGcFKOYgwCfphrRqzzhCTJekqZKf+7R4rjBncBAN6eWuD5CK/8apou+HVUIV/qZwvVL0 1ZeJsMrRaiRzdcLbXOtRiws/MKMH2KsIScn300I25BqGUmMcB6oe5o867XqOt8FMZ8bum8SYcPhs FrLTYsQ25ENG4EreAq70I7BonLSXFg8WWkXJDA9vGGoA0KeYiVm9yfTPOwq8xrfJ7aVezzdjxg8v UQemNLiIlOnLBSmjL5wzv1FBfDunmNueFOErDMyPp4ns0DIRgg1wImLu95ZI/FnLwCkaU/XmwDnv bfBUJ/FjJpOd8ygKdIxVXjIdwJxEPM7KL/R6bCKEXgYBQBUlLMS2llYQnVUIGyiq8V7MjlqvVTo6 I+rnDJBy6J6jecmWPN6jkr+BTVFVdp5m1ALVrpI3eYJVU6k2Ijw2jL80PbKnX+KrYMXgVqlcCXE6 8nQul9AyS7KeKD6qJnHGutoAXnh6yJSupXaa4F5apqXn90+XOJPn1eufL/jbSBSdsInHy37iBUKw w0PLI7+Lq0Qf1XVFDxAXz3JMW7v3oQd4rsq7EpckDJHzP7X2OCsgJMGBFr+2T9lYIXJbGDldkVFA POCaq7eBdVyiu5wzhgtwLAYTfVt9TM49vf3I69SWHwdrF8ysu3nm6wYIvunIcsXPHlwhnLNX5Sc0 7pzfqY3795kOHTmITkv1ecJlr2sXR6QAKcAoRT3MO+YgRJatjDFWf/a3v7DVaObhfRR0nezf5l4K COBcIiP5bK95kfFbNkJrsimhARjnUmeP/q+7PB4lnI4TkJkFhFXUfpOt7haAIO+CqaqgDCnkcsW2 Fc7Zz55c0x8h8uL/fYz5d68I38erBuyYIlzr/7JMGO3Dj1ZjVC3UQt0Jg2Z6u//7fU7+7voSVjpJ 7dnU6Oh6YS0hZlOlsrhxXUxPL3zQOLauuT3Ddg5PP1jxdMjf+k6imj01iwsaSZXMVwm0ULUVONeR P/eFi9Pwy4niNjxfiVlHDWlw9Oj+4oVwMRXvAkvs+9/hVHmEf9+5yLNAzbeeDCYu8c+UtKJLjHah aUHa2rKEELaZvDJBMPPyP7AVhYv8asIZgvx950xKOnnK4z2sWuCvV3UEFvfH4wyhBVPsV7mwy9GN vB4tyz4W30Va8jUFH/kqUNkz9QWinzY8f9kOfwLYJ7f5IJ+FeV4B9qcWEEdpyLmIaMw6vS5THSrh s8A5yH81v+A0hxdTWYLuKNKz6IZhJMvhA52Tu5tW5xuPbLmW4FSbgrMFqPfT22MyCXcTUNZXOLTK DVsBf9iK7i9rXWlVazHZMx2vqr8UswyDGSIjmsh78dDQkt5xk99C7RG7GKGxgHBNba8j3lt1VTAl jjzxTaR3pZQR/cbsydmIANW8HY4wKrxorkAK4IlWP5T62B1YJWFnZSg6PXRaXQlg81DFHipE6IyL Jdy9hhCv8OFOXKpz86tkt7vfcGzODMAJOEfXZdeZ/TNbXDTftA9kx1bnww5K7u3r5lUqqJF8iXjH o4OoySQkYX/GsMFagiN0KDEB1hRrmB7+cYfZDJCNrnL31/5u50wOoEAceJwIb3zSk9NYaJRy4dlx lPpIL1RWqt9Ibwgs8DanTUuvkyLE8FJHi3uiVNEYrVRBK6jLKZ7Az/LaIMnrzR0S4jZ2m1xg2heX rMozi16t2WVhXC/X9smU80Sq+SVWXX+fMHVE67eMUQum2b5ZtObEQsJdfDgEdYlvFIkfrRLWr9Gr GtYtSp9P+Rr1y8v55/P7SDIwlTjKzzN+nMeICg0Urp+XowFyvpYjcj3fDR89sfcF4xfb3wioFjkM i74SS13gbNOtmjXGSY1vmMu+/zl9ne9R7lCiI98jaLsMIjB9BFvls7M3nhUK2M3Ja5WH8jSuKpXF c2ouc6gjeyD7XN399l3zixN05wFQrUMAhUl/sf4l8QXI51Rzb9ag26Ra6ifBQ6LWItmM0jszhth1 iySPu3rwKXqFcZnQ7SPqVHUr0AW7VUGSx0Y/oXafHRKn44QLaQiJ/ILDm180KlyL4jdJiopMjKYi 3MJoAgYIvG6QozPhJYXdqUSFq7us6LCsuowTRwjojub/I/BJlXLmbCP0SurlXymydEyI+4NPZFM5 nYs7G7iMO45dAF7zNwMLRwYGuhtaw2k1pBel9VfdnRKbksOch+Y5NosBd0SuHDeOwJPe47EiGor2 cwwn+lWKlnGFNGg2JNxnQ2ajBMf5V9kbsOPf2J5pptAur1hmKfPo6FQGOBjRZ0jJX2lZwg2bqry4 U5BKGAe0p1DFOTF6+nSJQgnkDbYNoZkiJNtEoLUPD9FhHbf+QB5kMl4mUxCizrZQ8qtm5WdYFtBr oq3bOuWisop7M9siqNz4lP7Ku/BSp6o5ru/bGfK6vA8wLzvYlobvg8Zy7W640i/CAX6e5rEsGAJ2 j4Yq6k+DzjNKNdLAAzbFVmHXD1mdei92eumO6XoGMDHXxDoGhzg3mSxlD0a3br2z8kX45vLpjBed Q9J2T1N+qu5y7i8V7dSZ7Rt8KX6+An2AkBaZRWXQ28EoHBNhl5jbvq8DLqtlLqzWbWucPEah7+kO ouil7KhZO0tJnZdAB4Vj0lK6jUhtzJnqi7wHps2DYLNs9bPjFAH4dYl2B5F/LHiKMyiCxZqgg3ro EOSJrQ9HxOYf7qSTqQPUDKRDd1bm3gDAwF8wVUMi7UHN522eqPaIMaVAbnDGg86CG1RKeT9AJRyK ppgBCSzZ1AVFipR6LG1g0ff6zkBQrOpHAm3W7CfCYdauCmVuZHN0cmVhbSAKZW5kb2JqIAoxMCAw IG9iaiAKPDwKL0xlbmd0aCA3NjgKPj4Kc3RyZWFtCnnaoJuDW87/Kaj6KUG0THwqNeU1hMQYaK0s ZJ/vaH103OiQ3RMokKSIUGINgfGGlLhbZUkAWmIBQjK2O0DBxEowQJilD/Jd439FJxGTVKh2XDi1 lqbvgKWtCOkwqPQsa6CdniYeC0cgRDJ3hs19PMBQhxHcGa6I4T0DvyaePoxEzcCD0BbKRJKWSDnG ip+8+5oVOkbpSYcFuAezmK/Lla7jnMQrcAWziFXFTX7vF1sNWMtOl4Q8r9+3AUHurbs1dA5Tft6y vuzZZIXRs9KjKzhQA2lUo4gTFR3z6mUBUO9eXe6CAwxBfGRf1pewqxiWFt9kT/hvE3mS14cKGTOt nOZEYya9OK7TEd9aqT20y0UFVQGOnUgD3O5j308grCjG2hkB8uxh+U6lxecBLf8A5go0MTCq/oRC 8ag64vrD/dlHx46NtpVST+L4SbCRmLbnYAlg+iNpHVmhQ4MnJjGX2PfQifBfIOwjm0y3//UI8mvw 6M7QeRp4duTh6DO0DtQ+NqTUfawfMvpPcnWY1nAI0SzsebZeRtYmvyHNqTar68/oOe8tjGM1kKOc iJj0pv7s3S2aYHohknN3SuVfiie4PnO0opqMbIh9kC0/4ORG6DHLYHyG0688mUEQZPMIypYJm5PH qD0kWQfkbqv41D7RjAjRN5550X5Y6I24qCZX21jo/BljbX1Mb9DvDZoPFmFE+ga0lXSwLao4Zusi s3YY5q+FLb9Jo7YlCHoc6b1vkxp7JzpFafdqWzXbAcSvItbjiEGAmfL9Ra1VijOfydyecLMxyNdT G9c0MkZ/R56GfAiUNbvR9jLj3bCyNOWPsjMDRZ03QzqC/YtyQnwUVcbg32wc5uTAGaV8mmprcQua urnJ1Dl+peCC1i/fTZRC9C5fGOcMXiYk/xavY4aEBswuDRiPUItl7Y46NBz5dxI5Mhs7UCD+qBTf rV20iC4RJQAy3vg4xazUdJN/0BXb87uaBZvwmLT56W7/w5RmfQ25EUchKllMFBMLFgjZltWDc5um iQplbmRzdHJlYW0gCmVuZG9iaiAKMTEgMCBvYmogCjw8Ci9SIDMKL1AgLTM5MDQKL08gKDUE9lxy ERu+9xcUUZvzX0P9tl9D0d7/MGP0XFw4d6m9luIpCi9GaWx0ZXIgL1N0YW5kYXJkCi9MZW5ndGgg MTI4Ci9WIDIKL1UgKO12rVmJUk2dPlqWOvKxXG6lAAAAAAAAAAAAAAAAAAAAACkKPj4KZW5kb2Jq IAoxMiAwIG9iaiAKPDwKL1RpdGxlIChkmj5Oi4cEa3l+kSpdKQovUHJvZHVjZXIgKF6DMEqFlRFh YDOKblxyNzJcXFZcKRVFrV+MpwRZqVJAuUP+f/xVGxuStHQzY4ESqeVXOPu0aif5fE+2RCkKL01v ZERhdGUgKFPUYx3Q70AxOGfQfw5cKTdBKQovQ3JlYXRpb25EYXRlIChT1GMd0O9AMThn0H8OXCk3 QSkKPj4KZW5kb2JqIHhyZWYKMCAxMwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDAwMTUgMDAw MDAgbiAKMDAwMDAwMDA2NiAwMDAwMCBuIAowMDAwMDAwMTI1IDAwMDAwIG4gCjAwMDAwMDY5NDkg MDAwMDAgbiAKMDAwMDAwMDU2NCAwMDAwMCBuIAowMDAwMDAwNDU0IDAwMDAwIG4gCjAwMDAwMDA0 MTcgMDAwMDAgbiAKMDAwMDAwMDMzMyAwMDAwMCBuIAowMDAwMDA2OTAwIDAwMDAwIG4gCjAwMDAw MTExMTEgMDAwMDAgbiAKMDAwMDAxMTkzNCAwMDAwMCBuIAowMDAwMDEyMDg2IDAwMDAwIG4gCnRy YWlsZXIKCjw8Ci9FbmNyeXB0IDExIDAgUgovSW5mbyAxMiAwIFIKL1Jvb3QgMSAwIFIKL1NpemUg MTMKL0lEIFs8NDlmNWFjZTY4NDA1YzBmM2MxYjc2OTk3MTE3MDNiYWE+PGEwYjQwMGJlOWI4ZjQ1 ZGQ4OWVlMDM1MTE1ZGNlNzBlPl0KPj4Kc3RhcnR4cmVmCjEyMjY4CiUlRU9GCg== --------------070203040507050406040001-- From simple-bounces@ietf.org Tue Jul 17 04:13:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAiBa-0006FJ-Ay; Tue, 17 Jul 2007 04:13:34 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IAiBX-0006Dd-S9 for simple-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 04:13:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAiBX-0006C8-7O for simple@ietf.org; Tue, 17 Jul 2007 04:13:31 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAiBW-0006ST-Dm for simple@ietf.org; Tue, 17 Jul 2007 04:13:31 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLB007HEDGNGG@szxga03-in.huawei.com> for simple@ietf.org; Tue, 17 Jul 2007 16:12:23 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLB00JIODGLTH@szxga03-in.huawei.com> for simple@ietf.org; Tue, 17 Jul 2007 16:12:23 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLB002ZCDGI1Z@szxml04-in.huawei.com> for simple@ietf.org; Tue, 17 Jul 2007 16:12:21 +0800 (CST) Date: Tue, 17 Jul 2007 16:12:18 +0800 From: Qian Sun Subject: RE: [Simple] Nickname negotiation In-reply-to: <469B4152.80607@nsn.com> To: 'Miguel Garcia' Message-id: <000601c7c84a$315be6b0$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: AcfHj/K7AgJBmP1eSVGFTh1Yt4ewNQAshruw X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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: , Errors-To: simple-bounces@ietf.org Hello Miguel, Maybe we don't need a new method NICKNAME or CHAT-COMMAND, SEND is enough for nickname negotiation. For example: MSRP 6959ssdf SEND Content-Type: message/cpim To: Content-Type: text/plain Content-Disposition: chat-command NICKNAME "Alice in Wonderland" -------6959ssdf$ The above way is also suitable for SIP MESSAGE or HTTP. Existing chat services provide users with all kinds of chat commands, we can not standardize so many commands. A more extensible approach should be considered. In the above example, the chat commands are sent by using the same channel as chat text. It is also possible that the chat commands are sent by using a separate channel, e.g. control channel defining in XCON. Only a control element is needed to define. Could we specify a generic mechanism about chat commands for text-supported chat service in a separate spec (probably in XCON)? The frequently used chat commands could be enumerated in this spec. Cheers, Qian -----Original Message----- From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] Sent: Monday, July 16, 2007 5:59 PM To: Qian Sun Cc: 'SIMPLE mailing list' Subject: Re: [Simple] Nickname negotiation Hi Qian: Interesting topic... So, you are suggesting to generalize the semantics and method name of NICKNAME and instead having something more generic, such as CHAT-COMMAND. This will be equivalent to the "//" in commercial chat rooms. Then there should be a subcommand that demultiplex and indicates the specific action. Here we need to get the balance between be specific and generality. Also, we need to first discuss whether MSRP is the protocol that we want to use to command a chat room. The idea clashes with the work that is currently taking place in XCON, which is defining a generic protocol for manipulating conference servers. We also decided some time ago to have reduced scope in the MSRP chat draft, where we only address a couple of topic, namely nickname handling and private messaging. We deferred to XCON with generic and more sophisticated procedures. So moving into a direction of a generic MSRP method for controlling chat rooms will not allow users of SIP MESSAGE to use either. We will not be able to reuse the procedures for non-text conferences (e.g., audio, video). I think the topic is worth discussing, but we need to consider all the aspects. /Miguel Qian Sun wrote: > Hi, > There was a long discussion about nickname. Here just a suggest for nickname negotiation, could we use a litle more genenal approach instead of MSRP method "NICKNAME"? > > In many chat systems, it is very simple to set or modify nickname, just send a text-based command like "//nickname spiderman". In addition to nickname there are also many other chat commands, e.g. "emote", or change rooms in the chat lobby. > > On the other hand, some users may connect to a MSRP chatroom via SIP MESSAGE or HTTP. They can not use the MSRP method "NICKNAME". > > A possible approach might be including the chat command in the CPIM body, like this: > Content-Type: message/cpim > To: > Content-Type: text/plain > Content-Disposition: chat-command > NICKNAME "Alice in Wonderland" > > To "emote" function: > Content-Disposition: chat-emote > KISS Bob > > Opinion? > > Cheers, > Qian > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 17 07:06:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAksi-0000NS-MZ; Tue, 17 Jul 2007 07:06:16 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IAksg-0000Fc-Q4 for simple-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 07:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAksg-0000FU-GR for simple@ietf.org; Tue, 17 Jul 2007 07:06:14 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAksb-00024j-JO for simple@ietf.org; Tue, 17 Jul 2007 07:06:14 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6HB5t4r009446; Tue, 17 Jul 2007 14:06:02 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 14:06:01 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 14:06:01 +0300 Received: from [172.21.155.38] ([172.21.155.38]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 14:06:01 +0300 Message-ID: <469CA297.7020400@nsn.com> Date: Tue, 17 Jul 2007 14:05:59 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Qian Sun Subject: Re: [Simple] Nickname negotiation References: <000601c7c84a$315be6b0$7c6c460a@china.huawei.com> In-Reply-To: <000601c7c84a$315be6b0$7c6c460a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 11:06:01.0108 (UTC) FILETIME=[75BDED40:01C7C862] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: 'SIMPLE mailing list' , Niemi Aki X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Quian: There is a bit of history for the existence of the NICKNAME method. Sometime ago, when we didn't have the SDP extensions to determine whether the chat room server supported and allowed nicknames, we needed a mechanism to differentiate setting a nickname from sending a regular message. We decided to define a new method, because if the chat room server didn't support it, it would reply with an MSRP 501 response. If we had only the SEND request as you suggest, and the server didn't support nicknames, it would answer with a 200 response and the user wouldn't know what has happened. Now we could argue that this his history, and due to the SDP a=chatroom attribute, the UE discovers the server support for nicknames and private messaging and the use case would only be an error case. I agree, but I feel more comfortable separating SEND requests that carry instant messages from commands to be understood by the chat server. To make some analogy, MSRP defines also AUTH and REPORT requests, which differentiates them from SEND requests. Both AUTH and REPORT could have been adapted to be send in SEND requests, but the semantics of the SEND method would be dismissed. So I think we need to follow the MSRP model and use a different method name when the semantics are different from those of SEND: "render the message to the user". Now, the other topic, which you started in a previous e-mail. Should we generalize NICKNAME and call it CHAT-COMMAND or something else, which can be generally used for sending commands to a chat room? As I said before, this requires a careful analysis and some agreement on how much do we want to use MSRP for controlling chat rooms versus how much do we want to use the conference protocol under development in XCON. With the agreements we made in the past, we in SIMPLE are going to have the minimum mechanisms to enable chat rooms. A full fledged solution will come from XCON. You can challenge these agreements, of course. I am just giving a bit of background of how we came to this point. Do we have any other opinions in the group? /Miguel Qian Sun wrote: > Hello Miguel, > > Maybe we don't need a new method NICKNAME or CHAT-COMMAND, SEND is enough for nickname negotiation. For example: > > MSRP 6959ssdf SEND > Content-Type: message/cpim > To: > Content-Type: text/plain > Content-Disposition: chat-command > NICKNAME "Alice in Wonderland" > -------6959ssdf$ > > The above way is also suitable for SIP MESSAGE or HTTP. > > Existing chat services provide users with all kinds of chat commands, we can not standardize so many commands. A more extensible approach should be considered. > > In the above example, the chat commands are sent by using the same channel as chat text. It is also possible that the chat commands are sent by using a separate channel, e.g. control channel defining in XCON. Only a control element is needed to define. > > Could we specify a generic mechanism about chat commands for text-supported chat service in a separate spec (probably in XCON)? The frequently used chat commands could be enumerated in this spec. > > Cheers, > Qian > > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > Sent: Monday, July 16, 2007 5:59 PM > To: Qian Sun > Cc: 'SIMPLE mailing list' > Subject: Re: [Simple] Nickname negotiation > > Hi Qian: > > Interesting topic... So, you are suggesting to generalize the semantics > and method name of NICKNAME and instead having something more generic, > such as CHAT-COMMAND. This will be equivalent to the "//" in commercial > chat rooms. Then there should be a subcommand that demultiplex and > indicates the specific action. > > Here we need to get the balance between be specific and generality. > Also, we need to first discuss whether MSRP is the protocol that we want > to use to command a chat room. The idea clashes with the work that is > currently taking place in XCON, which is defining a generic protocol for > manipulating conference servers. > > We also decided some time ago to have reduced scope in the MSRP chat > draft, where we only address a couple of topic, namely nickname handling > and private messaging. We deferred to XCON with generic and more > sophisticated procedures. > > So moving into a direction of a generic MSRP method for controlling chat > rooms will not allow users of SIP MESSAGE to use either. We will not be > able to reuse the procedures for non-text conferences (e.g., audio, video). > > I think the topic is worth discussing, but we need to consider all the > aspects. > > /Miguel > > > > Qian Sun wrote: >> Hi, >> There was a long discussion about nickname. Here just a suggest for nickname negotiation, could we use a litle more genenal approach instead of MSRP method "NICKNAME"? >> >> In many chat systems, it is very simple to set or modify nickname, just send a text-based command like "//nickname spiderman". In addition to nickname there are also many other chat commands, e.g. "emote", or change rooms in the chat lobby. >> >> On the other hand, some users may connect to a MSRP chatroom via SIP MESSAGE or HTTP. They can not use the MSRP method "NICKNAME". >> >> A possible approach might be including the chat command in the CPIM body, like this: >> Content-Type: message/cpim >> To: >> Content-Type: text/plain >> Content-Disposition: chat-command >> NICKNAME "Alice in Wonderland" >> >> To "emote" function: >> Content-Disposition: chat-emote >> KISS Bob >> >> Opinion? >> >> Cheers, >> Qian >> >> >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 17 09:20:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAmyt-0006UJ-6C; Tue, 17 Jul 2007 09:20:47 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IAmyr-0006TX-MX for simple-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 09:20:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAmyr-0006TO-Az for simple@ietf.org; Tue, 17 Jul 2007 09:20:45 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAmyn-00081j-Qg for simple@ietf.org; Tue, 17 Jul 2007 09:20:45 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Jul 2007 09:20:41 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0KACpenEZAZnme/2dsb2JhbACIWpxU X-IronPort-AV: i="4.16,546,1175486400"; d="scan'208"; a="65377037:sNHT33661528" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6HDKfIV007807; Tue, 17 Jul 2007 09:20:41 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6HDKeWK001195; Tue, 17 Jul 2007 13:20:40 GMT 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.1830); Tue, 17 Jul 2007 09:20:40 -0400 Received: from [10.86.240.114] ([10.86.240.114]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 09:20:39 -0400 Message-ID: <469CC224.3020802@cisco.com> Date: Tue, 17 Jul 2007 09:20:36 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] Nickname negotiation References: <000601c7c84a$315be6b0$7c6c460a@china.huawei.com> <469CA297.7020400@nsn.com> In-Reply-To: <469CA297.7020400@nsn.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 13:20:39.0881 (UTC) FILETIME=[4510DB90:01C7C875] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6764; t=1184678441; x=1185542441; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20Nickname=20negotiation |Sender:=20 |To:=20Miguel=20Garcia=20; bh=WY72c3alrWF4FNI86AjKeSETva4XrqbN6El7zJ5AbNA=; b=kouQ+l2Fp0qLut2o7VE7zXHbr6lfNeqqQsi2LIwKcFGSrYekpf8pAmvabX/ghZn1jjh3e+oF Gwme98b7haIrFty7DMVj2ET+amx7TdovObBRgXfo09+w7zwtMFQKVXhI; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: Niemi Aki , '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: , Errors-To: simple-bounces@ietf.org I think I agree with Miguel. But maybe I don't understand Qian. Is the example Qian gave intended to be recognized and acted upon by software in the receiving node? Or is it intended to be treated as the simple text message that it appears to be, and displayed by conference participants like any other message? I don't like attaching special significance in software to "ordinary" messages. Paul Miguel Garcia wrote: > Hi Quian: > > There is a bit of history for the existence of the NICKNAME method. > Sometime ago, when we didn't have the SDP extensions to determine > whether the chat room server supported and allowed nicknames, we needed > a mechanism to differentiate setting a nickname from sending a regular > message. We decided to define a new method, because if the chat room > server didn't support it, it would reply with an MSRP 501 response. If > we had only the SEND request as you suggest, and the server didn't > support nicknames, it would answer with a 200 response and the user > wouldn't know what has happened. > > Now we could argue that this his history, and due to the SDP a=chatroom > attribute, the UE discovers the server support for nicknames and private > messaging and the use case would only be an error case. I agree, but I > feel more comfortable separating SEND requests that carry instant > messages from commands to be understood by the chat server. To make some > analogy, MSRP defines also AUTH and REPORT requests, which > differentiates them from SEND requests. Both AUTH and REPORT could have > been adapted to be send in SEND requests, but the semantics of the SEND > method would be dismissed. So I think we need to follow the MSRP model > and use a different method name when the semantics are different from > those of SEND: "render the message to the user". > > Now, the other topic, which you started in a previous e-mail. Should we > generalize NICKNAME and call it CHAT-COMMAND or something else, which > can be generally used for sending commands to a chat room? As I said > before, this requires a careful analysis and some agreement on how much > do we want to use MSRP for controlling chat rooms versus how much do we > want to use the conference protocol under development in XCON. With the > agreements we made in the past, we in SIMPLE are going to have the > minimum mechanisms to enable chat rooms. A full fledged solution will > come from XCON. You can challenge these agreements, of course. I am just > giving a bit of background of how we came to this point. > > Do we have any other opinions in the group? > > /Miguel > > > > > Qian Sun wrote: >> Hello Miguel, >> >> Maybe we don't need a new method NICKNAME or CHAT-COMMAND, SEND is >> enough for nickname negotiation. For example: >> >> MSRP 6959ssdf SEND >> Content-Type: message/cpim >> To: >> Content-Type: text/plain >> Content-Disposition: chat-command >> NICKNAME "Alice in Wonderland" >> -------6959ssdf$ >> >> The above way is also suitable for SIP MESSAGE or HTTP. >> >> Existing chat services provide users with all kinds of chat commands, >> we can not standardize so many commands. A more extensible approach >> should be considered. >> >> In the above example, the chat commands are sent by using the same >> channel as chat text. It is also possible that the chat commands are >> sent by using a separate channel, e.g. control channel defining in >> XCON. Only a control element is needed to define. >> >> Could we specify a generic mechanism about chat commands for >> text-supported chat service in a separate spec (probably in XCON)? The >> frequently used chat commands could be enumerated in this spec. >> >> Cheers, >> Qian >> >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] Sent: Monday, July >> 16, 2007 5:59 PM >> To: Qian Sun >> Cc: 'SIMPLE mailing list' >> Subject: Re: [Simple] Nickname negotiation >> >> Hi Qian: >> >> Interesting topic... So, you are suggesting to generalize the >> semantics and method name of NICKNAME and instead having something >> more generic, such as CHAT-COMMAND. This will be equivalent to the >> "//" in commercial chat rooms. Then there should be a subcommand that >> demultiplex and indicates the specific action. >> >> Here we need to get the balance between be specific and generality. >> Also, we need to first discuss whether MSRP is the protocol that we >> want to use to command a chat room. The idea clashes with the work >> that is currently taking place in XCON, which is defining a generic >> protocol for manipulating conference servers. >> >> We also decided some time ago to have reduced scope in the MSRP chat >> draft, where we only address a couple of topic, namely nickname >> handling and private messaging. We deferred to XCON with generic and >> more sophisticated procedures. >> >> So moving into a direction of a generic MSRP method for controlling >> chat rooms will not allow users of SIP MESSAGE to use either. We will >> not be able to reuse the procedures for non-text conferences (e.g., >> audio, video). >> >> I think the topic is worth discussing, but we need to consider all the >> aspects. >> >> /Miguel >> >> >> >> Qian Sun wrote: >>> Hi, >>> There was a long discussion about nickname. Here just a suggest for >>> nickname negotiation, could we use a litle more genenal approach >>> instead of MSRP method "NICKNAME"? >>> >>> In many chat systems, it is very simple to set or modify nickname, >>> just send a text-based command like "//nickname spiderman". In >>> addition to nickname there are also many other chat commands, e.g. >>> "emote", or change rooms in the chat lobby. >>> >>> On the other hand, some users may connect to a MSRP chatroom via SIP >>> MESSAGE or HTTP. They can not use the MSRP method "NICKNAME". >>> >>> A possible approach might be including the chat command in the CPIM >>> body, like this: >>> Content-Type: message/cpim >>> To: >>> Content-Type: text/plain >>> Content-Disposition: chat-command >>> NICKNAME "Alice in Wonderland" >>> >>> >>> To "emote" function: >>> Content-Disposition: chat-emote >>> KISS Bob >>> >>> Opinion? >>> >>> Cheers, >>> Qian >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Simple mailing 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 Jul 17 11:21:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAord-0008CK-FD; Tue, 17 Jul 2007 11:21:25 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IAora-0008C7-CV for simple-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 11:21:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAorZ-0008Bw-2S for simple@ietf.org; Tue, 17 Jul 2007 11:21:22 -0400 Received: from tpamail4.verizon.com ([192.76.82.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAorV-0003vt-4o for simple@ietf.org; Tue, 17 Jul 2007 11:21:20 -0400 Received: from smtptpa3.verizon.com (smtptpa3.verizon.com [138.83.71.176]) by tpamail4.verizon.com (8.13.6/8.13.3) with ESMTP id l6HFJGq8025876 for ; Tue, 17 Jul 2007 11:19:16 -0400 (EDT) Received: from ftwccout01.verizon.com (ftwccout01.verizon.com [138.83.131.134]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id l6HFLEK5026269 for ; Tue, 17 Jul 2007 11:21:14 -0400 (EDT) Received: from ftwccout01.verizon.com (unknown [127.0.0.1]) by ftwccout01.verizon.com (Symantec Mail Security) with ESMTP id 1E8C3528002 for ; Tue, 17 Jul 2007 11:21:14 -0400 (EDT) X-AuditID: 8a538386-a4ff9bb0000034c2-3c-469cde65499a Received: from smtpirv2.verizon.com (unknown [138.83.34.66]) by ftwccout01.verizon.com (EMF) with ESMTP id 14D694E4002 for ; Tue, 17 Jul 2007 11:21:09 -0400 (EDT) Received: from warsaw ([132.197.59.56]) by smtpirv2.verizon.com (8.13.3/8.13.3) with ESMTP id l6HFKDna015231 for ; Tue, 17 Jul 2007 10:20:14 -0500 (CDT) Message-Id: <200707171520.l6HFKDna015231@smtpirv2.verizon.com> From: "Piotr Boni" To: Subject: [Simple] New I-D: Membership Event Package plus updated Vehicle Info Event Package Date: Tue, 17 Jul 2007 11:26:23 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfIhtUxGpM5NkFKTjmqYjm13D0+tA== X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: ebd5ffc455fd7bcccba963126e1cf1f5 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============0079779940==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0079779940== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C7C865.4E944360" This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C7C865.4E944360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Everybody, We have submitted a new Internet-draft: Membership Event Package Authors: V. Singh, H. Schulzrinne, P. Boni The draft is available at: http://www.ietf.org/internet-drafts/draft-singh-simple-membership-00.txt Abstract This document defines a new event membership package that allows to track changes in membership in groups. Groups can represent entities contained within a physical space, such as a room or vehicle, or a logical group of entities, such as a call center team. Each member of a group can support a different set of event packages. We have also submitted an updated version of the Vehicle Info Event Package Authors: V. Singh, H. Schulzrinne, P. Boni The draft is available at: http://www.ietf.org/internet-drafts/draft-singh-simple-vehicle-info-01.txt Abstract This document defines a new SIP event package for updating and retrieving status information of vehicles. The information can include the vehicle's status and diagnostic information distributed by vehicle telematics systems. This event package is useful for fleet management and vehicle tracking applications. The event package is called vehicle-info event package and is applicable to all types of vehicles like cars, buses, ships and aircraft. However, this document focuses on automobiles. Your comments are welcome. Best piotr Piotr Boni Verizon Laboratories 40 Sylvan Road Waltham, MA 02451 phone: 781-466-2903 cell phone: 781-789-4819 e-mail: piotr.boni@verizon.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------=_NextPart_000_0029_01C7C865.4E944360 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Everybody,

 

We have submitted a new Internet-draft: Membership Event = Package

 

Authors: V. Singh, H. Schulzrinne, P. Boni

The draft is available at:

 

http://www.ietf.org/internet-drafts/draft-singh-simple-membershi= p-00.txt

 

Abstract
 
   This document defines a =
new event membership package that allows =
to
   track changes in membership in groups.  Groups can represent =
entities
   contained within a physical space, such as a room =
or vehicle, or a
   logical group of entities, such as a call center =
team.  Each =
member
   of a group can support a different set of event =
packages.

 

We have also submitted an updated version of the Vehicle Info Event = Package

Authors: V. Singh, H. Schulzrinne, P. Boni

The draft is available at:

 

http://www.ietf.org/internet-drafts/draft-singh-simple-vehicle= -info-01.txt

 

Abstract
 
   This document defines a =
new SIP event package for updating =
and
   retrieving status information of vehicles.  The information =
can
   include the vehicle's status and diagnostic =
information distributed
   by vehicle telematics =
systems.  This event =
package is useful for
   fleet management and vehicle tracking =
applications.  The =
event
   package is called vehicle-info event package and is =
applicable to all
   types of vehicles like cars, buses, ships and =
aircraft.  =
However,
   this document focuses on =
automobiles.
 

Your comments are welcome. =

 

        = ;    Best

        = ;            =     piotr

 

Piotr = Boni

Verizon Laboratories

40 Sylvan = Road

Waltham, MA 02451

phone: 781-466-2903

cell phone: 781-789-4819

e-mail: piotr.boni@verizon.com

 

____________________________= ___________________

Simple mailing list

Simple@ietf.org

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

 

 

------=_NextPart_000_0029_01C7C865.4E944360-- --===============0079779940== 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 --===============0079779940==-- From simple-bounces@ietf.org Tue Jul 17 22:20:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAz9S-0005H5-Eq; Tue, 17 Jul 2007 22:20:30 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IAz9P-0005GE-6i for simple-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 22:20:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAz9N-0005FN-AU for simple@ietf.org; Tue, 17 Jul 2007 22:20:25 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAz9K-0007Bx-L0 for simple@ietf.org; Tue, 17 Jul 2007 22:20:25 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLC007WIRSO7J@szxga03-in.huawei.com> for simple@ietf.org; Wed, 18 Jul 2007 10:19:36 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLC005EYRSM53@szxga03-in.huawei.com> for simple@ietf.org; Wed, 18 Jul 2007 10:19:36 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLC002VPRSHUQ@szxml04-in.huawei.com> for simple@ietf.org; Wed, 18 Jul 2007 10:19:34 +0800 (CST) Date: Wed, 18 Jul 2007 10:19:29 +0800 From: Qian Sun Subject: RE: [Simple] Nickname negotiation In-reply-to: <469CA297.7020400@nsn.com> To: 'Miguel Garcia' Message-id: <002f01c7c8e2$12523510$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: AcfIYnnZ42w2aTIGTzynxEpR1VKqhAAeBl5w X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, Miguel and Paul Thanks for your clarification! If we want the user know the chat room server don't support nicknames, we still have solution by using only SEND request. Fox example: MSRP 6959ssdf SEND Content-Type: text/plain Content-Disposition: chat-command-response Content-ID: Command "NICKNAME" is not supported! -------6959ssdf$ The chat server may deliver the chat command response by using a SEND message. The Content-ID in the chat command response is identical with that in the corresponding chat command. And the chat client or server can differentiates chat commands and command response from "ordinary" messages by Content-Disposition. For the users who connect to chat room via SIP MESSAGE, the above way also works: A user sends a SIP MESSAGE including chat command, the chat server return 200 OK. Then the chat server sends a SIP MESSAGE including the corresponding chat command response. Cheers, Qian -----Original Message----- From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] Sent: Tuesday, July 17, 2007 7:06 PM To: Qian Sun Cc: 'SIMPLE mailing list'; Niemi Aki Subject: Re: [Simple] Nickname negotiation Hi Quian: There is a bit of history for the existence of the NICKNAME method. Sometime ago, when we didn't have the SDP extensions to determine whether the chat room server supported and allowed nicknames, we needed a mechanism to differentiate setting a nickname from sending a regular message. We decided to define a new method, because if the chat room server didn't support it, it would reply with an MSRP 501 response. If we had only the SEND request as you suggest, and the server didn't support nicknames, it would answer with a 200 response and the user wouldn't know what has happened. Now we could argue that this his history, and due to the SDP a=chatroom attribute, the UE discovers the server support for nicknames and private messaging and the use case would only be an error case. I agree, but I feel more comfortable separating SEND requests that carry instant messages from commands to be understood by the chat server. To make some analogy, MSRP defines also AUTH and REPORT requests, which differentiates them from SEND requests. Both AUTH and REPORT could have been adapted to be send in SEND requests, but the semantics of the SEND method would be dismissed. So I think we need to follow the MSRP model and use a different method name when the semantics are different from those of SEND: "render the message to the user". Now, the other topic, which you started in a previous e-mail. Should we generalize NICKNAME and call it CHAT-COMMAND or something else, which can be generally used for sending commands to a chat room? As I said before, this requires a careful analysis and some agreement on how much do we want to use MSRP for controlling chat rooms versus how much do we want to use the conference protocol under development in XCON. With the agreements we made in the past, we in SIMPLE are going to have the minimum mechanisms to enable chat rooms. A full fledged solution will come from XCON. You can challenge these agreements, of course. I am just giving a bit of background of how we came to this point. Do we have any other opinions in the group? /Miguel Qian Sun wrote: > Hello Miguel, > > Maybe we don't need a new method NICKNAME or CHAT-COMMAND, SEND is enough for nickname negotiation. For example: > > MSRP 6959ssdf SEND > Content-Type: message/cpim > To: > Content-Type: text/plain > Content-Disposition: chat-command > Content-ID: > NICKNAME "Alice in Wonderland" > -------6959ssdf$ > > The above way is also suitable for SIP MESSAGE or HTTP. > > Existing chat services provide users with all kinds of chat commands, we can not standardize so many commands. A more extensible approach should be considered. > > In the above example, the chat commands are sent by using the same channel as chat text. It is also possible that the chat commands are sent by using a separate channel, e.g. control channel defining in XCON. Only a control element is needed to define. > > Could we specify a generic mechanism about chat commands for text-supported chat service in a separate spec (probably in XCON)? The frequently used chat commands could be enumerated in this spec. > > Cheers, > Qian > > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > Sent: Monday, July 16, 2007 5:59 PM > To: Qian Sun > Cc: 'SIMPLE mailing list' > Subject: Re: [Simple] Nickname negotiation > > Hi Qian: > > Interesting topic... So, you are suggesting to generalize the semantics > and method name of NICKNAME and instead having something more generic, > such as CHAT-COMMAND. This will be equivalent to the "//" in commercial > chat rooms. Then there should be a subcommand that demultiplex and > indicates the specific action. > > Here we need to get the balance between be specific and generality. > Also, we need to first discuss whether MSRP is the protocol that we want > to use to command a chat room. The idea clashes with the work that is > currently taking place in XCON, which is defining a generic protocol for > manipulating conference servers. > > We also decided some time ago to have reduced scope in the MSRP chat > draft, where we only address a couple of topic, namely nickname handling > and private messaging. We deferred to XCON with generic and more > sophisticated procedures. > > So moving into a direction of a generic MSRP method for controlling chat > rooms will not allow users of SIP MESSAGE to use either. We will not be > able to reuse the procedures for non-text conferences (e.g., audio, video). > > I think the topic is worth discussing, but we need to consider all the > aspects. > > /Miguel > > > > Qian Sun wrote: >> Hi, >> There was a long discussion about nickname. Here just a suggest for nickname negotiation, could we use a litle more genenal approach instead of MSRP method "NICKNAME"? >> >> In many chat systems, it is very simple to set or modify nickname, just send a text-based command like "//nickname spiderman". In addition to nickname there are also many other chat commands, e.g. "emote", or change rooms in the chat lobby. >> >> On the other hand, some users may connect to a MSRP chatroom via SIP MESSAGE or HTTP. They can not use the MSRP method "NICKNAME". >> >> A possible approach might be including the chat command in the CPIM body, like this: >> Content-Type: message/cpim >> To: >> Content-Type: text/plain >> Content-Disposition: chat-command >> NICKNAME "Alice in Wonderland" >> >> To "emote" function: >> Content-Disposition: chat-emote >> KISS Bob >> >> Opinion? >> >> Cheers, >> Qian >> >> >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 17 22:29:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAzIL-0005ml-Bk; Tue, 17 Jul 2007 22:29:41 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IAzIJ-0005mZ-Cs for simple-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 22:29:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAzIJ-0005mM-0R for simple@ietf.org; Tue, 17 Jul 2007 22:29:39 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAzIH-0007nY-Cf for simple@ietf.org; Tue, 17 Jul 2007 22:29:38 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 17 Jul 2007 22:29:37 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0KAI8XnUZAZnmf/2dsb2JhbACIWp1K X-IronPort-AV: i="4.16,548,1175486400"; d="scan'208"; a="126331423:sNHT34008968" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6I2Ta8m026833; Tue, 17 Jul 2007 22:29:36 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6I2TVWI029059; Wed, 18 Jul 2007 02:29:31 GMT 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.1830); Tue, 17 Jul 2007 22:29:31 -0400 Received: from [10.86.242.217] ([10.86.242.217]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 22:29:31 -0400 Message-ID: <469D7B0A.7030701@cisco.com> Date: Tue, 17 Jul 2007 22:29:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Qian Sun Subject: Re: [Simple] Nickname negotiation References: <002f01c7c8e2$12523510$7c6c460a@china.huawei.com> In-Reply-To: <002f01c7c8e2$12523510$7c6c460a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2007 02:29:31.0166 (UTC) FILETIME=[78B5CBE0:01C7C8E3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8033; t=1184725776; x=1185589776; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20Nickname=20negotiation |Sender:=20 |To:=20Qian=20Sun=20; bh=iD0YFh9PD8k5RwZGa0UF4belJrW0CWnJfogUHiF8iv8=; b=tDA+6onbrLviTa47LOT2a4wZSrEd1CYqmVDeERoSXHSp4Zpdyai2xJFx+Mj11Wt8MSR2n1lm NDR3u3sH7LUqRsqJPXzzV1Y8pe2MxI7ehRu9At4J4jG5/QHNtFZTIQqg; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: 'Miguel Garcia' , 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Qian, I missed the content-disposition in your original example. Now that I see it, it resolves one of my concerns about your proposal. That would still leave a couple of issues: - where is the specification of the "command-chat" content-disposition? Unless there is an agreement of what it makes sense to send with this disposition it isn't interoperable. - how do you know the peer you are sending to understands this disposition? Paul Qian Sun wrote: > Hi, Miguel and Paul > > Thanks for your clarification! > > If we want the user know the chat room server don't support nicknames, we still have solution by using only SEND request. Fox example: > MSRP 6959ssdf SEND > Content-Type: text/plain > Content-Disposition: chat-command-response > Content-ID: > Command "NICKNAME" is not supported! > -------6959ssdf$ > > The chat server may deliver the chat command response by using a SEND message. The Content-ID in the chat command response is identical with that in the corresponding chat command. > > And the chat client or server can differentiates chat commands and command response from "ordinary" messages by Content-Disposition. > > For the users who connect to chat room via SIP MESSAGE, the above way also works: > A user sends a SIP MESSAGE including chat command, the chat server return 200 OK. Then the chat server sends a SIP MESSAGE including the corresponding chat command response. > > Cheers, > Qian > > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > Sent: Tuesday, July 17, 2007 7:06 PM > To: Qian Sun > Cc: 'SIMPLE mailing list'; Niemi Aki > Subject: Re: [Simple] Nickname negotiation > > Hi Quian: > > There is a bit of history for the existence of the NICKNAME method. > Sometime ago, when we didn't have the SDP extensions to determine > whether the chat room server supported and allowed nicknames, we needed > a mechanism to differentiate setting a nickname from sending a regular > message. We decided to define a new method, because if the chat room > server didn't support it, it would reply with an MSRP 501 response. If > we had only the SEND request as you suggest, and the server didn't > support nicknames, it would answer with a 200 response and the user > wouldn't know what has happened. > > Now we could argue that this his history, and due to the SDP a=chatroom > attribute, the UE discovers the server support for nicknames and private > messaging and the use case would only be an error case. I agree, but I > feel more comfortable separating SEND requests that carry instant > messages from commands to be understood by the chat server. To make some > analogy, MSRP defines also AUTH and REPORT requests, which > differentiates them from SEND requests. Both AUTH and REPORT could have > been adapted to be send in SEND requests, but the semantics of the SEND > method would be dismissed. So I think we need to follow the MSRP model > and use a different method name when the semantics are different from > those of SEND: "render the message to the user". > > Now, the other topic, which you started in a previous e-mail. Should we > generalize NICKNAME and call it CHAT-COMMAND or something else, which > can be generally used for sending commands to a chat room? As I said > before, this requires a careful analysis and some agreement on how much > do we want to use MSRP for controlling chat rooms versus how much do we > want to use the conference protocol under development in XCON. With the > agreements we made in the past, we in SIMPLE are going to have the > minimum mechanisms to enable chat rooms. A full fledged solution will > come from XCON. You can challenge these agreements, of course. I am just > giving a bit of background of how we came to this point. > > Do we have any other opinions in the group? > > /Miguel > > > > > Qian Sun wrote: >> Hello Miguel, >> >> Maybe we don't need a new method NICKNAME or CHAT-COMMAND, SEND is enough for nickname negotiation. For example: >> >> MSRP 6959ssdf SEND >> Content-Type: message/cpim >> To: >> Content-Type: text/plain >> Content-Disposition: chat-command >> Content-ID: >> NICKNAME "Alice in Wonderland" >> -------6959ssdf$ >> >> The above way is also suitable for SIP MESSAGE or HTTP. >> >> Existing chat services provide users with all kinds of chat commands, we can not standardize so many commands. A more extensible approach should be considered. >> >> In the above example, the chat commands are sent by using the same channel as chat text. It is also possible that the chat commands are sent by using a separate channel, e.g. control channel defining in XCON. Only a control element is needed to define. >> >> Could we specify a generic mechanism about chat commands for text-supported chat service in a separate spec (probably in XCON)? The frequently used chat commands could be enumerated in this spec. >> >> Cheers, >> Qian >> >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >> Sent: Monday, July 16, 2007 5:59 PM >> To: Qian Sun >> Cc: 'SIMPLE mailing list' >> Subject: Re: [Simple] Nickname negotiation >> >> Hi Qian: >> >> Interesting topic... So, you are suggesting to generalize the semantics >> and method name of NICKNAME and instead having something more generic, >> such as CHAT-COMMAND. This will be equivalent to the "//" in commercial >> chat rooms. Then there should be a subcommand that demultiplex and >> indicates the specific action. >> >> Here we need to get the balance between be specific and generality. >> Also, we need to first discuss whether MSRP is the protocol that we want >> to use to command a chat room. The idea clashes with the work that is >> currently taking place in XCON, which is defining a generic protocol for >> manipulating conference servers. >> >> We also decided some time ago to have reduced scope in the MSRP chat >> draft, where we only address a couple of topic, namely nickname handling >> and private messaging. We deferred to XCON with generic and more >> sophisticated procedures. >> >> So moving into a direction of a generic MSRP method for controlling chat >> rooms will not allow users of SIP MESSAGE to use either. We will not be >> able to reuse the procedures for non-text conferences (e.g., audio, video). >> >> I think the topic is worth discussing, but we need to consider all the >> aspects. >> >> /Miguel >> >> >> >> Qian Sun wrote: >>> Hi, >>> There was a long discussion about nickname. Here just a suggest for nickname negotiation, could we use a litle more genenal approach instead of MSRP method "NICKNAME"? >>> >>> In many chat systems, it is very simple to set or modify nickname, just send a text-based command like "//nickname spiderman". In addition to nickname there are also many other chat commands, e.g. "emote", or change rooms in the chat lobby. >>> >>> On the other hand, some users may connect to a MSRP chatroom via SIP MESSAGE or HTTP. They can not use the MSRP method "NICKNAME". >>> >>> A possible approach might be including the chat command in the CPIM body, like this: >>> Content-Type: message/cpim >>> To: >>> Content-Type: text/plain >>> Content-Disposition: chat-command >>> NICKNAME "Alice in Wonderland" >>> >>> To "emote" function: >>> Content-Disposition: chat-emote >>> KISS Bob >>> >>> Opinion? >>> >>> Cheers, >>> Qian >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Simple mailing 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 Jul 18 02:43:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB3FW-0001DL-8J; Wed, 18 Jul 2007 02:43:02 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IB3FU-0001Cn-JV for simple-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 02:43:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB3FT-0001Cf-RV for simple@ietf.org; Wed, 18 Jul 2007 02:43:00 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB3FS-0005ES-Kz for simple@ietf.org; Wed, 18 Jul 2007 02:42:59 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6I6gDbG011932; Wed, 18 Jul 2007 09:42:29 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 09:42:20 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 09:42:20 +0300 Received: from [172.21.155.38] ([172.21.155.38]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 09:42:19 +0300 Message-ID: <469DB64B.5060608@nsn.com> Date: Wed, 18 Jul 2007 09:42:19 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Qian Sun Subject: Re: [Simple] Nickname negotiation References: <002f01c7c8e2$12523510$7c6c460a@china.huawei.com> In-Reply-To: <002f01c7c8e2$12523510$7c6c460a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2007 06:42:19.0929 (UTC) FILETIME=[C9FF5890:01C7C906] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: 'SIMPLE mailing list' , 'Niemi Aki' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi: With respect your example, I guess we should still wrap everything in message/cpim, because the chat room server will always look into the To header of the message/cpim wrapper to determine whether the message is a private message (even for the server itself) or to be distributed to the world). But even though, I don't like this multiplexing. What is the benefit? Implementing a new method is not so complicated, besides, we have already specified other 2 in MSRP. I think this is exactly what methods are for: to be specific on the semantics. I also disagree with your statements about MESSAGE. I think a chat room should have minimum support (if any) for MESSAGE. MESSAGE is the IETF solution for page mode messaging, not for session mode. MESSAGE has so many problems that I doubt any chat room will provide support for it (I may be wrong as well :-) /Miguel Qian Sun wrote: > Hi, Miguel and Paul > > Thanks for your clarification! > > If we want the user know the chat room server don't support nicknames, we still have solution by using only SEND request. Fox example: > MSRP 6959ssdf SEND > Content-Type: text/plain > Content-Disposition: chat-command-response > Content-ID: > Command "NICKNAME" is not supported! > -------6959ssdf$ > > The chat server may deliver the chat command response by using a SEND message. The Content-ID in the chat command response is identical with that in the corresponding chat command. > > And the chat client or server can differentiates chat commands and command response from "ordinary" messages by Content-Disposition. > > For the users who connect to chat room via SIP MESSAGE, the above way also works: > A user sends a SIP MESSAGE including chat command, the chat server return 200 OK. Then the chat server sends a SIP MESSAGE including the corresponding chat command response. > > Cheers, > Qian > > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] > Sent: Tuesday, July 17, 2007 7:06 PM > To: Qian Sun > Cc: 'SIMPLE mailing list'; Niemi Aki > Subject: Re: [Simple] Nickname negotiation > > Hi Quian: > > There is a bit of history for the existence of the NICKNAME method. > Sometime ago, when we didn't have the SDP extensions to determine > whether the chat room server supported and allowed nicknames, we needed > a mechanism to differentiate setting a nickname from sending a regular > message. We decided to define a new method, because if the chat room > server didn't support it, it would reply with an MSRP 501 response. If > we had only the SEND request as you suggest, and the server didn't > support nicknames, it would answer with a 200 response and the user > wouldn't know what has happened. > > Now we could argue that this his history, and due to the SDP a=chatroom > attribute, the UE discovers the server support for nicknames and private > messaging and the use case would only be an error case. I agree, but I > feel more comfortable separating SEND requests that carry instant > messages from commands to be understood by the chat server. To make some > analogy, MSRP defines also AUTH and REPORT requests, which > differentiates them from SEND requests. Both AUTH and REPORT could have > been adapted to be send in SEND requests, but the semantics of the SEND > method would be dismissed. So I think we need to follow the MSRP model > and use a different method name when the semantics are different from > those of SEND: "render the message to the user". > > Now, the other topic, which you started in a previous e-mail. Should we > generalize NICKNAME and call it CHAT-COMMAND or something else, which > can be generally used for sending commands to a chat room? As I said > before, this requires a careful analysis and some agreement on how much > do we want to use MSRP for controlling chat rooms versus how much do we > want to use the conference protocol under development in XCON. With the > agreements we made in the past, we in SIMPLE are going to have the > minimum mechanisms to enable chat rooms. A full fledged solution will > come from XCON. You can challenge these agreements, of course. I am just > giving a bit of background of how we came to this point. > > Do we have any other opinions in the group? > > /Miguel > > > > > Qian Sun wrote: >> Hello Miguel, >> >> Maybe we don't need a new method NICKNAME or CHAT-COMMAND, SEND is enough for nickname negotiation. For example: >> >> MSRP 6959ssdf SEND >> Content-Type: message/cpim >> To: >> Content-Type: text/plain >> Content-Disposition: chat-command >> Content-ID: >> NICKNAME "Alice in Wonderland" >> -------6959ssdf$ >> >> The above way is also suitable for SIP MESSAGE or HTTP. >> >> Existing chat services provide users with all kinds of chat commands, we can not standardize so many commands. A more extensible approach should be considered. >> >> In the above example, the chat commands are sent by using the same channel as chat text. It is also possible that the chat commands are sent by using a separate channel, e.g. control channel defining in XCON. Only a control element is needed to define. >> >> Could we specify a generic mechanism about chat commands for text-supported chat service in a separate spec (probably in XCON)? The frequently used chat commands could be enumerated in this spec. >> >> Cheers, >> Qian >> >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] >> Sent: Monday, July 16, 2007 5:59 PM >> To: Qian Sun >> Cc: 'SIMPLE mailing list' >> Subject: Re: [Simple] Nickname negotiation >> >> Hi Qian: >> >> Interesting topic... So, you are suggesting to generalize the semantics >> and method name of NICKNAME and instead having something more generic, >> such as CHAT-COMMAND. This will be equivalent to the "//" in commercial >> chat rooms. Then there should be a subcommand that demultiplex and >> indicates the specific action. >> >> Here we need to get the balance between be specific and generality. >> Also, we need to first discuss whether MSRP is the protocol that we want >> to use to command a chat room. The idea clashes with the work that is >> currently taking place in XCON, which is defining a generic protocol for >> manipulating conference servers. >> >> We also decided some time ago to have reduced scope in the MSRP chat >> draft, where we only address a couple of topic, namely nickname handling >> and private messaging. We deferred to XCON with generic and more >> sophisticated procedures. >> >> So moving into a direction of a generic MSRP method for controlling chat >> rooms will not allow users of SIP MESSAGE to use either. We will not be >> able to reuse the procedures for non-text conferences (e.g., audio, video). >> >> I think the topic is worth discussing, but we need to consider all the >> aspects. >> >> /Miguel >> >> >> >> Qian Sun wrote: >>> Hi, >>> There was a long discussion about nickname. Here just a suggest for nickname negotiation, could we use a litle more genenal approach instead of MSRP method "NICKNAME"? >>> >>> In many chat systems, it is very simple to set or modify nickname, just send a text-based command like "//nickname spiderman". In addition to nickname there are also many other chat commands, e.g. "emote", or change rooms in the chat lobby. >>> >>> On the other hand, some users may connect to a MSRP chatroom via SIP MESSAGE or HTTP. They can not use the MSRP method "NICKNAME". >>> >>> A possible approach might be including the chat command in the CPIM body, like this: >>> Content-Type: message/cpim >>> To: >>> Content-Type: text/plain >>> Content-Disposition: chat-command >>> NICKNAME "Alice in Wonderland" >>> >>> To "emote" function: >>> Content-Disposition: chat-emote >>> KISS Bob >>> >>> Opinion? >>> >>> Cheers, >>> Qian >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 18 10:07:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBABS-000539-Ff; Wed, 18 Jul 2007 10:07:18 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IBABQ-00051j-TQ for simple-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 10:07:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBABP-000518-VY for simple@ietf.org; Wed, 18 Jul 2007 10:07:15 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBABO-0001xJ-NE for simple@ietf.org; Wed, 18 Jul 2007 10:07:15 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6IE76HQ020519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Jul 2007 09:07:06 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <469DB64B.5060608@nsn.com> References: <002f01c7c8e2$12523510$7c6c460a@china.huawei.com> <469DB64B.5060608@nsn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <762DD7B9-E087-484D-A623-8F0C581B7D64@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Simple] Nickname negotiation Date: Wed, 18 Jul 2007 09:07:03 -0500 To: Miguel Garcia X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: -1.4 (-) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: 'Niemi Aki' , '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: , Errors-To: simple-bounces@ietf.org To reinforce what Miguel says - we've had this kind of discussion in the process of developing other protocols that are method extensible. The conclusion of those discussions has always been that the fundamental meaning of the method shouldn't be changed by the side-effect of adding new headers. We build extension points in instead. In the case of MSRP, the easiest extension point is to add a method. RjS On Jul 18, 2007, at 1:42 AM, Miguel Garcia wrote: > Hi: > > With respect your example, I guess we should still wrap everything > in message/cpim, because the chat room server will always look into > the To header of the message/cpim wrapper to determine whether the > message is a private message (even for the server itself) or to be > distributed to the world). > > But even though, I don't like this multiplexing. What is the > benefit? Implementing a new method is not so complicated, besides, > we have already specified other 2 in MSRP. I think this is exactly > what methods are for: to be specific on the semantics. > > I also disagree with your statements about MESSAGE. I think a chat > room should have minimum support (if any) for MESSAGE. MESSAGE is > the IETF solution for page mode messaging, not for session mode. > MESSAGE has so many problems that I doubt any chat room will > provide support for it (I may be wrong as well :-) > > /Miguel > > > Qian Sun wrote: >> Hi, Miguel and Paul >> Thanks for your clarification! If we want the user know the chat >> room server don't support nicknames, we still have solution by >> using only SEND request. Fox example: >> MSRP 6959ssdf SEND >> Content-Type: text/plain >> Content-Disposition: chat-command-response >> Content-ID: >> Command "NICKNAME" is not supported! >> -------6959ssdf$ >> The chat server may deliver the chat command response by using a >> SEND message. The Content-ID in the chat command response is >> identical with that in the corresponding chat command. >> And the chat client or server can differentiates chat commands and >> command response from "ordinary" messages by Content-Disposition. >> For the users who connect to chat room via SIP MESSAGE, the above >> way also works: >> A user sends a SIP MESSAGE including chat command, the chat server >> return 200 OK. Then the chat server sends a SIP MESSAGE including >> the corresponding chat command response. >> Cheers, >> Qian >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] Sent: Tuesday, >> July 17, 2007 7:06 PM >> To: Qian Sun >> Cc: 'SIMPLE mailing list'; Niemi Aki >> Subject: Re: [Simple] Nickname negotiation >> Hi Quian: >> There is a bit of history for the existence of the NICKNAME >> method. Sometime ago, when we didn't have the SDP extensions to >> determine whether the chat room server supported and allowed >> nicknames, we needed a mechanism to differentiate setting a >> nickname from sending a regular message. We decided to define a >> new method, because if the chat room server didn't support it, it >> would reply with an MSRP 501 response. If we had only the SEND >> request as you suggest, and the server didn't support nicknames, >> it would answer with a 200 response and the user wouldn't know >> what has happened. >> Now we could argue that this his history, and due to the SDP >> a=chatroom attribute, the UE discovers the server support for >> nicknames and private messaging and the use case would only be an >> error case. I agree, but I feel more comfortable separating SEND >> requests that carry instant messages from commands to be >> understood by the chat server. To make some analogy, MSRP defines >> also AUTH and REPORT requests, which differentiates them from SEND >> requests. Both AUTH and REPORT could have been adapted to be send >> in SEND requests, but the semantics of the SEND method would be >> dismissed. So I think we need to follow the MSRP model and use a >> different method name when the semantics are different from those >> of SEND: "render the message to the user". >> Now, the other topic, which you started in a previous e-mail. >> Should we generalize NICKNAME and call it CHAT-COMMAND or >> something else, which can be generally used for sending commands >> to a chat room? As I said before, this requires a careful analysis >> and some agreement on how much do we want to use MSRP for >> controlling chat rooms versus how much do we want to use the >> conference protocol under development in XCON. With the agreements >> we made in the past, we in SIMPLE are going to have the minimum >> mechanisms to enable chat rooms. A full fledged solution will come >> from XCON. You can challenge these agreements, of course. I am >> just giving a bit of background of how we came to this point. >> Do we have any other opinions in the group? >> /Miguel >> Qian Sun wrote: >>> Hello Miguel, >>> >>> Maybe we don't need a new method NICKNAME or CHAT-COMMAND, SEND >>> is enough for nickname negotiation. For example: >>> >>> MSRP 6959ssdf SEND >>> Content-Type: message/cpim >>> To: >>> Content-Type: text/plain >>> Content-Disposition: chat-command >>> Content-ID: >>> NICKNAME "Alice in Wonderland" >>> -------6959ssdf$ >>> >>> The above way is also suitable for SIP MESSAGE or HTTP. >>> >>> Existing chat services provide users with all kinds of chat >>> commands, we can not standardize so many commands. A more >>> extensible approach should be considered. >>> >>> In the above example, the chat commands are sent by using the >>> same channel as chat text. It is also possible that the chat >>> commands are sent by using a separate channel, e.g. control >>> channel defining in XCON. Only a control element >>> is needed to define. >>> >>> Could we specify a generic mechanism about chat commands for text- >>> supported chat service in a separate spec (probably in XCON)? The >>> frequently used chat commands could be enumerated in this spec. >>> >>> Cheers, >>> Qian >>> >>> -----Original Message----- >>> From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com] Sent: Monday, >>> July 16, 2007 5:59 PM >>> To: Qian Sun >>> Cc: 'SIMPLE mailing list' >>> Subject: Re: [Simple] Nickname negotiation >>> >>> Hi Qian: >>> >>> Interesting topic... So, you are suggesting to generalize the >>> semantics and method name of NICKNAME and instead having >>> something more generic, such as CHAT-COMMAND. This will be >>> equivalent to the "//" in commercial chat rooms. Then there >>> should be a subcommand that demultiplex and indicates the >>> specific action. >>> >>> Here we need to get the balance between be specific and >>> generality. Also, we need to first discuss whether MSRP is the >>> protocol that we want to use to command a chat room. The idea >>> clashes with the work that is currently taking place in XCON, >>> which is defining a generic protocol for manipulating conference >>> servers. >>> >>> We also decided some time ago to have reduced scope in the MSRP >>> chat draft, where we only address a couple of topic, namely >>> nickname handling and private messaging. We deferred to XCON with >>> generic and more sophisticated procedures. >>> >>> So moving into a direction of a generic MSRP method for >>> controlling chat rooms will not allow users of SIP MESSAGE to use >>> either. We will not be able to reuse the procedures for non-text >>> conferences (e.g., audio, video). >>> >>> I think the topic is worth discussing, but we need to consider >>> all the aspects. >>> >>> /Miguel >>> >>> >>> >>> Qian Sun wrote: >>>> Hi, >>>> There was a long discussion about nickname. Here just a suggest >>>> for nickname negotiation, could we use a litle more genenal >>>> approach instead of MSRP method "NICKNAME"? >>>> >>>> In many chat systems, it is very simple to set or modify >>>> nickname, just send a text-based command like "//nickname >>>> spiderman". In addition to nickname there are also many other >>>> chat commands, e.g. "emote", or change rooms in the chat lobby. >>>> >>>> On the other hand, some users may connect to a MSRP chatroom via >>>> SIP MESSAGE or HTTP. They can not use the MSRP method "NICKNAME". >>>> >>>> A possible approach might be including the chat command in the >>>> CPIM body, like this: >>>> Content-Type: message/cpim >>>> To: >>>> Content-Type: text/plain >>>> Content-Disposition: chat-command >>>> NICKNAME "Alice in Wonderland" >>> 40chatroom22@chat.example.com> >>>> >>>> To "emote" function: >>>> Content-Disposition: chat-emote >>>> KISS Bob >>>> >>>> Opinion? >>>> >>>> Cheers, >>>> Qian >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Siemens Networks Espoo, Finland > > > > _______________________________________________ > Simple mailing 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 Jul 19 15:22:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbZn-0003qB-MJ; Thu, 19 Jul 2007 15:22:15 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IBbZm-0003q6-KA for simple-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 15:22:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbZm-0003pq-74 for simple@ietf.org; Thu, 19 Jul 2007 15:22:14 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBbZl-0002F9-SU for simple@ietf.org; Thu, 19 Jul 2007 15:22:14 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6JJMDOD018293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 19 Jul 2007 14:22:13 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <1FCC1736-3504-408C-A9ED-55C33FDE6D39@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIMPLE mailing list From: Robert Sparks Date: Thu, 19 Jul 2007 14:22:09 -0500 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Simple] minor agenda change X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I'd like to have Jonathan talk about the SIMPLE protocol annotated overview at the beginning of the SIMPLE meeting (right after the chair status update) instead of later in the meeting. Let me know if that gives anyone heartburn. The adjusted agenda would look like this: 5m - Status/Administrivia 5m - Annotated Overview 10m - Interdomain Scaling Analysis 20m - Chat using MSRP 20m - Remaining direction RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 24 11:52:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMgo-0006wL-QC; Tue, 24 Jul 2007 11:52:46 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IDMgn-0006wC-Rw for simple-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 11:52:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMgn-0006w1-EB for simple@ietf.org; Tue, 24 Jul 2007 11:52:45 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDMgm-0005ys-PJ for simple@ietf.org; Tue, 24 Jul 2007 11:52:45 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6OFqBBd020879; Tue, 24 Jul 2007 18:52:42 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 18:52:24 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 18:52:24 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Jul 2007 18:52:20 +0300 Message-ID: In-Reply-To: <1FCC1736-3504-408C-A9ED-55C33FDE6D39@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSRP NAT traversal Thread-Index: AcfKOitTb6AfMBR2SPKNXWeF1SUk5wDxNuQw References: <1FCC1736-3504-408C-A9ED-55C33FDE6D39@nostrum.com> From: To: , X-OriginalArrivalTime: 24 Jul 2007 15:52:24.0286 (UTC) FILETIME=[A09B0FE0:01C7CE0A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [Simple] MSRP NAT traversal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, Now that MSRP has been finally approved as an RFC, it would be nice to get some actual implementations and even deployments for it. Based on what I've heard there are several client implementations under development (for instance to support file/image transfer service). The problem is that I've got a sense that the interest to support MSRP relay extension seems to be quite low. I'm not sure if there are MSRP relay implementations under development. Instead it seems that many people would rather have MSRP NAT traversal using SBCs (based on comedia) or ICE/TURN. Personally I think that the decision in MSRP not to use comedia has been a mistake. It's not possible to change that anymore in the MSRP base spec, but I think it would be valuable to define how to negotiate MSRP with comedia in an extension spec. This would allow MSRP to work in situations where one of the endpoints can receive incoming TCP connections, as well as with SBCs supporting comedia. Also the work started in http://www.ietf.org/internet-drafts/draft-niemi-simple-msrp-ice-00.txt should be brought to completion. I would be interested in hearing comments whether people think that MSRP relays are going to be sufficient for MSRP NAT traversal (and especially if there are implementation plans) or if there is interest in defining how MSRP works with comedia as an alternative mechanism. My goal would be to do whatever is best to have MSRP deployable. Regards, Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 24 17:13:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRgt-0004sk-Oo; Tue, 24 Jul 2007 17:13:11 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IDRgr-0004se-Jk for simple-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 17:13:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRgq-0004sW-Bs for simple@ietf.org; Tue, 24 Jul 2007 17:13:08 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDRgo-00038G-H5 for simple@ietf.org; Tue, 24 Jul 2007 17:13:08 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id l6OLD5FY171976 for ; Tue, 24 Jul 2007 21:13:05 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6OLD5aT1912996 for ; Tue, 24 Jul 2007 23:13:05 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6OLD2xn015377 for ; Tue, 24 Jul 2007 23:13:02 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6OLD283015317; Tue, 24 Jul 2007 23:13:02 +0200 In-Reply-To: <67043E463DDBFD4A8087ED940BFF756B01851ED9@BRU0038A.ww018.siemens.net> To: "Willekens, Marc" Subject: RE: [Simple]I-D ACTION:draft-ietf-simple-interdomain-scaling-analysis-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 From: Avshalom Houri Message-ID: Date: Wed, 25 Jul 2007 00:12:54 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 25/07/2007 00:13:02, Serialize complete at 25/07/2007 00:13:02 X-Spam-Score: -4.0 (----) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a 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="===============1110040735==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1110040735== Content-Type: multipart/alternative; boundary="=_alternative 0074896EC2257322_=" This is a multipart message in MIME format. --=_alternative 0074896EC2257322_= Content-Type: text/plain; charset="US-ASCII" Sorry for late reply and many thanks for reviewing. See comments below. Comments inline. "Willekens, Marc" wrote on 17/07/2007 02:19:45: > Hi Avshalom, > > Can you check the formulas for S03 and S08? > For No NOTIFY opt, I had values of S03/2 and S08/4 > For NOTIFY opt, S03/2 and S08/2/ > For Other protocol: OK > For NOTIFY and partial: S03/2 and S08/2 I have looked at the formulas again and they look OK. Can you provide more details? Also if you can, please look at http://www.nostrum.com/~rjsparks/SIMPLE_message_computation.xls and see if there is an error in the formula. > > Some remarks: > 1. With the "Other protocol", do you mean XMPP? XMPP is one example. Proprietry protocols that are used in consumber networks and in enterprises is another example. > 2. The figures indicate that the influence of the optimizations > become smaller when the status change traffic increases. > 3. For the very large network peering model with a frequency of > status updates of 5sec, the required bandwidth between the domains > becomes very high both for the SIMPLE and the XMPP approach: i.e. > ca. 1,24 Tbps and 1 Tbps! > > br, > Marc. > From: ext Avshalom Houri [mailto:AVSHALOM@il.ibm.com] > Sent: vrijdag 6 juli 2007 7:38 > To: simple@ietf.org > Subject: Fw: [Simple]I-D ACTION:draft-ietf-simple-interdomain- > scaling-analysis-01.txt > > The excel file I have used for the computations is in: > > http://www.nostrum.com/~rjsparks/SIMPLE_message_computation.xls > > Thanks to Robert for hosting it. > > --Avshalom > > > > > ----- Forwarded by Avshalom Houri/Haifa/IBM on 06/07/2007 08:36 ----- > > Internet-Drafts@ietf.org > 06/07/2007 03:15 > > To > > i-d-announce@ietf.org > > cc > > simple@ietf.org > > Subject > > [Simple] I-D ACTION:draft-ietf-simple-interdomain-scaling- > analysis-01.txt > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the SIP for Instant Messaging and > Presence Leveraging Extensions Working Group of the IETF. > > Title : Presence > Interdomain Scaling Analysis for SIP/SIMPLE > Author(s) : A. Houri, et al. > Filename : draft-ietf-simple- > interdomain-scaling-analysis-01.txt > Pages : 49 > Date : 2007-7-5 > > The document analyses the traffic that is generated due to presence > subscriptions between domains. It is shown that the amount of > traffic can be extremely big. In addition to the very large traffic > the document also analyses the affects of a large presence system on > the memory footprint and the CPU load. Current approved and in work > optimizations to the SIMPLE protocol are analysed with the possible > impact on the load. Separate documents contain the requirements for > optimizations and suggestions for new optimizations. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain- > scaling-analysis-01.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-interdomain-scaling-analysis-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-simple- > interdomain-scaling-analysis-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need > "munpack" or > a MIME-compliant mail reader. Different MIME- > compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which havebeen split > up into multiple messages), so check your local > documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-simple- > interdomain-scaling-analysis-01.txt > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple --=_alternative 0074896EC2257322_= Content-Type: text/html; charset="US-ASCII"
Sorry for late reply and many thanks for reviewing.
See comments below.

Comments inline.

"Willekens, Marc" <marc.willekens@nsn.com> wrote on 17/07/2007 02:19:45:

> Hi Avshalom,
>  
> Can you check the formulas for S03 and S08?
> For No NOTIFY opt, I had values of S03/2 and S08/4
> For NOTIFY opt, S03/2 and S08/2/
> For Other protocol: OK
> For NOTIFY and partial: S03/2 and S08/2
I have looked at the formulas again and they look OK.
Can you provide more details?
Also if you can, please look at
http://www.nostrum.com/~rjsparks/SIMPLE_message_computation.xls

and see if there is an error in the formula.

>  
> Some remarks:
> 1. With the "Other protocol", do you mean XMPP? XMPP is one example.

Proprietry protocols that are used in consumber networks and in enterprises is another example.

> 2. The figures indicate that the influence of the optimizations
> become smaller when the status change traffic increases.
> 3. For the very large network peering model with a frequency of
> status updates of 5sec, the required bandwidth between the domains
> becomes very high both for the SIMPLE and the XMPP approach: i.e.
> ca. 1,24 Tbps and 1 Tbps!
>  
> br,
> Marc.
> From: ext Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
> Sent: vrijdag 6 juli 2007 7:38
> To: simple@ietf.org
> Subject: Fw: [Simple]I-D ACTION:draft-ietf-simple-interdomain-
> scaling-analysis-01.txt
>
> The excel file I have used for the computations is in:
>
> http://www.nostrum.com/~rjsparks/SIMPLE_message_computation.xls
>
> Thanks to Robert for hosting it.
>
> --Avshalom
>
>
>
>
> ----- Forwarded by Avshalom Houri/Haifa/IBM on 06/07/2007 08:36 -----
>
> Internet-Drafts@ietf.org
> 06/07/2007 03:15
>
> To
>
> i-d-announce@ietf.org
>
> cc
>
> simple@ietf.org
>
> Subject
>
> [Simple] I-D        ACTION:draft-ietf-simple-interdomain-scaling-
> analysis-01.txt
>
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the SIP for Instant Messaging and
> Presence Leveraging Extensions Working Group of the IETF.
>
>                 Title                                  : Presence
> Interdomain Scaling Analysis for SIP/SIMPLE
>                 Author(s)                 : A. Houri, et al.
>                 Filename                 : draft-ietf-simple-
> interdomain-scaling-analysis-01.txt
>                 Pages                                  : 49
>                 Date                                  : 2007-7-5
>                
> The document analyses the traffic that is generated due to presence
>   subscriptions between domains.  It is shown that the amount of
>   traffic can be extremely big.  In addition to the very large traffic
>   the document also analyses the affects of a large presence system on
>   the memory footprint and the CPU load.  Current approved and in work
>   optimizations to the SIMPLE protocol are analysed with the possible
>   impact on the load.  Separate documents contain the requirements for
>   optimizations and suggestions for new optimizations.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-
> scaling-analysis-01.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-interdomain-scaling-analysis-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>                 mailserv@ietf.org.
> In the body type:
>                 "FILE /internet-drafts/draft-ietf-simple-
> interdomain-scaling-analysis-01.txt".
>                
> NOTE:                 The mail server at ietf.org can return the document in
>                 MIME-encoded form by using the "mpack" utility.  To use this
>                 feature, insert the command "ENCODING mime" before the "FILE"
>                 command.  To decode the response(s), you will need
> "munpack" or
>                 a MIME-compliant mail reader.  Different MIME-
> compliant mail readers
>                 exhibit different behavior, especially when dealing with
>                 "multipart" MIME messages (i.e. documents which havebeen split
>                 up into multiple messages), so check your local
> documentation on
>                 how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-simple-
> interdomain-scaling-analysis-01.txt
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
 --=_alternative 0074896EC2257322_=-- --===============1110040735== 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 --===============1110040735==-- From simple-bounces@ietf.org Tue Jul 24 19:33:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDTsF-0005xj-7m; Tue, 24 Jul 2007 19:33:03 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IDTsB-0005xe-Vo for simple-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 19:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDTsB-0005xW-Fl for simple@ietf.org; Tue, 24 Jul 2007 19:32:59 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDTsA-0005k6-Vi for simple@ietf.org; Tue, 24 Jul 2007 19:32:59 -0400 Received: from [130.129.84.200] ([130.129.84.200]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l6ONWmsL064252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jul 2007 18:32:53 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: References: <1FCC1736-3504-408C-A9ED-55C33FDE6D39@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <23FA74AF-C681-4C17-B4A1-9ADA96B896B8@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP NAT traversal Date: Tue, 24 Jul 2007 18:32:47 -0500 To: "" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.4 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: , Errors-To: simple-bounces@ietf.org On Jul 24, 2007, at 10:52 AM, wrote: > I would be interested in hearing comments whether people think that > MSRP > relays are going to be sufficient for MSRP NAT traversal (and > especially > if there are implementation plans) We have plans to implement relays. I think MSRP relays are sufficient for the NAT problem, but I realize that some may be motivated to use other existing technologies (i.e. SBCs, stun relay, etc.) > or if there is interest in defining > how MSRP works with comedia as an alternative mechanism. My goal would > be to do whatever is best to have MSRP deployable. I have no objection to work on specifying MSRP with COMEDIA. The only reason we took it out of the MSRP base was that at the time we worked on that part of the protocol, COMEDIA was not a sufficient solution, and we did not want to block on it. COMEDIA has evolved since then, but if we went back and adapted to every change in dependencies, we would never have finished MSRP. MSRP has explicit words indicating that the TCP connection direction could be changed by future extensions for this exact reason. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 24 19:42:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDU12-0003Uo-EH; Tue, 24 Jul 2007 19:42:08 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IDU11-0003Uj-Q3 for simple-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 19:42:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDU11-0003Ua-G3 for simple@ietf.org; Tue, 24 Jul 2007 19:42:07 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDU10-0005vW-3A for simple@ietf.org; Tue, 24 Jul 2007 19:42:07 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6ONg3Pv028671 for ; Wed, 25 Jul 2007 02:42:04 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 02:42:03 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 02:42:02 +0300 Received: from essapo-nirac253205.europe.nokia.com ([10.162.253.205]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 02:42:02 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: simple@ietf.org Subject: Re: [Simple] MSRP NAT traversal Date: Wed, 25 Jul 2007 02:42:00 +0300 User-Agent: KMail/1.9.6 References: <1FCC1736-3504-408C-A9ED-55C33FDE6D39@nostrum.com> <23FA74AF-C681-4C17-B4A1-9ADA96B896B8@estacado.net> In-Reply-To: <23FA74AF-C681-4C17-B4A1-9ADA96B896B8@estacado.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707250242.00551.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 24 Jul 2007 23:42:02.0608 (UTC) FILETIME=[3C31C700:01C7CE4C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Wednesday 25 July 2007 02:32:47 ext Ben Campbell wrote: > I have no objection to work on specifying MSRP with COMEDIA. The only > reason we took it out of the MSRP base was that at the time we worked > on that part of the protocol, COMEDIA was not a sufficient solution, > and we did not want to block on it. COMEDIA has evolved since then, > but if we went back and adapted to every change in dependencies, we > would never have finished MSRP. > > MSRP has explicit words indicating that the TCP connection direction > could be changed by future extensions for this exact reason. Unfortunately, that wording is most likely insufficient. We will most likel= y=20 stumble upon the fact that COMEDIA will want to use c=3D and m=3D as=20 authoritative, rather than the MSRP URL, if there is a COMEDIA-capable SBC.= =20 We've already seen that was a problem for MSRP+ICE in Prague. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 25 10:55:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiGb-0003IQ-G6; Wed, 25 Jul 2007 10:55:09 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IDiGa-0003IG-4c for simple-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 10:55:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiGZ-0003I8-R9 for simple@ietf.org; Wed, 25 Jul 2007 10:55:07 -0400 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDiGY-0000iB-A4 for simple@ietf.org; Wed, 25 Jul 2007 10:55:07 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l6PEt5hf562106 for ; Wed, 25 Jul 2007 14:55:05 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6PEt5TD1790200 for ; Wed, 25 Jul 2007 16:55:05 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6PEswww017248 for ; Wed, 25 Jul 2007 16:54:58 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6PEswuc017043 for ; Wed, 25 Jul 2007 16:54:58 +0200 To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 From: Avshalom Houri Message-ID: Date: Wed, 25 Jul 2007 17:54:51 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 25/07/2007 17:54:57, Serialize complete at 25/07/2007 17:54:57 X-Spam-Score: -4.0 (----) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [Simple] Bytes calculation error in the scaling-analysis draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============0276745226==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0276745226== Content-Type: multipart/alternative; boundary="=_alternative 0051ECE1C2257323_=" This is a multipart message in MIME format. --=_alternative 0051ECE1C2257323_= Content-Type: text/plain; charset="US-ASCII" 123456789012345678901234567890123456789012345678901234567890123456789012345 Marc Willekens has found a calculation error in the draft. Many thanks to Marc for finding this. The affect is that the number of bytes in steady state was doubled or quadrupled and the net effect was double the number of bytes per day/second. Numbers are still high but it is very important to make sure that the calculations are right. I hope that other people will be able to review the calculations in depth. The mistake that I have made was in the calculation of S03 and S08 number of bytes. I have multiplied that total number of message at that stage with the total number of bytes for NOTIFY, 200 OK and the presence document. The result was that we got almost double the size of the presence document which is 3000 bytes in the document. An updated draft and excel file were prepared and Robert agreed to host them (thanks): http://www.nostrum.com/~rjsparks/draft-ietf-simple-interdomain- scaling-analysis-02.txt http://www.nostrum.com/~rjsparks/SIMPLE_message_computation-02.xls --Avshalom --=_alternative 0051ECE1C2257323_= Content-Type: text/html; charset="US-ASCII"
123456789012345678901234567890123456789012345678901234567890123456789012345
Marc Willekens has found a calculation error in the draft.
Many thanks to Marc for finding this.

The affect is that the number of bytes in steady state was doubled
or quadrupled and the net effect was double the number of bytes
per day/second.

Numbers are still high but it is very important to make sure that
the calculations are right.
I hope that other people will be able to review the calculations
in depth.

The mistake that I have made was in the calculation of S03 and S08
number of bytes. I have multiplied that total number of message at that
stage with the total number of bytes for NOTIFY, 200 OK and the presence
document. The result was that we got almost double the size of the
presence document which is 3000 bytes in the document.

An updated draft and excel file were prepared and Robert agreed to host
them (thanks):

http://www.nostrum.com/~rjsparks/draft-ietf-simple-interdomain-scaling-analysis-02.txt
http://www.nostrum.com/~rjsparks/SIMPLE_message_computation-02.xls

--Avshalom



 --=_alternative 0051ECE1C2257323_=-- --===============0276745226== 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 --===============0276745226==-- From simple-bounces@ietf.org Wed Jul 25 12:11:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjSj-0001Df-R6; Wed, 25 Jul 2007 12:11:45 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IDjSj-0001Da-3L for simple-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 12:11:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjSi-0001DM-Nd for simple@ietf.org; Wed, 25 Jul 2007 12:11:44 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDjSi-0007uv-7g for simple@ietf.org; Wed, 25 Jul 2007 12:11:44 -0400 Received: from hkaplan [130.129.16.205] by acmepacket.com with ESMTP (SMTPD-9.10) id A637031C; Wed, 25 Jul 2007 12:11:35 -0400 From: "Hadriel Kaplan" To: , , References: <1FCC1736-3504-408C-A9ED-55C33FDE6D39@nostrum.com> Subject: RE: [Simple] MSRP NAT traversal Date: Wed, 25 Jul 2007 12:11:33 -0400 Message-ID: <04a301c7ced6$79b58190$6410a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfKOitTb6AfMBR2SPKNXWeF1SUk5wDxNuQwADMw/RA= In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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: , Errors-To: simple-bounces@ietf.org I think changing the SDP for MSRP to follow comedia's model is necessary but not sufficient to get it to go through SBCs, or at least some SBCs. The problem is the to-path/from-path URIs in MSRP itself. The SIP protocol headers have been virtually reproduced in the bearer plane, and along with that comes all the baggage. I was hoping we could just treat MSRP as a media-plane connection, and allow TLS to be end-end (which we do for comedia-tls), if the operator so wished - but that won't be the case as MSRP is currently defined, because of the to-path/from-path. Few operators will let us leak those URI IP addresses through, and even if they did the protocol will break when they don't match L3/sdp addresses. -hadriel > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Tuesday, July 24, 2007 11:52 AM > To: rjsparks@nostrum.com; simple@ietf.org > Subject: [Simple] MSRP NAT traversal > > Hi, > > Now that MSRP has been finally approved as an RFC, it would be nice to > get some actual implementations and even deployments for it. Based on > what I've heard there are several client implementations under > development (for instance to support file/image transfer service). The > problem is that I've got a sense that the interest to support MSRP relay > extension seems to be quite low. I'm not sure if there are MSRP relay > implementations under development. Instead it seems that many people > would rather have MSRP NAT traversal using SBCs (based on comedia) or > ICE/TURN. > > Personally I think that the decision in MSRP not to use comedia has been > a mistake. It's not possible to change that anymore in the MSRP base > spec, but I think it would be valuable to define how to negotiate MSRP > with comedia in an extension spec. This would allow MSRP to work in > situations where one of the endpoints can receive incoming TCP > connections, as well as with SBCs supporting comedia. > > Also the work started in > http://www.ietf.org/internet-drafts/draft-niemi-simple-msrp-ice-00.txt > should be brought to completion. > > I would be interested in hearing comments whether people think that MSRP > relays are going to be sufficient for MSRP NAT traversal (and especially > if there are implementation plans) or if there is interest in defining > how MSRP works with comedia as an alternative mechanism. My goal would > be to do whatever is best to have MSRP deployable. > > Regards, > Markus > > > _______________________________________________ > Simple mailing 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 Jul 25 13:59:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDl8f-0008SY-TR; Wed, 25 Jul 2007 13:59:09 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IDl8e-0008SR-QM for simple-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 13:59:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDl8e-0008SI-De for simple@ietf.org; Wed, 25 Jul 2007 13:59:08 -0400 Received: from mail-out.sbs.be ([193.109.72.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDl8d-0004P2-Nm for simple@ietf.org; Wed, 25 Jul 2007 13:59:08 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail-out.sbs.be (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l6PHx6Lf032626; Wed, 25 Jul 2007 19:59:06 +0200 Received: from bru0007a.ww018.siemens.net (bru0007a.ww018.siemens.net [193.210.175.161]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6PHx857023231; Wed, 25 Jul 2007 19:59:08 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.65]) by bru0007a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jul 2007 19:59:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jul 2007 19:58:56 +0200 Message-ID: <67043E463DDBFD4A8087ED940BFF756B018AC764@BRU0038A.ww018.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIMPLE presence scaling Thread-Index: AcfO5XhlUD0V+qtAQm608T3cD6wlAA== From: "Willekens, Marc" To: "ext Avshalom Houri" X-OriginalArrivalTime: 25 Jul 2007 17:59:06.0042 (UTC) FILETIME=[7E04B9A0:01C7CEE5] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: simple@ietf.org Subject: [Simple] SIMPLE presence scaling X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============0738198326==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0738198326== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CEE5.7DD27D75" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CEE5.7DD27D75 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Avshalom, I agree with your "red statement" in your slides. All the current proposed optimizaton techniques only delays the problem a little bit in time but do not solve the real issue, certainly when presence will be used with higher frequency ranges and with more equipment. =20 Is the main problem not related to the fact that no differentiation can be made for the same notification for all the different subscribers, e.g. maybe some watchers want to be informed immediatly, and maybe some others don't always need the latest status change. The SIMPLE and even the XMPP protocol does not support this as far as I know. So, we certainly have to look at the problem from another point of view. =20 br, Marc. ------_=_NextPart_001_01C7CEE5.7DD27D75 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Avshalom,
I agree with your = "red=20 statement" in your slides. All the current proposed optimizaton = techniques only=20 delays the problem a little bit in time but do not solve the real issue, = certainly when presence will be used with higher frequency ranges and = with more=20 equipment.
 
Is the main problem = not related=20 to the fact that no differentiation can be made for the same = notification=20 for all the different subscribers, e.g. maybe some watchers want to be = informed=20 immediatly, and maybe some others don't always need the latest status = change.=20 The SIMPLE and even the XMPP protocol does not support this as far as I = know.=20 So, we certainly have to look at the problem from another point of=20 view.
 
br,
Marc.
------_=_NextPart_001_01C7CEE5.7DD27D75-- --===============0738198326== 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 --===============0738198326==-- From simple-bounces@ietf.org Wed Jul 25 14:10:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlJv-0002of-Mm; Wed, 25 Jul 2007 14:10:47 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IDlJs-0002oa-A5 for simple-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 14:10:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlJr-0002oR-VG for simple@ietf.org; Wed, 25 Jul 2007 14:10:44 -0400 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDlJq-0004hV-Ne for simple@ietf.org; Wed, 25 Jul 2007 14:10:43 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.8/8.13.8) with ESMTP id l6PIAffl401684 for ; Wed, 25 Jul 2007 18:10:41 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6PIAfYO2076882 for ; Wed, 25 Jul 2007 20:10:41 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6PIAYoA013175 for ; Wed, 25 Jul 2007 20:10:35 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6PIAY3P013143 for ; Wed, 25 Jul 2007 20:10:34 +0200 In-Reply-To: <67043E463DDBFD4A8087ED940BFF756B018AC764@BRU0038A.ww018.siemens.net> To: "Willekens, Marc" MIME-Version: 1.0 Subject: Re: [Simple] SIMPLE presence scaling X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 From: Avshalom Houri Message-ID: Date: Wed, 25 Jul 2007 21:10:31 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 25/07/2007 21:10:34, Serialize complete at 25/07/2007 21:10:34 X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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="===============1311549494==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1311549494== Content-Type: multipart/alternative; boundary="=_alternative 0063D6B2C2257323_=" This is a multipart message in MIME format. --=_alternative 0063D6B2C2257323_= Content-Type: text/plain; charset="US-ASCII" Hi Marc, What you suggest is one way to look at the issue differently. If my memory is correct I think that Henning has suggested similar approach. We really need to move on in the requirements work and start working on suggestions as soon as possible. --Avshalom "Willekens, Marc" 25/07/2007 20:58 To Avshalom Houri/Haifa/IBM@IBMIL cc simple@ietf.org Subject [Simple] SIMPLE presence scaling Hi Avshalom, I agree with your "red statement" in your slides. All the current proposed optimizaton techniques only delays the problem a little bit in time but do not solve the real issue, certainly when presence will be used with higher frequency ranges and with more equipment. Is the main problem not related to the fact that no differentiation can be made for the same notification for all the different subscribers, e.g. maybe some watchers want to be informed immediatly, and maybe some others don't always need the latest status change. The SIMPLE and even the XMPP protocol does not support this as far as I know. So, we certainly have to look at the problem from another point of view. br, Marc._______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --=_alternative 0063D6B2C2257323_= Content-Type: text/html; charset="US-ASCII"
Hi Marc,

What you suggest is one way to look at the issue differently.
If my memory is correct I think that Henning has suggested similar approach.

We really need to move on in the requirements work and start working on suggestions as soon as possible.

--Avshalom


"Willekens, Marc" <marc.willekens@nsn.com>

25/07/2007 20:58

To
Avshalom Houri/Haifa/IBM@IBMIL
cc
simple@ietf.org
Subject
[Simple] SIMPLE presence scaling





Hi Avshalom,
I agree with your "red statement" in your slides. All the current proposed optimizaton techniques only delays the problem a little bit in time but do not solve the real issue, certainly when presence will be used with higher frequency ranges and with more equipment.
 
Is the main problem not related to the fact that no differentiation can be made for the same notification for all the different subscribers, e.g. maybe some watchers want to be informed immediatly, and maybe some others don't always need the latest status change. The SIMPLE and even the XMPP protocol does not support this as far as I know. So, we certainly have to look at the problem from another point of view.
 
br,
Marc._______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
--=_alternative 0063D6B2C2257323_=-- --===============1311549494== 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 --===============1311549494==-- From simple-bounces@ietf.org Wed Jul 25 14:31:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlds-0007To-OM; Wed, 25 Jul 2007 14:31:24 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IDldr-0007Tc-69 for simple-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 14:31:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDldq-0007TT-R1 for simple@ietf.org; Wed, 25 Jul 2007 14:31:22 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDldq-0005ju-5M for simple@ietf.org; Wed, 25 Jul 2007 14:31:22 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 25 Jul 2007 11:31:21 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwPAIYzp0arR7O6/2dsb2JhbACIYZ4/ X-IronPort-AV: i="4.16,581,1175497200"; d="scan'208"; a="188491675:sNHT45591093" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6PIVLOP026536; Wed, 25 Jul 2007 11:31:21 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l6PIUj5I019020; Wed, 25 Jul 2007 18:31:16 GMT 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.1830); Wed, 25 Jul 2007 14:30:57 -0400 Received: from [10.86.242.174] ([10.86.242.174]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 14:30:56 -0400 Message-ID: <46A796E0.5080702@cisco.com> Date: Wed, 25 Jul 2007 14:30:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Simple] MSRP NAT traversal References: <1FCC1736-3504-408C-A9ED-55C33FDE6D39@nostrum.com> <04a301c7ced6$79b58190$6410a8c0@acmepacket.com> In-Reply-To: <04a301c7ced6$79b58190$6410a8c0@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2007 18:30:57.0016 (UTC) FILETIME=[F10C3780:01C7CEE9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3064; t=1185388281; x=1186252281; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20MSRP=20NAT=20traversal |Sender:=20; bh=LkCO/7lSVzY/Xt2iY0o3sxLCEeLd0BmtC8vFpy0ZE3c=; b=KVRgMnCp+cClvt6mtIn+UssQkgmiJir4+LxtNcZgjSeZRqILsvVT97ADyO00Uwqaf/v7Yrg/ 01FQaFuwPuAHo5a/MXVSBG/FO082QqZiGqcrLo6VG3MM+ZzRCmsP0Fvw; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: simple@ietf.org, Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Since when is it the responsibility of protocol designers to design their protocols to get through SBCs, rather than visa versa? Paul Hadriel Kaplan wrote: > I think changing the SDP for MSRP to follow comedia's model is necessary but > not sufficient to get it to go through SBCs, or at least some SBCs. > > The problem is the to-path/from-path URIs in MSRP itself. The SIP protocol > headers have been virtually reproduced in the bearer plane, and along with > that comes all the baggage. I was hoping we could just treat MSRP as a > media-plane connection, and allow TLS to be end-end (which we do for > comedia-tls), if the operator so wished - but that won't be the case as MSRP > is currently defined, because of the to-path/from-path. Few operators will > let us leak those URI IP addresses through, and even if they did the > protocol will break when they don't match L3/sdp addresses. > > -hadriel > >> -----Original Message----- >> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >> Sent: Tuesday, July 24, 2007 11:52 AM >> To: rjsparks@nostrum.com; simple@ietf.org >> Subject: [Simple] MSRP NAT traversal >> >> Hi, >> >> Now that MSRP has been finally approved as an RFC, it would be nice to >> get some actual implementations and even deployments for it. Based on >> what I've heard there are several client implementations under >> development (for instance to support file/image transfer service). The >> problem is that I've got a sense that the interest to support MSRP relay >> extension seems to be quite low. I'm not sure if there are MSRP relay >> implementations under development. Instead it seems that many people >> would rather have MSRP NAT traversal using SBCs (based on comedia) or >> ICE/TURN. >> >> Personally I think that the decision in MSRP not to use comedia has been >> a mistake. It's not possible to change that anymore in the MSRP base >> spec, but I think it would be valuable to define how to negotiate MSRP >> with comedia in an extension spec. This would allow MSRP to work in >> situations where one of the endpoints can receive incoming TCP >> connections, as well as with SBCs supporting comedia. >> >> Also the work started in >> http://www.ietf.org/internet-drafts/draft-niemi-simple-msrp-ice-00.txt >> should be brought to completion. >> >> I would be interested in hearing comments whether people think that MSRP >> relays are going to be sufficient for MSRP NAT traversal (and especially >> if there are implementation plans) or if there is interest in defining >> how MSRP works with comedia as an alternative mechanism. My goal would >> be to do whatever is best to have MSRP deployable. >> >> Regards, >> Markus >> >> >> _______________________________________________ >> Simple mailing 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 Jul 25 14:36:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlid-0000ma-BS; Wed, 25 Jul 2007 14:36:19 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IDlib-0000m2-QB for simple-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 14:36:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlib-0000lp-ET for simple@ietf.org; Wed, 25 Jul 2007 14:36:17 -0400 Received: from mail-out.sbs.be ([193.109.72.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDlia-0005xw-CO for simple@ietf.org; Wed, 25 Jul 2007 14:36:17 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail-out.sbs.be (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l6PIaEAP000674; Wed, 25 Jul 2007 20:36:14 +0200 Received: from bru0007a.ww018.siemens.net (bru0007a.ww018.siemens.net [193.210.175.161]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6PIaH57025201; Wed, 25 Jul 2007 20:36:17 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.65]) by bru0007a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jul 2007 20:36:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple] SIMPLE presence scaling Date: Wed, 25 Jul 2007 20:36:02 +0200 Message-ID: <67043E463DDBFD4A8087ED940BFF756B018AC76E@BRU0038A.ww018.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] SIMPLE presence scaling Thread-Index: AcfO5zMSUrFWmho3QkuCR7Ldc0UGGwAAPvlQ From: "Willekens, Marc" To: "ext Avshalom Houri" X-OriginalArrivalTime: 25 Jul 2007 18:36:14.0448 (UTC) FILETIME=[AE407F00:01C7CEEA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd 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="===============1119001415==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1119001415== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CEEA.ADC7AE11" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CEEA.ADC7AE11 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Avshalom, Are you referring to the "Timed presence" proposal from Henning which basically plays with the "Subscription' state to enable/disable the notification based on automatic trigger points. =20 There are indeed many different end-user requirements. Mostly, all people want to be informed directly, until they have to pay in addition for that. In practice however, there is something as "directly", "as soon as possible", "as late as possible", "not after a certain moment in time", etc. Both the Presence server of the presentity and the presence server of the watcher can make use of these practices to optimize their traffic to serve the user as close as possible with their whishes. When the capacity of the servers and the networks is there, why not use this capacity to serve the end-user even better?=20 =20 Br, Marc. =20 ________________________________ From: ext Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: Wednesday, July 25, 2007 13:11 To: Willekens, Marc Cc: simple@ietf.org Subject: Re: [Simple] SIMPLE presence scaling Hi Marc,=20 What you suggest is one way to look at the issue differently.=20 If my memory is correct I think that Henning has suggested similar approach.=20 We really need to move on in the requirements work and start working on suggestions as soon as possible.=20 --Avshalom "Willekens, Marc" =20 25/07/2007 20:58=20 To Avshalom Houri/Haifa/IBM@IBMIL=20 cc simple@ietf.org=20 Subject [Simple] SIMPLE presence scaling =09 Hi Avshalom,=20 I agree with your "red statement" in your slides. All the current proposed optimizaton techniques only delays the problem a little bit in time but do not solve the real issue, certainly when presence will be used with higher frequency ranges and with more equipment.=20 =20 Is the main problem not related to the fact that no differentiation can be made for the same notification for all the different subscribers, e.g. maybe some watchers want to be informed immediatly, and maybe some others don't always need the latest status change. The SIMPLE and even the XMPP protocol does not support this as far as I know. So, we certainly have to look at the problem from another point of view.=20 =20 br,=20 Marc._______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------_=_NextPart_001_01C7CEEA.ADC7AE11 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Avshalom,
Are you referring to the "Timed presence" proposal from Henning = which=20 basically plays with the "Subscription' state to enable/disable the = notification=20 based on automatic trigger points.
 
There are indeed many different end-user requirements. = Mostly, all=20 people want to be informed directly, until they have to pay in addition = for=20 that. In practice however, there is something as "directly", "as soon as = possible", "as late as possible", "not after a certain moment in time", = etc.=20 Both the Presence server of the presentity and the presence server = of the=20 watcher can make use of these practices to optimize their traffic to = serve the=20 user as close as possible with their whishes. When the capacity of = the=20 servers and the networks is there, why not use this capacity to serve = the=20 end-user even better?
 
Br,
Marc.
 

From: ext Avshalom Houri=20 [mailto:AVSHALOM@il.ibm.com]
Sent: Wednesday, July 25, 2007=20 13:11
To: Willekens, Marc
Cc:=20 simple@ietf.org
Subject: Re: [Simple] SIMPLE presence=20 scaling


Hi Marc, =

What you suggest is one way to look at the = issue=20 differently.
If my memory is = correct I=20 think that Henning has suggested similar approach.

We really need to move on in the requirements = work and=20 start working on suggestions as soon as possible.

--Avshalom







"Willekens, = Marc"=20 <marc.willekens@nsn.com>

25/07/2007 20:58

To
Avshalom=20 Houri/Haifa/IBM@IBMIL=20
cc
simple@ietf.org=20
Subject
[Simple] SIMPLE presence=20 scaling

=




Hi=20 Avshalom,
I agree with your "red statement" in = your=20 slides. All the current proposed optimizaton techniques only delays the = problem=20 a little bit in time but do not solve the real issue, certainly when = presence=20 will be used with higher frequency ranges and with more = equipment.=20
 
Is the main problem = not related=20 to the fact that no differentiation can be made for the same = notification for=20 all the different subscribers, e.g. maybe some watchers want to be = informed=20 immediatly, and maybe some others don't always need the latest status = change.=20 The SIMPLE and even the XMPP protocol does not support this as far as I = know.=20 So, we certainly have to look at the problem from another point of = view.=20
 
br,
Marc._______________________________________________
Simple = mailing=20 list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple<= BR>
------_=_NextPart_001_01C7CEEA.ADC7AE11-- --===============1119001415== 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 --===============1119001415==-- From simple-bounces@ietf.org Wed Jul 25 14:53:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlzO-00008H-W7; Wed, 25 Jul 2007 14:53:39 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IDlzN-00007Q-5N for simple-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 14:53:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlzM-00007I-Rs for simple@ietf.org; Wed, 25 Jul 2007 14:53:36 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDlzK-0001aW-WD for simple@ietf.org; Wed, 25 Jul 2007 14:53:36 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id l6PIrYaR046196 for ; Wed, 25 Jul 2007 18:53:34 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6PIrQt12216012 for ; Wed, 25 Jul 2007 20:53:34 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6PIr9LY013360 for ; Wed, 25 Jul 2007 20:53:09 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6PIr9fn013084 for ; Wed, 25 Jul 2007 20:53:09 +0200 In-Reply-To: <67043E463DDBFD4A8087ED940BFF756B018AC76E@BRU0038A.ww018.siemens.net> To: "Willekens, Marc" MIME-Version: 1.0 Subject: RE: [Simple] SIMPLE presence scaling X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 From: Avshalom Houri Message-ID: Date: Wed, 25 Jul 2007 21:52:49 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 25/07/2007 21:53:09, Serialize complete at 25/07/2007 21:53:09 X-Spam-Score: -4.0 (----) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 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="===============1464858564==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1464858564== Content-Type: multipart/alternative; boundary="=_alternative 0067B60FC2257323_=" This is a multipart message in MIME format. --=_alternative 0067B60FC2257323_= Content-Type: text/plain; charset="US-ASCII" Hi Marc, I am referring to timed presence and also the on demand presence mentioned in 2.4 of draft-houri-simple-interdomain-scaling-optimizations-00.txt The current assumption is that if I put a user in my BL I really want to know everything about that user. It is not really true. Regards --Avshalom "Willekens, Marc" 25/07/2007 21:36 To Avshalom Houri/Haifa/IBM@IBMIL cc simple@ietf.org Subject RE: [Simple] SIMPLE presence scaling Hi Avshalom, Are you referring to the "Timed presence" proposal from Henning which basically plays with the "Subscription' state to enable/disable the notification based on automatic trigger points. There are indeed many different end-user requirements. Mostly, all people want to be informed directly, until they have to pay in addition for that. In practice however, there is something as "directly", "as soon as possible", "as late as possible", "not after a certain moment in time", etc. Both the Presence server of the presentity and the presence server of the watcher can make use of these practices to optimize their traffic to serve the user as close as possible with their whishes. When the capacity of the servers and the networks is there, why not use this capacity to serve the end-user even better? Br, Marc. From: ext Avshalom Houri [mailto:AVSHALOM@il.ibm.com] Sent: Wednesday, July 25, 2007 13:11 To: Willekens, Marc Cc: simple@ietf.org Subject: Re: [Simple] SIMPLE presence scaling Hi Marc, What you suggest is one way to look at the issue differently. If my memory is correct I think that Henning has suggested similar approach. We really need to move on in the requirements work and start working on suggestions as soon as possible. --Avshalom "Willekens, Marc" 25/07/2007 20:58 To Avshalom Houri/Haifa/IBM@IBMIL cc simple@ietf.org Subject [Simple] SIMPLE presence scaling Hi Avshalom, I agree with your "red statement" in your slides. All the current proposed optimizaton techniques only delays the problem a little bit in time but do not solve the real issue, certainly when presence will be used with higher frequency ranges and with more equipment. Is the main problem not related to the fact that no differentiation can be made for the same notification for all the different subscribers, e.g. maybe some watchers want to be informed immediatly, and maybe some others don't always need the latest status change. The SIMPLE and even the XMPP protocol does not support this as far as I know. So, we certainly have to look at the problem from another point of view. br, Marc._______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --=_alternative 0067B60FC2257323_= Content-Type: text/html; charset="US-ASCII"
Hi Marc,

I am referring to timed presence and also the on demand presence  mentioned in 2.4 of
draft-houri-simple-interdomain-scaling-optimizations-00.txt

The current assumption is that if I put a user in my BL I really want to know everything about that user. It is not really true.
Regards
--Avshalom


"Willekens, Marc" <marc.willekens@nsn.com>

25/07/2007 21:36

To
Avshalom Houri/Haifa/IBM@IBMIL
cc
simple@ietf.org
Subject
RE: [Simple] SIMPLE presence scaling





Hi Avshalom,
Are you referring to the "Timed presence" proposal from Henning which basically plays with the "Subscription' state to enable/disable the notification based on automatic trigger points.
 
There are indeed many different end-user requirements. Mostly, all people want to be informed directly, until they have to pay in addition for that. In practice however, there is something as "directly", "as soon as possible", "as late as possible", "not after a certain moment in time", etc. Both the Presence server of the presentity and the presence server of the watcher can make use of these practices to optimize their traffic to serve the user as close as possible with their whishes. When the capacity of the servers and the networks is there, why not use this capacity to serve the end-user even better?
 
Br,
Marc.
 

From: ext Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
Sent: Wednesday, July 25, 2007 13:11
To: Willekens, Marc
Cc: simple@ietf.org
Subject: Re: [Simple] SIMPLE presence scaling

Hi Marc,

What you suggest is one way to look at the issue differently.
If my memory is correct I think that Henning has suggested similar approach.

We really need to move on in the requirements work and start working on suggestions as soon as possible.

--Avshalom
"Willekens, Marc" <marc.willekens@nsn.com>

25/07/2007 20:58


To
Avshalom Houri/Haifa/IBM@IBMIL
cc
simple@ietf.org
Subject
[Simple] SIMPLE presence scaling







Hi Avshalom,
I agree with your "red statement" in your slides. All the current proposed optimizaton techniques only delays the problem a little bit in time but do not solve the real issue, certainly when presence will be used with higher frequency ranges and with more equipment.
 
Is the main problem not related to the fact that no differentiation can be made for the same notification for all the different subscribers, e.g. maybe some watchers want to be informed immediatly, and maybe some others don't always need the latest status change. The SIMPLE and even the XMPP protocol does not support this as far as I know. So, we certainly have to look at the problem from another point of view.
 
br,
Marc._______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
--=_alternative 0067B60FC2257323_=-- --===============1464858564== 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 --===============1464858564==-- From simple-bounces@ietf.org Wed Jul 25 15:23:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDmSV-0007yL-1B; Wed, 25 Jul 2007 15:23:43 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IDmST-0007yG-ML for simple-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 15:23:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDmST-0007y8-CY for simple@ietf.org; Wed, 25 Jul 2007 15:23:41 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDmSR-0002PA-Sa for simple@ietf.org; Wed, 25 Jul 2007 15:23:41 -0400 Received: from hkaplan [130.129.16.205] by acmepacket.com with ESMTP (SMTPD-9.10) id A3370380; Wed, 25 Jul 2007 15:23:35 -0400 From: "Hadriel Kaplan" To: "'Paul Kyzivat'" References: <1FCC1736-3504-408C-A9ED-55C33FDE6D39@nostrum.com> <04a301c7ced6$79b58190$6410a8c0@acmepacket.com> <46A796E0.5080702@cisco.com> Subject: RE: [Simple] MSRP NAT traversal Date: Wed, 25 Jul 2007 15:23:35 -0400 Message-ID: <05f901c7cef1$4c385970$6410a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfO6gJS45jSDH+KQZWue+sffOTscwABGTLQ In-Reply-To: <46A796E0.5080702@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: simple@ietf.org, Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org It isn't, and I didn't say it should. Markus posed a question. I tried to answer part of it. Having said that, I think history has shown designing protocols which don't consider NATs/FWs/etc. is not the best of ideas. But that's just my view. -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, July 25, 2007 2:31 PM > To: Hadriel Kaplan > Cc: Markus.Isomaki@nokia.com; rjsparks@nostrum.com; simple@ietf.org > Subject: Re: [Simple] MSRP NAT traversal > > Since when is it the responsibility of protocol designers to design > their protocols to get through SBCs, rather than visa versa? > > Paul > > Hadriel Kaplan wrote: > > I think changing the SDP for MSRP to follow comedia's model is necessary > but > > not sufficient to get it to go through SBCs, or at least some SBCs. > > > > The problem is the to-path/from-path URIs in MSRP itself. The SIP > protocol > > headers have been virtually reproduced in the bearer plane, and along > with > > that comes all the baggage. I was hoping we could just treat MSRP as a > > media-plane connection, and allow TLS to be end-end (which we do for > > comedia-tls), if the operator so wished - but that won't be the case as > MSRP > > is currently defined, because of the to-path/from-path. Few operators > will > > let us leak those URI IP addresses through, and even if they did the > > protocol will break when they don't match L3/sdp addresses. > > > > -hadriel > > > >> -----Original Message----- > >> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > >> Sent: Tuesday, July 24, 2007 11:52 AM > >> To: rjsparks@nostrum.com; simple@ietf.org > >> Subject: [Simple] MSRP NAT traversal > >> > >> Hi, > >> > >> Now that MSRP has been finally approved as an RFC, it would be nice to > >> get some actual implementations and even deployments for it. Based on > >> what I've heard there are several client implementations under > >> development (for instance to support file/image transfer service). The > >> problem is that I've got a sense that the interest to support MSRP > relay > >> extension seems to be quite low. I'm not sure if there are MSRP relay > >> implementations under development. Instead it seems that many people > >> would rather have MSRP NAT traversal using SBCs (based on comedia) or > >> ICE/TURN. > >> > >> Personally I think that the decision in MSRP not to use comedia has > been > >> a mistake. It's not possible to change that anymore in the MSRP base > >> spec, but I think it would be valuable to define how to negotiate MSRP > >> with comedia in an extension spec. This would allow MSRP to work in > >> situations where one of the endpoints can receive incoming TCP > >> connections, as well as with SBCs supporting comedia. > >> > >> Also the work started in > >> http://www.ietf.org/internet-drafts/draft-niemi-simple-msrp-ice-00.txt > >> should be brought to completion. > >> > >> I would be interested in hearing comments whether people think that > MSRP > >> relays are going to be sufficient for MSRP NAT traversal (and > especially > >> if there are implementation plans) or if there is interest in defining > >> how MSRP works with comedia as an alternative mechanism. My goal would > >> be to do whatever is best to have MSRP deployable. > >> > >> Regards, > >> Markus > >> > >> > >> _______________________________________________ > >> Simple mailing 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 Jul 25 17:09:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDo72-0002Yd-LG; Wed, 25 Jul 2007 17:09:40 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IDo71-0002YX-9I for simple-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 17:09:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDo70-0002YP-Tm for simple@ietf.org; Wed, 25 Jul 2007 17:09:38 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDo70-0001F5-4I for simple@ietf.org; Wed, 25 Jul 2007 17:09:38 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2007 17:09:38 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAI9Yp0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,581,1175486400"; d="scan'208"; a="66148999:sNHT41893612" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6PL9b2V001467 for ; Wed, 25 Jul 2007 17:09:37 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6PL9bWQ025495 for ; Wed, 25 Jul 2007 21:09:37 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 17:09:33 -0400 Received: from [10.86.242.47] ([10.86.242.47]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 17:09:33 -0400 Message-ID: <46A7BC15.5040909@cisco.com> Date: Wed, 25 Jul 2007 17:09:41 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2007 21:09:33.0112 (UTC) FILETIME=[19153B80:01C7CF00] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6208; t=1185397777; x=1186261777; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-ietf-simple-chat |Sender:=20 |To:=20Simple=20WG=20; bh=Q9YBwmtjyKx5e1z1S/ahnhRrVcRnALF9x851/W9sg4M=; b=Q0hzuYZlZiBa+swHtGQRdEUzNiqeeo5Y9vaRbK7ViA/cxIhJl3kWbxC97m04WLjCJtWJ/a3t baDIJH85xES76KqE2yFHu3K5qJ39Eh4BCdiDbXqdXKbI6IijCab65dK9; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Subject: [Simple] comments on draft-ietf-simple-chat X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The draft worries about MSRP chatrooms negotiating the capability for private and sidebar functions. Wouldn't it be easier to require all MSRP mixers to support this functionality? Then you only need to worry about conference-unaware participants. Figure 1: should clarify that this is showing only the MSRP relationship, not the SIP one. > The conference focus of a chat room MUST learn the chatroom > capabilities of each participant that joins the chat room, and MUST > inform the MSRP mixer of such support. This is to prevent that the > MSRP mixer distributes private messages to participants who do not > support private messaging. this text seems out of place here since you havent said anything about what is involved in learning such capabilities. > In particular, this specification does not provide > a general mechanism for domains issuing nicknames, other than the > domain of the conference server. I think this is good, but the conversational text above talks about domain nicknames. I think it should speak only of chatroom nicknames. > An example of a nickname is: > > sip:Alice%20in%20wonderland@example.com If a nickname is scoped to a conference, the URI has to include a conference identifier so that such URIs are unique and properly scoped. I'd suggest something like: sip:"msrp-nicknames" "/" "/" @ domain > The > validation can also fail, e.g., if the Use-Nickname header contains a > nickname URI for which the conference server has no authority and the > conference server does not have the means to validate the nickname > from the domain that issued it. This seems to say that what a user should be able to reserve is ONLY the part above, so that the only error possible is that the nickname is in use. I'd suggest that the text on nicknames clarify why this is IM specific. I think the reason is, that unlike audio or video, IM's contain sender identifiers as part of the media, and the purpose of this function is the IM-specific process of their reservation. In fact, this is not entirely true; there is a rough equivalent in RTP which is the CNAME. There is a media-specific (i.e., RTP-based) approach for declaring (if not reserving) cnames, which is via RTCP. So this is really just an analagous function. > A policy in the > MSRP mixer determines whether avoidance of collisions between > nicknames and regular Addresses of Record is enforced. Practically speaking this is impossible to do. This is why I suggest formal structure around the user part of the URI to guarantee this. > A policy in the conference > server determines whether a user who is participating in the > conference from various UAs is allowed to use the same nickname > across those UAs. This requires knowledge of this alias relationship which may be hard or impossible to know. Why is this needed? > If the sender of the message wants to remain anonymous to the rest of > the participants, and providing that the policy of the conference > allows anonymous participation, the creator SHOULD populate the From > header of the Message/CPIM body with an anonymous identity, e.g., > using the "anonymous" SIP URI as described in RFC 3261 [RFC3261] Ugh, this is a bug I'd rather not propagate.... > An MSRP switch that receives a SEND request from a participant SHOULD > first verify that the From header field of the Message/CPIM wrapper > is correctly populated with a valid URI as indicated earlier. If the > URI included in the From header field of the Message/CPIM wrapper is > not valid (e.g, because it does not "belong" to the user), then the > MSRP switch MUST generate a 403 response and MUST NOT forward the > SEND request to any of the participants. Otherwise, the MSRP switch > SHOULD generate a 200 response according to the MSRP rules for > response generation. Hmm, I wonder if, you take the model that NICKNAME is like CNAME/SSRC, then the only thing that you would be allowed send in the MSRP is the nickname, and then in that case this authentication is easy - you only need to verify that the sender had reserved that nickname. Would allow a much lighter relationship between the focus and the msrp switch. Section 7 - should break it up into sections on client and switch behavior requirements. > Then the MSRP switch should inspect the To header field of the > Message/CPIM wrapper. If the To header field of the Message/CPIM > wrapper contains the chat room URI, the MSRP switch can generate a > copy of the SEND request to each of the participants in the > conference except the sender. MUST generate a copy Suggest merging 7.1 and 7.2 since they are largely the same, differing only in construction and interpreation of To field. > Sidebars > > This document does not provide any protocol means to create, > manipulate, or send messages to sidebars. In many cases, a sidebar > is a logical subgroup of participants which exists only in each of > the recipients endpoints. Sending a message to the sidebar is > modelled as a private message addressed to each of the members of the > sidebar. As such, it is to possible to re-create the 'sidebar user > experience' totally in the endpoints by correlating collections of > private messages, thus, this document does not create any sidebar- > specific mechanism. I'd suggest that private messaging is distinct from a sidebar. The latter is an object that is really a full conference within a conference, allowing for audio and video. Private messaging is a much more lightweight, transient form of communication. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow 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 Jul 25 18:58:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDpnq-0001u0-JF; Wed, 25 Jul 2007 18:57:58 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IDpnp-0001tv-JW for simple-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 18:57:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDpnp-0001tn-6j for simple@ietf.org; Wed, 25 Jul 2007 18:57:57 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDpno-0003W2-Kl for simple@ietf.org; Wed, 25 Jul 2007 18:57:57 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP for simple@ietf.org; Thu, 26 Jul 2007 00:57:53 +0200 Received: from S4DE9JSAAIG.ost.t-com.de ([10.125.177.192]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jul 2007 00:57:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Jul 2007 00:57:52 +0200 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB7DF@S4DE9JSAAIG.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Pet names instead of nickname negotiation? Thread-Index: AcfPD3Ko5ghW0nX3SpGgUQai6gyyRQ== From: "Beck01, Wolfgang" To: X-OriginalArrivalTime: 25 Jul 2007 22:57:52.0825 (UTC) FILETIME=[3B36BA90:01C7CF0F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Simple] Pet names instead of nickname negotiation? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org In a pet name system, the client maintains a mapping between SIP-AoR and locally unique, short identifiers -- the pet names. Instead of displaying a SIP-AoR to the user, the client displays the corresponding pet name. When the user enters a pet name, the client replaces it with = the corresponding SIP-AoR. To the user, this looks much like a traditional nickname system. The owner of a SIP-AoR can give recipients a hint of her preferred pet name. If a recipient detects that the preferred pet name is already in use, it assigns a derived pet name. This can be done by simply adding a digit, so a pet name 'alice' would become 'alice1'. Alternatively, the user can be prompted to assign a locally unique pet name. The SIP-AoR, = the preferred pet name, and the selected pet name should be accessible to the recipient user. A pet name system requires little changes, just a header indicating the preferred pet name. This header isn't even necessary, as the = recipient user could be prompted for a pet name whenever a new SIP-AoR is = received.=20 Pet names could also play a role in P2PSIP environments, where globally unique names need to be selected randomly in absence of a central instance handling duplicates. Wolfgang -- T-Systems Enterprise Services GmbH=20 Supervisory Board: Ren=E9 Obermann (Chairman)=20 Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, Katrin = Horstmann, Ulrich Kemp,=20 Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger*=20 Commercial register: Amtsgericht Frankfurt am Main HRB 55933=20 Registered office: Frankfurt am Main=20 WEEE -Reg.-No. DE87523644=20 *Member of the Board of Directors as defined under section 35 GmbHG _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 25 19:08:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDpxx-0008IP-CV; Wed, 25 Jul 2007 19:08:25 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IDpxv-0008Cl-Vp for simple-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 19:08:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDpxv-0008Cd-JN for simple@ietf.org; Wed, 25 Jul 2007 19:08:23 -0400 Received: from ip2.fa1-0-2.occ.iinet.com ([198.145.33.2] helo=roundabout.local) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDpxt-0003f9-GE for simple@ietf.org; Wed, 25 Jul 2007 19:08:23 -0400 Received: from roundabout.local (localhost [127.0.0.1]) by roundabout.local (Postfix) with ESMTP id DA29362B75C; Wed, 25 Jul 2007 16:10:16 -0700 (PDT) Message-ID: <46A7D857.101@jabber.org> Date: Wed, 25 Jul 2007 16:10:15 -0700 From: Peter Saint-Andre Organization: XMPP Standards Foundation User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.5) Gecko/20070716 Thunderbird/2.0.0.5 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Beck01, Wolfgang" Subject: Re: [Simple] Pet names instead of nickname negotiation? References: <1E4CCB2441C5C0409AD8A929482A09F31BB7DF@S4DE9JSAAIG.ost.t-com.de> In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F31BB7DF@S4DE9JSAAIG.ost.t-com.de> Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 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="===============1538899530==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1538899530== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050307010001010008050000" This is a cryptographically signed message in MIME format. --------------ms050307010001010008050000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Beck01, Wolfgang wrote: > The owner of a SIP-AoR can give recipients a hint of her preferred pet > name. If a recipient detects that the preferred pet name is already > in use, it assigns a derived pet name. This can be done by simply adding > a digit, so a pet name 'alice' would become 'alice1'. Alternatively, the > user can be prompted to assign a locally unique pet name. The SIP-AoR, the > preferred pet name, and the selected pet name should be accessible to > the recipient user. The point of a petname system is that the petname is always assigned by the recipient. Enabling the sender to suggest a petname is contrary to the meaning and design of a petname system. See here: http://www.skyhunter.com/marcs/petnames/IntroPetNames.html For a use of petnames in the context of a real-time communication system, see here: http://www.xmpp.org/extensions/xep-0165.html#rec-petname Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms050307010001010008050000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGowggdSoAMCAQICAwFotjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwNzA1MTYxODMyWhcNMDgwNzA0MTYxODMyWjCBwjELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxIjAgBgNVBAoTGVhN UFAgU3RhbmRhcmRzIEZvdW5kYXRpb24xLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2Vy dGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3 DQEJARYSc3RwZXRlckBqYWJiZXIub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAoRCp9cymHb9V1L04LWCmN2wQEbHFWrmgFnAPxRVQpMsB4ifl5iYSDICmBkLINum2inq9 /+0Fz6ScCEONYC/CDOkkmLPItEDNZ0gdUd+kl+5wMPI+567ttt85ResrUAN0B/gcp+prQKxS 7uM6JcSxC0PdwrWK9pWwxPR+LveLgX9/oE9jSSy5BIQnZVgH8nhjlNMcfkTw/hVuGD/8HJFX 1MVySNt7Qy38Kc3CALmuR3ulGUkYeepGUHXj3gdITJ1CKSKCTq6hqzjTZ4m2BDAdIV4LVVlZ pH8AFs7zcl6HuQ2jLAXqBH97iSHjm5bziC9PaNmAbQkLYIPqSK46YdnSmwIDAQABo4IEeDCC BHQwDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBS08ly4gUAQeznlzuQXQlnPQN0HMTCB3QYDVR0jBIHVMIHSgBQE rNskd1NGRpZfFwFcfUJHvUgZCKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklz cmFlbDEOMAwGA1UEBxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsT EUNBIEF1dGhvcml0eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0g BIIBNzCCATMwggEvBgsrBgEEAYG1NwEBAzCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20g THRkLjADAgEBGoGNTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2Fs IExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZh aWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRd MFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4 MHYwNwYIKwYBBQUHMAGGK2h0dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3Vz ZXIvY2EwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3Mz LnVzZXIuY2EuY3J0MBEGCWCGSAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRD b20gVHJ1c3RlZCBFbWFpbCBDZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFy dGNvbS5vcmcwDQYJKoZIhvcNAQEFBQADggEBAL7ynZiQ7FHEMcQsQetYQwDHKql1d2dBtPtW YjPvU62LyZHbqFKVc2oA6rKaGBqpUKVYUyoBkfJkyAz5/YgrFufw5mnrqysjctDMKTsjdtvu NnL0pIGnvZsQhlL/sTUV/hDOBv00ypsbHXpv5YrVKpCw4Vs9rwSo/5o8f2K8dMHbNB4dv3GX JfMGQUHR/UDTiMqMOxSRAXQ6xGBwNr3zmfDys7qtgoSqy9nBy3er12WRN10jUjdJsFv11Syh 1qyRr+RH0z3Yz6gfd0tq1S9sdzDZ+hFAai3eyjKU6kNLneumEu0w1jeL9EiDRioFsEqCYTuu +c4/cvqC+T/dP89QbGowgghqMIIHUqADAgECAgMBaLYwDQYJKoZIhvcNAQEFBQAwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAzIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnMB4XDTA3MDcwNTE2MTgzMloXDTA4MDcwNDE2MTgzMlowgcIxCzAJBgNVBAYT AlVTMREwDwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQ IFN0YW5kYXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRp ZmljYXRlIE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0B CQEWEnN0cGV0ZXJAamFiYmVyLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKEQqfXMph2/VdS9OC1gpjdsEBGxxVq5oBZwD8UVUKTLAeIn5eYmEgyApgZCyDbptop6vf/t Bc+knAhDjWAvwgzpJJizyLRAzWdIHVHfpJfucDDyPueu7bbfOUXrK1ADdAf4HKfqa0CsUu7j OiXEsQtD3cK1ivaVsMT0fi73i4F/f6BPY0ksuQSEJ2VYB/J4Y5TTHH5E8P4Vbhg//ByRV9TF ckjbe0Mt/CnNwgC5rkd7pRlJGHnqRlB1494HSEydQikigk6uoas402eJtgQwHSFeC1VZWaR/ ABbO83Jeh7kNoywF6gR/e4kh45uW84gvT2jZgG0JC2CD6kiuOmHZ0psCAwEAAaOCBHgwggR0 MAwGA1UdEwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDAdBgNVHQ4EFgQUtPJcuIFAEHs55c7kF0JZz0DdBzEwgd0GA1UdIwSB1TCB0oAUBKzb JHdTRkaWXxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3Jh ZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFD QSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASC ATcwggEzMIIBLwYLKwYBBAGBtTcBAQMwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0 ZC4wAwIBARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBb MCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4Yl aHR0cDovL2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2 MDcGCCsGAQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2Vy L2NhMDsGCCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51 c2VyLmNhLmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29t IFRydXN0ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC+8p2YkOxRxDHELEHrWEMAxyqpdXdnQbT7VmIz 71Oti8mR26hSlXNqAOqymhgaqVClWFMqAZHyZMgM+f2IKxbn8OZp66srI3LQzCk7I3bb7jZy 9KSBp72bEIZS/7E1Ff4Qzgb9NMqbGx16b+WK1SqQsOFbPa8EqP+aPH9ivHTB2zQeHb9xlyXz BkFB0f1A04jKjDsUkQF0OsRgcDa985nw8rO6rYKEqsvZwct3q9dlkTddI1I3SbBb9dUsodas ka/kR9M92M+oH3dLatUvbHcw2foRQGot3soylOpDS53rphLtMNY3i/RIg0YqBbBKgmE7rvnO P3L6gvk/3T/PUGxqMYIELDCCBCgCAQEwgbcwga8xCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJ c3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBDZXJ0aWZp Y2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgRW1haWwg RnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBaLYwCQYFKw4D AhoFAKCCAkkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcw NzI1MjMxMDE1WjAjBgkqhkiG9w0BCQQxFgQUdbl7CXpwmWDOMHpYjULfM+zXe3UwUgYJKoZI hvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgcgGCSsGAQQBgjcQBDGBujCBtzCBrzELMAkGA1UE BhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UE CxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNz IDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNv bS5vcmcCAwFotjCBygYLKoZIhvcNAQkQAgsxgbqggbcwga8xCzAJBgNVBAYTAklMMQ8wDQYD VQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBD ZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkg RW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBaLYw DQYJKoZIhvcNAQEBBQAEggEAYBg3pV1TFTbz/laTeWMMzk67FMoJ0iNH7UUOLu8coSRFrOIE Cn3+TZXP77Dr0n0SuLvkiATUJ57SZV3Va5H6oGs16oCK07H4VXkITej6SKikMN/61IhlZsO/ Sp4hRsfw4RtuI6xPd2AHwyD4m4F9aorUw+6fvjwu1HVjHCN3ejCEkJXSHlu4SQY2pPH2PJsI pwYdTlgj0bgLh4ffT3O+uMaWJ8vNVteAyLLofUBl0sYp4FyDpZJd3mNc86SOf/khvwdBzQ8U UOAneujqvMrN8mwJNv+Vcn4GQJoik/RZ2DnkSzuu2R/DeuXHHAeV8M0aGdbm85pbBjFLQX9B 9OM80wAAAAAAAA== --------------ms050307010001010008050000-- --===============1538899530== 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 --===============1538899530==-- From simple-bounces@ietf.org Wed Jul 25 22:35:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDtC5-0001Eu-Mr; Wed, 25 Jul 2007 22:35:13 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IDtC4-00017B-Eh for simple-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 22:35:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDtC4-00015I-4I for simple@ietf.org; Wed, 25 Jul 2007 22:35:12 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDtC3-0001Vz-F9 for simple@ietf.org; Wed, 25 Jul 2007 22:35:12 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Thu, 26 Jul 2007 04:35:10 +0200 Received: from S4DE9JSAAIG.ost.t-com.de ([10.125.177.192]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jul 2007 04:35:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: [Simple] Pet names instead of nickname negotiation? Date: Thu, 26 Jul 2007 04:35:08 +0200 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB7E0@S4DE9JSAAIG.ost.t-com.de> In-Reply-To: <46A7D857.101@jabber.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Pet names instead of nickname negotiation? Thread-Index: AcfPFKwrEZ8RZtUkT4+cR2udzy6WawAF7DWg From: "Beck01, Wolfgang" To: X-OriginalArrivalTime: 26 Jul 2007 02:35:09.0514 (UTC) FILETIME=[95AF9AA0:01C7CF2D] X-Spam-Score: -0.7 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: , Errors-To: simple-bounces@ietf.org Peter Saint-Andre wrote: > The point of a petname system is that the petname is always=20 > assigned by the recipient. Enabling the sender to suggest a=20 > petname is contrary to the meaning and design of a petname system. >=20 Who chooses the petname is irrelevant. The point of the petname is that it is only visible to the recipient. Pet name systems resemble NAT in a way. You set up a private identifier space and map a globally unique identifier to a private identifier and vice versa. The idea of the sender giving a hint about a possible pet name is just to relieve the recipient from being prompted for some meaningful pet name every time he sees a new SIP-AoR. > See here: >=20 > http://www.skyhunter.com/marcs/petnames/IntroPetNames.html >=20 Wolfgang _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 26 16:50:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEAHd-0004JU-Ms; Thu, 26 Jul 2007 16:50:05 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IEAHc-0004JG-Cy for simple-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 16:50:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEAHc-0004J7-0D for simple@ietf.org; Thu, 26 Jul 2007 16:50:04 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEAHb-0007pj-5a for simple@ietf.org; Thu, 26 Jul 2007 16:50:03 -0400 Received: from [130.129.22.70] (dhcp-1646.ietf69.org [130.129.22.70]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6QKo2iX006732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 Jul 2007 15:50:02 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIMPLE mailing list From: Robert Sparks Date: Thu, 26 Jul 2007 15:49:58 -0500 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 130.129.22.70 is authenticated by a trusted mechanism) X-Spam-Score: 1.2 (+) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Subject: [Simple] Draft minutes: SIMPLE at IETF69 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Folks - here's a first pass at the minutes for yesterday's SIMPLE meeting. Please send comments/corrections ASAP. Thanks, RjS ------------- MINUTES - SIMPLE - IETF69 Wednesday July 25 1510-1610 Summary: * The group agreed to adopt -simple-simple as a working group item. The room felt that something closer to the hitchhiker's guide in SIP is what we want to produce rather than the earlier architecture draft attempts. * An error was identified and removed from the output numbers in the interdomain scaling analysis draft. The next revision will be ready for last call. * The room discussed pursuing nicknames in MSRP vs a non-chat specific mechanism. The conclusion of the discussion on the room was that we would continue to pursue the path currently in the draft. If a general mechanism appears before this draft is done, the group will consider shifting to use it. * All SIMPLE participants are encouraged to help finish the part of XCON needed to realize SIMPLE chatrooms, or help recruit someone who will * Brian Rosen will coordinate an effort to start work on a generalized nickname mechanism. Raw notes follow ---------------------------- Notes on SIMPLE at IETF 69 Recorded by Dean Willis Meeting chaired by Robert Sparks. Agenda accepted as presented. Status reviewed by chair. status issue: ; xcap-diff: According to JDR, a swamp. Caught up in requirements discussion and there are many open issues relating to OMA requirements, synchronization, granularity, and issues with xcap- config. Topic: SIMPLE Made Simple by Jonathan Rosenberg Slides presented. A hitch-hikers's guide to SIMPLE. Comment: This is a good start on the work item. But it needs a lot more use cases, and discourse on bringing the pieces together. It doesn't have enough context -- needs to be 35 pages or so that could be used to orient a new developer. Needs to have a network diagram showing where the components are and what protocols are used between them. Response: That would be the old architecture document that we failed to produce. JDR is not interested in attempting it. Avshalom Houri reports that he tried working on this several years ago, and it just kept getting bigger. We need a much clearer definition of the task. Poll on "who read this" revealed few had read it. Poll on "is this a good starting point" indicates a fair number of the people who read the draft thing it is a good starting point. Few people (15 people) responded, with about 2/3 thinking this draft is what we want, and about 1/3 think a lot more work is needed. Poll: Who will contribute text to a more detailed document? No takers . . . John Elwell suggested that though he thinks this is nearly done, he would like a picture or two describing how the parts fit together. JDR is willing to do a one pager. Several speakers noted we're not likely to get much better than this document. It would be nice, but it isn't likely to happen. Consensus: Adopt this document as WG, next rev to be submitted as simple-00. Topic: SIMPLE Problem Statement Led by Avshalom Houri Slides presented Changes since last version of document reviewed. A major calculation error (50%) has been corrected. This error was in the number of bytes only. Question: What is the source of the numbers? They appear to be rough assumptions. It would be very good to have real numbers here. Noted that while the numbers look large, they work out to a small number like 75 bytes per second per subscriber. Perhaps we simply have unreasonable assumptions. The traffic for 20M users will always be large. Response: The problem is in the fundamental assumptions of the architecture. For example, do we need currency of status for all presentities? Poll: Are we ready for WGLC? Consensus is yes. Chair will schedule. Topic: Chat using MSRP Led by Miguel Garcia Slides presented Major ongoing work is around nicknames. Major Issue: Nickname reservation mechanism A protocol is needed. SIP mechanisms including new methods and new headers have been proposed, as has the NICKNAME method in MSRP. Proposed by author that we us the MSRP method. Discussion: (Brian Rosen, Ben Campbell) Nicknames are useful in many scopes, and generality is desirable. However, there is a desire to expedite a solution. We could have TWO mechanisms. The general mechanism would appear to be needed in SIP. Nicknames inside MSRP are not a general solution -- won't work in mixed-media conferences, for example.. The parts of the network that know about identities (signaling) are also likely to be the parts that know about nicknames. Comments: (JDR) Draft starts on nicknames between domains. This is a big challenge and should be excised. If scope is restricted to similar to SSRC, then identifiers are scoped within the conference only and things are much easier to achieve. Comment: We really need to have SOMETHING that works well enough to use at IETF. This is very important. Comment: (Mary) There is clearly a more general problem that exceeds MSRP and SIP (it occurs also in XCON). It might be acceptable if tightly scoped to do it in MSRP, but we should probably have a second effort to do the general solution. Comment: (Paul K). Long-term reservation scopes this outside of MSRP. Restricting scope (to level of SSRC) makes the solution unsatisfactory. Comment: (Gonzalo) We should work toward a general solution, but do a minimal solution (ala MSRP) in the short term. AD Comment (Jon P): We know that the work here overlaps with other stuff in RAI, but we chartered a subset here in SIMPLE with the intent of getting something done sooner. Chair suggestion: WG to proceed down this path (MSRP) with people who think a general solution is needed to go work on it. If they get a general solution done in good order, we'll adopt it, else proceed with MSRP. No one stood up to say this is a show-stopper for them (though many people don't like it they aren't willing to stand up an alternative). Brian Rosen asked people to meet him today to work on a more general solution. Chair noted that XCON is working on abstract model that needs review and support from SIMPLE. Poll for volunteers shows general apathy . . . Further exhortation raised two or three hands. People who care are asked to come to XCON tomorrow. Meeting concluded. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 26 19:50:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IED62-0004XE-5r; Thu, 26 Jul 2007 19:50:18 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IED60-0004Ub-Iq for simple-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 19:50:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IED60-0004US-7K; Thu, 26 Jul 2007 19:50:16 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IED5z-0002so-Qf; Thu, 26 Jul 2007 19:50:16 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 88E20175FE; Thu, 26 Jul 2007 23:49:45 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IED5V-00064D-56; Thu, 26 Jul 2007 19:49:45 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 26 Jul 2007 19:49:45 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-simple-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: , 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 : SIMPLE made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence using the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-simple-simple-00.txt Pages : 14 Date : 2007-07-26 The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP). Collectively, these specifications are known as SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions. This document serves as a guide to the SIMPLE suite of specifications. It breaks them up into categories and explains what each is for and how they relate to each other. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-simple-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-simple-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-simple-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: <2007-07-26194019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-simple-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-simple-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-07-26194019.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Fri Jul 27 00:29:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEHSZ-0004LI-It; Fri, 27 Jul 2007 00:29:51 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IEHSY-0004LC-DF for simple-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 00:29:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEHSY-0004L4-3S for simple@ietf.org; Fri, 27 Jul 2007 00:29:50 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEHSW-0000Cy-Rf for simple@ietf.org; Fri, 27 Jul 2007 00:29:50 -0400 Received: by py-out-1112.google.com with SMTP id f31so2510322pyh for ; Thu, 26 Jul 2007 21:29:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=EOnpyEgOEXBG5XbVY70Gg1Tv8scZp1bJbYapKyi+drKguFPOuzk3LlnBvPwor8T2DNiQymnQQMW7YSyoxDUWwSmwSiejJsC0Vbh+foTk8IyC7etXug5P2p0GIiFHlWZHoFX+yNdEl+R/GA+PbAgh19n3CR4JzPjyueBLjTB/TIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tm5lT5QDwQ6URFpFvUTtrkLgkTWJ8YWTnrDC8RWpX7F0Bs7l00gcVJjs01EWHoL5FVjHsyhlHPisoPTkLEEP5BrlUXGISBhrkSZtULmbuDLgWCxbgBpQxJPqOyrecyGeCZYfPNVtfFbq53NK/peH14Ht/IMBnt5DdPX7b04AWHk= Received: by 10.65.196.2 with SMTP id y2mr4288326qbp.1185510588438; Thu, 26 Jul 2007 21:29:48 -0700 (PDT) Received: by 10.65.254.11 with HTTP; Thu, 26 Jul 2007 21:29:48 -0700 (PDT) Message-ID: <66cd252f0707262129t15383003rd9f0c090acf07a13@mail.gmail.com> Date: Fri, 27 Jul 2007 14:29:48 +1000 From: "Hisham Khartabil" To: "Markus.Isomaki@nokia.com" Subject: Re: [Simple] MSRP NAT traversal In-Reply-To: MIME-Version: 1.0 References: <1FCC1736-3504-408C-A9ED-55C33FDE6D39@nostrum.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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="===============2065111521==" Errors-To: simple-bounces@ietf.org --===============2065111521== Content-Type: multipart/alternative; boundary="----=_Part_510_10150505.1185510588325" ------=_Part_510_10150505.1185510588325 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think we are always in the habbit on being 10 years ahead of implementation and always trying to design an alternative solution to a solution that has not been proven broken. We spent years on designing MSRP and MSRP relay. Now that they are finally becoming RFCs, we want an alternative solution. One that will cause interoperability problem in the sense that different implementors will choose different solutions. This will cause further work in order to negotiate the NAT traversal solution between endpoints. - Why is not using comedia a mistake? - Why is it valuable? - Why isnt MSRP Relay sufficient? Config framework work is another example where people are proposing something else before the config framework has been proven broken. I don't know why you would want to standardise something that is not any better than an existing solution. Hisham On 25/07/07, Markus.Isomaki@nokia.com wrote: > > Hi, > > Now that MSRP has been finally approved as an RFC, it would be nice to > get some actual implementations and even deployments for it. Based on > what I've heard there are several client implementations under > development (for instance to support file/image transfer service). The > problem is that I've got a sense that the interest to support MSRP relay > extension seems to be quite low. I'm not sure if there are MSRP relay > implementations under development. Instead it seems that many people > would rather have MSRP NAT traversal using SBCs (based on comedia) or > ICE/TURN. > > Personally I think that the decision in MSRP not to use comedia has been > a mistake. It's not possible to change that anymore in the MSRP base > spec, but I think it would be valuable to define how to negotiate MSRP > with comedia in an extension spec. This would allow MSRP to work in > situations where one of the endpoints can receive incoming TCP > connections, as well as with SBCs supporting comedia. > > Also the work started in > http://www.ietf.org/internet-drafts/draft-niemi-simple-msrp-ice-00.txt > should be brought to completion. > > I would be interested in hearing comments whether people think that MSRP > relays are going to be sufficient for MSRP NAT traversal (and especially > if there are implementation plans) or if there is interest in defining > how MSRP works with comedia as an alternative mechanism. My goal would > be to do whatever is best to have MSRP deployable. > > Regards, > Markus > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > ------=_Part_510_10150505.1185510588325 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I think we are always in the habbit on being 10 years ahead of implementation and always trying to design an alternative solution to a solution that has not been proven broken.
 
We spent years on designing MSRP and MSRP relay. Now that they are finally becoming RFCs, we want an alternative solution. One that will cause interoperability problem in the sense that different implementors will choose different solutions. This will cause further work in order to negotiate the NAT traversal solution between endpoints.
 
- Why is not using comedia a mistake?
- Why is it valuable?
- Why isnt MSRP Relay sufficient?
 
Config framework work is another example where people are proposing something else before the config framework has been proven broken.
 
I don't know why you would want to standardise something that is not any better than an existing solution.
 
Hisham
 
On 25/07/07, Markus.Isomaki@nokia.com <Markus.Isomaki@nokia.com > wrote:
Hi,

Now that MSRP has been finally approved as an RFC, it would be nice to
get some actual implementations and even deployments for it. Based on
what I've heard there are several client implementations under
development (for instance to support file/image transfer service). The
problem is that I've got a sense that the interest to support MSRP relay
extension seems to be quite low. I'm not sure if there are MSRP relay
implementations under development. Instead it seems that many people
would rather have MSRP NAT traversal using SBCs (based on comedia) or
ICE/TURN.

Personally I think that the decision in MSRP not to use comedia has been
a mistake. It's not possible to change that anymore in the MSRP base
spec, but I think it would be valuable to define how to negotiate MSRP
with comedia in an extension spec. This would allow MSRP to work in
situations where one of the endpoints can receive incoming TCP
connections, as well as with SBCs supporting comedia.

Also the work started in
http://www.ietf.org/internet-drafts/draft-niemi-simple-msrp-ice-00.txt
should be brought to completion.

I would be interested in hearing comments whether people think that MSRP
relays are going to be sufficient for MSRP NAT traversal (and especially
if there are implementation plans) or if there is interest in defining
how MSRP works with comedia as an alternative mechanism. My goal would
be to do whatever is best to have MSRP deployable.

Regards,
       Markus


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

------=_Part_510_10150505.1185510588325-- --===============2065111521== 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 --===============2065111521==-- From JeramiahStuhldreher@citynewsstand.com Sat Jul 28 07:15:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEkGw-0004RG-73 for simple-archive@lists.ietf.org; Sat, 28 Jul 2007 07:15:46 -0400 Received: from aczs200.neoplus.adsl.tpnet.pl ([83.11.228.200]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEkGu-0008TW-GG for simple-archive@lists.ietf.org; Sat, 28 Jul 2007 07:15:46 -0400 Received: from q-c282bf7796964 ([72.196.158.70]) by citynewsstand.com.local (8.13.2/8.13.2) with SMTP id ZAxpfCjSxR5515; Sat, 28 Jul 2007 13:15:41 +0200 Message-ID: <3D72FA7F.450CBDA@citynewsstand.com> Date: Sat, 28 Jul 2007 13:15:40 +0200 From: Jeramiah User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simple-archive@lists.ietf.org Subject: Content-Type: multipart/mixed; boundary="------------080606070404000004010200" X-Antivirus: avast! (VPS 000761-2, 2007-07-27), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 4.8 (++++) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 --------------080606070404000004010200 Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 7bit --------------080606070404000004010200 Content-Type: application/octet-stream; name="investor_news-1766033284.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="investor_news-1766033284.zip" UEsDBBQAAgAIAGVz+zbfqwd/shYAAABgAAANAAAAMTYwNzkyNTE4Lnhsc+xce3AcRXrvGe2uZiVZ L9uy/G7Lsi3ZkpC0smxssCytVrbw6hFpBeaAMqPdkXZKq53NPmzrCg5xj38OQsAOkIDJhdy5Kpcj 9wByjwrxmSR1pFIicSXhKC6Q+BIgl7tLruAuRe4K2Hzd89h57y7oLiTxjHp3+uv+ft/XX3/9dc/s tK78TcPVJ7+26fvIdBxBFej9vB/5dDRGSfSoR2ifkn8/n8+r5Af2cXctTH/2HeHip1mJfWdv/trx kT7eg9QJ/VYByQPJC4n0eSUkDpIfUhWkakg1kNZAqoVUJ7sAaoDUCGktpHWQ1kNqgrQBUjOkjZA2 QdoMaQukrZC2QdoOCUPaAakF0k5IrZB2QdoNaQ+kNkjtkPYqPkZSl+762vHhjykkwZmFvgihJHyn 0RIq52gCj1GxWNKnHEvpl+XiEfLx1VTmzx+68gKDnvjXxnPw3QG0ZbkaugWkp9ECmqV6LKByj0bE MsRvVR1K4SGif3NSvvaiaZRDi3DytO2jYIU5qhOhZJEI10kXrDaQzyjjp1T55LiCVPnDICFKdRBo D5Snz0GQr+/PUmQTe/1MufZzMIp9XvTF7S9WPg/R3AeF3wcLfdXzPLXTP0O6HaVITFiUZsWEgH81 xxDVgWeIDpfBwDcyPtCOBTtfgM96iCus3Ps09pDPr9C6z9HPG6HkKnMCvXzg3xsPKnPXSfYorfcb 9LOFftbCJ4O+QXm+Ryk9EJ1epbHvQYa6yicrmSBYPgGWn4VeEH+lNRio8RzrXOMq44XoTGowDjWu sMVqPFtUj78sWoMrKqV4a+Mwjg6aWruolPO0RodNDSOGp2gNYtNiNcisVqzn1hWtcUPRGkeK9v5A 0bb0FW1LX1Ep/qIYVUUwWJjvi7XW71hjm2cLxEFYMbS0tuzs2Lmz+1T74dvb1Mzt7ds8OyD+bDGU 3zYlxO4wVmqBRcvWQqWubiMO5EmtPeCGLeZaJjSl6gFYefQidIrQ92JVspK9vU0RrBJaOlto6dFT wNoFC5d2wqrnMzKZOAZQBzpkFCbrZpRHVdOJHBgoQPTDirxHJ1TltzBbOGfQF2AmY26DJdhTuBMa fQcEfQyLsg5IO1E36oLUjQ6j29AUTFMxWt6JitUnHXdR33GggGxrHeEqXTci9J95rJujLuNr9F8O nUE6OivTq9X6z6pLhM850P/Igf6HDvQvO9Afd6B/xYH+lAP9CQf6fWXq44T/DKVvstB/14H+hAP9 Pgf6FxzoX3OgP+tAv+RA/6wD/VurpM8fU3qDg5+sV+m/1dDwaPWj1cjzCKVv0Ohzc9/e/u3tyPMN xf77ZPp/Gf22GoKpPb3Dgb7Xlr5RlfszI73ewZ/XqPS/R5PyTatcv9ZIr1bpdQU6lm+STXST3LUW +8j+31TAuVO+gZbrN1r0/JLRby80NDRVNwHOY5S+Tocv2/kRpb7f1j41Dnp6C/rwsG7R7NDsUF+L M0cVss9vpN/JskfxUVxvoSMHOnags8gBx0EudqjPYgccBzo20H2UDsuKs0a5lZTeSOgG/asc6sv4 HIIbLhs6stC9lN5swZHp9RY6R+ltDnRoV9ws96JMjxXod3Hr0F2c/n5yCs38y/LRu7lOdDdnvdde AzgViv7dyiqiFjRkrQxMuQxsuQwV5TJ4ymXwlsvgK5ehslwGrlwGf7kMVeUyVJfLUFMuw5pyGWrL ZagrxjBoYjhCHdCRwaMUkENdVVtBBlYD5OhqgAyuBsjQaoAEVwNkeDVAQqsBMrIaIMdWA+S4BkIi bR7+PgDI6GqA3LQaICdWwybh1QAZWw2Q8dUAmVgNkMkPAmKOp/vKDcAd5TJ0lsvQVS7DoXIZDhsY KkwMjNXUPQZTmxlYTinwuPZXbykg+QF3kEApIL0Bj2un97m232YS7TYEArgdsQYCUvCdn/x13ln1 NgPIBeSzB8m/4AZywAgiOGiS/9EFHchDJpD9dEGnggwMnHYAWfkdDaRSod1zzz159Ukbp6OpP6H4 dbTCQs1Ksyp1vUmpAXul3n77bYtStLJJKUIzK0VoZqX0NKtS7QalfnE3Kl2p1bOU2Qf6DT5gUUoV ll9mXHxgr9YyNUjatuzixYu/RHObB+aN2sC0nXCtrThoaAXj1Ip8fsXSiqefftrSCkIzt4LQzK3Q 06ytuM7QCuoHxlbMmBhuoLHTsRWVNuFVH3LVVlg9pcUQLZHTFOkecutLmWeFOXeQplJAVsLuIFtK aY45+JtBdpZmE68rSENpNnEH2VCaTdxBtpZmE3eQ1tJs4nMFaSzNJu4gzaXZxB1kW2k2cQfZVZpN Kl1B1pZmE3eQjaXZxB1ke2k2cQfZXZpNOFeQdaXZxB1kU2k2cQfBpdnEHWRPaTbxu4KsL80m7iCb S7OJO8iO0mziDvJr5d+anWcbYaZZA7cJ3btwJx6MRoVktuccN4bO6aAZz7b8GqjfDcMTw60VRoMo Cqf8FpN8m8KgGlTpEeb+4Y238l5yLb8+mt9FRBMxDWYxvVYxLS5iegtivMLc26+9ai+m0SwmYBWz 20VMoCDGJ8z98K3X7MWsNYvps4rZ6yKmryCmUph74+qP7cWsM4vZbxXT5SJmf0EMB33zHz+1F7Pe LKbfKqbXRUx/QYxfmHvv316xF9NExPS5e9p2ENNXgqethL+58rq9mA1mMTaettNFjN7TVsJvfuub 9mKazWJsPG2Pixi9p62EX379OXsxG81ibDxtn4sYvaethFcuf89ezCazGBtPu85FjN7TVsJff+0H 9mI2m8XYeFrARYze01bC7770rL2YLURMv7unYRDTX4Kn9QYefuZlWYzy5qcmZqtZjI2ntbqI0Xta b+CVRx+2F7PNLMbG09pcxOg9rTfwZ999zF7MdrMYG0/rcBGj97TewNNPvmAvBpvF2Hhat4sYvaf1 Bs6/+Jq9mB1mMTae1uciRu9pvYFfXH7QTkwNIq+iIc3HBk0CtuYrHf0KoYl7/9QedGcBtNcKusME qvcihC5PjtmDthZAA1bQXSZQvc8g9Pif3GoPuqsA2mcFbTeB6j0EoeXY79uD7i6A7reCdppA9f6A 0ImnvmMPuqcA2m8F7TGB6nsfoXceGbED5VAbWVEN8bFz3PVGQGZzvgINIZ7+nC4DefPyY0avck2e RSpA9aid/E4a5BPRXILPilLyHHevEZBtylcj+WVK8gp5wvCKeKUmgDwTUwWQZ1RUgA/VUgJ5KMJA ZX2OM+T8htx5tg7tJb/4BuNCdAEHhUTiHHePSa8N+SrQKw52i6IFGENBuErAqdeKPM+y2E/Vijyc 8mlayTnOkPMbcudhJbtvuSJ/jsNGVbwVICQIJpHfqScHqdux7IO6baa6vrxfVxej2yAM3KHxdC57 gGe3iceT54Anh9JwEjeJKjsoCEfXciVwdJk4KvM1Fg6jrPXoOvKsJ3Q2leCTfFZKL+GIcDZ7jjtm svP+fD0KobMoRfs+SftfohsHMIoA+FnIkydgau+TLlTcyw/yINwckyRw1MMmR92U96BjdEuG0VXJ Y3UVizx7V7BqIYbBiDgu8DExOY97LIpW1INlj4NCxPdFUHQeFJTjHnUBGDDbR++W4UinFwIhAe/V g/dawRtswHvdwPMDf3D5HxXwgB48YAVvtAEPuIHLSwOWgvfpwfssAaFirQ14n9ZjBvDzbBVENYjl o8lUDlwhZ3KFddAeslskBZ6VNQw08uOB2mnkF4YPOfzrIQ5CXAqLyQUhpoz/EyZlmiEuhWmLFuj7 wvoIUIEssUgVT56Tk7Fcgw6QsDAu5LJpPmEJzMwWCMzjAJijO5Z4BVZr748uFOKpoDkpuNQyguEY MIEhEDmubbFJFKxvXD/60UEyXsalrHCOmzW1twrGyzjdSCXQB5aaKvmVvGpp8qS6YGk5xxlyfkPu PFuNricP+iZyWdrjZ0xC1wP0BLWBtc/1IZ9ESEtwZQzBlTEEV8YQXBkayg4te8F2raZQ5oWOmIQ2 p7U5Ug5gVegwcdWImE2AtXpMXl8HqkXAO7JgbcHW2xkCcQOFkLLEA0yLtIqNFIIYXO4yj7XLfLo4 IrdWzREXa0A3kpeKbuHTSTI25fA6YLJwNUTqW+hOrKQ2PO3Cal6V+QB3Ej2gg3iQPqBuACYezdLW TgPrEr0aoyNDpNu9rgcriug0bVChBhlB8zCLkiViP7qTblP6DLTjlRvlF8em44KQ7SGUT43pKL2E 4p/QUQKPcc3oMc74pp36/XmuHpLxtb37waAMnM8zHCSE5t9k0LvoUGWd8t7Tx8nkFI3zyXkBj8n7 woaEeTGZwePCvJQV6XIlg8+I2TgOxXJRmucTmM9l41JazIpCBotJHBZ5iZp/Mi2dFpNRoQNPTgW7 qm4RYkkhE+OX8E25xBLuOdiBDx4KdGN+EYciGJbwQWkxxSeX8Di/KByqJY4WXRDSeHppcVZKHIIK I2mRsAcTUkYg+f2dw5CN8Ol5IXuozqL9uIdj0c2D48GJmZtDUx2qWHzd5NS4cCZzRkwLnSNiOpOF 1VjiOnL3kM7E+RiejvNx0DktZMQYrCExn4SIGJrA0hw22yciJISotLiYS4pRxTxBKZ3qwm0jaT65 MJdLZw/h0FhPewegJKUcWCOGsxK0ogNLSTwrxPnEHAHOxsHYEp+OkcwwaBaFBUKmA+h81iI1zmdw WsjyYhLQeBwFsblElgdVsxLJQd9kcdLSZ0RGSu4T0dRtINTSbbTdhCeZWxTSUi6DM9G4JCXwLNFT xoTu1qFCT89JaUqJCamEtLRIzAfYYjaDJ/k0yUUEPhqHXh0TMhkemqS1rW0yMnayHSsbEvlUKqGY tKuqihRhMQNtTfHprGovxRqDhap4OidmBU0JzUnxNLUnbdEZMZHAQpKfBdYU1Skjt1RWLENsmBbm YXWeBncRVPXEJKAuymhg4qggh5hMNif7SDYrJGO8araUkKbVSZ7YScplcS5DGIheGlOGZhXJezJ4 EYwigLQ0tPkgXgRNiTiluv3gIsYIQj/wwBIBFJAPaVGCD/CdJA50d9sCUR7clkqLi3wavHFRjMUS 0IG7cVycjytdDW4L8GfiYjSugyxoRkTZKQW6HEsLfBb6WUyelhKnBdUTVIsDl6D1Du3ZaELg0+BJ IvHJJdqHsxJ47RwP0oiPErvKasG4mAWD8lEYetD3mbhsWJGMil/PweCheDAsRegV6NkzUucZCBSG gQrGSMMwyZFGSTiTS6Uk8CzqzFTFTsXZicMlwS3iYgpaRX5nID+iboTolEsncWtPd0c3WFhMAkhr H83sgtXc+M2h6QgeHcehk8Hjg+PHQnhsYmg0HMJtE5EgRISTY5F2WERqGfJQVh/MIH9An8dwQzs8 DJFkLIIjE/jWiZkpPDkxFRmZCI9OAGV48NZjDBoenQ6GB0fHQlOHcISYA/6SEglgYPo56AxQcja3 hMG0GVjhYRJsM0I0RwzehQdhlINxYLBkJbgHjKT5GLCQMJjBMTETJVE3IwckMNMSPkOcLcWLZOiQ MAARgnTRzPQw7TxgyaZF6CdibDpiaf8QM3fJ2skZMppIKMsQrjMQWToTkrQgjy3wIOI4mS48Cd6R gbAi4VgOvsAj5gXi/bPCnESd8LSQyRImcCzSrKg8l3TBDJahjpfIQZug/UtSDitRCxx/QQBfHIOI CaYGBydOvKNqD8wkJyfDE9OjN4fwscHR8Wk8OBWCSSw0PBqMhIbxyMQU7bUdedQIa6wD/fKrzJ84 jNA0rG6iXBMk42/z8ovtj8Cs/IiuZOgNBj0OtMdNs/j9QLvfNHtXaRu76w0bu6vZZsNvqtcHEXr0 BELvhMn70ixdPLKwJqmj1w30nYl60PrdL771t2OzkwOnKH0vpe+jn5+klGVUUGAXWWejDuZeKHne o/5LiE/R2p+mn7uh9hw93hzYo7tu01B+MNCuux5DQx5EV5lJutw7C4uwSbppntxbZNFN9JPclJG7 4BzK2G56ZzzI9yqKVQR/suwlK5sfVklcDL7r6LZiBj5JS8IUK0tXtB/+YAz7GuRvu036w6PjMy2o jYnBCjhX0Tzhhlmtw5W3l7Do2vH/62D0rzJCZnoscpP8elAzU944oc8ShsQkGhscnxkMo6nQ9HA4 jGaSZGYkV5M8rE+mxY/DzUgoEglNyYTIUkpAwVyW3lygYSGZgWkB7tl7U4mlMSkmoGExQ1ZNaARW NiOCEKPEEfGsEJuElRysvuG+ntBRL5pIixC36USLyDw1NTgaQVNCRkrQ+QBNpMhXDzoOy9+slBTQ 8cipycHI9OjHQqcGZyITJdrsSdQCdovRuxoyZjqYDiZAj78bUL8ZdIHbDckZ5YaAejUDGBy6m0Zz BrX6j8hvoNEIyqJzFUfouCT5CjgXqwt5D8Rnff1qOFt15eRs9RTyMMEzan3E1mrRm6V7XDi2Xrk+ LLsFU4cJjaG0H3vodg+mjtZjKe0Kq6dVUNozjJ7mobS4gealtIcNNJ8NrdKGxtnQ/Da0KkpbY9Cv mtL+yUCrobQOtb2UtsaGVmtDq7Oh1dvQGmxojTa0tTa0dTa09Ta0JhvaBhtasw1tow1tE6WdNNhq M6V9ntXX22LDu9WGts2Gtt1Eu4RkXxtAR5XTh96DniRPXEbpDCXX4LTyQei/S0j2xiEUVE6ZiwWO 43Tul2twWvkw5dpC/bXAddxQzrA+6rtDFMsDdYPyPy2jdA/kZDr5QcBLZayDnM8Wx6vheCkOq+B4 NRwvxfErOF4HHJ+G46M4FQqOj+J8giV0L31L58rAJbqV1B6nUsOppDhVCk6lhlNJcZjlwaOX6NZT exxOw+EojkfB4TQcTsZB4xSHc8Dxazh+ilOt4Pg1HL+Mc/RjFMfvgFNFcS5BropyFnyhivpCreIL VSZfILzVmg7VoAN9BAZ1myFHnsYaT5WnRuMhkfkEfZGS8JC4HDadqs+toTxhx/LaIuV1Rcrri5Q3 FClvLFK+tkj5uiLl64uUNxUp31CkvLlI+cYi5Ztcy+UYaI40m8G7bqKzt1zDGmm2GLiClvKtRcq3 FSnf7lL+Mnx+F4JngiV7DPph1XZcd96A+uDELme/8k0iNraJ4jtsaC02tJ02tFbTaoOMKqyNKgyj aoKuTMiowjCqJk2n2v4dlGfSsbylSPnOIuVEzxAasZzHqH1rYa1M7ipVOx5hG9HXfermWHUb5n1w F32facPqVhjPFR76jjVDp5XGxjfABSsAlnxW05N8k3+IQ77nuQ2Q9LvW6b9sqxh2u1OvN6w7Hx7/ KN+hP0l3N8j30QydgZm8eW19rOy1tbrW1W2gJn2E9H2EbPuIlfvIeLO0Cr2wefJ/ey+gj3gvXDv+ Bx4lsMrOS/I/VfX//5Xk/cr3teP/5vF+HtFbFDu/uPqZz73984l4/Zce4tC+Pc+8Qrbe/p722FEe /h7lvwSQIX1S2XkUV/5fx7LybzjuV3bf/Lbia6975H1BhEf+Dc8+T4LvmBhNSxlpjv6yKSTkkPPT rW++9VcvMPT66Yv0f8pWfED/d2s/+9KLL13o2lx//lFof8fPv0za/xeKnozS7g3K7vdqpf1E5zuV 9saVB/opxQ5nFbs8qbODrHcN5Vcf79p9b6tH2h4n+Wf/wmVv4TKAaupl8G0K8y1SeiFDijLaDmtj O+X33VKwaJtF/70sksMP1PUg9fxZUPgVUbEMI9V+aoOhbD8jMAcwc0HMQD+7WQ0l//mnpWUmp0Ky oYKRgYGxAjxpgWsMp8y0NAtwdx2sRA+cHvUsGL5YbiocrWcHKwAAUEsBAhQAFAACAAgAZXP7Nt+r B3+yFgAAAGAAAA0AAAAAAAAAAAAgAAAAAAAAADE2MDc5MjUxOC54bHNQSwUGAAAAAAEAAQA7AAAA 3RYAAAAA --------------080606070404000004010200-- From simple-bounces@ietf.org Mon Jul 30 05:37:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFRgW-0001nu-1i; Mon, 30 Jul 2007 05:37:04 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFRgU-0001no-Vg for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 05:37:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFRgU-0001ng-M0 for simple@ietf.org; Mon, 30 Jul 2007 05:37:02 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFRgT-0006sh-Vd for simple@ietf.org; Mon, 30 Jul 2007 05:37:02 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6U9atVZ031686; Mon, 30 Jul 2007 12:36:58 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 12:36:40 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 12:36:38 +0300 Received: from esdhcp05136.research.nokia.com ([172.21.51.36]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 12:36:37 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: simple@ietf.org Subject: Re: [Simple] MSRP NAT traversal Date: Mon, 30 Jul 2007 12:36:42 +0300 User-Agent: KMail/1.9.6 References: <1FCC1736-3504-408C-A9ED-55C33FDE6D39@nostrum.com> <66cd252f0707262129t15383003rd9f0c090acf07a13@mail.gmail.com> In-Reply-To: <66cd252f0707262129t15383003rd9f0c090acf07a13@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707301236.42438.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 30 Jul 2007 09:36:37.0869 (UTC) FILETIME=[205F59D0:01C7D28D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "Markus.Isomaki@nokia.com" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Friday 27 July 2007 07:29:48 ext Hisham Khartabil wrote: > I think we are always in the habbit on being 10 years ahead of > implementation and always trying to design an alternative solution to a > solution that has not been proven broken. > > We spent years on designing MSRP and MSRP relay. Now that they are finally > becoming RFCs, we want an alternative solution. One that will cause > interoperability problem in the sense that different implementors will > choose different solutions. This will cause further work in order to > negotiate the NAT traversal solution between endpoints. > > - Why is not using comedia a mistake? > - Why is it valuable? > - Why isnt MSRP Relay sufficient? Hmm, I cannot honestly say that I am satisfied with the answers that were=20 given in this thread: http://www1.ietf.org/mail-archive/web/simple/current/msg05676.html and in particular, that one is very worrying: http://www1.ietf.org/mail-archive/web/simple/current/msg05706.html I still consider the current design of MSRP relays to be fatally broken, as= in=20 easily abusable by malign third parties. It's currently basically like TCP= =20 without window and ACKs... which of course does not work. On the contrary, using COMEDIA and/or ICE ensures end-to-end congestion and= =20 error control, with TCP, proven IETF technology. =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 06:30:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFSVx-0003c6-SP; Mon, 30 Jul 2007 06:30:13 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFSVv-0003bW-VX for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 06:30:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFSVv-0003bL-Ln for simple@ietf.org; Mon, 30 Jul 2007 06:30:11 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFSVu-0000KN-3M for simple@ietf.org; Mon, 30 Jul 2007 06:30:11 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6UATf0O017738; Mon, 30 Jul 2007 13:30:05 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 13:30:04 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 13:30:04 +0300 Received: from [10.144.22.119] ([10.144.22.119]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 13:30:03 +0300 Message-ID: <46ADBDAB.4060207@nsn.com> Date: Mon, 30 Jul 2007 13:30:03 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] comments on draft-ietf-simple-chat References: <46A7BC15.5040909@cisco.com> In-Reply-To: <46A7BC15.5040909@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 10:30:03.0918 (UTC) FILETIME=[97539AE0:01C7D294] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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: , Errors-To: simple-bounces@ietf.org Jonathan, thanks for your comments. In order to keep the discussion under control, I am going to split your mail in a series open issues and post separately. So folks interested in the discussion, I will suggest to not reply to this e-mail and wait for each separate post. /Miguel Jonathan Rosenberg wrote: > The draft worries about MSRP chatrooms negotiating the capability for > private and sidebar functions. Wouldn't it be easier to require all MSRP > mixers to support this functionality? Then you only need to worry about > conference-unaware participants. > > > Figure 1: should clarify that this is showing only the MSRP > relationship, not the SIP one. > >> The conference focus of a chat room MUST learn the chatroom >> capabilities of each participant that joins the chat room, and MUST >> inform the MSRP mixer of such support. This is to prevent that the >> MSRP mixer distributes private messages to participants who do not >> support private messaging. > > this text seems out of place here since you havent said anything about > what is involved in learning such capabilities. > >> In particular, this specification does not provide >> a general mechanism for domains issuing nicknames, other than the >> domain of the conference server. > > I think this is good, but the conversational text above talks about > domain nicknames. I think it should speak only of chatroom nicknames. > >> An example of a nickname is: >> >> sip:Alice%20in%20wonderland@example.com > > If a nickname is scoped to a conference, the URI has to include a > conference identifier so that such URIs are unique and properly scoped. > I'd suggest something like: > > sip:"msrp-nicknames" "/" "/" @ domain > > >> The >> validation can also fail, e.g., if the Use-Nickname header contains a >> nickname URI for which the conference server has no authority and the >> conference server does not have the means to validate the nickname >> from the domain that issued it. > > This seems to say that what a user should be able to reserve is ONLY the > part above, so that the only error possible is that the > nickname is in use. > > I'd suggest that the text on nicknames clarify why this is IM specific. > I think the reason is, that unlike audio or video, IM's contain sender > identifiers as part of the media, and the purpose of this function is > the IM-specific process of their reservation. > > In fact, this is not entirely true; there is a rough equivalent in RTP > which is the CNAME. There is a media-specific (i.e., RTP-based) approach > for declaring (if not reserving) cnames, which is via RTCP. So this is > really just an analagous function. > >> A policy in the >> MSRP mixer determines whether avoidance of collisions between >> nicknames and regular Addresses of Record is enforced. > > Practically speaking this is impossible to do. This is why I suggest > formal structure around the user part of the URI to guarantee this. > >> A policy in the conference >> server determines whether a user who is participating in the >> conference from various UAs is allowed to use the same nickname >> across those UAs. > > This requires knowledge of this alias relationship which may be hard or > impossible to know. Why is this needed? > >> If the sender of the message wants to remain anonymous to the rest of >> the participants, and providing that the policy of the conference >> allows anonymous participation, the creator SHOULD populate the From >> header of the Message/CPIM body with an anonymous identity, e.g., >> using the "anonymous" SIP URI as described in RFC 3261 [RFC3261] > > Ugh, this is a bug I'd rather not propagate.... > >> An MSRP switch that receives a SEND request from a participant SHOULD >> first verify that the From header field of the Message/CPIM wrapper >> is correctly populated with a valid URI as indicated earlier. If the >> URI included in the From header field of the Message/CPIM wrapper is >> not valid (e.g, because it does not "belong" to the user), then the >> MSRP switch MUST generate a 403 response and MUST NOT forward the >> SEND request to any of the participants. Otherwise, the MSRP switch >> SHOULD generate a 200 response according to the MSRP rules for >> response generation. > > Hmm, I wonder if, you take the model that NICKNAME is like CNAME/SSRC, > then the only thing that you would be allowed send in the MSRP is the > nickname, and then in that case this authentication is easy - you only > need to verify that the sender had reserved that nickname. Would allow a > much lighter relationship between the focus and the msrp switch. > > Section 7 - should break it up into sections on client and switch > behavior requirements. > >> Then the MSRP switch should inspect the To header field of the >> Message/CPIM wrapper. If the To header field of the Message/CPIM >> wrapper contains the chat room URI, the MSRP switch can generate a >> copy of the SEND request to each of the participants in the >> conference except the sender. > > MUST generate a copy > > Suggest merging 7.1 and 7.2 since they are largely the same, differing > only in construction and interpreation of To field. > >> Sidebars >> >> This document does not provide any protocol means to create, >> manipulate, or send messages to sidebars. In many cases, a sidebar >> is a logical subgroup of participants which exists only in each of >> the recipients endpoints. Sending a message to the sidebar is >> modelled as a private message addressed to each of the members of the >> sidebar. As such, it is to possible to re-create the 'sidebar user >> experience' totally in the endpoints by correlating collections of >> private messages, thus, this document does not create any sidebar- >> specific mechanism. > > I'd suggest that private messaging is distinct from a sidebar. The > latter is an object that is really a full conference within a > conference, allowing for audio and video. Private messaging is a much > more lightweight, transient form of communication. > > Thanks, > Jonathan R. -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 06:36:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFScT-0006wv-2j; Mon, 30 Jul 2007 06:36:57 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFScS-0006wm-4K for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 06:36:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFScR-0006wc-R4 for simple@ietf.org; Mon, 30 Jul 2007 06:36:55 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFScQ-0000hl-3q for simple@ietf.org; Mon, 30 Jul 2007 06:36:55 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6UAafEj029509; Mon, 30 Jul 2007 13:36:50 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 13:36:22 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 13:36:22 +0300 Received: from [10.144.22.119] ([10.144.22.119]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 13:36:21 +0300 Message-ID: <46ADBF25.7000801@nsn.com> Date: Mon, 30 Jul 2007 13:36:21 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 10:36:21.0830 (UTC) FILETIME=[78946660:01C7D295] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: SIMPLE mailing list Subject: [Simple] [MSRP chat] Issue 3: capability negotiation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jonathan Rosenberg wrote: > The draft worries about MSRP chatrooms negotiating the capability for > private and sidebar functions. Wouldn't it be easier to require all > MSRP mixers to support this functionality? Then you only need to worry > about conference-unaware participants. This comes from the idea that not all MSRP mixers would implement this document: one can easily build an MSRP mixer today that merely forwards messages from one participant to the rest. If the UA does not learn whether private messages are implemented, the risk is that the MSRP mixer does not implement these functions; a user could send a private message that would be distributed to all the participants. Also, as a side effect, the capability negotiation provides an indication of functions (nicknames, private messaging), which are enabled (by policy). Honestly, I feel more comfortable if we don't assume anything and let the UA learn the features that are implemented. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 06:41:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFSgD-0001k2-Nk; Mon, 30 Jul 2007 06:40:49 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFSgC-0001jv-FR for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 06:40:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFSgC-0001jn-5P for simple@ietf.org; Mon, 30 Jul 2007 06:40:48 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFSgB-0000PU-Ko for simple@ietf.org; Mon, 30 Jul 2007 06:40:48 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6UAeI5C023286; Mon, 30 Jul 2007 13:40:43 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 13:40:23 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 13:40:23 +0300 Received: from [10.144.22.119] ([10.144.22.119]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 13:40:23 +0300 Message-ID: <46ADC017.9070602@nsn.com> Date: Mon, 30 Jul 2007 13:40:23 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 10:40:23.0371 (UTC) FILETIME=[088CA1B0:01C7D296] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: SIMPLE mailing list Subject: [Simple] [MSRP-Chat] Figure improvement X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jonathan Rosenberg wrote: > Figure 1: should clarify that this is showing only the MSRP > relationship, not the SIP one. Right. Perhaps also a reference to RFC 4353 or adding the SIP missing interfaces. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 06:56:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFSv1-0000a0-By; Mon, 30 Jul 2007 06:56:07 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFSuz-0000Zr-HO for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 06:56:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFSuz-0000Zh-73 for simple@ietf.org; Mon, 30 Jul 2007 06:56:05 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFSuy-0000ts-LK for simple@ietf.org; Mon, 30 Jul 2007 06:56:05 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6UAtY0m014484; Mon, 30 Jul 2007 13:56:01 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 13:55:36 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 13:55:35 +0300 Received: from [10.144.22.119] ([10.144.22.119]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 13:55:32 +0300 Message-ID: <46ADC3A3.7010900@nsn.com> Date: Mon, 30 Jul 2007 13:55:31 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 10:55:32.0082 (UTC) FILETIME=[262EED20:01C7D298] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: SIMPLE mailing list Subject: [Simple] [MSRP chat] Issue 5: Unplaced text: learning capabilities X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jonathan Rosenberg wrote: >> The conference focus of a chat room MUST learn the chatroom >> capabilities of each participant that joins the chat room, and >> MUST >> inform the MSRP mixer of such support. This is to prevent that >> the >> MSRP mixer distributes private messages to participants who do not >> support private messaging. > > this text seems out of place here since you havent said anything about > what is involved in learning such capabilities. There is a paragraph in Section 4 (earlier in the draft) that mentions the learning process: We extend the current MSRP negotiation that takes place in SDP [RFC4566] to allow participants to learn whether the chat room supports and is willing to accept (e.g., due to local policy restrictions) certain MSRP functions defined in this memo, such as nicknames or private messaging. Isn't that enough to justify the actions that take place when a user joins a chat room? Or are you suggesting to clarify that the learning process is bidirectional, from chat room server to UA and from UA to chat room server? /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 08:01:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFTwD-0008PT-L8; Mon, 30 Jul 2007 08:01:25 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFTwB-0008Ox-W2 for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 08:01:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFTwB-0008OW-3k for simple@ietf.org; Mon, 30 Jul 2007 08:01:23 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFTwA-0002gO-Gu for simple@ietf.org; Mon, 30 Jul 2007 08:01:23 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6UC0qcr032554; Mon, 30 Jul 2007 15:01:19 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 15:00:42 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 15:00:41 +0300 Received: from [10.144.22.119] ([10.144.22.119]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 15:00:41 +0300 Message-ID: <46ADD2E9.9010206@nsn.com> Date: Mon, 30 Jul 2007 15:00:41 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 12:00:41.0544 (UTC) FILETIME=[40677C80:01C7D2A1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: SIMPLE mailing list Subject: [Simple] [MSRP chat] Issue 6: Domain of the nickname URI X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jonathan Rosenberg wrote: >> In particular, this specification does not provide >> a general mechanism for domains issuing nicknames, other than the >> domain of the conference server. > > I think this is good, but the conversational text above talks about > domain nicknames. I think it should speak only of chatroom nicknames. > My understanding was that we wanted to provide zero support for domain nicknames, although it would be syntactically correct to include a domain nickname in the protocol. On doing so, there might be a few areas where the authors have failed to provide a clear terminology when transiting from previous versions of the drafts. So, I would suggest that we clarify early enough that: - The spec does not support domain names, although it could be included if in the future a spec indicates all the procedures. - The spec supports only nicknames issued by the chat room server /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 08:40:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFUXd-0003bp-Jz; Mon, 30 Jul 2007 08:40:05 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFUXc-0003XN-A4 for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 08:40:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFUXb-0003W3-U1 for simple@ietf.org; Mon, 30 Jul 2007 08:40:03 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFUXb-0003cK-9z for simple@ietf.org; Mon, 30 Jul 2007 08:40:03 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6UCdeeC031021; Mon, 30 Jul 2007 15:39:59 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 15:39:58 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 15:39:58 +0300 Received: from [10.144.22.119] ([10.144.22.119]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 15:39:58 +0300 Message-ID: <46ADDC1E.10301@nsn.com> Date: Mon, 30 Jul 2007 15:39:58 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 12:39:58.0078 (UTC) FILETIME=[BD0209E0:01C7D2A6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: SIMPLE mailing list Subject: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jonathan Rosenberg wrote: >> An example of a nickname is: >> >> sip:Alice%20in%20wonderland@example.com > > If a nickname is scoped to a conference, the URI has to include a > conference identifier so that such URIs are unique and properly scoped. > I'd suggest something like: > > sip:"msrp-nicknames" "/" "/" @ domain This comes as a side effect of the confusion with domain nicknames in previous issues. So, I agree that the nickname URI has to include the conference URI. Earlier versions of the drat spoke about sip:nick@conf@domain, and percentage encoding of the first '@' sgn. Please verify if the text we used to have is still applicable Let us take a look at an example. Assume the chat room URI allocated to a given chat room is 'sip:room34@example.com'. A user whose nickname identifier is set to 'nordicguy' is represented with the nickname URI: 'sip:nordicguy%40room34@example.com'. In another example the chat room URI does not include a username part. For example, the chat room URI is 'sip:chat34.example.com'. In this context a user whose nickname is 'nordicguy' gets represented with a nickname URI of 'sip:nordicguy@chat34.example.com'. Let me know if the percentage encoding of the '@' is ok or you really want to go with the "/" sign. The second aspect you are you suggesting: we should create a convention to represent nicknames so that they are distinguishable from "regular" URIs. This corresponds to the "msrp-nicknames" in your suggestion. I also think we need to do it, mostly for tracing and debugging purposes, but I thought of using the user= parameter of a SIP URI. So, what about this syntax? sip:nickname%40conf-uri-userpart@example.com;user=nikcname /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 09:54:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVhb-0007M2-Dq; Mon, 30 Jul 2007 09:54:27 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFVhZ-0007Lw-TH for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 09:54:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVhZ-0007Lm-JA for simple@ietf.org; Mon, 30 Jul 2007 09:54:25 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFVhZ-0005kV-16 for simple@ietf.org; Mon, 30 Jul 2007 09:54:25 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6UDrmq1010008; Mon, 30 Jul 2007 16:54:17 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 16:54:15 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 16:54:15 +0300 Received: from [10.144.22.119] ([10.144.22.119]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 16:54:14 +0300 Message-ID: <46ADED86.5040405@nsn.com> Date: Mon, 30 Jul 2007 16:54:14 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 13:54:14.0747 (UTC) FILETIME=[1D63C2B0:01C7D2B1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: SIMPLE mailing list Subject: [Simple] [MSRP chat] Issue 9: Nickname is IM specific X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jonathan Rosenberg wrote: > I'd suggest that the text on nicknames clarify why this is IM specific. > I think the reason is, that unlike audio or video, IM's contain sender > identifiers as part of the media, and the purpose of this function is > the IM-specific process of their reservation. > > In fact, this is not entirely true; there is a rough equivalent in RTP > which is the CNAME. There is a media-specific (i.e., RTP-based) approach > for declaring (if not reserving) cnames, which is via RTCP. So this is > really just an analagous function. I will clarify the name as you suggested. One distinction with CNAME in RTP is that nicknames are selected by the user whereas the user has no imput to the CNAME selection process. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 09:55:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFViw-0000HP-Rw; Mon, 30 Jul 2007 09:55:50 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFViv-0000HE-Vt for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 09:55:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFViv-0000H6-Lg for simple@ietf.org; Mon, 30 Jul 2007 09:55:49 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFViv-0005m3-3V for simple@ietf.org; Mon, 30 Jul 2007 09:55:49 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6UDtLbO011228; Mon, 30 Jul 2007 16:55:45 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 16:55:44 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 16:55:44 +0300 Received: from [10.144.22.119] ([10.144.22.119]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 16:55:44 +0300 Message-ID: <46ADEDDF.7060400@nsn.com> Date: Mon, 30 Jul 2007 16:55:43 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 13:55:44.0215 (UTC) FILETIME=[52B77E70:01C7D2B1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: SIMPLE mailing list Subject: [Simple] [MSRP chat] Issue 8: Domain in validations X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jonathan Rosenberg wrote: >> The >> validation can also fail, e.g., if the Use-Nickname header contains a >> nickname URI for which the conference server has no authority and the >> conference server does not have the means to validate the nickname >> from the domain that issued it. > > This seems to say that what a user should be able to reserve is ONLY the > part above, so that the only error possible is that the > nickname is in use. It would be possible, but then the headers wouldn't include a nickname URI, but just the "nickname" portion of the URI, not even the whole 'username' part of the nickname URI. The UA has the knowledge to build a full nickname URI, so I would prefer to leave in that way. The text that you mention was considering an error or unsupported case: the user includes a full nickname URI which is not structured according to this specification. Probably, in this case, we would need an error response as well (not yet specified). My suggestion: leave the procedures as they are, but clarify that the text above is an error case when a nickname is not built according to what the document says. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 10:06:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVss-0005Cu-Hg; Mon, 30 Jul 2007 10:06:06 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFVsq-0005Co-Qt for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 10:06:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVsq-0005Cg-GG for simple@ietf.org; Mon, 30 Jul 2007 10:06:04 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFVsp-0005zX-U6 for simple@ietf.org; Mon, 30 Jul 2007 10:06:04 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6UE5Sc1010712; Mon, 30 Jul 2007 17:05:58 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:05:11 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:05:10 +0300 Received: from [10.144.22.119] ([10.144.22.119]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:05:10 +0300 Message-ID: <46ADF016.10506@nsn.com> Date: Mon, 30 Jul 2007 17:05:10 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 14:05:10.0758 (UTC) FILETIME=[A4671860:01C7D2B2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: SIMPLE mailing list Subject: [Simple] [MSRP chat] Issue 10: Policies in the MSRP mixer X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jonathan Rosenberg wrote: >> A policy in the >> MSRP mixer determines whether avoidance of collisions between >> nicknames and regular Addresses of Record is enforced. > > Practically speaking this is impossible to do. This is why I suggest > formal structure around the user part of the URI to guarantee this. I see your point. So this is the reason for your suggestion of adding an "msrp-nickname" string to the user part of the URI. I want to hear if the "user=nickname" parameter is acceptable, which I believe is a bit more elegant. > >> A policy in the conference >> server determines whether a user who is participating in the >> conference from various UAs is allowed to use the same nickname >> across those UAs. > > This requires knowledge of this alias relationship which may be hard or > impossible to know. Why is this needed? Because I may want to attend a chat room from different devices simultaneously. I think I am still a single user, so, other participants shouldn't need to know which device I am using. And they should be able to send me private messages to both devices simultaneously, if this is my wish. This requires a policy in the server to allow it. I think it is feasible, at the end of the day, both the focus and the MSRP mixer already know the SIP AOR relation to nicknames. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 10:09:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVvg-0006Ts-7E; Mon, 30 Jul 2007 10:09:00 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFVve-0006Tn-W7 for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 10:08:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVve-0006Tf-Mf for simple@ietf.org; Mon, 30 Jul 2007 10:08:58 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFVvd-0007JN-4I for simple@ietf.org; Mon, 30 Jul 2007 10:08:58 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6UE8gV8007805; Mon, 30 Jul 2007 17:08:53 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:08:15 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:08:14 +0300 Received: from [10.144.22.119] ([10.144.22.119]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:08:14 +0300 Message-ID: <46ADF0CD.4080006@nsn.com> Date: Mon, 30 Jul 2007 17:08:13 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 14:08:14.0038 (UTC) FILETIME=[11A56760:01C7D2B3] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: SIMPLE mailing list Subject: [Simple] [MSRP chat] Issue 11: Anonymity bug X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jonathan Rosenberg wrote: >> If the sender of the message wants to remain anonymous to the rest of >> the participants, and providing that the policy of the conference >> allows anonymous participation, the creator SHOULD populate the From >> header of the Message/CPIM body with an anonymous identity, e.g., >> using the "anonymous" SIP URI as described in RFC 3261 [RFC3261] > > Ugh, this is a bug I'd rather not propagate.... So you are OK with the text, I hope. I was trying to give similar guidelines as RFC 3261 gives with respect the population of the From header field. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 10:20:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFW6i-0004I0-5i; Mon, 30 Jul 2007 10:20:24 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFW6h-0004Hv-89 for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 10:20:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFW6g-0004Hn-Um for simple@ietf.org; Mon, 30 Jul 2007 10:20:22 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFW6g-0007Zd-GE for simple@ietf.org; Mon, 30 Jul 2007 10:20:22 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 Jul 2007 10:20:22 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswMAKqQrUZAZnmf/2dsb2JhbACIZZ0r X-IronPort-AV: i="4.19,198,1183348800"; d="scan'208"; a="127398528:sNHT32541468" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6UEKMwU000420; Mon, 30 Jul 2007 10:20:22 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6UEKLEf029540; Mon, 30 Jul 2007 14:20:21 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 10:20:01 -0400 Received: from [161.44.174.190] ([161.44.174.190]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 10:20:00 -0400 Message-ID: <46ADF390.4010204@cisco.com> Date: Mon, 30 Jul 2007 10:20:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> In-Reply-To: <46ADDC1E.10301@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 14:20:00.0774 (UTC) FILETIME=[B6E4C260:01C7D2B4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2977; t=1185805222; x=1186669222; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20 |To:=20Miguel=20Garcia=20; bh=Qxz0zcYNSy83Zmecwra2m1w5GwjvIuwPaX9dKNzKgf0=; b=dRzGK3uFL3u/5kI9pcGocvLllLJla3zBxTI2f18TekFLahLc0qQXKWWE53HDS2HXJjaa1Le0 AOEDKZtGN4Qo/9zUg8eObJVgegQ6me5XKtN75CKfH2XTqiWd+m0TBMMm; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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: , Errors-To: simple-bounces@ietf.org inline Miguel Garcia wrote: > Jonathan Rosenberg wrote: > >> An example of a nickname is: > >> > >> sip:Alice%20in%20wonderland@example.com > > > > If a nickname is scoped to a conference, the URI has to include a > > conference identifier so that such URIs are unique and properly scoped. > > I'd suggest something like: > > > > sip:"msrp-nicknames" "/" "/" @ domain > > This comes as a side effect of the confusion with domain nicknames in > previous issues. > > So, I agree that the nickname URI has to include the conference > URI. Why? By my understanding we are not excluding domain nicknames - we are just not requiring them or specifying how they might work. Any syntactically correct nickname should be ok if the server finds it acceptable according to its own policies. Perhaps there is need for some mandatory-to-implement naming convention for nicknames that are intended to be per-conference. > Earlier versions of the drat spoke about sip:nick@conf@domain, > and percentage encoding of the first '@' sgn. Please verify if the > text we used to have is still applicable > > Let us take a look at an example. Assume the chat room URI allocated > to a given chat room is 'sip:room34@example.com'. A user whose > nickname identifier is set to 'nordicguy' is represented with the > nickname URI: 'sip:nordicguy%40room34@example.com'. Some other possibilities: sip:nordicguy@example.com;conf=room34 or sip:room34@example.com;name="nordicguy" > In another example the chat room URI does not include a username > part. For example, the chat room URI is 'sip:chat34.example.com'. > In this context a user whose nickname is 'nordicguy' gets represented > with a nickname URI of 'sip:nordicguy@chat34.example.com'. > > Let me know if the percentage encoding of the '@' is ok or you really > want to go with the "/" sign. > > The second aspect you are you suggesting: we should create a > convention to represent nicknames so that they are distinguishable > from "regular" URIs. This corresponds to the "msrp-nicknames" in your > suggestion. I also think we need to do it, mostly for tracing and > debugging purposes, but I thought of using the user= parameter of a > SIP URI. > > So, what about this syntax? > > sip:nickname%40conf-uri-userpart@example.com;user=nikcname The user=nickname is an interesting idea. Would this mean that it would be possible to have both: sip:alice@atlanta.com sip:alice@atlanta.com;user=nickname and the two would be distinct, potentially owned by different people? That sounds like a pretty confusing situation. Isn't it sufficient for a particular domain name to be dedicated to either "regular AORs" or "nicknames", if that makes sense? And why would it be bad to use a real AOR (that you own) as a nickname if you want and the focus allows it? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 10:20:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFW79-0004du-6d; Mon, 30 Jul 2007 10:20:51 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFW77-0004dj-BB for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 10:20:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFW77-0004db-1c for simple@ietf.org; Mon, 30 Jul 2007 10:20:49 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFW75-0007aM-JZ for simple@ietf.org; Mon, 30 Jul 2007 10:20:49 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6UEKaDE023510; Mon, 30 Jul 2007 17:20:44 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:20:27 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:20:26 +0300 Received: from [10.144.22.119] ([10.144.22.119]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:20:26 +0300 Message-ID: <46ADF3AA.4030400@nsn.com> Date: Mon, 30 Jul 2007 17:20:26 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 14:20:26.0612 (UTC) FILETIME=[C64B5340:01C7D2B4] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: SIMPLE mailing list Subject: [Simple] [MSRP chat] Issue 12: From header in CPIM X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jonathan Rosenberg wrote: >> An MSRP switch that receives a SEND request from a participant SHOULD >> first verify that the From header field of the Message/CPIM wrapper >> is correctly populated with a valid URI as indicated earlier. If the >> URI included in the From header field of the Message/CPIM wrapper is >> not valid (e.g, because it does not "belong" to the user), then the >> MSRP switch MUST generate a 403 response and MUST NOT forward the >> SEND request to any of the participants. Otherwise, the MSRP switch >> SHOULD generate a 200 response according to the MSRP rules for >> response generation. > > Hmm, I wonder if, you take the model that NICKNAME is like CNAME/SSRC, > then the only thing that you would be allowed send in the MSRP is the > nickname, and then in that case this authentication is easy - you only > need to verify that the sender had reserved that nickname. Would allow a > much lighter relationship between the focus and the msrp switch. True, but then we would be forcing that every user needs a nickname to join the conference. So far, we have been thinking that nicknames could be disabled by policy. This is something I have observed particularly in corporate chat rooms. Additionally, we currently have a two-stage joining model, where first there is an INVITE and the a NICKNAME method to set up the nickname. Therefore, it is perfectly valid that a user does not setup his nickname at all. So, I think we need to leave the text as is. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 10:25:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWB7-0005u6-Pj; Mon, 30 Jul 2007 10:24:57 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFWB6-0005tv-Py for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 10:24:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWB6-0005tg-FT for simple@ietf.org; Mon, 30 Jul 2007 10:24:56 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFWB5-0006Qe-VJ for simple@ietf.org; Mon, 30 Jul 2007 10:24:56 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6UEOQ6K004303; Mon, 30 Jul 2007 17:24:50 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:24:33 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:24:33 +0300 Received: from [10.144.22.119] ([10.144.22.119]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:24:33 +0300 Message-ID: <46ADF4A0.5080606@nsn.com> Date: Mon, 30 Jul 2007 17:24:32 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 14:24:33.0108 (UTC) FILETIME=[5937A140:01C7D2B5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: SIMPLE mailing list Subject: [Simple] [MSRP chat] Issue 13: Divide Section 7 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jonathan Rosenberg wrote: > Section 7 - should break it up into sections on client and switch > behavior requirements. Will do, no problem. -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 10:28:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWES-0008LJ-8C; Mon, 30 Jul 2007 10:28:24 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFWER-0008KZ-0V for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 10:28:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWEQ-0008KR-Mg for simple@ietf.org; Mon, 30 Jul 2007 10:28:22 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFWEQ-0006VA-5H for simple@ietf.org; Mon, 30 Jul 2007 10:28:22 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6UES1Nv024819; Mon, 30 Jul 2007 17:28:18 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:28:16 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:28:16 +0300 Received: from [10.144.22.119] ([10.144.22.119]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:28:15 +0300 Message-ID: <46ADF57F.1070508@nsn.com> Date: Mon, 30 Jul 2007 17:28:15 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 14:28:15.0901 (UTC) FILETIME=[DE0324D0:01C7D2B5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: SIMPLE mailing list Subject: [Simple] [MSRP chat] Issue 14: Normative text X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jonathan Rosenberg wrote: >> Then the MSRP switch should inspect the To header field of the >> Message/CPIM wrapper. If the To header field of the Message/CPIM >> wrapper contains the chat room URI, the MSRP switch can generate a >> copy of the SEND request to each of the participants in the >> conference except the sender. > > MUST generate a copy Will upgrade to normative text. -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 10:30:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWGb-0001Jm-UM; Mon, 30 Jul 2007 10:30:37 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFWGZ-0001Jg-SB for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 10:30:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWGZ-0001JY-Ie for simple@ietf.org; Mon, 30 Jul 2007 10:30:35 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFWGY-0007nz-39 for simple@ietf.org; Mon, 30 Jul 2007 10:30:35 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6UEULaK003027; Mon, 30 Jul 2007 17:30:30 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:30:00 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:29:59 +0300 Received: from [10.144.22.119] ([10.144.22.119]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:29:59 +0300 Message-ID: <46ADF5E7.50107@nsn.com> Date: Mon, 30 Jul 2007 17:29:59 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 14:29:59.0273 (UTC) FILETIME=[1BA07590:01C7D2B6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: SIMPLE mailing list Subject: [Simple] [MSRP chat] Issue 15: Merging of Sections 7.1 and 7.2 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jonathan Rosenberg wrote: > Suggest merging 7.1 and 7.2 since they are largely the same, differing > only in construction and interpreation of To field. Agreed, will merge. -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 10:37:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWNH-0005FV-51; Mon, 30 Jul 2007 10:37:31 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFWNF-0005FK-3Z for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 10:37:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWNE-0005FC-Po for simple@ietf.org; Mon, 30 Jul 2007 10:37:28 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFWNE-0006s6-7n for simple@ietf.org; Mon, 30 Jul 2007 10:37:28 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6UEb1Jg032033; Mon, 30 Jul 2007 17:37:24 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:34:46 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:34:46 +0300 Received: from [10.144.22.119] ([10.144.22.119]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 17:34:46 +0300 Message-ID: <46ADF706.6060208@nsn.com> Date: Mon, 30 Jul 2007 17:34:46 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 14:34:46.0265 (UTC) FILETIME=[C6AFF690:01C7D2B6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: SIMPLE mailing list Subject: [Simple] [MSRP chat] Issue 16: Sidebars concept X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jonathan Rosenberg wrote: >> Sidebars >> >> This document does not provide any protocol means to create, >> manipulate, or send messages to sidebars. In many cases, a sidebar >> is a logical subgroup of participants which exists only in each of >> the recipients endpoints. Sending a message to the sidebar is >> modelled as a private message addressed to each of the members of the >> sidebar. As such, it is to possible to re-create the 'sidebar user >> experience' totally in the endpoints by correlating collections of >> private messages, thus, this document does not create any sidebar- >> specific mechanism. > > I'd suggest that private messaging is distinct from a sidebar. The > latter is an object that is really a full conference within a > conference, allowing for audio and video. Private messaging is a much > more lightweight, transient form of communication. I agree. We put effort to say that sidebars are not supported, but can somehow be emulated. I will add some further clarifications with respect the differences between the two. I will add considerations with respect the limitations to emulate audio and video in a series of correlated private messages. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 10:37:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWNQ-0005YM-K1; Mon, 30 Jul 2007 10:37:40 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFWNP-0005RQ-DR for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 10:37:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWNP-0005PN-2t for simple@ietf.org; Mon, 30 Jul 2007 10:37:39 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFWNO-00081g-MS for simple@ietf.org; Mon, 30 Jul 2007 10:37:39 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Jul 2007 10:37:38 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswMAOyUrUZAZnme/2dsb2JhbACIZZ0r X-IronPort-AV: i="4.19,198,1183348800"; d="scan'208"; a="66524178:sNHT28519222" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6UEbcMs023786; Mon, 30 Jul 2007 10:37:38 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6UEbSWa025042; Mon, 30 Jul 2007 14:37:30 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 10:37:22 -0400 Received: from [161.44.174.190] ([161.44.174.190]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 10:37:21 -0400 Message-ID: <46ADF7A1.3060200@cisco.com> Date: Mon, 30 Jul 2007 10:37:21 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] [MSRP chat] Issue 10: Policies in the MSRP mixer References: <46ADF016.10506@nsn.com> In-Reply-To: <46ADF016.10506@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 14:37:21.0779 (UTC) FILETIME=[23618430:01C7D2B7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1936; t=1185806258; x=1186670258; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20[MSRP=20chat]=20Issue=2010=3A=20Policies=2 0in=20the=20MSRP=20mixer |Sender:=20 |To:=20Miguel=20Garcia=20; bh=mbNQ/fwJJFFxopmAanqOAndY8Dip30rCoFhSsoV2iv0=; b=WrT00YjqMB78wUG3IvQbmWVOQ84qksC83v1R2KIbyXBA0hN9zLtG75emXJ3uVWVfY87RmH4f THeEvWkmQZ80RarmBmBY/cx+LgBE4Q7l/hkc4Ma0tY+JJworpEmYeZlA; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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: , Errors-To: simple-bounces@ietf.org In common usage the collisions probably won't happen. And in any case, why is it important to avoid collisions? Two "participants" can legitimately have the same nickname if the same user connects twice. I don't see that it presents any further issues if one user uses the URI as a From-URI for session establishment and another uses it as a nickname. In either case a targeted message may need to go to multiple participants. So what? Paul Miguel Garcia wrote: > Jonathan Rosenberg wrote: > >> A policy in the > >> MSRP mixer determines whether avoidance of collisions between > >> nicknames and regular Addresses of Record is enforced. > > > > Practically speaking this is impossible to do. This is why I suggest > > formal structure around the user part of the URI to guarantee this. > > I see your point. So this is the reason for your suggestion of adding > an "msrp-nickname" string to the user part of the URI. I want to hear > if the "user=nickname" parameter is acceptable, which I believe is a > bit more elegant. > > > > >> A policy in the conference > >> server determines whether a user who is participating in the > >> conference from various UAs is allowed to use the same nickname > >> across those UAs. > > > > This requires knowledge of this alias relationship which may be hard or > > impossible to know. Why is this needed? > > Because I may want to attend a chat room from different devices > simultaneously. I think I am still a single user, so, other > participants shouldn't need to know which device I am using. And they > should be able to send me private messages to both devices > simultaneously, if this is my wish. > > This requires a policy in the server to allow it. I think it is > feasible, at the end of the day, both the focus and the MSRP mixer > already know the SIP AOR relation to nicknames. > > /Miguel > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 10:41:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWRL-000893-Rm; Mon, 30 Jul 2007 10:41:43 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFWRK-00088y-FR for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 10:41:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWRK-00088o-4k for simple@ietf.org; Mon, 30 Jul 2007 10:41:42 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFWRJ-0006xq-Qv for simple@ietf.org; Mon, 30 Jul 2007 10:41:42 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 Jul 2007 10:41:42 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswMAB+VrUZAZnmf/2dsb2JhbACIZZ0s X-IronPort-AV: i="4.19,198,1183348800"; d="scan'208"; a="127401107:sNHT26017134" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6UEffAl012231; Mon, 30 Jul 2007 10:41:41 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6UEfRWq026638; Mon, 30 Jul 2007 14:41:41 GMT 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.1830); Mon, 30 Jul 2007 10:41:33 -0400 Received: from [161.44.174.190] ([161.44.174.190]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 10:41:32 -0400 Message-ID: <46ADF89D.5050908@cisco.com> Date: Mon, 30 Jul 2007 10:41:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] [MSRP chat] Issue 14: Normative text References: <46ADF57F.1070508@nsn.com> In-Reply-To: <46ADF57F.1070508@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 14:41:32.0822 (UTC) FILETIME=[B903A360:01C7D2B7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=662; t=1185806501; x=1186670501; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20[MSRP=20chat]=20Issue=2014=3A=20Normative= 20text |Sender:=20 |To:=20Miguel=20Garcia=20; bh=gAgKJtINqJ+NW3Rbt9QK4N/GeXx9ajw0haUC4JVlalU=; b=W8PuZvdPBAX2Ob3TcKbVPG98erLrFnxQ8fy+CWt9UbzoJNCZt4mVHFnx7rJ0dJrqcn9lj5Tp Q2w9TN/hWf7nl5IFHfNh2LRyy3RjPhgaOiSHi9G/uHMwdwrvxzP92tY/; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: , Errors-To: simple-bounces@ietf.org Miguel Garcia wrote: > Jonathan Rosenberg wrote: > >> Then the MSRP switch should inspect the To header field of the > >> Message/CPIM wrapper. If the To header field of the Message/CPIM > >> wrapper contains the chat room URI, the MSRP switch can generate a > >> copy of the SEND request to each of the participants in the > >> conference except the sender. > > > > MUST generate a copy Is this really mandatory? What about a participant that is in "sendonly" or "inactive" mode? It seems that the To header value is input to the "mixer", but that the mixing policy has some say in what to do as a result. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 19:22:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFeZO-0007Yw-6C; Mon, 30 Jul 2007 19:22:34 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFeZM-0007Yn-Ks for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 19:22:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFeZM-0007Yf-BL for simple@ietf.org; Mon, 30 Jul 2007 19:22:32 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFeZL-0005fV-TL for simple@ietf.org; Mon, 30 Jul 2007 19:22:32 -0400 Received: by py-out-1112.google.com with SMTP id f31so5393204pyh for ; Mon, 30 Jul 2007 16:22:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=uEVo4UqEhfg++vCu0bsPslhMXYXdf8AJxO2SYADzUsjIB7wskoQxwJYghA1TDRkRkqZcRlJBz8HLdnQwihc0HzJSUcp5yvO9zCRU57BcP9Q9h++IxENAtA6Tr3cV9+UNSKefqdCgiTikuo4cUy6JxdXhHT4T8HfwWmUaOCdgyBA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Pu00TjP0BvdplqArfpMVFHFtcZVy4XHVQJmxwarLU4lvoosMiLPLuz2v77MZcH2S3gxUjbVjNFGI4Jd5nOZHy8xIt6wdgV8p7j75rQ1AAbyJYSq6cz3lUgHeDQfWShnckzxIqfeewAp7vP+ccyxfrLm/IWWtzmFhPM7IwReaqdc= Received: by 10.65.214.19 with SMTP id r19mr9645003qbq.1185837751067; Mon, 30 Jul 2007 16:22:31 -0700 (PDT) Received: by 10.65.213.1 with HTTP; Mon, 30 Jul 2007 16:22:31 -0700 (PDT) Message-ID: <66cd252f0707301622g663d8d05yd93dfa60e283a12@mail.gmail.com> Date: Tue, 31 Jul 2007 09:22:31 +1000 From: "Hisham Khartabil" To: "Miguel Garcia" Subject: Re: [Simple] [MSRP chat] Issue 11: Anonymity bug In-Reply-To: <46ADF0CD.4080006@nsn.com> MIME-Version: 1.0 References: <46ADF0CD.4080006@nsn.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: , Content-Type: multipart/mixed; boundary="===============0830283702==" Errors-To: simple-bounces@ietf.org --===============0830283702== Content-Type: multipart/alternative; boundary="----=_Part_32584_2404075.1185837751020" ------=_Part_32584_2404075.1185837751020 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think Jonathan is asking you not to use whatever is in RFC3261 since he believes is it a bug. So he is not ok with the text. What other mechanisms do we have in place to allow anonymity? Hisham On 31/07/07, Miguel Garcia wrote: > > Jonathan Rosenberg wrote: > >> If the sender of the message wants to remain anonymous to the rest of > >> the participants, and providing that the policy of the conference > >> allows anonymous participation, the creator SHOULD populate the From > >> header of the Message/CPIM body with an anonymous identity, e.g., > >> using the "anonymous" SIP URI as described in RFC 3261 [RFC3261] > > > > Ugh, this is a bug I'd rather not propagate.... > > So you are OK with the text, I hope. I was trying to give similar > guidelines as RFC 3261 gives with respect the population of the From > header field. > > /Miguel > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Siemens Networks Espoo, Finland > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > ------=_Part_32584_2404075.1185837751020 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I think Jonathan is asking you not to use whatever is in RFC3261 since he believes is it a bug. So he is not ok with the text.
 
What other mechanisms do we have in place to allow anonymity?
 
Hisham

 
On 31/07/07, Miguel Garcia <Miguel.Garcia@nsn.com> wrote:
Jonathan Rosenberg wrote:
>> If the sender of the message wants to remain anonymous to the rest of
>>    the participants, and providing that the policy of the conference
>>    allows anonymous participation, the creator SHOULD populate the From
>>    header of the Message/CPIM body with an anonymous identity, e.g.,
>>    using the "anonymous" SIP URI as described in RFC 3261 [RFC3261]
>
> Ugh, this is a bug I'd rather not propagate....

So you are OK with the text, I hope. I was trying to give similar
guidelines as RFC 3261 gives with respect the population of the From
header field.

/Miguel
--
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland



_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

------=_Part_32584_2404075.1185837751020-- --===============0830283702== 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 --===============0830283702==-- From simple-bounces@ietf.org Mon Jul 30 19:41:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFert-0007xF-Eo; Mon, 30 Jul 2007 19:41:41 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFerr-0007xA-86 for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 19:41:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFerq-0007x1-Ul for simple@ietf.org; Mon, 30 Jul 2007 19:41:38 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFerp-00066D-UT for simple@ietf.org; Mon, 30 Jul 2007 19:41:38 -0400 Received: by py-out-1112.google.com with SMTP id f31so5406706pyh for ; Mon, 30 Jul 2007 16:41:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=AojsbjrURTxFbq1XGGcq8dgJZKgCEuQH1EzTcI0fgIveGP+Ea1KpJo3eYnhRkAaO/KKtNYJxH9KdgWqRpeRRnTCW+L9gCslZQO+704zrGsNjJTmqm+ZLdw9d0bgWIo9Mth9E5v4Tbjba/RUFWXr7J7D8V8MY2NW0cO0vp3UQyYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=W6wF214FpBDqATv8FGIikxR9q76eciTQEgKJKecPdYJYkaqMPtwb0cBShJx4zLx0ajqCnlk2erFaPFa84qv0QeYlX3DRo7zm9j3XorqUJI+LoFUEkjwGdkxvxa1L/8RnfhM5kMe8PHG0PAD2Kg3XcHfVQL0saB9bm6RjkynNf1U= Received: by 10.65.54.9 with SMTP id g9mr9643562qbk.1185838896241; Mon, 30 Jul 2007 16:41:36 -0700 (PDT) Received: by 10.65.213.1 with HTTP; Mon, 30 Jul 2007 16:41:36 -0700 (PDT) Message-ID: <66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com> Date: Tue, 31 Jul 2007 09:41:36 +1000 From: "Hisham Khartabil" To: "Paul Kyzivat" Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI In-Reply-To: <46ADF390.4010204@cisco.com> MIME-Version: 1.0 References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: Miguel Garcia , 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: , Content-Type: multipart/mixed; boundary="===============0294359727==" Errors-To: simple-bounces@ietf.org --===============0294359727== Content-Type: multipart/alternative; boundary="----=_Part_32732_7999813.1185838896205" ------=_Part_32732_7999813.1185838896205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think the nickname needs to include the conference identifier for the reasons as follows: I am in a chatroom where Alice is. I want to send a private message to Alice, so my client just happens to pick Alice's nickname and send the message to her in a normal SIP MESSAGE. The way I think the MESSAGE should reach its destination of Alice's client is via the chatroom server. So, in order for that to happen, the domain part of the nickname should be routable to the chatroom. So Miguel, looking at your examples 'sip:chat34@example.com' and 'sip:chat34.example.com' being both valid chatroom URIs. In both cases, I think the nickname URI should look like @chat34.example.com. The latter chatroom URI is ok since it can be routable to the chatroom , but the former is troublesom. Guidence is need to say that when a nickname is created and the chatroom URI is in the form room@domain.com, the 'room' should be put as a subdomain in the form nickname@room.domain.com. Regards, Hisham On 31/07/07, Paul Kyzivat wrote: > > inline > > Miguel Garcia wrote: > > Jonathan Rosenberg wrote: > > >> An example of a nickname is: > > >> > > >> sip:Alice%20in%20wonderland@example.com > > > > > > If a nickname is scoped to a conference, the URI has to include a > > > conference identifier so that such URIs are unique and properly > scoped. > > > I'd suggest something like: > > > > > > sip:"msrp-nicknames" "/" "/" @ domain > > > > This comes as a side effect of the confusion with domain nicknames in > > previous issues. > > > > So, I agree that the nickname URI has to include the conference > > URI. > > Why? > > By my understanding we are not excluding domain nicknames - we are just > not requiring them or specifying how they might work. Any syntactically > correct nickname should be ok if the server finds it acceptable > according to its own policies. > > Perhaps there is need for some mandatory-to-implement naming convention > for nicknames that are intended to be per-conference. > > > Earlier versions of the drat spoke about sip:nick@conf@domain, > > and percentage encoding of the first '@' sgn. Please verify if the > > text we used to have is still applicable > > > > Let us take a look at an example. Assume the chat room URI allocated > > to a given chat room is 'sip:room34@example.com'. A user whose > > nickname identifier is set to 'nordicguy' is represented with the > > nickname URI: 'sip:nordicguy%40room34@example.com'. > > Some other possibilities: > > sip:nordicguy@example.com;conf=room34 > or sip:room34@example.com;name="nordicguy" > > > In another example the chat room URI does not include a username > > part. For example, the chat room URI is 'sip:chat34.example.com'. > > In this context a user whose nickname is 'nordicguy' gets represented > > with a nickname URI of 'sip:nordicguy@chat34.example.com'. > > > > Let me know if the percentage encoding of the '@' is ok or you really > > want to go with the "/" sign. > > > > The second aspect you are you suggesting: we should create a > > convention to represent nicknames so that they are distinguishable > > from "regular" URIs. This corresponds to the "msrp-nicknames" in your > > suggestion. I also think we need to do it, mostly for tracing and > > debugging purposes, but I thought of using the user= parameter of a > > SIP URI. > > > > So, what about this syntax? > > > > sip:nickname%40conf-uri-userpart@example.com;user=nikcname > > The user=nickname is an interesting idea. Would this mean that it would > be possible to have both: > > sip:alice@atlanta.com > sip:alice@atlanta.com;user=nickname > > and the two would be distinct, potentially owned by different people? > That sounds like a pretty confusing situation. Isn't it sufficient for a > particular domain name to be dedicated to either "regular AORs" or > "nicknames", if that makes sense? And why would it be bad to use a real > AOR (that you own) as a nickname if you want and the focus allows it? > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > ------=_Part_32732_7999813.1185838896205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I think the nickname needs to include the conference identifier for the reasons as follows:
 
I am in a chatroom where Alice is. I want to send a private message to Alice, so my client just happens to pick Alice's nickname and send the message to her in a normal SIP MESSAGE.
 
The way I think the MESSAGE should reach its destination of Alice's client is via the chatroom server. So, in order for that to happen, the domain part of the nickname should be routable to the chatroom.
 
So Miguel, looking at your examples 'sip:chat34@example.com' and 'sip:chat34.example.com' being both valid chatroom URIs. In both cases, I think the nickname URI should look like <nickname>@ chat34.example.com. The latter chatroom URI is ok since it can be routable to the chatroom , but the former is troublesom. Guidence is need to say that when a nickname is created and the chatroom URI is in the form room@domain.com, the 'room' should be put as a subdomain in the form nickname@room.domain.com.
Regards,
Hisham


 
On 31/07/07, Paul Kyzivat <pkyzivat@cisco.com> wrote:
inline

Miguel Garcia wrote:
> Jonathan Rosenberg wrote:
>  >> An example of a nickname is:
>  >>
>  >>           sip:Alice%20in%20wonderland@example.com
>  >
>  > If a nickname is scoped to a conference, the URI has to include a
>  > conference identifier so that such URIs are unique and properly scoped.
>  > I'd suggest something like:
>  >
>  > sip:"msrp-nicknames" "/" <nickname> "/" <conf-uri-userpart> @ domain
>
> This comes as a side effect of the confusion with domain nicknames in
> previous issues.
>
> So, I agree that the nickname URI has to include the conference
> URI.

Why?

By my understanding we are not excluding domain nicknames - we are just
not requiring them or specifying how they might work. Any syntactically
correct nickname should be ok if the server finds it acceptable
according to its own policies.

Perhaps there is need for some mandatory-to-implement naming convention
for nicknames that are intended to be per-conference.

> Earlier versions of the drat spoke about sip:nick@conf@domain,
> and percentage encoding of the first '@' sgn. Please verify if the
> text we used to have is still applicable
>
>    Let us take a look at an example.  Assume the chat room URI allocated
>    to a given chat room is 'sip:room34@example.com '.  A user whose
>    nickname identifier is set to 'nordicguy' is represented with the
>    nickname URI: 'sip:nordicguy%40room34@example.com '.

Some other possibilities:

       sip:nordicguy@example.com;conf=room34
or    sip:room34@example.com;name="nordicguy"

>    In another example the chat room URI does not include a username
>    part.  For example, the chat room URI is 'sip:chat34.example.com'.
>    In this context a user whose nickname is 'nordicguy' gets represented
>    with a nickname URI of 'sip:nordicguy@chat34.example.com'.
>
> Let me know if the percentage encoding of the '@' is ok or you really
> want to go with the "/" sign.
>
> The second aspect you are you suggesting: we should create a
> convention to represent nicknames so that they are distinguishable
> from "regular" URIs. This corresponds to the "msrp-nicknames" in your
> suggestion. I also think we need to do it, mostly for tracing and
> debugging purposes, but I thought of using the user= parameter of a
> SIP URI.
>
> So, what about this syntax?
>
>    sip:nickname%40conf-uri-userpart@example.com;user=nikcname

The user=nickname is an interesting idea. Would this mean that it would
be possible to have both:

       sip:alice@atlanta.com
       sip:alice@atlanta.com;user=nickname

and the two would be distinct, potentially owned by different people?
That sounds like a pretty confusing situation. Isn't it sufficient for a
particular domain name to be dedicated to either "regular AORs" or
"nicknames", if that makes sense? And why would it be bad to use a real
AOR (that you own) as a nickname if you want and the focus allows it?

       Paul


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

------=_Part_32732_7999813.1185838896205-- --===============0294359727== 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 --===============0294359727==-- From RodgerpenthouseOneal@homestead.com Mon Jul 30 20:26:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFfZT-0005bL-HE for simple-archive@lists.ietf.org; Mon, 30 Jul 2007 20:26:43 -0400 Received: from cpe-69-205-130-131.stny.res.rr.com ([69.205.130.131] helo=Perez) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IFfZS-0007W7-Ty for simple-archive@lists.ietf.org; Mon, 30 Jul 2007 20:26:43 -0400 Message-ID: From: "Kendall Oconnor" To: Subject: Fw: Thank you, we are ready to give a loan for a low month payment Date: Mon, 30 Jul 2007 20:26:26 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_A618_01C7D309.73A77830" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This is a multi-part message in MIME format. ------=_NextPart_000_A618_01C7D309.73A77830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit history does not matter to us! If you have your own business and require IMMEDIATE money to spend ANY = way you like or require Extra money to give your company a boost or wish = A low interest loan - NO STRINGS ATTACHED, here is best deal we can = offer you NOW (hurry, this tender will expire TODAY): $54,000+ loan Hurry, when our best deal is gone, it is gone. Simply Call Us... Don't worry about approval, your your credit report will not disqualify = you! Call Us Free on 877-542-1884 ------=_NextPart_000_A618_01C7D309.73A77830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your credit history does not = matter to=20 us!
=20
 
If you have your own business and = require=20 IMMEDIATE money to spend ANY way you like or require Extra money to give = your=20 company a boost or wish A low interest loan - NO STRINGS ATTACHED, here = is=20 best deal we can offer you NOW (hurry, this tender will expire=20 TODAY):
=20
 
$54,000+ loan
 
Hurry, when our best deal is = gone, it is=20 gone. Simply Call Us...
=20
 
Don't worry about approval, your = your credit=20 report will not disqualify you!
=20
 
Call Us Free on = 877-542-1884
------=_NextPart_000_A618_01C7D309.73A77830-- From simple-bounces@ietf.org Mon Jul 30 22:25:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFhQa-0004Ts-8z; Mon, 30 Jul 2007 22:25:40 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFhQZ-0004Tn-Cc for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 22:25:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFhQZ-0004TY-0o for simple@ietf.org; Mon, 30 Jul 2007 22:25:39 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFhQY-00038q-72 for simple@ietf.org; Mon, 30 Jul 2007 22:25:38 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Jul 2007 22:25:38 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwPAFc6rkZAZnme/2dsb2JhbACIBJwm X-IronPort-AV: i="4.19,201,1183348800"; d="scan'208"; a="66585730:sNHT145373752" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6V2PbO7022028; Mon, 30 Jul 2007 22:25:37 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6V2PbEZ029778; Tue, 31 Jul 2007 02:25:37 GMT 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.1830); Mon, 30 Jul 2007 22:24:30 -0400 Received: from [10.82.218.240] ([10.82.218.240]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 22:24:30 -0400 Message-ID: <46AE9D5C.8020609@cisco.com> Date: Mon, 30 Jul 2007 22:24:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com> <66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com> In-Reply-To: <66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 02:24:30.0175 (UTC) FILETIME=[ECACF6F0:01C7D319] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6633; t=1185848737; x=1186712737; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20[MSRP=20chat]=20Issue=207=3A=20Syntax=20of =20Nickname=20URI |Sender:=20 |To:=20Hisham=20Khartabil=20; bh=b/9McpKRKFoLxSuK4Kw+nn0kU46xGaQCJwZ2QwvXx3g=; b=VcUBMgC+TNQfHtXojFX8dMC36LbHIwv4E18GhrsOQiKuGyIeimNdBkyBFN08j7qRRgl8+2sf ae6Rc4wcc74OewopV8UoW4OAsePNFZ5eB2Xj48h8OvXI89X+34RSX8NR; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: Miguel Garcia , 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: , Errors-To: simple-bounces@ietf.org Hisham, Now you have almost embraced my concept of how this should work - that the nickname should be a sip routable address. But that does not require that it must identify the conference. I agree that it makes sense that it identify the converence *if the nickname is scoped to the conference*. But if the nickname has a broader scope then of course it can't be scoped to the conference. I see no problem with a nickname being a regular routable AOR, though most likely not all regular AORs will be suitable as nicknames. (There must be some way to verify that the nickname is authorized for use as a nickname by the user that is asserting it. In the case that the nickname is scoped to a conference then the conference focus can act as a proxy to route messages, and it can choose to do so only when the user is in the conference. It is also possible that the nickname is scoped to the conference server but not a particular conference. In that case it could still choose, if it desires, to only route messages to the nickname when the user is participating in a conference of that server. Thanks, Paul Hisham Khartabil wrote: > I think the nickname needs to include the conference identifier for the > reasons as follows: > > I am in a chatroom where Alice is. I want to send a private message to > Alice, so my client just happens to pick Alice's nickname and send the > message to her in a normal SIP MESSAGE. > > The way I think the MESSAGE should reach its destination of Alice's > client is via the chatroom server. So, in order for that to happen, the > domain part of the nickname should be routable to the chatroom. > > So Miguel, looking at your examples 'sip:chat34@example.com > ' and 'sip:chat34.example.com > ' being both valid chatroom URIs. In both > cases, I think the nickname URI should look like @ > chat34.example.com . The latter chatroom URI > is ok since it can be routable to the chatroom , but the former is > troublesom. Guidence is need to say that when a nickname is created and > the chatroom URI is in the form room@domain.com > , the 'room' should be put as a subdomain in the > form nickname@room.domain.com . > Regards, > Hisham > > > > On 31/07/07, *Paul Kyzivat* > wrote: > > inline > > Miguel Garcia wrote: > > Jonathan Rosenberg wrote: > > >> An example of a nickname is: > > >> > > >> sip:Alice%20in%20wonderland@example.com > > > > > > > If a nickname is scoped to a conference, the URI has to include a > > > conference identifier so that such URIs are unique and > properly scoped. > > > I'd suggest something like: > > > > > > sip:"msrp-nicknames" "/" "/" @ > domain > > > > This comes as a side effect of the confusion with domain nicknames in > > previous issues. > > > > So, I agree that the nickname URI has to include the conference > > URI. > > Why? > > By my understanding we are not excluding domain nicknames - we are just > not requiring them or specifying how they might work. Any syntactically > correct nickname should be ok if the server finds it acceptable > according to its own policies. > > Perhaps there is need for some mandatory-to-implement naming convention > for nicknames that are intended to be per-conference. > > > Earlier versions of the drat spoke about sip:nick@conf@domain, > > and percentage encoding of the first '@' sgn. Please verify if the > > text we used to have is still applicable > > > > Let us take a look at an example. Assume the chat room URI > allocated > > to a given chat room is 'sip:room34@example.com > '. A user whose > > nickname identifier is set to 'nordicguy' is represented with the > > nickname URI: 'sip:nordicguy%40room34@example.com > '. > > Some other possibilities: > > sip:nordicguy@example.com > ;conf=room34 > or sip:room34@example.com > ;name="nordicguy" > > > In another example the chat room URI does not include a username > > part. For example, the chat room URI is > 'sip:chat34.example.com '. > > In this context a user whose nickname is 'nordicguy' gets > represented > > with a nickname URI of 'sip:nordicguy@chat34.example.com > '. > > > > Let me know if the percentage encoding of the '@' is ok or you > really > > want to go with the "/" sign. > > > > The second aspect you are you suggesting: we should create a > > convention to represent nicknames so that they are distinguishable > > from "regular" URIs. This corresponds to the "msrp-nicknames" in > your > > suggestion. I also think we need to do it, mostly for tracing and > > debugging purposes, but I thought of using the user= parameter of a > > SIP URI. > > > > So, what about this syntax? > > > > sip:nickname%40conf-uri-userpart@example.com > ;user=nikcname > > The user=nickname is an interesting idea. Would this mean that it would > be possible to have both: > > sip:alice@atlanta.com > sip:alice@atlanta.com > ;user=nickname > > and the two would be distinct, potentially owned by different people? > That sounds like a pretty confusing situation. Isn't it sufficient for a > particular domain name to be dedicated to either "regular AORs" or > "nicknames", if that makes sense? And why would it be bad to use a real > AOR (that you own) as a nickname if you want and the focus allows it? > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 30 23:01:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFhz7-0000An-Ar; Mon, 30 Jul 2007 23:01:21 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFhz5-0000Aa-Tb for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 23:01:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFhz5-0000AS-J5 for simple@ietf.org; Mon, 30 Jul 2007 23:01:19 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFhz4-000499-AA for simple@ietf.org; Mon, 30 Jul 2007 23:01:19 -0400 Received: by py-out-1112.google.com with SMTP id f31so5533205pyh for ; Mon, 30 Jul 2007 20:01:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=l91U7svFOoVJUu1HsBy4boS/1dedGH+IS7egzlc8rHmwJh8c/Qt6r9WLXITQILPC5P7qOjGuR3AfmxO+G/J8VBd97KonA6Yuutrp9bFUMgiC9oDpJaCvIIQWtEQBE8n52G3b2dXw1ed32NshDxZN/np1Aqv1oID0cWE/PHaFLho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=p4STLspCOcya8IG0ejqfv181kFg5frdH+a7Gl61hsSHG9bKlSdReesxhfa7yB2iK7sBBtAyY8wR9MlXDpv+rFD/AMEyuiID/pNrtppnE+WEBq4bpEazK89NFlL0Hd553EbeMHnU1bqUbkLeM57XJ87XkieelG5mBp7AYyL7NBQM= Received: by 10.65.220.8 with SMTP id x8mr9799784qbq.1185850876759; Mon, 30 Jul 2007 20:01:16 -0700 (PDT) Received: by 10.65.213.1 with HTTP; Mon, 30 Jul 2007 20:01:16 -0700 (PDT) Message-ID: <66cd252f0707302001h3d854102r24f721f3911651a1@mail.gmail.com> Date: Tue, 31 Jul 2007 13:01:16 +1000 From: "Hisham Khartabil" To: "Paul Kyzivat" Subject: Re: [Simple] [MSRP chat] Issue 7: Syntax of Nickname URI In-Reply-To: <46AE9D5C.8020609@cisco.com> MIME-Version: 1.0 References: <46ADDC1E.10301@nsn.com> <46ADF390.4010204@cisco.com> <66cd252f0707301641w1eabc3f2ib817e669abdd7b55@mail.gmail.com> <46AE9D5C.8020609@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: Miguel Garcia , 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: , Content-Type: multipart/mixed; boundary="===============1891842694==" Errors-To: simple-bounces@ietf.org --===============1891842694== Content-Type: multipart/alternative; boundary="----=_Part_34432_30295561.1185850876715" ------=_Part_34432_30295561.1185850876715 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 31/07/07, Paul Kyzivat wrote: > > Hisham, > > > > In the case that the nickname is scoped to a conference then the > conference focus can act as a proxy to route messages, and it can choose > to do so only when the user is in the conference. Yes, I believe this is what we want for now. Hisham Hisham Khartabil wrote: > > I think the nickname needs to include the conference identifier for the > > reasons as follows: > > > > I am in a chatroom where Alice is. I want to send a private message to > > Alice, so my client just happens to pick Alice's nickname and send the > > message to her in a normal SIP MESSAGE. > > > > The way I think the MESSAGE should reach its destination of Alice's > > client is via the chatroom server. So, in order for that to happen, the > > domain part of the nickname should be routable to the chatroom. > > > > So Miguel, looking at your examples 'sip:chat34@example.com > > ' and 'sip:chat34.example.com > > ' being both valid chatroom URIs. In both > > cases, I think the nickname URI should look like @ > > chat34.example.com . The latter chatroom URI > > is ok since it can be routable to the chatroom , but the former is > > troublesom. Guidence is need to say that when a nickname is created and > > the chatroom URI is in the form room@domain.com > > , the 'room' should be put as a subdomain in the > > form nickname@room.domain.com . > > Regards, > > Hisham > > > > > > > > On 31/07/07, *Paul Kyzivat* > > wrote: > > > > inline > > > > Miguel Garcia wrote: > > > Jonathan Rosenberg wrote: > > > >> An example of a nickname is: > > > >> > > > >> sip:Alice%20in%20wonderland@example.com > > > > > > > > > > If a nickname is scoped to a conference, the URI has to > include a > > > > conference identifier so that such URIs are unique and > > properly scoped. > > > > I'd suggest something like: > > > > > > > > sip:"msrp-nicknames" "/" "/" @ > > domain > > > > > > This comes as a side effect of the confusion with domain > nicknames in > > > previous issues. > > > > > > So, I agree that the nickname URI has to include the conference > > > URI. > > > > Why? > > > > By my understanding we are not excluding domain nicknames - we are > just > > not requiring them or specifying how they might work. Any > syntactically > > correct nickname should be ok if the server finds it acceptable > > according to its own policies. > > > > Perhaps there is need for some mandatory-to-implement naming > convention > > for nicknames that are intended to be per-conference. > > > > > Earlier versions of the drat spoke about sip:nick@conf@domain, > > > and percentage encoding of the first '@' sgn. Please verify if > the > > > text we used to have is still applicable > > > > > > Let us take a look at an example. Assume the chat room URI > > allocated > > > to a given chat room is 'sip:room34@example.com > > '. A user whose > > > nickname identifier is set to 'nordicguy' is represented with > the > > > nickname URI: 'sip:nordicguy%40room34@example.com > > '. > > > > Some other possibilities: > > > > sip:nordicguy@example.com > > ;conf=room34 > > or sip:room34@example.com > > ;name="nordicguy" > > > > > In another example the chat room URI does not include a > username > > > part. For example, the chat room URI is > > 'sip:chat34.example.com '. > > > In this context a user whose nickname is 'nordicguy' gets > > represented > > > with a nickname URI of 'sip:nordicguy@chat34.example.com > > '. > > > > > > Let me know if the percentage encoding of the '@' is ok or you > > really > > > want to go with the "/" sign. > > > > > > The second aspect you are you suggesting: we should create a > > > convention to represent nicknames so that they are > distinguishable > > > from "regular" URIs. This corresponds to the "msrp-nicknames" in > > your > > > suggestion. I also think we need to do it, mostly for tracing and > > > debugging purposes, but I thought of using the user= parameter of > a > > > SIP URI. > > > > > > So, what about this syntax? > > > > > > sip:nickname%40conf-uri-userpart@example.com > > ;user=nikcname > > > > The user=nickname is an interesting idea. Would this mean that it > would > > be possible to have both: > > > > sip:alice@atlanta.com > > sip:alice@atlanta.com > > ;user=nickname > > > > and the two would be distinct, potentially owned by different > people? > > That sounds like a pretty confusing situation. Isn't it sufficient > for a > > particular domain name to be dedicated to either "regular AORs" or > > "nicknames", if that makes sense? And why would it be bad to use a > real > > AOR (that you own) as a nickname if you want and the focus allows > it? > > > > Paul > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > > ------=_Part_34432_30295561.1185850876715 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 31/07/07, Paul Kyzivat <pkyzivat@cisco.com> wrote:
Hisham,



In the case that the nickname is scoped to a conference then the
conference focus can act as a proxy to route messages, and it can choose
to do so only when the user is in the conference.
 
Yes, I believe this is what we want for now.
 
Hisham

Hisham Khartabil wrote:
> I think the nickname needs to include the conference identifier for the
> reasons as follows:
>
> I am in a chatroom where Alice is. I want to send a private message to
> Alice, so my client just happens to pick Alice's nickname and send the
> message to her in a normal SIP MESSAGE.
>
> The way I think the MESSAGE should reach its destination of Alice's
> client is via the chatroom server. So, in order for that to happen, the
> domain part of the nickname should be routable to the chatroom.
>
> So Miguel, looking at your examples 'sip:chat34@example.com
> <mailto:chat34@example.com>' and 'sip: chat34.example.com
> <http://chat34.example.com/>' being both valid chatroom URIs. In both
> cases, I think the nickname URI should look like <nickname>@
> chat34.example.com <http://chat34.example.com>. The latter chatroom URI
> is ok since it can be routable to the chatroom , but the former is
> troublesom. Guidence is need to say that when a nickname is created and
> the chatroom URI is in the form room@domain.com
> <mailto: room@domain.com>, the 'room' should be put as a subdomain in the
> form nickname@room.domain.com <mailto:nickname@room.domain.com >.
> Regards,
> Hisham
>
>
>
> On 31/07/07, *Paul Kyzivat* <pkyzivat@cisco.com
> <mailto:pkyzivat@cisco.com >> wrote:
>
>     inline
>
>     Miguel Garcia wrote:
>      > Jonathan Rosenberg wrote:
>      >  >> An example of a nickname is:
>      >  >>
>      >  >>           sip:Alice%20in%20wonderland@example.com
>     <mailto:sip:Alice%20in%20wonderland@example.com >
>      >  >
>      >  > If a nickname is scoped to a conference, the URI has to include a
>      >  > conference identifier so that such URIs are unique and
>     properly scoped.
>      >  > I'd suggest something like:
>      >  >
>      >  > sip:"msrp-nicknames" "/" <nickname> "/" <conf-uri-userpart> @
>     domain
>      >
>      > This comes as a side effect of the confusion with domain nicknames in
>      > previous issues.
>      >
>      > So, I agree that the nickname URI has to include the conference
>      > URI.
>
>     Why?
>
>     By my understanding we are not excluding domain nicknames - we are just
>     not requiring them or specifying how they might work. Any syntactically
>     correct nickname should be ok if the server finds it acceptable
>     according to its own policies.
>
>     Perhaps there is need for some mandatory-to-implement naming convention
>     for nicknames that are intended to be per-conference.
>
>      > Earlier versions of the drat spoke about sip:nick@conf@domain,
>      > and percentage encoding of the first '@' sgn. Please verify if the
>      > text we used to have is still applicable
>      >
>      >    Let us take a look at an example.  Assume the chat room URI
>     allocated
>      >    to a given chat room is 'sip:room34@example.com
>     <mailto:sip:room34@example.com>'.  A user whose
>      >    nickname identifier is set to 'nordicguy' is represented with the
>      >    nickname URI: 'sip:nordicguy%40room34@example.com
>     <mailto:sip: nordicguy%40room34@example.com>'.
>
>     Some other possibilities:
>
>            sip:nordicguy@example.com
>     <mailto: sip:nordicguy@example.com>;conf=room34
>     or    sip:room34@example.com
>     <mailto:sip :room34@example.com>;name="nordicguy"
>
>      >    In another example the chat room URI does not include a username
>      >    part.  For example, the chat room URI is
>     'sip:chat34.example.com <http://chat34.example.com>'.
>      >    In this context a user whose nickname is 'nordicguy' gets
>     represented
>      >    with a nickname URI of 'sip:nordicguy@chat34.example.com
>     <mailto:sip: nordicguy@chat34.example.com>'.
>      >
>      > Let me know if the percentage encoding of the '@' is ok or you
>     really
>      > want to go with the "/" sign.
>      >
>      > The second aspect you are you suggesting: we should create a
>      > convention to represent nicknames so that they are distinguishable
>      > from "regular" URIs. This corresponds to the "msrp-nicknames" in
>     your
>      > suggestion. I also think we need to do it, mostly for tracing and
>      > debugging purposes, but I thought of using the user= parameter of a
>      > SIP URI.
>      >
>      > So, what about this syntax?
>      >
>      >    sip:nickname%40conf-uri-userpart@example.com
>     <mailto: sip:nickname%40conf-uri-userpart@example.com>;user=nikcname
>
>     The user=nickname is an interesting idea. Would this mean that it would
>     be possible to have both:
>
>            sip:alice@atlanta.com <mailto:sip:alice@atlanta.com >
>            sip:alice@atlanta.com
>     <mailto:sip:alice@atlanta.com>;user=nickname
>
>     and the two would be distinct, potentially owned by different people?
>     That sounds like a pretty confusing situation. Isn't it sufficient for a
>     particular domain name to be dedicated to either "regular AORs" or
>     "nicknames", if that makes sense? And why would it be bad to use a real
>     AOR (that you own) as a nickname if you want and the focus allows it?
>
>            Paul
>
>
>     _______________________________________________
>     Simple mailing list
>     Simple@ietf.org <mailto:Simple@ietf.org >
>     https://www1.ietf.org/mailman/listinfo/simple
>
>

------=_Part_34432_30295561.1185850876715-- --===============1891842694== 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 --===============1891842694==-- From simple-bounces@ietf.org Mon Jul 30 23:33:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFiTQ-0007ev-H8; Mon, 30 Jul 2007 23:32:40 -0400 Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1IFiTP-0007Uy-3Y for simple-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 23:32:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFiTO-0007Tv-Po for simple@ietf.org; Mon, 30 Jul 2007 23:32:38 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFiTM-0005df-J7 for simple@ietf.org; Mon, 30 Jul 2007 23:32:38 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM0001N8XT2V8@szxga01-in.huawei.com> for simple@ietf.org; Tue, 31 Jul 2007 11:31:51 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM000IQOXT2FH@szxga01-in.huawei.com> for simple@ietf.org; Tue, 31 Jul 2007 11:31:50 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JM0003RXXSYN6@szxml04-in.huawei.com> for simple@ietf.org; Tue, 31 Jul 2007 11:31:50 +0800 (CST) Date: Tue, 31 Jul 2007 11:31:46 +0800 From: Qian Sun To: 'SIMPLE mailing list' Message-id: <024e01c7d323$52b83af0$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: AcfTI1J3ZzuojQOSTTmjtUHBg6510Q== X-Spam-Score: 1.2 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Simple] Twitter X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, guys Is anybody interested in this jumped-up website http://twitter.com? It is a kind of microblog. "A global community of friends and strangers answering one simple question: What are you doing?" I think it is very relevant to presence service. Could we define a microblog extension for element of PIDF? Like this: Busy day for me. Out for some fun Tue, 31 Jul 2007 02:09:35 +0000 http://twitter.com/ABCDee //it's a real example So that users can share their microblog via presence service. What do you think of this idea? Cheers, Qian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple