From alexey.melnikov@isode.com Wed Mar 2 06:42:39 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869593A6817 for ; Wed, 2 Mar 2011 06:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRwZN3oN1hHB for ; Wed, 2 Mar 2011 06:42:38 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 595BD3A67AF for ; Wed, 2 Mar 2011 06:42:38 -0800 (PST) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 2 Mar 2011 14:43:42 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D6E578D.9080707@isode.com> Date: Wed, 02 Mar 2011 14:43:25 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Alexey's next to the last AD report X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 14:42:39 -0000 I meant to write a "Christmas edition" of my usual AD report, but things got a bit out of hand with trying to finish various IESG related tasks. At the moment, I am holding a DISCUSS on a single document (draft-ietf-tls-rfc4347-bis-04 .txt), but this should be resolved before or around Prague. Other DISCUSSes were either cleared, or were taken by other ADs who would remain on IESG after Prague. At the moment I am concentrating on finishing sponsoring of a few remaining drafts: 1) draft-ietf-httpbis-content-disp-06 - in IETF LC and I hope to get it approved on March 17th IESG telechat. If this doesn't happen, Peter will be taking over the sponsoring of this document. 2) draft-holsten-about-uri-scheme-06 - I am trying to get this approved, but authors are not responding to my emails recently. Peter will take over this document, if I don't get it approved for publication. 3) draft-meadors-multiple-attachments-ediint-10 - This should be reviewed by IESG on March 17th. I am hoping this can get approved before my AD term ends at the end of March. 4) draft-salowey-secsh-uri-00 - Waiting for the author to revise the draft to address IETF LC comments. I am not certain that this document will be approved before Prague. 5) draft-ietf-tsvwg-iana-ports-10 - Reviewed by IESG. I need to enter some RFC Editor notes to address IESG and some IETF LC comments. I hope to get this approved before Prague. 6) draft-bryan-metalinkhttp-21 - In IESG review on March 3rd. Good effort from editors to clear DISCUSSes on the document. I am hoping to get this approved before Prague. I am spending a significant amount of my time tracking EAI and HYBI WGs. I am planning to close MORG WG before Prague. I am hoping to either close or start rechartering discussion for YAM before Prague. I am also trying to finish some IESG/IETF related projects: 1). Trying to finish Sieve External List (one of my documents) with Barry Leiba. Approval of this document would release 3 related Sieve RFCs. 2). Several related discussions on making URI/Media Type review processes easier and more transparent. I am hoping to discuss some proposed changes in Prague (during the Apps Area meeting), plus make some process/tool changes on IESG side (at least for MIME types) If you think this list is missing something, please let me know. Best Regards, Alexey From alexey.melnikov@isode.com Wed Mar 2 06:52:03 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B52B3A680F for ; Wed, 2 Mar 2011 06:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8nVqIQ6NIbC for ; Wed, 2 Mar 2011 06:52:02 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 155FF3A6806 for ; Wed, 2 Mar 2011 06:52:02 -0800 (PST) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 2 Mar 2011 14:53:07 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D6E59C2.70207@isode.com> Date: Wed, 02 Mar 2011 14:52:50 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org References: <4D6E578D.9080707@isode.com> In-Reply-To: <4D6E578D.9080707@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Alexey's next to the last AD report X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 14:52:03 -0000 Alexey Melnikov wrote: > At the moment I am concentrating on finishing sponsoring of a few > remaining drafts: > > 1) draft-ietf-httpbis-content-disp-06 - in IETF LC and I hope to get > it approved on March 17th IESG telechat. If this doesn't happen, Peter > will be taking over the sponsoring of this document. > 2) draft-holsten-about-uri-scheme-06 - I am trying to get this > approved, but authors are not responding to my emails recently. Peter > will take over this document, if I don't get it approved for publication. > 3) draft-meadors-multiple-attachments-ediint-10 - This should be > reviewed by IESG on March 17th. I am hoping this can get approved > before my AD term ends at the end of March. > 4) draft-salowey-secsh-uri-00 - Waiting for the author to revise the > draft to address IETF LC comments. I am not certain that this document > will be approved before Prague. > 5) draft-ietf-tsvwg-iana-ports-10 - Reviewed by IESG. I need to enter > some RFC Editor notes to address IESG and some IETF LC comments. I > hope to get this approved before Prague. > 6) draft-bryan-metalinkhttp-21 - In IESG review on March 3rd. Good > effort from editors to clear DISCUSSes on the document. I am hoping to > get this approved before Prague. If your document is not in this list, then it means that I wouldn't be able to sponsor it as an AD. But I might be able to help you as an editor/document shepherd starting from April. From stpeter@stpeter.im Wed Mar 2 08:30:47 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B01F3A6810 for ; Wed, 2 Mar 2011 08:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LhJHTvH46Im for ; Wed, 2 Mar 2011 08:30:43 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E5F4C3A67B6 for ; Wed, 2 Mar 2011 08:30:42 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 31166400F6; Wed, 2 Mar 2011 09:51:11 -0700 (MST) Message-ID: <4D6E70F2.6050205@stpeter.im> Date: Wed, 02 Mar 2011 09:31:46 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alexey Melnikov References: <4D6E578D.9080707@isode.com> In-Reply-To: <4D6E578D.9080707@isode.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050503070302030900040203" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Alexey's next to the last AD report X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 16:30:47 -0000 This is a cryptographically signed message in MIME format. --------------ms050503070302030900040203 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/2/11 7:43 AM, Alexey Melnikov wrote: > I meant to write a "Christmas edition" of my usual AD report, but thing= s > got a bit out of hand with trying to finish various IESG related tasks.= Thanks, Alexey! You're doing much better than I am on AD reports, but at least I'm almost caught up on email... Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050503070302030900040203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMw MjE2MzE0NlowIwYJKoZIhvcNAQkEMRYEFB6a+If8GbUfjSxgT0riTtUiLxRfMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCWsbM8tpyithpikEe/NAwJEbfagq7OGYZitu7H5gktvd6/yZ8E0sXimU/k FQcW4G6OmT/zbJxboMu6NRWZ35bSGHqDtbUt2d8zarN7Jm5V3PwtrjWDl+jY96tfYa/xkpKm yNGwDocly0T3dDtxR3OwBG7gT3cbr8mnlGQHxfrTTryjwbFQff+p20Esk/nnzjb5q+Vqhngq xhLniKbubiyH7+zzlTavVnPo4h7FRrNm5Zk9RqYEmxoghn7k5+kL06SKHMtGIYY0Pq9VBYhv 8ynLgUZd/v5t9wwgUVwd5xYSTL3ocIqkhAn8wWLvkqkLNsPMTjpwg+JDelEdonWs5DQuAAAA AAAA --------------ms050503070302030900040203-- From alexey.melnikov@isode.com Thu Mar 3 08:13:57 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5BE3A6A06 for ; Thu, 3 Mar 2011 08:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMab-KFB-Fvk for ; Thu, 3 Mar 2011 08:13:56 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 80D5C3A69ED for ; Thu, 3 Mar 2011 08:13:56 -0800 (PST) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 3 Mar 2011 16:15:03 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D6FBE4D.10602@isode.com> Date: Thu, 03 Mar 2011 16:14:05 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 16:13:57 -0000 I am working with the rest of IESG on issuing the following IESG statement: ------------------------ BCP 13 (currently RFC 4288) specifies that Media Type registrations from other Standards Organizations (SDOs) can be submitted directly to IESG for approval, without a need to submit an Internet Draft and to ask an Area Director to shepherd its publication. While this IESG statement doesn't change that, IESG would like to encourage other SDOs to submit their registriation as Internet Drafts, as this tends to improve quality of final registrations, and sometimes even improves quality of the underlying format itself. IESG would also like to remind that as per BCP 13, other SDOs are not excluded from the requirement to post their Media Type registrations for 2 weeks review on the ietf-types@iana.org mailing list. When reviewing Media Type registrations IESG checks that the Media Type registration template is correct and reasonably complete. When reviewing Media Type registrations (including those from other SDOs) IESG also checks that references to documents describing details of the Media Type format are stable, i.e. - a) the references are reasonably long lived and - b1) the document pointed to by the reference is either immutable (i.e. if an updated document is approved for publication by the SDO, then it will be posted at a different URI) or can only change in insignificant ways (e.g. to correct typos, clarify text without changing the media type format, etc.) - b2) the media type format contains some internal fields for versioning that can be used to distingiush 2 incompatible versions of the Media Type format - b3) there is some guaranty that future revisions of the format are going to be backward compatible Note that the choices b1, b2 and b3 are not mutually exclusive. If the Media Type format specification has licensing restrictions, the Internet Assigned Numbers Authority (IANA) must be granted express permission to make archival copies of the Media Type format specification, and to redistribute such a copy in the event that the link to the format specification becomes inoperative and it is determined that it will not be repaired. ------------------------ Please let me know if you have any corrections or major objections to this before March 17th. Thanks, Alexey From stpeter@stpeter.im Thu Mar 3 08:44:30 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85AAD3A69FF for ; Thu, 3 Mar 2011 08:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9Rtc3yXCZKg for ; Thu, 3 Mar 2011 08:44:29 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3BE053A67F1 for ; Thu, 3 Mar 2011 08:44:29 -0800 (PST) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 58E39400F6 for ; Thu, 3 Mar 2011 10:05:05 -0700 (MST) Message-ID: <4D6FC5AF.8060503@stpeter.im> Date: Thu, 03 Mar 2011 09:45:35 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020302010904070303010908" Subject: [apps-discuss] timezone database maintenance X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 16:44:30 -0000 This is a cryptographically signed message in MIME format. --------------ms020302010904070303010908 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Apps Folks, We need to finish our work on draft-lear-iana-timezone-database and decide if we will pursue the approach outlined in that document, so that Mr. David Olson (maintainer of the timezone database) can work for a while within the new processes before starting his well-deserved retireme= nt. I plan to issue an IETF Last Call on that I-D soon after IETF 80. To expedite the conversation, I encourage those who care about future management of the timezone database to weigh in on the apps-discuss list. In addition, I have reserved a room from 08:00 to 09:00 on Wednesday, March 30 at the IETF meeting in Prague, so please add that time slot to your calendar if you wish to participate. Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020302010904070303010908 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMw MzE2NDUzNVowIwYJKoZIhvcNAQkEMRYEFNXhZofhXsvnIcpP2ugDUgCF5BWbMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBaNHSlr5y8XP4vkYtJkLbvivJKQ7UC7BaVSg/m9nu6kEbpt6EhZoevpoWK h+G3ZtbIf+cwgKS02z3tS2uOW5j/ACRnAw0QX+PJS+IOczGtazPGfnlF8S7vT215bKxxL0+K QY4auJQ3ujqCXd6/NX7PguRTgRW6mC8wcENcsTl2s9XASTPfV1MEMA4OZRC+QepA7HXDe6NX DDRpwhgaxe6Zstm+OoGJRpIlgH7CdmNHrZTjx7IztMbUg0dtdtMmmNRqn2mVfke+UoxsWKjQ ZZR38mPX9bOz3IP8EjaoJCwybtOGDCBHSZdhKp23AByIe9qFLwnOAqt9pxnd04nvvW9YAAAA AAAA --------------ms020302010904070303010908-- From marc.blanchet@viagenie.ca Thu Mar 3 08:57:51 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F2F3A6A00 for ; Thu, 3 Mar 2011 08:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nrhq3gH4wg4z for ; Thu, 3 Mar 2011 08:57:49 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 60D033A69FF for ; Thu, 3 Mar 2011 08:57:49 -0800 (PST) Received: from h109.viagenie.ca (h109.viagenie.ca [206.123.31.109]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3E83B20D08; Thu, 3 Mar 2011 11:58:56 -0500 (EST) Message-ID: <4D6FC8CF.20705@viagenie.ca> Date: Thu, 03 Mar 2011 11:58:55 -0500 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: apps-discuss@ietf.org, draft-lear-iana-timezone-database@tools.ietf.org References: <4D6FC5AF.8060503@stpeter.im> In-Reply-To: <4D6FC5AF.8060503@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] timezone database maintenance X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 16:57:51 -0000 comments: A) XML IANA - IANA has been converting its "old" registries to XML native format. - for new registries, XML is used as native format. - TZ database has its own format. - wonder if it would be relevant to have IANA do the registry in XML (as others and to be managed by the same tools) and then convert to the TZ database format. B) draft shall be updated before IETF last call on the warning of community concensus. ie. "ATTENTION: This memo contains a DRAFT proposal for the IANA to assume operational responsibilities relating to the management of the Timezone (TZ) Database. The authors seek comment and review of this proposal. No action will be taken without rough consensus of the TZ community." Should be either changed, updated or removed. C) Reference code. I'm not sure IANA is the right place to archive software code. why not have a separate web site/sourceforge/google code/... place for managing this? Marc. Le 11-03-03 11:45, Peter Saint-Andre a écrit : > Dear Apps Folks, > > We need to finish our work on draft-lear-iana-timezone-database and > decide if we will pursue the approach outlined in that document, so that > Mr. David Olson (maintainer of the timezone database) can work for a > while within the new processes before starting his well-deserved retirement. > > I plan to issue an IETF Last Call on that I-D soon after IETF 80. To > expedite the conversation, I encourage those who care about future > management of the timezone database to weigh in on the apps-discuss > list. In addition, I have reserved a room from 08:00 to 09:00 on > Wednesday, March 30 at the IETF meeting in Prague, so please add that > time slot to your calendar if you wish to participate. > > Thanks! > > Peter > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From cyrus@daboo.name Thu Mar 3 09:26:22 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7923A67A5 for ; Thu, 3 Mar 2011 09:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BL56lIJqrypC for ; Thu, 3 Mar 2011 09:26:21 -0800 (PST) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 7A33B3A6A17 for ; Thu, 3 Mar 2011 09:25:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 8F36D1BF9778F; Thu, 3 Mar 2011 12:26:58 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzK3z-5h4V6b; Thu, 3 Mar 2011 12:26:57 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id E39451BF97782; Thu, 3 Mar 2011 12:26:56 -0500 (EST) Date: Thu, 03 Mar 2011 12:26:53 -0500 From: Cyrus Daboo To: Marc Blanchet , apps-discuss@ietf.org, draft-lear-iana-timezone-database@tools.ietf.org Message-ID: In-Reply-To: <4D6FC8CF.20705@viagenie.ca> References: <4D6FC5AF.8060503@stpeter.im> <4D6FC8CF.20705@viagenie.ca> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2286 Subject: Re: [apps-discuss] timezone database maintenance X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 17:26:22 -0000 Hi Marc, --On March 3, 2011 11:58:55 AM -0500 Marc Blanchet wrote: > A) XML IANA > - IANA has been converting its "old" registries to XML native format. > - for new registries, XML is used as native format. > - TZ database has its own format. > - wonder if it would be relevant to have IANA do the registry in XML (as > others and to be managed by the same tools) and then convert to the TZ > database format. CalConnect has been working on an XML representation for timezone data, but I think it is fair to say at this time we consider this premature. One of the key things CalConnect wants to do is promote use of a Timezone Service protocol (draft-douglass-timezone-service about to be updated) to allow for timely, secure, reliable update of timezone information. Right now that is focussed primarily on iCalendar timezone data, but we intend to allow it to be used by anyone that needs timezone information, including OS's (i.e. allow "live" updates to zoneinfo files rather than requiring OS 'patches'). What I think we need to do now is treat the Olson data format as "normative" and then work on defining a solid XML representation (with hopefully a straightforward mapping to Olson data). We can then make that available as an alternative format and allow tools to adopt it, and once we have good adoption then move to have that be the normative format. However, that is something that will need more time to develop than I think we have before we need IANA to start managing the Olson process (given what I know about the length of the IETF process). > C) Reference code. > > I'm not sure IANA is the right place to archive software code. why not > have a separate web site/sourceforge/google code/... place for managing > this? That would probably need additional text describing how that is managed (who has commit rights, how would those be administered/changed etc) and would be a significant change to the current Olson process. It may be reasonable to put the code up on a source site, but if we do that, I do think it is important that appropriate "snapshots" be tied to the updates to the IANA data - so I still think IANA ought to maintain a tarball of the code appropriate to the actual data. -- Cyrus Daboo From fanf2@hermes.cam.ac.uk Thu Mar 3 11:13:19 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A2903A6A06 for ; Thu, 3 Mar 2011 11:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xz-FXW0gDY1u for ; Thu, 3 Mar 2011 11:13:18 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by core3.amsl.com (Postfix) with ESMTP id 238723A6843 for ; Thu, 3 Mar 2011 11:13:16 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39330) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1PvDyh-0002Gh-Qk (Exim 4.72) for apps-discuss@ietf.org (return-path ); Thu, 03 Mar 2011 19:14:23 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PvDyh-0006en-8x (Exim 4.67) for apps-discuss@ietf.org (return-path ); Thu, 03 Mar 2011 19:14:23 +0000 Date: Thu, 3 Mar 2011 19:14:23 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: apps-discuss@ietf.org In-Reply-To: <4D6FC5AF.8060503@stpeter.im> Message-ID: References: <4D6FC5AF.8060503@stpeter.im> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: [apps-discuss] draft-lear-iana-timezone-database X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 19:13:19 -0000 The current draft looks pretty good to me. A few small questions: Is the shouty mustard supposed to mean anything different from normal English usage? Section 3: The word "key" is used to mean both a cryptographic key and a TZ name. Is there a reason for not using the term "TZ name" or "time zone name"? Section 6: Should it be made clear in this section that contributions to the code are presumed to be in the public domain or under equivalently liberal licencing terms whether or not the contributions are made via the mailing list? Or is section 7 enough? Sections 7 and 8: Should "database" be expanded to "database and reference code" throughout? Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Northeast 5 to 7. Moderate or rough. Showers. Good. From lear@cisco.com Thu Mar 3 11:21:44 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963A83A69A4 for ; Thu, 3 Mar 2011 11:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.582 X-Spam-Level: X-Spam-Status: No, score=-110.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApGmQSeFUyXZ for ; Thu, 3 Mar 2011 11:21:43 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 98DD03A681A for ; Thu, 3 Mar 2011 11:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1763; q=dns/txt; s=iport; t=1299180170; x=1300389770; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=USA6EfHgRrOm0TglNzmCjHrHCrnQ3TTVBUzR7I81HOo=; b=ZVbHDuAPUCvgECqvAHUQBydCxFG7Ja2qcUAwO+6n4AAW6Z67XBa4qK9R xFYXJHnRhvO7KaxO2khV1BsB95NX0W459w5jHyZj9HdkrvtfkNiUr07VE Mby/bVGu1LgysaMYUwhX+Mq2eqF+9R1J8a/735yIUjWiKf/UqrICRCmH7 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIEAGN5b02Q/khMgWdsb2JhbACEKqI8FQEBFiIlohyLCpETgSeDRHYEjCw X-IronPort-AV: E=Sophos;i="4.62,259,1297036800"; d="scan'208";a="77964397" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 03 Mar 2011 19:22:49 +0000 Received: from dhcp-10-55-82-239.cisco.com (dhcp-10-55-82-239.cisco.com [10.55.82.239]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p23JMmaV000517; Thu, 3 Mar 2011 19:22:48 GMT Message-ID: <4D6FEA6F.8040000@cisco.com> Date: Thu, 03 Mar 2011 20:22:23 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Tony Finch References: <4D6FC5AF.8060503@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-lear-iana-timezone-database X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 19:21:44 -0000 Tony, Marc, Cyrus, Thank you for your comments. On 3/3/11 8:14 PM, Tony Finch wrote: > The current draft looks pretty good to me. A few small questions: > > Is the shouty mustard supposed to mean anything different from normal > English usage? I searched the draft but couldn't find shouty mustard ;-) I'd gladly accept editorial changes to improve language though. No need to send those to the list. > Section 3: > > The word "key" is used to mean both a cryptographic key and a TZ name. > Is there a reason for not using the term "TZ name" or "time zone name"? No. There is not. I will go with TZ name and define it above. > Section 6: > > Should it be made clear in this section that contributions to the code are > presumed to be in the public domain or under equivalently liberal > licencing terms whether or not the contributions are made via the mailing > list? Or is section 7 enough? And this goes to Marc's point C) as well. The goal here is to assume the current responsibilities of the TZ coordinator which includes some code. The database itself is in the public domain. So is much of the code, but not all. Thus there is a distinction. > Sections 7 and 8: > > Should "database" be expanded to "database and reference code" throughout? I'll review each use, but there are some differences as I noted. Marc: > A) XML IANA The database is currently sucked down and used by many many companies, and it must be maintained in its current form. New forms are fine. Even new normative forms! But this form can't go away. > B) draft shall be updated before IETF last call on the warning of > community concensus. ie. Indeed. Will remove. Thank you again for your contributions! Eliot From marc.blanchet@viagenie.ca Thu Mar 3 11:27:29 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20BAC3A6840 for ; Thu, 3 Mar 2011 11:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZn9ynEOZxt6 for ; Thu, 3 Mar 2011 11:27:28 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id B56D43A681B for ; Thu, 3 Mar 2011 11:27:27 -0800 (PST) Received: from h109.viagenie.ca (h109.viagenie.ca [206.123.31.109]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 87A942151D; Thu, 3 Mar 2011 14:28:34 -0500 (EST) Message-ID: <4D6FEBE2.1000309@viagenie.ca> Date: Thu, 03 Mar 2011 14:28:34 -0500 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Eliot Lear References: <4D6FC5AF.8060503@stpeter.im> <4D6FEA6F.8040000@cisco.com> In-Reply-To: <4D6FEA6F.8040000@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-lear-iana-timezone-database X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 19:27:29 -0000 Le 11-03-03 14:22, Eliot Lear a écrit : > Tony, Marc, Cyrus, > >> > Marc: >> A) XML IANA > > The database is currently sucked down and used by many many companies, > and it must be maintained in its current form. I know. > New forms are fine. > Even new normative forms! But this form can't go away. What I was trying to say is the following: - IANA do keep the data in native XML format - IANA converts XML native to the current file format. - both formats are available from IANA web sites and are in sync. that way, IANA continues with its XML infrastructure and have the TZ community keep the same file format as before. Marc. -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From fanf2@hermes.cam.ac.uk Thu Mar 3 11:46:42 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27CD23A69FA for ; Thu, 3 Mar 2011 11:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLiM3TnmQMl1 for ; Thu, 3 Mar 2011 11:46:41 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id E4DBC3A6843 for ; Thu, 3 Mar 2011 11:46:40 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:43845) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1PvEV2-0007AL-rL (Exim 4.72) (return-path ); Thu, 03 Mar 2011 19:47:48 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PvEV2-0003AW-Gw (Exim 4.67) (return-path ); Thu, 03 Mar 2011 19:47:48 +0000 Date: Thu, 3 Mar 2011 19:47:48 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Eliot Lear In-Reply-To: <4D6FEA6F.8040000@cisco.com> Message-ID: References: <4D6FC5AF.8060503@stpeter.im> <4D6FEA6F.8040000@cisco.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-lear-iana-timezone-database X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 19:46:42 -0000 On Thu, 3 Mar 2011, Eliot Lear wrote: > > > Section 6: > > > > Should it be made clear in this section that contributions to the code are > > presumed to be in the public domain or under equivalently liberal > > licencing terms whether or not the contributions are made via the mailing > > list? Or is section 7 enough? > > And this goes to Marc's point C) as well. The goal here is to assume > the current responsibilities of the TZ coordinator which includes some > code. The database itself is in the public domain. So is much of the > code, but not all. Thus there is a distinction. Right. But it gets very complicated if you try to say that if a contributor is making a contribution to the Berkeley licenced code then their licence must also be Berkeley licenced but not otherwise. Do they get to add their copyright line to the Berkeley code? etc. If all contributions are unambigously public domain then they can be freely added to the existing code regardless of the existing code's licence. So I'm making a distinction between the licence in contributions and the licence of the (parts of) the collaborative work as a whole. Tony. -- f.anthony.n.finch http://dotat.at/ Rockall: Variable 3 or 4, becoming southwesterly 5 for a time in northwest Rockall. Moderate or rough. Occasional rain or drizzle. Moderate, occasionally poor. From marc.blanchet@viagenie.ca Thu Mar 3 11:48:44 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97563A6A06 for ; Thu, 3 Mar 2011 11:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xo+Po4b4OUx for ; Thu, 3 Mar 2011 11:48:43 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 7D7A13A690F for ; Thu, 3 Mar 2011 11:48:43 -0800 (PST) Received: from h109.viagenie.ca (h109.viagenie.ca [206.123.31.109]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8FDFF2151D for ; Thu, 3 Mar 2011 14:49:50 -0500 (EST) Message-ID: <4D6FF0DD.7040006@viagenie.ca> Date: Thu, 03 Mar 2011 14:49:49 -0500 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4D6FC5AF.8060503@stpeter.im> <4D6FEA6F.8040000@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] draft-lear-iana-timezone-database X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 19:48:44 -0000 Le 11-03-03 14:47, Tony Finch a écrit : > On Thu, 3 Mar 2011, Eliot Lear wrote: >> >>> Section 6: >>> >>> Should it be made clear in this section that contributions to the code are >>> presumed to be in the public domain or under equivalently liberal >>> licencing terms whether or not the contributions are made via the mailing >>> list? Or is section 7 enough? >> >> And this goes to Marc's point C) as well. The goal here is to assume >> the current responsibilities of the TZ coordinator which includes some >> code. The database itself is in the public domain. So is much of the >> code, but not all. Thus there is a distinction. > > Right. But it gets very complicated if you try to say that if a > contributor is making a contribution to the Berkeley licenced code then > their licence must also be Berkeley licenced but not otherwise. Do they > get to add their copyright line to the Berkeley code? etc. > > If all contributions are unambigously public domain then they can be > freely added to the existing code regardless of the existing code's > licence. > > So I'm making a distinction between the licence in contributions and the > licence of the (parts of) the collaborative work as a whole. I continue to think that archiving and managing software should not be done by IANA, but some third party over a forge site. Marc. > > Tony. -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From vumip1@gmail.com Sat Mar 5 12:50:17 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B93DA3A6AC0 for ; Sat, 5 Mar 2011 12:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Wtja15l1PmM for ; Sat, 5 Mar 2011 12:50:16 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id CFBC03A6830 for ; Sat, 5 Mar 2011 12:50:15 -0800 (PST) Received: by yxk30 with SMTP id 30so1441081yxk.31 for ; Sat, 05 Mar 2011 12:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Mdqc8ZkBSHElEoCtfTliLWYGXS5Tk4oua9LdLPu79uQ=; b=O4JmwwxX8tfvKsPD/Cqh9rwhx4cYbkSeNkir3flSKZZTgkiWLt+nRKPpZjA47CawmF lfF9Jb25bqoMxVjc6u+zrVgx/641jXxUBbF8VUWIUdNYKrG0QhoVCC188jBVsEc6+Ge4 vHaVy07FWUUmhgGEb07GCM9p5LCnxR46XImpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fJPyDU25qP5GG3jA1sk0QL9nSxTbHE52U/85qQnHC6v9JbxhwyvAYp8wLoHwpsiAEr Xf4zL+RpoK22JWj79N7glA6x+S3Nn+rmqTR0WBD6TNcRpBjMn1BTBPu8i6PRWmJ5nrUZ UBbjh+mtvyioyYWGO9NhKQNojLqHtEi0s2VZ8= MIME-Version: 1.0 Received: by 10.151.29.17 with SMTP id g17mr2723151ybj.21.1299358285677; Sat, 05 Mar 2011 12:51:25 -0800 (PST) Received: by 10.147.98.18 with HTTP; Sat, 5 Mar 2011 12:51:25 -0800 (PST) In-Reply-To: References: Date: Sat, 5 Mar 2011 15:51:25 -0500 Message-ID: From: Bhumip Khasnabish To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=000e0cd2901a0dc4c9049dc26d28 Cc: "So, Ning" , meng.yu@zte.com.cn, wang.jun17@zte.com.cn, Suren Karavettil Subject: [apps-discuss] proposal for Virtual desktop infrastructure (VDI) work in APP area X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 20:50:17 -0000 --000e0cd2901a0dc4c9049dc26d28 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear All, Based on multiple discussions that we had in clouds@ietf.org and suggestion= s / recommendations from IETF APP area AD (Peter), we plan to focus former CloudApps work in th= e proposed virtual desktop infrastructure (VDI) area. Below pls find the draft charter we are developing based on participation and contribution of those who are interested in this. The clear and present trend of end-user device convergence merges multiple information processing devices, communication devices, and entertainment devices into a single unit. This highly converged device is supported by the Virtual Desktop Infrastructure (VDI) in the virtual on-demand computing and networking environment (commonly referred to as Cloud environment). VDI consists of the following three basic functional components: Virtual Desktop Client (VDC, the converged end-user device), the Virtual Desktop Agent (VDA, the control software residing in a virtual machine hosted in a data center), and a set of protocols connecting them together to deliver th= e desired services. +---------------------------+ | +-----------------------+ | +-----------+ VDI protocol | | +------------------+ | | | VDI Client|----------------+ + | Virtual Desktop | | | +-----------+ | | Agent | | | | | +------------------+ | | | | Guest OS | | | +-----------------------+ | | Virtual Machine | | Hosted in a Data Center | +---------------------------+ Currently there are no standard VDI protocols. This lack of standard protocol creates friction and barrier in solution development, deployment, and service management. In addition, the limited available proprietary solutions do not fully address the issues caused by service mobility and access (both nomadic and wireless). Furthermore, many critical functional requirements for VDI such as service availability/distribution, scalability= , security, and manageability are not addressed in a way to support interoperability. The proposed VDI WG focuses on the requirements and protocol development activities that are directly associated with virtual desktop infrastructure= . The background materials related to SDO survey, reference framework, work items gap, and security gap can be found in the already published/work-in-progress (to be completed soon) drafts as cited at the en= d of this document. The proposed work items for the VDI WG are as listed below. 1) Produce a VDI Problem Statement and Resolution document listing the technical issues of the existing VDI systems, proposing reference architecture, and defining the scope of VDI protocol standard. 2) Produce a VDI Requirements document that defines the functional and operational requirements of the VDI protocol. 3) Produce a detailed VDI Protocol Specification. 4) Once the base protocol specification is complete, re-charter the WG to produce various VDI protocol extensions to support application-specific areas such as access security, additional video/audio compression mechanism= , service mobility, profile/personality adjustment, and context-awareness. *References and VDI-related drafts:* =D8 http://tools.ietf.org/id/draft-wang-clouds-vdi-problem-statement-00.tx= t =D8 http://www.ietf.org/id/draft-cloud-log-00.txt =D8 http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/Johnston-IE= TF-78-Clouds-bar-BoF-Std-Gap-28July10.pdf =D8 http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/Protocol%20= Considerations%20for%20Workload%20Mobility%20in%20Clouds.txt =D8 http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/draft-rfc-s= eamless-Cloud-masum-01.txt =D8 Karavettil-et-al-IETF-VDI-Draft-v1-03042011 *Background References and drafts:* =D8 http://tools.ietf.org/id/draft-ma-clouds-vdi-survey-00.txt =D8 http://tools.ietf.org/id/draft-khasnabish-cloud-sdo-survey-00.txt =D8 http://tools.ietf.org/id/draft-khasnabish-cloud-reference-framework-00.txt =D8 http://tools.ietf.org/id/draft-khasnabish-cloud-industry-workitems-survey-0= 0.txt =D8 http://tools.ietf.org/id/draft-so-vepc-01.txt =D8 http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/Karavettil-= et-al-IETF-Cloud-Security-Framework-11Feb2011_v2.pdf All of the drafts and presentations are available at the following site: http://trac.tools.ietf.org/area/app/trac/wiki/Clouds We look forward to your further comments and suggestions. Many thanks. Best Regards. Bhumip Khasnabish (Mobile:+001-781-752-8003, vumip1@gmail.com) http://www.linkedin.com/in/bhumipkhasnabish --000e0cd2901a0dc4c9049dc26d28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear All,
=A0=
Based on multiple discus= sions that we had in c= louds@ietf.org and suggestions / recommendations
from IETF APP area AD (P= eter), w= e plan to focus former CloudApps work in the proposed
virtual desktop infrastr= ucture (VDI) area.=A0
=A0
Below pls find the draft chart= er we are developing based on participation and contribution of those
who are interested in this.
=A0

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">The clea= r and present trend of end-user device convergence merges multiple informat= ion processing devices, communication devices, and entertainment devices in= to a single unit.=A0 This highly converged device is supported= by the Virtual Desktop Infrastructure (VDI) in the virtual on-demand compu= ting and networking environment (commonly referred to as Cloud environment)= . VDI consists of the following three basic functional components:=A0= Virtual Desktop Client (VDC, the converged end-user device), the Vi= rtual Desktop Agent (VDA, the control software residing in a virtual machin= e hosted in a data center), and a set of protocols connecting them together= to deliver the desired services.=A0=A0=A0=A0=A0=A0=A0=A0=A0 <= /span>

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">=A0

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">=A0

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">= =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0+-------------------= --------+

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | +-----------------------+ |

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">= =A0=A0=A0=A0=A0=A0=A0 +-----------+=A0 VDI protocol =A0| | +------------------+=A0 | |=A0 <= /span>

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">= =A0=A0=A0=A0=A0=A0=A0 | VDI Client|----------------+ + | Virtual Des= ktop=A0 |=A0 | |

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">= =A0=A0=A0=A0=A0=A0=A0 +-----------+=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 =A0| |=A0=A0=A0=A0=A0=A0 A= gent=A0=A0=A0=A0 =A0=A0=A0|=A0= | |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| | +------------------+=A0 | |

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | |=A0=A0=A0=A0=A0 Gu= est OS=A0=A0=A0=A0=A0=A0=A0=A0 | |

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">= =A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| +-----------------= ------+ |

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0 Virtual Machi= ne=A0=A0=A0=A0=A0=A0=A0=A0 |

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Hosted in a Data Center=A0= =A0 |

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +---------------------------+

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">=A0

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">Currentl= y there are no standard VDI protocols.=A0 This lack of standar= d protocol creates friction and barrier in solution development, deployment= , and service management.=A0 In addition, the limited availabl= e proprietary solutions do not fully address the issues caused by service m= obility and =A0=A0access (both nomadic and wireless).=A0= Furthermore, many critical functional requirements for VDI such as = service availability/distribution, scalability, security, and manageability= are not addressed in a way to support interoperability.

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">=A0

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">The prop= osed VDI WG focuses on the requirements and protocol development activities= that are directly associated with virtual desktop infrastructure.=A0= The background materials related to SDO survey, reference framework= , work items gap, and security gap can be found in the already published/wo= rk-in-progress (to be completed soon) drafts as cited at the end of this do= cument.=A0=A0=A0

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">The prop= osed work items for the VDI WG are as listed below.

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">=A0

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">= =A0

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">1) Produ= ce a VDI Problem Statement and Resolution document listing the technical is= sues of the existing VDI systems, proposing reference architecture, and def= ining the scope of VDI protocol standard.

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">=A0

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">2) Produ= ce a VDI Requirements document that defines the functional and operational = requirements of the VDI protocol.

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">=A0

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">3) Produ= ce a detailed VDI Protocol Specification.

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">=A0

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">4) Once = the base protocol specification is complete, re-charter the WG to produce v= arious VDI protocol extensions to support application-specific areas such a= s access security, additional video/audio compression mechanism, service mo= bility, profile/personality adjustment, and context-awareness.

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">=A0

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">=A0

<= u>Refer= ences and VDI-related drafts:

=D8=A0 http://tools.ietf.org/id/draft-wang-clouds-vdi-problem-sta= tement-00.txt

=D8=A0 http://ww= w.ietf.org/id/draft-cloud-log-00.txt

=D8=A0 http://trac.t= ools.ietf.org/area/app/trac/attachment/wiki/Clouds/Johnston-IETF-78-Clouds-= bar-BoF-Std-Gap-28July10.pdf

=D8=A0 http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/Proto= col%20Considerations%20for%20Workload%20Mobility%20in%20Clouds.txt

=D8=A0 http://trac.tools.ietf.org/a= rea/app/trac/attachment/wiki/Clouds/draft-rfc-seamless-Cloud-masum-01.txt

=D8=A0 Karavettil= -et-al-IETF-VDI-Draft-v1-03042011

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">=A0

<= u>Backg= round References and drafts:

=D8=A0 http://tools.ietf.org/id/draft-ma-clouds-vdi-survey-00.txt <= /p>

=D8=A0 http://tools.ietf.org/id/draft-khasnabish-cloud-sdo-survey-00.t= xt

=D8=A0 http://tools.ietf.org/id/draft-khasnabish-cloud-referen= ce-framework-00.txt

=D8=A0 http://tools.ietf.org/id/draft-khasnabish-cloud-i= ndustry-workitems-survey-00.txt

=D8=A0 http://to= ols.ietf.org/id/draft-so-vepc-01.txt

=D8=A0 ht= tp://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/Karavettil-et= -al-IETF-Cloud-Security-Framework-11Feb2011_v2.pdf

<= span style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">=A0

<= span>All of the drafts and presentations are available at = the following site:

<= span>http://trac.tools.ietf.org/area/app/trac/wiki= /Clouds


We=A0 look forward to your further comments and sugg= estions.
=A0
Many thanks.
Best Regards.

Bhumip Khasnabish (Mobile:+001-781-752-8003, vumip1@gmail.com)
= h= ttp://www.linkedin.com/in/bhumipkhasnabish

=A0
=A0
--000e0cd2901a0dc4c9049dc26d28-- From paul.hoffman@vpnc.org Sat Mar 5 15:10:16 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE313A6A32 for ; Sat, 5 Mar 2011 15:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.872 X-Spam-Level: X-Spam-Status: No, score=-101.872 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAIciLNLTtwg for ; Sat, 5 Mar 2011 15:10:15 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 5DF333A67ED for ; Sat, 5 Mar 2011 15:10:15 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p25NBKNs099242 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 5 Mar 2011 16:11:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D72C318.7090303@vpnc.org> Date: Sat, 05 Mar 2011 15:11:20 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Suren Karavettil , "So, Ning" , wang.jun17@zte.com.cn, meng.yu@zte.com.cn Subject: Re: [apps-discuss] proposal for Virtual desktop infrastructure (VDI) work in APP area X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 23:10:17 -0000 First off, I think this work could be very useful both in the short and long run. I am swimming in these issues today in my work, so please do not take the response below as diminishing the need. I question whether or not the IETF would be the best place for this. I say that not because "SDO X would be better than the IETF" because if that were the case, SDO X would have done so by now. However, most of the interesting work here is, in fact, an API. Note that I am *not* one of the people who says "the IETF { doesn't / can't } do APIs"; I think we do/can as long as we are upfront about it. In specific (a fixed chart): +---------------------------+ | +-----------------------+ | +-----------+ VDI protocol | | +------------------+ | | | VDI Client|----------------+ + | Virtual Desktop | | | +-----------+ | | | Agent | | | | | +------------------+ | | | | Guest OS | | | +-----------------------+ | | Virtual Machine | | Hosted in a Data Center | +---------------------------+ Given that the text of the proposed charter says that the protocol would be between the VDI Client and the Virtual Desktop Agent", which might be software running on a Guest OS with no network connectivity, this will be an API unless there is a requirement that the Guest OS has network connectivity at a known and predictable address, and that the Virtual Machine (actually, the host system) also has network connectivity at a known and predictable address, and neither is firewalled from the VDI client. A different model would be that the VDI Client has a new protocol to talk to the host system, and that the host system has an API for talking to the Guest OS in a way that would reach the Virtual Desktop Agent. This model has some advantages over the narrow one in the charter. For example, the protocol would allow control over Guest OSs, such as "start up machine X" and "send text to the console on machine X". These will work even if the Guest OS does not support the API, or if it does not currently have network connectivity. The proposed WG could come up with requirements for both the client-to-host protocol and the API between the host and the desktop agent, and the two could clearly have some good interactions. (And for those of you who want to come up to speed on the terminology used in virtualization and some of the security issues, please see NIST SP 800-125 . --Paul Hoffman, Director --VPN Consortium From vumip1@gmail.com Fri Mar 4 08:12:12 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195A73A6812 for ; Fri, 4 Mar 2011 08:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.418 X-Spam-Level: X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0Aa9Mw5ki3t for ; Fri, 4 Mar 2011 08:12:10 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id DC5FE3A67B1 for ; Fri, 4 Mar 2011 08:12:09 -0800 (PST) Received: by yic13 with SMTP id 13so980881yic.31 for ; Fri, 04 Mar 2011 08:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=yFee68Wge1G7X3nMI2f6+KIhEaYIV2fcudYZx6oe5w8=; b=PWUM80X4B20d2bPGvXQRCXUsL+kCNE04i/kmRKH3D8Ov8SvjKib2rtjdHC8M9qDmGu SD5SRNKQ5yWRN4RtrhiOMj1H1hwA/YXKKM+pk13Fgdp+y5Aedb4za3sQjO1rbMAxlRLI 1kf/wqPPTckUwjL6S1FCnLcsNfnWNuzERq4P0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=ixcIMQ76VG9ZiyEwSlmYNb6IeH1oYU6BXC+buKgkMv9FPNvLk5RxOSLfWS66DphC7+ 8fd5/Rg2oR8Ypb+Atox/XSSKYa8boyFAFNpyVHDzIrNKsnSWo57iOTVV1UtLj6J0CBPR bdBmuu4WUGffw5E99lv/3OPoAX00xBSwkeZ9s= MIME-Version: 1.0 Received: by 10.146.114.26 with SMTP id m26mr1190936yac.30.1299255198269; Fri, 04 Mar 2011 08:13:18 -0800 (PST) Received: by 10.147.98.18 with HTTP; Fri, 4 Mar 2011 08:13:18 -0800 (PST) Date: Fri, 4 Mar 2011 11:13:18 -0500 Message-ID: From: Bhumip Khasnabish To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=000e0cd5645290c171049daa6c5e X-Mailman-Approved-At: Sat, 05 Mar 2011 15:40:27 -0800 Cc: "So, Ning" , meng.yu@zte.com.cn, wang.jun17@zte.com.cn, Suren Karavettil Subject: [apps-discuss] proposal for Virtual desktop infrastructure (VDI) work in APP area X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 16:12:12 -0000 --000e0cd5645290c171049daa6c5e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear All, Based on multiple discussions that we had in clouds@ietf.org and suggestion= s / recommendations from IETF APP area AD (Peter), we plan to focus former CloudApps work in th= e proposed virtual desktop infrastructure (VDI) area. Below pls find the draft charter we are developing based on participation and contribution of those who are interested in this. The clear and present trend of end-user device convergence merges multiple information processing devices, communication devices, and entertainment devices into a single unit. This highly converged device is supported by the Virtual Desktop Infrastructure (VDI) in the virtual on-demand computing and networking environment (commonly referred to as Cloud environment). VDI consists of the following three basic functional components: Virtual Desktop Client (VDC, the converged end-user device), the Virtual Desktop Agent (VDA, the control software residing in a virtual machine hosted in a data center), and a set of protocols connecting them together to deliver th= e desired services. +---------------------------+ | +-----------------------+ | +-----------+ VDI protocol | | +------------------+ | | | VDI Client|----------------+ + | Virtual Desktop | | | +-----------+ | | Agent | | | | | +------------------+ | | | | Guest OS | | | +-----------------------+ | | Virtual Machine | | Hosted in a Data Center | +---------------------------+ Currently there are no standard VDI protocols. This lack of standard protocol creates friction and barrier in solution development, deployment, and service management. In addition, the limited available proprietary solutions do not fully address the issues caused by service mobility and access (both nomadic and wireless). Furthermore, many critical functional requirements for VDI such as service availability/distribution, scalability= , security, and manageability are not addressed in a way to support interoperability. The proposed VDI WG focuses on the requirements and protocol development activities that are directly associated with virtual desktop infrastructure= . The background materials related to SDO survey, reference framework, work items gap, and security gap can be found in the already published/work-in-progress (to be completed soon) drafts as cited at the en= d of this document. The proposed work items for the VDI WG are as listed below. 1) Produce a VDI Problem Statement and Resolution document listing the technical issues of the existing VDI systems, proposing reference architecture, and defining the scope of VDI protocol standard. 2) Produce a VDI Requirements document that defines the functional and operational requirements of the VDI protocol. 3) Produce a detailed VDI Protocol Specification. 4) Once the base protocol specification is complete, re-charter the WG to produce various VDI protocol extensions to support application-specific areas such as access security, additional video/audio compression mechanism= , service mobility, profile/personality adjustment, and context-awareness. *References and VDI-related drafts:* =D8 http://tools.ietf.org/id/draft-wang-clouds-vdi-problem-statement-00.tx= t =D8 http://www.ietf.org/id/draft-cloud-log-00.txt =D8 http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/Johnston-IE= TF-78-Clouds-bar-BoF-Std-Gap-28July10.pdf =D8 http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/Protocol%20= Considerations%20for%20Workload%20Mobility%20in%20Clouds.txt =D8 http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/draft-rfc-s= eamless-Cloud-masum-01.txt =D8 Karavettil-et-al-IETF-VDI-Draft-v1-03042011 *Background References and drafts:* =D8 http://tools.ietf.org/id/draft-ma-clouds-vdi-survey-00.txt =D8 http://tools.ietf.org/id/draft-khasnabish-cloud-sdo-survey-00.txt =D8 http://tools.ietf.org/id/draft-khasnabish-cloud-reference-framework-00.txt =D8 http://tools.ietf.org/id/draft-khasnabish-cloud-industry-workitems-survey-0= 0.txt =D8 http://tools.ietf.org/id/draft-so-vepc-01.txt =D8 http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/Karavettil-= et-al-IETF-Cloud-Security-Framework-11Feb2011_v2.pdf All of the drafts and presentations are available at the following site: http://trac.tools.ietf.org/area/app/trac/wiki/Clouds We look forward to your further comments and suggestions. Many thanks. Best Regards. Bhumip Khasnabish (Mobile:+001-781-752-8003, vumip1@gmail.com) http://www.linkedin.com/in/bhumipkhasnabish --000e0cd5645290c171049daa6c5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear All,
=A0
Based on multiple discussions that we = had in clouds@ietf.org and s= uggestions / recommendations
from IETF APP area AD (Peter), = we plan to focus former CloudApps work in the propo= sed
virtual desktop infrastructure (VDI) a= rea.=A0
=A0
Below pls find the draft charter we are deve= loping based on participation and contribution of those
who are interested in this.
=A0

The clear and present trend of end-user device converg= ence merges multiple information processing devices, communication devices,= and entertainment devices into a single unit.=A0 This highly converged device is supported by the Virtual De= sktop Infrastructure (VDI) in the virtual on-demand computing and networkin= g environment (commonly referred to as Cloud environment). VDI consists of = the following three basic functional components:=A0 Virtual Desktop Client (VDC, the converged end-user devic= e), the Virtual Desktop Agent (VDA, the control software residing in a virt= ual machine hosted in a data center), and a set of protocols connecting the= m together to deliver the desired services.=A0

=A0

=A0=A0=A0=A0=A0=A0= =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0+----------= -----------------+

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 | +-----------------------+ |

=A0=A0=A0=A0=A0=A0= =A0 +-----------+=A0 VDI pr= otocol =A0| | +------------------+= =A0 | |=A0

=A0=A0=A0=A0=A0=A0= =A0 | VDI Client|----------------+ + | Virtual Desktop=A0 |=A0 | |

=A0=A0=A0=A0=A0=A0= =A0 +-----------+=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0| |=A0=A0=A0=A0=A0=A0 Agent=A0=A0=A0=A0 =A0=A0=A0|=A0 | |= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0| |= +------------------+=A0 | |

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 | |=A0=A0=A0=A0=A0= Guest OS=A0=A0=A0=A0=A0=A0=A0=A0 = | |

=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| +--------= ---------------+ |

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 |=A0=A0 Vir= tual Machine=A0=A0=A0=A0=A0=A0=A0=A0 |

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 | Hosted in a Data Center=A0=A0 |

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 +---------------------------+

=A0

Currently there are no st= andard VDI protocols.=A0 This lack= of standard protocol creates friction and barrier in solution development,= deployment, and service management.=A0 <= /span>In addition, the limited available proprietary solutions do not fully= address the issues caused by service mobility and =A0=A0access (both nomadic and wireless).=A0 Furthermore, many critical functional requireme= nts for VDI such as service availability/distribution, scalability, securit= y, and manageability are not addressed in a way to support interoperability= .

=A0

The proposed VDI WG focus= es on the requirements and protocol development activities that are directl= y associated with virtual desktop infrastructure.=A0 The background materials related to SDO survey, referenc= e framework, work items gap, and security gap can be found in the already p= ublished/work-in-progress (to be completed soon) drafts as cited at the end= of this document.=A0=A0=A0

The proposed work items f= or the VDI WG are as listed below.

=A0

=A0

1) Produce a VDI Problem Statement and Resolution docu= ment listing the technical issues of the existing VDI systems, proposing re= ference architecture, and defining the scope of VDI protocol standard.

=A0

2) Produce a VDI Requirements document that defines th= e functional and operational requirements of the VDI protocol.

=A0

3) Produce a detailed VDI Protocol Specification.

=A0

4) Once the base protocol specification is complete, r= e-charter the WG to produce various VDI protocol extensions to support appl= ication-specific areas such as access security, additional video/audio comp= ression mechanism, service mobility, profile/personality adjustment, and co= ntext-awareness.

=A0

=A0

References and VDI-related drafts:

=D8=A0 <= /span>http://tools.ietf.org/id/draft-wang-clouds-vdi-proble= m-statement-00.txt

=D8=A0 <= /span>http= ://www.ietf.org/id/draft-cloud-log-00.txt

=D8=A0 <= /span>http://t= rac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/Johnston-IETF-78-Cl= ouds-bar-BoF-Std-Gap-28July10.pdf

=D8=A0 <= /span>http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/= Protocol%20Considerations%20for%20Workload%20Mobility%20in%20Clouds.txt=

=D8=A0 <= /span>http://trac.tools.ietf.= org/area/app/trac/attachment/wiki/Clouds/draft-rfc-seamless-Cloud-masum-01.= txt

=D8=A0 <= /span>Karavettil-et-al-IETF-VDI-Draft-v1-03042011

=A0

Background References and drafts:

=D8=A0 <= /span>http://tools.ietf.org/id/draft-ma-clouds-vdi-survey-00.txt

=D8=A0 <= /span>http://tools.ietf.org/id/draft-khasnabish-cloud-sdo-survey-= 00.txt

=D8=A0 <= /span>http://tools.ietf.org/id/draft-khasnabish-cloud-re= ference-framework-00.txt

=D8=A0 <= /span>http://tools.ietf.org/id/draft-khasnabish-cl= oud-industry-workitems-survey-00.txt

=D8=A0 <= /span>http= ://tools.ietf.org/id/draft-so-vepc-01.txt

=D8=A0 <= /span>http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/Karavett= il-et-al-IETF-Cloud-Security-Framework-11Feb2011_v2.pdf

=A0

<= span style=3D"mso-fareast-font-family: 'Times New Roman'">All of the drafts and presentations are available at the following = site:

<= span style=3D"mso-fareast-font-family: 'Times New Roman'">ht= tp://trac.tools.ietf.org/area/app/trac/wiki/Clouds


We=A0 look forward to your further comments and sugg= estions.
=A0
Many thanks.
Best Regards.

Bhumip Khasnabish (Mobile:+001-781-752-8003, vumip1@gmail.com)
= h= ttp://www.linkedin.com/in/bhumipkhasnabish

=A0
--000e0cd5645290c171049daa6c5e-- From johnl@iecc.com Sat Mar 5 16:08:58 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5143A6A41 for ; Sat, 5 Mar 2011 16:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.091 X-Spam-Level: X-Spam-Status: No, score=-111.091 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG2dKLjFxoFh for ; Sat, 5 Mar 2011 16:08:57 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id B56FE3A6A32 for ; Sat, 5 Mar 2011 16:08:56 -0800 (PST) Received: (qmail 77154 invoked from network); 6 Mar 2011 00:10:07 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 6 Mar 2011 00:10:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=4e3d.4d72d0df.k1103; i=johnl@user.iecc.com; bh=yuBUTzaf6nC2EZHHE1Yf2IOPNGpMOFsMvEFibRYkdZk=; b=etNeTbR1NbF/91IeWb6Mg3BILw6wJCQJtWuFH3XL8aij4MAMnIlWKsZN/EQauFXkricaLOmNCRf3r0UOfQ1sJRK57ohmxPN8CX7RGL1lcoHF1LskXSroRY55oxRp13BtODVA/GGj2QsoLGa6vLu1/OKkBd+SV0rX5j/4GObUYHc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=4e3d.4d72d0df.k1103; olt=johnl@user.iecc.com; bh=yuBUTzaf6nC2EZHHE1Yf2IOPNGpMOFsMvEFibRYkdZk=; b=Hh/+RtzTDorBRovdCkmoUVkjYjzBW40T/dZTXHv/n/6zVX45wUJeU1pdKN+3Y5AvhxvYhTImnO1zyAswUd3/7/x9r92YziCH8hXX+nOU5i+inFi1zw0Wbx+160+ZrEWAAXsr6ADh8lhkVFIserR+kzpVQasuM0HiqfAceEmouxA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 6 Mar 2011 00:10:06 -0000 Message-ID: <20110306001006.20028.qmail@joyce.lan> From: John Levine To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] proposal for Virtual desktop infrastructure (VDI) work in APP area X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 00:08:58 -0000 >Currently there are no standard VDI protocols. Isn't the de-facto standard VNC? It will be RFC 6143, probably coming out this week. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From paul.hoffman@vpnc.org Sat Mar 5 16:22:46 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBC63A6A44 for ; Sat, 5 Mar 2011 16:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.88 X-Spam-Level: X-Spam-Status: No, score=-101.88 tagged_above=-999 required=5 tests=[AWL=0.719, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEqTgvgpMev7 for ; Sat, 5 Mar 2011 16:22:45 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id CA1AA3A6A41 for ; Sat, 5 Mar 2011 16:22:44 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p260NsDb001113 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 5 Mar 2011 17:23:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D72D41A.7060708@vpnc.org> Date: Sat, 05 Mar 2011 16:23:54 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20110306001006.20028.qmail@joyce.lan> In-Reply-To: <20110306001006.20028.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] proposal for Virtual desktop infrastructure (VDI) work in APP area X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 00:22:46 -0000 On 3/5/11 4:10 PM, John Levine wrote: >> Currently there are no standard VDI protocols. > > Isn't the de-facto standard VNC? It will be RFC 6143, probably coming > out this week. VNC covers one part of what is being described, namely the KVM control of the guest OS. The proposal Bhumip sent goes well beyond that control, and the one I propose goes beyond what Bhumip has proposed. --Paul Hoffman From sm@elandsys.com Sat Mar 5 17:29:45 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9A23A6ACB for ; Sat, 5 Mar 2011 17:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgKU7C4oILCK for ; Sat, 5 Mar 2011 17:29:41 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id B38FD3A6AA1 for ; Sat, 5 Mar 2011 17:29:41 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.44]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p261Ufqb000775 for ; Sat, 5 Mar 2011 17:30:48 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1299375050; bh=0WXOeS9cEL02RTRzwEYl7DngoTw=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type: Content-Transfer-Encoding; b=LslKteJWRF9E7rkyk1av+vBVWuHeu3+rpSQYAUF4YRPxqYRDAN3zyyTfmUBV96iCU tsJoBSlX8oX3TzER1cQj1WG1H4hwXTJeP2jYebbn2rdEkDmTMpxKl0rTQLyXHSzQUV jVIorDEs/Y/WYMm7nGP9Lek6/NnY0kIM8oMmZu6k= Message-Id: <6.2.5.6.2.20110305172214.0b733880@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 05 Mar 2011 17:30:18 -0800 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [apps-discuss] Apps Area Review Team Report for February 2011 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 01:29:46 -0000 Hello, The Applications Area Review Team provides=20 semi-formal reviews of Internet-Drafts as a way=20 to improve the quality of IETF=20 specifications. The members of the team are=20 selected from the IETF community, especially from=20 among active participants and recognized experts in the Applications Area. I would like to thank Larry Masinter for=20 accepting to join the Applications Area Review Team. The following reviews have been performed in February 2011: Reviewer I-D Eliot Lear draft-ietf-hokey-ldn-discovery-06 Martin J. D=FCrst draft-holsten-about-uri-scheme-06 Joshua Bell draft-ietf-netconf-4741bis-07 Pending review: draft-ietf-avt-rtp-svc assigned to Glenn Parsons draft-salowey-secsh-uri assigned to Joe Hildebrand draft-ietf-eai-rfc5335bis assigned to Dave Cridland draft-meadors-multiple-attachments-ediint assigned to Glenn Parsons draft-mraihi-totp-timebased assigned to Joe Hildebrand Regards, S. Moonesamy On behalf of the Apps Review Team http://www.apps.ietf.org/content/applications-area-review-team From derhoermi@gmx.net Sun Mar 6 15:56:58 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF94A28C0DD for ; Sun, 6 Mar 2011 15:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.838 X-Spam-Level: X-Spam-Status: No, score=-2.838 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbLKNydI8f2Q for ; Sun, 6 Mar 2011 15:56:56 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 61DCD28C0CF for ; Sun, 6 Mar 2011 15:56:55 -0800 (PST) Received: (qmail invoked by alias); 06 Mar 2011 23:58:06 -0000 Received: from dslb-094-223-183-128.pools.arcor-ip.net (EHLO HIVE) [94.223.183.128] by mail.gmx.net (mp007) with SMTP; 07 Mar 2011 00:58:06 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+gUS0eRb+gGRlwch0JNTQ9Af0bD1beNcaya0sA6q bJCCdb58SMdKX3 From: Bjoern Hoehrmann To: Alexey Melnikov Date: Mon, 07 Mar 2011 00:58:12 +0100 Message-ID: References: <4D6FBE4D.10602@isode.com> In-Reply-To: <4D6FBE4D.10602@isode.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Mon, 07 Mar 2011 08:17:38 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 23:56:58 -0000 * Alexey Melnikov wrote: >I am working with the rest of IESG on issuing the following IESG statement: It would probably be a good idea to point ietf-types subscribers to your message, they are the most likely to have opinions on this matter. >While this IESG statement doesn't change that, IESG would like to >encourage other SDOs to submit their registriation as Internet Drafts, >as this tends to improve quality of final registrations, and sometimes >even improves quality of the underlying format itself. The IESG's workflow is probably optimized for Internet-Drafts, so it's easy to see how this might improve things for the IESG, with requests ending up in the right tracking systems and such, but it would seem the idea would be to actually advance these Internet-Drafts to RFC status, but RFCs that contain little more than the media type registration tem- plates are not very useful. Nobody would look at the text/css RFC for instance to learn about CSS syntax, character encodings in CSS, or re- lated issues, for instance. So if you really mean they should go the I-D -> RFC route, then I'm not sure this is a good idea. If the idea is just to have something better on record than, say, review requests in the ietf-types list archives, then I doubt a bit that this would really help quality, even if you post an I-D you'd still request ietf-types review and as far as I can tell the "quality" issues usually get fixed there, if they get fixed at all. A bigger problem to me is that there are many entry points. If you want to register a type, do you contact IANA, do you contact ietf-types, do you contact the IESG, or someone else, in what order, and so on. If the process was "post registration information to ietf-types, fix issues raised there, then the media type reviewers will guide you through the next steps" that would be much simpler. Some people for instance think by posting to ietf-types they are asking the IESG to register a type. Another problem seems to be that after ietf-types review the process is intransparent. It seems to me that people are to contact the IESG se- parately and then the IESG may announce a decision sooner or later, but what happens inbetween does not seem to be easily publically accessible. Those two problems would be addressed by using I-Ds, but see above. As for the points on format evolution and licensing, instead of listing rather onerous requirements that I am not sure are fully supported by RFC 4288, it might be better to say that, if a format does not meet some reasonable stability and availability requirements, it is better to re- gister types in other trees than the standards tree. OASIS registering types under vnd.oasis rather than in the standards tree seems quite okay indeed. Personally, I think we might do just fine having just a "specification available" policy for media types with little regard for immutability or availability of specifications, or whether registrations use one version of the registration template or another, or getting some weird "Mac" codes right. We have more of a problem with many dozens of common types that are not registered at all. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From floe@butterbrot.org Mon Mar 7 08:48:10 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B299C3A67F3 for ; Mon, 7 Mar 2011 08:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3qeWZ8J2jzc for ; Mon, 7 Mar 2011 08:48:09 -0800 (PST) Received: from butterbrot.org (butterbrot.org [88.198.47.201]) by core3.amsl.com (Postfix) with ESMTP id 79FDD3A67F2 for ; Mon, 7 Mar 2011 08:48:09 -0800 (PST) Received: from [192.168.178.35] (unknown [93.104.123.233]) (using SSLv3 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by butterbrot.org (Postfix) with ESMTPSA id D4658154040 for ; Mon, 7 Mar 2011 17:49:53 +0100 (CET) From: Florian Echtler To: apps-discuss@ietf.org Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Mar 2011 17:49:21 +0100 Message-ID: <1299516561.2201.9.camel@hanuta> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] new internet-draft: GISpL - Gestural Interface Specification Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 16:48:10 -0000 Hello everyone, I'd like to announce that I've just uploaded an internet-draft for which I'm hoping to receive some comments & feedback: http://www.ietf.org/internet-drafts/draft-echtler-gispl-specification-00.txt This is very likely best discussed as a working group document in the appsawg, AFAICT. In particular, I'm interested to know whether this draft could also be published as an informational RFC in the future (since its topic is quite far off the norm). A HTML version generated by xml2rfc is also available at http://gispl.org/ . Looking forward to your comments, Yours, Florian Echtler From stpeter@stpeter.im Mon Mar 7 13:21:26 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5CE93A6818 for ; Mon, 7 Mar 2011 13:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.669 X-Spam-Level: X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+U6A74PH5oy for ; Mon, 7 Mar 2011 13:21:25 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 006C33A67EC for ; Mon, 7 Mar 2011 13:21:24 -0800 (PST) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7A4D4400F6; Mon, 7 Mar 2011 14:42:28 -0700 (MST) Message-ID: <4D754C9C.5040503@stpeter.im> Date: Mon, 07 Mar 2011 14:22:36 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Marc Blanchet References: <4D6FC5AF.8060503@stpeter.im> <4D6FEA6F.8040000@cisco.com> <4D6FEBE2.1000309@viagenie.ca> In-Reply-To: <4D6FEBE2.1000309@viagenie.ca> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010001050109060103090505" Cc: Michelle Cotton , apps-discuss@ietf.org, Eliot Lear Subject: Re: [apps-discuss] draft-lear-iana-timezone-database X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 21:21:26 -0000 This is a cryptographically signed message in MIME format. --------------ms010001050109060103090505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (Or should that be , I wonder...) On 3/3/11 12:28 PM, Marc Blanchet wrote: > Le 11-03-03 14:22, Eliot Lear a =C3=A9crit : >> Tony, Marc, Cyrus, >> >>> >> Marc: >>> A) XML IANA >> >> The database is currently sucked down and used by many many companies,= >> and it must be maintained in its current form. >=20 > I know. >=20 >> New forms are fine. >> Even new normative forms! But this form can't go away. >=20 > What I was trying to say is the following: > - IANA do keep the data in native XML format > - IANA converts XML native to the current file format. > - both formats are available from IANA web sites and are in sync. >=20 > that way, IANA continues with its XML infrastructure and have the TZ > community keep the same file format as before. Based on the comments from Cyrus [1], it sounds as if that is a good goal, but that we might not achieve it right away because of the complexities of modeling this data in XML. BTW, I know that Michelle Cotton from IANA plans to participate in the side meeting we'll hold about the timezone database (currently planned for the morning of Wednesday, March 30, 08:00-09:00), so her input will be very helpful. I've cc'd her on this message so that she's aware of this discussion, with threads starting at [2] and [3]. /psa [1] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02303.ht= ml [2] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02301.ht= ml [3] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02304.ht= ml --------------ms010001050109060103090505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMw NzIxMjIzNlowIwYJKoZIhvcNAQkEMRYEFHzRzUIYZFl9oDBqECJFef4hFkiEMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQC06ehF/LqH5hjMwepGNPc3fxMF4wNGDC2yjkWarG0L9KPg7Ev1QSBhXvqT Z+CQ9PnM+cgy3Q6hoTGzzi3XXk2vvV9hPTXiwUM211ShrvXe6KJlWkwu+WL35iXWRfoLzhS+ YWdrEp1SRWmCJNNpSDFH97cLMv6z5X/A23wA8SQfwIn6yiwHeFusma7g5McQn5NJY5vGFs++ gZa2LHw12K2+kOBBliG5cj5BmiljZcDdfiKdQ5+CQQmxp1ZS9cKII9oS2LajsjTCYBST0r+l aOI7riNOxtcVVnuIO6Mx8DDmOkAZdpqkbkU+tPj62dM1Gai+QvuHcmvbtXWJIfa5iDyKAAAA AAAA --------------ms010001050109060103090505-- From scott.brim@gmail.com Mon Mar 7 16:16:55 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53363A68F2 for ; Mon, 7 Mar 2011 16:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xSxh2G18G36 for ; Mon, 7 Mar 2011 16:16:54 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 96B763A68AC for ; Mon, 7 Mar 2011 16:16:54 -0800 (PST) Received: by ywi6 with SMTP id 6so2302291ywi.31 for ; Mon, 07 Mar 2011 16:18:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Tq/hwzyO1S0R2wPkJGvwp9ntJBg+xn7JzMvHEebv+KE=; b=QNk15QznzdVBNv2d9E2YmH3MrHLUctvVNSdTXE2PC2BgRR5J9tzg3CBYGtXxNszUHP glfD+TCCNMyAR8DC35oSDCg4/TWOj82cmZ+z+8NRnfKrI+yjvhXgRma+5u+93x+sFB84 ibc1ixtDBMMciwR7pS3DWRVTbLdyuskKDRgEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=PbOdl22dOXcSw6Nl4hHTyzRB8FkDRCak+hRCUxB1TuGJyuuVN7VwKMcYcIIuYl+gF0 VK1R22zQ2vgGLkeFshXqoGJ1ISzzD/11V8u7z/yhZrsLMkab9JIIW79uQJhN0Fay1WCq OAvR7Pft4oCcTj26No4PQCdPpf5toSnQOoHlY= Received: by 10.90.236.12 with SMTP id j12mr5678641agh.175.1299543488077; Mon, 07 Mar 2011 16:18:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.63.9 with HTTP; Mon, 7 Mar 2011 16:17:48 -0800 (PST) In-Reply-To: <4D72C318.7090303@vpnc.org> References: <4D72C318.7090303@vpnc.org> From: Scott W Brim Date: Mon, 7 Mar 2011 19:17:48 -0500 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=00163630ef45fa213a049ded8b45 Cc: meng.yu@zte.com.cn, "So, Ning" , wang.jun17@zte.com.cn, apps-discuss@ietf.org, Suren Karavettil Subject: Re: [apps-discuss] proposal for Virtual desktop infrastructure (VDI) work in APP area X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 00:16:55 -0000 --00163630ef45fa213a049ded8b45 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 5, 2011 at 18:11, Paul Hoffman wrote: > However, most of the interesting work here is, in fact, an API. Note that > I am *not* one of the people who says "the IETF { doesn't / can't } do > APIs"; I think we do/can as long as we are upfront about it. > Right. Personally I believe it's fine for the IETF to do APIs that enable capabilities closely associated with the network. I see no problem doing this. > Given that the text of the proposed charter says that the protocol would be > between the VDI Client and the Virtual Desktop Agent", which might be > software running on a Guest OS with no network connectivity, this will be an > API unless there is a requirement that the Guest OS has network connectivity > at a known and predictable address, and that the Virtual Machine (actually, > the host system) also has network connectivity at a known and predictable > address, and neither is firewalled from the VDI client. > > A different model would be that the VDI Client has a new protocol to talk > to the host system, and that the host system has an API for talking to the > Guest OS in a way that would reach the Virtual Desktop Agent. This model has > some advantages over the narrow one in the charter. For example, the > protocol would allow control over Guest OSs, such as "start up machine X" > and "send text to the console on machine X". These will work even if the > Guest OS does not support the API, or if it does not currently have network > connectivity. > > The proposed WG could come up with requirements for both the client-to-host > protocol and the API between the host and the desktop agent, and the two > could clearly have some good interactions. > If I understand you correctly, I just want to be sure functions are decoupled. The client SHOULD NOT know whether its agent is in a particular environment, e.g. a VM / Guest OS. Environments need to be replaceable, and the VDI or VDIs must be able to change independently. No? So I think it's okay to just focus on just the relationship between client and agent to start with, and possibly bring other things in as they turn out to be useful. Scott --00163630ef45fa213a049ded8b45 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Mar 5, 2011 at 18:11, Paul Hoffman <paul.hoffman@vpnc.org> wrote:<= br>
=A0However, most of the interesting work here is, in fact, an API. Note tha= t I am *not* one of the people who says "the IETF { doesn't / can&= #39;t } do APIs"; I think we do/can as long as we are upfront about it= .

Right. =A0Personally I believe it's fi= ne for the IETF to do APIs that enable capabilities closely associated with= the network. =A0I see no problem doing this.
=A0
Given that the text of the proposed charter says that the protocol would be= between the VDI Client and the Virtual Desktop Agent", which might be= software running on a Guest OS with no network connectivity, this will be = an API unless there is a requirement that the Guest OS has network connecti= vity at a known and predictable address, and that the Virtual Machine (actu= ally, the host system) also has network connectivity at a known and predict= able address, and neither is firewalled from the VDI client.

A different model would be that the VDI Client has a new protocol to talk t= o the host system, and that the host system has an API for talking to the G= uest OS in a way that would reach the Virtual Desktop Agent. This model has= some advantages over the narrow one in the charter. For example, the proto= col would allow control over Guest OSs, such as "start up machine X&qu= ot; and "send text to the console on machine X". These will work = even if the Guest OS does not support the API, or if it does not currently = have network connectivity.

The proposed WG could come up with requirements for both the client-to-host= protocol and the API between the host and the desktop agent, and the two c= ould clearly have some good interactions.

If I understand you correctly, I just want to be sure functions are de= coupled. =A0The client SHOULD NOT know whether its agent is in a particular= environment, e.g. a VM / Guest OS. =A0Environments need to be replaceable,= and the VDI or VDIs must be able to change independently. =A0No? =A0So I t= hink it's okay to just focus on just the relationship between client an= d agent to start with, and possibly bring other things in as they turn out = to be useful.

Scott
--00163630ef45fa213a049ded8b45-- From duerst@it.aoyama.ac.jp Tue Mar 8 00:03:43 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793443A68EA for ; Tue, 8 Mar 2011 00:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.843 X-Spam-Level: X-Spam-Status: No, score=-99.843 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOiJZDcPsCSl for ; Tue, 8 Mar 2011 00:03:40 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id 8BD943A68AB for ; Tue, 8 Mar 2011 00:03:39 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p2884itD007426 for ; Tue, 8 Mar 2011 17:04:44 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 424a_364c_ba5297da_495a_11e0_bde9_001d096c566a; Tue, 08 Mar 2011 17:04:44 +0900 Received: from [IPv6:::1] ([133.2.210.1]:49919) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 8 Mar 2011 17:04:43 +0900 Message-ID: <4D75E305.2060600@it.aoyama.ac.jp> Date: Tue, 08 Mar 2011 17:04:21 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Alexey Melnikov References: <4D6FBE4D.10602@isode.com> In-Reply-To: <4D6FBE4D.10602@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 08:03:43 -0000 Hello Alex, I support most of the comments from Björn. Some additional comments below. On 2011/03/04 1:14, Alexey Melnikov wrote: > I am working with the rest of IESG on issuing the following IESG statement: First, I'm worried that an IESG statement (of whatever content) will only complicate things for applicants and reviewers/commenters. IESG statements seem to work well for things that affect people who are already in the know, insiders,..., but not for outsiders. > ------------------------ > > BCP 13 (currently RFC 4288) specifies that Media Type registrations > from other Standards Organizations (SDOs) can be submitted directly to > IESG for approval, without a need to submit an Internet Draft and to ask > an Area Director to shepherd its publication. > > While this IESG statement doesn't change that, IESG would like to > encourage other SDOs to submit their registriation as Internet Drafts, I don't understand what's the purpose of this. One of the main changes in RFC 4288 was to get away from the fact that every type in the standards tree had to be an RFC. This was discussed e.g. with W3C, and made it considerably more straightforward to register types from W3C. For details, please see http://www.w3.org/2002/06/registering-mediatype. It could easily be seen as a step back. Also, please very strongly consider that while for somebody on the IESG, writing an ID, in particular if it only contains the template, is something they can easily do before breakfast, for people from the outside, it's something where they have no idea where to start, which often means they don't start at all. > as this tends to improve quality of final registrations, Can you give any examples? I don't say there are none, but I couldn't come up with one myself. > and sometimes > even improves quality of the underlying format itself. Does that imply that the underlying format should be included in the ID? That would definitely deviate from BCP 13. Anyway, giving clearer explanations (and probably discussion) about when exactly and what for an ID makes sense seems to be much needed, and the actual need should not be just because the datatracker cannot handle anything else than drafts. > IESG would also like to remind that as per BCP 13, other SDOs are not > excluded from the requirement to post their Media Type registrations > for 2 weeks review on the ietf-types@iana.org mailing list. That's true, and doesn't hurt mentioning. If we say something about this, please include a line or so saying that the post should contain an actual copy of the registration template (not just "it's over there") because that makes it much easier to comment. Regards, Martin. > When reviewing Media Type registrations IESG checks that the Media > Type registration template is correct and reasonably complete. > > When reviewing Media Type registrations (including those from other > SDOs) IESG also > checks that references to documents describing details of the Media > Type format are stable, i.e. > - a) the references are reasonably long lived > > and > > - b1) the document pointed to by the reference is either immutable > (i.e. if an updated document is approved for publication by the SDO, > then it will be posted at a different URI) or can only change in > insignificant ways (e.g. to correct typos, clarify text without > changing the media type format, etc.) > > - b2) the media type format contains some internal fields for > versioning that can be used to distingiush 2 incompatible versions of > the Media Type format > > - b3) there is some guaranty that future revisions of the format are > going to be backward compatible > > Note that the choices b1, b2 and b3 are not mutually exclusive. > > If the Media Type format specification has licensing restrictions, the > Internet Assigned Numbers Authority (IANA) must be granted express > permission to make archival copies of the Media Type format > specification, and to redistribute such a copy in the event that the > link to the format specification becomes inoperative and it is > determined that it will not be repaired. > > ------------------------ > > Please let me know if you have any corrections or major objections to > this before March 17th. > > Thanks, > Alexey > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From stpeter@stpeter.im Tue Mar 8 15:18:08 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A913A67AB for ; Tue, 8 Mar 2011 15:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.621 X-Spam-Level: X-Spam-Status: No, score=-102.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXOYSgjo2SHs for ; Tue, 8 Mar 2011 15:18:07 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B9DAB3A659B for ; Tue, 8 Mar 2011 15:18:07 -0800 (PST) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7EA7E4011B for ; Tue, 8 Mar 2011 16:39:19 -0700 (MST) Message-ID: <4D76B979.9060507@stpeter.im> Date: Tue, 08 Mar 2011 16:19:21 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080102080309080301090900" Subject: [apps-discuss] draft agenda for IETF 80 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 23:18:08 -0000 This is a cryptographically signed message in MIME format. --------------ms080102080309080301090900 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here is a draft agenda for the Apps Area open meeting (with APPSAWG session) at IETF 80. Bashing is welcome and changes are possible. ### AppsArea Open Meeting and APPSAWG Meeting IETF 80, Prague, Czech Republic Monday, March 28, 2011, 09:00-11:30 Chatroom: xmpp:appsarea@jabber.ietf.org?join Mailing list: apps-discuss@ietf.org ADs: Alexey Melnikov (outgoing) Peter Saint-Andre (continuing) Pete Resnick (incoming) 1. [ 5 mins] Area Directors Administrivia 2. [55 mins] Barry Leiba and Jiankang Yao APPSAWG session 2a. [15 mins] Paul Hoffman Specifying that a Server Supports TLS draft-hoffman-server-has-tls 2b. [ 5 mins] Paul Hoffman / Patrik F=C3=A4ltstr=C3=B6m Unicode and IDNA draft-faltstrom-5892bis 2c. [10 mins] Mark Nottingham The Network Authentication Required HTTP Status Code draft-nottingham-http-portal 2d. [15 mins] Murray Kucherawy Best Current Practices for Handling Malformed Messages draft-kucherawy-mta-malformed & The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages draft-kucherawy-rfc3462bis 2e. [10 mins] APPSAWG open mic 3. [10 mins] Eliot Lear IANA Procedures for Maintaining the Timezone Database draft-lear-iana-timezone-database-02 4. [10 mins] Eric Rescorla and Joe Hildebrand Web Object Encryption and Signing (WOES) draft-rescorla-jsms-00 5. [10 mins] Bernie Hoeneisen IANA Registration of Enumservices for Internet Calendaring draft-hoeneisen-rfc5333bis-00 6. [15 mins] Alexey Melnikov SMTP Extensions for Message Priorities and Alternate Recipient Delivery Option draft-melnikov-smtp-priority-00 draft-melnikov-smtp-altrecip-on-error-00 7. [20 mins] Larry Masinter / Alexey Melnikov MIME and the Web draft-masinter-mime-web-info-02 8. [10 mins] Florian Echtler GISpL: Gestural Interface Specification Language draft-echtler-gispl-specification-00 9. [15 mins] Applications Area open mic END ### --------------ms080102080309080301090900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMw ODIzMTkyMVowIwYJKoZIhvcNAQkEMRYEFBheb1kyUvG/w0M4DR1no1GacMIcMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQByAHJXKSTqZyrcPG+MloJqbOLH/JlMVxr+Pa80Z1+T3qnePpTDXgjY35Qm jNQ8vFhll1+wT7B5EuxFVPt4BuFEhnzPm8m4ymj4HzUCim1STstVXyTE6HBbVQBiU4mrGl6Z gL/Iw5uRT0UaHeS9MS6EwFt16RQVfekNGXdcJv+SqY18RkPmGnlBPJLeJU11lQN59mKyo9VQ sj/ayv+cPgPie12ib0dXCCLu1+GoZPe5n6DaP/yxjl1fKxh71AsM+ssxDwmwd2h/s/grQTrx NumltNTwXtO04xi12cqtIvkbu5sy6g0RJPJFFPs1tG3IV2aLgHtcBbmkMLAEk3Tnc0dMAAAA AAAA --------------ms080102080309080301090900-- From sm@resistor.net Tue Mar 8 17:12:36 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20F03A67F2 for ; Tue, 8 Mar 2011 17:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bh52X4Eiojk2 for ; Tue, 8 Mar 2011 17:12:35 -0800 (PST) Received: from mx.elandsys.com (eland-1-pt.tunnel.tserv15.lax1.ipv6.he.net [IPv6:2001:470:c:d43::2]) by core3.amsl.com (Postfix) with ESMTP id 4DB873A67CC for ; Tue, 8 Mar 2011 17:12:34 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Alpha0) with ESMTP id p291Dgu6007525; Tue, 8 Mar 2011 17:13:44 -0800 (PST) Message-Id: <6.2.5.6.2.20110308164758.0be3c0a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 08 Mar 2011 17:13:37 -0800 To: Alexey Melnikov From: SM In-Reply-To: <4D6FBE4D.10602@isode.com> References: <4D6FBE4D.10602@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 01:12:36 -0000 Hi Alexey, At 08:14 03-03-2011, Alexey Melnikov wrote: >I am working with the rest of IESG on issuing the following IESG statement: > >------------------------ > >BCP 13 (currently RFC 4288) specifies that Media Type registrations >from other Standards Organizations (SDOs) can be submitted directly to >IESG for approval, without a need to submit an Internet Draft and to ask >an Area Director to shepherd its publication. > >While this IESG statement doesn't change that, IESG would like to >encourage other SDOs to submit their registriation as Internet Drafts, >as this tends to improve quality of final registrations, and sometimes >even improves quality of the underlying format itself. The above sounds fine from an IETF point of view. According to BCP 13: "The standards tree is intended for types of general interest to the Internet community. Registrations in the standards tree MUST be approved by the IESG and MUST correspond to a formal publication by a recognized standards body. In the case of registration for the IETF itself, the registration proposal MUST be published as an RFC." "The media type registration procedure is not a formal standards process, but rather an administrative procedure intended to allow community comment and sanity checking without excessive time delay." The proposed IESG statement will end up turning=20 "the posting of an Internet Draft [into] a=20 necessary first step". Martin D=FCrst mentioned=20 that it is not always easy for people outside the=20 IETF to write an I-D [1]. "The IESG's workflow=20 is probably optimized for Internet-Drafts, so=20 it's easy to see how this might improve things=20 for the IESG, with requests ending up in the=20 right tracking systems" [2]. This has the=20 makings of turning the registration procedure into a formal standards= process. Regards, -sm 1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02319.html 2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02315.html= =20 From ted.ietf@gmail.com Tue Mar 8 17:33:00 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 329AC3A67EA for ; Tue, 8 Mar 2011 17:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47GhK-7TsbKQ for ; Tue, 8 Mar 2011 17:32:57 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id B7C0C3A67E6 for ; Tue, 8 Mar 2011 17:32:57 -0800 (PST) Received: by qwh6 with SMTP id 6so42654qwh.31 for ; Tue, 08 Mar 2011 17:34:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gE9QtEunX08OMZb1aQEZtTYFO/IF4OG2Mlkeat6HmzE=; b=QExL0P5biTRXVFbmdeM+HIaWagN/juT6FzqZ76TQPKp94LKgVQKl+ZkTlZy38BI6AL WPa/kNuMTRcHkTgCxppEir5KEA6efQomFunV8hzT+9k5nPlVxKphU88YZyAzahIVHAjT QDGI7oWGWTajR4OrzFbzJNJ2BlHE0VXKYbyFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HvpDTJ/as3pgN015fqeFTVI1MlYD7aiCOfkk2iM4YEgieXrKACKDh0BGz6RCmENeJ0 rQ92VF7nR2p7enQKGfU4netF91MoBOdyCNQJEFvGd5KcQ680HJz6hK8lOvB/N1EFkwUx GJ/FfPA5MfBMlASURcLUoQZnuQ8xTQlwnP20A= MIME-Version: 1.0 Received: by 10.229.41.70 with SMTP id n6mr3468903qce.252.1299634453078; Tue, 08 Mar 2011 17:34:13 -0800 (PST) Received: by 10.229.11.74 with HTTP; Tue, 8 Mar 2011 17:34:13 -0800 (PST) In-Reply-To: <6.2.5.6.2.20110308164758.0be3c0a8@resistor.net> References: <4D6FBE4D.10602@isode.com> <6.2.5.6.2.20110308164758.0be3c0a8@resistor.net> Date: Tue, 8 Mar 2011 17:34:13 -0800 Message-ID: From: Ted Hardie To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 01:33:00 -0000 On Tue, Mar 8, 2011 at 5:13 PM, SM wrote: > Hi Alexey, >> BCP 13 (currently RFC 4288) specifies that Media Type registrations >> from other Standards Organizations (SDOs) can be submitted directly to >> IESG for approval, without a need to submit an Internet Draft and to ask >> an Area Director to shepherd its publication. >> >> While this IESG statement doesn't change that, IESG would like to >> encourage other SDOs to submit their registriation as Internet Drafts, >> as this tends to improve quality of final registrations, and sometimes >> even improves quality of the underlying format itself. > > =A0"The media type registration procedure is not a formal standards > =A0 process, but rather an administrative procedure intended to allow > =A0 community comment and sanity checking without excessive time delay." > > The proposed IESG statement will end up turning "the posting of an Intern= et > Draft [into] a necessary first step". =A0Martin D=FCrst mentioned that it= is not > always easy for people outside the IETF to write an I-D [1]. =A0"The IESG= 's > workflow is probably optimized for Internet-Drafts, so it's easy to see h= ow > this might improve things for the IESG, with requests ending up in the ri= ght > tracking systems" [2]. =A0This has the makings of turning the registratio= n > procedure into a formal standards process. > I'm not sure I agree that it turns into a formal standards process, but I definitely agree that it's going to be very hard for outsiders to find this statement and do the right thing, absent additional clue. The BCP will say "not needed" and the IESG statement will say "encouraged". I'd say if the IESG ever plans to point to the statement after receiving one in another format, it should update the BCP instead. regards, Ted Hardie From stpeter@stpeter.im Tue Mar 8 18:46:18 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777A33A680D for ; Tue, 8 Mar 2011 18:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cetda2OUpnK for ; Tue, 8 Mar 2011 18:46:17 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2B6603A680C for ; Tue, 8 Mar 2011 18:46:17 -0800 (PST) Received: from squire.local (dsl-251-69.dynamic-dsl.frii.net [216.17.251.69]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B84FC400F6; Tue, 8 Mar 2011 20:07:28 -0700 (MST) Message-ID: <4D76EA41.3030204@stpeter.im> Date: Tue, 08 Mar 2011 19:47:29 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Paul Hoffman References: <4D72C318.7090303@vpnc.org> In-Reply-To: <4D72C318.7090303@vpnc.org> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090704020507000200000407" Cc: meng.yu@zte.com.cn, "So, Ning" , wang.jun17@zte.com.cn, apps-discuss@ietf.org, Suren Karavettil Subject: Re: [apps-discuss] proposal for Virtual desktop infrastructure (VDI) work in APP area X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 02:46:18 -0000 This is a cryptographically signed message in MIME format. --------------ms090704020507000200000407 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/5/11 4:11 PM, Paul Hoffman wrote: > First off, I think this work could be very useful both in the short and= > long run. I am swimming in these issues today in my work, so please do > not take the response below as diminishing the need. >=20 > I question whether or not the IETF would be the best place for this. I > say that not because "SDO X would be better than the IETF" because if > that were the case, SDO X would have done so by now.=20 Paul, I'm not sure that follows. :) Many factors are involved in the standardization (or lack thereof) within a particular problem domain. > However, most of > the interesting work here is, in fact, an API. Note that I am *not* one= > of the people who says "the IETF { doesn't / can't } do APIs"; I think > we do/can as long as we are upfront about it. Another question is: can we do it well? And, more specifically, do we have reason to think that we might do it well in the virtual desktop infrastructure (VDI) space? > In specific (a fixed chart): >=20 > +---------------------------+ > | +-----------------------+ | > +-----------+ VDI protocol | | +------------------+ | | > | VDI Client|----------------+ + | Virtual Desktop | | | > +-----------+ | | | Agent | | | > | | +------------------+ | | > | | Guest OS | | > | +-----------------------+ | > | Virtual Machine | > | Hosted in a Data Center | > +---------------------------+ >=20 > Given that the text of the proposed charter says that the protocol woul= d > be between the VDI Client and the Virtual Desktop Agent", which might b= e > software running on a Guest OS with no network connectivity, this will > be an API unless there is a requirement that the Guest OS has network > connectivity at a known and predictable address, and that the Virtual > Machine (actually, the host system) also has network connectivity at a > known and predictable address, and neither is firewalled from the VDI > client. Roughly what percentage of Guest OS and VM systems have network connectivity of the kind that would enable use of a protocol instead of an API? That might be helpful information. > A different model would be that the VDI Client has a new protocol to > talk to the host system, and that the host system has an API for talkin= g > to the Guest OS in a way that would reach the Virtual Desktop Agent. > This model has some advantages over the narrow one in the charter. For > example, the protocol would allow control over Guest OSs, such as "star= t > up machine X" and "send text to the console on machine X". These will > work even if the Guest OS does not support the API, or if it does not > currently have network connectivity. Yes, that does seem like a powerful model. Roughly what percentage of VDI systems are architected that way currently, as opposed to the model outlined in the proposed charter? How does what you've described differ from draft-wang-clouds-vdi-problem-statement-00? (And as I'm sure you've thought about, the security considerations might get "interesting" if the VDI client has permissions to do things at the host level.) > The proposed WG could come up with requirements for both the > client-to-host protocol and the API between the host and the desktop > agent, and the two could clearly have some good interactions. In your opinion, which would come first -- the protocol or the API? > (And for those of you who want to come up to speed on the terminology > used in virtualization and some of the security issues, please see NIST= > SP 800-125 > . Thanks for providing the reference. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090704020507000200000407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMw OTAyNDcyOVowIwYJKoZIhvcNAQkEMRYEFNsZxtZIiux+oHni4j5pDRYAdqFHMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBrGcdhtrR9W3TfSme4yXaaFBsWSorc80P5Dvbbscx6cuCIDlTcM1mDR4Uk Ruh7fl/9ikjkDUvKcKaxMIdgY/zXropqullgJPEqspq1QDIsT5+YkMoXIjAATnNMCdA7eLyB iwwDJWVImLIDVJuGdL0V1/2Cdoye0uYSY7ZIthBq0/Kr5PmIGBT7uoVN6VG9njY8lTEsoOv6 lmqKPDUFupsLnY9xiq9KNnPzmjf4lpRqhW66acY3vGU00asvbMhj5s1d1yDWDiu6UPHkpuDz je5qjv/KQpbyOHsOeZerbHi9ww7EFJNVDy7t+a23FSAa8nJvyrj2cGxi5EqG77389RS9AAAA AAAA --------------ms090704020507000200000407-- From stpeter@stpeter.im Tue Mar 8 19:58:08 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 285963A6802 for ; Tue, 8 Mar 2011 19:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tycjEwEa9Xka for ; Tue, 8 Mar 2011 19:58:07 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E658B3A67B5 for ; Tue, 8 Mar 2011 19:58:06 -0800 (PST) Received: from squire.local (dsl-251-69.dynamic-dsl.frii.net [216.17.251.69]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 420AB4011B; Tue, 8 Mar 2011 21:19:19 -0700 (MST) Message-ID: <4D76FB18.1040304@stpeter.im> Date: Tue, 08 Mar 2011 20:59:20 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Ted Hardie References: <4D6FBE4D.10602@isode.com> <6.2.5.6.2.20110308164758.0be3c0a8@resistor.net> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050706010303010107010505" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 03:58:08 -0000 This is a cryptographically signed message in MIME format. --------------ms050706010303010107010505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/8/11 6:34 PM, Ted Hardie wrote: > On Tue, Mar 8, 2011 at 5:13 PM, SM wrote: >> Hi Alexey, >=20 >>> BCP 13 (currently RFC 4288) specifies that Media Type registrations >>> from other Standards Organizations (SDOs) can be submitted directly t= o >>> IESG for approval, without a need to submit an Internet Draft and to = ask >>> an Area Director to shepherd its publication. >>> >>> While this IESG statement doesn't change that, IESG would like to >>> encourage other SDOs to submit their registriation as Internet Drafts= , >>> as this tends to improve quality of final registrations, and sometime= s >>> even improves quality of the underlying format itself. >> > >=20 >> "The media type registration procedure is not a formal standards >> process, but rather an administrative procedure intended to allow >> community comment and sanity checking without excessive time delay."= >> >> The proposed IESG statement will end up turning "the posting of an Int= ernet >> Draft [into] a necessary first step". Martin D=C3=BCrst mentioned tha= t it is not >> always easy for people outside the IETF to write an I-D [1]. "The IES= G's >> workflow is probably optimized for Internet-Drafts, so it's easy to se= e how >> this might improve things for the IESG, with requests ending up in the= right >> tracking systems" [2]. This has the makings of turning the registrati= on >> procedure into a formal standards process. >> >=20 > I'm not sure I agree that it turns into a formal standards process, > but I definitely agree that it's going to be very hard for outsiders > to find this statement and do the right thing, absent additional clue. Currently folks working within other SDOs ping one or both of the Applications Area Directors, who usually say "we know it's not mandatory, but it would be helpful if you could write a brief Internet-Draft defining your registration request". So outsiders don't need to find this statement and do the right thing from the start, and I don't think the Apps ADs (or IESG in general) expect that they would. > The BCP will say "not needed" and the IESG statement will say > "encouraged". I'd say if the IESG ever plans to point to the > statement after receiving one in another format, it should update the > BCP instead. Yes, it's always good to align our procedural BCPs with the practices we actually follow (if they're "best", at least). Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050706010303010107010505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMw OTAzNTkyMFowIwYJKoZIhvcNAQkEMRYEFES1ibdLA9z/VmBQPJ5dpTQZ4xR1MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQC0TG2p/kxZZMIs8pWROcpP0xyHzPxKc+MWBjw3OwcyMTJEdEyx26tJmrs+ KubBBTHhu2DoUJF+c19xTi7TblfyTXZKSI0jgraIKt4Fr1wR4Zg5cIsLh4mO9vsrHkyAEcHv KrmSX4pmKVK8R7YErVv5sdysjEVW+t23Md9TvAwHt0Z5IJGSGdUBCTZmd5HcZfmpXR+HOcKc U/ekLd/DGRh35SyowkORYkX4CDzl5G95tkTuol3XGLsf5xE2atNWDTJ3mBmCCcqPGaR6TBYU /0s/34+Fb721er1kARsuKroddO6tL8rYb0Js6/Pvcag4QrAsulbtxv75EUKCPMD9RTnbAAAA AAAA --------------ms050706010303010107010505-- From fluffy@cisco.com Tue Mar 8 20:51:17 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AA993A6817 for ; Tue, 8 Mar 2011 20:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.34 X-Spam-Level: X-Spam-Status: No, score=-110.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nn3+I54w7Bm for ; Tue, 8 Mar 2011 20:51:08 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C18083A6807 for ; Tue, 8 Mar 2011 20:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=822; q=dns/txt; s=iport; t=1299646344; x=1300855944; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4bfWMoHEB9bNyN+j2uvyNaEs/ihV/Ubh0XA7jABZBU4=; b=UlS+3IIwmavm/iFYMpAu8zT9JjuVuis1gV/pWMdF1cACwC5HvPyL8xXc vU4cJHXH6QGItz9aWPpoDhIfK8O3fvjIJjuFkWC5DZFmudGbSMQryrBAF 2gCvyK4Ku/rH70ZU1l9OyQyatzQL+LnYWKjrFt3CYqQW9QXp4QRJypeQt A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHuWdk2rR7H+/2dsb2JhbACma3SmP5wthWMEhR2HFYNH X-IronPort-AV: E=Sophos;i="4.62,288,1297036800"; d="scan'208";a="275324102" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 09 Mar 2011 04:52:16 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p294qF1R002782; Wed, 9 Mar 2011 04:52:16 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D72D41A.7060708@vpnc.org> Date: Tue, 8 Mar 2011 21:54:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5E76135C-0232-4390-A4B4-CE5D6C7B1DCC@cisco.com> References: <20110306001006.20028.qmail@joyce.lan> <4D72D41A.7060708@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] proposal for Virtual desktop infrastructure (VDI) work in APP area X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 04:51:17 -0000 Paul, I'm sure I should be embarrassed to ask this and it is somewhere = in my inbox ... but do you have point to the two proposal from you and = Bhumip. Thanks, Cullen On Mar 5, 2011, at 5:23 PM, Paul Hoffman wrote: > On 3/5/11 4:10 PM, John Levine wrote: >>> Currently there are no standard VDI protocols. >>=20 >> Isn't the de-facto standard VNC? It will be RFC 6143, probably coming >> out this week. >=20 > VNC covers one part of what is being described, namely the KVM control = of the guest OS. The proposal Bhumip sent goes well beyond that control, = and the one I propose goes beyond what Bhumip has proposed. >=20 > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From stpeter@stpeter.im Tue Mar 8 20:57:58 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143123A6807 for ; Tue, 8 Mar 2011 20:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.622 X-Spam-Level: X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yL8h-la5nHOQ for ; Tue, 8 Mar 2011 20:57:57 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AAE1F3A67FD for ; Tue, 8 Mar 2011 20:57:56 -0800 (PST) Received: from squire.local (dsl-251-69.dynamic-dsl.frii.net [216.17.251.69]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D843140393; Tue, 8 Mar 2011 22:19:09 -0700 (MST) Message-ID: <4D77091E.1060400@stpeter.im> Date: Tue, 08 Mar 2011 21:59:10 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Cullen Jennings References: <20110306001006.20028.qmail@joyce.lan> <4D72D41A.7060708@vpnc.org> <5E76135C-0232-4390-A4B4-CE5D6C7B1DCC@cisco.com> In-Reply-To: <5E76135C-0232-4390-A4B4-CE5D6C7B1DCC@cisco.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010209000501090407010605" Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] proposal for Virtual desktop infrastructure (VDI) work in APP area X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 04:57:58 -0000 This is a cryptographically signed message in MIME format. --------------ms010209000501090407010605 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/8/11 9:54 PM, Cullen Jennings wrote: >=20 > Paul, I'm sure I should be embarrassed to ask this and it is somewhere = in my inbox ... but do you have point to the two proposal from you and Bh= umip. Thanks, Cullen That would be: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02309.html and http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02310.html Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010209000501090407010605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMw OTA0NTkxMFowIwYJKoZIhvcNAQkEMRYEFJ/SMYEzhzJkm5Z4+1XiIPe/ILdTMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAujydvmZ/bAKuHNmFAeCzUbWygzlLmsuIlFUbu8Q5NdjKRga+lh7hpmlAn 8fat6ipRNc+lU724Qare2wW7JUr5EUxsVN+PAhiL3VKcth0o1++czLcNqiHxJtE96n1E9Dhm +cY5Ou6dBOOX4gnorXIlpJ3KuuJoMtlkjitsRa0UfkZs1+eg3U2wh3qZAdktU4JbhFmHDGvI jRfKi9RTPnf7L7WtTdcfzquAj1wkoFL0RQxP7GRFuGx4QZV53NXgYIN0yijDe28KyMo0zZly 8Ys4KfEOkqmCEqQ2uzhvAArqgS5aExlh2cXE19KqKcK5wUE4mNgAFEvbiyR3rZODpr2mAAAA AAAA --------------ms010209000501090407010605-- From duerst@it.aoyama.ac.jp Tue Mar 8 23:43:39 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B433A6822 for ; Tue, 8 Mar 2011 23:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.84 X-Spam-Level: X-Spam-Status: No, score=-99.84 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IM6a8nz+4dw5 for ; Tue, 8 Mar 2011 23:43:37 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by core3.amsl.com (Postfix) with ESMTP id 33F2A3A685D for ; Tue, 8 Mar 2011 23:43:36 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p297ikTW020245 for ; Wed, 9 Mar 2011 16:44:46 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 7c1d_2f09_1ad304f2_4a21_11e0_a579_001d096c5782; Wed, 09 Mar 2011 16:44:46 +0900 Received: from [IPv6:::1] ([133.2.210.1]:59433) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 9 Mar 2011 16:44:47 +0900 Message-ID: <4D772FD6.4080305@it.aoyama.ac.jp> Date: Wed, 09 Mar 2011 16:44:22 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <4D6FBE4D.10602@isode.com> <6.2.5.6.2.20110308164758.0be3c0a8@resistor.net> <4D76FB18.1040304@stpeter.im> In-Reply-To: <4D76FB18.1040304@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 07:43:39 -0000 Hello Peter, On 2011/03/09 12:59, Peter Saint-Andre wrote: > On 3/8/11 6:34 PM, Ted Hardie wrote: >> I'm not sure I agree that it turns into a formal standards process, >> but I definitely agree that it's going to be very hard for outsiders >> to find this statement and do the right thing, absent additional clue. > > Currently folks working within other SDOs ping one or both of the > Applications Area Directors, who usually say "we know it's not > mandatory, but it would be helpful if you could write a brief > Internet-Draft defining your registration request". So outsiders don't > need to find this statement and do the right thing from the start, and I > don't think the Apps ADs (or IESG in general) expect that they would. [Assuming the above also applies to W3C] I'm no longer working for W3C, but if I still did, and in particular if I still was in charge of coordinating these registration requests, I'd very clearly and explicitly not be happy with this. In my view, one of the main points of RFC 4288 was exactly to get away from the need to have things in two places, and to get away from the need for people who never before and never after wrote Internet Drafts to get familiar with all the details. If we think RFC 4288 has failed, we should fix it. (I for my part don't think it has failed, at least not in this respect.) Also, while the above solves the "find the Statement" problem, it won't avoid the problem that outsiders get told different things at different stages: First, they get told to follow RFC 4288 (or they might even find it themselves), then once they are through review on ietf-types, they get told something else. And the above "it would be helpful" still doesn't answer the question why. The assumption from non-IESG people including me is that the main or only reason is because the datatracker can only handle IDs. It would be helpful (sic) if you and Alex could be clear and frank about this. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From alexey.melnikov@isode.com Wed Mar 9 03:42:11 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95DBD3A6842 for ; Wed, 9 Mar 2011 03:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.269 X-Spam-Level: X-Spam-Status: No, score=-102.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgVId85uS7ir for ; Wed, 9 Mar 2011 03:42:10 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 197FF3A695B for ; Wed, 9 Mar 2011 03:42:10 -0800 (PST) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 9 Mar 2011 11:43:25 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D7767AD.6020808@isode.com> Date: Wed, 09 Mar 2011 11:42:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Bjoern Hoehrmann References: <4D6FBE4D.10602@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 11:42:11 -0000 Hi Bjoern, Bjoern Hoehrmann wrote: >* Alexey Melnikov wrote: > >>I am working with the rest of IESG on issuing the following IESG statement: >> > >It would probably be a good idea to point ietf-types subscribers to your >message, they are the most likely to have opinions on this matter. > Yes, good point. I will do. >>While this IESG statement doesn't change that, IESG would like to >>encourage other SDOs to submit their registriation as Internet Drafts, >>as this tends to improve quality of final registrations, and sometimes >>even improves quality of the underlying format itself. >> >> > >The IESG's workflow is probably optimized for Internet-Drafts, so it's >easy to see how this might improve things for the IESG, with requests >ending up in the right tracking systems and such, but it would seem the >idea would be to actually advance these Internet-Drafts to RFC status, >but RFCs that contain little more than the media type registration tem- >plates are not very useful. Nobody would look at the text/css RFC for >instance to learn about CSS syntax, character encodings in CSS, or re- >lated issues, for instance. > It dependends on how much extra information such document provides. Collecting all references in one place is a good thing as well. But YMMV. >So if you really mean they should go the I-D -> RFC route, then I'm not >sure this is a good idea. If the idea is just to have something better >on record than, say, review requests in the ietf-types list archives, >then I doubt a bit that this would really help quality, even if you post >an I-D you'd still request ietf-types review and as far as I can tell >the "quality" issues usually get fixed there, if they get fixed at all. > I should have pointed out earlier that the paragraph recommending Internet Drafts is non normative (it is expressing the opinion of the current IESG, but this can change over time). I am still thinking about what you, Martin, Ted and others said about this paragraph and maybe the best way forward is actually to delete it. The main purpose of this proposed IESG statement is to clarify stability of references and licensing. >A bigger problem to me is that there are many entry points. If you want >to register a type, do you contact IANA, do you contact ietf-types, do >you contact the IESG, or someone else, in what order, and so on. > Right. I think IANA is doing the right thing by always redirecting to either IESG (for registrations in the standars tree) or to the Expert Reviewer (for vendor specific registrations). But I can see how the process can confuse people. >If the >process was "post registration information to ietf-types, fix issues >raised there, then the media type reviewers will guide you through the >next steps" that would be much simpler. Some people for instance think >by posting to ietf-types they are asking the IESG to register a type. > Right. I am open to suggestion how to improve this. This probably doesn't need an IESG statement of any sort. >Another problem seems to be that after ietf-types review the process is >intransparent. It seems to me that people are to contact the IESG se- >parately and then the IESG may announce a decision sooner or later, but >what happens inbetween does not seem to be easily publically accessible. > Yes. IESG and interested parties in W3C are actively discussing how to improve this. I think IESG will end up using a public trac system or the like. >Those two problems would be addressed by using I-Ds, but see above. > >As for the points on format evolution and licensing, instead of listing >rather onerous requirements that I am not sure are fully supported by >RFC 4288, > It isn't, that is why IESG is proposing a statement. >it might be better to say that, if a format does not meet some >reasonable stability and availability requirements, it is better to re- >gister types in other trees than the standards tree. OASIS registering >types under vnd.oasis rather than in the standards tree seems quite okay >indeed. > Right. Let me think about this a bit more. >Personally, I think we might do just fine having just a "specification >available" policy for media types with little regard for immutability or >availability of specifications, or whether registrations use one version >of the registration template or another, or getting some weird "Mac" >codes right. We have more of a problem with many dozens of common types >that are not registered at all. > > Best Regards, Alexey -- IETF Application Area Director, Internet Messaging Team Lead, JID: same as my email address From paul.hoffman@vpnc.org Wed Mar 9 08:25:10 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EB003A6859 for ; Wed, 9 Mar 2011 08:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.932 X-Spam-Level: X-Spam-Status: No, score=-101.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwlwLthua4A6 for ; Wed, 9 Mar 2011 08:25:08 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 240473A683E for ; Wed, 9 Mar 2011 08:25:07 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p29GQNhH000230 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 9 Mar 2011 09:26:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D77AA2F.3010007@vpnc.org> Date: Wed, 09 Mar 2011 08:26:23 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4D72C318.7090303@vpnc.org> <4D76EA41.3030204@stpeter.im> In-Reply-To: <4D76EA41.3030204@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] proposal for Virtual desktop infrastructure (VDI) work in APP area X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 16:25:10 -0000 On 3/8/11 6:47 PM, Peter Saint-Andre wrote: >> However, most of >> the interesting work here is, in fact, an API. Note that I am *not* one >> of the people who says "the IETF { doesn't / can't } do APIs"; I think >> we do/can as long as we are upfront about it. > > Another question is: can we do it well? And, more specifically, do we > have reason to think that we might do it well in the virtual desktop > infrastructure (VDI) space? That is a very good question, and the answer depends on where you think the VDI protocol's endpoint it. The proposed charter has it being an agent in the Guest OS. As John Levine points out, this is essentially VNC (for which we now have RFC 6143) and/or Microsoft's RDC. It actually has nothing to do with "virtual" at all: it works as well for OSs running on real boxes as it does for guest OSs running in a hypervisor. FWIW, I think that RFC 6143 could be extended to have some other features that are useful, such as file transfer and better security. But I don't think the IETF has any special knowledge (or lack thereof) for such extensions. If you think that the VDI ends at the hypervisor, as I have proposed, this becomes a protocol that is more in line with the normal IETF work. > Roughly what percentage of Guest OS and VM systems have network > connectivity of the kind that would enable use of a protocol instead of > an API? That might be helpful information. It is safe to assume that all hypervisors have network connectivity. The interesting question is for the guest OSs, and there are multiple answers. Many guest OSs have network connectivity to other guest OSs but not to the Internet: they are by design on switches with no contact outside the LAN. Some guest OSs are dual-homed, acting as gateways / firewalls / routers for other guest OSs on their LAN. And an often-ignored scenario is a guest OS that has no network connectivity because it is coming up for the first time or has been purposely pulled off all networks for security reasons. >> A different model would be that the VDI Client has a new protocol to >> talk to the host system, and that the host system has an API for talking >> to the Guest OS in a way that would reach the Virtual Desktop Agent. >> This model has some advantages over the narrow one in the charter. For >> example, the protocol would allow control over Guest OSs, such as "start >> up machine X" and "send text to the console on machine X". These will >> work even if the Guest OS does not support the API, or if it does not >> currently have network connectivity. > > Yes, that does seem like a powerful model. Roughly what percentage of > VDI systems are architected that way currently, as opposed to the model > outlined in the proposed charter? All. That is, all hypervisors have methods to start up guest OSs, shut them down, and so on. Some have CLI languages to do so; a good example is VirtualBox's VBoxManage CLI. > How does what you've described differ > from draft-wang-clouds-vdi-problem-statement-00? It's hard to say, but I don't see anything in that draft the requirement to control the hypervisor. It seems like the draft is really about supplanting VNC and RDC. Again, that might be a useful exercise, but the draft does not address whether it is better to just extend VNC or to start fresh. > (And as I'm sure you've thought about, the security considerations might > get "interesting" if the VDI client has permissions to do things at the > host level.) Of course they have those permissions: that's what the entire draft is about. You want to be remote hands on the guest OS. >> The proposed WG could come up with requirements for both the >> client-to-host protocol and the API between the host and the desktop >> agent, and the two could clearly have some good interactions. > > In your opinion, which would come first -- the protocol or the API? The protocol. The API already exists in VNC and RDC. Defining how the protocol interacts with the APIs is quite easy relative to defining what needs to be in the protocol itself. OTOH, if there is not much interest in defining the protocol, I don't think a WG is needed. From wang.jun17@zte.com.cn Wed Mar 9 22:30:48 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9223A68BF for ; Wed, 9 Mar 2011 22:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y64NvWJCZuyG for ; Wed, 9 Mar 2011 22:30:46 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id B9F733A68C6 for ; Wed, 9 Mar 2011 22:30:45 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205951193944097; Thu, 10 Mar 2011 14:26:39 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.4784611511; Thu, 10 Mar 2011 14:24:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p2A6O5m8077299; Thu, 10 Mar 2011 14:24:05 +0800 (GMT-8) (envelope-from wang.jun17@zte.com.cn) In-Reply-To: <4D76EA41.3030204@stpeter.im> To: Peter Saint-Andre MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.jun17@zte.com.cn Date: Thu, 10 Mar 2011 14:24:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-10 14:24:06, Serialize complete at 2011-03-10 14:24:06 Content-Type: multipart/alternative; boundary="=_alternative 002321004825784F_=" X-MAIL: mse01.zte.com.cn p2A6O5m8077299 Cc: Suren Karavettil , "So, Ning" , meng.yu@zte.com.cn, apps-discuss@ietf.org, Paul Hoffman Subject: Re: [apps-discuss] proposal for Virtual desktop infrastructure (VDI) work in APP area X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 06:30:48 -0000 This is a multipart message in MIME format. --=_alternative 002321004825784F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgcGV0ZXIgJiBhbGwsDQogICBJIGhhdmUgcmVwbGllZCBQYXVsJ3MgbWFpbCBvbmNlLCBidXQg cmVqZWN0ZWQgYnkgdGhlIGFwcC1kaXNjdXNzIA0KbWFpbGxpc3QsIHNvIEknbSB0cnlpbmcgYWdh aW4gaGVyZS4NCiAgIEF0IHRoZSBzZWN0aW9uIDIuMSBpbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQg ZHJhZnQsIGJvdGggVkRBIGluIHRoZSANCmd1ZXN0IE9TIGFuZCBpbiB0aGUgaG9zdCBoYXZlIGJl ZW4gYnJpZWZseSBkaXNjdXNzZWQuIA0KICAgUmVnYXJkaW5nIHRoZSBBUElzIGJldHdlZW4gVkRB IGFuZCBob3N0IHN5c3RlbSwgSSB0aGluayBtb3N0IG9mIHRoZW0gDQphcmUgZXhpc3RpbmcgZGV2 aWNlIEkvTyBzcGVjaWZpY2F0aW9ucyBhbmQgaGFyZHdhcmUgcGxhdGZvcm0gc3BlY2lmaWMsIA0K d2hpY2ggc2hvdWxkIGJlIGxlZnQgZm9yIHN5c3RlbSBkZXZlbG9wZXJzJyBkZWNpc2lvbi4gQWN0 dWFsbHksIHdpdGhvdXQgDQphbnkgYWRkaXRpb25hbCBzb2Z0d2FyZSBpbnN0YWxsZWQgaW4gdGhl IGd1ZXN0LCB0aGUgaG9zdCBWREkgbW9kZWwgc3RpbGwgDQp3b3JrcyB3ZWxsLCBhbHRob3VnaCBu b3QgdmVyeSB3ZWxsLg0KDQpSdXNzZWxsDQoNCg0KUGV0ZXIgU2FpbnQtQW5kcmUgPHN0cGV0ZXJA c3RwZXRlci5pbT4g0LTT2iAyMDExLTAzLTA5IDEwOjQ3OjI5Og0KDQo+IDxoYXQgdHlwZT0naW5k aXZpZHVhbCcvPg0KPiANCj4gT24gMy81LzExIDQ6MTEgUE0sIFBhdWwgSG9mZm1hbiB3cm90ZToN Cj4gPiBGaXJzdCBvZmYsIEkgdGhpbmsgdGhpcyB3b3JrIGNvdWxkIGJlIHZlcnkgdXNlZnVsIGJv dGggaW4gdGhlIHNob3J0IA0KYW5kDQo+ID4gbG9uZyBydW4uIEkgYW0gc3dpbW1pbmcgaW4gdGhl c2UgaXNzdWVzIHRvZGF5IGluIG15IHdvcmssIHNvIHBsZWFzZSBkbw0KPiA+IG5vdCB0YWtlIHRo ZSByZXNwb25zZSBiZWxvdyBhcyBkaW1pbmlzaGluZyB0aGUgbmVlZC4NCj4gPiANCj4gPiBJIHF1 ZXN0aW9uIHdoZXRoZXIgb3Igbm90IHRoZSBJRVRGIHdvdWxkIGJlIHRoZSBiZXN0IHBsYWNlIGZv ciB0aGlzLiBJDQo+ID4gc2F5IHRoYXQgbm90IGJlY2F1c2UgIlNETyBYIHdvdWxkIGJlIGJldHRl ciB0aGFuIHRoZSBJRVRGIiBiZWNhdXNlIGlmDQo+ID4gdGhhdCB3ZXJlIHRoZSBjYXNlLCBTRE8g WCB3b3VsZCBoYXZlIGRvbmUgc28gYnkgbm93LiANCj4gDQo+IFBhdWwsIEknbSBub3Qgc3VyZSB0 aGF0IGZvbGxvd3MuIDopIE1hbnkgZmFjdG9ycyBhcmUgaW52b2x2ZWQgaW4gdGhlDQo+IHN0YW5k YXJkaXphdGlvbiAob3IgbGFjayB0aGVyZW9mKSB3aXRoaW4gYSBwYXJ0aWN1bGFyIHByb2JsZW0g ZG9tYWluLg0KPiANCj4gPiBIb3dldmVyLCBtb3N0IG9mDQo+ID4gdGhlIGludGVyZXN0aW5nIHdv cmsgaGVyZSBpcywgaW4gZmFjdCwgYW4gQVBJLiBOb3RlIHRoYXQgSSBhbSAqbm90KiANCm9uZQ0K PiA+IG9mIHRoZSBwZW9wbGUgd2hvIHNheXMgInRoZSBJRVRGIHsgZG9lc24ndCAvIGNhbid0IH0g ZG8gQVBJcyI7IEkgdGhpbmsNCj4gPiB3ZSBkby9jYW4gYXMgbG9uZyBhcyB3ZSBhcmUgdXBmcm9u dCBhYm91dCBpdC4NCj4gDQo+IEFub3RoZXIgcXVlc3Rpb24gaXM6IGNhbiB3ZSBkbyBpdCB3ZWxs PyBBbmQsIG1vcmUgc3BlY2lmaWNhbGx5LCBkbyB3ZQ0KPiBoYXZlIHJlYXNvbiB0byB0aGluayB0 aGF0IHdlIG1pZ2h0IGRvIGl0IHdlbGwgaW4gdGhlIHZpcnR1YWwgZGVza3RvcA0KPiBpbmZyYXN0 cnVjdHVyZSAoVkRJKSBzcGFjZT8NCj4gDQo+ID4gSW4gc3BlY2lmaWMgKGEgZml4ZWQgY2hhcnQp Og0KPiA+IA0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKyB8DQo+ID4gKy0tLS0tLS0tLS0tKyAgVkRJIHByb3RvY29sICB8 IHwgKy0tLS0tLS0tLS0tLS0tLS0tLSsgIHwgfA0KPiA+IHwgVkRJIENsaWVudHwtLS0tLS0tLS0t LS0tLS0tKyArIHwgVmlydHVhbCBEZXNrdG9wICB8ICB8IHwNCj4gPiArLS0tLS0tLS0tLS0rICAg ICAgICAgICAgICAgIHwgfCB8ICAgICBBZ2VudCAgICAgICAgfCAgfCB8DQo+ID4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8IHwgKy0tLS0tLS0tLS0tLS0tLS0tLSsgIHwgfA0KPiA+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB8ICAgICAgR3Vlc3QgT1MgICAgICAgICB8IHwN Cj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKyB8DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgVmlydHVhbCBNYWNo aW5lICAgICAgICAgfA0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBIb3N0ZWQg aW4gYSBEYXRhIENlbnRlciAgIHwNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ID4gDQo+ID4gR2l2ZW4gdGhhdCB0aGUgdGV4 dCBvZiB0aGUgcHJvcG9zZWQgY2hhcnRlciBzYXlzIHRoYXQgdGhlIHByb3RvY29sIA0Kd291bGQN Cj4gPiBiZSBiZXR3ZWVuIHRoZSBWREkgQ2xpZW50IGFuZCB0aGUgVmlydHVhbCBEZXNrdG9wIEFn ZW50Iiwgd2hpY2ggbWlnaHQgDQpiZQ0KPiA+IHNvZnR3YXJlIHJ1bm5pbmcgb24gYSBHdWVzdCBP UyB3aXRoIG5vIG5ldHdvcmsgY29ubmVjdGl2aXR5LCB0aGlzIHdpbGwNCj4gPiBiZSBhbiBBUEkg dW5sZXNzIHRoZXJlIGlzIGEgcmVxdWlyZW1lbnQgdGhhdCB0aGUgR3Vlc3QgT1MgaGFzIG5ldHdv cmsNCj4gPiBjb25uZWN0aXZpdHkgYXQgYSBrbm93biBhbmQgcHJlZGljdGFibGUgYWRkcmVzcywg YW5kIHRoYXQgdGhlIFZpcnR1YWwNCj4gPiBNYWNoaW5lIChhY3R1YWxseSwgdGhlIGhvc3Qgc3lz dGVtKSBhbHNvIGhhcyBuZXR3b3JrIGNvbm5lY3Rpdml0eSBhdCBhDQo+ID4ga25vd24gYW5kIHBy ZWRpY3RhYmxlIGFkZHJlc3MsIGFuZCBuZWl0aGVyIGlzIGZpcmV3YWxsZWQgZnJvbSB0aGUgVkRJ DQo+ID4gY2xpZW50Lg0KPiANCj4gUm91Z2hseSB3aGF0IHBlcmNlbnRhZ2Ugb2YgR3Vlc3QgT1Mg YW5kIFZNIHN5c3RlbXMgaGF2ZSBuZXR3b3JrDQo+IGNvbm5lY3Rpdml0eSBvZiB0aGUga2luZCB0 aGF0IHdvdWxkIGVuYWJsZSB1c2Ugb2YgYSBwcm90b2NvbCBpbnN0ZWFkIG9mDQo+IGFuIEFQST8g VGhhdCBtaWdodCBiZSBoZWxwZnVsIGluZm9ybWF0aW9uLg0KPiANCj4gPiBBIGRpZmZlcmVudCBt b2RlbCB3b3VsZCBiZSB0aGF0IHRoZSBWREkgQ2xpZW50IGhhcyBhIG5ldyBwcm90b2NvbCB0bw0K PiA+IHRhbGsgdG8gdGhlIGhvc3Qgc3lzdGVtLCBhbmQgdGhhdCB0aGUgaG9zdCBzeXN0ZW0gaGFz IGFuIEFQSSBmb3IgDQp0YWxraW5nDQo+ID4gdG8gdGhlIEd1ZXN0IE9TIGluIGEgd2F5IHRoYXQg d291bGQgcmVhY2ggdGhlIFZpcnR1YWwgRGVza3RvcCBBZ2VudC4NCj4gPiBUaGlzIG1vZGVsIGhh cyBzb21lIGFkdmFudGFnZXMgb3ZlciB0aGUgbmFycm93IG9uZSBpbiB0aGUgY2hhcnRlci4gRm9y DQo+ID4gZXhhbXBsZSwgdGhlIHByb3RvY29sIHdvdWxkIGFsbG93IGNvbnRyb2wgb3ZlciBHdWVz dCBPU3MsIHN1Y2ggYXMgDQoic3RhcnQNCj4gPiB1cCBtYWNoaW5lIFgiIGFuZCAic2VuZCB0ZXh0 IHRvIHRoZSBjb25zb2xlIG9uIG1hY2hpbmUgWCIuIFRoZXNlIHdpbGwNCj4gPiB3b3JrIGV2ZW4g aWYgdGhlIEd1ZXN0IE9TIGRvZXMgbm90IHN1cHBvcnQgdGhlIEFQSSwgb3IgaWYgaXQgZG9lcyBu b3QNCj4gPiBjdXJyZW50bHkgaGF2ZSBuZXR3b3JrIGNvbm5lY3Rpdml0eS4NCj4gDQo+IFllcywg dGhhdCBkb2VzIHNlZW0gbGlrZSBhIHBvd2VyZnVsIG1vZGVsLiBSb3VnaGx5IHdoYXQgcGVyY2Vu dGFnZSBvZg0KPiBWREkgc3lzdGVtcyBhcmUgYXJjaGl0ZWN0ZWQgdGhhdCB3YXkgY3VycmVudGx5 LCBhcyBvcHBvc2VkIHRvIHRoZSBtb2RlbA0KPiBvdXRsaW5lZCBpbiB0aGUgcHJvcG9zZWQgY2hh cnRlcj8gSG93IGRvZXMgd2hhdCB5b3UndmUgZGVzY3JpYmVkIGRpZmZlcg0KPiBmcm9tIGRyYWZ0 LXdhbmctY2xvdWRzLXZkaS1wcm9ibGVtLXN0YXRlbWVudC0wMD8NCj4gDQo+IChBbmQgYXMgSSdt IHN1cmUgeW91J3ZlIHRob3VnaHQgYWJvdXQsIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBt aWdodA0KPiBnZXQgImludGVyZXN0aW5nIiBpZiB0aGUgVkRJIGNsaWVudCBoYXMgcGVybWlzc2lv bnMgdG8gZG8gdGhpbmdzIGF0IHRoZQ0KPiBob3N0IGxldmVsLikNCj4gDQo+ID4gVGhlIHByb3Bv c2VkIFdHIGNvdWxkIGNvbWUgdXAgd2l0aCByZXF1aXJlbWVudHMgZm9yIGJvdGggdGhlDQo+ID4g Y2xpZW50LXRvLWhvc3QgcHJvdG9jb2wgYW5kIHRoZSBBUEkgYmV0d2VlbiB0aGUgaG9zdCBhbmQg dGhlIGRlc2t0b3ANCj4gPiBhZ2VudCwgYW5kIHRoZSB0d28gY291bGQgY2xlYXJseSBoYXZlIHNv bWUgZ29vZCBpbnRlcmFjdGlvbnMuDQo+IA0KPiBJbiB5b3VyIG9waW5pb24sIHdoaWNoIHdvdWxk IGNvbWUgZmlyc3QgLS0gdGhlIHByb3RvY29sIG9yIHRoZSBBUEk/DQo+IA0KPiA+IChBbmQgZm9y IHRob3NlIG9mIHlvdSB3aG8gd2FudCB0byBjb21lIHVwIHRvIHNwZWVkIG9uIHRoZSB0ZXJtaW5v bG9neQ0KPiA+IHVzZWQgaW4gdmlydHVhbGl6YXRpb24gYW5kIHNvbWUgb2YgdGhlIHNlY3VyaXR5 IGlzc3VlcywgcGxlYXNlIHNlZSANCk5JU1QNCj4gPiBTUCA4MDAtMTI1DQo+ID4gDQo8aHR0cDov L2NzcmMubmlzdC5nb3YvcHVibGljYXRpb25zL25pc3RwdWJzLzgwMC0xMjUvU1A4MDAtMTI1LWZp bmFsLnBkZj4uDQo+IA0KPiBUaGFua3MgZm9yIHByb3ZpZGluZyB0aGUgcmVmZXJlbmNlLg0KPiAN Cj4gUGV0ZXINCj4gDQo+IC0tIA0KPiBQZXRlciBTYWludC1BbmRyZQ0KPiBodHRwczovL3N0cGV0 ZXIuaW0vDQo+IA0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0 aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25m aWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFp biBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMg b2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxl cyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFy ZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxl YXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJl c3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4N ClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpU RSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 002321004825784F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIHBldGVyICZhbXA7IGFsbCw8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtJ IGhhdmUgcmVwbGllZCBQYXVsJ3MgbWFpbA0Kb25jZSwgYnV0IHJlamVjdGVkIGJ5IHRoZSBhcHAt ZGlzY3VzcyBtYWlsbGlzdCwgc28gSSdtIHRyeWluZyBhZ2FpbiBoZXJlLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0F0IHRoZSBzZWN0aW9u IDIuMSBpbiB0aGUNCnByb2JsZW0gc3RhdGVtZW50IGRyYWZ0LCBib3RoIFZEQSBpbiB0aGUgZ3Vl c3QgT1MgYW5kIGluIHRoZSBob3N0IGhhdmUNCmJlZW4gYnJpZWZseSBkaXNjdXNzZWQuIDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1JlZ2Fy ZGluZyB0aGUgQVBJcyBiZXR3ZWVuDQpWREEgYW5kIGhvc3Qgc3lzdGVtLCBJIHRoaW5rIG1vc3Qg b2YgdGhlbSAmbmJzcDthcmUgZXhpc3RpbmcgZGV2aWNlIEkvTw0Kc3BlY2lmaWNhdGlvbnMgYW5k IGhhcmR3YXJlIHBsYXRmb3JtIHNwZWNpZmljLCB3aGljaCBzaG91bGQgYmUgbGVmdCBmb3INCnN5 c3RlbSBkZXZlbG9wZXJzJyBkZWNpc2lvbi4gQWN0dWFsbHksIHdpdGhvdXQgYW55IGFkZGl0aW9u YWwgc29mdHdhcmUNCmluc3RhbGxlZCBpbiB0aGUgZ3Vlc3QsIHRoZSBob3N0IFZESSBtb2RlbCBz dGlsbCB3b3JrcyB3ZWxsLCBhbHRob3VnaCBub3QNCnZlcnkgd2VsbC48YnI+DQo8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJ1c3NlbGw8YnI+DQo8L2ZvbnQ+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5QZXRlciBTYWludC1BbmRyZSAmbHQ7c3RwZXRlckBz dHBldGVyLmltJmd0OyDQtNPaDQoyMDExLTAzLTA5IDEwOjQ3OjI5Ojxicj4NCjxicj4NCiZndDsg Jmx0O2hhdCB0eXBlPSdpbmRpdmlkdWFsJy8mZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDMv NS8xMSA0OjExIFBNLCBQYXVsIEhvZmZtYW4gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IEZpcnN0IG9m ZiwgSSB0aGluayB0aGlzIHdvcmsgY291bGQgYmUgdmVyeSB1c2VmdWwgYm90aCBpbiB0aGUNCnNo b3J0IGFuZDxicj4NCiZndDsgJmd0OyBsb25nIHJ1bi4gSSBhbSBzd2ltbWluZyBpbiB0aGVzZSBp c3N1ZXMgdG9kYXkgaW4gbXkgd29yaywgc28NCnBsZWFzZSBkbzxicj4NCiZndDsgJmd0OyBub3Qg dGFrZSB0aGUgcmVzcG9uc2UgYmVsb3cgYXMgZGltaW5pc2hpbmcgdGhlIG5lZWQuPGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJIHF1ZXN0aW9uIHdoZXRoZXIgb3Igbm90IHRoZSBJRVRG IHdvdWxkIGJlIHRoZSBiZXN0IHBsYWNlIGZvcg0KdGhpcy4gSTxicj4NCiZndDsgJmd0OyBzYXkg dGhhdCBub3QgYmVjYXVzZSAmcXVvdDtTRE8gWCB3b3VsZCBiZSBiZXR0ZXIgdGhhbiB0aGUgSUVU RiZxdW90Ow0KYmVjYXVzZSBpZjxicj4NCiZndDsgJmd0OyB0aGF0IHdlcmUgdGhlIGNhc2UsIFNE TyBYIHdvdWxkIGhhdmUgZG9uZSBzbyBieSBub3cuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBQYXVs LCBJJ20gbm90IHN1cmUgdGhhdCBmb2xsb3dzLiA6KSBNYW55IGZhY3RvcnMgYXJlIGludm9sdmVk IGluIHRoZTxicj4NCiZndDsgc3RhbmRhcmRpemF0aW9uIChvciBsYWNrIHRoZXJlb2YpIHdpdGhp biBhIHBhcnRpY3VsYXIgcHJvYmxlbSBkb21haW4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsg SG93ZXZlciwgbW9zdCBvZjxicj4NCiZndDsgJmd0OyB0aGUgaW50ZXJlc3Rpbmcgd29yayBoZXJl IGlzLCBpbiBmYWN0LCBhbiBBUEkuIE5vdGUgdGhhdCBJIGFtDQoqbm90KiBvbmU8YnI+DQomZ3Q7 ICZndDsgb2YgdGhlIHBlb3BsZSB3aG8gc2F5cyAmcXVvdDt0aGUgSUVURiB7IGRvZXNuJ3QgLyBj YW4ndCB9IGRvDQpBUElzJnF1b3Q7OyBJIHRoaW5rPGJyPg0KJmd0OyAmZ3Q7IHdlIGRvL2NhbiBh cyBsb25nIGFzIHdlIGFyZSB1cGZyb250IGFib3V0IGl0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBB bm90aGVyIHF1ZXN0aW9uIGlzOiBjYW4gd2UgZG8gaXQgd2VsbD8gQW5kLCBtb3JlIHNwZWNpZmlj YWxseSwgZG8NCndlPGJyPg0KJmd0OyBoYXZlIHJlYXNvbiB0byB0aGluayB0aGF0IHdlIG1pZ2h0 IGRvIGl0IHdlbGwgaW4gdGhlIHZpcnR1YWwgZGVza3RvcDxicj4NCiZndDsgaW5mcmFzdHJ1Y3R1 cmUgKFZESSkgc3BhY2U/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgSW4gc3BlY2lmaWMgKGEg Zml4ZWQgY2hhcnQpOjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7fCArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIHw8YnI+DQomZ3Q7ICZn dDsgKy0tLS0tLS0tLS0tKyAmbmJzcDtWREkgcHJvdG9jb2wgJm5ic3A7fCB8ICstLS0tLS0tLS0t LS0tLS0tLS0rDQombmJzcDt8IHw8YnI+DQomZ3Q7ICZndDsgfCBWREkgQ2xpZW50fC0tLS0tLS0t LS0tLS0tLS0rICsgfCBWaXJ0dWFsIERlc2t0b3AgJm5ic3A7fCAmbmJzcDt8DQp8PGJyPg0KJmd0 OyAmZ3Q7ICstLS0tLS0tLS0tLSsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDt8IHwgfCAmbmJzcDsgJm5ic3A7IEFnZW50ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7fCB8PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgfCArLS0tLS0tLS0tLS0tLS0tLS0t KyAmbmJzcDt8DQp8PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3wgfCAmbmJzcDsgJm5ic3A7ICZuYnNwO0d1ZXN0DQpPUyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCB8PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKyB8PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3wgJm5ic3A7IFZpcnR1YWwgTWFjaGluZSAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7fCBIb3N0ZWQgaW4gYSBEYXRhIENlbnRlciAmbmJzcDsNCnw8YnI+ DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSs8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7IEdpdmVuIHRoYXQgdGhlIHRleHQgb2YgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgc2F5cyB0 aGF0IHRoZSBwcm90b2NvbA0Kd291bGQ8YnI+DQomZ3Q7ICZndDsgYmUgYmV0d2VlbiB0aGUgVkRJ IENsaWVudCBhbmQgdGhlIFZpcnR1YWwgRGVza3RvcCBBZ2VudCZxdW90OywNCndoaWNoIG1pZ2h0 IGJlPGJyPg0KJmd0OyAmZ3Q7IHNvZnR3YXJlIHJ1bm5pbmcgb24gYSBHdWVzdCBPUyB3aXRoIG5v IG5ldHdvcmsgY29ubmVjdGl2aXR5LA0KdGhpcyB3aWxsPGJyPg0KJmd0OyAmZ3Q7IGJlIGFuIEFQ SSB1bmxlc3MgdGhlcmUgaXMgYSByZXF1aXJlbWVudCB0aGF0IHRoZSBHdWVzdCBPUyBoYXMNCm5l dHdvcms8YnI+DQomZ3Q7ICZndDsgY29ubmVjdGl2aXR5IGF0IGEga25vd24gYW5kIHByZWRpY3Rh YmxlIGFkZHJlc3MsIGFuZCB0aGF0IHRoZQ0KVmlydHVhbDxicj4NCiZndDsgJmd0OyBNYWNoaW5l IChhY3R1YWxseSwgdGhlIGhvc3Qgc3lzdGVtKSBhbHNvIGhhcyBuZXR3b3JrIGNvbm5lY3Rpdml0 eQ0KYXQgYTxicj4NCiZndDsgJmd0OyBrbm93biBhbmQgcHJlZGljdGFibGUgYWRkcmVzcywgYW5k IG5laXRoZXIgaXMgZmlyZXdhbGxlZCBmcm9tDQp0aGUgVkRJPGJyPg0KJmd0OyAmZ3Q7IGNsaWVu dC48YnI+DQomZ3Q7IDxicj4NCiZndDsgUm91Z2hseSB3aGF0IHBlcmNlbnRhZ2Ugb2YgR3Vlc3Qg T1MgYW5kIFZNIHN5c3RlbXMgaGF2ZSBuZXR3b3JrPGJyPg0KJmd0OyBjb25uZWN0aXZpdHkgb2Yg dGhlIGtpbmQgdGhhdCB3b3VsZCBlbmFibGUgdXNlIG9mIGEgcHJvdG9jb2wgaW5zdGVhZA0Kb2Y8 YnI+DQomZ3Q7IGFuIEFQST8gVGhhdCBtaWdodCBiZSBoZWxwZnVsIGluZm9ybWF0aW9uLjxicj4N CiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEEgZGlmZmVyZW50IG1vZGVsIHdvdWxkIGJlIHRoYXQgdGhl IFZESSBDbGllbnQgaGFzIGEgbmV3IHByb3RvY29sDQp0bzxicj4NCiZndDsgJmd0OyB0YWxrIHRv IHRoZSBob3N0IHN5c3RlbSwgYW5kIHRoYXQgdGhlIGhvc3Qgc3lzdGVtIGhhcyBhbiBBUEkNCmZv ciB0YWxraW5nPGJyPg0KJmd0OyAmZ3Q7IHRvIHRoZSBHdWVzdCBPUyBpbiBhIHdheSB0aGF0IHdv dWxkIHJlYWNoIHRoZSBWaXJ0dWFsIERlc2t0b3ANCkFnZW50Ljxicj4NCiZndDsgJmd0OyBUaGlz IG1vZGVsIGhhcyBzb21lIGFkdmFudGFnZXMgb3ZlciB0aGUgbmFycm93IG9uZSBpbiB0aGUgY2hh cnRlci4NCkZvcjxicj4NCiZndDsgJmd0OyBleGFtcGxlLCB0aGUgcHJvdG9jb2wgd291bGQgYWxs b3cgY29udHJvbCBvdmVyIEd1ZXN0IE9Tcywgc3VjaA0KYXMgJnF1b3Q7c3RhcnQ8YnI+DQomZ3Q7 ICZndDsgdXAgbWFjaGluZSBYJnF1b3Q7IGFuZCAmcXVvdDtzZW5kIHRleHQgdG8gdGhlIGNvbnNv bGUgb24gbWFjaGluZQ0KWCZxdW90Oy4gVGhlc2Ugd2lsbDxicj4NCiZndDsgJmd0OyB3b3JrIGV2 ZW4gaWYgdGhlIEd1ZXN0IE9TIGRvZXMgbm90IHN1cHBvcnQgdGhlIEFQSSwgb3IgaWYgaXQNCmRv ZXMgbm90PGJyPg0KJmd0OyAmZ3Q7IGN1cnJlbnRseSBoYXZlIG5ldHdvcmsgY29ubmVjdGl2aXR5 Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBZZXMsIHRoYXQgZG9lcyBzZWVtIGxpa2UgYSBwb3dlcmZ1 bCBtb2RlbC4gUm91Z2hseSB3aGF0IHBlcmNlbnRhZ2UNCm9mPGJyPg0KJmd0OyBWREkgc3lzdGVt cyBhcmUgYXJjaGl0ZWN0ZWQgdGhhdCB3YXkgY3VycmVudGx5LCBhcyBvcHBvc2VkIHRvIHRoZQ0K bW9kZWw8YnI+DQomZ3Q7IG91dGxpbmVkIGluIHRoZSBwcm9wb3NlZCBjaGFydGVyPyBIb3cgZG9l cyB3aGF0IHlvdSd2ZSBkZXNjcmliZWQgZGlmZmVyPGJyPg0KJmd0OyBmcm9tIGRyYWZ0LXdhbmct Y2xvdWRzLXZkaS1wcm9ibGVtLXN0YXRlbWVudC0wMD88YnI+DQomZ3Q7IDxicj4NCiZndDsgKEFu ZCBhcyBJJ20gc3VyZSB5b3UndmUgdGhvdWdodCBhYm91dCwgdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zDQptaWdodDxicj4NCiZndDsgZ2V0ICZxdW90O2ludGVyZXN0aW5nJnF1b3Q7IGlmIHRo ZSBWREkgY2xpZW50IGhhcyBwZXJtaXNzaW9ucyB0byBkbw0KdGhpbmdzIGF0IHRoZTxicj4NCiZn dDsgaG9zdCBsZXZlbC4pPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlIHByb3Bvc2VkIFdH IGNvdWxkIGNvbWUgdXAgd2l0aCByZXF1aXJlbWVudHMgZm9yIGJvdGggdGhlPGJyPg0KJmd0OyAm Z3Q7IGNsaWVudC10by1ob3N0IHByb3RvY29sIGFuZCB0aGUgQVBJIGJldHdlZW4gdGhlIGhvc3Qg YW5kIHRoZQ0KZGVza3RvcDxicj4NCiZndDsgJmd0OyBhZ2VudCwgYW5kIHRoZSB0d28gY291bGQg Y2xlYXJseSBoYXZlIHNvbWUgZ29vZCBpbnRlcmFjdGlvbnMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEluIHlvdXIgb3Bpbmlvbiwgd2hpY2ggd291bGQgY29tZSBmaXJzdCAtLSB0aGUgcHJvdG9jb2wg b3IgdGhlIEFQST88YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyAoQW5kIGZvciB0aG9zZSBvZiB5 b3Ugd2hvIHdhbnQgdG8gY29tZSB1cCB0byBzcGVlZCBvbiB0aGUgdGVybWlub2xvZ3k8YnI+DQom Z3Q7ICZndDsgdXNlZCBpbiB2aXJ0dWFsaXphdGlvbiBhbmQgc29tZSBvZiB0aGUgc2VjdXJpdHkg aXNzdWVzLCBwbGVhc2UNCnNlZSBOSVNUPGJyPg0KJmd0OyAmZ3Q7IFNQIDgwMC0xMjU8YnI+DQom Z3Q7ICZndDsgJmx0O2h0dHA6Ly9jc3JjLm5pc3QuZ292L3B1YmxpY2F0aW9ucy9uaXN0cHVicy84 MDAtMTI1L1NQODAwLTEyNS1maW5hbC5wZGYmZ3Q7Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFu a3MgZm9yIHByb3ZpZGluZyB0aGUgcmVmZXJlbmNlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBQZXRl cjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IFBldGVyIFNhaW50LUFuZHJlPGJy Pg0KJmd0OyBodHRwczovL3N0cGV0ZXIuaW0vPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4N Cjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3Rp Y2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNw O3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNw O21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7 UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQm bmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNw O25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtj b250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNw O290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5i c3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRp YWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZu YnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50 aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4m bmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtl bWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUm bmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZu YnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZu YnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7 c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5l ZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDta VEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 002321004825784F_=-- From derhoermi@gmx.net Wed Mar 9 16:54:24 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093CC3A6B1F for ; Wed, 9 Mar 2011 16:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcl04TjLoV5u for ; Wed, 9 Mar 2011 16:54:22 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 7D4AB3A6B1D for ; Wed, 9 Mar 2011 16:54:21 -0800 (PST) Received: (qmail invoked by alias); 10 Mar 2011 00:55:37 -0000 Received: from dslb-094-222-129-148.pools.arcor-ip.net (EHLO HIVE) [94.222.129.148] by mail.gmx.net (mp054) with SMTP; 10 Mar 2011 01:55:37 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX195AUR1vHl5hZg4NjZqQExGC4Quaw2ZAyEhD4eYZq B39zEzcxEw/1ya From: Bjoern Hoehrmann To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Date: Thu, 10 Mar 2011 01:55:35 +0100 Message-ID: References: <4D6FBE4D.10602@isode.com> <6.2.5.6.2.20110308164758.0be3c0a8@resistor.net> <4D76FB18.1040304@stpeter.im> <4D772FD6.4080305@it.aoyama.ac.jp> In-Reply-To: <4D772FD6.4080305@it.aoyama.ac.jp> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Thu, 10 Mar 2011 08:19:23 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 00:54:24 -0000 * Martin J. Dürst wrote: >[Assuming the above also applies to W3C] I'm no longer working for W3C, >but if I still did, and in particular if I still was in charge of >coordinating these registration requests, I'd very clearly and >explicitly not be happy with this. In my view, one of the main points of >RFC 4288 was exactly to get away from the need to have things in two >places, and to get away from the need for people who never before and >never after wrote Internet Drafts to get familiar with all the details. > >If we think RFC 4288 has failed, we should fix it. (I for my part don't >think it has failed, at least not in this respect.) I am not sure whether RFC 4288 has failed in this respect generally, but it seems pretty clear that the W3C has been largely unable to follow the much simpler process here. If you look at the not-very-well-maintained index at http://www.w3.org/2002/06/registering-mediatype.html you have entries there like "Check in November 2009" under "Plans". It's not a total failure, but W3C staff obviously can't do so much as check, say, a review request to ietf-types goes out along with a Last Call or that the types have actually been registered when a document is to move to CR, PR REC, "Second Edition" levels. Putting this around, a bit of a summary of the problems the IESG has en- countered with registration requests from other standards organizations that don't come as I-Ds would help in making suggestions. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From mnot@mnot.net Thu Mar 10 14:50:36 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CA7E3A6A74 for ; Thu, 10 Mar 2011 14:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.598 X-Spam-Level: X-Spam-Status: No, score=-104.598 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRfZBLfxGANS for ; Thu, 10 Mar 2011 14:50:35 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 8C99C3A6407 for ; Thu, 10 Mar 2011 14:50:35 -0800 (PST) Received: from l2tp-8-236.corp.yahoo.com (unknown [209.131.62.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D3D47509E2 for ; Thu, 10 Mar 2011 17:51:47 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 10 Mar 2011 14:51:46 -0800 Message-Id: <4BC10742-7C69-4207-AE32-081A208B8DC5@mnot.net> To: Apps Discuss Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [apps-discuss] Wiki for bar bofs? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 22:50:36 -0000 Is there a wiki page for bar bofs being put together yet? There's text for a link on the meeting page, but no actual link... -- Mark Nottingham http://www.mnot.net/ From sm@resistor.net Thu Mar 10 19:11:50 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 891533A6B5D for ; Thu, 10 Mar 2011 19:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnvlVuLkU7+S for ; Thu, 10 Mar 2011 19:11:49 -0800 (PST) Received: from mx.elandsys.com (eland-1-pt.tunnel.tserv15.lax1.ipv6.he.net [IPv6:2001:470:c:d43::2]) by core3.amsl.com (Postfix) with ESMTP id 38BD13A6B52 for ; Thu, 10 Mar 2011 19:11:48 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Alpha0) with ESMTP id p2B3D1de009571; Thu, 10 Mar 2011 19:13:03 -0800 (PST) Message-Id: <6.2.5.6.2.20110310184422.09896d80@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 10 Mar 2011 18:45:13 -0800 To: Mark Nottingham From: SM In-Reply-To: <4BC10742-7C69-4207-AE32-081A208B8DC5@mnot.net> References: <4BC10742-7C69-4207-AE32-081A208B8DC5@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Apps Discuss Subject: Re: [apps-discuss] Wiki for bar bofs? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 03:11:50 -0000 Hi Mark, At 14:51 10-03-2011, Mark Nottingham wrote: >Is there a wiki page for bar bofs being put together yet? http://trac.tools.ietf.org/bof/trac/wiki Regards, -sm From mnot@mnot.net Thu Mar 10 20:12:59 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78DD43A6ABA for ; Thu, 10 Mar 2011 20:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wzZnvJVJGp6 for ; Thu, 10 Mar 2011 20:12:58 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 7FC213A6A8D for ; Thu, 10 Mar 2011 20:12:58 -0800 (PST) Received: from [10.10.1.100] (unknown [67.111.52.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B44CD22E1EB; Thu, 10 Mar 2011 23:14:10 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <6.2.5.6.2.20110310184422.09896d80@resistor.net> Date: Thu, 10 Mar 2011 20:14:08 -0800 Content-Transfer-Encoding: 7bit Message-Id: <48FD3A57-6FC4-4A2B-8288-79A233F413B6@mnot.net> References: <4BC10742-7C69-4207-AE32-081A208B8DC5@mnot.net> <6.2.5.6.2.20110310184422.09896d80@resistor.net> To: SM X-Mailer: Apple Mail (2.1082) Cc: Apps Discuss Subject: Re: [apps-discuss] Wiki for bar bofs? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 04:12:59 -0000 Not official BoFs, Bar BoFs. Cheers, On 10/03/2011, at 6:45 PM, SM wrote: > Hi Mark, > At 14:51 10-03-2011, Mark Nottingham wrote: >> Is there a wiki page for bar bofs being put together yet? > > http://trac.tools.ietf.org/bof/trac/wiki > > Regards, > -sm -- Mark Nottingham http://www.mnot.net/ From lars.eggert@nokia.com Thu Mar 10 22:49:51 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529533A687D for ; Thu, 10 Mar 2011 22:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.272 X-Spam-Level: X-Spam-Status: No, score=-103.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZk0pO3DGF54 for ; Thu, 10 Mar 2011 22:49:50 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 478633A6805 for ; Thu, 10 Mar 2011 22:49:50 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2B6p5bp029479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2011 08:51:06 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-25--603489480; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <48FD3A57-6FC4-4A2B-8288-79A233F413B6@mnot.net> Date: Fri, 11 Mar 2011 08:50:57 +0200 Message-Id: <2ECD9B78-E9AB-45C1-AFC6-347A2AC5F930@nokia.com> References: <4BC10742-7C69-4207-AE32-081A208B8DC5@mnot.net> <6.2.5.6.2.20110310184422.09896d80@resistor.net> <48FD3A57-6FC4-4A2B-8288-79A233F413B6@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Fri, 11 Mar 2011 08:51:02 +0200 (EET) X-Nokia-AV: Clean Cc: Gonzalo Camarillo , Apps Discuss Subject: Re: [apps-discuss] Wiki for bar bofs? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 06:49:51 -0000 --Apple-Mail-25--603489480 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2011-3-11, at 6:14, Mark Nottingham wrote: > Not official BoFs, Bar BoFs. This confusion nicely demonstrates why we're trying to push people to = call these things side meetings: = http://tools.ietf.org/html/draft-eggert-successful-bar-bof > On 10/03/2011, at 6:45 PM, SM wrote: >> At 14:51 10-03-2011, Mark Nottingham wrote: >>> Is there a wiki page for bar bofs being put together yet? >>=20 >> http://trac.tools.ietf.org/bof/trac/wiki Lars --Apple-Mail-25--603489480 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMxMTA2NTA1OFowIwYJKoZIhvcNAQkE MRYEFPCUcaY7JOA8jVzS7+rEI+rRId02MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB ALbysZz6uQREKebQHr0A0l84jAldIwB2bMgQlQwZMJ9nRVJMQipPooUg7UHmzELFQF/bwyzlKhTS UNZOwEbZun5rG811iMKKjNcR0uUAmYrnPyVwCd/StT4yWaNEC/z3tyxeBplY6Vllr6G8ZKDmExBk h0KgVGKyid/bIdlfsKnZWFkmBUweuv9puesj7UnQBPpjOFjcDljuYhRoorButl7GlyEYlA5NLSwh J6g0txhr6phw3jrA4aYRNJl1JPQ+zI2c1yMsOyNEvUX8a3q+OlyP8GE04l3R9mnW47k3Ab2L8+9D sD1p/1ZkECo8ZEtFrpkZw4iry9me0tZwOrrq3fYAAAAAAAA= --Apple-Mail-25--603489480-- From simon.perreault@viagenie.ca Fri Mar 11 05:16:55 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78283A6999 for ; Fri, 11 Mar 2011 05:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-uLWPx-3-vj for ; Fri, 11 Mar 2011 05:16:54 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 8BAB73A6835 for ; Fri, 11 Mar 2011 05:16:54 -0800 (PST) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E262221F64 for ; Fri, 11 Mar 2011 08:18:12 -0500 (EST) Message-ID: <4D7A2114.7010506@viagenie.ca> Date: Fri, 11 Mar 2011 08:18:12 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4BC10742-7C69-4207-AE32-081A208B8DC5@mnot.net> <6.2.5.6.2.20110310184422.09896d80@resistor.net> <48FD3A57-6FC4-4A2B-8288-79A233F413B6@mnot.net> <2ECD9B78-E9AB-45C1-AFC6-347A2AC5F930@nokia.com> In-Reply-To: <2ECD9B78-E9AB-45C1-AFC6-347A2AC5F930@nokia.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Wiki for bar bofs? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 13:16:56 -0000 On 2011-03-11 01:50, Lars Eggert wrote: > On 2011-3-11, at 6:14, Mark Nottingham wrote: >> Not official BoFs, Bar BoFs. > > This confusion nicely demonstrates why we're trying to push people to call these things side meetings: http://tools.ietf.org/html/draft-eggert-successful-bar-bof +1 I'm part of a group that is organizing a bar BoF. I would prefer ours to not be listed in the wiki, exactly for the reasons cited in the draft. As a general rule, if you know about the existence of a bar BoF, it means you're invited. Advertising it at large on a wiki breaks that filtering mechanism. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From jav@sics.se Fri Mar 11 06:00:30 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392163A6B81 for ; Fri, 11 Mar 2011 06:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svN4uGeOZVc6 for ; Fri, 11 Mar 2011 06:00:29 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 1825C3A6A90 for ; Fri, 11 Mar 2011 06:00:29 -0800 (PST) Received: from [193.10.66.199] (dab.sics.se [193.10.66.199]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 0575B40121; Fri, 11 Mar 2011 15:01:47 +0100 (CET) From: Javier Ubillos To: Simon Perreault In-Reply-To: <4D7A2114.7010506@viagenie.ca> References: <4BC10742-7C69-4207-AE32-081A208B8DC5@mnot.net> <6.2.5.6.2.20110310184422.09896d80@resistor.net> <48FD3A57-6FC4-4A2B-8288-79A233F413B6@mnot.net> <2ECD9B78-E9AB-45C1-AFC6-347A2AC5F930@nokia.com> <4D7A2114.7010506@viagenie.ca> Content-Type: text/plain; charset="UTF-8" Date: Fri, 11 Mar 2011 15:01:43 +0100 Message-ID: <1299852103.1975.85.camel@dab> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Wiki for bar bofs? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 14:00:30 -0000 On Fri, 2011-03-11 at 08:18 -0500, Simon Perreault wrote: > On 2011-03-11 01:50, Lars Eggert wrote: > > On 2011-3-11, at 6:14, Mark Nottingham wrote: > >> Not official BoFs, Bar BoFs. > > > > This confusion nicely demonstrates why we're trying to push people to call these things side meetings: http://tools.ietf.org/html/draft-eggert-successful-bar-bof > > +1 > > I'm part of a group that is organizing a bar BoF. I would prefer ours to > not be listed in the wiki, exactly for the reasons cited in the draft. > As a general rule, if you know about the existence of a bar BoF, it > means you're invited. Advertising it at large on a wiki breaks that > filtering mechanism. > > Simon I second the algorithm suggested by Klaas Wierenga. *** a "convener MUST buy 1 beer or alternative consumption for all invited attendees of the bar BoF" would solve lots of the problems you mention: - reduce the number of attendees - favor meeting in a bar - gives a more informal way of communication *** http://www.ietf.org/mail-archive/web/77attendees/current/msg00300.html // Javier From eburger@standardstrack.com Fri Mar 11 07:06:19 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D503A69F5 for ; Fri, 11 Mar 2011 07:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn+Iz6E5bnJK for ; Fri, 11 Mar 2011 07:06:17 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.249.249]) by core3.amsl.com (Postfix) with ESMTP id D329F3A69EF for ; Fri, 11 Mar 2011 07:06:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer; b=oRU2yUVaIbPWBzNAa652m8PSjOBMmrAYOGiSulN7yxLp0w6p2RhGFeerLKbuSnvZFBsLMCTskm9y73Una8bJK6C4CqpItCV8GYlHXZOqAWRwZfy4SEzlzadte6oeaXQK; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.134]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Py3u3-0000bT-7M for apps-discuss@ietf.org; Fri, 11 Mar 2011 07:05:19 -0800 From: Eric Burger Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-128--573693202; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 11 Mar 2011 10:07:33 -0500 In-Reply-To: <1299852103.1975.85.camel@dab> To: apps-discuss@ietf.org References: <4BC10742-7C69-4207-AE32-081A208B8DC5@mnot.net> <6.2.5.6.2.20110310184422.09896d80@resistor.net> <48FD3A57-6FC4-4A2B-8288-79A233F413B6@mnot.net> <2ECD9B78-E9AB-45C1-AFC6-347A2AC5F930@nokia.com> <4D7A2114.7010506@viagenie.ca> <1299852103.1975.85.camel@dab> Message-Id: X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com Subject: Re: [apps-discuss] Wiki for bar bofs? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 15:06:19 -0000 --Apple-Mail-128--573693202 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Last I looked, we are the IETF, not the ITU. You do not need permission to get together to drink. You do not need parliamentary rules to talk about stuff while you get = together to drink. IF you want to advertise your Bar BOF, PLEASE put an appropriate page on = the wiki. PEOPLE: IT IS A WIKI, not a moderated, official business only = web page. IF you do NOT want to advertise your Bar BOF, guess what? Do not = advertise it! Of course, if you want good conversation, do not forget to invite me and = buy me a beer :-) On Mar 11, 2011, at 9:01 AM, Javier Ubillos wrote: > On Fri, 2011-03-11 at 08:18 -0500, Simon Perreault wrote: >> On 2011-03-11 01:50, Lars Eggert wrote: >>> On 2011-3-11, at 6:14, Mark Nottingham wrote: >>>> Not official BoFs, Bar BoFs. >>>=20 >>> This confusion nicely demonstrates why we're trying to push people = to call these things side meetings: = http://tools.ietf.org/html/draft-eggert-successful-bar-bof >>=20 >> +1 >>=20 >> I'm part of a group that is organizing a bar BoF. I would prefer ours = to >> not be listed in the wiki, exactly for the reasons cited in the = draft. >> As a general rule, if you know about the existence of a bar BoF, it >> means you're invited. Advertising it at large on a wiki breaks that >> filtering mechanism. >>=20 >> Simon >=20 > I second the algorithm suggested by Klaas Wierenga. >=20 > *** > a "convener MUST buy 1 beer or alternative consumption for all invited > attendees of the bar BoF" would solve lots of the problems you = mention: >=20 > - reduce the number of attendees > - favor meeting in a bar > - gives a more informal way of communication > *** >=20 > http://www.ietf.org/mail-archive/web/77attendees/current/msg00300.html >=20 > // Javier >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-128--573693202 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAzMTExNTA3MzRaMCMGCSqGSIb3DQEJ BDEWBBQW2wJCI/74uxazmi8bqg97XMJFrDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAIXzHNzD3RxS9+afcqRn8LnKq6dIuSjvvtL6pV6veyrKdiPD EUpb0JY4cWKsHxZ20QNB0DENNak+Q4/Rg4/wh4n/5dZ+2kTA/xKmeD3n2E43NKKVu0NTnubDo2AB 3HS3kPKVCbnlwKMu7lT056Jox+HLhjJaxADdgD6JFcUK13d3K+8THov3HCai6n0V88EJWaDaJci/ Q/8sv61aiR7opMFc73szriT/auqHlBfgrmpIWbXVKeynpIGIrgF0bHyBaUCvwVt6gsrNQIsLnCIo zm4oeTmrUt4IJ1m1Mto/XmtVSAo7VezXa34tS8DFh+ZDwf+1Z55E4A8d6glhdv9HtRkAAAAAAAA= --Apple-Mail-128--573693202-- From mnot@mnot.net Fri Mar 11 08:43:27 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 711823A6B2C for ; Fri, 11 Mar 2011 08:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.313 X-Spam-Level: X-Spam-Status: No, score=-104.313 tagged_above=-999 required=5 tests=[AWL=-1.714, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8R6EMt0ui6d for ; Fri, 11 Mar 2011 08:43:26 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id D10DB3A6B2B for ; Fri, 11 Mar 2011 08:43:22 -0800 (PST) Received: from [10.10.1.100] (unknown [67.111.52.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AAD1822E1EB for ; Fri, 11 Mar 2011 11:44:35 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Mark Nottingham In-Reply-To: Date: Fri, 11 Mar 2011 08:44:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4183E07F-FE16-4D6B-A033-F310CE8B3C10@mnot.net> References: <4BC10742-7C69-4207-AE32-081A208B8DC5@mnot.net> <6.2.5.6.2.20110310184422.09896d80@resistor.net> <48FD3A57-6FC4-4A2B-8288-79A233F413B6@mnot.net> <2ECD9B78-E9AB-45C1-AFC6-347A2AC5F930@nokia.com> <4D7A2114.7010506@viagenie.ca> <1299852103.1975.85.camel@dab> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [apps-discuss] Wiki for bar bofs? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 16:43:27 -0000 I don't disagree with any particular point raised in this thread, but = for some of us, scheduling bar bofs is difficult, as there are many = people with overlapping areas of interest. Given that Bar BoFs (side = meetings, whatever -- if you want to change the terminology, the meeting = page is a good start!) are often high value, *some* sort of coordination = would be nice. On 11/03/2011, at 7:07 AM, Eric Burger wrote: > Last I looked, we are the IETF, not the ITU. >=20 > You do not need permission to get together to drink. >=20 > You do not need parliamentary rules to talk about stuff while you get = together to drink. >=20 > IF you want to advertise your Bar BOF, PLEASE put an appropriate page = on the wiki. PEOPLE: IT IS A WIKI, not a moderated, official business = only web page. >=20 > IF you do NOT want to advertise your Bar BOF, guess what? Do not = advertise it! >=20 > Of course, if you want good conversation, do not forget to invite me = and buy me a beer :-) >=20 >=20 > On Mar 11, 2011, at 9:01 AM, Javier Ubillos wrote: >=20 >> On Fri, 2011-03-11 at 08:18 -0500, Simon Perreault wrote: >>> On 2011-03-11 01:50, Lars Eggert wrote: >>>> On 2011-3-11, at 6:14, Mark Nottingham wrote: >>>>> Not official BoFs, Bar BoFs. >>>>=20 >>>> This confusion nicely demonstrates why we're trying to push people = to call these things side meetings: = http://tools.ietf.org/html/draft-eggert-successful-bar-bof >>>=20 >>> +1 >>>=20 >>> I'm part of a group that is organizing a bar BoF. I would prefer = ours to >>> not be listed in the wiki, exactly for the reasons cited in the = draft. >>> As a general rule, if you know about the existence of a bar BoF, it >>> means you're invited. Advertising it at large on a wiki breaks that >>> filtering mechanism. >>>=20 >>> Simon >>=20 >> I second the algorithm suggested by Klaas Wierenga. >>=20 >> *** >> a "convener MUST buy 1 beer or alternative consumption for all = invited >> attendees of the bar BoF" would solve lots of the problems you = mention: >>=20 >> - reduce the number of attendees >> - favor meeting in a bar >> - gives a more informal way of communication >> *** >>=20 >> = http://www.ietf.org/mail-archive/web/77attendees/current/msg00300.html >>=20 >> // Javier >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From fluffy@cisco.com Fri Mar 11 15:10:02 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060423A6A33 for ; Fri, 11 Mar 2011 15:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jl0kH-zPwEHi for ; Fri, 11 Mar 2011 15:10:00 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id DF42F3A6AB2 for ; Fri, 11 Mar 2011 15:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3259; q=dns/txt; s=iport; t=1299885081; x=1301094681; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=O+6+KH3TWqOepyin5JCpc2qdF1gbAaPbHN5X/2+jqA0=; b=UGCUDFzNP1XuukmyY90RMCY/usSktXIGnhBU63gOqEgdjzlDGlQRwsVK siEp1t77r7Lzc988vhLbNBnQ4pzm+7Ri29Bfi3zmtPA+b9+mocG3sFW1c EdMXU6DXucqOzD7Tz3mR8qsZPbEcjhavta8g9QlONQS103cgzXGQ8PgXY U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABk7ek2tJXHB/2dsb2JhbACmOHemNpwShWIEhSmHJoNK X-IronPort-AV: E=Sophos;i="4.62,305,1297036800"; d="scan'208";a="275067796" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-4.cisco.com with ESMTP; 11 Mar 2011 23:11:16 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2BNBFuW017574; Fri, 11 Mar 2011 23:11:15 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4183E07F-FE16-4D6B-A033-F310CE8B3C10@mnot.net> Date: Fri, 11 Mar 2011 16:13:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C630C0E-D2A2-423B-8B54-C5509067FC22@cisco.com> References: <4BC10742-7C69-4207-AE32-081A208B8DC5@mnot.net> <6.2.5.6.2.20110310184422.09896d80@resistor.net> <48FD3A57-6FC4-4A2B-8288-79A233F413B6@mnot.net> <2ECD9B78-E9AB-45C1-AFC6-347A2AC5F930@nokia.com> <4D7A2114.7010506@viagenie.ca> <1299852103.1975.85.camel@dab> <4183E07F-FE16-4D6B-A033-F310CE8B3C10@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1082) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Wiki for bar bofs? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 23:10:02 -0000 So back to Mark's questions, is there a WIKI page to help coordinate my = drinking problem, I hate to end up with a situation where the transport = guys are having a fine scotch at the same time the RAI guys were opening = some nice Bordeaux.=20 On Mar 11, 2011, at 9:44 AM, Mark Nottingham wrote: > I don't disagree with any particular point raised in this thread, but = for some of us, scheduling bar bofs is difficult, as there are many = people with overlapping areas of interest. Given that Bar BoFs (side = meetings, whatever -- if you want to change the terminology, the meeting = page is a good start!) are often high value, *some* sort of coordination = would be nice. >=20 >=20 > On 11/03/2011, at 7:07 AM, Eric Burger wrote: >=20 >> Last I looked, we are the IETF, not the ITU. >>=20 >> You do not need permission to get together to drink. >>=20 >> You do not need parliamentary rules to talk about stuff while you get = together to drink. >>=20 >> IF you want to advertise your Bar BOF, PLEASE put an appropriate page = on the wiki. PEOPLE: IT IS A WIKI, not a moderated, official business = only web page. >>=20 >> IF you do NOT want to advertise your Bar BOF, guess what? Do not = advertise it! >>=20 >> Of course, if you want good conversation, do not forget to invite me = and buy me a beer :-) >>=20 >>=20 >> On Mar 11, 2011, at 9:01 AM, Javier Ubillos wrote: >>=20 >>> On Fri, 2011-03-11 at 08:18 -0500, Simon Perreault wrote: >>>> On 2011-03-11 01:50, Lars Eggert wrote: >>>>> On 2011-3-11, at 6:14, Mark Nottingham wrote: >>>>>> Not official BoFs, Bar BoFs. >>>>>=20 >>>>> This confusion nicely demonstrates why we're trying to push people = to call these things side meetings: = http://tools.ietf.org/html/draft-eggert-successful-bar-bof >>>>=20 >>>> +1 >>>>=20 >>>> I'm part of a group that is organizing a bar BoF. I would prefer = ours to >>>> not be listed in the wiki, exactly for the reasons cited in the = draft. >>>> As a general rule, if you know about the existence of a bar BoF, it >>>> means you're invited. Advertising it at large on a wiki breaks that >>>> filtering mechanism. >>>>=20 >>>> Simon >>>=20 >>> I second the algorithm suggested by Klaas Wierenga. >>>=20 >>> *** >>> a "convener MUST buy 1 beer or alternative consumption for all = invited >>> attendees of the bar BoF" would solve lots of the problems you = mention: >>>=20 >>> - reduce the number of attendees >>> - favor meeting in a bar >>> - gives a more informal way of communication >>> *** >>>=20 >>> = http://www.ietf.org/mail-archive/web/77attendees/current/msg00300.html >>>=20 >>> // Javier >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From mnot@mnot.net Fri Mar 11 15:10:54 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271063A6AB2 for ; Fri, 11 Mar 2011 15:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.009 X-Spam-Level: X-Spam-Status: No, score=-104.009 tagged_above=-999 required=5 tests=[AWL=-1.411, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugvf9i66541S for ; Fri, 11 Mar 2011 15:10:53 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 0E3013A6A33 for ; Fri, 11 Mar 2011 15:10:53 -0800 (PST) Received: from l2tp-4-87.corp.yahoo.com (unknown [209.131.62.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 740E3509B3; Fri, 11 Mar 2011 18:12:06 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <3C630C0E-D2A2-423B-8B54-C5509067FC22@cisco.com> Date: Fri, 11 Mar 2011 15:12:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9EB818FD-5DCE-4E1D-8EAC-A487046BD4F5@mnot.net> References: <4BC10742-7C69-4207-AE32-081A208B8DC5@mnot.net> <6.2.5.6.2.20110310184422.09896d80@resistor.net> <48FD3A57-6FC4-4A2B-8288-79A233F413B6@mnot.net> <2ECD9B78-E9AB-45C1-AFC6-347A2AC5F930@nokia.com> <4D7A2114.7010506@viagenie.ca> <1299852103.1975.85.camel@dab> <4183E07F-FE16-4D6B-A033-F310CE8B3C10@mnot.net> <3C630C0E-D2A2-423B-8B54-C5509067FC22@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1082) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Wiki for bar bofs? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 23:10:54 -0000 Exactly. We can always cut out the middleman, of course. On 11/03/2011, at 3:13 PM, Cullen Jennings wrote: >=20 > So back to Mark's questions, is there a WIKI page to help coordinate = my drinking problem, I hate to end up with a situation where the = transport guys are having a fine scotch at the same time the RAI guys = were opening some nice Bordeaux.=20 >=20 >=20 > On Mar 11, 2011, at 9:44 AM, Mark Nottingham wrote: >=20 >> I don't disagree with any particular point raised in this thread, but = for some of us, scheduling bar bofs is difficult, as there are many = people with overlapping areas of interest. Given that Bar BoFs (side = meetings, whatever -- if you want to change the terminology, the meeting = page is a good start!) are often high value, *some* sort of coordination = would be nice. >>=20 >>=20 >> On 11/03/2011, at 7:07 AM, Eric Burger wrote: >>=20 >>> Last I looked, we are the IETF, not the ITU. >>>=20 >>> You do not need permission to get together to drink. >>>=20 >>> You do not need parliamentary rules to talk about stuff while you = get together to drink. >>>=20 >>> IF you want to advertise your Bar BOF, PLEASE put an appropriate = page on the wiki. PEOPLE: IT IS A WIKI, not a moderated, official = business only web page. >>>=20 >>> IF you do NOT want to advertise your Bar BOF, guess what? Do not = advertise it! >>>=20 >>> Of course, if you want good conversation, do not forget to invite me = and buy me a beer :-) >>>=20 >>>=20 >>> On Mar 11, 2011, at 9:01 AM, Javier Ubillos wrote: >>>=20 >>>> On Fri, 2011-03-11 at 08:18 -0500, Simon Perreault wrote: >>>>> On 2011-03-11 01:50, Lars Eggert wrote: >>>>>> On 2011-3-11, at 6:14, Mark Nottingham wrote: >>>>>>> Not official BoFs, Bar BoFs. >>>>>>=20 >>>>>> This confusion nicely demonstrates why we're trying to push = people to call these things side meetings: = http://tools.ietf.org/html/draft-eggert-successful-bar-bof >>>>>=20 >>>>> +1 >>>>>=20 >>>>> I'm part of a group that is organizing a bar BoF. I would prefer = ours to >>>>> not be listed in the wiki, exactly for the reasons cited in the = draft. >>>>> As a general rule, if you know about the existence of a bar BoF, = it >>>>> means you're invited. Advertising it at large on a wiki breaks = that >>>>> filtering mechanism. >>>>>=20 >>>>> Simon >>>>=20 >>>> I second the algorithm suggested by Klaas Wierenga. >>>>=20 >>>> *** >>>> a "convener MUST buy 1 beer or alternative consumption for all = invited >>>> attendees of the bar BoF" would solve lots of the problems you = mention: >>>>=20 >>>> - reduce the number of attendees >>>> - favor meeting in a bar >>>> - gives a more informal way of communication >>>> *** >>>>=20 >>>> = http://www.ietf.org/mail-archive/web/77attendees/current/msg00300.html >>>>=20 >>>> // Javier >>>>=20 >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> -- >> Mark Nottingham http://www.mnot.net/ >>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 -- Mark Nottingham http://www.mnot.net/ From scott.brim@gmail.com Fri Mar 11 15:24:40 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EDB53A6ABC for ; Fri, 11 Mar 2011 15:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IV4j8LymyvKV for ; Fri, 11 Mar 2011 15:24:38 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id A8E0C3A6AB2 for ; Fri, 11 Mar 2011 15:24:38 -0800 (PST) Received: by iyj8 with SMTP id 8so3816365iyj.31 for ; Fri, 11 Mar 2011 15:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5P264IIcobL7tvTnVw8a54gNAFwhbxNMb7wc7iXHvXM=; b=gv51y5jTq1SFSOry/+V4wbFbCl+qwAs+0eLXef++iHOhf6wMPPtPyhuVLDy6uNBN2C pu42gDnTZzFxLC1pxITPB8Wt9U2nQX9uMLAtL0Os/WDin5/KFAbAt9Eb1aQ/3sB1HZBj k0+e8wj+hSdiKaJPtK/OXVVtxewzvhUthwdy0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BwgMlxvpxSgreAu32ZbrWJ1yqIszw2gF5vjMrIINzawh79jdBR0UJC0wcwwx/KNobZ imst9JLaDSPN3hxt2c+RiS8BRWK7MUDVAOCQLVrodXteLSxUqeAC8cY8wYMuNcJic2RN 74emsJMpGjBC4TWsJ3La0Vfd/JmY/xW5rYfbs= MIME-Version: 1.0 Received: by 10.42.189.200 with SMTP id df8mr3053072icb.33.1299885956445; Fri, 11 Mar 2011 15:25:56 -0800 (PST) Received: by 10.42.114.81 with HTTP; Fri, 11 Mar 2011 15:25:56 -0800 (PST) Received: by 10.42.114.81 with HTTP; Fri, 11 Mar 2011 15:25:56 -0800 (PST) In-Reply-To: <9EB818FD-5DCE-4E1D-8EAC-A487046BD4F5@mnot.net> References: <4BC10742-7C69-4207-AE32-081A208B8DC5@mnot.net> <6.2.5.6.2.20110310184422.09896d80@resistor.net> <48FD3A57-6FC4-4A2B-8288-79A233F413B6@mnot.net> <2ECD9B78-E9AB-45C1-AFC6-347A2AC5F930@nokia.com> <4D7A2114.7010506@viagenie.ca> <1299852103.1975.85.camel@dab> <4183E07F-FE16-4D6B-A033-F310CE8B3C10@mnot.net> <3C630C0E-D2A2-423B-8B54-C5509067FC22@cisco.com> <9EB818FD-5DCE-4E1D-8EAC-A487046BD4F5@mnot.net> Date: Fri, 11 Mar 2011 18:25:56 -0500 Message-ID: From: Scott W Brim To: Mark Nottingham Content-Type: multipart/alternative; boundary=20cf303ea5eaaeb5b8049e3d4873 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Wiki for bar bofs? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 23:24:40 -0000 --20cf303ea5eaaeb5b8049e3d4873 Content-Type: text/plain; charset=ISO-8859-1 I hear the best bars are in the area somewhat east of the Hilton [Sent from my mobile.] On Mar 11, 2011 6:12 PM, "Mark Nottingham" wrote: > Exactly. We can always cut out the middleman, of course. > > > On 11/03/2011, at 3:13 PM, Cullen Jennings wrote: > >> >> So back to Mark's questions, is there a WIKI page to help coordinate my drinking problem, I hate to end up with a situation where the transport guys are having a fine scotch at the same time the RAI guys were opening some nice Bordeaux. >> >> >> On Mar 11, 2011, at 9:44 AM, Mark Nottingham wrote: >> >>> I don't disagree with any particular point raised in this thread, but for some of us, scheduling bar bofs is difficult, as there are many people with overlapping areas of interest. Given that Bar BoFs (side meetings, whatever -- if you want to change the terminology, the meeting page is a good start!) are often high value, *some* sort of coordination would be nice. >>> >>> >>> On 11/03/2011, at 7:07 AM, Eric Burger wrote: >>> >>>> Last I looked, we are the IETF, not the ITU. >>>> >>>> You do not need permission to get together to drink. >>>> >>>> You do not need parliamentary rules to talk about stuff while you get together to drink. >>>> >>>> IF you want to advertise your Bar BOF, PLEASE put an appropriate page on the wiki. PEOPLE: IT IS A WIKI, not a moderated, official business only web page. >>>> >>>> IF you do NOT want to advertise your Bar BOF, guess what? Do not advertise it! >>>> >>>> Of course, if you want good conversation, do not forget to invite me and buy me a beer :-) >>>> >>>> >>>> On Mar 11, 2011, at 9:01 AM, Javier Ubillos wrote: >>>> >>>>> On Fri, 2011-03-11 at 08:18 -0500, Simon Perreault wrote: >>>>>> On 2011-03-11 01:50, Lars Eggert wrote: >>>>>>> On 2011-3-11, at 6:14, Mark Nottingham wrote: >>>>>>>> Not official BoFs, Bar BoFs. >>>>>>> >>>>>>> This confusion nicely demonstrates why we're trying to push people to call these things side meetings: http://tools.ietf.org/html/draft-eggert-successful-bar-bof >>>>>> >>>>>> +1 >>>>>> >>>>>> I'm part of a group that is organizing a bar BoF. I would prefer ours to >>>>>> not be listed in the wiki, exactly for the reasons cited in the draft. >>>>>> As a general rule, if you know about the existence of a bar BoF, it >>>>>> means you're invited. Advertising it at large on a wiki breaks that >>>>>> filtering mechanism. >>>>>> >>>>>> Simon >>>>> >>>>> I second the algorithm suggested by Klaas Wierenga. >>>>> >>>>> *** >>>>> a "convener MUST buy 1 beer or alternative consumption for all invited >>>>> attendees of the bar BoF" would solve lots of the problems you mention: >>>>> >>>>> - reduce the number of attendees >>>>> - favor meeting in a bar >>>>> - gives a more informal way of communication >>>>> *** >>>>> >>>>> http://www.ietf.org/mail-archive/web/77attendees/current/msg00300.html >>>>> >>>>> // Javier >>>>> >>>>> _______________________________________________ >>>>> apps-discuss mailing list >>>>> apps-discuss@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>> >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --20cf303ea5eaaeb5b8049e3d4873 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I hear the best bars are in the area somewhat east of the Hilton

[Sent from my mobile.]

On Mar 11, 2011 6:12 PM, "Mark Nottingham&q= uot; <mnot@mnot.net> wrote:
> Exactly. We can always cut out the middleman, of c= ourse.
>
>
> On 11/03/2011, at 3:13 PM, Cullen Jennings wrote:>
>>
>> So back to Mark's questions, is there a= WIKI page to help coordinate my drinking problem, I hate to end up with a = situation where the transport guys are having a fine scotch at the same tim= e the RAI guys were opening some nice Bordeaux.
>>
>>
>> On Mar 11, 2011, at 9:44 AM, Mark Nottin= gham wrote:
>>
>>> I don't disagree with any part= icular point raised in this thread, but for some of us, scheduling bar bofs= is difficult, as there are many people with overlapping areas of interest.= Given that Bar BoFs (side meetings, whatever -- if you want to change the = terminology, the meeting page is a good start!) are often high value, *some= * sort of coordination would be nice.
>>>
>>>
>>> On 11/03/2011, at 7:07 AM, E= ric Burger wrote:
>>>
>>>> Last I looked, we ar= e the IETF, not the ITU.
>>>>
>>>> You do no= t need permission to get together to drink.
>>>>
>>>> You do not need parliamentary rules t= o talk about stuff while you get together to drink.
>>>> >>>> IF you want to advertise your Bar BOF, PLEASE put an appr= opriate page on the wiki. PEOPLE: IT IS A WIKI, not a moderated, official = business only web page.
>>>>
>>>> IF you do NOT want to advertise your = Bar BOF, guess what? Do not advertise it!
>>>>
>>= >> Of course, if you want good conversation, do not forget to invite = me and buy me a beer :-)
>>>>
>>>>
>>>> On Mar 11, 2011,= at 9:01 AM, Javier Ubillos wrote:
>>>>
>>>>= > On Fri, 2011-03-11 at 08:18 -0500, Simon Perreault wrote:
>>&= gt;>>> On 2011-03-11 01:50, Lars Eggert wrote:
>>>>>>> On 2011-3-11, at 6:14, Mark Nottingham wrote:<= br>>>>>>>>> Not official BoFs, Bar BoFs.
>>= ;>>>>>
>>>>>>> This confusion nicel= y demonstrates why we're trying to push people to call these things sid= e meetings: http://tools.ietf.org/html/draft-eggert-successful-bar-bof
>>>>>>
>>>>>> +1
>>>>= ;>>
>>>>>> I'm part of a group that is orga= nizing a bar BoF. I would prefer ours to
>>>>>> not be= listed in the wiki, exactly for the reasons cited in the draft.
>>>>>> As a general rule, if you know about the existence= of a bar BoF, it
>>>>>> means you're invited. Adv= ertising it at large on a wiki breaks that
>>>>>> filt= ering mechanism.
>>>>>>
>>>>>> Simon
>>>= >>
>>>>> I second the algorithm suggested by Klaas= Wierenga.
>>>>>
>>>>> ***
>>= >>> a "convener MUST buy 1 beer or alternative consumption fo= r all invited
>>>>> attendees of the bar BoF" would solve lots of the= problems you mention:
>>>>>
>>>>> - r= educe the number of attendees
>>>>> - favor meeting in a = bar
>>>>> - gives a more informal way of communication
>&g= t;>>> ***
>>>>>
>>>>> http://www.ietf.org/mail-archive/web/77attendees/current/msg00300.html=
>>>>>
>>>>> // Javier
>>>>= >
>>>>> _____________________________________________= __
>>>>> apps-discuss mailing list
>>>>>= ; apps-discuss@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>= >>
>>>> _____________________________________________= __
>>>> apps-discuss mailing list
>>>> apps-discuss@ietf.org
>>>> = https://www.= ietf.org/mailman/listinfo/apps-discuss
>>>
>>> --
>>> Mark Nottingham http://www.mnot.net/
>>>
>= >>
>>>
>>> ________________________________= _______________
>>> apps-discuss mailing list
>>> apps-discuss@ietf.org
>>> https://www.ietf.org/mai= lman/listinfo/apps-discuss
>>
>
> --
> Mark Nottingham http://www.mnot.net/
>
>
>
> _= ______________________________________________
> apps-discuss mailing= list
> apps-discuss@ietf.org
= > https:/= /www.ietf.org/mailman/listinfo/apps-discuss
--20cf303ea5eaaeb5b8049e3d4873-- From paul.hoffman@vpnc.org Sat Mar 12 15:08:05 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A5943A6A5B for ; Sat, 12 Mar 2011 15:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.983 X-Spam-Level: X-Spam-Status: No, score=-101.983 tagged_above=-999 required=5 tests=[AWL=0.616, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0IwN94w6O1I for ; Sat, 12 Mar 2011 15:08:04 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 1FE783A6A48 for ; Sat, 12 Mar 2011 15:08:03 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2CN9ODP096561 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 12 Mar 2011 16:09:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D7BFD23.60707@vpnc.org> Date: Sat, 12 Mar 2011 15:09:23 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] draft-hoffman-server-has-tls-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 23:08:05 -0000 Greetings again. Although the WG chairs said that it was fine to bring this document into the WG, I was hesitant to do so before dealing with all the issues that were raised in the earlier discussion. Try as I might, I wasn't able to resolve one significant issue, so I have kept this as an individual submission, listed below. The issue is listed in Appendix A of the new draft. If people agree that one of the proposed solutions is fine, I can make that change and issue a new draft for the WG after the window opens in Prague. I suspect that there will be a lot of discussion of which proposal is best; if I'm wrong, I apologize for not having seen it early and turning this into a WG document before now. --Paul Hoffman ========== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Specifying That a Server Supports TLS Author(s) : P. Hoffman Filename : draft-hoffman-server-has-tls-04.txt Pages : 9 Date : 2011-03-12 A server that hosts applications that can be run with or without TLS may want to communicate with clients whether the server is hosting an application only using TLS or also hosting the application without TLS. Many clients have a policy to try to set up a TLS session but fall back to insecure if the TLS session cannot be set up. If the server can securely communicate whether or not it can fall back to insecure tells such a client whether or not they should even try to set up an insecure session with the server. This document describes the use cases for this type of communication and a secure method for communicating that information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-server-has-tls-04.txt From moore@network-heretics.com Sat Mar 12 16:15:38 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C71C3A6A63 for ; Sat, 12 Mar 2011 16:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EA9XikDUqBqX for ; Sat, 12 Mar 2011 16:15:37 -0800 (PST) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by core3.amsl.com (Postfix) with ESMTP id D4E293A695B for ; Sat, 12 Mar 2011 16:15:36 -0800 (PST) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 9CD7B2083A; Sat, 12 Mar 2011 19:16:57 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 12 Mar 2011 19:16:57 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=X9WSkC/Ny+jV5wxkTA86lbYkEvU=; b=mvg5yIeSjPidQYqBwuAFX23ZnJ7riMgmZq2VnVqUNZIarzDVHhDrMi6llCX3NZMaL36FTYIA5UyDtSHjt+zbSX11AN46eIbfg7WFchIT+pqeXPduaW1aYZo5fadF/m6gnWbiZm8GfcvV22M8ZXxtomX9gGDVrag+qo40EVZx8Pw= X-Sasl-enc: F86NfYrf7sWqyVhhFbnFlIL7BQRuSrnUnPY47KM0Hn6X 1299975416 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 78794441ACB; Sat, 12 Mar 2011 19:16:55 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-33--454333436 From: Keith Moore In-Reply-To: <4D7BFD23.60707@vpnc.org> Date: Sat, 12 Mar 2011 19:16:53 -0500 Message-Id: <5E3BC253-6BA8-417A-BB2C-C5D33EEEBBCC@network-heretics.com> References: <4D7BFD23.60707@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-hoffman-server-has-tls-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 00:15:38 -0000 --Apple-Mail-33--454333436 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is the first time I've looked at this document, so these are = thoughts about the document as a whole, not just appendix A. However, = while reading through the document, I kept wondering how this applied to = STARTTLS and similar schemes for doing in-band negotiation of TLS. 1. My first impression is that for protocols whose connection details = are specified by URL, any kind of automatic negotiation of TLS (or not) = might be the wrong thing to do. http://example.com/foo.bar arguably means to use (a) raw HTTP and (b) = port 80, regardless of whether example.com supports HTTP-over-TLS, or = access on a different port. https://example.com/foo.bar arguably means to use (a) HTTP over TLS, and = (b) port 443, rather than some other port. If the user typed in https, he has the right to expect TLS. You = definitely do not want the latter case to "fall back" to an insecure = port without the user being aware of it, no matter what the DNS says. I'll note that HTTP, at least, already has a fairly flexible redirect = mechanism, so doesn't seem to benefit from HASTLS. =20 So I guess I wonder if HASTLS should apply to protocols whose connection = details are specified in a URL, especially if they're explicitly = specified in a URL (as with literal port numbers). 2. Furthermore, if a port is explicitly specified in a URL, that = definitely means to use that port. But URL canonicalization routines = usually delete an explicitly specified default port. So even if a user = (or a program) explicitly specifies http://example.com:80/foo.bar then = that has a good chance of being rewritten internally to = http://example.com/foo.bar even though port 80 was explicitly specified. = Naive implementation of HASTLS (or any other rewriting mechanism) = would defeat the ability to use literal port numbers, for diagnostics, = debugging, etc. That isn't by itself a showstopper for HASTLS, but it = does probably mean that some more detail is needed in specifying how = HASTLS is used. 3. Again regarding protocol connections specified by URL, I guess that = if a server administrator wanted to publish some sort of mapping in DNS = that said "any resources with names starting with http://example.com/foo = can also be located at https://example.com/foo, and the latter is = preferred", that might be useful. Really, some of us have been wanting = this since the mid 1990s at least, and NAPTR is fairly well suited to = such mappings. But the semantics of HASTLS aren't defined tightly = enough to warrant that kind of interpretation. =20 4. Especially in these days with widespread and increasing use of NAPTs, = it seems dubious for a "please use TLS" solution to impose the = constraint that the alternate protocol uses a separate port than the = primary one. =20 5. Something I've wanted for a long time is automatic configuration of = various kinds of services. Say you get an email account from your ISP, = enterprise, whatever. They give you an email address and a password. = Your mail client should be able to do a DNS lookup of your email address = (say using NAPTR), and get back a list of records that say: send outgoing mail to: smtp.example.com using the mail submission protocol over port 587 using = STARTTLS and plain authentication access received mail using any of the following imap4 over port 143 using starttls from imap.example.com; username =3D = your email address (preference=3D1) imap4 over tls over port 993 from imap.example.com; username =3D your = email address (preference=3D2) imap4 over port 143 from imap.example.com; username =3D your email = address (preference=3D3) pop3 over tls over port 110 using STLS from pop.example.com; username =3D = your email address (preference=3D1) pop3 over tls over port 995 from pop.example.com; username =3D your = email address (preference=3D2) pop3 over port 110 using APOP from pop.example.com; username =3D your = email address (preference=3D3) pop3 over port 110 from pop.example.com; username =3D your email address = (preference=3D4) a webmail client is also available at: https://webmail.example.com (preference=3D1) This would provide a very general way to encourage use of secure = servers, as well as other advantages. For instance, other services = associated with the email address could also be specified: instant = messaging, public key, directory lookup (business card), home web page, = VoIP, etc. Again, I think that something like NAPTR is pretty close to being able = to do this, though it needs to be profiled for this case. The other = pieces that are missing are suitable URL definitions for all of these = protocols (SMTP, mail submission, POP, IMAP) and a way to embed "use = STARTTLS" in those URLs. (In some cases the URLs exist but might not = have been designed with this purpose in mind.) Keith --Apple-Mail-33--454333436 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = is the first time I've looked at this document, so these are thoughts = about the document as a whole, not just appendix A.  However, while = reading through the document, I kept wondering how this applied to = STARTTLS and similar schemes for doing in-band negotiation of = TLS.

1. My first impression is that for protocols = whose connection details are specified by URL, any kind of automatic = negotiation of TLS (or not) might be the wrong thing to = do.

http://example.com/foo.bar = arguably means to use (a) raw HTTP and (b) port 80, regardless of = whether example.com supports = HTTP-over-TLS, or access on a different = port.

https://example.com/foo.bar arguably means to use (a) HTTP over TLS, and (b) port 443, rather than = some other port.

If the user typed in https, he = has the right to expect TLS.  You definitely do not want the latter = case to "fall back" to an insecure port without the user being aware of = it, no matter what the DNS says.

I'll note that = HTTP, at least, already has a fairly flexible redirect mechanism, so = doesn't seem to benefit from HASTLS.  

So = I guess I wonder if HASTLS should apply to protocols whose connection = details are specified in a URL, especially if they're explicitly = specified in a URL (as with literal port = numbers).


2. Furthermore, = if a port is explicitly specified in a URL, that definitely means to use = that port.   But URL canonicalization routines usually delete an = explicitly specified default port.  So even if a user (or a = program) explicitly specifies http://example.com:80/foo.bar then that has a good chance of being rewritten internally to http://example.com/foo.bar = even though port 80 was explicitly specified.    Naive = implementation of HASTLS (or any other rewriting mechanism) would defeat = the ability to use literal port numbers, for diagnostics, debugging, = etc.  That isn't by itself a showstopper for HASTLS, but it does = probably mean that some more detail is needed in specifying how HASTLS = is used.


3.  Again = regarding protocol connections specified by URL, I guess that if a = server administrator wanted to publish some sort of mapping in DNS that = said "any resources with names starting with http://example.com/foo can also be = located at https://example.com/foo, and the = latter is preferred", that might be useful.   Really, some of us = have been wanting this since the mid 1990s at least, and NAPTR is fairly = well suited to such mappings.   But the semantics of HASTLS aren't = defined tightly enough to warrant that kind of interpretation. =  


4. Especially in these = days with widespread and increasing use of NAPTs, it seems dubious for a = "please use TLS" solution to impose the constraint that the alternate = protocol uses a separate port than the primary one. =  


5. Something I've wanted = for a long time is automatic configuration of various kinds of services. =   Say you get an email account from your ISP, enterprise, whatever. =  They give you an email address and a password.  Your mail = client should be able to do a DNS lookup of your email address (say = using NAPTR), and get back a list of records that = say:

  • send = outgoing mail to:
    • smtp.example.com using the mail = submission protocol over port 587 using STARTTLS and plain = authentication
  • access received mail using any of the = following
    • imap4 over port 143 using starttls from imap.example.com; username =3D your = email address (preference=3D1)
    • imap4 over tls over port 993 from = imap.example.com; username =3D = your email address (preference=3D2)
    • imap4 over port 143 from imap.example.com; username =3D your = email address (preference=3D3)
    • pop3 over tls over port 110 using = STLS from pop.example.com; = username =3D your email address (preference=3D1)
    • pop3 over tls = over port 995 from pop.example.com;= username =3D your email address (preference=3D2)
    • pop3 over port = 110 using APOP from pop.example.com; username =3D your = email address (preference=3D3)
    • pop3 over port 110 from pop.example.com; username =3D your = email address (preference=3D4)
  • a webmail client is also = available at:

This would provide a = very general way to encourage use of secure servers, as well as other = advantages.  For instance, other services associated with the email = address could also be specified:  instant messaging, public key, = directory lookup (business card), home web page, VoIP, = etc.

Again, I think that something like = NAPTR is pretty close to being able to do this, though it needs to be = profiled for this case.  The other pieces that are missing are = suitable URL definitions for all of these protocols (SMTP, mail = submission, POP, IMAP) and a way to embed "use STARTTLS" in those URLs. =  (In some cases the URLs exist but might not have been designed = with this purpose in = mind.)

Keith

= --Apple-Mail-33--454333436-- From stpeter@stpeter.im Mon Mar 14 13:10:57 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DCAD3A6B71 for ; Mon, 14 Mar 2011 13:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.631 X-Spam-Level: X-Spam-Status: No, score=-102.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5l9iv3GvC5D for ; Mon, 14 Mar 2011 13:10:54 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9A9AF3A6808 for ; Mon, 14 Mar 2011 13:10:54 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8F24A4006D for ; Mon, 14 Mar 2011 14:12:40 -0600 (MDT) Message-ID: <4D7E76A0.8060107@stpeter.im> Date: Mon, 14 Mar 2011 14:12:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050208030209060908090205" Subject: [apps-discuss] Fwd: I-D Action:draft-iab-dns-applications-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 20:10:57 -0000 This is a cryptographically signed message in MIME format. --------------ms050208030209060908090205 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks, this is probably of interest here... -------- Original Message -------- Subject: I-D Action:draft-iab-dns-applications-01.txt Date: Mon, 14 Mar 2011 12:45:01 -0700 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: iab@iab.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Architecture Board Working Group of the IETF. Title : Architectural Considerations on Application Features in the DNS Author(s) : O. Kolkman, et al. Filename : draft-iab-dns-applications-01.txt Pages : 24 Date : 2011-03-14 While the principal purpose of the Domain Name System (DNS) is to translate Internet domain names to IP addresses, over time a number of Internet applications have integrated supplemental features into the DNS to support their operations. Many of these features assist in locating the appropriate service in a domain, or in transforming intermediary identifiers into names that the DNS can process. Proposals to piggyback more sophisticated application behavior on top of the DNS, however, have raised questions about the propriety of instantiating some features in that way, especially those with security sensitivities. This document explores the architectural consequences of installing application features in the DNS, and provides guidance for future work in this area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iab-dns-applications-01.txt --------------ms050208030209060908090205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMx NDIwMTIxNlowIwYJKoZIhvcNAQkEMRYEFDaipc4FDZk0qEwwvB55gGr61g5lMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQB97jYkhXfBxVfKLaWPAfoRsPGe0q61tzyUihQUKlAAANvVQy4OQlhJvqiA LCgaGuuut1Wg0I83KmzfYbvWG8/MCRB1tB0/Sd2ykyq0a0Y2p0Y5MG0nWXvLfNH03NZsOfk+ JyevjVXOkj18hpcz2K8KlNP5IuuUVSwT5ERj/M3VTSgKXjiIsD29uwD7eeGO7Wyt8CZLFHtj fIvvQJrd3niohaIv2ptu8nlfERN9xzovVX2C5imb5A4LVrKgTwPmkKT/auVOW7uW9Tu/D1YO wxvySMZOJ4D8Nr6dCFbkg/hRlac6zB4CuzCu4jjcJnXfM2fWlvhrW8HCl4nvgK6F3WKpAAAA AAAA --------------ms050208030209060908090205-- From tobias.gondrom@gondrom.org Tue Mar 15 16:51:26 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11093A6D9F for ; Tue, 15 Mar 2011 16:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.705 X-Spam-Level: X-Spam-Status: No, score=-94.705 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, SARE_TOWRITE=1.05, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+Cbdy1e2YyW for ; Tue, 15 Mar 2011 16:51:22 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 629F43A6F03 for ; Tue, 15 Mar 2011 16:51:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=W5aNpmBz7Tb7oRtGKi9VPdU1fGYa+Rxm8OAg/z7wZiB8pVUJn37qGWEuwB873Qcuru4za+9x6Cg0rSCHgztgOYlxTvYG8i1AcmGQT4dXY1sU5MoQkdwELGBEZ6W7TF1q; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:X-Enigmail-Version:Content-Type; Received: (qmail 15641 invoked from network); 16 Mar 2011 00:51:54 +0100 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Mar 2011 00:51:54 +0100 Message-ID: <4D7FFBDA.7070505@gondrom.org> Date: Tue, 15 Mar 2011 23:52:58 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: apps-discuss@ietf.org X-Priority: 4 (Low) X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------050302010402010900050701" Subject: [apps-discuss] Fwd: [websec] FYI: New draft draft-gondrom-frame-options-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 23:51:26 -0000 This is a multi-part message in MIME format. --------------050302010402010900050701 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Folks, just FYI as this (HTTP Header Frame-Options) may be of interest for apps area as well. - Tobias (websec) -------- Original Message -------- Subject: [websec] FYI: New draft draft-gondrom-frame-options-01 Date: Tue, 15 Mar 2011 21:43:52 +0000 From: Tobias Gondrom To: websec@ietf.org CC: dross@microsoft.com Hello dear fellow websec colleagues, following up on some discussions at the OWASP Summit last month, David Ross and I decided to write up a draft on Frame-Options (currently know as X-Frame-Options) and to develop this further as a standard: https://datatracker.ietf.org/doc/draft-gondrom-frame-options/ The draft is still a little bit rough on the edges and e.g. how it works with websec-origin, but I hope we can sort out some of the details in Prague and with your feedback on the mailing-list. Kind regards, Tobias Ps.: and on a note as websec chair: although I believe this draft to be relevant in websec scope, I submitted it as individual draft initially, so we can have a first discussion and have a proper look for feedback whether the WG wants to adopt this draft or not. -------- Original Message -------- Subject: New Version Notification for draft-gondrom-frame-options-01 Date: Mon, 14 Mar 2011 16:19:55 -0700 (PDT) From: IETF I-D Submission Tool To: tobias.gondrom@gondrom.org A new version of I-D, draft-gondrom-frame-options-01.txt has been successfully submitted by Tobias Gondrom and posted to the IETF repository. Filename: draft-gondrom-frame-options Revision: 01 Title: HTTP Header Frame Options Creation_date: 2011-03-15 WG ID: Independent Submission Number_of_pages: 9 Abstract: To improve the protection of web applications against Cross Site Request Forgery (CSRF) and Clickjacking this standards defines a http response header that declares a policy communicated from a host to the client browser whether the transmitted content MUST NOT be displayed in frames of other pages from different origins or a list of trusted origins which are allowed to frame the content. The IETF Secretariat. --------------050302010402010900050701 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Folks,
just FYI as this (HTTP Header Frame-Options) may be of interest for apps area as well.
- Tobias (websec)


-------- Original Message --------
Subject: [websec] FYI: New draft draft-gondrom-frame-options-01
Date: Tue, 15 Mar 2011 21:43:52 +0000
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
To: websec@ietf.org
CC: dross@microsoft.com


Hello dear fellow websec colleagues,

following up on some discussions at the OWASP Summit last month, David Ross and I decided to write up a draft on Frame-Options (currently know as X-Frame-Options) and to develop this further as a standard:
https://datatracker.ietf.org/doc/draft-gondrom-frame-options/

The draft is still a little bit rough on the edges and e.g. how it works with websec-origin, but I hope we can sort out some of the details in Prague and with your feedback on the mailing-list.

Kind regards,

Tobias


Ps.: and on a note as websec chair: although I believe this draft to be relevant in websec scope, I submitted it as individual draft initially, so we can have a first discussion and have a proper look for feedback whether the WG wants to adopt this draft or not.



-------- Original Message --------
Subject: New Version Notification for draft-gondrom-frame-options-01
Date: Mon, 14 Mar 2011 16:19:55 -0700 (PDT)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: tobias.gondrom@gondrom.org 


A new version of I-D, draft-gondrom-frame-options-01.txt has been successfully submitted by Tobias Gondrom and posted to the IETF repository.

Filename:	 draft-gondrom-frame-options
Revision:	 01
Title:		 HTTP Header Frame Options
Creation_date:	 2011-03-15
WG ID:		 Independent Submission
Number_of_pages: 9

Abstract:
To improve the protection of web applications against Cross Site
Request Forgery (CSRF) and Clickjacking this standards defines a http
response header that declares a policy communicated from a host to
the client browser whether the transmitted content MUST NOT be
displayed in frames of other pages from different origins or a list
of trusted origins which are allowed to frame the content.
                                                                                  


The IETF Secretariat.
--------------050302010402010900050701-- From alexey.melnikov@isode.com Fri Mar 18 12:45:49 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9863F3A6926; Fri, 18 Mar 2011 12:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.103 X-Spam-Level: X-Spam-Status: No, score=-102.103 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZSu-sRPCAy1; Fri, 18 Mar 2011 12:45:48 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C497E3A691C; Fri, 18 Mar 2011 12:45:47 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 18 Mar 2011 19:47:16 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D83B681.60906@isode.com> Date: Fri, 18 Mar 2011 19:46:09 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <4D4FD50E.2020503@it.aoyama.ac.jp> In-Reply-To: <4D4FD50E.2020503@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: draft-holsten-about-uri-scheme@tools.ietf.org, "uri-review@ietf.org" , "apps-discuss@ietf.org" , IESG Subject: Re: [apps-discuss] apps-team review of draft-holsten-about-uri-scheme-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 19:45:49 -0000 Hi Martin, As authors didn't respond to your comments and I need to pass on=20 shepherding of this document to Peter, so I will quickly respond to=20 clarify where I stand on your comments (as the shepherding AD): Martin J. D=C3=BCrst wrote: > I have been selected as the Applications Area Review Team reviewer for > this draft (for background on apps-review, please see > http://www.apps.ietf.org/content/applications-area-review-team). > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > > Document: draft-holsten-about-uri-scheme-06 > Title: The 'about' URI scheme > Reviewer: Martin J. D=C3=BCrst > Review Date: February 7, 2011 > > > Summary: This draft is not ready for publication, but because it is=20 > short, the problems identified below could be fixed soon. > > This draft defines the about: URI scheme, a scheme that has been used=20 > internally, informally by browsers since ages. It's good to see this=20 > defined and registered finally, but there are some problems that need=20 > to be fixed. > > > Major Issues: > > - Section 5.1: "Other specification MAY reserve "about" URIs.": How is=20 > this done? And done in a way that gives implementers a chance to know=20 > about it? Surely if specifications are involved, a very lightweight=20 > version of IANA registry/process should not be too heavy. For my own=20 > taste, even a Wikipedia page might do the job, but just leaving this=20 > open looks like a bad idea. If additions are thought to be very=20 > infrequent, "updates to this specification" might also do the job. I think pretty much everybody (including GenArt, Ted Hardie and myself)=20 spotted this issue. > - 6. Normalization: This is confused. There are NO standard URI=20 > normalization rules, just various choices, in RFC 3986. And the choice=20 > of normalization rule is NOT a per-scheme choice, it's a per-usage=20 > choice, where usage for XML namespaces differs widely from usage for=20 > some protocol-based resolutions, and that again differs widely from=20 > what spiders and robots do. As an example, when used as an XML=20 > namespace URI, "about:blank" and "about:blan%6B" identify different=20 > namespaces. The text should make it excruciatingly clear that the=20 > normalization rules given there apply ONLY to (browser built-in)=20 > resolution of about URIs. Also, the phrase "Due to the structure of=20 > the "about" URI, some normalizations do not apply, specifically ..."=20 > is inappropriate given the examples following, and unnecessary. Right. > Minor Issues: > > - The split of about: URIs into three kinds (reserved, unreserved, and=20 > unrecognized) is highly confusing. It looks as if two binary=20 > distinctions are conflated: a) The distinction between reserved and=20 > unreserved, which is a distinction from a specification point. b) The=20 > distinction between recognized and unrecognized, which is a=20 > distinction from an implementation (resolution) point. There's nothing=20 > to rule out reserved but unrecognized about: URIs in the future (with=20 > only about:blank being standardized at the moment, and unrecognized=20 > about: URIs defaulting to about:blank, there's currently no such case). Agreed. > - The abstract describes the about: scheme. It should explicitly=20 > contain the wording "defines ... the about: scheme", because that's=20 > the most important thing done with this document. That will also make=20 > the Abstract more different from the Introduction; currently the read Ok. > - The abstract and the text mention "easter eggs". There are large=20 > parts of the world where Easter isn't known, and nor are Easter eggs=20 > (in the general sense of fancifully colored eggs). On top of this, the=20 > use of the term "easter egg" in the document is a very specialized=20 > hacker jargon use. Proposal: Remove from abstract, add explanation in=20 > text. Possibly. I wouldn't worry too much about this particular issue: I hope=20 RFC Editor can provide a good advice on this. > - End of first paragraph of Section 4: "then only those octets that do=20 > not correspond to characters in the unreserved set [RFC3986] SHOULD be=20 > percent-encoded." This can very easily be misunderstood. The writer=20 > seems to want to apply the SHOULD to 'only', but readers will apply it=20 > to 'percent-encoded', meaning that an implementation might be okay=20 > even if it didn't percent-encode characters outside the unreserved=20 > set. The best thing to do here is to not make this normative language=20 > (because RFC 3986 already defines what's allowed and what not). The=20 > authors seems to be worried that some people might apply=20 > percent-escaping to a-z and such, but this is not something to worry=20 > about in practice. I actually found similar text in other RFCs. > - Section 5 starts defining various kinds of "about" URIs. It should=20 > start by first saying that there are three different kinds of "about"=20 > URIs, to make the reader's job easier (but see above). > > - Section 5.1.1 contains a lone sentence fragment 'i.e.=20 > "about:blank".', which seems to be unnecessary. > > - 5.4. Examples is inconsistent with final punctuation. > > - I seem to remember that the change controller for standards track=20 > stuff is the IESG. But I may be wrong. Yes. From masinter@adobe.com Sun Mar 20 07:34:36 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9D928C0D9 for ; Sun, 20 Mar 2011 07:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSG-YRITCpFT for ; Sun, 20 Mar 2011 07:34:35 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by core3.amsl.com (Postfix) with ESMTP id 4733E3A6AAB for ; Sun, 20 Mar 2011 07:34:34 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKTYYQ1bGvN7GWqFPkoWzcv8VcqkA1OcFb@postini.com; Sun, 20 Mar 2011 07:36:07 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p2KEZKES023308 for ; Sun, 20 Mar 2011 07:35:20 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p2KEa5PY012294 for ; Sun, 20 Mar 2011 07:36:05 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Sun, 20 Mar 2011 07:36:05 -0700 From: Larry Masinter To: "apps-discuss@ietf.org" Date: Sun, 20 Mar 2011 07:36:04 -0700 Thread-Topic: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs Thread-Index: AcvfPyoA+yoRLFFQRBKXbBZK9ylRmgHxeADw Message-ID: References: <4D6FBE4D.10602@isode.com> <6.2.5.6.2.20110308164758.0be3c0a8@resistor.net> <4D76FB18.1040304@stpeter.im> <4D772FD6.4080305@it.aoyama.ac.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 14:34:36 -0000 This proposed IESG statement fails to address any of the significant diffic= ulties: Registering MIME types is an activity that has high cost and little benefit= . Cost in terms of learning the process (poorly documented, inconsistent, = hard to follow) and following it (responding to reviewer comments). Little = benefit, in that the registry plays little or no role in the actual impleme= ntation and deployment cycle for new values.=20 This issue applies also to URI schemes, and to some degree to other (web-) = and perhaps (application-level) parameters. The high cost and low benefit holds in general for any organization deployi= ng a new or updated content type. While it is also true for other SDOs, the= proposed statement does not address the general problem, and might even ma= ke the situation worse, by making the SDO process even more different from = the non-SDO problem. =20 (It does not address the cost/benefit tradeoff for SDOs either, except perh= aps to trade off one cost -- cost of learning a cumbersome and poorly docum= ented process -- with another.) With MIME types and charset values, there are additional consequences: Because some organizations and implementations originally did not supply th= e correct registered values, many implementations override the provided MIM= E types and character encoding assertions (use of registered values) by "sn= iffing" https://tools.ietf.org/html/draft-ietf-websec-mime-sniff see also http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#mim= e-types http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#de= termining-the-character-encoding . More problematic is when the "ownership" of a MIME registration is in dispu= te, for example when there are multiple, different specifications which cla= im to be the authority on a registered value, e.g., the two registries for = the same MIME value http://www.whatwg.org/specs/web-apps/current-work/multi= page/iana.html vs. http://dev.w3.org/html5/spec/iana.html pointing to subs= tantially different specifications.=20 The proposed IESG statement does not address this issue, and, in fact might= exacerbate it, by making the registration process for SDOs more difficult = than the non-registration-process for non-SDOs. (Too bad the IAB document on "Design Considerations for Protocol Extension= s" http://tools.ietf.org/html/draft-iab-extension-recs#section-3.6 doesn'= t take on these issues).=20 Larry From alexey.melnikov@isode.com Sun Mar 20 08:27:24 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 523F428C0DF for ; Sun, 20 Mar 2011 08:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBRypqBF5+1C for ; Sun, 20 Mar 2011 08:27:22 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id EBEE928C0D8 for ; Sun, 20 Mar 2011 08:27:21 -0700 (PDT) Received: from [192.168.20.2] ((unknown) [212.183.140.35]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 20 Mar 2011 15:28:50 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D861D02.1090000@isode.com> Date: Sun, 20 Mar 2011 15:28:02 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Larry Masinter References: <4D6FBE4D.10602@isode.com> <6.2.5.6.2.20110308164758.0be3c0a8@resistor.net> <4D76FB18.1040304@stpeter.im> <4D772FD6.4080305@it.aoyama.ac.jp> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 15:27:24 -0000 Hi Larry, Larry Masinter wrote: >This proposed IESG statement fails to address any of the significant difficulties: > > ...because it was not planning to address them. There are multiple related discussions going on at the moment. This particular statement proposal originated from an internal IESG discussion about stability of references in registrations from other SDOs. >Registering MIME types is an activity that has high cost and little benefit. Cost in terms of learning the process (poorly documented, inconsistent, hard to follow) and following it (responding to reviewer comments). Little benefit, in that the registry plays little or no role in the actual implementation and deployment cycle for new values. > Ack. >This issue applies also to URI schemes, and to some degree to other (web-) and perhaps (application-level) parameters. > >The high cost and low benefit holds in general for any organization deploying a new or updated content type. While it is also true for other SDOs, the proposed statement does not address the general problem, and might even make the situation worse, by making the SDO process even more different from the non-SDO problem. > I don't think it does, but I am happy to discuss. >(It does not address the cost/benefit tradeoff for SDOs either, except perhaps to trade off one cost -- cost of learning a cumbersome and poorly documented process -- with another.) > >With MIME types and charset values, there are additional consequences: > >Because some organizations and implementations originally did not supply the correct registered values, many implementations override the provided MIME types and character encoding assertions (use of registered values) by "sniffing" https://tools.ietf.org/html/draft-ietf-websec-mime-sniff see also > http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#mime-types >http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#determining-the-character-encoding . > I agree that this is worth addressing, but addressing this particular problem wasn't a goal. >More problematic is when the "ownership" of a MIME registration is in dispute, for example when there are multiple, different specifications which claim to be the authority on a registered value, e.g., the two registries for the same MIME value http://www.whatwg.org/specs/web-apps/current-work/multipage/iana.html vs. http://dev.w3.org/html5/spec/iana.html pointing to substantially different specifications. > > What is your proposal here? I think this issue is quite rare and the only cases I've seen all originate from WHATWG/W3C. As far as IANA (or IESG) is concerned, there is only one true registration in each case, so there is no dispute. >The proposed IESG statement does not address this issue, and, in fact might exacerbate it, by making the registration process for SDOs more difficult than the non-registration-process for non-SDOs. > > (Too bad the IAB document on "Design Considerations for Protocol Extensions" http://tools.ietf.org/html/draft-iab-extension-recs#section-3.6 doesn't take on these issues). > >Larry > > From dhc@dcrocker.net Mon Mar 21 07:29:49 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BBBE28C152 for ; Mon, 21 Mar 2011 07:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zB9cEWbmcLSk for ; Mon, 21 Mar 2011 07:29:48 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 80D8D28C14E for ; Mon, 21 Mar 2011 07:29:48 -0700 (PDT) Received: from [192.168.1.4] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p2LEVFjB019851 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 21 Mar 2011 07:31:20 -0700 Message-ID: <4D87612E.3090900@dcrocker.net> Date: Mon, 21 Mar 2011 07:31:10 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 21 Mar 2011 07:31:21 -0700 (PDT) Subject: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 14:29:50 -0000 Folks, I just saw the announcement for the Technical Plenary presentation. As described, the session suggests a failure to recognize at least two architectural issues. One is that it mandates full-time connectivity. The other is that protocols that it says are no longer needed are in fact still needed in some form, albeit as a layer above HTTP, rather than TCP. Replacing TCP with HTTP does not eliminate the requirement for purpose-built application protocols, such as specialized mailbox access. On the other hand, it does tend to encourage an explosion of competing, incompatible application protocols, making for rather remarkable burdens on servers and clients. The summary also neglects to mention rather significant security concerns in all this real-time application downloading... d/ > The Future of Applications > > > Advancements in the design of web browsers have introduced fundamental > changes to the architecture of application protocols. The widespread > availability and growing sophistication of JavaScript interpreters in > browsers enables web servers to push to browsers all of the application > logic required to implement a client-server protocol. Consequently, many > client-server applications that once required an installed client on a host > computer now can rely simply on a modern browser to act as a client for the > purposes of a particular application. For example, where once email clients > required a custom application to access an inbox, increasingly a web browser > can serve this purpose as well as the purpose-built applications of the > past. Similarly, HTTP with the assistance of JavaScript can subsume the > functions performed by the protocols like POP3 and IMAP. The need for > Internet standards beyond HTTP to implement an email inbox application > consequently diminishes - why author standards and worry about > interoperability of clients and servers when the server can simply push to > the client all the code it needs to be interoperable? > > Many client-server applications on the Internet could potential migrate to > this post-standardization environment. In this environment, there is of > course still a role for the IETF to play: existing working groups like HyBi > and OAuth are examples of areas where standards work is still required to > support this application development paradigm. Collectively, we need to > identify areas where the standardization is unlikely to be relevant in the > future, and focus our efforts on those areas where our application designs > will remain impactful. The goals of this session are to explore future areas > of IETF work surrounding this evolution. > > Speakers: Jonathan Rosenberg (Skype) Harald Alvestrand (Google) Henry S. > Thompson (W3C) -- Dave Crocker Brandenburg InternetWorking bbiw.net From dave@cridland.net Mon Mar 21 07:43:36 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748A43A6874 for ; Mon, 21 Mar 2011 07:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sE9o1rjHSTwy for ; Mon, 21 Mar 2011 07:43:35 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 32A5E3A6873 for ; Mon, 21 Mar 2011 07:43:35 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 966561168087; Mon, 21 Mar 2011 14:45:05 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2joAK4Vb-iJx; Mon, 21 Mar 2011 14:45:04 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 2B6951168067; Mon, 21 Mar 2011 14:45:04 +0000 (GMT) References: <4D87612E.3090900@dcrocker.net> In-Reply-To: <4D87612E.3090900@dcrocker.net> MIME-Version: 1.0 Message-Id: <6266.1300718704.155911@puncture> Date: Mon, 21 Mar 2011 14:45:04 +0000 From: Dave Cridland To: Dave CROCKER , General discussion of application-layer protocols Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 14:43:36 -0000 On Mon Mar 21 14:31:10 2011, Dave CROCKER wrote: > As described, the session suggests a failure to recognize at least > two architectural issues. More than that, actually. > One is that it mandates full-time connectivity. The other is that > protocols > that it says are no longer needed are in fact still needed in some > form, albeit > as a layer above HTTP, rather than TCP. Right - repeated redesign doesn't lend itself well to optimal protocol. > Replacing TCP with HTTP does not eliminate the requirement for > purpose-built > application protocols, such as specialized mailbox access. No, and crucially, it hugely increases the cost of lightweight clients. I can code an IMAP library, say, in a few hundred lines of code in pretty well any language, whereas in order to support the new world order, I'd have to begin by ensuring I had Javascript available on the device. The baseline stack needed to read email, therefore, would exponentially increase. Secondly, the bandwidth overhead of HTTP is very significant. While this would undoubtedly be lowered by the efforts of HyBi (admittedly this results in double-AES, but still) it still involves downloading a client afresh each time, as well as at least the majority of data, in a world where connectivity is still metered by the byte in many cases. I do, of course, recognise that there are significant benefits to a HTTP/Javascript world, but the notion that we are somehow "post-standardization" suggests that we are also "post-desktop"; that all we ever need nowadays is a web browser. I've not heard that one since the Netscape browser-as-platform days, and it's a loony now as it was then. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From scott.brim@gmail.com Mon Mar 21 07:47:06 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C71128C158 for ; Mon, 21 Mar 2011 07:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.566 X-Spam-Level: X-Spam-Status: No, score=-103.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBQVlD2ZXUkF for ; Mon, 21 Mar 2011 07:47:05 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 0A9DD28C153 for ; Mon, 21 Mar 2011 07:47:00 -0700 (PDT) Received: by gxk19 with SMTP id 19so2903383gxk.31 for ; Mon, 21 Mar 2011 07:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GowQ6xbb63V5Fiun3jE6dYHsY2qgAu9y9UNnoy7put8=; b=VK4Pvn6UvSeiI+v0Mr1S1K2NHbjCnsc3x6bGTB+zMY7h3jO5sa4PX6bK+MM1ZfZOPJ /7Jukkx+TDrCsYJRjjOBfQgMyzfWpwIHYWc7yI5u4KaziIFWKd1dNA4W4MvWJLLIrIPW xE3PYrKxA+/yuHTRj1o7kz4biEwARJ0Nem5PQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=uuLbhPf++2FfGb2EeRCxAc0YWeNduBEBAvN/6eF71tBlvkxphqipSbIX9/bKyXDq7M cY2QtlkKHUG683FcCOc/APrcsau4QZg4oVkcT/yJTLejpTgeD9SBsnh6T0T6al/jNnkU bEcR0Pn5EbJNCaFaGejcgIBD39mrN2onvUvaw= Received: by 10.42.166.6 with SMTP id m6mr6842337icy.281.1300718777677; Mon, 21 Mar 2011 07:46:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.164.74 with HTTP; Mon, 21 Mar 2011 07:43:40 -0700 (PDT) In-Reply-To: <4D87612E.3090900@dcrocker.net> References: <4D87612E.3090900@dcrocker.net> From: Scott Brim Date: Mon, 21 Mar 2011 10:43:40 -0400 Message-ID: To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 14:47:06 -0000 On Mon, Mar 21, 2011 at 10:31, Dave CROCKER wrote: > Folks, > > I just saw the announcement for the Technical Plenary presentation. > > As described, the session suggests a failure to recognize at least two > architectural issues. Dave, here's my understanding ... > One is that it mandates full-time connectivity. No. Look, for example, at 'offline gmail', in which browser-based scripts cache files locally while doing their normal job of interacting with a cloud-based service. For starting offline, there is a little local app that essentially says "fire up a browser and run this script in it". > The other is that protocols > that it says are no longer needed are in fact still needed in some form, > albeit > as a layer above HTTP, rather than TCP. On one hand you have application programs with socket interfaces speaking to TCP and controlling everything TCP does. On the other you have application modules loaded by a browser and speaking to the browser (not necessarily HTTP). > Replacing TCP with HTTP does not eliminate the requirement for purpose-built > application protocols, such as specialized mailbox access. It's not replacing TCP with HTTP. It's adding another more abstract API. > On the other hand, it does tend to encourage an explosion of competing, > incompatible application protocols, making for rather remarkable burdens on > servers and clients. Those 'clients' are installed by the services. There is no need for every mail-related service to use exactly the same interface, since nothing needs to know in advance how the interaction will go. A few basics need to be agreed, e.g. HTTP, HTML, PHP, Javascript. But how those scripts actually speak to the service does not need to be standardized. > The summary also neglects to mention rather significant security concerns in > all this real-time application downloading... Please say more. From dhc@dcrocker.net Mon Mar 21 08:13:00 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695263A6877 for ; Mon, 21 Mar 2011 08:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxRTXdoPaolc for ; Mon, 21 Mar 2011 08:12:59 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 5D36E3A6875 for ; Mon, 21 Mar 2011 08:12:59 -0700 (PDT) Received: from [192.168.1.4] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p2LFEOiK021081 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2011 08:14:29 -0700 Message-ID: <4D876B4C.5070706@dcrocker.net> Date: Mon, 21 Mar 2011 08:14:20 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Scott Brim References: <4D87612E.3090900@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 21 Mar 2011 08:14:30 -0700 (PDT) Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 15:13:00 -0000 On 3/21/2011 7:43 AM, Scott Brim wrote: >> One is that it mandates full-time connectivity. > > No. Look, for example, at 'offline gmail', in which browser-based > scripts cache files locally while doing their normal job of > interacting with a cloud-based service. For starting offline, there > is a little local app that essentially says "fire up a browser and run > this script in it". Exactly. That's just another installed app: >> The other is that protocols >> that it says are no longer needed are in fact still needed in some form, >> albeit >> as a layer above HTTP, rather than TCP. > > On one hand you have application programs with socket interfaces > speaking to TCP and controlling everything TCP does. On the other you > have application modules loaded by a browser and speaking to the > browser (not necessarily HTTP). Well, I do note the somewhat different terminology you use to distinguish the two, but I'm not clear how that relates to my point: There is still a special protocol for the tailored application. >> Replacing TCP with HTTP does not eliminate the requirement for purpose-built >> application protocols, such as specialized mailbox access. > > It's not replacing TCP with HTTP. It's adding another more abstract API. Not just an API. There is are a set of exchange conventions that must exist between the client and the server to achieve the specifics of the application service. That the server downloads code to the client and thereby provides the software for both ends of the exchange does not change the fact that this is a tailored exchange. In networking, structured data exchanges are typically called protocols... >> On the other hand, it does tend to encourage an explosion of competing, >> incompatible application protocols, making for rather remarkable burdens on >> servers and clients. > > Those 'clients' are installed by the services. There is no need for > every mail-related service to use exactly the same interface, since > nothing needs to know in advance how the interaction will go. A few I was not trying to deny the operational "convenience" of this process, although note that the gmail offline example still requires the user to go through installation hassles. My point is that all this spontaneous downloading of redundant and slightly different software carries some problems. (cf, Dave Cridland's response.) To me, one of the more serious problems is the failure to see that these implement a potential explosion of proprietary protocols. > basics need to be agreed, e.g. HTTP, HTML, PHP, Javascript. But how > those scripts actually speak to the service does not need to be > standardized. As the other Dave C notes, that is a heck of a lot of infrastructure overhead. >> The summary also neglects to mention rather significant security concerns in >> all this real-time application downloading... There is a popular name for software that is injected into a user's machine without the user necessarily knowing about it or approving of it explicitly... To get computer sciency: mobile agent models have long been understood to pose a serious security risk. But don't get me wrong. I think mobile agent technology is the bee's knees. I've been a fan at least since working on an early example (Telescript at General Magic) and encouraging development of SafeTCL... However, I think it is problematic to view this space simplistically. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Claudio.Allocchio@garr.it Mon Mar 21 08:14:28 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60A453A6877 for ; Mon, 21 Mar 2011 08:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IGiVZo8WZ1p for ; Mon, 21 Mar 2011 08:14:27 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 79FA43A6875 for ; Mon, 21 Mar 2011 08:14:26 -0700 (PDT) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p2LFFTOs019705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2011 16:15:31 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p2LFFTOs019705 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=OAei1uHU3xiHAlM+h5qesmM58cfvN8DYUxd0j9QAPggnauKbrY0ZR0U1opV0W7HQ/ zhuxfclB0bhC4iZ08mxQ1dgm9do3Eq5eilJyc2m6Ojv7so9fnUhb5Zv5RRYfRf3FNCc yP1XJ6LNQKva3QihXam2ImtJf+OuOOnMo9v4+gU= Date: Mon, 21 Mar 2011 16:15:17 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: dcrocker@bbiw.net In-Reply-To: <4D87612E.3090900@dcrocker.net> Message-ID: References: <4D87612E.3090900@dcrocker.net> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 15:14:28 -0000 It seems to me more a "provocative" talk, than a fully consisten one... but of course it also accepts as "granted" thet given HTTP goes throug firewalls, and NATs etc, it is the way to solve the problem that the "transport" has in IPv4. Defintly a wrong concept... On Mon, 21 Mar 2011, Dave CROCKER wrote: > Folks, > > I just saw the announcement for the Technical Plenary presentation. > > As described, the session suggests a failure to recognize at least two > architectural issues. > > One is that it mandates full-time connectivity. The other is that protocols > that it says are no longer needed are in fact still needed in some form, > albeit > as a layer above HTTP, rather than TCP. > > Replacing TCP with HTTP does not eliminate the requirement for purpose-built > application protocols, such as specialized mailbox access. > > On the other hand, it does tend to encourage an explosion of competing, > incompatible application protocols, making for rather remarkable burdens on > servers and clients. I agree... just an example? "calendars"... we do have protocols for it... but a large number of those implemented "inside HTTP" just do not interoperate among them and with standard clients. Another example? audio/video communication in collaborative/group communications. > > The summary also neglects to mention rather significant security concerns in > all this real-time application downloading... sure! and I will be there to pose lot's of questions about this security aspect of the proposed solutions. :-) > > d/ > > >> The Future of Applications >> >> >> Advancements in the design of web browsers have introduced fundamental >> changes to the architecture of application protocols. The widespread >> availability and growing sophistication of JavaScript interpreters in >> browsers enables web servers to push to browsers all of the application >> logic required to implement a client-server protocol. Consequently, many >> client-server applications that once required an installed client on a host >> computer now can rely simply on a modern browser to act as a client for the >> purposes of a particular application. For example, where once email clients >> required a custom application to access an inbox, increasingly a web >> browser >> can serve this purpose as well as the purpose-built applications of the >> past. Similarly, HTTP with the assistance of JavaScript can subsume the >> functions performed by the protocols like POP3 and IMAP. The need for >> Internet standards beyond HTTP to implement an email inbox application >> consequently diminishes - why author standards and worry about >> interoperability of clients and servers when the server can simply push to >> the client all the code it needs to be interoperable? >> >> Many client-server applications on the Internet could potential migrate to >> this post-standardization environment. In this environment, there is of >> course still a role for the IETF to play: existing working groups like HyBi >> and OAuth are examples of areas where standards work is still required to >> support this application development paradigm. Collectively, we need to >> identify areas where the standardization is unlikely to be relevant in the >> future, and focus our efforts on those areas where our application designs >> will remain impactful. The goals of this session are to explore future >> areas >> of IETF work surrounding this evolution. >> >> Speakers: Jonathan Rosenberg (Skype) Harald Alvestrand (Google) Henry S. >> Thompson (W3C) > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From vumip1@gmail.com Mon Mar 21 08:38:53 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37E528C0E8 for ; Mon, 21 Mar 2011 08:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUsA7fagEUbM for ; Mon, 21 Mar 2011 08:38:52 -0700 (PDT) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by core3.amsl.com (Postfix) with ESMTP id 1F31628C0E4 for ; Mon, 21 Mar 2011 08:38:51 -0700 (PDT) Received: by gxk28 with SMTP id 28so3424123gxk.27 for ; Mon, 21 Mar 2011 08:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u+bl9kIAuZy6If5EBhvn5l0pZXIF9w8GuOyUdlJso7k=; b=F3iZY9aaZB+ygMmPdCmNm2dThk+UKM3bNL+kS5N+kVKmTLhPQpNck8NUDwYc+JFHSy +qaT7z1Ffk8+u6XTzY7qSejlN5mCnTN1O+g0wuH4ZHRDgd6UwRGTW+Rkbo4LsQDgeYO1 Njzmli/LSugDXit13ER7dO7wTgyWyz9RoE9RY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=h/8NfXEo+z/BoIhUJjr2y5hi+oB5DHksnggV8MVht61be19MZseo382kqhiSZd8gpc hLHvoa8vC4BFtRf6tKXqHfU682cSUYC8VCdT2Tzja/2mmYSBGaQc9AIEz21IiWKnTsIy ALg2s5U6WAxKXVlKPopaqWger4w+vH2fL0lbs= MIME-Version: 1.0 Received: by 10.146.164.11 with SMTP id m11mr3887176yae.20.1300722023867; Mon, 21 Mar 2011 08:40:23 -0700 (PDT) Received: by 10.146.86.16 with HTTP; Mon, 21 Mar 2011 08:40:23 -0700 (PDT) In-Reply-To: References: <4D87612E.3090900@dcrocker.net> Date: Mon, 21 Mar 2011 11:40:23 -0400 Message-ID: From: Bhumip Khasnabish To: Claudio Allocchio Content-Type: multipart/alternative; boundary=000e0cd48c422f2765049efff214 Cc: dcrocker@bbiw.net, Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 15:38:54 -0000 --000e0cd48c422f2765049efff214 Content-Type: text/plain; charset=ISO-8859-1 Virtualization of the desktop infrastructure with properly defined interface protocols and APIs may help solve the problems. We probably need to explore these more in the APP area. Thanks. Bhumip (vumip1@gmail.com) ** On Mon, Mar 21, 2011 at 11:15 AM, Claudio Allocchio < Claudio.Allocchio@garr.it> wrote: > > It seems to me more a "provocative" talk, than a fully consisten one... but > of course it also accepts as "granted" thet given HTTP goes throug > firewalls, and NATs etc, it is the way to solve the problem that the > "transport" has in IPv4. > > Defintly a wrong concept... > > > On Mon, 21 Mar 2011, Dave CROCKER wrote: > > Folks, >> >> I just saw the announcement for the Technical Plenary presentation. >> >> As described, the session suggests a failure to recognize at least two >> architectural issues. >> >> One is that it mandates full-time connectivity. The other is that >> protocols >> that it says are no longer needed are in fact still needed in some form, >> albeit >> as a layer above HTTP, rather than TCP. >> >> Replacing TCP with HTTP does not eliminate the requirement for >> purpose-built >> application protocols, such as specialized mailbox access. >> >> On the other hand, it does tend to encourage an explosion of competing, >> incompatible application protocols, making for rather remarkable burdens >> on >> servers and clients. >> > > I agree... just an example? "calendars"... we do have protocols for it... > but a large number of those implemented "inside HTTP" just do not > interoperate among them and with standard clients. Another example? > audio/video communication in collaborative/group communications. > > > >> The summary also neglects to mention rather significant security concerns >> in all this real-time application downloading... >> > > sure! > > and I will be there to pose lot's of questions about this security aspect > of the proposed solutions. :-) > > > > >> d/ >> >> >> The Future of Applications >>> >>> >>> Advancements in the design of web browsers have introduced fundamental >>> changes to the architecture of application protocols. The widespread >>> availability and growing sophistication of JavaScript interpreters in >>> browsers enables web servers to push to browsers all of the application >>> logic required to implement a client-server protocol. Consequently, many >>> client-server applications that once required an installed client on a >>> host >>> computer now can rely simply on a modern browser to act as a client for >>> the >>> purposes of a particular application. For example, where once email >>> clients >>> required a custom application to access an inbox, increasingly a web >>> browser >>> can serve this purpose as well as the purpose-built applications of the >>> past. Similarly, HTTP with the assistance of JavaScript can subsume the >>> functions performed by the protocols like POP3 and IMAP. The need for >>> Internet standards beyond HTTP to implement an email inbox application >>> consequently diminishes - why author standards and worry about >>> interoperability of clients and servers when the server can simply push >>> to >>> the client all the code it needs to be interoperable? >>> >>> Many client-server applications on the Internet could potential migrate >>> to >>> this post-standardization environment. In this environment, there is of >>> course still a role for the IETF to play: existing working groups like >>> HyBi >>> and OAuth are examples of areas where standards work is still required to >>> support this application development paradigm. Collectively, we need to >>> identify areas where the standardization is unlikely to be relevant in >>> the >>> future, and focus our efforts on those areas where our application >>> designs >>> will remain impactful. The goals of this session are to explore future >>> areas >>> of IETF work surrounding this evolution. >>> >>> Speakers: Jonathan Rosenberg (Skype) Harald Alvestrand (Google) Henry S. >>> Thompson (W3C) >>> >> >> -- >> >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > ------------------------------------------------------------------------------ > Claudio Allocchio G A R R > Claudio.Allocchio@garr.it > Senior Technical Officer > tel: +39 040 3758523 Italian Academic and G=Claudio; > S=Allocchio; > fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; > > PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --000e0cd48c422f2765049efff214 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Virt= ualization of the desktop infrastructure with properly defined interface pr= otocols and APIs may help solve the problems.=A0 We prob= ably need to explore these more in the APP area.=A0 Thanks.

Bhum= ip (vumip1@gmail.com)

=A0
On Mon, Mar 21, 2011 at 11:15 AM, Claudio Allocc= hio <Clau= dio.Allocchio@garr.it> wrote:

It seems to me more a "= provocative" talk, than a fully consisten one... but of course it also= accepts as "granted" thet given HTTP goes throug firewalls, and = NATs etc, it is the way to solve the problem that the "transport"= has in IPv4.

Defintly a wrong concept...=20


On Mon, 21 Mar 2011, Dave CROCKER wrote:

Folks,

I just saw the ann= ouncement for the Technical Plenary presentation.

As described, the = session suggests a failure to recognize at least two architectural issues.<= br>
One is that it mandates full-time connectivity. =A0The other is that pr= otocols
that it says are no longer needed are in fact still needed in so= me form, albeit
as a layer above HTTP, rather than TCP.

Replacing= TCP with HTTP does not eliminate the requirement for purpose-built
application protocols, such as specialized mailbox access.

On the ot= her hand, it does tend to encourage an explosion of competing,
incompati= ble application protocols, making for rather remarkable burdens on
serve= rs and clients.

I agree... just an example? "calendars"...= we do have protocols for it... but a large number of those implemented &qu= ot;inside HTTP" just do not interoperate among them and with standard = clients. Another example? audio/video communication in collaborative/group = communications.=20



The summary also neglects to= mention rather significant security concerns in all this real-time applica= tion downloading...

sure!

and I will be there to pose lot's o= f questions about this security aspect of the proposed solutions. :-)=20




d/


The Future of Applications

Advancements in the design of web browsers have introduced fundamenta= l
changes to the architecture of application protocols. The widespread
ava= ilability and growing sophistication of JavaScript interpreters in
brows= ers enables web servers to push to browsers all of the application
logic= required to implement a client-server protocol. Consequently, many
client-server applications that once required an installed client on a host=
computer now can rely simply on a modern browser to act as a client for= the
purposes of a particular application. For example, where once email= clients
required a custom application to access an inbox, increasingly a web browse= r
can serve this purpose as well as the purpose-built applications of th= e
past. Similarly, HTTP with the assistance of JavaScript can subsume th= e
functions performed by the protocols like POP3 and IMAP. The need for
In= ternet standards beyond HTTP to implement an email inbox application
con= sequently diminishes - why author standards and worry about
interoperabi= lity of clients and servers when the server can simply push to
the client all the code it needs to be interoperable?

Many client-se= rver applications on the Internet could potential migrate to
this post-s= tandardization environment. In this environment, there is of
course stil= l a role for the IETF to play: existing working groups like HyBi
and OAuth are examples of areas where standards work is still required tosupport this application development paradigm. Collectively, we need toidentify areas where the standardization is unlikely to be relevant in th= e
future, and focus our efforts on those areas where our application designs<= br>will remain impactful. The goals of this session are to explore future a= reas
of IETF work surrounding this evolution.

Speakers: Jonathan = Rosenberg (Skype) Harald Alvestrand (Google) Henry S.
Thompson (W3C)

--

=A0Dave Crocker
=A0Branden= burg InternetWorking
=A0b= biw.net
_______________________________________________
apps-disc= uss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

----------------------------------------------= --------------------------------
Claudio Allocchio =A0 =A0 =A0 =A0 =A0 = =A0 G =A0 A =A0 R =A0 R =A0 =A0 =A0 =A0 =A0Claudio.Allocchio@garr.it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Senior Technical Officer
= tel: +39 040 375852= 3 =A0 =A0 =A0Italian Academic and =A0 =A0 =A0 G=3DClaudio; S=3DAllocchi= o;
fax: +39 040 = 3758565 =A0 =A0 =A0 =A0Research Network =A0 =A0 =A0 =A0 P=3Dgarr; A=3Dg= arr; C=3Dit;

=A0 =A0 =A0 =A0 =A0 PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca= =20

_______________________________________________
ap= ps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman= /listinfo/apps-discuss


=A0 --000e0cd48c422f2765049efff214-- From dhc@dcrocker.net Mon Mar 21 08:44:47 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B91028C0EF for ; Mon, 21 Mar 2011 08:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mg0nCJiSOIeF for ; Mon, 21 Mar 2011 08:44:46 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 83FFF28C0EE for ; Mon, 21 Mar 2011 08:44:46 -0700 (PDT) Received: from [192.168.1.4] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p2LFk3OL022018 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2011 08:46:08 -0700 Message-ID: <4D8772B7.7030200@dcrocker.net> Date: Mon, 21 Mar 2011 08:45:59 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Claudio Allocchio References: <4D87612E.3090900@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 21 Mar 2011 08:46:09 -0700 (PDT) Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 15:44:47 -0000 On 3/21/2011 8:15 AM, Claudio Allocchio wrote: > and I will be there to pose lot's of questions about this security aspect of the > proposed solutions. :-) There is a difference between controlling the dais versus begging for time at the audience microphone. My concern, based on the offered description, is that the presentation will be an exercise in unbounded boosterism. Engineering is an exercise in discerning and selecting among tradeoffs. This requires diligent efforts to acknowledge, understand and deal with downsides and well as upsides. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Claudio.Allocchio@garr.it Mon Mar 21 09:08:35 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7153A6889 for ; Mon, 21 Mar 2011 09:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uy4JNSe2nXgn for ; Mon, 21 Mar 2011 09:08:34 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 7FA1B3A6886 for ; Mon, 21 Mar 2011 09:08:33 -0700 (PDT) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p2LG9hhq021286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2011 17:09:44 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p2LG9hhq021286 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=TC1q0UgXds0EhuWUKhynzKMfNvGERs3G+W4YRvEdvC2lGINLUuiFtNzklyQjoUhLJ czI1MR9exAXsmsuFRzD+Jk9mzij9egln81iGTZoV6lU9tIG9Mhwhs/dX7E7pFmihMVl /Oj3Lye8QMeclJIgIHMP2X+7skovs8hYvgr6VhU= Date: Mon, 21 Mar 2011 17:09:43 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: dcrocker@bbiw.net In-Reply-To: <4D8772B7.7030200@dcrocker.net> Message-ID: References: <4D87612E.3090900@dcrocker.net> <4D8772B7.7030200@dcrocker.net> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Claudio Allocchio , Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 16:08:35 -0000 > My concern, based on the offered description, is that the presentation will > be an exercise in unbounded boosterism. that's why I called it a "sort of provocative talk". If the intention was not this, e.g. to raise a discussion, then somebody did the wrong choice. > Engineering is an exercise in discerning and selecting among tradeoffs. This > requires diligent efforts to acknowledge, understand and deal with downsides > and well as upsides. I fully agree. Another bullet point not in the description: "mobile internet effects of the proposed solution". Carriers will be happy with all these one-time downloads, while users will be very unhappy while watching the "please wait" icon on their mobile device. ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From stpeter@stpeter.im Mon Mar 21 09:29:11 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E87CF28C0EA for ; Mon, 21 Mar 2011 09:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsFePtzMi2wt for ; Mon, 21 Mar 2011 09:29:09 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id BE4B23A687B for ; Mon, 21 Mar 2011 09:29:09 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 807EB40022; Mon, 21 Mar 2011 10:31:40 -0600 (MDT) Message-ID: <4D877D30.9090502@stpeter.im> Date: Mon, 21 Mar 2011 10:30:40 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4D87612E.3090900@dcrocker.net> <4D876B4C.5070706@dcrocker.net> In-Reply-To: <4D876B4C.5070706@dcrocker.net> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050608060705020101030704" Cc: Scott Brim , Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 16:29:11 -0000 This is a cryptographically signed message in MIME format. --------------ms050608060705020101030704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/21/11 9:14 AM, Dave CROCKER wrote: >=20 > On 3/21/2011 7:43 AM, Scott Brim wrote: >> >> On 3/21/11 8:31 AM, Dave CROCKER wrote: >> >>> Replacing TCP with HTTP does not eliminate the requirement for >>> purpose-built >>> application protocols, such as specialized mailbox access. >> >> It's not replacing TCP with HTTP. It's adding another more abstract A= PI. >=20 > Not just an API. >=20 > There is are a set of exchange conventions that must exist between the > client and the server to achieve the specifics of the application > service. That the server downloads code to the client and thereby > provides the software for both ends of the exchange does not change the= > fact that this is a tailored exchange. >=20 > In networking, structured data exchanges are typically called protocols= =2E.. >=20 >=20 >>> On the other hand, it does tend to encourage an explosion of competin= g, >>> incompatible application protocols, making for rather remarkable >>> burdens on >>> servers and clients. >> >> Those 'clients' are installed by the services. There is no need for >> every mail-related service to use exactly the same interface, since >> nothing needs to know in advance how the interaction will go. A few >=20 > I was not trying to deny the operational "convenience" of this process,= > although note that the gmail offline example still requires the user to= > go through installation hassles. >=20 > My point is that all this spontaneous downloading of redundant and > slightly different software carries some problems. (cf, Dave Cridland'= s > response.) >=20 > To me, one of the more serious problems is the failure to see that thes= e > implement a potential explosion of proprietary protocols. This is what I see, too: each service will have its own API / protocol, resulting in wonderful vendor lock-in for the service provider but a distinct lack of interoperability across services. We've just moved the problem elsewhere. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050608060705020101030704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMy MTE2MzA0MFowIwYJKoZIhvcNAQkEMRYEFK4df8QcTHYe7YzsH4LuRaXSpZiSMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQB3WSQGgh/sPlKgT6XWroiUII5uBKfZZu3S925ZF29ZkBHdYzzlSanVpKWo GTAnlM7+GQ8zfvFbzbQsM/2DDf+WQ1CuSu2+ZmsyVq09DawhpPTc/oICE1lodRgVHjTheqP3 zfg1Eihn4DIyIEatI5v/usktS8sKdH3GH7TVAp0dBLhQjmigKDbXZcLdnXCRMRBihPCzeCWX y3+Y+4gW56pzMJWBwcVVYxlHz6CXUEFGmE2cfhCpRFU4h0SbF6DmHzEm89ezTt9JuChmDMxG WpHKIz0hlttX4rQN2UKoXSOlx6zyiQ+g4vtZTHLyO0XernMZhKTGPpsY2leP4Jnz/SlQAAAA AAAA --------------ms050608060705020101030704-- From ted.ietf@gmail.com Mon Mar 21 09:30:28 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA2893A68A9 for ; Mon, 21 Mar 2011 09:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQoKs5w07zar for ; Mon, 21 Mar 2011 09:30:27 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4B5703A688C for ; Mon, 21 Mar 2011 09:30:27 -0700 (PDT) Received: by iwl42 with SMTP id 42so7722921iwl.31 for ; Mon, 21 Mar 2011 09:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CXJ0WqzSkorztpR/pvP/sgq/rkY8IQ71Yo6dr0+i0g4=; b=mkyZv0S4A3zvmaOrt8hqbV4pAqPsABrNjwl4cOZUpXnkoFiPdG2DHltAMDh0Q0gVv2 tNFwFcWYBf+GjsVZUACNYj7j8pqHeFbttg5tnERLt0squEW5SWZCnOWtgiuibG+MaDIz qWpXhCOJYbMUN5uFt6tfztu7d/9acaVIXl64s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uFM5eiN6rpJgEHZB5Bh/f0N6mGxaV6Lko3vp1XQjMXNDmUMsvQFrrYeXAHrdGI4YId RqBl1djqgqkjCz/mqBiSqsy1K8c7U1oVMBsuuFs2SZMSk0hTDfjEcJv4WDSpcdoHHZs/ gEuyLV00pCEM3qP4AQRSF78e3WjFUs/mSwKSE= MIME-Version: 1.0 Received: by 10.231.177.193 with SMTP id bj1mr4286779ibb.145.1300725119677; Mon, 21 Mar 2011 09:31:59 -0700 (PDT) Received: by 10.231.39.76 with HTTP; Mon, 21 Mar 2011 09:31:59 -0700 (PDT) In-Reply-To: References: <4D87612E.3090900@dcrocker.net> <4D8772B7.7030200@dcrocker.net> Date: Mon, 21 Mar 2011 09:31:59 -0700 Message-ID: From: Ted Hardie To: Claudio Allocchio Content-Type: text/plain; charset=ISO-8859-1 Cc: dcrocker@bbiw.net, Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 16:30:29 -0000 On Mon, Mar 21, 2011 at 9:09 AM, Claudio Allocchio > I fully agree. Another bullet point not in the description: "mobile internet > effects of the proposed solution". Carriers will be happy with all these > one-time downloads, while users will be very unhappy while watching the > "please wait" icon on their mobile device. > I fully agree that "mobile Internet effects" would be a useful thing to add to the discussion, but I think you should talk to an operator before presuming that they would be happy with " all these one-time downloads". If the consumption reduces the availability of resources in the radio access network such that fewer subscribers can be serviced in a cell sector, you are likely to get the opposite result. They either have unhappy customers who generate support costs and churn, build out costs to increase the number of cells, or artificial limitation of revenue opportunities. None are fun. To put this more generally, waste is the enemy of the resource-constrained device or system. And wireless spectrum is pretty commonly acknowledged as a constrained resource. regards, Ted Hardie From dhc@dcrocker.net Mon Mar 21 09:36:31 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA9A28C0F4 for ; Mon, 21 Mar 2011 09:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbZHjDWWrBCv for ; Mon, 21 Mar 2011 09:36:30 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 4F85028C157 for ; Mon, 21 Mar 2011 09:36:30 -0700 (PDT) Received: from [192.168.1.4] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p2LGbtTZ023419 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2011 09:38:00 -0700 Message-ID: <4D877EDF.1090500@dcrocker.net> Date: Mon, 21 Mar 2011 09:37:51 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Peter Saint-Andre References: <4D87612E.3090900@dcrocker.net> <4D876B4C.5070706@dcrocker.net> <4D877D30.9090502@stpeter.im> In-Reply-To: <4D877D30.9090502@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 21 Mar 2011 09:38:01 -0700 (PDT) Cc: Scott Brim , Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 16:36:31 -0000 On 3/21/2011 9:30 AM, Peter Saint-Andre wrote: > On 3/21/11 9:14 AM, Dave CROCKER wrote: >> To me, one of the more serious problems is the failure to see that these >> implement a potential explosion of proprietary protocols. > > This is what I see, too: each service will have its own API / protocol, > resulting in wonderful vendor lock-in for the service provider but a > distinct lack of interoperability across services. We've just moved the > problem elsewhere. I think Claudio raises another fundamental point, namely the loss of interoperability. The proposed model is a pure silo, with no apparent ability to have variations or incremental capabilities that build on the base, except by the single vendor providing the proprietary protocol. The point that Claudio and Ted make about possible inefficiencies due to repeated download is also worth noting.' d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Claudio.Allocchio@garr.it Mon Mar 21 09:42:26 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A591428C16A for ; Mon, 21 Mar 2011 09:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghmVkkU-OP2P for ; Mon, 21 Mar 2011 09:42:25 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 2068728C0EB for ; Mon, 21 Mar 2011 09:42:24 -0700 (PDT) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p2LGhedn022162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2011 17:43:41 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p2LGhedn022162 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=F6A+RKNFV8BvlU5Q6YVMs+h0m6v4Pwq7/msVfehioxgvaCuNa74ICRocE6jRLcKUE 628SgcZqjxGcY32jQrgvpqBLH61SrCvlladLWEsn20ZLp95Z2JHrxkdyESbCTmhNShK u2Xa1uYzmYZIUjxug1qKgpAeMkKKoFsLgHmvqEM= Date: Mon, 21 Mar 2011 17:43:40 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: Ted Hardie In-Reply-To: Message-ID: References: <4D87612E.3090900@dcrocker.net> <4D8772B7.7030200@dcrocker.net> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Claudio Allocchio , Apps Discuss , dcrocker@bbiw.net Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 16:42:26 -0000 On Mon, 21 Mar 2011, Ted Hardie wrote: > On Mon, Mar 21, 2011 at 9:09 AM, Claudio Allocchio >> I fully agree. Another bullet point not in the description: "mobile internet >> effects of the proposed solution". Carriers will be happy with all these >> one-time downloads, while users will be very unhappy while watching the >> "please wait" icon on their mobile device. >> > > I fully agree that "mobile Internet effects" would be a useful thing > to add to the discussion, but I think you should talk to an operator > before presuming that they would be happy with " all these one-time > downloads". yes, ... I was just thinking of the "billing aspect of volume based contracts" of course. If the consumption reduces the availability of resources > in the radio access network such that fewer subscribers can be > serviced in a cell sector, you are likely to get the opposite result. > They either have unhappy customers who generate support costs and > churn, build out costs to increase the number of cells, or artificial > limitation of revenue opportunities. None are fun. And in some areas we already see the effects: 3G is no longer what it used to be, and users rush to WiFi hot-spots, non only for billing reasons. > To put this more generally, waste is the enemy of the > resource-constrained device or system. And wireless spectrum is > pretty commonly acknowledged as a constrained resource. +1 > > regards, > > Ted Hardie > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From scott.brim@gmail.com Mon Mar 21 09:43:13 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66E0F28C0EB for ; Mon, 21 Mar 2011 09:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.567 X-Spam-Level: X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCT066+OzqBe for ; Mon, 21 Mar 2011 09:43:12 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3B1613A687B for ; Mon, 21 Mar 2011 09:43:12 -0700 (PDT) Received: by iwl42 with SMTP id 42so7735607iwl.31 for ; Mon, 21 Mar 2011 09:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pqcEx6Wb8U2Qj6smm+SSCEfqfVYjhwmx7ds0Uo2aLio=; b=Chv2q3TjiQT1tBSd8pYSHKtKoRmG2pzlofHQ0XlQrOOpyCDdQ8/+TStNa6Mn9lqeBc LQH72crvgtLj9NHghf91XXY9M14Ssi4T/rmpy784jDq/Y7OsKVqOyO1FrW2nZ6jTi3oP XMidehSmu8jn/HNQSNE4wU+xI42CNmk0z3p6Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=PXKE2VJmd5H4xP+LK8TNkcK2S9JxiJB6gosrRm9+358wjrlaqcU9OgWVMBb/IUIlTo 0pMnQt0g/u5qReuqQJVXjIGqN5/8Za66X0l21v3fSuz7gLSeRoP/b54znbpsOl1R4rNn ico3kmzlD+QKnPJq0skotrLpXe3tyS6Nfra/g= Received: by 10.42.18.193 with SMTP id y1mr7012102ica.415.1300725727426; Mon, 21 Mar 2011 09:42:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.164.74 with HTTP; Mon, 21 Mar 2011 09:40:01 -0700 (PDT) In-Reply-To: <4D877D30.9090502@stpeter.im> References: <4D87612E.3090900@dcrocker.net> <4D876B4C.5070706@dcrocker.net> <4D877D30.9090502@stpeter.im> From: Scott Brim Date: Mon, 21 Mar 2011 12:40:01 -0400 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: dcrocker@bbiw.net, Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 16:43:13 -0000 On Mon, Mar 21, 2011 at 12:30, Peter Saint-Andre wrote: > This is what I see, too: each service will have its own API / protocol, > resulting in wonderful vendor lock-in for the service provider but a > distinct lack of interoperability across services. We've just moved the > problem elsewhere. What interoperability do you need? This isn't peer to peer, it's client/server. All of the servers have de facto converged on the same client capabilities (http, html etc). It's already standardized. Granted there are new scripting languages all the time, and some browsers like new transport protocols, but those don't lead to interoperability problems. They lead to implementor problems, having to do different versions of software for different environments. Is that what you're pointing to? Would you say that iPhone and Android should have the same app environments? From scott.brim@gmail.com Mon Mar 21 09:44:26 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 917AB28C0EB for ; Mon, 21 Mar 2011 09:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7p7S0UKre394 for ; Mon, 21 Mar 2011 09:44:25 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C7EB43A687B for ; Mon, 21 Mar 2011 09:44:25 -0700 (PDT) Received: by iwl42 with SMTP id 42so7736832iwl.31 for ; Mon, 21 Mar 2011 09:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=l9SiyqG/2YtpH2OhvRxbdio+FaYi2EkgNWJuEZ18zXE=; b=x6HFdPEmguio4LnCc+sqAgkNEMICt+Ak4g/7AZO9BUTjhFXQeXieSsN8FAGMepVuZu vISsl5jUFYEZyoyirEPuvSohYb41hXvNPpS2r0BGx3QQgzvIbCPPZ3orgZBzBvX2rXIx sf16XlWsTI+yMzgj1Goat19hG0pm5nlGJIaq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ONeYiQ0JNna8fJgzWzN5SvAsmJMDprOWOmLE011UsUnUUF50x1ZemqH62Abwo7XI8m 48jg8CUswny3aU9st9uWjQX1+jwNfWbXEV9EdrZ/8o1t/+S8m5zZh8SXTc+8CE6I0zIV +qwmfLH8TuACgaA9Ydl5qyKDOdtA6h8mdEN9E= Received: by 10.42.161.198 with SMTP id u6mr6991795icx.482.1300725817588; Mon, 21 Mar 2011 09:43:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.164.74 with HTTP; Mon, 21 Mar 2011 09:40:49 -0700 (PDT) In-Reply-To: <4D877EDF.1090500@dcrocker.net> References: <4D87612E.3090900@dcrocker.net> <4D876B4C.5070706@dcrocker.net> <4D877D30.9090502@stpeter.im> <4D877EDF.1090500@dcrocker.net> From: Scott Brim Date: Mon, 21 Mar 2011 12:40:49 -0400 Message-ID: To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 16:44:26 -0000 On Mon, Mar 21, 2011 at 12:37, Dave CROCKER wrote: > I think Claudio raises another fundamental point, namely the loss of > interoperability. =A0The proposed model is a pure silo, with no apparent > ability to have variations or incremental capabilities that build on the > base, except by the single vendor providing the proprietary protocol. Could you give a specific example? From cyrus@daboo.name Mon Mar 21 09:50:32 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC56F28C0EC for ; Mon, 21 Mar 2011 09:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2yMl7Qi23we for ; Mon, 21 Mar 2011 09:50:31 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 3E18028C0EB for ; Mon, 21 Mar 2011 09:50:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 80B761C2D8438; Mon, 21 Mar 2011 12:52:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4KFOoiYUW3r; Mon, 21 Mar 2011 12:52:03 -0400 (EDT) Received: from [17.101.34.182] (unknown [17.101.34.182]) by daboo.name (Postfix) with ESMTPSA id AAABB1C2D842B; Mon, 21 Mar 2011 12:52:01 -0400 (EDT) Date: Mon, 21 Mar 2011 12:52:13 -0400 From: Cyrus Daboo To: Scott Brim , Peter Saint-Andre Message-ID: In-Reply-To: References: <4D87612E.3090900@dcrocker.net> <4D876B4C.5070706@dcrocker.net> <4D877D30.9090502@stpeter.im> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1127 Cc: dcrocker@bbiw.net, Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 16:50:32 -0000 Hi Scott, --On March 21, 2011 12:40:01 PM -0400 Scott Brim wrote: >> This is what I see, too: each service will have its own API / protocol, >> resulting in wonderful vendor lock-in for the service provider but a >> distinct lack of interoperability across services. We've just moved the >> problem elsewhere. > > What interoperability do you need? This isn't peer to peer, it's > client/server. All of the servers have de facto converged on the same > client capabilities (http, html etc). It's already standardized. What if I have multiple service providers yet I want to present an aggregated view of all the data? e.g. the very common case of having multiple email accounts on different providers and wanting a "unified" inbox. With the "proprietary" approach of silo-ed web services, that becomes hard. Either I have to have a local app that understands each of the "proprietary" protocols and does the aggregation locally, or I have to rely on an intermediary to aggregate the data (which probably requires handing over credentials or doing some complicated crypto). -- Cyrus Daboo From vumip1@gmail.com Mon Mar 21 09:50:58 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6A6E3A68A6 for ; Mon, 21 Mar 2011 09:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gg32XGUdLV7h for ; Mon, 21 Mar 2011 09:50:56 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id A5B673A687B for ; Mon, 21 Mar 2011 09:50:56 -0700 (PDT) Received: by ywi6 with SMTP id 6so2981656ywi.31 for ; Mon, 21 Mar 2011 09:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rWRLHHt9XVZpNN9I3iMU1L2PTOHhy4Gz5JISxD5yEs0=; b=C9BptSg6ulylKI9UCNVLhtTOOqsdlG8bS8wOdh3I9lxxj1OOZvG7HkIwQ9Kz2olkJr OfWSNW+pFQh2Tr2a0RvTNCytyuBmd7HZajztWClyHVVFw1X8taaCynbuaquSGMx6Z8eV DQXUmQ3RmUDhii0lyg+UELDEQQ3m5DzTfZ7+s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JcgLwL5opmu2FN2NDD0lwC4rYtZ4PYq2DYfSZU3Y9ze8yEiNMJbD7Et19QUPKj7Fhs mpuqp0JXBWQLZ4HqxlkZlYI5jbAUg9BWd/M/ySWNxhGrm23j4tMZVQJN3kMsgqXjjaq3 TxIm/jxX3ZOWVyaa5UaRdV9zGzCMIH0WeAAm8= MIME-Version: 1.0 Received: by 10.236.200.138 with SMTP id z10mr5675570yhn.164.1300726348318; Mon, 21 Mar 2011 09:52:28 -0700 (PDT) Received: by 10.146.86.16 with HTTP; Mon, 21 Mar 2011 09:52:28 -0700 (PDT) In-Reply-To: <4D877D30.9090502@stpeter.im> References: <4D87612E.3090900@dcrocker.net> <4D876B4C.5070706@dcrocker.net> <4D877D30.9090502@stpeter.im> Date: Mon, 21 Mar 2011 12:52:28 -0400 Message-ID: From: Bhumip Khasnabish To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=20cf305b096af108a2049f00f346 Cc: Scott Brim , dcrocker@bbiw.net, Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 16:50:59 -0000 --20cf305b096af108a2049f00f346 Content-Type: text/plain; charset=ISO-8859-1 >This is what I see, too: each service will have its own API / protocol, >resulting in wonderful vendor lock-in for the service provider but a >distinct lack of interoperability across services. We've just moved the >problem elsewhere. >Peter Yes, actually each service, service provider, developer-group, etc. and so on start using own protocol/API .. the problem actually gets worse .. and the silos get bigger and bigger (not necessarily better). Bhumip On Mon, Mar 21, 2011 at 12:30 PM, Peter Saint-Andre wrote: > On 3/21/11 9:14 AM, Dave CROCKER wrote: > > > > On 3/21/2011 7:43 AM, Scott Brim wrote: > >> > >> On 3/21/11 8:31 AM, Dave CROCKER wrote: > >> > >>> Replacing TCP with HTTP does not eliminate the requirement for > >>> purpose-built > >>> application protocols, such as specialized mailbox access. > >> > >> It's not replacing TCP with HTTP. It's adding another more abstract > API. > > > > Not just an API. > > > > There is are a set of exchange conventions that must exist between the > > client and the server to achieve the specifics of the application > > service. That the server downloads code to the client and thereby > > provides the software for both ends of the exchange does not change the > > fact that this is a tailored exchange. > > > > In networking, structured data exchanges are typically called > protocols... > > > > > >>> On the other hand, it does tend to encourage an explosion of competing, > >>> incompatible application protocols, making for rather remarkable > >>> burdens on > >>> servers and clients. > >> > >> Those 'clients' are installed by the services. There is no need for > >> every mail-related service to use exactly the same interface, since > >> nothing needs to know in advance how the interaction will go. A few > > > > I was not trying to deny the operational "convenience" of this process, > > although note that the gmail offline example still requires the user to > > go through installation hassles. > > > > My point is that all this spontaneous downloading of redundant and > > slightly different software carries some problems. (cf, Dave Cridland's > > response.) > > > > To me, one of the more serious problems is the failure to see that these > > implement a potential explosion of proprietary protocols. > > This is what I see, too: each service will have its own API / protocol, > resulting in wonderful vendor lock-in for the service provider but a > distinct lack of interoperability across services. We've just moved the > problem elsewhere. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --20cf305b096af108a2049f00f346 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

>This is what I see, too: each service will have its own API / = protocol,
>resulting in wonderful vendor lock-in for the service prov= ider but a
>distinct lack of interoperability across services. We'= ;ve just moved the
>problem elsewhere.
>Peter
Yes, actually each service, service provider, developer-group, etc. an= d so on start using own protocol/API=A0.. the problem actually gets worse .= . and the silos get bigger and bigger (not necessarily better).=A0
=A0
Bhumip
=A0

=A0
On Mon, Mar 21, 2011 at 12:30 PM, Peter Saint-An= dre <stpeter@stp= eter.im> wrote:
On 3/21/11 9:14 AM, Dave CROCKER wrote:
>
> O= n 3/21/2011 7:43 AM, Scott Brim wrote:
>>
>> On 3/21/11 8:31 AM, Dave CROCKER wrote:
>&= gt;
>>> Replacing TCP with HTTP does not eliminate the requirem= ent for
>>> purpose-built
>>> application protocols= , such as specialized mailbox access.
>>
>> It's not replacing TCP with HTTP. =A0It's addi= ng another more abstract API.
>
> Not just an API.
>
&= gt; There is are a set of exchange conventions that must exist between the<= br> > client and the server to achieve the specifics of the application
&= gt; service. =A0That the server downloads code to the client and thereby> provides the software for both ends of the exchange does not change t= he
> fact that this is a tailored exchange.
>
> In networking, = structured data exchanges are typically called protocols...
>
>=
>>> On the other hand, it does tend to encourage an explosion = of competing,
>>> incompatible application protocols, making for rather remarkab= le
>>> burdens on
>>> servers and clients.
>&= gt;
>> Those 'clients' are installed by the services. =A0T= here is no need for
>> every mail-related service to use exactly the same interface, sinc= e
>> nothing needs to know in advance how the interaction will go.= =A0A few
>
> I was not trying to deny the operational "co= nvenience" of this process,
> although note that the gmail offline example still requires the user t= o
> go through installation hassles.
>
> My point is that= all this spontaneous downloading of redundant and
> slightly differe= nt software carries some problems. =A0(cf, Dave Cridland's
> response.)
>
> To me, one of the more serious problems is = the failure to see that these
> implement a potential explosion of pr= oprietary protocols.

This is what I see, too: each servi= ce will have its own API / protocol,
resulting in wonderful vendor lock-in for the service provider but a
dis= tinct lack of interoperability across services. We've just moved theproblem elsewhere.

Peter

--
Peter= Saint-Andre
https://stpeter.im/



_______________________________________________apps-discuss mailing list
apps= -discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



=A0 --20cf305b096af108a2049f00f346-- From dhc@dcrocker.net Mon Mar 21 09:54:11 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CEEF28C0EB for ; Mon, 21 Mar 2011 09:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8EBCi5Lw9Td for ; Mon, 21 Mar 2011 09:54:10 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 4FCB73A687B for ; Mon, 21 Mar 2011 09:54:10 -0700 (PDT) Received: from [192.168.1.4] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p2LGtZli024160 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2011 09:55:41 -0700 Message-ID: <4D878303.60908@dcrocker.net> Date: Mon, 21 Mar 2011 09:55:31 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Scott Brim References: <4D87612E.3090900@dcrocker.net> <4D876B4C.5070706@dcrocker.net> <4D877D30.9090502@stpeter.im> <4D877EDF.1090500@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 21 Mar 2011 09:55:41 -0700 (PDT) Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 16:54:11 -0000 On 3/21/2011 9:40 AM, Scott Brim wrote: > On Mon, Mar 21, 2011 at 12:37, Dave CROCKER wrote: >> I think Claudio raises another fundamental point, namely the loss of >> interoperability. The proposed model is a pure silo, with no apparent >> ability to have variations or incremental capabilities that build on the >> base, except by the single vendor providing the proprietary protocol. > > Could you give a specific example? My email client accesses 6 different accounts. The point of commonality is my client. Typical silo solutions are for that silo only. As being touted, that would mean 6 different downloaded, proprietary access clients, with my having to switch from one to another. Besides being a pain, this means that they cannot share data, such as getting a message in on one account and forwarding it through another. To the extent that you (quite reasonably) then project adaption of some of these to support additional, external accounts, what we done is merely to reinvent the general-purpose email client, except that I have to be careful to invoke the correct one every time... d/ ps. The rather bizare problem with many different and non-interoperable IM protocols is another example of this. Although some independent clients have gotten pretty good at providing an integrative experience, it is not possible to do group IMs except within a proprietary context requiring everyone to have an account with the same provider. If then. -- Dave Crocker Brandenburg InternetWorking bbiw.net From GK@ninebynine.org Mon Mar 21 09:54:36 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C820F28C156 for ; Mon, 21 Mar 2011 09:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.453 X-Spam-Level: X-Spam-Status: No, score=-5.453 tagged_above=-999 required=5 tests=[AWL=1.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MF2RMFcBifZ1 for ; Mon, 21 Mar 2011 09:54:35 -0700 (PDT) Received: from relay7.mail.ox.ac.uk (relay7.mail.ox.ac.uk [129.67.1.167]) by core3.amsl.com (Postfix) with ESMTP id 8E5DC3A687B for ; Mon, 21 Mar 2011 09:54:35 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay7.mail.ox.ac.uk with esmtp (Exim 4.74) (envelope-from ) id 1Q1iOh-0003Jq-P3; Mon, 21 Mar 2011 16:56:03 +0000 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Q1iOh-0003Ii-4m; Mon, 21 Mar 2011 16:56:03 +0000 Message-ID: <4D878303.6000401@ninebynine.org> Date: Mon, 21 Mar 2011 16:55:31 +0000 From: Graham Klyne User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4D87612E.3090900@dcrocker.net> <4D876B4C.5070706@dcrocker.net> <4D877D30.9090502@stpeter.im> <4D877EDF.1090500@dcrocker.net> In-Reply-To: <4D877EDF.1090500@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: Scott Brim , Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 16:54:36 -0000 Ah, I wish I could be there! I think it's not so black-and-white. The problems mentioned are real enough, but there are other considerations too: - for some applications, designing to run on HTTP can increase the effective use of bandwidth by making it easier to build applications around more coarse-grained exchanges. More bang per round-trip. (Of course this *can* be done over bare TCP, but HTTP handles much of the common grunt work). - for some applications, a focus on a RESTful style of interface pushes the emphasis away from multiple protocols towards a common protocol with more complex object representations. Yes, this moves the application domain problems somewhere else, but that somewhere else is less dependent on a detailed bilateral agreement about the nature of exchanges. - for some applications, using Javascript in the browser can dramatically reduce the complexity of a distributed client-server application, and the attendant network exchanges, by allowing client state to be managed locally and reducing the amount of state that the server needs to be aware of. HTTP is much, much more than a simple request/response protocol. It underpins the most successful, most scalable distributed application the world has seen, and *for some applications* that fit well into its particular model of interaction, I think it can offer improved efficiency and reduced siloing of applications. Of course, your application may vary. #g -- Dave CROCKER wrote: > > > On 3/21/2011 9:30 AM, Peter Saint-Andre wrote: >> On 3/21/11 9:14 AM, Dave CROCKER wrote: >>> To me, one of the more serious problems is the failure to see that these >>> implement a potential explosion of proprietary protocols. >> >> This is what I see, too: each service will have its own API / protocol, >> resulting in wonderful vendor lock-in for the service provider but a >> distinct lack of interoperability across services. We've just moved the >> problem elsewhere. > > > I think Claudio raises another fundamental point, namely the loss of > interoperability. The proposed model is a pure silo, with no apparent > ability to have variations or incremental capabilities that build on the > base, except by the single vendor providing the proprietary protocol. > > The point that Claudio and Ted make about possible inefficiencies due to > repeated download is also worth noting.' > > d/ > From hannes.tschofenig@gmx.net Mon Mar 21 09:57:27 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC8328C0EC for ; Mon, 21 Mar 2011 09:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEP1qv0g18Fk for ; Mon, 21 Mar 2011 09:57:26 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id ADD8528C0EB for ; Mon, 21 Mar 2011 09:57:25 -0700 (PDT) Received: (qmail invoked by alias); 21 Mar 2011 16:58:56 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp005) with SMTP; 21 Mar 2011 17:58:56 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18xcc177xkxWXZq6/7gg97iARUl/6EOQAKEA+s+su iOKWNV90yPmlaW Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4D87612E.3090900@dcrocker.net> Date: Mon, 21 Mar 2011 18:58:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> References: <4D87612E.3090900@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 16:57:27 -0000 Hi Dave,=20 you may want to take a look at the more complete writeup, which we = submitted as an Internet draft:=20 http://tools.ietf.org/html/draft-tschofenig-post-standardization-00 On your questions below:=20 On Mar 21, 2011, at 4:31 PM, Dave CROCKER wrote: > Folks, >=20 > I just saw the announcement for the Technical Plenary presentation. >=20 > As described, the session suggests a failure to recognize at least two = architectural issues. >=20 > One is that it mandates full-time connectivity. No; it does not mandate full-time connectivity.=20 It only mandates connectivity between the client and the server.=20 For example, look at your Web-based email account (like Gmail). The = client-to-server interaction indeed requires connectivity.=20 However, it does not require full end-to-end community to work. The = real-time communication work that is being discussed in the RAI area = does require end-to-end community because this is the entire purpose of = the whole exercise.=20 > The other is that protocols > that it says are no longer needed are in fact still needed in some = form, albeit > as a layer above HTTP, rather than TCP. We are not saying that the protocols are not needed at all anymore.=20 However, the need for standardization shifts.=20 >=20 > Replacing TCP with HTTP does not eliminate the requirement for = purpose-built > application protocols, such as specialized mailbox access. >=20 > On the other hand, it does tend to encourage an explosion of = competing, > incompatible application protocols, making for rather remarkable = burdens on > servers and clients. Not really. It allows people to innovate at full speed. There is no need = to go through a 5 year standardization effort for a protocol extension = when you can make it available to others easily (without even letting = the user to download and instal a new application).=20 >=20 > The summary also neglects to mention rather significant security = concerns in all this real-time application downloading... The short summary on the announcement page cannot cover every issue. We = did, however, touch on this aspect in the draft.=20 Thanks for paying attention to the IAB plenary topic.=20 Ciao Hannes >=20 > d/ >=20 >=20 >> The Future of Applications >>=20 >>=20 >> Advancements in the design of web browsers have introduced = fundamental >> changes to the architecture of application protocols. The widespread >> availability and growing sophistication of JavaScript interpreters in >> browsers enables web servers to push to browsers all of the = application >> logic required to implement a client-server protocol. Consequently, = many >> client-server applications that once required an installed client on = a host >> computer now can rely simply on a modern browser to act as a client = for the >> purposes of a particular application. For example, where once email = clients >> required a custom application to access an inbox, increasingly a web = browser >> can serve this purpose as well as the purpose-built applications of = the >> past. Similarly, HTTP with the assistance of JavaScript can subsume = the >> functions performed by the protocols like POP3 and IMAP. The need for >> Internet standards beyond HTTP to implement an email inbox = application >> consequently diminishes - why author standards and worry about >> interoperability of clients and servers when the server can simply = push to >> the client all the code it needs to be interoperable? >>=20 >> Many client-server applications on the Internet could potential = migrate to >> this post-standardization environment. In this environment, there is = of >> course still a role for the IETF to play: existing working groups = like HyBi >> and OAuth are examples of areas where standards work is still = required to >> support this application development paradigm. Collectively, we need = to >> identify areas where the standardization is unlikely to be relevant = in the >> future, and focus our efforts on those areas where our application = designs >> will remain impactful. The goals of this session are to explore = future areas >> of IETF work surrounding this evolution. >>=20 >> Speakers: Jonathan Rosenberg (Skype) Harald Alvestrand (Google) Henry = S. >> Thompson (W3C) >=20 > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From hannes.tschofenig@gmx.net Mon Mar 21 10:02:18 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF81028C16D for ; Mon, 21 Mar 2011 10:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x26O93Fl2sXy for ; Mon, 21 Mar 2011 10:02:18 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 6418C28C156 for ; Mon, 21 Mar 2011 10:02:16 -0700 (PDT) Received: (qmail invoked by alias); 21 Mar 2011 17:03:48 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp069) with SMTP; 21 Mar 2011 18:03:48 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+cUONeY1ic6P9tpbDc3Uede3+IEBWvCoG8z2s7+S EPou6XfcL8KGEh Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Mon, 21 Mar 2011 19:03:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F5590FD-CF20-46FF-B85D-E8CA66133D00@gmx.net> References: <4D87612E.3090900@dcrocker.net> <4D876B4C.5070706@dcrocker.net> <4D877D30.9090502@stpeter.im> To: Bhumip Khasnabish X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: Apps Discuss , Scott Brim , dcrocker@bbiw.net Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:02:18 -0000 The most important aspect to look at is where interoperability is truly = needed.=20 The speakers at the plenary will argue that you do not need = interoperability everywhere. Do not get me wrong - interoperability is great but it comes at a cost.=20= If you look at the Web application space then you would quickly ask = yourself "Where would the Web be if everything has to be standardized?" On Mar 21, 2011, at 6:52 PM, Bhumip Khasnabish wrote: > >This is what I see, too: each service will have its own API / = protocol, > >resulting in wonderful vendor lock-in for the service provider but a > >distinct lack of interoperability across services. We've just moved = the > >problem elsewhere. > >Peter > Yes, actually each service, service provider, developer-group, etc. = and so on start using own protocol/API .. the problem actually gets = worse .. and the silos get bigger and bigger (not necessarily better).=20= > =20 > Bhumip From scott.brim@gmail.com Mon Mar 21 10:03:28 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2479628C156 for ; Mon, 21 Mar 2011 10:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.57 X-Spam-Level: X-Spam-Status: No, score=-103.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2mI5EvrndS8 for ; Mon, 21 Mar 2011 10:03:24 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 533543A687B for ; Mon, 21 Mar 2011 10:03:24 -0700 (PDT) Received: by iwl42 with SMTP id 42so7754644iwl.31 for ; Mon, 21 Mar 2011 10:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Qcu+SKLijMcjvhCJlOApV+qKQ27ZbfCJ9QGCmR6F3bs=; b=j0Rw2IMdQpUPB+lerFQAKEaHyGDtmoMGmDPibNCejb+dRv048jMTW1spmQrBPuz13O 1s6ZI8R3VgIzWoAcWKM4fCqD0o1L8AZYZvIXPRd4fA2x/REBguEDTtwRv/oAZpM1ljDa F04LpWojA6AKtZfugNl+suwgwiooBlKAuSb9Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ZNbCMDmzWe44oAUHZds54fNxE952CTTDgunQM0wbgApXbFcXPttnf7vcTRqhEfC7+i WVF0j0ScHlHbJVOw7bTdd+obteyN7JFjE2ceAs+LqkhNwpL/KyDkgV6NJ0XINHlIwa0y 9cYb6ZI/raU7SePuzgLQd6yCzBiMVlRtJCEuE= Received: by 10.42.117.68 with SMTP id s4mr7241721icq.348.1300727032362; Mon, 21 Mar 2011 10:03:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.164.74 with HTTP; Mon, 21 Mar 2011 10:01:38 -0700 (PDT) In-Reply-To: References: <4D87612E.3090900@dcrocker.net> <4D876B4C.5070706@dcrocker.net> <4D877D30.9090502@stpeter.im> From: Scott Brim Date: Mon, 21 Mar 2011 13:01:38 -0400 Message-ID: To: Cyrus Daboo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss , dcrocker@bbiw.net Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:03:28 -0000 On Mon, Mar 21, 2011 at 12:52, Cyrus Daboo wrote: > Hi Scott, > > --On March 21, 2011 12:40:01 PM -0400 Scott Brim > wrote: > >>> This is what I see, too: each service will have its own API / protocol, >>> resulting in wonderful vendor lock-in for the service provider but a >>> distinct lack of interoperability across services. We've just moved the >>> problem elsewhere. >> >> What interoperability do you need? =A0This isn't peer to peer, it's >> client/server. =A0All of the servers have de facto converged on the same >> client capabilities (http, html etc). =A0It's already standardized. > > What if I have multiple service providers yet I want to present an > aggregated view of all the data? e.g. the very common case of having > multiple email accounts on different providers and wanting a "unified" > inbox. With the "proprietary" approach of silo-ed web services, that beco= mes > hard. Either I have to have a local app that understands each of the > "proprietary" protocols and does the aggregation locally, or I have to re= ly > on an intermediary to aggregate the data (which probably requires handing > over credentials or doing some complicated crypto). First, as I understand it, the aggregator is the browser. Don't think of each of these as "mail". They are more "browser-based interactions" that might include mail. Consider the google "mail" front page, which can optionally have 17 other things (calendar, online friends, grocery manager via Google API, etc.). So if your browser has the tools to connect to each of these services -- which it does -- then it becomes a problem of how to show multiple "pages" in an interesting way. Second, if you want to totally integrate, e.g. have a common inbox for mail, then yes you need 'mail' APIs for each of them, as opposed to 'service' APIs that I believe we're talking about. From stpeter@stpeter.im Mon Mar 21 10:05:43 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1BC28C0F2 for ; Mon, 21 Mar 2011 10:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85RSoIP8lTDu for ; Mon, 21 Mar 2011 10:05:42 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 73F0F3A687B for ; Mon, 21 Mar 2011 10:05:42 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D5FE04006D for ; Mon, 21 Mar 2011 11:08:13 -0600 (MDT) Message-ID: <4D8785C1.8020703@stpeter.im> Date: Mon, 21 Mar 2011 11:07:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080606050208020908010509" Subject: [apps-discuss] updated agenda X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:05:43 -0000 This is a cryptographically signed message in MIME format. --------------ms080606050208020908010509 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI, I've updated the IETF 80 agenda for AppsArea: http://www.ietf.org/proceedings/80/agenda/apparea.txt The open mic time at the end is now gone, replaced by a presentation from Dave Crocker about DomainKeys Security Tagging (DOSETA). Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080606050208020908010509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMy MTE3MDcxM1owIwYJKoZIhvcNAQkEMRYEFFzuwBFQA88iAdGGR2CQwbZ9QAHUMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCNZZn6DUD8QG1qAGr71Mx4GxLUSBk51Ugh3YvtJg19gWeA9ftiQOyVLBdG 3HC4CVuO3LFJ2TnX9ja8Kly2ZyXNqp3IGN2k8emno14L4eALt3mDN28WSVfBDjByPSX286ah HQuK/q49Qu6Ph5VB2CniJkoj/dOW7Gho16Uht05czd3eeWKJmTPMQ4/7uf1nXSSpRGn57PRT GDOBKDEqLKAo2IpFJV919MB16pHK1cWjiBRx/zupuIhdNpbkFBhaAKtbnpbdTlcmqXsWozgj kYMdwAe0yUkmo/0rZfd0KkK5O9MEuAr31NQywXbRA4xQJhsg/Cqi1iGpIdpQcfqE2SBSAAAA AAAA --------------ms080606050208020908010509-- From dhc@dcrocker.net Mon Mar 21 10:06:11 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5256C28C184 for ; Mon, 21 Mar 2011 10:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxSHCh6fDejr for ; Mon, 21 Mar 2011 10:06:10 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 2EC7B28C176 for ; Mon, 21 Mar 2011 10:06:10 -0700 (PDT) Received: from [192.168.1.4] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p2LH7YPZ024574 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2011 10:07:40 -0700 Message-ID: <4D8785D2.5070306@dcrocker.net> Date: Mon, 21 Mar 2011 10:07:30 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Hannes Tschofenig References: <4D87612E.3090900@dcrocker.net> <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> In-Reply-To: <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 21 Mar 2011 10:07:40 -0700 (PDT) Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:06:11 -0000 On 3/21/2011 9:58 AM, Hannes Tschofenig wrote: >> One is that it mandates full-time connectivity. > > No; it does not mandate full-time connectivity. It only mandates connectivity > between the client and the server. ??? That's the connectivity I am referring to. > For example, look at your Web-based email I don't use web-based mail. I realize that that mode is extremely popular and that it is a useful mode, but I find it problematic, for a number of the reasons we've been discussing on this thread. One of the issues this highlights is the need to be very careful not to tout the benefits of something as universal when, in fact, it has restricted utility. > account (like Gmail). The client-to-server interaction indeed requires > connectivity. However, it does not require full end-to-end community to work. I do not understand what distinction you are drawing. >> The other is that protocols that it says are no longer needed are in fact >> still needed in some form, albeit as a layer above HTTP, rather than TCP. > > We are not saying that the protocols are not needed at all anymore. However, > the need for standardization shifts. Actually, that really is what the announcement implies. >> On the other hand, it does tend to encourage an explosion of competing, >> incompatible application protocols, making for rather remarkable burdens >> on servers and clients. > > Not really. It allows people to innovate at full speed. There is no need to > go through a 5 year standardization effort for a protocol extension when you > can make it available to others easily (without even letting the user to > download and instal a new application). No one said that standardization-prior-to-use was a preferred model. I suspect you are confusing architectural issues with alternatives for developing and standardizing interoperable protocols. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From scott.brim@gmail.com Mon Mar 21 10:10:45 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58D928C177 for ; Mon, 21 Mar 2011 10:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.571 X-Spam-Level: X-Spam-Status: No, score=-103.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AR07K2mPlVYO for ; Mon, 21 Mar 2011 10:10:45 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id DCDBC3A68B3 for ; Mon, 21 Mar 2011 10:10:44 -0700 (PDT) Received: by iyi12 with SMTP id 12so7694427iyi.31 for ; Mon, 21 Mar 2011 10:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=9zv2ysAeid5fLHU4nTeeQey70yAHXz8Zw3+RtHwmgDg=; b=ZRzVqX4MWMxFz1fPPUP2Odg/qI0sgQzTaFKludh4WFA7Cks5u/3f4WA4mlKWm46+EE yqZcm9FX5SSlrrFyMUa0mHRqrkiSSMX1wYX+7KQ2kelv64l3JHn2iYHteyyJaWRZAN/h IJbb8Sno47XkfRXeNPPeE/S6ckcWx+6DNd8N4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=frc/9xPcnrto09nAuysJJUx9l2hTAkrZOZkIxJb3klRr3V2FiFuKPtnwseYv29KIN5 vbGewApwzNv176us6KjXhwc68Ive7ENOgUyQkOnX1O3HtixBCD/Fdu7Wo589HxLCbtPh ALLof50V2FvI/yMg5mY4hFX3YrLRc123RqfdQ= Received: by 10.42.161.198 with SMTP id u6mr7037489icx.482.1300727416137; Mon, 21 Mar 2011 10:10:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.164.74 with HTTP; Mon, 21 Mar 2011 10:09:02 -0700 (PDT) In-Reply-To: <4D878303.60908@dcrocker.net> References: <4D87612E.3090900@dcrocker.net> <4D876B4C.5070706@dcrocker.net> <4D877D30.9090502@stpeter.im> <4D877EDF.1090500@dcrocker.net> <4D878303.60908@dcrocker.net> From: Scott Brim Date: Mon, 21 Mar 2011 13:09:02 -0400 Message-ID: To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:10:45 -0000 On Mon, Mar 21, 2011 at 12:55, Dave CROCKER wrote: > On 3/21/2011 9:40 AM, Scott Brim wrote: >> >> On Mon, Mar 21, 2011 at 12:37, Dave CROCKER =A0wrote: >>> >>> I think Claudio raises another fundamental point, namely the loss of >>> interoperability. =A0The proposed model is a pure silo, with no apparen= t >>> ability to have variations or incremental capabilities that build on th= e >>> base, except by the single vendor providing the proprietary protocol. >> >> Could you give a specific example? > > > My email client accesses 6 different accounts. =A0The point of commonalit= y is > my client. =A0Typical silo solutions are for that silo only. See response to Cyrus. > As being touted, that would mean 6 different downloaded, proprietary acce= ss > clients, with my having to switch from one to another. =A0Besides being a > pain, this means that they cannot share data, such as getting a message i= n > on one account and forwarding it through another. I can give you an existence proof of that working today but I'm getting hesitant to name specific services. Let's get away from using email as an example. Even within the mail world, none of the web-based mail services are just mail, although they offer a just mail API (IMAP, POP). > Although some independent clients > have gotten pretty good at providing an integrative experience, it is not > possible to do group IMs except within a proprietary context requiring > everyone to have an account with the same provider. OK, a good example. The difference between this and mail is that there is no back end connectivity. With mail you can use any (including proprietary) interface to your service, and it will get it to other services. Since there are standards in the _back_ end, there don't have to be standard user interfaces in the _front_ end. I think this is finally a point worth bringing up. From scott.brim@gmail.com Mon Mar 21 10:14:42 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC1D3A68BD for ; Mon, 21 Mar 2011 10:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFTsOItVPPm9 for ; Mon, 21 Mar 2011 10:14:41 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 590803A68AD for ; Mon, 21 Mar 2011 10:14:41 -0700 (PDT) Received: by iyi12 with SMTP id 12so7698314iyi.31 for ; Mon, 21 Mar 2011 10:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=jv/8zQ3VMOOuETtcQDkm8xRyiHJ8WrfmcYoYZ48C1qg=; b=T9YwT0Wwv+R88NMuuOgIsNIRF1l2/e2cY+iOEGopZ+gEh5i9OfqOpD++4xJk8ErJku lfia2AqTpJI3kzJYiGqWo8UouBNgm5tHR3B5RTF4SSyE/mAGhXZs3CcapzF7LolkWJn0 YWmt1Bd104TdpALbAFpr45oM/8RYzYgPVPvh8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=LIg3NDMGt0IeTmqIY9Whp5HUEASaCEIej+/qU2mLi4tqTU/2BjSDbKkXqjGtvGBJrz c5xNjdjY1fhMwZByzHhtckahsD2aya8OQOT2Ceoitwmo4OTZaBngSiEgXfTu7RjVMF1F AAGE+bxDG6XXVciAJ5oBxNwyS40icuyb838Ek= Received: by 10.43.69.67 with SMTP id yb3mr7360172icb.147.1300727677555; Mon, 21 Mar 2011 10:14:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.164.74 with HTTP; Mon, 21 Mar 2011 10:12:40 -0700 (PDT) In-Reply-To: <4D8785D2.5070306@dcrocker.net> References: <4D87612E.3090900@dcrocker.net> <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> <4D8785D2.5070306@dcrocker.net> From: Scott Brim Date: Mon, 21 Mar 2011 13:12:40 -0400 Message-ID: To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:14:42 -0000 On Mon, Mar 21, 2011 at 13:07, Dave CROCKER wrote: > On 3/21/2011 9:58 AM, Hannes Tschofenig wrote: >>> >>> One is that it mandates full-time connectivity. >> >> No; it does not mandate full-time connectivity. It only mandates >> connectivity >> between the client and the server. > > ??? That's the connectivity I am referring to. This morning I was using one of these web-based mail services in offline mode. It caught up when I reconnected. >> =A0For example, look at your Web-based email > > I don't use web-based mail. =A0I realize that that mode is extremely popu= lar > and that it is a useful mode, but I find it problematic, for a number of = the > reasons we've been discussing on this thread. You should try out some browser-based, cloud-based tools so you have more experience in this area. :-) From hannes.tschofenig@gmx.net Mon Mar 21 10:31:47 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8856228C0F6 for ; Mon, 21 Mar 2011 10:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmnVz8j1H4Id for ; Mon, 21 Mar 2011 10:31:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 11D0C28C0F2 for ; Mon, 21 Mar 2011 10:31:44 -0700 (PDT) Received: (qmail invoked by alias); 21 Mar 2011 17:33:16 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp018) with SMTP; 21 Mar 2011 18:33:16 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/7OL93a5r7TB3WkZuNEYg3jP9Bhq7CwWkYRJCB3u jqp8PDqqUGCXCZ Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4D8785D2.5070306@dcrocker.net> Date: Mon, 21 Mar 2011 19:33:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D87612E.3090900@dcrocker.net> <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> <4D8785D2.5070306@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:31:47 -0000 Hi Dave,=20 On Mar 21, 2011, at 7:07 PM, Dave CROCKER wrote: >=20 >=20 > On 3/21/2011 9:58 AM, Hannes Tschofenig wrote: >>> One is that it mandates full-time connectivity. >>=20 >> No; it does not mandate full-time connectivity. It only mandates = connectivity >> between the client and the server. >=20 > ??? That's the connectivity I am referring to. >=20 There are lots of other things you could refer to.=20 Btw, you also need client-to-server connectivity to fetch your mails... >=20 >> For example, look at your Web-based email >=20 > I don't use web-based mail. I realize that that mode is extremely = popular and that it is a useful mode, but I find it problematic, for a = number of the reasons we've been discussing on this thread. >=20 > One of the issues this highlights is the need to be very careful not = to tout the benefits of something as universal when, in fact, it has = restricted utility. >=20 For service providers it matters what most users like. It seems that = more and more people are experiencing the Internet via Web browser.=20 >=20 >> account (like Gmail). The client-to-server interaction indeed = requires >> connectivity. However, it does not require full end-to-end community = to work. >=20 > I do not understand what distinction you are drawing. >=20 >=20 There are different communication paradigms. The discussion that is = currently ongoing in the RAI area is focused on real-time communication = between two endpoints (browsers).=20 So, the level of required connectivity is different.=20 There both parties always need to be online. If they aren't nothing = works. This is not a constraint given the application space folks are = looking at.=20 >>> The other is that protocols that it says are no longer needed are in = fact >>> still needed in some form, albeit as a layer above HTTP, rather than = TCP. >>=20 >> We are not saying that the protocols are not needed at all anymore. = However, >> the need for standardization shifts. >=20 > Actually, that really is what the announcement implies. >=20 >=20 The importance of the entire plenary is about innovation and how the = choice of architecture impacts the speed of innovation.=20 >>> On the other hand, it does tend to encourage an explosion of = competing, >>> incompatible application protocols, making for rather remarkable = burdens >>> on servers and clients. >>=20 >> Not really. It allows people to innovate at full speed. There is no = need to >> go through a 5 year standardization effort for a protocol extension = when you >> can make it available to others easily (without even letting the user = to >> download and instal a new application). >=20 > No one said that standardization-prior-to-use was a preferred model. = I suspect you are confusing architectural issues with alternatives for = developing and standardizing interoperable protocols. We describe a model that is deployed today (the Web model with HTTP/HTML = + JavaScript) that allows shifting the interoperability need away from = the client.=20 The talk will further argue that following this model will let you = innovate faster and everything that does not follow this model will have = a hard time to compete. If you look around in the IETF applications and = RAI area then you will notice that we are seen this hard time today.=20 Regarding "No one said that standardization-prior-to-use was a preferred = model.": This is what the W3C did with some of their work on HTML5. The = experience of Google on Gmail with offline storage was folded into the = HTML5 related work.=20 Ciao Hannes >=20 > d/ > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From Claudio.Allocchio@garr.it Mon Mar 21 10:45:16 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4019428C0F9 for ; Mon, 21 Mar 2011 10:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OB01xhFQpQCy for ; Mon, 21 Mar 2011 10:45:15 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 9126528C0F7 for ; Mon, 21 Mar 2011 10:45:14 -0700 (PDT) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p2LHkYEc023736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2011 18:46:35 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p2LHkYEc023736 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=Ozst16MDn8DVprm3MTYVQyI155VZtS5jo7w1grPI0vvG1/nGBSbdlBWJI570p6ci5 N1QLWuahhj8qwSRbZAzeRs6uRl/hbEZz7F2czDvUmie2c+khnkE5FEkc9WV2dH8Xp/6 j9iS0AUGeA8EhDJqLrXvxCHOkr4jm6+GQ5H8W5A= Date: Mon, 21 Mar 2011 18:46:34 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: Hannes Tschofenig In-Reply-To: Message-ID: References: <4D87612E.3090900@dcrocker.net> <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> <4D8785D2.5070306@dcrocker.net> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dcrocker@bbiw.net, Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:45:16 -0000 > For service providers it matters what most users like. It seems that > more and more people are experiencing the Internet via Web browser. because they do not know what the Internet is suppoused to be: "communicating with the others", e.g. receive information, but also GENERATE information. At least in the "research and education" sections of the Internet we still stick to the paradigm that users generate information and content, and they invent their own services, while we (the "carrier") do not tell them what they can "download", or again we (the "carrier") just give users simmetrical connectivity. And when we ask for innovation proposals, the most innovative ones we get are not "via Web Browsers". An example: a real-time audio-video protocol which enable musicians to perform a live concert even when they're a thousand miles apart from each other. but this will lead quite far away from what we started to discuss... :-) ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From scott.brim@gmail.com Mon Mar 21 10:50:14 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB6028C0D9 for ; Mon, 21 Mar 2011 10:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.575 X-Spam-Level: X-Spam-Status: No, score=-103.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Blme9TIj26M for ; Mon, 21 Mar 2011 10:50:14 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 433753A687B for ; Mon, 21 Mar 2011 10:50:13 -0700 (PDT) Received: by iyi12 with SMTP id 12so7731892iyi.31 for ; Mon, 21 Mar 2011 10:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=93bW6gXsXT8FtnZVWm3/qv9ApIYz2F9PuwVwj/fcGxA=; b=YzRG85eYpTgiA9sMJ1vlYRpHMDy86z/yqs1VWo7zddUAS4R1e1WgEMOMvTXTg4KTBn wMiXa7/F+MD6AAyo1x6rNrGSkufvKDJP0kVeYWe0nJciKl9fLMYbaO4h54I2ej/RS98e bQEtr6NoZSyOUIQmS3UPjaA9nmkl41WG58Jck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=b3rIUWGVZBdvtksx33ZflMIriqZLCjg+CVqWkYn2PM454I+jnRtCkc/AfIPUlk0kHo Z2wkLcCf/e9t9QGXo4X2HLM+qCHdL0FradkrOd6VPmjILbZOeuohmFtGnP4oVqwYUinO vKQE64HGkm64qKIes3oQ//rn8ZwgHKjxTiJp8= Received: by 10.42.134.132 with SMTP id l4mr7527875ict.13.1300729892144; Mon, 21 Mar 2011 10:51:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.164.74 with HTTP; Mon, 21 Mar 2011 10:51:01 -0700 (PDT) In-Reply-To: References: <4D87612E.3090900@dcrocker.net> <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> <4D8785D2.5070306@dcrocker.net> From: Scott Brim Date: Mon, 21 Mar 2011 13:51:01 -0400 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: dcrocker@bbiw.net, Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:50:15 -0000 On Mon, Mar 21, 2011 at 13:33, Hannes Tschofenig wrote: > We describe a model that is deployed today (the Web model with HTTP/HTML + JavaScript) that allows shifting the interoperability need away from the client. I suspect this is the gist. It used to be that we required standard protocols at the endpoint. As Dave's mention of IM clients shows, that's necessary if there is no coordination among services. But if there is coordination among services, such that using any one service allows you to reach anyone on any service, then you don't need standardized UIs. From scott.brim@gmail.com Mon Mar 21 10:52:19 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41EB628C0F2 for ; Mon, 21 Mar 2011 10:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.575 X-Spam-Level: X-Spam-Status: No, score=-103.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ow26cguiwsWD for ; Mon, 21 Mar 2011 10:52:18 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 80BD228C0D8 for ; Mon, 21 Mar 2011 10:52:18 -0700 (PDT) Received: by iwl42 with SMTP id 42so7802549iwl.31 for ; Mon, 21 Mar 2011 10:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WCnWToJrBDXO50CxVR4I/gFTLzGCWDHJi9AOSxCWGBw=; b=C/qwsGvuXm2RKSU5BcRGriSt1p1EZAY3h+bnjOSNZJWkNBxDQE4BfaL4wKY0VPiRaZ bsmFkUgtKv47EpbkMESkIP0lbt+AVuWyjdu6xO2k2XGfcwVlyAbP+cCAoep7HNmMtXk9 ePUPGXaM+/W29iIYYUeh8mCHGfYVM4wrAYiWE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=rh+6ROqX3Y6Q2rm0fMRZsfc8BPJlDI6BjJ7RTDc17wa/YheOGItrvevigS2icAPsNn WzZTDBBWxqjLMbEeIykDs0sYB4dSxNG59yDJprSn9NGb4AxzaUsNotaZyyIvflScMCh7 tOeDeqm9cFwDW0MNej0YoJte4327zZWVXcEeU= Received: by 10.42.133.72 with SMTP id g8mr7517757ict.80.1300730031115; Mon, 21 Mar 2011 10:53:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.164.74 with HTTP; Mon, 21 Mar 2011 10:53:31 -0700 (PDT) In-Reply-To: References: <4D87612E.3090900@dcrocker.net> <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> <4D8785D2.5070306@dcrocker.net> From: Scott Brim Date: Mon, 21 Mar 2011 13:53:31 -0400 Message-ID: To: Claudio Allocchio Content-Type: text/plain; charset=ISO-8859-1 Cc: dcrocker@bbiw.net, Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:52:19 -0000 On Mon, Mar 21, 2011 at 13:46, Claudio Allocchio wrote: > because they do not know what the Internet is suppoused to be: > "communicating with the others", e.g. receive information, but also GENERATE > information. yes we must absolutely insist that the Internet be fundamentally peer to peer. But on top of that, 98% of exchanges between what look like peers at the IP layer is client-server at higher layers. From hannes.tschofenig@gmx.net Mon Mar 21 10:59:46 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 260E83A68CC for ; Mon, 21 Mar 2011 10:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWdL9eVTpcWu for ; Mon, 21 Mar 2011 10:59:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id ACA773A68C7 for ; Mon, 21 Mar 2011 10:59:44 -0700 (PDT) Received: (qmail invoked by alias); 21 Mar 2011 18:01:15 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp063) with SMTP; 21 Mar 2011 19:01:15 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+kBYExhkGkBfttPme661P9oyU6avh0cmcjPX6bU0 SRmyPddF8eIdKA Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Mon, 21 Mar 2011 20:01:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D87612E.3090900@dcrocker.net> <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> <4D8785D2.5070306@dcrocker.net> To: Claudio Allocchio X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: dcrocker@bbiw.net, Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:59:46 -0000 Hi Claudio,=20 I am not sure I understand your argument.=20 I am using the term "service provider" in a quite relaxed way.=20 For example, I (Hannes) want to reach out to others to share my remarks = about IETF what would I do?=20 I would (and I did) I installed a Wordpress blog. If I want to add chat = capabilities, I add Strophe (a JavaScript based XMPP implementation).=20 If I want to outsource my identity management (to make it simpler for = others to comment on my blog) then I add OAuth and OpenID.=20 I can (as a service provider) add a lot of functionality without = demanding you to download a new application (every time I make add more = functionality to my site). You could even play nice little games via my site; everything runs in = JavaScript.=20 I hope I made it clear what I mean by "service provider".=20 Ciao Hannes On Mar 21, 2011, at 7:46 PM, Claudio Allocchio wrote: >=20 >> For service providers it matters what most users like. It seems that = more and more people are experiencing the Internet via Web browser. >=20 > because they do not know what the Internet is suppoused to be: = "communicating with the others", e.g. receive information, but also = GENERATE information. >=20 > At least in the "research and education" sections of the Internet we = still stick to the paradigm that users generate information and content, = and they invent their own services, while we (the "carrier") do not tell = them what they can "download", or again we (the "carrier") just give = users simmetrical connectivity. And when we ask for innovation = proposals, the most innovative ones we get are not "via Web Browsers". = An example: a real-time audio-video protocol which enable musicians to = perform a live concert even when they're a thousand miles apart from = each other. >=20 > but this will lead quite far away from what we started to discuss... >=20 > :-) >=20 > = --------------------------------------------------------------------------= ---- > Claudio Allocchio G A R R = Claudio.Allocchio@garr.it > Senior Technical Officer > tel: +39 040 3758523 Italian Academic and G=3DClaudio; = S=3DAllocchio; > fax: +39 040 3758565 Research Network P=3Dgarr; A=3Dgarr;= C=3Dit; >=20 > PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From dave@cridland.net Mon Mar 21 11:03:34 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38B928C0D9 for ; Mon, 21 Mar 2011 11:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZVb6xXmiff7 for ; Mon, 21 Mar 2011 11:03:33 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 63BEE3A68C4 for ; Mon, 21 Mar 2011 11:03:33 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id B6AD01168090; Mon, 21 Mar 2011 18:05:04 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 756POM0KEcKx; Mon, 21 Mar 2011 18:05:02 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id C4B3B1168067; Mon, 21 Mar 2011 18:05:01 +0000 (GMT) References: <4D87612E.3090900@dcrocker.net> <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> <4D8785D2.5070306@dcrocker.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <6266.1300730701.805233@puncture> Date: Mon, 21 Mar 2011 18:05:01 +0000 From: Dave Cridland To: Scott Brim , Dave CROCKER , General discussion of application-layer protocols , Hannes Tschofenig Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 18:03:34 -0000 On Mon Mar 21 17:51:01 2011, Scott Brim wrote: > On Mon, Mar 21, 2011 at 13:33, Hannes Tschofenig > wrote: > > We describe a model that is deployed today (the Web model with > HTTP/HTML + JavaScript) that allows shifting the interoperability > need away from the client. > > I suspect this is the gist. It used to be that we required standard > protocols at the endpoint. As Dave's mention of IM clients shows, > that's necessary if there is no coordination among services. But if > there is coordination among services, such that using any one > service > allows you to reach anyone on any service, then you don't need > standardized UIs. With XMPP, an XMPP server will talk with other XMPP servers - this means that HTTP cannot be used. (And if anyone suggests S2S/BOSH I will throw up). But XMPP clients also talk with other clients, in sometimes client-specific ways over variable services. Thus to no small degree the XMPP experience is governed by the client, rather than the server, and the overall experience is most certainly a product of both. This is also similar with mail - you may think of email as just a blob of functionality, but I can assure you that there are both good and bad email clients, and good and bad email services. By restricting client/server to be just browser-based, you eliminate the ability of users to select a user interface of their choice orthogonal to the service, and you also create a down-pressure on functionality via standardized protocols - hence Google Mail's IMAP support is very much a lowest common denominator - it is sufficient, instead of offering the richer support it might. This is not to say that a web-based interface is not a good thing, and a useful thing, too - there are plenty such interfaces for both email and XMPP. In fact, in XMPP there are many more because we devised standards for how browser-based clients could connect to servers (see BOSH, for example). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From hannes.tschofenig@gmx.net Mon Mar 21 11:06:16 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B9D928C194 for ; Mon, 21 Mar 2011 11:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKevLXYTG54A for ; Mon, 21 Mar 2011 11:06:15 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 9ED7528C187 for ; Mon, 21 Mar 2011 11:06:14 -0700 (PDT) Received: (qmail invoked by alias); 21 Mar 2011 18:07:46 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp064) with SMTP; 21 Mar 2011 19:07:46 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+vbZoP+XmvRWk5HOLPDpGtnG4Ar3T3ANvj0YYKZ3 3fhVtFC+oDkDCZ Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Mon, 21 Mar 2011 20:07:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3EA044DE-3A5F-4C9F-9F43-3FB2E7F4C434@gmx.net> References: <4D87612E.3090900@dcrocker.net> <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> <4D8785D2.5070306@dcrocker.net> To: Scott Brim X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: Claudio Allocchio , Apps Discuss , dcrocker@bbiw.net Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 18:06:16 -0000 On Mar 21, 2011, at 7:53 PM, Scott Brim wrote: > On Mon, Mar 21, 2011 at 13:46, Claudio Allocchio > wrote: >> because they do not know what the Internet is suppoused to be: >> "communicating with the others", e.g. receive information, but also = GENERATE >> information. >=20 > yes we must absolutely insist that the Internet be fundamentally peer > to peer. Whatever the peers in this exchange are.=20 If peer means Web browser then you will probably like the RTCWeb BOF. > But on top of that, 98% of exchanges between what look like > peers at the IP layer is client-server at higher layers. Purely a matter of definition.=20 Ciao Hannes From dave@cridland.net Mon Mar 21 11:10:50 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2C2C28C185 for ; Mon, 21 Mar 2011 11:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrG7EEbQpU22 for ; Mon, 21 Mar 2011 11:10:48 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id A5C0928C193 for ; Mon, 21 Mar 2011 11:10:47 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 6A672116808D; Mon, 21 Mar 2011 18:12:19 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0zOFwszw6eg; Mon, 21 Mar 2011 18:12:18 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 1FA4A1168067; Mon, 21 Mar 2011 18:12:18 +0000 (GMT) References: <4D87612E.3090900@dcrocker.net> <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> <4D8785D2.5070306@dcrocker.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <6266.1300731138.128009@puncture> Date: Mon, 21 Mar 2011 18:12:18 +0000 From: Dave Cridland To: Hannes Tschofenig , Dave CROCKER , General discussion of application-layer protocols , Claudio Allocchio Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 18:10:50 -0000 On Mon Mar 21 18:01:13 2011, Hannes Tschofenig wrote: > I would (and I did) I installed a Wordpress blog. If I want to add > chat capabilities, I add Strophe (a JavaScript based XMPP > implementation). Thanks for proving my point as I wrote it - Strophe.js is in itself only possible because we (that is, the XMPP community) went to some effort to standardize a method for browser-hosted XMPP clients to interoperably connect to XMPP servers. It's almost a perfect counter-example to your argument. If you want chat *without* having an XMPP server in your browser, you're forced into reinventing IM for your purposes - which is indeed possible. You need not do this yourself, of course, just as you needn't write your own XMPP server, but unlike the latter case, you're very tightly coupled to the solution. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From hannes.tschofenig@gmx.net Mon Mar 21 11:14:54 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C79E28C0F8 for ; Mon, 21 Mar 2011 11:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.156 X-Spam-Level: X-Spam-Status: No, score=-102.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xhkw-wDnN59r for ; Mon, 21 Mar 2011 11:14:53 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 9083C3A68CC for ; Mon, 21 Mar 2011 11:14:52 -0700 (PDT) Received: (qmail invoked by alias); 21 Mar 2011 18:16:20 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp041) with SMTP; 21 Mar 2011 19:16:20 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18kVjQSY10kQi3pRM9oHm5Xtm8ibeFVentdvzXJT9 xBkYzCU6C1C1oQ Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-11-301632893 From: Hannes Tschofenig In-Reply-To: <6266.1300730701.805233@puncture> Date: Mon, 21 Mar 2011 20:16:19 +0200 Message-Id: <58FF0930-4C05-4791-A40C-B64BDA2E3165@gmx.net> References: <4D87612E.3090900@dcrocker.net> <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> <4D8785D2.5070306@dcrocker.net> <6266.1300730701.805233@puncture> To: Dave Cridland X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: Scott Brim , Dave CROCKER , General discussion of application-layer protocols Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 18:14:54 -0000 --Apple-Mail-11-301632893 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 21, 2011, at 8:05 PM, Dave Cridland wrote: > With XMPP, an XMPP server will talk with other XMPP servers - this = means that HTTP cannot be used. (And if anyone suggests S2S/BOSH I will = throw up). I was focusing more on the client-to-server interaction; I don't think = the need for interoperability on the server-to-server side vanishes.=20 The model I have in my mind is this one: (modified from = http://tools.ietf.org/html/draft-rosenberg-rtcweb-framework-00) +-----------+ +-----------+ | Web | Server-to- | Web | | | Server | | | |-------------| | | Server | | Server | | | | | +-----------+ +-----------+ / \ / \ Proprietary over / \ HTTP/Websockets / \ / Proprietary over \ / HTTP/Websockets \ / \ +-----------+ +-----------+ |JS/HTML/CSS| |JS/HTML/CSS| +-----------+ +-----------+ +-----------+ +-----------+ | | | | | | | | | Browser | ------------------------- | Browser | | | Media (if needed) | | | | | | +-----------+ +-----------+ The browser to server side does not need to be standardized. Everyone = is, however, free to use what standardized protocol they want.=20 There is no shortage of standardized protocols for that interface.=20 If you want cross-service provider communication then the = interoperability need is on the server-to-server side.=20 Given that you are heavily involved in the XMPP space you are very much = familiar with this model.=20 Ciao Hannes --Apple-Mail-11-301632893 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
With XMPP, an = XMPP server will talk with other XMPP servers - this means that HTTP = cannot be used. (And if anyone suggests S2S/BOSH I will throw = up).

I was focusing more on the = client-to-server interaction; I don't think the need for = interoperability on the server-to-server side = vanishes. 

The model I have in my mind is = this one:


             =    +-----------+             = +-----------+
             =    |   Web     | Server-to-  |   Web =     |
             =    |           | Server     =  |           |
     =            |         =   |-------------|           = |
                | =  Server   |             | =  Server   |
             =    |           |       =       |           = |
               =  +-----------+             = +-----------+
             =         /             =               = \
                 =    /                 =             \   Proprietary = over
                 =   /                   =             \ =  HTTP/Websockets
             =      /               =                   = \
                 / =  Proprietary over               =   \
             =    /   HTTP/Websockets           =         \
     =           /           =                     =         \
     =     +-----------+             =               = +-----------+
         |JS/HTML/CSS| =                     =       |JS/HTML/CSS|
     =     +-----------+             =               = +-----------+
         +-----------+ =                     =       +-----------+
     =     |           |     =                     =   |           |
     =     |           |     =                     =   |           |
     =     |  Browser  | ------------------------- | =  Browser  |
         |     =       |   Media (if needed)       | =           |
     =     |           |     =                     =   |           |
     =     +-----------+             =               = +-----------+

The browser to = server side does not need to be standardized. Everyone is, however, free = to use what standardized protocol they want. 
There is no = shortage of standardized protocols for that = interface. 

If you want cross-service = provider communication then the interoperability need is on the = server-to-server side. 

Given that you are = heavily involved in the XMPP space you are very much familiar with this = model. 

Ciao
Hannes

=
= --Apple-Mail-11-301632893-- From ted.ietf@gmail.com Mon Mar 21 11:25:29 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0776428C1AA for ; Mon, 21 Mar 2011 11:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOdkHAjwOG79 for ; Mon, 21 Mar 2011 11:25:28 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id F3D2128C1A8 for ; Mon, 21 Mar 2011 11:25:27 -0700 (PDT) Received: by iyi12 with SMTP id 12so7764574iyi.31 for ; Mon, 21 Mar 2011 11:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4F4t4d2wGD51EktnL/sE0WfNeE0Y8ZCQmiqZFSBxaz8=; b=B7i8Oynzmf3bxY5tn/j8ZpJk7GPbuo7pc8UkJVT5cSqmNYTSpwAElqMSt59lsoniir z6yCjYHaNTqyfctk8dbsulLoJ7UjlUgqoxhB7zOcFQ4eMHoBzz1PH33azQi49tEVu4iS MzOGqltA6W8mm0J3tXlu0htiQEdl0MlHjKbck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DNKsuz0tvpotpn/GYd3NXIglB2CUhBYZITbVq29TaAITQL6lD6lNyhiCl7fttIZkgx HUWY8VjXNlI5sA2T4qT3nmHxlySFSiXm9TzdYued0QAzBM/l43AiEgNmiIx4uBgrAg/i xi4mQJuu3InQnvlV8IsfVG9jQrCJvZzvUAelk= MIME-Version: 1.0 Received: by 10.42.155.197 with SMTP id v5mr7382247icw.142.1300732020667; Mon, 21 Mar 2011 11:27:00 -0700 (PDT) Received: by 10.231.39.76 with HTTP; Mon, 21 Mar 2011 11:27:00 -0700 (PDT) In-Reply-To: <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> References: <4D87612E.3090900@dcrocker.net> <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> Date: Mon, 21 Mar 2011 11:27:00 -0700 Message-ID: From: Ted Hardie To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dcrocker@bbiw.net, Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 18:25:29 -0000 On Mon, Mar 21, 2011 at 9:58 AM, Hannes Tschofenig > Not really. It allows people to innovate at full speed. There is no need = to go through a 5 year standardization effort for a protocol extension when= you can make it available to others easily (without even letting the user = to download and instal a new application). > So, there is an old saying: "Success has many fathers, but failure is an orphan". While I strongly agree that establishing where interoperability is needed should make for an interesting plenary discussion and is something every WG should consider, I think we have to be pretty careful in reading any paternity tests for the pace of innovation. There are several mutually reinforcing network effects here. The web provided the opportunity for many people to become publishers as well as consumers of network resources. That created a pool of developers and the opportunity for those who wanted to build tools for that pool of developers. That created a further explosion in interest in creating content and new innovations in the kind of content that could be created entirely within the web context (at one of my early employers, we created interactive content using web forms and Sun RPC, and the transition in technologies took a few years). While all of this content was moving onto the web, firewall and NAT technologies were getting widely deployed. One of the biggest risks was unvetted web-based content, but it could not be sequestered without enormous outcry, so those ports were left open. This pushed other kinds of traffic onto those ports, even when there was no user produced or consumable information involved. That increased the set of developers who understood network programming, but only from a web-centric view point. That, in turn, created a new body of content and protocols built on those tools. Network effects are very powerful, as we all know. The availability of one set of tools in the web environment (downloadable javascript) has clearly had an important part in that. But let's not confuse its role with the overall effect. It's particularly important that we not ascribe to those tools the overall pace of innovation. Developer community size, security models, and network topology restrictions have been as or more important. Any of the Daves in this conversation could create an innovative protocol to solve a problem without touching the web. It might take a good bit longer to deploy than one that did, but it's a set of other constraints (treatment of downloaded standalone applications vs. downloaded web applications, NATs, Firewalls, developer interest) that would slow its pace. That's important in part because new network effects are always possible. If we ascribe their results to one particular set of tools we may miss the generative possibilities of other tools. regards, Ted Hardie From dave@cridland.net Mon Mar 21 11:33:32 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA7003A659C for ; Mon, 21 Mar 2011 11:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqUssYLambrh for ; Mon, 21 Mar 2011 11:33:31 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 417353A67B0 for ; Mon, 21 Mar 2011 11:33:31 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id D1B58116808D; Mon, 21 Mar 2011 18:35:00 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJuYY02NFtD1; Mon, 21 Mar 2011 18:34:58 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id D4FE91168087; Mon, 21 Mar 2011 18:34:57 +0000 (GMT) References: <4D87612E.3090900@dcrocker.net> <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> <4D8785D2.5070306@dcrocker.net> <6266.1300730701.805233@puncture> <58FF0930-4C05-4791-A40C-B64BDA2E3165@gmx.net> In-Reply-To: <58FF0930-4C05-4791-A40C-B64BDA2E3165@gmx.net> MIME-Version: 1.0 Message-Id: <6266.1300732497.869753@puncture> Date: Mon, 21 Mar 2011 18:34:57 +0000 From: Dave Cridland To: Hannes Tschofenig , Scott Brim , Dave CROCKER , General discussion of application-layer protocols Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 18:33:32 -0000 On Mon Mar 21 18:16:19 2011, Hannes Tschofenig wrote: > Given that you are heavily involved in the XMPP space you are very > much familiar with this model. Nope, your model is entirely alien to me; your assumptions therefore fail. In the XMPP world, clients talk to each other and are mediated and aided by servers. This model is far closer to the model of hosts and routers, and there's much similarity - XMPP has a tendency toward pushing functionality out to the clients and avoiding involving the servers unless it's unavoidable. Yet XMPP *also* has very fast innovation, which I attribute to its close-knit culture and approachable specifications. And beer. So I think I agree with Ted Hardie, on another level - I think analysing why innovation can be quick and slow is interesting, but presenting a "final solution" for client/server interop seems a little hasty. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From presnick@qualcomm.com Mon Mar 21 20:46:55 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6563A6403 for ; Mon, 21 Mar 2011 20:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.596 X-Spam-Level: X-Spam-Status: No, score=-106.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NuSLWcN1FjO for ; Mon, 21 Mar 2011 20:46:54 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 37F193A63EC for ; Mon, 21 Mar 2011 20:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1300765707; x=1332301707; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4D881C04.2080406@qualcomm.com>|Date:=20Mo n,=2021=20Mar=202011=2022:48:20=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20|CC:=20Dave =20CROCKER=20,=20Apps=20Discuss=20|Subject:=20Re:=20[apps-discuss]=20IETF =20technical=20plenary:=20the=20end=20of=20application=0D =0A=20protocols|References:=20<4D87612E.3090900@dcrocker. net>|In-Reply-To:=20<4D87612E.3090900@dcrocker.net> |Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.39.5]; bh=+c5F0sEphQ7ZNFUPJNuC3wnqGTxY3AsKW67E6DzQOVA=; b=uJ1B7wEzeUEEJ7GtC1TL+DLcgswKbapwXp2Avx2ljdC88z8JzZokbM4B JHE0gwTdUrFD/viptNSZglhm9b+V1WiLckIKWOjSJ7ZkI3yZoySgTzjO1 AXEa5ABuUVioqbelxj/5cNFN0iAmF1H/LQT4Bfw4X2glS5VEHvwULwfpD Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6292"; a="81088323" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 21 Mar 2011 20:48:26 -0700 X-IronPort-AV: E=Sophos;i="4.63,222,1299484800"; d="scan'208";a="126115903" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 21 Mar 2011 20:48:26 -0700 Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 21 Mar 2011 20:48:26 -0700 Message-ID: <4D881C04.2080406@qualcomm.com> Date: Mon, 21 Mar 2011 22:48:20 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <4D87612E.3090900@dcrocker.net> In-Reply-To: <4D87612E.3090900@dcrocker.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 03:46:55 -0000 On 3/21/11 9:31 AM, Dave CROCKER wrote: > Folks, > > I just saw the announcement for the Technical Plenary presentation. I sent this to the IAB a few weeks ago. We haven't had much conversation (they responded, but the firehose of stuff before the IETF meeting kept me from replying until recently), but I thought you all would be amused. -------- Original Message -------- Message-ID: <4D76B361.2050704@qualcomm.com> Date: Tue, 8 Mar 2011 16:53:21 -0600 From: Pete Resnick To: Subject: IAB Technical Session CC: "'The IESG'" [Feel free to forward this as you see fit.] Dear IAB, You will probably find it unsurprising that I find the abstract of the technical session at the IAB plenary to be completely unadulterated rubbish. It is by no means the "advancement in the design of web browsers" nor the "widespread availability and growing sophistication of JavaScript interpreters in browsers" that has changed the architecture of applications. Quite the contrary, it is the forcing of a particular application paradigm, that of requiring all applications to be client-server based with all intelligence based in the server, that has in turn forced Javascript sophistication to increase to accommodate complex application logic inside the browser. (Indeed, it is this force that has led to HyBi, the abomination whereby browser-based applications, instead of being able to simply open a TCP connection, are forced to go through an HTTP tunnel to the web server in order to get any kind of network connectivity.) Protocols like POP and IMAP are not being subsumed into these systems. Rather, the semantics of these protocols are being dumbed down, eliminating functionality, in order to allow them to fit into the new constrained environment. There are two obvious drivers of this evolution: First and foremost is the continuing lack of end-to-end connectivity in the network. This is due to the presence of NATs and assorted firewall nonsense that makes non-tunneled applications harder and harder to deploy. But the second driving force is the more insidious one: economics. The economics of the Internet are currently being driven by big players consolidating the network, pushing as much as they can into servers so that they can control both the data and the user experience for applications on the Internet. This of course is not in the interest of end users, except insofar as the "big players" are end users with large economic interests. The more centralized the data becomes, the more dependent users are on the "big players", the less innovation in applications can take place, and the less stable the Internet is as a whole. This is not a state of affairs in which we need to "identify areas where the standardization is unlikely to be relevant in the future, and focus our efforts on those areas where our application designs will remain impactful." Rather, we need to do what we can with tools we are currently developing (the deployment of IPv6, the use of MPTCP and other protocols which allow us to route around the damage to the end-to-end model) to combat this model and have the Internet remain a distributed end-to-end network. Back to La Mancha. I've been noticing these windmills.... pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From dhc@dcrocker.net Mon Mar 21 21:35:58 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26DB28C0F5 for ; Mon, 21 Mar 2011 21:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5syS7U3IY8vO for ; Mon, 21 Mar 2011 21:35:56 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id AE7113A6930 for ; Mon, 21 Mar 2011 21:35:56 -0700 (PDT) Received: from [192.168.1.4] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p2M4bObC006939 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2011 21:37:29 -0700 Message-ID: <4D882781.8020605@dcrocker.net> Date: Mon, 21 Mar 2011 21:37:21 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Pete Resnick References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> In-Reply-To: <4D881C04.2080406@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 21 Mar 2011 21:37:29 -0700 (PDT) Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 04:35:58 -0000 On 3/21/2011 8:48 PM, Pete Resnick wrote: > I sent this to the IAB a few weeks ago. We haven't had much conversation (they > responded, but the firehose of stuff before the IETF meeting kept me from > replying until recently), but I thought you all would be amused. The degree of disconnect about architecture and protocol issues makes this a bit challenging to view with humor. (It's tempting to counter that that's not really true since it is so easy to make fun of the situation, but that's not what you meant and it's not what I'd find productive...) The larger issue I see is that the views being put forward for the talk well might be reasonable, with sufficient qualifiers and very careful language, but no qualifiers are being offered. Instead the language asserts universals, and these most certainly are not correct. There could be a rather interesting discussion about these issues, given a reasonable mix of people and a reasonable format for exploration and debate. The current format is cast more for selling a specific view than for understanding pros and cons and tradeoffs. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@resistor.net Mon Mar 21 23:45:16 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2273A67C2 for ; Mon, 21 Mar 2011 23:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52bgnkjO+Wzt for ; Mon, 21 Mar 2011 23:45:09 -0700 (PDT) Received: from mx.elandsys.com (eland-1-pt.tunnel.tserv15.lax1.ipv6.he.net [IPv6:2001:470:c:d43::2]) by core3.amsl.com (Postfix) with ESMTP id 67A7C3A6849 for ; Mon, 21 Mar 2011 23:45:08 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p2M6kYJj001322 for ; Mon, 21 Mar 2011 23:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1300776399; bh=Rb730HTTQaziKKkm2VVB00Wd04WOQFGvu+2uNLDR8Qs=; h=Message-Id:X-Mailer:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type; b=psfdQ3eZUWj/L5vel6z675XUWH06i85WB12zk6O4X/w+dSyb/0JchHHSQL3bAL+Ni BCO3Vvxx4WG8YLNLlkEhUch/GWsnmCio1pu24LRJ5GNN2v4qpidKPmuXaQa237yfIZ wviNdJRQALQICcF9ab/OFi7SaDJKViMrdS8ZDDy0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1300776399; bh=Rb730HTTQaziKKkm2VVB00Wd04WOQFGvu+2uNLDR8Qs=; h=Message-Id:X-Mailer:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type; b=JFftLos/CobWVS40wS1FgNhrt5StXcdY+mqQHAHS7wQ3m6tww4aEDhGBhU0sPUScL EJvVn5xXQg1ulTlT831aVvKQ2EiYi2Ovwdcv6cfVk6Ve6gmVefV6kLWX94suTLR2rj +ADcsiw3tZJAVpSLNW8ODLH6KOxq8mkj6uH221vg= Message-Id: <6.2.5.6.2.20110321223051.0e352650@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 21 Mar 2011 23:35:44 -0700 To: Apps Discuss From: SM In-Reply-To: <4D881C04.2080406@qualcomm.com> References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 06:45:16 -0000 At 20:48 21-03-2011, Pete Resnick wrote: >Back to La Mancha. I've been noticing these windmills.... Adapted from draft-iab-ip-model-evolution: 'Since the Internet Protocol was first published as [IEN028] in 1978, IP has provided a network-layer connectivity service to upper-layer protocols and applications. The basic IP service model was documented in the original IEN's (and subsequently in the RFC's that obsolete them). However, since the mantra [is] "Everything Over [HTTP]' It is easier not to "worry about about interoperability of clients and servers when the server", thanks to the magic of fog computing, "can simply push to the client all the code it needs to be interoperable". Instead of talking about finding a role in this "post-standardization environment" [sic], the IETF might as well shut down the Applications Area and create a Web Area. Regards, -sm From hannes.tschofenig@gmx.net Mon Mar 21 23:52:03 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01DDD3A68EC for ; Mon, 21 Mar 2011 23:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSKvxEcm4f9B for ; Mon, 21 Mar 2011 23:52:02 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 79FA23A68E0 for ; Mon, 21 Mar 2011 23:52:00 -0700 (PDT) Received: (qmail invoked by alias); 22 Mar 2011 06:53:32 -0000 Received: from unknown (EHLO [10.255.135.249]) [192.100.123.77] by mail.gmx.net (mp042) with SMTP; 22 Mar 2011 07:53:32 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+NQBglO/eNbOgc5HqpztPc0DOJWRj6Nlr24i8eCJ fcCLrsczkCODJD Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4D882781.8020605@dcrocker.net> Date: Tue, 22 Mar 2011 08:53:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <00B4DE85-D820-4BA3-A460-7C847734A06A@gmx.net> References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D882781.8020605@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: Pete Resnick , Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 06:52:03 -0000 Hi Dave,=20 the abstract cannot obviously cover all aspects of the talk, as you = know.=20 Jonathan & Harald, who are among the speakers, have good knowledge about = the IETF. They have made significant contributions and they had run into = a few of the issues we are discussing on this list. In our writeup = http://tools.ietf.org/html/draft-tschofenig-post-standardization-00 we = have not only described the positive effects of the trend we are = believing to see but expressed also some concerns. There are also cases = where the current Web model is not able to compete with native = applications. We talk about those as well in the document. =20 In any case, we thought that this topic is relevant enough for the IETF = community to have a dialog and to hear whether you have a view about the = topic as well. As this discussion shows, you obviously do.=20 The time could not have been better given the RTCWeb BOF that is also = going to happen in Prague.=20 Ciao Hannes On Mar 22, 2011, at 6:37 AM, Dave CROCKER wrote: >=20 > On 3/21/2011 8:48 PM, Pete Resnick wrote: >> I sent this to the IAB a few weeks ago. We haven't had much = conversation (they >> responded, but the firehose of stuff before the IETF meeting kept me = from >> replying until recently), but I thought you all would be amused. >=20 >=20 > The degree of disconnect about architecture and protocol issues makes = this a bit challenging to view with humor. (It's tempting to counter = that that's not really true since it is so easy to make fun of the = situation, but that's not what you meant and it's not what I'd find = productive...) >=20 > The larger issue I see is that the views being put forward for the = talk well might be reasonable, with sufficient qualifiers and very = careful language, but no qualifiers are being offered. Instead the = language asserts universals, and these most certainly are not correct. >=20 > There could be a rather interesting discussion about these issues, = given a reasonable mix of people and a reasonable format for exploration = and debate. The current format is cast more for selling a specific view = than for understanding pros and cons and tradeoffs. >=20 > d/ > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From hannes.tschofenig@nsn.com Tue Mar 22 00:18:44 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6B063A6906 for ; Tue, 22 Mar 2011 00:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9zdUUUV9hmh for ; Tue, 22 Mar 2011 00:18:44 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id CFEFF3A68FF for ; Tue, 22 Mar 2011 00:18:43 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p2M7KFIr031153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Mar 2011 08:20:15 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p2M7KEkF014019; Tue, 22 Mar 2011 08:20:14 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Mar 2011 08:20:14 +0100 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, 22 Mar 2011 09:24:10 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450404241E@FIESEXC015.nsn-intra.net> In-Reply-To: <6.2.5.6.2.20110321223051.0e352650@resistor.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [apps-discuss] IETF technical plenary: the end of application protocols Thread-Index: AcvoXO9ivJeYyqFoQBa9Q56Yigc7NwABCbTw References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <6.2.5.6.2.20110321223051.0e352650@resistor.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext SM" , "Apps Discuss" X-OriginalArrivalTime: 22 Mar 2011 07:20:14.0445 (UTC) FILETIME=[967D31D0:01CBE861] Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 07:18:45 -0000 > Instead of talking about finding a role in this "post-standardization=20 > environment" [sic], the IETF might as well shut down the Applications=20 > Area and create a Web Area. Two points: A) A few groups with relevance to the Web have recently been created in the applications area.=20 Examples: OAuth, Websec, hybi B) You phrase it in a bad way that we talk about this topic. What is wrong with looking at trends in the industry that some of us are seeing happening? You can make fun about the way we wrote the document and my English writing skills.=20 From GK@ninebynine.org Tue Mar 22 00:57:14 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93E03A659C for ; Tue, 22 Mar 2011 00:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv8duoEoxC2T for ; Tue, 22 Mar 2011 00:57:13 -0700 (PDT) Received: from relay5.mail.ox.ac.uk (relay5.mail.ox.ac.uk [163.1.2.163]) by core3.amsl.com (Postfix) with ESMTP id 2E2753A659A for ; Tue, 22 Mar 2011 00:57:10 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay5.mail.ox.ac.uk with esmtp (Exim 4.74) (envelope-from ) id 1Q1wU7-00010O-Gx; Tue, 22 Mar 2011 07:58:35 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Q1wU6-00059Y-9K; Tue, 22 Mar 2011 07:58:35 +0000 Message-ID: <4D885482.2050006@ninebynine.org> Date: Tue, 22 Mar 2011 07:49:22 +0000 From: Graham Klyne User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Pete Resnick References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> In-Reply-To: <4D881C04.2080406@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: dcrocker@bbiw.net, Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 07:57:15 -0000 Pete, Notwithstanding my earlier comments in support of Web/HTTP for some applications, I have some sympathy for the sentiments you express here. It does sometimes feel to me that there a technology "capture" taking place by some of the big web players (cf. HTML5), and also there's the whole net neutrality debate seems to be heating up (again?). But at heart the web *should* be about decentralization, breaking the dependencies on single servers and services, enabling developers to develop innovative new applications based on web data. The web architecture principles build on the end-to-end Internet philosophy, and explicitly try to avoid adding new control points. I would say that "big players ... pushing as much as they can into servers so that they can control both the data and the user experience" is something the web makes possible in some cases by virtue of its lack of central coordination. There are many developers in the web community who are creating innovative applications that fit in and around the offerings of the big players. For just one example that happens to spring to mind, see http://weblog.clarkparsia.com/2010/05/26/another-reason-semantic-web-kicks-ass/. The Web is harmed as much by the lack of end-to-end connectivity as any other application. And, yes, I think that HyBi has degenerated into a rather unproductive bun-fight, possibly by trying to do too much rather than figuring a minimum set of requirements that could unlock a range of new capabilities *within* the established web framework. And yes, the Web isn't right for every application (email being a case in point). But I claim that there are very many applications that *can* sit comfortably within the web framework if the design is approached in a conforming way. (And that a lot of design choices in application design may be quite arbitrary, and constraining some of those choices doesn't greatly limit the range of useful applications that can be created.) So, while I agree with your exhortation to restore end-to-end connectivity to the Internet, I don't think that the Web itself is truly the great bete noir in this (other than, by virtue of its widespread use, exacerbating and accelerating the depletion of endpoint addresses). Don't throw out the baby with the bathwater! #g -- FWIW, I can think of two simple (to describe) capabilities that would help to make the web more widely usable as a application platform: (a) a *simple* mechanism for pushing asynchronous notifications to a web application (browser-based or otherwise). I had early hopes for HyBi, but have somewhat given up. (b) a well-founded security model to permit controlled relaxation of the same-origin restrictions on web applications in browsers. Many of the current proposals I'm aware of seem to lack a coherent security analysis (though, when I last looked, HTML5 may be an exception in this regard). I think this could make it easier to separate data storage from applications, opening the way to give users back control of their data. Pete Resnick wrote: > On 3/21/11 9:31 AM, Dave CROCKER wrote: >> Folks, >> >> I just saw the announcement for the Technical Plenary presentation. > I sent this to the IAB a few weeks ago. We haven't had much conversation > (they responded, but the firehose of stuff before the IETF meeting kept > me from replying until recently), but I thought you all would be amused. > > -------- Original Message -------- > Message-ID: <4D76B361.2050704@qualcomm.com> > Date: Tue, 8 Mar 2011 16:53:21 -0600 > From: Pete Resnick > To: > Subject: IAB Technical Session > CC: "'The IESG'" > > [Feel free to forward this as you see fit.] > > Dear IAB, > > You will probably find it unsurprising that I find the abstract of the > technical session at the IAB plenary to be completely unadulterated > rubbish. It is by no means the "advancement in the design of web > browsers" nor the "widespread availability and growing sophistication of > JavaScript interpreters in browsers" that has changed the architecture > of applications. Quite the contrary, it is the forcing of a particular > application paradigm, that of requiring all applications to be > client-server based with all intelligence based in the server, that has > in turn forced Javascript sophistication to increase to accommodate > complex application logic inside the browser. (Indeed, it is this force > that has led to HyBi, the abomination whereby browser-based > applications, instead of being able to simply open a TCP connection, are > forced to go through an HTTP tunnel to the web server in order to get > any kind of network connectivity.) Protocols like POP and IMAP are not > being subsumed into these systems. Rather, the semantics of these > protocols are being dumbed down, eliminating functionality, in order to > allow them to fit into the new constrained environment. > > There are two obvious drivers of this evolution: First and foremost is > the continuing lack of end-to-end connectivity in the network. This is > due to the presence of NATs and assorted firewall nonsense that makes > non-tunneled applications harder and harder to deploy. But the second > driving force is the more insidious one: economics. The economics of the > Internet are currently being driven by big players consolidating the > network, pushing as much as they can into servers so that they can > control both the data and the user experience for applications on the > Internet. This of course is not in the interest of end users, except > insofar as the "big players" are end users with large economic > interests. The more centralized the data becomes, the more dependent > users are on the "big players", the less innovation in applications can > take place, and the less stable the Internet is as a whole. > > This is not a state of affairs in which we need to "identify areas where > the standardization is unlikely to be relevant in the future, and focus > our efforts on those areas where our application designs will remain > impactful." Rather, we need to do what we can with tools we are > currently developing (the deployment of IPv6, the use of MPTCP and other > protocols which allow us to route around the damage to the end-to-end > model) to combat this model and have the Internet remain a distributed > end-to-end network. > > Back to La Mancha. I've been noticing these windmills.... > > pr > From sm@resistor.net Tue Mar 22 01:46:38 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2AE03A67B5 for ; Tue, 22 Mar 2011 01:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.211 X-Spam-Level: X-Spam-Status: No, score=-101.211 tagged_above=-999 required=5 tests=[AWL=-1.388, BAYES_00=-2.599, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCHstVDBRItW for ; Tue, 22 Mar 2011 01:46:34 -0700 (PDT) Received: from mx.elandsys.com (eland-1-pt.tunnel.tserv15.lax1.ipv6.he.net [IPv6:2001:470:c:d43::2]) by core3.amsl.com (Postfix) with ESMTP id C22313A67AA for ; Tue, 22 Mar 2011 01:46:33 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p2M8lxFT010746; Tue, 22 Mar 2011 01:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1300783685; bh=T0TFmzNpZbLDlhfmDN4vhw7nQ6wNZBmsru34GBNhivc=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=b6dNI6N3mELUopQnrDbig/B7mCxgGROLeVfm7mc0hKcIeJ4SM5lwV2C4OTxoKYYvv pjNX7HoPXvTbJBCdhlqz9da7czL4gbB1jvqTiAMSWjtbICcwz80y6VktB1pTGFJNx2 J+Y0/oQQFj5+toAD8nE1XJ1rEonMSxZXWkbbB3AA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1300783685; bh=T0TFmzNpZbLDlhfmDN4vhw7nQ6wNZBmsru34GBNhivc=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=AQVNAvnx6tJHpJRPgHGotVNpVmf9liMKGjyWfxE51zyoWeiRJgXPs1T2U7p/p2oF6 oJkJPSoVw3qMTbXaZmmN56UxoM7HJm6nhISbWL4efstjXka+48kcTc5I8JAp2YTMQq zH53X4wybjRvijt/d8nbxDXCthwaqTm6PcjnemiA= Message-Id: <6.2.5.6.2.20110322002954.0ca26cc8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 22 Mar 2011 01:47:52 -0700 To: "Tschofenig, Hannes (NSN - FI/Espoo)" From: SM In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450404241E@FIESEXC015.nsn-in tra.net> References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <6.2.5.6.2.20110321223051.0e352650@resistor.net> <3D3C75174CB95F42AD6BCC56E5555B450404241E@FIESEXC015.nsn-intra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 08:46:38 -0000 Hi Hannes, At 00:24 22-03-2011, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > Instead of talking about finding a role in this "post-standardization > > environment" [sic], the IETF might as well shut down the Applications > > Area and create a Web Area. > >Two points: > >A) A few groups with relevance to the Web have recently been created in >the applications area. >Examples: OAuth, Websec, hybi > >B) You phrase it in a bad way that we talk about this topic. What is >wrong with looking at trends in the industry that some of us are seeing >happening? You can make fun about the way we wrote the document and my >English writing skills. I'll respond to your last point first. I don't see anything wrong with your English writing skills. I did not even think of that. If I did, I would definitely not make fun about it. I commented on the paragraphs about "The Future of Applications" at https://datatracker.ietf.org/meeting/agenda/ When I see terms like "post-standardization environment", "forward-looking statements" come to mind. Such terms are also used by people with excellent English writing skills. I read "post-standardization environment" in terms of an organization trying to find something to do when its mission is obsoleted by events. I am aware of the work being carried out in OAuth, Websec and Hybi. There is nothing wrong with discussing about the trends in the industry. The arguments that are being made are, in my opinion, similar to those made in RFC 3903. Regards, -sm From Claudio.Allocchio@garr.it Tue Mar 22 01:48:35 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0AE3A67A4 for ; Tue, 22 Mar 2011 01:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sIQ22e1HkjC for ; Tue, 22 Mar 2011 01:48:34 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id CCE1A3A67AA for ; Tue, 22 Mar 2011 01:48:33 -0700 (PDT) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p2M8nrrk068557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Mar 2011 09:49:54 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p2M8nrrk068557 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=d4JMnPO74VaBSsp1url3CQFmIJBYLDr47uv1+Z92XLuHjsif90efjKpKGp6lRwCM2 jb0HLJEAhRM0bT21WD4n4poMyvvw5TRp4CL6cy/qJqxBPfXBR+cRZaN3lR9E0n24zup 1jVcxQc5xNQ/yqyK36L2k4ADa4issc5Yy1aLOUM= Date: Tue, 22 Mar 2011 09:49:53 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: Pete Resnick In-Reply-To: <4D881C04.2080406@qualcomm.com> Message-ID: References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dcrocker@bbiw.net, Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 08:48:35 -0000 On Mon, 21 Mar 2011, Pete Resnick wrote: > On 3/21/11 9:31 AM, Dave CROCKER wrote: >> Folks, >> >> I just saw the announcement for the Technical Plenary presentation. > I sent this to the IAB a few weeks ago. We haven't had much conversation > (they responded, but the firehose of stuff before the IETF meeting kept me > from replying until recently), but I thought you all would be amused. Pete... +1000 ! :-) (and I'm happy to be managing an R&D "carrier" which still thinks exactly what you wrote). > > -------- Original Message -------- > Message-ID: <4D76B361.2050704@qualcomm.com> > Date: Tue, 8 Mar 2011 16:53:21 -0600 > From: Pete Resnick > To: > Subject: IAB Technical Session > CC: "'The IESG'" > > [Feel free to forward this as you see fit.] > > Dear IAB, > > You will probably find it unsurprising that I find the abstract of the > technical session at the IAB plenary to be completely unadulterated rubbish. > It is by no means the "advancement in the design of web browsers" nor the > "widespread availability and growing sophistication of JavaScript > interpreters in browsers" that has changed the architecture of applications. > Quite the contrary, it is the forcing of a particular application paradigm, > that of requiring all applications to be client-server based with all > intelligence based in the server, that has in turn forced Javascript > sophistication to increase to accommodate complex application logic inside > the browser. (Indeed, it is this force that has led to HyBi, the abomination > whereby browser-based applications, instead of being able to simply open a > TCP connection, are forced to go through an HTTP tunnel to the web server in > order to get any kind of network connectivity.) Protocols like POP and IMAP > are not being subsumed into these systems. Rather, the semantics of these > protocols are being dumbed down, eliminating functionality, in order to allow > them to fit into the new constrained environment. > > There are two obvious drivers of this evolution: First and foremost is the > continuing lack of end-to-end connectivity in the network. This is due to the > presence of NATs and assorted firewall nonsense that makes non-tunneled > applications harder and harder to deploy. But the second driving force is the > more insidious one: economics. The economics of the Internet are currently > being driven by big players consolidating the network, pushing as much as > they can into servers so that they can control both the data and the user > experience for applications on the Internet. This of course is not in the > interest of end users, except insofar as the "big players" are end users with > large economic interests. The more centralized the data becomes, the more > dependent users are on the "big players", the less innovation in applications > can take place, and the less stable the Internet is as a whole. > > This is not a state of affairs in which we need to "identify areas where the > standardization is unlikely to be relevant in the future, and focus our > efforts on those areas where our application designs will remain impactful." > Rather, we need to do what we can with tools we are currently developing (the > deployment of IPv6, the use of MPTCP and other protocols which allow us to > route around the damage to the end-to-end model) to combat this model and > have the Internet remain a distributed end-to-end network. > > Back to La Mancha. I've been noticing these windmills.... > > pr > > -- > Pete Resnick > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From dave@cridland.net Tue Mar 22 01:59:47 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18BA3A67E7 for ; Tue, 22 Mar 2011 01:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVnHAtqxKL8B for ; Tue, 22 Mar 2011 01:59:46 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 3D3AF3A67D0 for ; Tue, 22 Mar 2011 01:59:46 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 4F463116808F; Tue, 22 Mar 2011 09:01:17 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFcZOxv-WU11; Tue, 22 Mar 2011 09:01:15 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 6BC1C1168067; Tue, 22 Mar 2011 09:01:15 +0000 (GMT) References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D885482.2050006@ninebynine.org> In-Reply-To: <4D885482.2050006@ninebynine.org> MIME-Version: 1.0 Message-Id: <6266.1300784475.434865@puncture> Date: Tue, 22 Mar 2011 09:01:15 +0000 From: Dave Cridland To: Graham Klyne , Dave CROCKER , General discussion of application-layer protocols , Pete Resnick Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 08:59:47 -0000 On Tue Mar 22 07:49:22 2011, Graham Klyne wrote: > FWIW, I can think of two simple (to describe) capabilities that > would help to make the web more widely usable as a application > platform: > > (a) a *simple* mechanism for pushing asynchronous notifications to > a web application (browser-based or otherwise). I had early hopes > for HyBi, but have somewhat given up. > > As have many. Another option would be to use XMPP directly in the browser - not some hacked down variant communicating only with the webserver's approved domain, but full XMPP. This has different properties entirely from WebSockets, but those properties give rise to some interesting concepts. > (b) a well-founded security model to permit controlled relaxation > of the same-origin restrictions on web applications in browsers. > Many of the current proposals I'm aware of seem to lack a coherent > security analysis (though, when I last looked, HTML5 may be an > exception in this regard). I think this could make it easier to > separate data storage from applications, opening the way to give > users back control of their data. Right - and full XMPP would also allow this, and single-identity, and your own [choice of] server/provider. In fact, it'd even allow a decoupling between the application and its UI, which'd make many of us happier. Oddly, I'd have thought this would be embraced both by the "big players" and end-users with concerns about them. I would love to see a world where the Web does what it's good at - that is, delivering static content, including application code and UI content - and protocols such as XMPP do what they're good at - that is, providing dynamic data between known federated entities. Sadly, I suspect that there is sufficient inertia involved that maintaining the emerging status quo of HTTP for everything will prove impossible to break. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From hannes.tschofenig@gmx.net Tue Mar 22 02:10:56 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46333A67E5 for ; Tue, 22 Mar 2011 02:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.83 X-Spam-Level: X-Spam-Status: No, score=-102.83 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8wRhgUtQhIf for ; Tue, 22 Mar 2011 02:10:52 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 5CF3F3A67E1 for ; Tue, 22 Mar 2011 02:10:49 -0700 (PDT) Received: (qmail invoked by alias); 22 Mar 2011 09:12:21 -0000 Received: from unknown (EHLO [10.255.135.249]) [192.100.123.77] by mail.gmx.net (mp032) with SMTP; 22 Mar 2011 10:12:21 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19ui/lzGJRu5+lmB3jUBsVwHStAjl7cgbxudskaTT cAnfbIPvtj3Wzr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <6.2.5.6.2.20110322002954.0ca26cc8@resistor.net> Date: Tue, 22 Mar 2011 11:12:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4B3040C3-BA44-4AA8-A0BC-395BA0E6DDB7@gmx.net> References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <6.2.5.6.2.20110321223051.0e352650@resistor.net> <3D3C75174CB95F42AD6BCC56E5555B450404241E@FIESEXC015.nsn-intra.net> <6.2.5.6.2.20110322002954.0ca26cc8@resistor.net> To: SM X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 09:10:57 -0000 On Mar 22, 2011, at 10:47 AM, SM wrote: > I read "post-standardization environment" in terms of an organization = trying to find something to do when its mission is obsoleted by events. We had to find some term to describe this paradigm and concept. =20 When you look through the broader standardization landscape then you for = sure will notice that there are architectural differences in where = groups see the need for standards and interoperability and what degree = of interoperability is necessary. For example, compare a 3GPP IMS = architecture, the IETF SIP architecture, and the RTCWeb-based = architecture. I hope you recognize differences - differences that go = beyond the protocol level.=20 I assume that you do not just randomly standardize something and wait = for someone else to pick it up (although researchers like to explore the = entire solution space and that's fine as well). While it is difficult to provide suggestions regarding the approach a = protocol designer should take there are various side-effects of any = decision you make. When we interviewed folks in the Web community (from = inside the IETF as well as outside) it was not so clear where the limits = for the Web (HTML/JavaScript) model are. In any case they are changing = rapidly. We hope to get more feedback from those who have been exposed = to some of the mentioned Web technologies. Are you this Web person? Ciao Hannes From mnot@mnot.net Tue Mar 22 02:44:42 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50AAA3A67F3 for ; Tue, 22 Mar 2011 02:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.325 X-Spam-Level: X-Spam-Status: No, score=-105.325 tagged_above=-999 required=5 tests=[AWL=-2.726, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtlc0VbmDyjb for ; Tue, 22 Mar 2011 02:44:41 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id DF6203A67F2 for ; Tue, 22 Mar 2011 02:44:40 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.52.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9F60A509EB for ; Tue, 22 Mar 2011 05:46:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Mark Nottingham In-Reply-To: <4D87612E.3090900@dcrocker.net> Date: Tue, 22 Mar 2011 20:46:04 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <2780E74C-6F08-4BC4-B23B-A35AFCB0BA3E@mnot.net> References: <4D87612E.3090900@dcrocker.net> To: Apps Discuss X-Mailer: Apple Mail (2.1082) Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 09:44:42 -0000 Since everyone is putting their .02 in... I'm very glad that we have this plenary topic, precisely because it's = getting this kind of response. I've been concerned about the evolution = of the browser for some time, for a variety of reasons (some already = stated by others): - General loss of high-level semantics in favour of low-level = functionality (consider: HTTP and WebSockets) because browser vendors = want to reduce QA exposure and "get out of the way" - Protocols are defined by libraries, not as standards. Thus it's easy = to innovate, but hard to build on others' work (e.g., as a middlebox).=20= - Corresponding loss of unintended reuse - =46rom what I've seen, most libraries tend to ignore aspects of = security, internationalisation, dealing with latency, dealing with = disconnectedness, and so forth. This leaves users with awkward choices. - Comparative weight of a "full" Web stack including JavaScript, = HTML5, CSS and more to implement a functional application (I'd encourage = people to read the HTML5 specification if they haven't already).=20 - Lock-in of data - Movement from declarative markup to imperative APIs for all Web = functionality=20 ... and so on. What's important for IETF folk to understand is that this = *is* happening, and it's going to be very big. The list above is = negative, but there are positives too; what I think we should focus on = is minimising the negative impacts of this platform, and maximising the = positive (to shamelessly borrow from Bill Clinton last week at ICANN). Cheers, On 22/03/2011, at 1:31 AM, Dave CROCKER wrote: > Folks, >=20 > I just saw the announcement for the Technical Plenary presentation. >=20 > As described, the session suggests a failure to recognize at least two = architectural issues. >=20 > One is that it mandates full-time connectivity. The other is that = protocols > that it says are no longer needed are in fact still needed in some = form, albeit > as a layer above HTTP, rather than TCP. >=20 > Replacing TCP with HTTP does not eliminate the requirement for = purpose-built > application protocols, such as specialized mailbox access. >=20 > On the other hand, it does tend to encourage an explosion of = competing, > incompatible application protocols, making for rather remarkable = burdens on > servers and clients. >=20 > The summary also neglects to mention rather significant security = concerns in all this real-time application downloading... >=20 > d/ >=20 >=20 >> The Future of Applications >>=20 >>=20 >> Advancements in the design of web browsers have introduced = fundamental >> changes to the architecture of application protocols. The widespread >> availability and growing sophistication of JavaScript interpreters in >> browsers enables web servers to push to browsers all of the = application >> logic required to implement a client-server protocol. Consequently, = many >> client-server applications that once required an installed client on = a host >> computer now can rely simply on a modern browser to act as a client = for the >> purposes of a particular application. For example, where once email = clients >> required a custom application to access an inbox, increasingly a web = browser >> can serve this purpose as well as the purpose-built applications of = the >> past. Similarly, HTTP with the assistance of JavaScript can subsume = the >> functions performed by the protocols like POP3 and IMAP. The need for >> Internet standards beyond HTTP to implement an email inbox = application >> consequently diminishes - why author standards and worry about >> interoperability of clients and servers when the server can simply = push to >> the client all the code it needs to be interoperable? >>=20 >> Many client-server applications on the Internet could potential = migrate to >> this post-standardization environment. In this environment, there is = of >> course still a role for the IETF to play: existing working groups = like HyBi >> and OAuth are examples of areas where standards work is still = required to >> support this application development paradigm. Collectively, we need = to >> identify areas where the standardization is unlikely to be relevant = in the >> future, and focus our efforts on those areas where our application = designs >> will remain impactful. The goals of this session are to explore = future areas >> of IETF work surrounding this evolution. >>=20 >> Speakers: Jonathan Rosenberg (Skype) Harald Alvestrand (Google) Henry = S. >> Thompson (W3C) >=20 > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From scott.brim@gmail.com Tue Mar 22 06:39:56 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108CB28C0EC for ; Tue, 22 Mar 2011 06:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbIa1jCkolKc for ; Tue, 22 Mar 2011 06:39:55 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 2D0953A6844 for ; Tue, 22 Mar 2011 06:39:55 -0700 (PDT) Received: by iyi12 with SMTP id 12so8750590iyi.31 for ; Tue, 22 Mar 2011 06:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=p+XVbr8Y+3UUuq3Q0lmwd6dTUtzE5HEzSccaw1UCyhg=; b=knu+EOHhNqYkYEkfUt32rAB1ZBoHmA9Sz3boWkm2yd6XGcm5E0zDx6ef5aCpl7SXXP NvbSbQAq21RiDXOlCFi2yVxf7DIgwDG/P+OtRlWhVJBUlmHrlAxgTG8zQBZu6PqRoHq2 cwM3mq09ftjhv3lRvfZ9x08iYA1eIIfEdAp1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Ace/QTtmbrP3WqhNQjm1MB/PyVqnnbZh34vMDa1BAtECsw/s5BEkKLXsteQHmaSQys lTbAXgzArw7/IrgNM58e8OvBA/nlf5CKzOTLhm4nrEh8ple5VGIwWtk89+d1oXfBfp2k XuZk1zkt2Gyi4vrzMUGGzqypruaJ/yc1+fMAc= Received: by 10.42.134.132 with SMTP id l4mr9232354ict.13.1300801285606; Tue, 22 Mar 2011 06:41:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.164.74 with HTTP; Tue, 22 Mar 2011 06:41:05 -0700 (PDT) In-Reply-To: <4D881C04.2080406@qualcomm.com> References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> From: Scott Brim Date: Tue, 22 Mar 2011 09:41:05 -0400 Message-ID: To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 13:39:56 -0000 Pete: Yes, amusing. I want to digress on one thing you said ... On Mon, Mar 21, 2011 at 23:48, Pete Resnick wrote: > There are two obvious drivers of this evolution: First and foremost is the > continuing lack of end-to-end connectivity in the network. This is due to > the presence of NATs and assorted firewall nonsense that makes non-tunneled > applications harder and harder to deploy. But the second driving force is > the more insidious one: economics. The economics of the Internet are > currently being driven by big players consolidating the network, pushing as > much as they can into servers so that they can control both the data and the > user experience for applications on the Internet. This of course is not in > the interest of end users, except insofar as the "big players" are end users > with large economic interests. The more centralized the data becomes, the > more dependent users are on the "big players", the less innovation in > applications can take place, and the less stable the Internet is as a whole. I think the causality is turned around several times in these sentences. First, NATs did not force people into client-server mode. If people had had a strong desire for end-to-end transparency, we would have more of it. NATs started appearing and they didn't cut off anything people saw as vital. Some apps (e.g. FTP and Skype) adapted. It is now hard to preserve peer-to-peer, and get away from client-server, partly because of NATs but mainly because the vast majority of people find client-server to be convenient. They like services. If there was more demand for transparency you would see more of it. Second, yes economics, and yes the big boys are pushing to control more, but that doesn't mean it is not in the interest of end users. They like services. So yes, architecturally we must fight to preserve peer-to-peer, but we are not doing so because zillions of end users want us to; we are doing so because we know better than they do what's good for them (and the Internet). Finally I don't see how having data centralized, or data flows between fewer src/dst pairs, lowers stability of the Internet. Scott From leslie@thinkingcat.com Tue Mar 22 13:09:09 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D22528C12E for ; Tue, 22 Mar 2011 13:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvjBAcf-pBcu for ; Tue, 22 Mar 2011 13:09:02 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 930603A6783 for ; Tue, 22 Mar 2011 13:09:02 -0700 (PDT) Received: from cashmere.local ([::ffff:173.71.208.218]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 22 Mar 2011 16:10:35 -0400 id 00018048.4D89023B.00006CDE Message-ID: <4D890230.4010308@thinkingcat.com> Date: Tue, 22 Mar 2011 16:10:24 -0400 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Apps Discuss References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D882781.8020605@dcrocker.net> In-Reply-To: <4D882781.8020605@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 20:09:09 -0000 +1 to this -- especially the points about the views being put forward being reasonable, but not all-encompassing. Leslie. Dave CROCKER wrote: > > On 3/21/2011 8:48 PM, Pete Resnick wrote: >> I sent this to the IAB a few weeks ago. We haven't had much >> conversation (they >> responded, but the firehose of stuff before the IETF meeting kept me from >> replying until recently), but I thought you all would be amused. > > > The degree of disconnect about architecture and protocol issues makes > this a bit challenging to view with humor. (It's tempting to counter > that that's not really true since it is so easy to make fun of the > situation, but that's not what you meant and it's not what I'd find > productive...) > > The larger issue I see is that the views being put forward for the talk > well might be reasonable, with sufficient qualifiers and very careful > language, but no qualifiers are being offered. Instead the language > asserts universals, and these most certainly are not correct. > > There could be a rather interesting discussion about these issues, given > a reasonable mix of people and a reasonable format for exploration and > debate. The current format is cast more for selling a specific view than > for understanding pros and cons and tradeoffs. > > d/ -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From leslie@thinkingcat.com Tue Mar 22 13:09:14 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C7D28C17A for ; Tue, 22 Mar 2011 13:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDRmZZfI3czX for ; Tue, 22 Mar 2011 13:09:12 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 3924328C176 for ; Tue, 22 Mar 2011 13:09:12 -0700 (PDT) Received: from cashmere.local ([::ffff:173.71.208.218]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 22 Mar 2011 16:10:44 -0400 id 00018054.4D890244.00006CEB Message-ID: <4D89023C.4090307@thinkingcat.com> Date: Tue, 22 Mar 2011 16:10:36 -0400 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Apps Discuss References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> In-Reply-To: <4D881C04.2080406@qualcomm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [apps-discuss] IETF-port-80 technical plenary Re: IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 20:09:14 -0000 So, this is the IETF-port-80 tech plenary? Can't wait for hosts2-ns in Quebec City ;-) IMO, the approach outlined in the plenary plan makes (and, ultimately, would entrench) an unwarranted distinction between clients and servers as devices on the Internet. Clients do IMAP to get mail, but SMTP is an Application protocol for inter-server mail transfer. The Internet has actually flourished _because_ any client could be a server. In that vein -- not all transaction models are supported in HTTP, so overlaying all applications could be expensive and ineffective. So, while I don't doubt there will be more of this type of HTTP-embedded application work, IMO it should not be conflated with the totality of Internet application/infrastructure standardization. In general, the IETF has done application _transport_ protocols (HTTP, and XMPP for that matter), and infrastructure (naming -- URLs, URNs etc). This is particularly evident in the split of HTML off to the W3C - which made sense, because the expertise required was different, the focus much more on the end-user requirements than the network realities. (And, HTTP remains at the IETF because its revisions benefit from the IETF's much broader understanding and expertise of transport issues is the most important aspect to bring to bear on it). So, making this a call to action around the IETF's application standardization activity seems a little incomplete. If this rises to the level of the IAB's attention, I'd like to think the IAB would manage to have that broader perspective -- not necessarily of application protocols or their structure, but the fact that the Internet of the future is going to be a very diverse place (still) and is not just about clients and servers as we commonly conceive them (notebooks, desktops, etc). In November, I had the opportunity to participate in some discussions about the shape of the future Internet, in terms of devices: i.e., handhelds and other untethered devices. The current and ongoing constraints of those devices make for an interesting landscape for the Internet of the future. Ted alluded to some of them in his remarks in this thread. I wrote up some of my perspective on the landscape, in terms of untethered devices and the implications of/for RFCs 1122/1123, here: http://isoc.org/wp/ietfjournal/?p=2185#more-2185 . I think those documents represent pretty sound "first principles", and concluded with: "Diversity and openness remain critical in Internet deployment, in order to continue to foster innovation. 1122/23 stress the importance of recognizing that individual networks would be set up and operated according to local design choices. The open Internetwork application framework is what has permitted the creation of novel applications without requiring permission from network operators or device manufacturers for deployment. The World Wide Web was one such idea that took hold like wildfire. Time and again, users and usage of Internet have laid the groundwork for the Internet’s evolution, not some master control. It’s important to retain the ability to support that kind of innovation and open experience, as provided for in the hosts requirements in 1122/23. In that light, the notion of an open standard “split node” model, with individual users establishing and controlling preferences for policies, would allow more growth and innovation than, for instance, “one size fits all” policy assumptions implemented as network operator private controls. In the end, then, it’s clear the future Internet will support many users and uses based on untethered devices, and thus feature hosts that exceed the expectations of 1122/23. But the framework in those documents is sound: provide a set of requirements for interoperation at the transport and application levels, and unfettered innovation will follow. Time will tell whether the requirements of hosts are updated to accommodate the practical realities of power and bandwidth constraints understood with untethered devices, or whether the “host” will become some tethered server supporting multiple roaming devices, for example. The only wrong choice is no choice at all." which seems applicable here. Leslie. Pete Resnick wrote: > On 3/21/11 9:31 AM, Dave CROCKER wrote: >> Folks, >> >> I just saw the announcement for the Technical Plenary presentation. > I sent this to the IAB a few weeks ago. We haven't had much conversation > (they responded, but the firehose of stuff before the IETF meeting kept > me from replying until recently), but I thought you all would be amused. > > -------- Original Message -------- > Message-ID: <4D76B361.2050704@qualcomm.com> > Date: Tue, 8 Mar 2011 16:53:21 -0600 > From: Pete Resnick > To: > Subject: IAB Technical Session > CC: "'The IESG'" > > [Feel free to forward this as you see fit.] > > Dear IAB, > > You will probably find it unsurprising that I find the abstract of the > technical session at the IAB plenary to be completely unadulterated > rubbish. It is by no means the "advancement in the design of web > browsers" nor the "widespread availability and growing sophistication of > JavaScript interpreters in browsers" that has changed the architecture > of applications. Quite the contrary, it is the forcing of a particular > application paradigm, that of requiring all applications to be > client-server based with all intelligence based in the server, that has > in turn forced Javascript sophistication to increase to accommodate > complex application logic inside the browser. (Indeed, it is this force > that has led to HyBi, the abomination whereby browser-based > applications, instead of being able to simply open a TCP connection, are > forced to go through an HTTP tunnel to the web server in order to get > any kind of network connectivity.) Protocols like POP and IMAP are not > being subsumed into these systems. Rather, the semantics of these > protocols are being dumbed down, eliminating functionality, in order to > allow them to fit into the new constrained environment. > > There are two obvious drivers of this evolution: First and foremost is > the continuing lack of end-to-end connectivity in the network. This is > due to the presence of NATs and assorted firewall nonsense that makes > non-tunneled applications harder and harder to deploy. But the second > driving force is the more insidious one: economics. The economics of the > Internet are currently being driven by big players consolidating the > network, pushing as much as they can into servers so that they can > control both the data and the user experience for applications on the > Internet. This of course is not in the interest of end users, except > insofar as the "big players" are end users with large economic > interests. The more centralized the data becomes, the more dependent > users are on the "big players", the less innovation in applications can > take place, and the less stable the Internet is as a whole. > > This is not a state of affairs in which we need to "identify areas where > the standardization is unlikely to be relevant in the future, and focus > our efforts on those areas where our application designs will remain > impactful." Rather, we need to do what we can with tools we are > currently developing (the deployment of IPv6, the use of MPTCP and other > protocols which allow us to route around the damage to the end-to-end > model) to combat this model and have the Internet remain a distributed > end-to-end network. > > Back to La Mancha. I've been noticing these windmills.... > > pr > -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From mnot@mnot.net Tue Mar 22 14:11:43 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE06528C0D9 for ; Tue, 22 Mar 2011 14:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.251 X-Spam-Level: X-Spam-Status: No, score=-105.251 tagged_above=-999 required=5 tests=[AWL=-2.652, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNvhB1eLasd2 for ; Tue, 22 Mar 2011 14:11:42 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id CB6663A68B1 for ; Tue, 22 Mar 2011 14:11:42 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.52.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 76DA3509ED; Tue, 22 Mar 2011 17:13:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4D89023C.4090307@thinkingcat.com> Date: Wed, 23 Mar 2011 08:13:06 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <6A625146-3094-4E61-9C35-18DA831F382A@mnot.net> References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D89023C.4090307@thinkingcat.com> To: Leslie Daigle X-Mailer: Apple Mail (2.1082) Cc: Apps Discuss Subject: Re: [apps-discuss] IETF-port-80 technical plenary Re: IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 21:11:44 -0000 Just to this point -- On 23/03/2011, at 7:10 AM, Leslie Daigle wrote: > In that vein -- not all transaction models are supported in HTTP, so = overlaying all applications could be expensive and ineffective. it's important to understand that the folks pushing = browser-as-a-platform see WebSockets (from our very own HYBI WG) the = answer to this. Regards, -- Mark Nottingham http://www.mnot.net/ From paul.hoffman@vpnc.org Tue Mar 22 15:17:45 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3D4C3A67DB for ; Tue, 22 Mar 2011 15:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.026 X-Spam-Level: X-Spam-Status: No, score=-102.026 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQijpIbjydxo for ; Tue, 22 Mar 2011 15:17:44 -0700 (PDT) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id E5E693A67D9 for ; Tue, 22 Mar 2011 15:17:43 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2MMJGnp090300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 22 Mar 2011 15:19:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Paul Hoffman In-Reply-To: <4D890230.4010308@thinkingcat.com> Date: Tue, 22 Mar 2011 15:19:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D882781.8020605@dcrocker.net> <4D890230.4010308@thinkingcat.com> To: Apps Discuss X-Mailer: Apple Mail (2.1084) Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 22:17:45 -0000 I note that all of the messages on this thread have gone to apps-discuss = only, not to iab@ietf.org. I propose that if those with strong feelings = about the topic description want to see it addressed sooner rather than = later, talking to the IAB at the same time as the Apps Area might be = more effective. --Paul Hoffman= From Claudio.Allocchio@garr.it Tue Mar 22 15:44:19 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AD793A6803 for ; Tue, 22 Mar 2011 15:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4keNQgzPMKVd for ; Tue, 22 Mar 2011 15:44:18 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id BAFA93A6808 for ; Tue, 22 Mar 2011 15:44:17 -0700 (PDT) Received: from webcam1-all.garrtest.units.it (webcam1-all.garrtest.units.it [140.105.201.5]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p2MMjjNU017564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Mar 2011 23:45:47 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p2MMjjNU017564 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=av900b7kx03E0jGeywr1HjNZEVknP5Jw6cvjq1zzBI/E0rKHoIK3ZbMVpyFW0hIu8 3VDy6ZsC1Oq2fOIYI6d955q+zG+t7pmj8ZzMT4rpPc3qS0/PbI8VgDrSsoMWxwEKYdn tRs7ul7ns0oDjkdcQ2zfpp9LsC/n6BDHjlsB0O8= Date: Tue, 22 Mar 2011 23:45:45 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@webcam1-all.garrtest.units.it To: Paul Hoffman In-Reply-To: Message-ID: References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D882781.8020605@dcrocker.net> <4D890230.4010308@thinkingcat.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 22:44:19 -0000 On Tue, 22 Mar 2011, Paul Hoffman wrote: > I note that all of the messages on this thread have gone to apps-discuss > only, not to iab@ietf.org. I propose that if those with strong feelings > about the topic description want to see it addressed sooner rather than > later, talking to the IAB at the same time as the Apps Area might be > more effective. True... but I would suggest a full digest of what has been said until now to be packed up for the IAB; they all give a view (or another less "spamming" version to convey the information to IAB, for example). thanks for pointing this, Paul! > > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nico@cryptonector.com Tue Mar 22 15:44:32 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 578DB28C16C for ; Tue, 22 Mar 2011 15:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLAcMpJli11j for ; Tue, 22 Mar 2011 15:44:31 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id 5119928C16B for ; Tue, 22 Mar 2011 15:44:31 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id C60962C806D for ; Tue, 22 Mar 2011 15:46:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=TL2cU5mLJ5mBj9eu6EYuLGLx08B8PFLFLjbS/DGZjdXY JGMFHa6iJk96HNiwNfA1WtoavgIw9tlZChvpD4E2eRfAr77vujezCgm3LVkWik9Z 0OhCc7mgqB3JWWMbwyBOrLqLLONCCNRRB/0m3HcJyZkzTZTIb+ueunlrbhS0neQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=2BRBfouLQ+RbFX5kBDt0DWR/PuY=; b=szMKbGCm+J7 Ja7MqM2kBZBgUzay7kse6PT8I8osjzH5qfKhy29VetRTWBCAiE1g3krmNdWGjPtn NH6okRBHeQiy9BdgIXOPc8QbIVyKkoJDgoXUQCnwSbB8QJrYn0pP9Orfc+Cng/Hs mF5Fmcg9mnRsyC0CgkWyyTfPa+iUn5ow= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 90D452C806B for ; Tue, 22 Mar 2011 15:46:03 -0700 (PDT) Received: by vxg33 with SMTP id 33so6954592vxg.31 for ; Tue, 22 Mar 2011 15:46:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.74.226 with SMTP id x2mr6013826vdv.264.1300833962768; Tue, 22 Mar 2011 15:46:02 -0700 (PDT) Received: by 10.52.159.4 with HTTP; Tue, 22 Mar 2011 15:46:02 -0700 (PDT) In-Reply-To: <4D87612E.3090900@dcrocker.net> References: <4D87612E.3090900@dcrocker.net> Date: Tue, 22 Mar 2011 17:46:02 -0500 Message-ID: From: Nico Williams To: dcrocker@bbiw.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 22:44:32 -0000 On Mon, Mar 21, 2011 at 9:31 AM, Dave CROCKER wrote: > I just saw the announcement for the Technical Plenary presentation. > > As described, the session suggests a failure to recognize at least two > architectural issues. > > One is that it mandates full-time connectivity. =C2=A0The other is that p= rotocols > that it says are no longer needed are in fact still needed in some form, > albeit > as a layer above HTTP, rather than TCP. > > Replacing TCP with HTTP does not eliminate the requirement for purpose-bu= ilt > application protocols, such as specialized mailbox access. HTTP _and_ JavaScript is what the announcement asserts. This is another way of saying that applications are now downloaded as necessary. Anything identifiable as an application protocol becomes an ephemeral incident. I don't quite buy it. Even in the age of AJAX people speak of APIs, where the APIs are all based on HTTP and some document representation (XML, XHTML, JSON, ...). APIs are -roughly, if not exactly- another name for "protocol" in this context. Perhaps we could speak of a large-scale replacement of many apps with a mixture of apps that define application protocols/APIs, apps that define neither, and apps that define protocols/APIs for some parts and none for others, plus a thin-client model. That is what I think is happening. Whether a protocol or an API are defined will generally depend on how much developers can rely on browsers and JavaScript. Browser-based UIs are nice, but not enough, which leads at least some applications to grow stable protocols or APIs. No, TCP is not now just a layer with which to slowdown HTTP. There will continue to be non-HTTP-based applications for a long time to come. > On the other hand, it does tend to encourage an explosion of competing, > incompatible application protocols, making for rather remarkable burdens = on > servers and clients. Certainly if all users were happy to live with browser-based apps only, where the application is always delivered by their corresponding service providers, then yes, we'd have an explosion of unstable and/or undocumented (and therefore non-interoperable) protocols. In practice there's a limit to how browser-bound users can be. Mobile devices in particular are probably a big driver of stable HTTP-based protocols/APIs, since it's oh so much lighter weight to speak HTTP without having to have a browser, a DOM, and a JavaScript engine. But there's also a lot of demand from users for third party apps, and pressure from 3rd party developers for the same, and it may well be that this will be enough in many cases for the provider to agree to provide stable interfaces, even if later on mobile devices were to gain so much power and functionality that browser-based UIs could reasonably rule the day. Besides, even if 90% of the time browser-based UIs sufficed, there will always be some cases where they don't (mash-ups, automation, convenience, aesthetics, ...). Only by ignoring the needs of users do we get to have a pure thin-client model of the world filled with unstable/undocumented protocols. Moreover, there is some degree to which we should be concerned that we're being encouraged (not necessarily by those giving the presentation in question) to accept such a model primarily because this is in the [apparent] self-interest of service providers. In other words: we probably need interoperable protocols/APIs now more than ever. They may simply take a different form than the non-HTTP apps' of yesteryear, but that's it. Nico -- From jon.peterson@neustar.biz Tue Mar 22 16:10:53 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939FC28C0F8 for ; Tue, 22 Mar 2011 16:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ISJ7F7sFNps for ; Tue, 22 Mar 2011 16:10:52 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by core3.amsl.com (Postfix) with ESMTP id 2956E28C0E0 for ; Tue, 22 Mar 2011 16:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1300835545; x=1616194743; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=p4Aj8+qzcglhswqqZsSiQ ivdvmDtbxIvgyG4E2TV2CI=; b=bgczUuEYYDScPVpr3B5eBUJVqq59Ji9nQoKyy Rb4bYMcRJ/bfIoiowsH/fa3xuHKVN7iUkXkJqimlTkSQWw1tA== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id 5202942.37452022; Tue, 22 Mar 2011 19:12:24 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Tue, 22 Mar 2011 19:12:24 -0400 From: "Peterson, Jon" To: Apps Discuss Date: Tue, 22 Mar 2011 19:12:22 -0400 Thread-Topic: [apps-discuss] IETF technical plenary: the end of application protocols Thread-Index: Acvo5pnRPxQ6R/EvSfe/g9du9K6nxA== Message-ID: <350C1321-1FA8-444B-AFA5-ACD8F36EB0E8@neustar.biz> References: <4D87612E.3090900@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: NkHk22aVj+cfzgCK+IfTsw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 23:10:53 -0000 I am glad to see the plenary has already inspired some good discussion befo= re it has even taken place. I only worry that the more dissent is vented in= this thread, the more the actually plenary will be a let-down, but... The purpose of this plenary is to raise awareness in the broader community = of new areas for IETF work and for coordination with the W3C. Some of that = work has already been chartered, some will be discussed in BoF form in Prag= ue, and some has yet to be nailed down into engineering problems. The most = immediate trigger for the plenary is the RTC-Web BoF, and the choice of pan= elists reflects that focus, but the IETF has plenty of other interactions i= n efforts like HyBi and the broader emergence of application designs buildi= ng on top of javascript and HTML5. I believe there is value in identifying= the commonalities in these trends in applications development and asking w= here the IETF can help to make them better. Websockets will exist, in one f= orm of another, the question is whether they will have the benefit of IETF = review, of our understanding of transports, of NATs, of security, of all th= e things that make sockets hard. By addressing itself to these emerging app= lication architectures, the IETF can find new areas of relevance and potent= ially attract new participants and ideas to our community. The purpose of this plenary is not to say that this web architecture should= be the exclusive focus of the Apps Area, nor to delineate some specific se= t of work that should be replaced by something else. That's why, in our pla= n for this, we didn't adopt a point/counterpoint format - I don't really th= ink web applications and standalone applications are mutually exclusive, bo= th will certainly exist in their own areas of applicability. As Hannes has = mentioned already, a few IAB members put out a draft on this subject which = is probably a better place to look for architectural thinking about this pl= enary than the blurb in the agenda. Note well, however, that document is no= t a consensus statement of the IAB. What the panelists will say is up to th= em, and should not be understood as a position of the IAB either. The IAB i= nterest here is simply to shine a spotlight where we think attention is war= ranted - if anything, this thread has shown the interest of the community i= n this subject. We do hope that the plenary will help people to see this ne= w work as a space where the IETF can make a meaningful contribution and not= , say, as "an abomination."=20 If, in light of all this, people feel that emergency course-correction is r= equired in order for this plenary to be useful to the community, don't hesi= tate to raise any specific ideas with me or the IAB as a whole, and we'll s= ee what we can do in our remaining couple days here. Jon Peterson NeuStar, Inc.= From sm@resistor.net Tue Mar 22 16:25:14 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 139E13A6835 for ; Tue, 22 Mar 2011 16:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ0bb3DM3lHJ for ; Tue, 22 Mar 2011 16:25:12 -0700 (PDT) Received: from mx.elandsys.com (eland-1-pt.tunnel.tserv15.lax1.ipv6.he.net [IPv6:2001:470:c:d43::2]) by core3.amsl.com (Postfix) with ESMTP id 18C603A683F for ; Tue, 22 Mar 2011 16:25:10 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p2MNQX4x014357; Tue, 22 Mar 2011 16:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1300836400; bh=17bHfiQN4wS31nzjHeZ5wBNnw7HiLNDyqsiq/Hm07lU=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=I01hz5UsROG+Z8q0XZCMkYOh8ThDdChjGFcCJuvNNBIyPV91/2B5biQW/PLfmskR3 Aos5RaIipvdW3UNAxO/wL/5PTuyy2v5rWA6J9Ma8niKUbGxg73Ix49y8OaW0EEcxbC V1rW5AKVr21KgMEOOJyngCQPH5q+VZIOKwn05spU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1300836400; bh=17bHfiQN4wS31nzjHeZ5wBNnw7HiLNDyqsiq/Hm07lU=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=H1F+wm+49CkbJCKnXFiJujMdSLLPuk2Zj63a1xF+DCdu1FNgeJyxP/KpUedxhZRd/ fLBvT5t4HGaeyOD3jDfBzThwLarTamV4PCD5gvJjCLqopLelZC3LhPEELZ51mSOBVs +ECJVkbK1UxW06pQFdgMSLx2v2xXcdCsoueg7Sec= Message-Id: <6.2.5.6.2.20110322125600.0d7e0050@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 22 Mar 2011 16:22:22 -0700 To: Hannes Tschofenig From: SM In-Reply-To: <4B3040C3-BA44-4AA8-A0BC-395BA0E6DDB7@gmx.net> References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <6.2.5.6.2.20110321223051.0e352650@resistor.net> <3D3C75174CB95F42AD6BCC56E5555B450404241E@FIESEXC015.nsn-intra.net> <6.2.5.6.2.20110322002954.0ca26cc8@resistor.net> <4B3040C3-BA44-4AA8-A0BC-395BA0E6DDB7@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 23:25:14 -0000 Hi Hannes, At 02:12 22-03-2011, Hannes Tschofenig wrote: >We had to find some term to describe this paradigm and concept. Ok. >When you look through the broader standardization landscape then you >for sure will notice that there are architectural differences in >where groups see the need for standards and interoperability and >what degree of interoperability is necessary. For example, compare a >3GPP IMS architecture, the IETF SIP architecture, and the >RTCWeb-based architecture. I hope you recognize differences - >differences that go beyond the protocol level. One key point here is the "degree of interoperability". That might sum up the various positions we have seen in this discussion. >While it is difficult to provide suggestions regarding the approach >a protocol designer should take there are various side-effects of >any decision you make. When we interviewed folks in the Web >community (from inside the IETF as well as outside) it was not so >clear where the limits for the Web (HTML/JavaScript) model are. In >any case they are changing rapidly. We hope to get more feedback >from those who have been exposed to some of the mentioned Web >technologies. Are you this Web person? I prefer not to answer yes to being a Web person. :-) I agree that the limits are changing rapidly. Mark commented on the evolution of the browser and lock-in of data [1]. As we move from protocol to service, the code is the least of our concerns. Regards, -sm 1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02396.html From dhc@dcrocker.net Wed Mar 23 06:57:44 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84F923A6915 for ; Wed, 23 Mar 2011 06:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpHqBe-lXoCK for ; Wed, 23 Mar 2011 06:57:43 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 714993A690F for ; Wed, 23 Mar 2011 06:57:43 -0700 (PDT) Received: from [10.2.2.20] (94-175-239-226.static.virginmedia.net [94.175.239.226] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p2NDx5it026910 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2011 06:59:12 -0700 Message-ID: <4D89FC99.2090101@dcrocker.net> Date: Wed, 23 Mar 2011 14:58:49 +0100 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Apps Discuss References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <6.2.5.6.2.20110321223051.0e352650@resistor.net> <3D3C75174CB95F42AD6BCC56E5555B450404241E@FIESEXC015.nsn-intra.net> <6.2.5.6.2.20110322002954.0ca26cc8@resistor.net> <4B3040C3-BA44-4AA8-A0BC-395BA0E6DDB7@gmx.net> <6.2.5.6.2.20110322125600.0d7e0050@resistor.net> In-Reply-To: <6.2.5.6.2.20110322125600.0d7e0050@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 23 Mar 2011 06:59:13 -0700 (PDT) Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 13:57:44 -0000 Somewhat relevant and cautionary, for this thread: Internet or Splinternet? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nico@cryptonector.com Wed Mar 23 11:32:58 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FA7428C115 for ; Wed, 23 Mar 2011 11:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+-RpdXf9VnF for ; Wed, 23 Mar 2011 11:32:57 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id D7F1B28C117 for ; Wed, 23 Mar 2011 11:32:56 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id EB2DB350079 for ; Wed, 23 Mar 2011 11:34:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=bpHRCtLKc5zuQUnEK60b9pTBv3Ddvcy4IRdzjFgHSllQ x+4g5Wl6mXZ35V0uHiYKHiqRJsyFDx6ZMPWj5uivPxvtxY0TFUTl8hfYbbmapzbD jCmRwYGNfHocQQSIn0sM9xVDnmIlmfk5ocksUbRhlxbwsUGUlEDE5fY9elcr/2w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=S7jyH1x+p8BYSmy09PyyI796Wm8=; b=YCPrWQzZA6h 4DHvtZOt9SUbkkH3kL1vbw/zYhN9tpL4aMphEfHGclJDJ5HyOchn+QzMooEQ+IqC AazCcGmP737TjO+coj1TaeazvdhrVCV01avvrjS5CEzDVR0+mh5fLHyjZ/5PdJKz 9zfeCEmZntiwDT1KcfGUz4gYsK+YyQok= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id B6F70350078 for ; Wed, 23 Mar 2011 11:34:30 -0700 (PDT) Received: by vws12 with SMTP id 12so6903770vws.31 for ; Wed, 23 Mar 2011 11:34:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.74.226 with SMTP id x2mr7314344vdv.264.1300905270130; Wed, 23 Mar 2011 11:34:30 -0700 (PDT) Received: by 10.52.159.4 with HTTP; Wed, 23 Mar 2011 11:34:29 -0700 (PDT) In-Reply-To: <350C1321-1FA8-444B-AFA5-ACD8F36EB0E8@neustar.biz> References: <4D87612E.3090900@dcrocker.net> <350C1321-1FA8-444B-AFA5-ACD8F36EB0E8@neustar.biz> Date: Wed, 23 Mar 2011 13:34:29 -0500 Message-ID: From: Nico Williams To: "Peterson, Jon" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 18:32:58 -0000 On Tue, Mar 22, 2011 at 6:12 PM, Peterson, Jon w= rote: > =C2=A0We do hope that the plenary will help people to see this new work a= s a space where the IETF can make a meaningful contribution and not, say, a= s "an abomination." > > If, in light of all this, people feel that emergency course-correction is= required in order for this plenary to be useful to the community, don't he= sitate to raise any specific ideas with me or the IAB as a whole, and we'll= see what we can do in our remaining couple days here. "Emergency course-correction"? No, no such thing is needed. The authors' dream(?) of protocol-less-ness may be over-the-top simplification, but they should be allowed to share their viewpoint. I believe that the driver for protocols or "APIs" is not the IETF, not the Internet community, but the community of users and third party developers that grows around successful services, as well as competition. Service providers may wish to retain full control over their protocols -whether out of a desire to be unconstrained in their evolution or for other reasons does not matter- but I believe that is wishful thinking. It is market forces, not the IETF, that will force a fair measure of protocol/API stability/standardization (de facto or de jure); market forces are likely to be overwhelming in the long run. Of course, it's always possible that some providers will succeed in creating popular, non-interoperable services, and since they are certainly free to try for that, therefore some will try. Cheers, Nico -- From cabo@tzi.org Wed Mar 23 13:20:43 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1A0728C0F9 for ; Wed, 23 Mar 2011 13:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.341 X-Spam-Level: X-Spam-Status: No, score=-104.341 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Vrnk3ca3T5j for ; Wed, 23 Mar 2011 13:20:42 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id BFF1A28C0F1 for ; Wed, 23 Mar 2011 13:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p2NKM6SK021352 for ; Wed, 23 Mar 2011 21:22:06 +0100 (CET) Received: from [192.168.2.2] (ip-2-202-245-10.web.vodafone.de [2.202.245.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 828A75EE; Wed, 23 Mar 2011 21:22:05 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4D87612E.3090900@dcrocker.net> Date: Wed, 23 Mar 2011 21:22:02 +0100 Content-Transfer-Encoding: 7bit Message-Id: <33EA7EF3-E148-492E-94EF-E95DC6BB7160@tzi.org> References: <4D87612E.3090900@dcrocker.net> To: Apps Discuss X-Mailer: Apple Mail (2.1082) Subject: Re: [apps-discuss] AJAX is the new NAT X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 20:20:43 -0000 So, AJAX appears to be the new NAT. (For those who weren't there in the 1990s: the IETF closed their eyes with respect to the emerging pervasiveness of NATs and continued designing protocols that ignored NATs and then didn't win. I was hoping we would never do that again.) (For those who weren't there in the 2000s: AJAX has indeed made the browser a useful application delivery platform. Once a node can control the code on *both* communicating peers, it can do interesting things without having to standardize much, as shown in RFC 3320 and as demonstrated nicely in AJAX. If you read German, there is even a somewhat dated book from 2005 still online at http://www.teialehrbuch.de/Kostenlose-Kurse/AJAX/ the initial chapters of which explain why this form of mobile code is winning.) Now for 2011: What we need to do is acknowledge that AJAX has happened. The Web hasn't been "hypertext" for a long time now. With all the negative (and not so negative) effects, which were nicely tabulated by Mark Nottingham in this thread. What we also need to do is help steer the standards-based foundation so that it encourages each and every single developer to favor standards-based (or standards-like) APIs/protocols even in this brave new world. The persistence of REST in the AJAX world has helped a lot; other, community-driven standards such as JSON have even been picked up by the IETF (even though RFC 4627 is labeled Informational). But, for example the rigid same-origin policy of the existing browser world makes standards-based APIs less useful though -- AJAX apps can only use their own servers' APIs, so there is less incentive to offer AJAX APIs for consumption by other apps/clients. The IETF needs to *help* the AJAX world, not close our eyes again. Help AJAX get better, get more secure. Get more standards-based, more open. Gruesse, Carsten From petithug@acm.org Wed Mar 23 14:11:33 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DEC828C0F1 for ; Wed, 23 Mar 2011 14:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.157 X-Spam-Level: X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBOknfvuRJm3 for ; Wed, 23 Mar 2011 14:11:32 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 6104928C0E5 for ; Wed, 23 Mar 2011 14:11:32 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 90D93DBCC046; Wed, 23 Mar 2011 21:13:06 +0000 (UTC) Received: from [192.168.2.225] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id F1353DBCC044; Wed, 23 Mar 2011 21:13:05 +0000 (UTC) Message-ID: <4D8A6261.1090308@acm.org> Date: Wed, 23 Mar 2011 14:13:05 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.4) Gecko/20100718 Icedove/3.1 MIME-Version: 1.0 To: Carsten Bormann References: <4D87612E.3090900@dcrocker.net> <33EA7EF3-E148-492E-94EF-E95DC6BB7160@tzi.org> In-Reply-To: <33EA7EF3-E148-492E-94EF-E95DC6BB7160@tzi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] AJAX is the new NAT X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 21:11:33 -0000 On 03/23/2011 01:22 PM, Carsten Bormann wrote: > So, AJAX appears to be the new NAT. > > (For those who weren't there in the 1990s: the IETF closed their eyes > with respect to the emerging pervasiveness of NATs and continued > designing protocols that ignored NATs and then didn't win. > I was hoping we would never do that again.) > > (For those who weren't there in the 2000s: AJAX has indeed made the > browser a useful application delivery platform. Once a node can > control the code on *both* communicating peers, it can do interesting > things without having to standardize much, as shown in RFC 3320 and as > demonstrated nicely in AJAX. If you read German, there is even a > somewhat dated book from 2005 still online at > http://www.teialehrbuch.de/Kostenlose-Kurse/AJAX/ the initial chapters > of which explain why this form of mobile code is winning.) > > Now for 2011: > > What we need to do is acknowledge that AJAX has happened. > > The Web hasn't been "hypertext" for a long time now. With all the > negative (and not so negative) effects, which were nicely tabulated by > Mark Nottingham in this thread. > > What we also need to do is help steer the standards-based foundation > so that it encourages each and every single developer to favor > standards-based (or standards-like) APIs/protocols even in this brave > new world. The persistence of REST in the AJAX world has helped a > lot; other, community-driven standards such as JSON have even been > picked up by the IETF (even though RFC 4627 is labeled Informational). > But, for example the rigid same-origin policy of the existing browser > world makes standards-based APIs less useful though -- AJAX apps can > only use their own servers' APIs, so there is less incentive to offer > AJAX APIs for consumption by other apps/clients. > > The IETF needs to *help* the AJAX world, not close our eyes again. > Help AJAX get better, get more secure. Get more standards-based, more > open. The greedy corporations who sold NATs to fix a problem that could have been fixed the right way, but with less money in their pocket, ruined the Internet for everybody. The same thing is happening today with a bunch of hyperactive people who still do not understand why it is wrong to copy the user input directly in a database query and want their fabulous application deployed in the next 5 minutes. You do understand that we are going back to the telecom model, intelligent network, dumb terminals, lots of money in their pockets, not much in ours, right? Why smart people like the IETF want to be sure that in a close future they will never ever again been able to invent a new application that does not go through the servers of a few powerful corporations answering only to their shareholders is beyond me. Yes, the end to end argument is dying, but what are we doing about this problem, is the right question. Not how a chain saw is a better tool to cut the branch we are perched on. -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From ted.ietf@gmail.com Wed Mar 23 14:32:14 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBBCC3A68DD for ; Wed, 23 Mar 2011 14:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8t3VAvMrv4P for ; Wed, 23 Mar 2011 14:32:13 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 3FD113A676A for ; Wed, 23 Mar 2011 14:32:13 -0700 (PDT) Received: by qyk29 with SMTP id 29so4448902qyk.10 for ; Wed, 23 Mar 2011 14:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=s2tKztZrHmvA8dtDSIuDoJJ0BJR+1la+kZPomlJEZM0=; b=pEx+xwtpFtvIQZ04+55J02kqAn0LvMADv0vKgPzaOlmhfymqYGFdpMPlX9drRtkNWP harqJO5KFPaIOBO0povOo79R/yC6A6oPKfK6/+ZsZALyM5eyDSuE9mmP+pnALmM/GkV1 sM/97scE6w22AH4Ol7xyZ/CUT2/C04+IYnXtc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tasVNCabIH1Iji20qrM9ZUzJH+xzr7QlGMZWSRZFpwo+QlmgSYFb4mQAXlNy/9HPVI fBR7ow6oa5PLar4/SHfZ4Q2wBdtM/+YTCOBUaPnCEywZ+KJtwwwPwICPReOX78ZA/MFq xLpKkhKZFt5K9UH4b+kz65B7rTENtplwbOuCM= MIME-Version: 1.0 Received: by 10.229.214.210 with SMTP id hb18mr6198539qcb.176.1300916027058; Wed, 23 Mar 2011 14:33:47 -0700 (PDT) Received: by 10.229.11.74 with HTTP; Wed, 23 Mar 2011 14:33:46 -0700 (PDT) In-Reply-To: <33EA7EF3-E148-492E-94EF-E95DC6BB7160@tzi.org> References: <4D87612E.3090900@dcrocker.net> <33EA7EF3-E148-492E-94EF-E95DC6BB7160@tzi.org> Date: Wed, 23 Mar 2011 14:33:46 -0700 Message-ID: From: Ted Hardie To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss Subject: Re: [apps-discuss] AJAX is the new NAT X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 21:32:15 -0000 On Wed, Mar 23, 2011 at 1:22 PM, Carsten Bormann wrote: > So, AJAX appears to be the new NAT. So, that's a very good sound bite, but not a very accurate analysis. There are two pieces that have been pointed out it a variety of ways which you seem to miss: =A0Once a node can > control the code on *both* communicating peers, it can do interesting > things without having to standardize much, as shown in RFC 3320 and as > demonstrated nicely in AJAX. The first is that AJAX is a client-server model which ensure that only one of the two nodes can control the code on *both* communicating peers. That has a set of impacts that has been alluded to already in this discussion, and it tends to concentrate power and development effort. You could say that enables innovation, as it creates a pool of libraries and methods that can be re-used by others. You could say it stifles it, because that concentration ignores other fertile ground. It's that second point that is really at issue for the web as a platform for application delivery. Those issues don't relate as strongly to the downloadable code issue as the base protocol having been built for synchronous transfer of relatively small, cachable, discrete objects; it's changed, of course, but the ability to do reasonable things on that basis has its limits. The RTCWeb effort that will be discussed in the upcoming BoF has been trotted out as an example of the beauty of this approach. In fact, it's a great example of the tension. Some aspects of the real-time communication it means to enable can be mediated by web servers fairly easily (the rendezvous and, to some extent, the negotiation). Other aspects, like the audio and video streams passed among peers, still make much more sense delivered as RTP or using RTP-like flows. (NB: my personal opinion; the eventual WG will have to draw the lines itself). In other words, there is a class of client-server protocols for which downloadable code is a good tool. There are other protocol requirements that are, bluntly, ill-met by that. We want innovation to proceed in both classes of problem. Which means enabling the first class *while acknowledging its limits*. Just my two cents, of course. Ted Hardie From jon.peterson@neustar.biz Wed Mar 23 14:47:25 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438233A6957 for ; Wed, 23 Mar 2011 14:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvOp69u-88ok for ; Wed, 23 Mar 2011 14:47:23 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by core3.amsl.com (Postfix) with ESMTP id 931943A6934 for ; Wed, 23 Mar 2011 14:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1300916933; x=1616257663; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=BF20mwOLlSaBCB6BvHPaU S1ErEfXkTNwgj1UZOuxjyc=; b=a2RWn8S+vDPpz1L/N8qVkDHXu6gp0WZmF1Jxl qkaxI8YyNx4Bf2ka7fsf046ECHzYeZH4b3OCLvAa8KyBvfq0g== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.35876581; Wed, 23 Mar 2011 17:48:52 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 23 Mar 2011 17:48:51 -0400 From: "Peterson, Jon" To: Marc Petit-Huguenin Date: Wed, 23 Mar 2011 17:48:50 -0400 Thread-Topic: [apps-discuss] AJAX is the new NAT Thread-Index: AcvppBkO9/IAqVe6TveQShOGTAPxoA== Message-ID: <0BD4169B-AA7F-4265-86C9-F2627074B75C@neustar.biz> References: <4D87612E.3090900@dcrocker.net> <33EA7EF3-E148-492E-94EF-E95DC6BB7160@tzi.org> <4D8A6261.1090308@acm.org> In-Reply-To: <4D8A6261.1090308@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: DfCkrmtEEZByYfKX9et5ZA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Apps Discuss Subject: Re: [apps-discuss] AJAX is the new NAT X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 21:47:25 -0000 I don't think the IETF started working on NATs because we all woke up one m= orning and decided that NATs were a great benefit to the Internet after all= . We started working on NATs because we recognized that market forces well = out of our control had selected NATs as a part of the Internet, whether we = liked it or not. When we do our work, we have a choice: do we want to make = the Internet better, or make better an imaginary network that embodies what= we ideally want the Internet to be? To the argument that javascript leads us back to the innovation-crippling "= telecom model," and that building applications on top of the web is inheren= tly antithetical to end-to-end principles, I can only say that numerous sma= ll developers seem to leverage the web ecosystem today for their business, = and that although there are giants in the web field who collect the lion's = share of the revenue, the same seems to be true in the routing vendor busin= ess, say. If we do our job in the IETF, and build tools that will support s= ecurity, scalability and interoperability in the web space, I don't think t= his design space poses any greater danger to the end-to-end model than we s= ee elsewhere in the IETF. If we neglect our responsibilities in this space,= however, and then probably lower-layer components will adopt non-interoper= able working parts, and we will drift closer to the forecasted "splinternet= ." The discussion in RTC-Web about the potential for interoperability betwe= en different web VoIP services throws this into painful relief. Jon Peterson NeuStar, Inc. On Mar 23, 2011, at 2:13 PM, Marc Petit-Huguenin wrote: > On 03/23/2011 01:22 PM, Carsten Bormann wrote: >> So, AJAX appears to be the new NAT. >>=20 >> (For those who weren't there in the 1990s: the IETF closed their eyes >> with respect to the emerging pervasiveness of NATs and continued >> designing protocols that ignored NATs and then didn't win. >> I was hoping we would never do that again.) >>=20 >> (For those who weren't there in the 2000s: AJAX has indeed made the >> browser a useful application delivery platform. Once a node can >> control the code on *both* communicating peers, it can do interesting >> things without having to standardize much, as shown in RFC 3320 and as >> demonstrated nicely in AJAX. If you read German, there is even a >> somewhat dated book from 2005 still online at >> http://www.teialehrbuch.de/Kostenlose-Kurse/AJAX/ the initial chapters >> of which explain why this form of mobile code is winning.) >>=20 >> Now for 2011: >>=20 >> What we need to do is acknowledge that AJAX has happened. >>=20 >> The Web hasn't been "hypertext" for a long time now. With all the >> negative (and not so negative) effects, which were nicely tabulated by >> Mark Nottingham in this thread. >>=20 >> What we also need to do is help steer the standards-based foundation >> so that it encourages each and every single developer to favor >> standards-based (or standards-like) APIs/protocols even in this brave >> new world. The persistence of REST in the AJAX world has helped a >> lot; other, community-driven standards such as JSON have even been >> picked up by the IETF (even though RFC 4627 is labeled Informational). >> But, for example the rigid same-origin policy of the existing browser >> world makes standards-based APIs less useful though -- AJAX apps can >> only use their own servers' APIs, so there is less incentive to offer >> AJAX APIs for consumption by other apps/clients. >>=20 >> The IETF needs to *help* the AJAX world, not close our eyes again. >> Help AJAX get better, get more secure. Get more standards-based, more >> open. >=20 > The greedy corporations who sold NATs to fix a problem that could have be= en=20 > fixed the right way, but with less money in their pocket, ruined the Inte= rnet=20 > for everybody. The same thing is happening today with a bunch of hyperac= tive=20 > people who still do not understand why it is wrong to copy the user input= =20 > directly in a database query and want their fabulous application deployed= in the=20 > next 5 minutes. You do understand that we are going back to the telecom = model,=20 > intelligent network, dumb terminals, lots of money in their pockets, not = much in=20 > ours, right? Why smart people like the IETF want to be sure that in a cl= ose=20 > future they will never ever again been able to invent a new application t= hat=20 > does not go through the servers of a few powerful corporations answering = only to=20 > their shareholders is beyond me. >=20 > Yes, the end to end argument is dying, but what are we doing about this p= roblem,=20 > is the right question. Not how a chain saw is a better tool to cut the b= ranch=20 > we are perched on. >=20 >=20 > --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From petithug@acm.org Wed Mar 23 15:39:40 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63DE03A6407 for ; Wed, 23 Mar 2011 15:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.16 X-Spam-Level: X-Spam-Status: No, score=-102.16 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IFEYwUT-b3l for ; Wed, 23 Mar 2011 15:39:39 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 31F1B3A63D2 for ; Wed, 23 Mar 2011 15:39:38 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id F186EDBCC046; Wed, 23 Mar 2011 22:41:12 +0000 (UTC) Received: from [192.168.2.225] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id C1C03DBCC044; Wed, 23 Mar 2011 22:41:11 +0000 (UTC) Message-ID: <4D8A7707.9000603@acm.org> Date: Wed, 23 Mar 2011 15:41:11 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.4) Gecko/20100718 Icedove/3.1 MIME-Version: 1.0 To: "Peterson, Jon" References: <4D87612E.3090900@dcrocker.net> <33EA7EF3-E148-492E-94EF-E95DC6BB7160@tzi.org> <4D8A6261.1090308@acm.org> <0BD4169B-AA7F-4265-86C9-F2627074B75C@neustar.biz> In-Reply-To: <0BD4169B-AA7F-4265-86C9-F2627074B75C@neustar.biz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] AJAX is the new NAT X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 22:39:40 -0000 On 03/23/2011 02:48 PM, Peterson, Jon wrote: > > I don't think the IETF started working on NATs because we all woke up one > morning and decided that NATs were a great benefit to the Internet after all. > We started working on NATs because we recognized that market forces well out > of our control had selected NATs as a part of the Internet, whether we liked > it or not. When we do our work, we have a choice: do we want to make the > Internet better, or make better an imaginary network that embodies what we > ideally want the Internet to be? > > To the argument that javascript leads us back to the innovation-crippling > "telecom model," and that building applications on top of the web is > inherently antithetical to end-to-end principles, I can only say that > numerous small developers seem to leverage the web ecosystem today for their > business, and that although there are giants in the web field who collect the > lion's share of the revenue, the same seems to be true in the routing vendor > business, say. If we do our job in the IETF, and build tools that will > support security, scalability and interoperability in the web space, I don't > think this design space poses any greater danger to the end-to-end model than > we see elsewhere in the IETF. If we neglect our responsibilities in this > space, however, and then probably lower-layer components will adopt > non-interoperable working parts, and we will drift closer to the forecasted > "splinternet." The discussion in RTC-Web about the potential for > interoperability between different web VoIP services throws this into painful > relief. This is the trapezoidal model - exactly the same model used by SIP, which makes you unable to call the videophone on my desk, even if they use the same exact codec, SIP and IP protocol. I do not see how adding JavaScript in the mix can improve anything - excepted the bottom line of a few. Besides the role of the IETF should be to increase the relevance of the end to end argument, not just merely verifying that a new design does not pose a danger to it. > > > On Mar 23, 2011, at 2:13 PM, Marc Petit-Huguenin wrote: > >> On 03/23/2011 01:22 PM, Carsten Bormann wrote: >>> So, AJAX appears to be the new NAT. >>> >>> (For those who weren't there in the 1990s: the IETF closed their eyes >>> with respect to the emerging pervasiveness of NATs and continued >>> designing protocols that ignored NATs and then didn't win. I was hoping >>> we would never do that again.) >>> >>> (For those who weren't there in the 2000s: AJAX has indeed made the >>> browser a useful application delivery platform. Once a node can control >>> the code on *both* communicating peers, it can do interesting things >>> without having to standardize much, as shown in RFC 3320 and as >>> demonstrated nicely in AJAX. If you read German, there is even a >>> somewhat dated book from 2005 still online at >>> http://www.teialehrbuch.de/Kostenlose-Kurse/AJAX/ the initial chapters of >>> which explain why this form of mobile code is winning.) >>> >>> Now for 2011: >>> >>> What we need to do is acknowledge that AJAX has happened. >>> >>> The Web hasn't been "hypertext" for a long time now. With all the >>> negative (and not so negative) effects, which were nicely tabulated by >>> Mark Nottingham in this thread. >>> >>> What we also need to do is help steer the standards-based foundation so >>> that it encourages each and every single developer to favor >>> standards-based (or standards-like) APIs/protocols even in this brave new >>> world. The persistence of REST in the AJAX world has helped a lot; >>> other, community-driven standards such as JSON have even been picked up >>> by the IETF (even though RFC 4627 is labeled Informational). But, for >>> example the rigid same-origin policy of the existing browser world makes >>> standards-based APIs less useful though -- AJAX apps can only use their >>> own servers' APIs, so there is less incentive to offer AJAX APIs for >>> consumption by other apps/clients. >>> >>> The IETF needs to *help* the AJAX world, not close our eyes again. Help >>> AJAX get better, get more secure. Get more standards-based, more open. >> >> The greedy corporations who sold NATs to fix a problem that could have >> been fixed the right way, but with less money in their pocket, ruined the >> Internet for everybody. The same thing is happening today with a bunch of >> hyperactive people who still do not understand why it is wrong to copy the >> user input directly in a database query and want their fabulous application >> deployed in the next 5 minutes. You do understand that we are going back >> to the telecom model, intelligent network, dumb terminals, lots of money in >> their pockets, not much in ours, right? Why smart people like the IETF >> want to be sure that in a close future they will never ever again been able >> to invent a new application that does not go through the servers of a few >> powerful corporations answering only to their shareholders is beyond me. >> >> Yes, the end to end argument is dying, but what are we doing about this >> problem, is the right question. Not how a chain saw is a better tool to >> cut the branch we are perched on. >> >> >> -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional >> email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org >> _______________________________________________ apps-discuss mailing list >> apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss > -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From stpeter@stpeter.im Wed Mar 23 20:08:25 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2443A67E9 for ; Wed, 23 Mar 2011 20:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Jl1Veh-Qeou for ; Wed, 23 Mar 2011 20:08:24 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E0C0E3A67D2 for ; Wed, 23 Mar 2011 20:08:23 -0700 (PDT) Received: from squire.local (dsl-251-69.dynamic-dsl.frii.net [216.17.251.69]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 803C840022; Wed, 23 Mar 2011 21:11:09 -0600 (MDT) Message-ID: <4D8AB5FC.9050500@stpeter.im> Date: Wed, 23 Mar 2011 21:09:48 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Scott Brim References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040906040702060600050202" Cc: Pete Resnick , Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 03:08:25 -0000 This is a cryptographically signed message in MIME format. --------------ms040906040702060600050202 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/22/11 7:41 AM, Scott Brim wrote: > Pete: Yes, amusing. I want to digress on one thing you said ... >=20 > On Mon, Mar 21, 2011 at 23:48, Pete Resnick wro= te: >> There are two obvious drivers of this evolution: First and foremost is= the >> continuing lack of end-to-end connectivity in the network. This is due= to >> the presence of NATs and assorted firewall nonsense that makes non-tun= neled >> applications harder and harder to deploy. But the second driving force= is >> the more insidious one: economics. The economics of the Internet are >> currently being driven by big players consolidating the network, pushi= ng as >> much as they can into servers so that they can control both the data a= nd the >> user experience for applications on the Internet. This of course is no= t in >> the interest of end users, except insofar as the "big players" are end= users >> with large economic interests. The more centralized the data becomes, = the >> more dependent users are on the "big players", the less innovation in >> applications can take place, and the less stable the Internet is as a = whole. >=20 > I think the causality is turned around several times in these sentences= =2E >=20 > First, NATs did not force people into client-server mode. If people > had had a strong desire for end-to-end transparency, we would have > more of it. NATs started appearing and they didn't cut off anything > people saw as vital. Some apps (e.g. FTP and Skype) adapted. It is > now hard to preserve peer-to-peer, and get away from client-server, > partly because of NATs but mainly because the vast majority of people > find client-server to be convenient. They like services. If there > was more demand for transparency you would see more of it. >=20 > Second, yes economics, and yes the big boys are pushing to control > more, but that doesn't mean it is not in the interest of end users. > They like services. Scott, I think there is a great deal of truth in what you say. The big services have become big in large measure because most people seem to prefer identifiable services. Perhaps it's the herd instinct or the human inability to hold too many things in mind at once or the simplicity of signing up for something and letting someone else handle the details. Whatever the reason, most people don't want to run their own services -- it's much easier to visit a website, and tell people that you're "on", a popular email or IM or blogging or microblogging or voice or video service than it is to install and maintain postfix or Prosody or WordPress or laconica or Asterisk or Yate on the server side plus Thunderbird or Pidgin or Jitsi (etc.) on the client side (let alone the whole stack of OS and DNS and databases and registered domains and certificates and all the rest). So yes, services are easy and popular with end users. As a result, the companies that offer those services often become large and even dominant on the 'net. At that point some of the dynamics that Pete mentioned come into play, but I don't think they are the root cause. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms040906040702060600050202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMy NDAzMDk0OFowIwYJKoZIhvcNAQkEMRYEFGvclZeBgruqGrgIEqxmPAnyCq9gMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCI3EgFCTMI51f83vWAX1F6r5OkpmXwyuTbaod94bylb8N4kCGGRQOa4pmU u2oxLS3vtP6drjCedvpA3ptqhbMcDTY97Us5M1ginnu8t5407yYKGmy2DBEA7hzxlNPYzWRv 4sVAAD0HeD9pYHjmH4cOpiA1uPmWXfk6gMGcRC9OfPngIGpDfxMETfcuQGnPQxF3cpj9D222 nQ/lrCaDzJLT+eJUMuur5hIjTo9UYHDcSHXU/YGT5HxfUjGmxQPjro7Qp+CeQFAYoyVo975T 3OYLG2FkI8SwhfZX4zN/DQD+8ie8zFYfm+w0KVXAEmzEqz51CtrBYzzxFe+t8favkUsYAAAA AAAA --------------ms040906040702060600050202-- From scott.brim@gmail.com Wed Mar 23 20:46:44 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B923A67DF for ; Wed, 23 Mar 2011 20:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z72ooGmNrjEM for ; Wed, 23 Mar 2011 20:46:43 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 674093A67D9 for ; Wed, 23 Mar 2011 20:46:42 -0700 (PDT) Received: by iwl42 with SMTP id 42so10870619iwl.31 for ; Wed, 23 Mar 2011 20:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oEVCAPXpMwNUtRM6sp3E0WMhsdJEjVVlkwDiNc77p5o=; b=LX/wfS+BVdo0FJ5q4+TwWFEhH3xX06JLj3/vzN4HerePfmxT4NeuIvzxsIV35flJLF g9kIs7r+4bPpMRdB7SEm04qGxKrJ+F/cXc/hYSV32H3Qz9fxf3fleW2hZH6Q+16BNhgn 8u01d5bBWJrNQ4/miuamr4vX8OwPHE3Yp7kMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=mLAQkrjFYtszyrfxMhOLfmZYdcdxcRt9bS29flDnWHsDzckjo0sHr2ed9Kt4FQCnaa yqgfHvyWgJY+4CgpbJC+JgJh82YsLUVOS0FYRwkVrD/OZwYjCAapV0chYiES4Sab2t+U rixc9R4pnw4jfGG8CtjalooRcVcDdhVmijR34= Received: by 10.42.117.68 with SMTP id s4mr2824060icq.348.1300938496516; Wed, 23 Mar 2011 20:48:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.165.65 with HTTP; Wed, 23 Mar 2011 20:45:32 -0700 (PDT) In-Reply-To: <4D8AB5FC.9050500@stpeter.im> References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D8AB5FC.9050500@stpeter.im> From: Scott Brim Date: Wed, 23 Mar 2011 23:45:32 -0400 Message-ID: To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=485b397dd109f5a3f7049f32580d Cc: Pete Resnick , Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 03:46:44 -0000 --485b397dd109f5a3f7049f32580d Content-Type: text/plain; charset=ISO-8859-1 I hope we can have a real discussion in Prague, without too much grandstanding. See you all too soon. Scott On Wed, Mar 23, 2011 at 23:09, Peter Saint-Andre wrote: > On 3/22/11 7:41 AM, Scott Brim wrote: > > Pete: Yes, amusing. I want to digress on one thing you said ... > > > > On Mon, Mar 21, 2011 at 23:48, Pete Resnick > wrote: > >> There are two obvious drivers of this evolution: First and foremost is > the > >> continuing lack of end-to-end connectivity in the network. This is due > to > >> the presence of NATs and assorted firewall nonsense that makes > non-tunneled > >> applications harder and harder to deploy. But the second driving force > is > >> the more insidious one: economics. The economics of the Internet are > >> currently being driven by big players consolidating the network, pushing > as > >> much as they can into servers so that they can control both the data and > the > >> user experience for applications on the Internet. This of course is not > in > >> the interest of end users, except insofar as the "big players" are end > users > >> with large economic interests. The more centralized the data becomes, > the > >> more dependent users are on the "big players", the less innovation in > >> applications can take place, and the less stable the Internet is as a > whole. > > > > I think the causality is turned around several times in these sentences. > > > > First, NATs did not force people into client-server mode. If people > > had had a strong desire for end-to-end transparency, we would have > > more of it. NATs started appearing and they didn't cut off anything > > people saw as vital. Some apps (e.g. FTP and Skype) adapted. It is > > now hard to preserve peer-to-peer, and get away from client-server, > > partly because of NATs but mainly because the vast majority of people > > find client-server to be convenient. They like services. If there > > was more demand for transparency you would see more of it. > > > > Second, yes economics, and yes the big boys are pushing to control > > more, but that doesn't mean it is not in the interest of end users. > > They like services. > > Scott, I think there is a great deal of truth in what you say. The big > services have become big in large measure because most people seem to > prefer identifiable services. Perhaps it's the herd instinct or the > human inability to hold too many things in mind at once or the > simplicity of signing up for something and letting someone else handle > the details. Whatever the reason, most people don't want to run their > own services -- it's much easier to visit a website, and tell people > that you're "on", a popular email or IM or blogging or microblogging or > voice or video service than it is to install and maintain postfix or > Prosody or WordPress or laconica or Asterisk or Yate on the server side > plus Thunderbird or Pidgin or Jitsi (etc.) on the client side (let alone > the whole stack of OS and DNS and databases and registered domains and > certificates and all the rest). > > So yes, services are easy and popular with end users. As a result, the > companies that offer those services often become large and even dominant > on the 'net. At that point some of the dynamics that Pete mentioned come > into play, but I don't think they are the root cause. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > --485b397dd109f5a3f7049f32580d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I hope we can have a real discussion in Prague, = without too much grandstanding.

<= div class=3D"gmail_quote">See you all too soon.

Scott
=
On Wed, Mar 23, 2011 at 23:09, Peter S= aint-Andre <stpe= ter@stpeter.im> wrote:
On 3/22/1= 1 7:41 AM, Scott Brim wrote:
> Pete: Yes, amusing. =A0I want to digress on one thing you said ...
>
> On Mon, Mar 21, 2011 at 23:48, Pete Resnick <presnick@qualcomm.com> wrote:
>> There are two obvious drivers of this evolution: First and foremos= t is the
>> continuing lack of end-to-end connectivity in the network. This is= due to
>> the presence of NATs and assorted firewall nonsense that makes non= -tunneled
>> applications harder and harder to deploy. But the second driving f= orce is
>> the more insidious one: economics. The economics of the Internet a= re
>> currently being driven by big players consolidating the network, p= ushing as
>> much as they can into servers so that they can control both the da= ta and the
>> user experience for applications on the Internet. This of course i= s not in
>> the interest of end users, except insofar as the "big players= " are end users
>> with large economic interests. The more centralized the data becom= es, the
>> more dependent users are on the "big players", the less = innovation in
>> applications can take place, and the less stable the Internet is a= s a whole.
>
> I think the causality is turned around several times in these sentence= s.
>
> First, NATs did not force people into client-server mode. =A0If people=
> had had a strong desire for end-to-end transparency, we would have
> more of it. =A0NATs started appearing and they didn't cut off anyt= hing
> people saw as vital. =A0Some apps (e.g. FTP and Skype) adapted. =A0It = is
> now hard to preserve peer-to-peer, and get away from client-server, > partly because of NATs but mainly because the vast majority of people<= br> > find client-server to be convenient. =A0They like services. =A0If ther= e
> was more demand for transparency you would see more of it.
>
> Second, yes economics, and yes the big boys are pushing to control
> more, but that doesn't mean it is not in the interest of end users= .
> They like services.

Scott, I think there is a great deal of truth in what you say. = The big
services have become big in large measure because most people seem to
prefer identifiable services. Perhaps it's the herd instinct or the
human inability to hold too many things in mind at once or the
simplicity of signing up for something and letting someone else handle
the details. Whatever the reason, most people don't want to run their own services -- it's much easier to visit a website, and tell people that you're "on", a popular email or IM or blogging or microb= logging or
voice or video service than it is to install and maintain postfix or
Prosody or WordPress or laconica or Asterisk or Yate on the server side
plus Thunderbird or Pidgin or Jitsi (etc.) on the client side (let alone the whole stack of OS and DNS and databases and registered domains and
certificates and all the rest).

So yes, services are easy and popular with end users. As a result, the
companies that offer those services often become large and even dominant on the 'net. At that point some of the dynamics that Pete mentioned com= e
into play, but I don't think they are the root cause.

Peter

--
Peter Saint-Andre
https://stpeter.im/



--485b397dd109f5a3f7049f32580d-- From hannes.tschofenig@gmx.net Thu Mar 24 05:03:40 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932893A6841 for ; Thu, 24 Mar 2011 05:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdrEL78Iv1AJ for ; Thu, 24 Mar 2011 05:03:39 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 3C55C3A680B for ; Thu, 24 Mar 2011 05:03:39 -0700 (PDT) Received: (qmail invoked by alias); 24 Mar 2011 12:05:12 -0000 Received: from eduroam-cl-171.feld.cvut.cz (EHLO eduroam-cl-171.feld.cvut.cz) [147.32.223.171] by mail.gmx.net (mp007) with SMTP; 24 Mar 2011 13:05:12 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/TaTNMt6vT1VgHwEg39wWCrMlsgyw0Q7hf+1noIf Knwmwo6vwwy4aT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <6266.1300784475.434865@puncture> Date: Thu, 24 Mar 2011 14:05:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3F2B4909-DE99-4189-98BC-5E9DDCE3CAC5@gmx.net> References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D885482.2050006@ninebynine.org> <6266.1300784475.434865@puncture> To: Dave Cridland X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Pete Resnick , Graham Klyne , Dave CROCKER , General discussion of application-layer protocols Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 12:03:40 -0000 On Mar 22, 2011, at 11:01 AM, Dave Cridland wrote: > I would love to see a world where the Web does what it's good at - = that is, delivering static content, including application code and UI = content - and protocols such as XMPP do what they're good at - that is, = providing dynamic data between known federated entities. How likely do you think is this going to happen? From dave@cridland.net Thu Mar 24 07:34:32 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A13B3A68E1 for ; Thu, 24 Mar 2011 07:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-Qyr0TUSPsm for ; Thu, 24 Mar 2011 07:34:31 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 3682B3A6869 for ; Thu, 24 Mar 2011 07:34:31 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 30007116808D; Thu, 24 Mar 2011 14:36:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiVQBOSlotUR; Thu, 24 Mar 2011 14:35:55 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 1AAFC1168067; Thu, 24 Mar 2011 14:35:55 +0000 (GMT) References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D885482.2050006@ninebynine.org> <6266.1300784475.434865@puncture> <3F2B4909-DE99-4189-98BC-5E9DDCE3CAC5@gmx.net> In-Reply-To: <3F2B4909-DE99-4189-98BC-5E9DDCE3CAC5@gmx.net> MIME-Version: 1.0 Message-Id: <4126.1300977355.111049@puncture> Date: Thu, 24 Mar 2011 14:35:55 +0000 From: Dave Cridland To: Hannes Tschofenig , Graham Klyne , Dave CROCKER , General discussion of application-layer protocols , Pete Resnick Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 14:34:32 -0000 On Thu Mar 24 12:05:09 2011, Hannes Tschofenig wrote: > > On Mar 22, 2011, at 11:01 AM, Dave Cridland wrote: > > > I would love to see a world where the Web does what it's good at > - that is, delivering static content, including application code > and UI content - and protocols such as XMPP do what they're good at > - that is, providing dynamic data between known federated entities. > > How likely do you think is this going to happen? Sadly, probably very unlikely. Who's going to provide the kind of leadership we'd need to have a coherent architecture for the internet, instead of one that emerges driven by a few service providers? Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From scott.brim@gmail.com Thu Mar 24 07:41:47 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CDBD28C11A for ; Thu, 24 Mar 2011 07:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.58 X-Spam-Level: X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Brg080JN7e0w for ; Thu, 24 Mar 2011 07:41:46 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 8110228C0DD for ; Thu, 24 Mar 2011 07:41:46 -0700 (PDT) Received: by iyi12 with SMTP id 12so34057iyi.31 for ; Thu, 24 Mar 2011 07:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3Mxvr5QQbqT4ohHnPZDDAa+FN20heMBAQ8H4FHq7Q14=; b=Shwq6WInAQpSIN1aR6LTE8zqQC9iuae2mPscdDPKSAiKVnwI1jSdz1wM1fjuLD+uPx hyl7I3LHCBoV7r1QywgEHuEp0v98T6tjd6wf9g1kLajKu3cZYqwLIjYA56k7VzRWSTgw /fkw1ymA9ucIeiwN/DM7Yvr9qLzembn04/U20= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=kxIAaYcTExx5jqogeEBtsLyZhS7ucSD+qpwsY6acZC2C+WWQQ05rqQyqYzVrBIJUEj Ds7sBBXIlJXKAyytqIVPf+umaFW/R1naslno57eyISE37lgvXzM3e0KCEsq0HZ3u37z1 w3dMb0Ygo1/J7Wn0a9X3h1lwCxF4lbkO0ycKg= Received: by 10.42.133.72 with SMTP id g8mr13627088ict.80.1300977801066; Thu, 24 Mar 2011 07:43:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.165.65 with HTTP; Thu, 24 Mar 2011 07:43:01 -0700 (PDT) In-Reply-To: <4126.1300977355.111049@puncture> References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D885482.2050006@ninebynine.org> <6266.1300784475.434865@puncture> <3F2B4909-DE99-4189-98BC-5E9DDCE3CAC5@gmx.net> <4126.1300977355.111049@puncture> From: Scott Brim Date: Thu, 24 Mar 2011 10:43:01 -0400 Message-ID: To: Dave Cridland Content-Type: text/plain; charset=ISO-8859-1 Cc: Pete Resnick , Graham Klyne , Dave CROCKER , General discussion of application-layer protocols Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 14:41:47 -0000 On Thu, Mar 24, 2011 at 10:35, Dave Cridland wrote: >> On Mar 22, 2011, at 11:01 AM, Dave Cridland wrote: >> > I would love to see a world where the Web does what it's good at - that >> > is, delivering static content, including application code and UI content - >> > and protocols such as XMPP do what they're good at - that is, providing >> > dynamic data between known federated entities. >> >> How likely do you think is this going to happen? > > Sadly, probably very unlikely. Who's going to provide the kind of leadership > we'd need to have a coherent architecture for the internet, instead of one > that emerges driven by a few service providers? > > Dave. I believe it was in Munich, oh so many years ago, that Dave Clark said "architect the inevitable". Yes we preserve the model of peer-to-peer symmetric communications. We know it and other principles are fundamental necessities for future adaptability. At the same time we engineer all sorts of stuff that is just subsets, that does not follow our fundamental principles completely, because it meets users' needs right now. From presnick@qualcomm.com Thu Mar 24 07:53:36 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1DA83A68E2 for ; Thu, 24 Mar 2011 07:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.595 X-Spam-Level: X-Spam-Status: No, score=-106.595 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR4VWuBpUbJO for ; Thu, 24 Mar 2011 07:53:35 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id CC1803A68DC for ; Thu, 24 Mar 2011 07:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1300978509; x=1332514509; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: x-originating-ip; z=Message-ID:=20<4D8B5AB7.5030202@qualcomm.com>|Date:=20Th u,=2024=20Mar=202011=2014:52:39=20+0000|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Scott=20Brim=20|CC:=20Peter=20Saint-Andre=20, =20Apps=20Discuss=0D=0A=09 |Subject:=20Re:=20[apps-discuss]=20IETF=20technical=20ple nary:=20the=20end=20of=20application=0D=0A=20protocols |References:=20<4D87612E.3090900@dcrocker.net>=20<4D881C0 4.2080406@qualcomm.com>=09=09<4D8AB5FC.9050500@stp eter.im>=20|In-Reply-To:=20|Content-Type:=20mul tipart/alternative=3B=0D=0A=09boundary=3D"------------080 901040301000601070009"|X-Originating-IP:=20[172.30.48.1]; bh=hW6zeEhzg8D+Rg1CNiDQ1x7PJ6ah1molxwEY77UX7Sk=; b=xfW+43FZDUCWwaC4Ju1MxBteTnyo5P/872t/nsG4PVZSG+sJBlI6z/7F PKonaoE/OasfnIe94FA41wV4grCP2DI398XEfIMG5VMZXGgjAhNP7y2e0 woUzGgjTs5RHVMleS8ZUGK/w/Nc61/J5BJ+ZptBc+JCtZYtzfrq0ptGdO 0=; X-IronPort-AV: E=McAfee;i="5400,1158,6294"; a="81820188" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 24 Mar 2011 07:55:09 -0700 X-IronPort-AV: E=Sophos;i="4.63,237,1299484800"; d="scan'208,217";a="127180271" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 24 Mar 2011 07:55:08 -0700 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 24 Mar 2011 07:52:50 -0700 Message-ID: <4D8B5AB7.5030202@qualcomm.com> Date: Thu, 24 Mar 2011 14:52:39 +0000 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Scott Brim References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D8AB5FC.9050500@stpeter.im> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080901040301000601070009" X-Originating-IP: [172.30.48.1] Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 14:53:36 -0000 --------------080901040301000601070009 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 3/24/11 3:45 AM, Scott Brim wrote: > On Wed, Mar 23, 2011 at 23:09, Peter Saint-Andre > wrote: > > On 3/22/11 7:41 AM, Scott Brim wrote: > > I think the causality is turned around several times in these > sentences. > > > > First, NATs did not force people into client-server mode. If people > > had had a strong desire for end-to-end transparency, we would have > > more of it. NATs started appearing and they didn't cut off anything > > people saw as vital. Some apps (e.g. FTP and Skype) adapted. It is > > now hard to preserve peer-to-peer, and get away from client-server, > > partly because of NATs but mainly because the vast majority of > people > > find client-server to be convenient. They like services. If there > > was more demand for transparency you would see more of it. > I think this is revisionist history. Let's separate out a couple of things: 1. Most people came to the Internet via the web. They never had much exposure to, let alone use for, other facilities provided. So they think about things through a web lens. NATs coming in didn't *have* to force people into client-server mode; it simply kept them there and kept them from seeing the other possibilities. 2. Don't confuse market forces for what people actually desire. People don't know what they want or desire until they understand what is available. If we only look to what people find desirable or what they view as vital *now*, nothing new is ever created. Did people desire forms of communication other than what AT&T provided to them with POTS? And really, I challenge you to come up with some evidence that people find client-server to be convenient. I hear people complain about their web-app experiences all of the time. Do people actually want client-server, or do they simply not understand what they could have? 3. We have been spending literally years coming up with ways to work through server-based services (and through NATs) to provide people with peer-to-peer services. Indeed, several of the technologies that seem to be driving this discussion (WebSockets, RTCWEB, HYBI) are in response to a stated need for Javascript applications to talk peer-to-peer, bypassing the client-server model you say people desire. That seems to go against the position that people aren't interested in peer-to-peer applications. If so, we're just talking about delivery model and underlying protocols, not people's desires. 4. Finally, be careful about layer violations. Whatever people want, it is likely above layer 7. Even if we could establish that people like the idea of using a server-based model for their interactions (of which I am not convinced), that doesn't mean that the underlying network ought to reflect that architecture. In fact, it's probably a really bad idea. People liked (still like) the idea of point-to-point connections for their telephones. That doesn't mean that we should devote ourselves to moving away from packet switching. When we bump into circuit switching, we tunnel through it or route around it. Similar principles ought to apply here. > > Second, yes economics, and yes the big boys are pushing to control > > more, but that doesn't mean it is not in the interest of end users. > > They like services. > > Scott, I think there is a great deal of truth in what you say. The big > services have become big in large measure because most people seem to > prefer identifiable services. Perhaps it's the herd instinct or the > human inability to hold too many things in mind at once or the > simplicity of signing up for something and letting someone else handle > the details. > I think Peter is on to something. It is I think more about the herd instinct, if not a more hierarchical instinct. We don't seem to like anarchy. We like someone "in charge" to take care of things. However: > Whatever the reason, most people don't want to run their > own services -- it's much easier to visit a website, and tell people > that you're "on", a popular email or IM or blogging or > microblogging or > voice or video service than it is to install and maintain postfix or > Prosody or WordPress or laconica or Asterisk or Yate on the server > side > plus Thunderbird or Pidgin or Jitsi (etc.) on the client side (let > alone > the whole stack of OS and DNS and databases and registered domains and > certificates and all the rest). > People do seem fully capable to grasp "Here is my phone number, you can reach me here" and do at least that particular kind of peer-to-peer communication. There is no reason that IM or email or blogging *have* to be a service; it's a remnant of being pre-disposed to client-server models (including, BTW, DNS). > So yes, services are easy and popular with end users. As a result, the > companies that offer those services often become large and even > dominant > on the 'net. At that point some of the dynamics that Pete > mentioned come > into play, but I don't think they are the root cause. > Chicken/egg. There's great incentive for those large entities to maintain the model that is making them money. I'm not convinced it's user wishes that keep things the way they are, anymore than I think it's user wishes that keep certain things on television. You can get people to watch all sorts of nonsense TV, but that doesn't (in and of itself) mean that they actually aspire to watch it. > I hope we can have a real discussion in Prague, without too much > grandstanding. It's going to be difficult. I can say for myself that I've been pushing for a deeper discussion (and getting it in many places), but the "death of application protocols predicted" tone of the abstract was a bit of grandstanding itself, IMO. Not too conducive to rational conversation. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 --------------080901040301000601070009 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 3/24/11 3:45 AM, Scott Brim wrote:
On Wed, Mar 23, 2011 at 23:09, Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 3/22/11 7:41 AM, Scott Brim wrote:
> I think the causality is turned around several times in these sentences.
>
> First, NATs did not force people into client-server mode.  If people
> had had a strong desire for end-to-end transparency, we would have
> more of it.  NATs started appearing and they didn't cut off anything
> people saw as vital. Some apps (e.g. FTP and Skype) adapted.  It is
> now hard to preserve peer-to-peer, and get away from client-server,
> partly because of NATs but mainly because the vast majority of people
> find client-server to be convenient.  They like services.  If there
> was more demand for transparency you would see more of it.

I think this is revisionist history. Let's separate out a couple of things:

1. Most people came to the Internet via the web. They never had much exposure to, let alone use for, other facilities provided. So they think about things through a web lens. NATs coming in didn't *have* to force people into client-server mode; it simply kept them there and kept them from seeing the other possibilities.

2. Don't confuse market forces for what people actually desire. People don't know what they want or desire until they understand what is available. If we only look to what people find desirable or what they view as vital *now*, nothing new is ever created. Did people desire forms of communication other than what AT&T provided to them with POTS? And really, I challenge you to come up with some evidence that people find client-server to be convenient. I hear people complain about their web-app experiences all of the time. Do people actually want client-server, or do they simply not understand what they could have?

3. We have been spending literally years coming up with ways to work through server-based services (and through NATs) to provide people with peer-to-peer services. Indeed, several of the technologies that seem to be driving this discussion (WebSockets, RTCWEB, HYBI) are in response to a stated need for Javascript applications to talk peer-to-peer, bypassing the client-server model you say people desire. That seems to go against the position that people aren't interested in peer-to-peer applications. If so, we're just talking about delivery model and underlying protocols, not people's desires.

4. Finally, be careful about layer violations. Whatever people want, it is likely above layer 7. Even if we could establish that people like the idea of using a server-based model for their interactions (of which I am not convinced), that doesn't mean that the underlying network ought to reflect that architecture. In fact, it's probably a really bad idea. People liked (still like) the idea of point-to-point connections for their telephones. That doesn't mean that we should devote ourselves to moving away from packet switching. When we bump into circuit switching, we tunnel through it or route around it. Similar principles ought to apply here.

> Second, yes economics, and yes the big boys are pushing to control
> more, but that doesn't mean it is not in the interest of end users.
> They like services.

Scott, I think there is a great deal of truth in what you say. The big
services have become big in large measure because most people seem to
prefer identifiable services. Perhaps it's the herd instinct or the
human inability to hold too many things in mind at once or the
simplicity of signing up for something and letting someone else handle
the details.

I think Peter is on to something. It is I think more about the herd instinct, if not a more hierarchical instinct. We don't seem to like anarchy. We like someone "in charge" to take care of things. However:

Whatever the reason, most people don't want to run their
own services -- it's much easier to visit a website, and tell people
that you're "on", a popular email or IM or blogging or microblogging or
voice or video service than it is to install and maintain postfix or
Prosody or WordPress or laconica or Asterisk or Yate on the server side
plus Thunderbird or Pidgin or Jitsi (etc.) on the client side (let alone
the whole stack of OS and DNS and databases and registered domains and
certificates and all the rest).

People do seem fully capable to grasp "Here is my phone number, you can reach me here" and do at least that particular kind of peer-to-peer communication. There is no reason that IM or email or blogging *have* to be a service; it's a remnant of being pre-disposed to client-server models (including, BTW, DNS).

So yes, services are easy and popular with end users. As a result, the
companies that offer those services often become large and even dominant
on the 'net. At that point some of the dynamics that Pete mentioned come
into play, but I don't think they are the root cause.

Chicken/egg. There's great incentive for those large entities to maintain the model that is making them money. I'm not convinced it's user wishes that keep things the way they are, anymore than I think it's user wishes that keep certain things on television. You can get people to watch all sorts of nonsense TV, but that doesn't (in and of itself) mean that they actually aspire to watch it.

I hope we can have a real discussion in Prague, without too much grandstanding.

It's going to be difficult. I can say for myself that I've been pushing for a deeper discussion (and getting it in many places), but the "death of application protocols predicted" tone of the abstract was a bit of grandstanding itself, IMO. Not too conducive to rational conversation.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
--------------080901040301000601070009-- From dave@cridland.net Thu Mar 24 08:34:47 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE3C928C128 for ; Thu, 24 Mar 2011 08:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11I1DCsXhjtR for ; Thu, 24 Mar 2011 08:34:46 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 2D71628C0F0 for ; Thu, 24 Mar 2011 08:34:46 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 8401F116808F; Thu, 24 Mar 2011 15:36:19 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltULVRzyJu9t; Thu, 24 Mar 2011 15:36:17 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 01E36116808D; Thu, 24 Mar 2011 15:36:17 +0000 (GMT) References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D885482.2050006@ninebynine.org> <6266.1300784475.434865@puncture> <3F2B4909-DE99-4189-98BC-5E9DDCE3CAC5@gmx.net> <4126.1300977355.111049@puncture> In-Reply-To: MIME-Version: 1.0 Message-Id: <4126.1300980977.007329@puncture> Date: Thu, 24 Mar 2011 15:36:17 +0000 From: Dave Cridland To: Scott Brim , Hannes Tschofenig , Graham Klyne , Dave CROCKER , General discussion of application-layer protocols , Pete Resnick Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 15:34:48 -0000 On Thu Mar 24 14:43:01 2011, Scott Brim wrote: > I believe it was in Munich, oh so many years ago, that Dave Clark > said > "architect the inevitable". Yes we preserve the model of > peer-to-peer > symmetric communications. We know it and other principles are > fundamental necessities for future adaptability. At the same time > we > engineer all sorts of stuff that is just subsets, that does not > follow > our fundamental principles completely, because it meets users' needs > right now. There is an immense distinction between pragmatically bending rules in the short term whilst clearly maintaining a single overriding architectural vision to aspire to, and throwing away years of architectural choices because a handful of very large near-monopolies would find it more convenient if they had total control over every aspect of the user's experience. On the subject of the thriving ecosystem of third-party apps clinging on for dear life to these rumbling giants hoping to compete by pretending that an "API" under the sole control of a single entity is, somehow, equivalent to a viable open standard - as Hannes et al are trying to persuade us - there is some interesting reading which was kindly produced a couple of weeks ago: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/c82cd59c7a87216a?pli=1 Anyone present who doesn't choke at the "Twitter is a network" line should really wonder what they're doing here. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From dhc@dcrocker.net Thu Mar 24 08:46:30 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A56F28C0D0 for ; Thu, 24 Mar 2011 08:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmCF+0A3jEsO for ; Thu, 24 Mar 2011 08:46:29 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 6DC9E28C0CE for ; Thu, 24 Mar 2011 08:46:29 -0700 (PDT) Received: from [10.12.208.53] ([217.194.73.178]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p2OFltFB007327 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 24 Mar 2011 08:48:03 -0700 Message-ID: <4D8B679A.4010708@dcrocker.net> Date: Thu, 24 Mar 2011 16:47:38 +0100 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Pete Resnick References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D8AB5FC.9050500@stpeter.im> <4D8B5AB7.5030202@qualcomm.com> In-Reply-To: <4D8B5AB7.5030202@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 24 Mar 2011 08:48:04 -0700 (PDT) Cc: Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 15:46:30 -0000 On 3/24/2011 3:52 PM, Pete Resnick wrote: > 1. Most people came to the Internet via the web. They never had much exposure > to, let alone use for, other facilities provided. So they think about things > through a web lens. NATs coming in didn't *have* to force people into > client-server mode; it simply kept them there and kept them from seeing the > other possibilities. I'll suggest that NAT's are irrelevant to the choice of client/server vs. peer-to-peer. I used to assume that peer-to-peer meant "direct" exchange between peers but it was pointed out to me that it merely refers to either being able to initiate an exchange. Witness instant messaging. That IM and such services are /mediated/ means that below the /logically/ direct exchange there is a relaying service. This is the same as pretending that TCP is "direct" in spite of having the layer below mediate. The appeal of client/server is simplicity. Distributed architecture are more difficult to design, build, debug and operate. Vendors prefer stovepipe solutions because it improves the vendor's control and it makes their life simpler. Venders do not typically engage in open and distributed systems because they like them. They engage in them due to market forces. DEC, IBM and Microsoft gave up their proprietary network protocols only when it was clear they had no choice. At that, vendors still try to add proprietary tweaks with the (sometimes valid) claimes of improved functionality, but also with the awareness that it buys them back some user lock-in. > 2. Don't confuse market forces for what people actually desire. People don't > know what they want or desire until they understand what is available. If we +1 > 4. Finally, be careful about layer violations. Whatever people want, it is > likely above layer 7. Or, rather, within it. Layer 7 is increasingly looking as if it might have 7 sub-layers... >> Whatever the reason, most people don't want to run their >> own services -- it's much easier to visit a website, and tell people ... > People do seem fully capable to grasp "Here is my phone number, you can reach me > here" and do at least that particular kind of peer-to-peer communication. There > is no reason that IM or email or blogging *have* to be a service; it's a remnant > of being pre-disposed to client-server models (including, BTW, DNS). This is almost certainly not correct. There are operational details required for these things to be useful. Someone has to do that work. It takes effort and skill. An indicator of market maturation is that end users can, do and even must offload much of that effort and skill to others called experts and/or providers. The critical questions are 1) Do they have a reasonable choice of who they can offload to? (competition) 2) Can the user switch to a new service easily? (vs. lock-in) 3) Is there reasonable interoperability among the providers? (interconnect) 4) Is there reasonable interoperability among the users. (reachability and data exchange.) > Chicken/egg. There's great incentive for those large entities to maintain the > model that is making them money. I'm not convinced it's user wishes that keep > things the way they are, +1 >> I hope we can have a real discussion in Prague, without too much grandstanding. > > It's going to be difficult. I can say for myself that I've been pushing for a > deeper discussion (and getting it in many places), but the "death of application > protocols predicted" tone of the abstract was a bit of grandstanding itself, > IMO. Not too conducive to rational conversation. +1 It is also discouraging to see narrow concerns being, instead, interpreted as broad rejections. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From lyndon@gandalf.orthanc.ca Thu Mar 24 09:13:27 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F53628C0DE for ; Thu, 24 Mar 2011 09:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eOkgjToigKg for ; Thu, 24 Mar 2011 09:13:26 -0700 (PDT) Received: from orthanc.ca (ve6bbm-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:139::2]) by core3.amsl.com (Postfix) with ESMTP id BF6D328C0DB for ; Thu, 24 Mar 2011 09:13:25 -0700 (PDT) Received: from orthanc.ca (localhost [127.0.0.1]) by orthanc.ca (8.14.4/8.14.4) with ESMTP id p2OGEvhV025187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Mar 2011 09:14:57 -0700 (PDT) (envelope-from lyndon@gandalf.orthanc.ca) Received: (from uucp@localhost) by orthanc.ca (8.14.4/8.14.4/Submit) with UUCP id p2OGEvoJ025186; Thu, 24 Mar 2011 09:14:57 -0700 (PDT) (envelope-from lyndon@gandalf.orthanc.ca) Received: from gandalf.orthanc.ca (frodo.orthanc.ca [172.16.0.3]) by legolas.orthanc.ca (8.14.4/8.14.4) with ESMTP id p2OGEtNs061908; Thu, 24 Mar 2011 09:14:55 -0700 (PDT) (envelope-from lyndon@gandalf.orthanc.ca) Message-ID: To: apps-discuss@ietf.org From: "Lyndon Nerenberg (VE6BBM/VE7TFX)" Date: Thu, 24 Mar 2011 08:14:55 -0800 In-Reply-To: <4126.1300980977.007329@puncture> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] IETF technical plenary: the end of application X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 16:13:27 -0000 > Anyone present who doesn't choke at the "Twitter is a network" line > should really wonder what they're doing here. I don't know ... it seems to me the context meant 'social network'. From dave@cridland.net Thu Mar 24 09:21:38 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A0528C0FD for ; Thu, 24 Mar 2011 09:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74RTvbj0v9Vk for ; Thu, 24 Mar 2011 09:21:36 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 932C228C0E1 for ; Thu, 24 Mar 2011 09:21:35 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 8995C1168087; Thu, 24 Mar 2011 16:23:05 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W70e2HuWEDEA; Thu, 24 Mar 2011 16:23:03 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 478131168067; Thu, 24 Mar 2011 16:23:03 +0000 (GMT) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <4126.1300983783.266010@puncture> Date: Thu, 24 Mar 2011 16:23:03 +0000 From: Dave Cridland To: "Lyndon Nerenberg \(VE6BBM/VE7TFX\)" , General discussion of application-layer protocols Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] IETF technical plenary: the end of application X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 16:21:38 -0000 On Thu Mar 24 16:14:55 2011, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: > > Anyone present who doesn't choke at the "Twitter is a network" > line > > should really wonder what they're doing here. > > I don't know ... it seems to me the context meant 'social network'. > > Perhaps I'm getting over-jaded. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From stpeter@stpeter.im Thu Mar 24 09:48:22 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDB5328C13C for ; Thu, 24 Mar 2011 09:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.611 X-Spam-Level: X-Spam-Status: No, score=-102.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ym0XgTU5fA+Z for ; Thu, 24 Mar 2011 09:48:21 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C69AF28C131 for ; Thu, 24 Mar 2011 09:48:21 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B304740022; Thu, 24 Mar 2011 10:51:10 -0600 (MDT) Message-ID: <4D8B7632.5030305@stpeter.im> Date: Thu, 24 Mar 2011 10:49:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Pete Resnick References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D8AB5FC.9050500@stpeter.im> <4D8B5AB7.5030202@qualcomm.com> In-Reply-To: <4D8B5AB7.5030202@qualcomm.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030800060604010608030705" Cc: Scott Brim , Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 16:48:22 -0000 This is a cryptographically signed message in MIME format. --------------ms030800060604010608030705 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/24/11 8:52 AM, Pete Resnick wrote: > On 3/24/11 3:45 AM, Scott Brim wrote: >> On Wed, Mar 23, 2011 at 23:09, Peter Saint-Andre > > wrote: >> > I think Peter is on to something. It is I think more about the herd > instinct, if not a more hierarchical instinct. We don't seem to like > anarchy.=20 Speak for yourself. ;-) > We like someone "in charge" to take care of things.=20 Up to a point. Humans are complicated creatures. We like hierarchy and centralization up to a point. When we feel that those "above" us are getting uppity and corrupt and abusive, we just might turn to something less hierarchical and centralized. Given recent events in certain countries, where those high up in the societal stack decided to simply turn off Internet access for the rebellious rabble, I rather think we might see increasing demand for technologies that route around centralized service providers (and even things like DNS) as damage. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms030800060604010608030705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMy NDE2NDk1NFowIwYJKoZIhvcNAQkEMRYEFErA42m9lACLG4YAJVtrUr6KgvznMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAAsfWuHdbPVRCwUXOw3/hYfkLEYm/ea5/UtkxGK3gWMfXUfekUz/9pB/WR Zh7YIgb1F3iqrAxd3GTORZaSuLPH/a16sgPKhHCLzjNtqPWnfGcP7S+fs/ntiTfxN5iYBwG2 HH4mNdfohaQW4xF+tu0j1Td2s0qhkNFLEUhyUjl2PfM/wqFIpN20nJHX0XOPHJK/BImTxB4W cV794GBm4S+rYcT3OVG8CsvhNLYxT9huDs7pXtq0q8zq0w7XzZh8wth9dQTErC8m/sDIb3xz 4qMc2lh24GcXeEfP0QfIV0C0Wl5KAE4VQLp79e2937HmiFvEiM6A6c433pH/5amK+GLuAAAA AAAA --------------ms030800060604010608030705-- From tobias.gondrom@gondrom.org Thu Mar 24 12:52:39 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E3528C10B for ; Thu, 24 Mar 2011 12:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.212 X-Spam-Level: X-Spam-Status: No, score=-95.212 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CGvS4Mxz7ZY for ; Thu, 24 Mar 2011 12:52:38 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 2C89528C0ED for ; Thu, 24 Mar 2011 12:52:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=KJngZcKyVkojOV4AtRWWo174k4vYTxpdcnS/xh32X4uc6iBhbj6vlvEHl5Qxkr68wb9aQnGeVAxLGyy5jPYjJ6M0OYrNT4R6h3mu2ox98rV7Ye2KzgQYOagrpa0de/bK; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 11632 invoked from network); 24 Mar 2011 20:53:40 +0100 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Mar 2011 20:53:40 +0100 Message-ID: <4D8BA19A.2040606@gondrom.org> Date: Thu, 24 Mar 2011 19:55:06 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: apps-discuss@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Content Types for Fonts? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 19:52:39 -0000 Hello all, maybe someone here can give some help/advice on this. At websec we have a draft on Mime type sniffing algorithms to improve on consistency of browser algorithms for mime type determination (and by thus improve security): http://www.ietf.org/id/draft-ietf-websec-mime-sniff-02.txt Recently a comment came up with regard to identifying fonts (e.g. referenced in style sheets). AFAIK fonts don't have registered mime/content types, so browsers already just use sniffing algorithms for them. And without them having a registered content/mime type, it's kind of a flawed logic to add this to the draft for mime sniffing. On the other hand it might make sense to add content types for fonts to the IANA registry? http://www.iana.org/assignments/media-types/index.html Has that ever come up? Or are they already registered and I missed them? Or is this a bad idea? Any opinions welcome... BR, Tobias (websec chair) From tlr@w3.org Thu Mar 24 13:02:20 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7AD3A68C3 for ; Thu, 24 Mar 2011 13:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZuzxAFY6ACm for ; Thu, 24 Mar 2011 13:02:19 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id B0F783A68BC for ; Thu, 24 Mar 2011 13:02:19 -0700 (PDT) Received: from [88.207.144.203] (helo=[192.168.2.114]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1Q2ql6-0002Rb-NB; Thu, 24 Mar 2011 16:03:52 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Roessler In-Reply-To: <4D8BA19A.2040606@gondrom.org> Date: Thu, 24 Mar 2011 21:03:49 +0100 Content-Transfer-Encoding: 7bit Message-Id: <18C87B21-16B2-44B7-89BD-6CC114352DC7@w3.org> References: <4D8BA19A.2040606@gondrom.org> To: Tobias Gondrom X-Mailer: Apple Mail (2.1084) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Content Types for Fonts? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 20:02:21 -0000 Relevant here: http://www.w3.org/TR/WOFF/#appendix-b Regards, -- Thomas Roessler, W3C (@roessler) On 24 Mar 2011, at 20:55, Tobias Gondrom wrote: > Hello all, > > maybe someone here can give some help/advice on this. > At websec we have a draft on Mime type sniffing algorithms to improve on > consistency of browser algorithms for mime type determination (and by > thus improve security): > http://www.ietf.org/id/draft-ietf-websec-mime-sniff-02.txt > > Recently a comment came up with regard to identifying fonts (e.g. > referenced in style sheets). > AFAIK fonts don't have registered mime/content types, so browsers > already just use sniffing algorithms for them. > And without them having a registered content/mime type, it's kind of a > flawed logic to add this to the draft for mime sniffing. > > On the other hand it might make sense to add content types for fonts to > the IANA registry? > http://www.iana.org/assignments/media-types/index.html > > Has that ever come up? Or are they already registered and I missed them? > Or is this a bad idea? > > Any opinions welcome... > > BR, Tobias > (websec chair) > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nico@cryptonector.com Thu Mar 24 13:25:07 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933123A6846 for ; Thu, 24 Mar 2011 13:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.587 X-Spam-Level: X-Spam-Status: No, score=-0.587 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_REPLY_C=2.012] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYI-1pvOIoxw for ; Thu, 24 Mar 2011 13:25:07 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 647833A67F1 for ; Thu, 24 Mar 2011 13:25:07 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 31C572C806B for ; Thu, 24 Mar 2011 13:26:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=GET80cRcpZZRSeo0lF35f dSJephjw7kgoMHrLsPzCF/qjXMnxuQIqIjH3cgpbi2N4ztVLK9OkAaDK3vwLExm6 xMZdm5mx4v9SpqUnQxj5UoExxPIwKc9O92zJu4yzjdjSpS8tEeNY8RtMwB2K8Hyo X4vMsaKTczdqUbX9T+UL/c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=x0SI2WAIwsIXW/P54Hlx EPKhfBM=; b=fhsFz4QLytkH0xAvERHDMEQMkwFJ2uX5KRYZFl4mioSA+wxyXwcc SmceARu0RAdkZyUATMVFWU+R7QTS/7Lcpvyni0PSgzX/ySxblaGVVp4K9yHR/QGy 8PLWKWVoKSjuRzgIAx7cdB5TPPx+RTwilspy6Nqh2B59CHbHh9BnOfw= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id ED9EF2C8057 for ; Thu, 24 Mar 2011 13:26:41 -0700 (PDT) Received: by vxg33 with SMTP id 33so347703vxg.31 for ; Thu, 24 Mar 2011 13:26:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.18.102 with SMTP id v6mr3810454vdd.224.1300998401325; Thu, 24 Mar 2011 13:26:41 -0700 (PDT) Received: by 10.52.159.4 with HTTP; Thu, 24 Mar 2011 13:26:41 -0700 (PDT) In-Reply-To: <4D8B5AB7.5030202@qualcomm.com> References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D8AB5FC.9050500@stpeter.im> <4D8B5AB7.5030202@qualcomm.com> Date: Thu, 24 Mar 2011 15:26:41 -0500 Message-ID: From: Nico Williams To: Pete Resnick Content-Type: text/plain; charset=UTF-8 Cc: Scott Brim , Apps Discuss Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 20:25:07 -0000 On Thu, Mar 24, 2011 at 9:52 AM, Pete Resnick wrote: > On 3/24/11 3:45 AM, Scott Brim wrote: > On Wed, Mar 23, 2011 at 23:09, Peter Saint-Andre wrote: >> Whatever the reason, most people don't want to run their >> own services -- it's much easier to visit a website, and tell people >> that you're "on", a popular email or IM or blogging or microblogging or >> voice or video service than it is to install and maintain postfix or >> Prosody or WordPress or laconica or Asterisk or Yate on the server side >> plus Thunderbird or Pidgin or Jitsi (etc.) on the client side (let alone >> the whole stack of OS and DNS and databases and registered domains and >> certificates and all the rest). > > People do seem fully capable to grasp "Here is my phone number, you can > reach me here" and do at least that particular kind of peer-to-peer > communication. There is no reason that IM or email or blogging *have* to be > a service; it's a remnant of being pre-disposed to client-server models > (including, BTW, DNS). "Here's my phone number, call me" is not really peer-to-peer. "Here's my address, drop by" is. The former relies on quite a bit of infrastructure (all the more so when the devices are mobile), but the latter could work even without roads, streets, etcetera (though addresses might have to be in the form of coordinates, but don't forget that GPS is also infrastructure). However, the phone system's infrastructure is an afterthought to the user, as you demonstrate :) The same is true of the Internet, but its engineers are aware of the infrastructure, giving us a different viewpoint than the user's. Looked at that way, what's so strange about NAT and SIP and XMPP? Infrastructure mediated peer-to-peer... seems perfectly natural to me. Is infrastructure really avoidable? Without infrastructure we're almost necessarily limited to peer-to-peer communications over a small area: the range of voice, of available travel technologies, of our peer-to-peer electromagnetic spectrum (further limited by device power capacity). Or is it the type of infrastructure that bothers some people? DNS is OK but "servers" are not?? I see complaints about the end of the end-to-end model implied by thin clients. But I don't think that's a forgone conclusion. End-to-end _security_ is the key at any rate (or maybe that's just me looking at things from a security point of view, or maybe I've been conditioned by HTTP to accept that the "network" does weird things, or...). > I hope we can have a real discussion in Prague, without too much > grandstanding. > > It's going to be difficult. I can say for myself that I've been pushing for > a deeper discussion (and getting it in many places), but the "death of > application protocols predicted" tone of the abstract was a bit of > grandstanding itself, IMO. Not too conducive to rational conversation. The Internet is as organic as it's not. I see this as yet another step in organic development. Some guidance may be needed to find and avert pitfalls before hitting them (again or for the first time), but that's as far as we can go. Nico -- From derhoermi@gmx.net Thu Mar 24 22:28:36 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2800A3A67FD for ; Thu, 24 Mar 2011 22:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCopXQEHP5g8 for ; Thu, 24 Mar 2011 22:28:34 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id DCEB83A6943 for ; Thu, 24 Mar 2011 22:28:33 -0700 (PDT) Received: (qmail invoked by alias); 25 Mar 2011 05:30:06 -0000 Received: from dslb-094-222-129-148.pools.arcor-ip.net (EHLO HIVE) [94.222.129.148] by mail.gmx.net (mp072) with SMTP; 25 Mar 2011 06:30:06 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+nduh6VbqnHjJ8qF2YJ79AIPNYk9Ucw0fiBt9Gcp xyitAEbiP0sVbu From: Bjoern Hoehrmann To: Tobias Gondrom Date: Fri, 25 Mar 2011 06:30:08 +0100 Message-ID: References: <4D8BA19A.2040606@gondrom.org> In-Reply-To: <4D8BA19A.2040606@gondrom.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Content Types for Fonts? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 05:28:36 -0000 * Tobias Gondrom wrote: >http://www.ietf.org/id/draft-ietf-websec-mime-sniff-02.txt >AFAIK fonts don't have registered mime/content types, so browsers >already just use sniffing algorithms for them. >And without them having a registered content/mime type, it's kind of a >flawed logic to add this to the draft for mime sniffing. The draft refers to application/x-rar-compressed, application/x-gzip, unknown/unknown, application/unknown, application/rss+xml, image/webp, video/webm. They are all unregistered, and in case of the first two, cannot be registered without changing BCP 13. Are those a problem as- well? >On the other hand it might make sense to add content types for fonts to >the IANA registry? >http://www.iana.org/assignments/media-types/index.html > >Has that ever come up? Or are they already registered and I missed them? >Or is this a bad idea? I don't think there is anything special about fonts that would make that a bad idea compared to other kinds of resources. There has been some interest in this and there have been some efforts, for example, , but as far as I am aware nobody has gone so far as to ask the IESG to actually approve a font media type. (I think it might be best for the Applications Area Working Group to draw up a list of common data formats with unregistered media types and make a bulk specification that contains the absolute minimum to register them all. If it were to do so, throwing in a couple of font types should be no problem.) -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From alexey.melnikov@isode.com Fri Mar 25 01:18:39 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5CD3A6978 for ; Fri, 25 Mar 2011 01:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFh2wKq7aqcc for ; Fri, 25 Mar 2011 01:18:27 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 8F93C3A6973 for ; Fri, 25 Mar 2011 01:18:27 -0700 (PDT) Received: from [192.168.192.13] (feldconf.feld.cvut.cz [147.32.192.240]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 25 Mar 2011 08:19:58 +0000 Message-ID: <4D8C390D.3050106@isode.com> Date: Fri, 25 Mar 2011 07:41:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Dave Cridland , Graham Klyne References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D885482.2050006@ninebynine.org> <6266.1300784475.434865@puncture> In-Reply-To: <6266.1300784475.434865@puncture> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: General discussion of application-layer protocols Subject: [apps-discuss] HYBI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 08:18:40 -0000 Dave Cridland wrote: > On Tue Mar 22 07:49:22 2011, Graham Klyne wrote: > >> FWIW, I can think of two simple (to describe) capabilities that >> would help to make the web more widely usable as a application >> platform: >> >> (a) a *simple* mechanism for pushing asynchronous notifications to a >> web application (browser-based or otherwise). I had early hopes for >> HyBi, but have somewhat given up. > > As have many. While I understand community frustration about HYBI WG discussions, I think people really need to look now at the latest protocol spec. The document has been improved substantially and I think it is actually implementable at this point in time. > Another option would be to use XMPP directly in the browser - not > some hacked down variant communicating only with the webserver's > approved domain, but full XMPP. This has different properties > entirely from WebSockets, but those properties give rise to some > interesting concepts. I would also like XMPP to be used directly by browsers, but if this doesn't happen, I think something close enough to the current HYBI protocol is going to be good enough. From salvatore.loreto@ericsson.com Fri Mar 25 01:55:20 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C29793A6843 for ; Fri, 25 Mar 2011 01:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGlRhAkkeMWd for ; Fri, 25 Mar 2011 01:55:19 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 1B2213A683B for ; Fri, 25 Mar 2011 01:55:18 -0700 (PDT) X-AuditID: c1b4fb3d-b7bbbae000005311-64-4d8c58d5e50f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7D.78.21265.5D85C8D4; Fri, 25 Mar 2011 09:56:53 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 25 Mar 2011 09:56:52 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BDCE5245F for ; Fri, 25 Mar 2011 10:56:52 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 84F6950AB7 for ; Fri, 25 Mar 2011 10:56:52 +0200 (EET) Received: from dhcp-1324.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2E91850AB6 for ; Fri, 25 Mar 2011 10:56:52 +0200 (EET) Message-ID: <4D8C58D3.3020503@ericsson.com> Date: Fri, 25 Mar 2011 09:56:51 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D885482.2050006@ninebynine.org> <6266.1300784475.434865@puncture> <4D8C390D.3050106@isode.com> In-Reply-To: <4D8C390D.3050106@isode.com> Content-Type: multipart/alternative; boundary="------------070006070701050005080107" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [apps-discuss] HYBI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 08:55:20 -0000 --------------070006070701050005080107 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 3/25/11 7:41 AM, Alexey Melnikov wrote: > Dave Cridland wrote: > >> > On Tue Mar 22 07:49:22 2011, Graham Klyne wrote: >> > >>> >> FWIW, I can think of two simple (to describe) capabilities that >>> >> would help to make the web more widely usable as a application >>> >> platform: >>> >> >>> >> (a) a*simple* mechanism for pushing asynchronous notifications to a >>> >> web application (browser-based or otherwise). I had early hopes for >>> >> HyBi, but have somewhat given up. >> > >> > As have many. > While I understand community frustration about HYBI WG discussions, I > think people really need to look now at the latest protocol spec. The > document has been improved substantially and I think it is actually > implementable at this point in time. > while I agree that as all the things in this world, the WebSocket protocol could have been designed differently and I understand that has been challenging and some time also frustrating for people to follow the intensive and long mail discussion, I do think (but I am biased here) in HyBi we (at IETF) have done, and we are still doing, an incredible effort to merge different cultures or at least make them to work together in a productive way the last version 06 has improved a lot: ( http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06 ) and there are already a lot of implementations of 06 draft (from both sides browsers and web severs) and more are under development and will be announced soon. We will try to give an overview of the situation at the upcoming HyBi session of course there are still open issues that need to be discussed, and need to reach consensus ... but are few and almost all of them are to improve (simplify) something cheers /Sal -- Salvatore Loreto www.sloreto.com --------------070006070701050005080107 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 3/25/11 7:41 AM, Alexey Melnikov wrote: 
Dave Cridland wrote:


> On Tue Mar 22 07:49:22 2011, Graham Klyne wrote:
>

>> FWIW, I can think of two simple (to describe) capabilities that  
>> would help to make the web more widely usable as a application  
>> platform:
>>
>> (a) a *simple* mechanism for pushing asynchronous notifications to  a 
>> web application (browser-based or otherwise).  I had early hopes  for 
>> HyBi, but have somewhat given up.

>
> As have many.

While I understand community frustration about HYBI WG discussions, I 
think people really need to look now at the latest protocol spec. The 
document has been improved substantially and I think it is actually 
implementable at this point in time.
while I agree that as all the things in this world,
the WebSocket protocol could have been designed differently
and I understand that has been challenging and some time also frustrating for people to follow the intensive
and long mail discussion,
I do think (but I am biased here) in HyBi we (at IETF) have done, and we are still doing, an incredible effort to merge
different cultures or at least make them to work together in a productive way

the last version 06 has improved a lot: ( http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06 )
and there are already a lot of implementations of 06 draft (from both sides browsers and web severs)
and more are under development and will be announced soon.
We will try to give an overview of the situation at the upcoming HyBi session

of course there are still open issues that need to be discussed,
and need to reach consensus ...  but are few and almost all of them are to improve (simplify) something

cheers
/Sal
-- 
Salvatore Loreto
www.sloreto.com
--------------070006070701050005080107-- From GK@ninebynine.org Fri Mar 25 06:59:45 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844283A6859 for ; Fri, 25 Mar 2011 06:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.813 X-Spam-Level: X-Spam-Status: No, score=-5.813 tagged_above=-999 required=5 tests=[AWL=0.742, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjRgi4fS-kT2 for ; Fri, 25 Mar 2011 06:59:44 -0700 (PDT) Received: from relay0.mail.ox.ac.uk (relay0.mail.ox.ac.uk [129.67.1.161]) by core3.amsl.com (Postfix) with ESMTP id 9B6B43A68A6 for ; Fri, 25 Mar 2011 06:59:44 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay0.mail.ox.ac.uk with esmtp (Exim 4.74) (envelope-from ) id 1Q37Zl-0007se-1n; Fri, 25 Mar 2011 14:01:17 +0000 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Q37Zl-0007WL-1E; Fri, 25 Mar 2011 14:01:17 +0000 Message-ID: <4D8C6CBD.6070705@ninebynine.org> Date: Fri, 25 Mar 2011 10:21:49 +0000 From: Graham Klyne User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alexey Melnikov References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D885482.2050006@ninebynine.org> <6266.1300784475.434865@puncture> <4D8C390D.3050106@isode.com> In-Reply-To: <4D8C390D.3050106@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] HYBI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 13:59:45 -0000 Alexey Melnikov wrote: > Dave Cridland wrote: > >> On Tue Mar 22 07:49:22 2011, Graham Klyne wrote: >> >>> FWIW, I can think of two simple (to describe) capabilities that >>> would help to make the web more widely usable as a application >>> platform: >>> >>> (a) a *simple* mechanism for pushing asynchronous notifications to a >>> web application (browser-based or otherwise). I had early hopes for >>> HyBi, but have somewhat given up. >> >> As have many. > > While I understand community frustration about HYBI WG discussions, I > think people really need to look now at the latest protocol spec. The > document has been improved substantially and I think it is actually > implementable at this point in time. A fair point ... I really should go back and look again. But, for context, my idea of *simple* here is a notification model that *could* be implemented today for browsers using Javascript-over-HTTP, and subsequently migrated to a more robust, native implementation in browsers. (FWIW, I did a little development around this idea a few years ago: http://code.google.com/p/webbrick-events/, esp http://code.google.com/p/webbrick-events/wiki/EventModel. My implementation uses a form of HTTP long-polling, but it was always my hope to more this to a more widely supported substrate.) #g -- From GK@ninebynine.org Fri Mar 25 06:59:47 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA76E28B56A for ; Fri, 25 Mar 2011 06:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17ASIak0ddFr for ; Fri, 25 Mar 2011 06:59:47 -0700 (PDT) Received: from relay2.mail.ox.ac.uk (relay2.mail.ox.ac.uk [163.1.2.161]) by core3.amsl.com (Postfix) with ESMTP id A5E7A3A6859 for ; Fri, 25 Mar 2011 06:59:46 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay2.mail.ox.ac.uk with esmtp (Exim 4.74) (envelope-from ) id 1Q37Zl-0000Wh-6S; Fri, 25 Mar 2011 14:01:17 +0000 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Q37Zk-0007WG-2o; Fri, 25 Mar 2011 14:01:16 +0000 Message-ID: <4D8C6A0F.2090908@ninebynine.org> Date: Fri, 25 Mar 2011 10:10:23 +0000 From: Graham Klyne User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Dave Cridland References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D885482.2050006@ninebynine.org> <6266.1300784475.434865@puncture> <3F2B4909-DE99-4189-98BC-5E9DDCE3CAC5@gmx.net> <4126.1300977355.111049@puncture> <4126.1300980977.007329@puncture> In-Reply-To: <4126.1300980977.007329@puncture> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Cc: Pete Resnick , Scott Brim , Dave CROCKER , General discussion of application-layer protocols Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 13:59:47 -0000 Dave Cridland wrote: > http://groups.google.com/group/twitter-development-talk/browse_thread/thread/c82cd59c7a87216a?pli=1 I assume you refer to: "Twitter is a network, and its network effects are driven by users seeing and contributing to the network’s conversations." > Anyone present who doesn't choke at the "Twitter is a network" line > should really wonder what they're doing here. There are many valid uses for the term "network": - The Internet is a communication network - The Web is a network of documents (and more...) - Life is driven by biochemical signalling networks - Biological ecosystems are resource distribution networks - Railways are transport networks - Communities of people form social networks - etc. And the great insight (surprise?) is that many of these networks share properties on common when viewed in a sufficiently abstract light. Cf. [1], [2], etc. And I people who are doing practical work that spans these fields; e.g. related to http://webscience.org/webscience.html to name just one example. So within this, I think there is a valid position that Twitter is *a* network. Just not a network that forms a basis for almost all kinds of computer communication. If we are to be relevant to a wider community of users, I don't think it helps to assert ownership of the term "network". So while I personally disagree with Twitter's position stated in the message cited, it's not with their claim that "Twitter is a network". Let's not confuse apple and oranges. #g -- [1] "Linked", Albert-Laszlo barabasi [2] "At home in the Universe", Stuart Kaufman From lars.eggert@nokia.com Fri Mar 25 08:08:33 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E867128C0EF; Fri, 25 Mar 2011 08:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.313 X-Spam-Level: X-Spam-Status: No, score=-103.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtdsK7ZyDVxA; Fri, 25 Mar 2011 08:08:33 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 152A53A6873; Fri, 25 Mar 2011 08:08:33 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2PFA5bR018488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Mar 2011 17:10:06 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-20-636054128; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 25 Mar 2011 16:10:01 +0100 Message-Id: <2DA0F0C5-7D06-44D9-B480-61BF7B1F01D6@nokia.com> To: apps-discuss@ietf.org, int-area@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Fri, 25 Mar 2011 17:10:02 +0200 (EET) X-Nokia-AV: Clean Subject: [apps-discuss] some items of interest on the TSVAREA agenda X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: TSV Area List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 15:08:34 -0000 --Apple-Mail-20-636054128 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, FYI, the TSVAREA meeting will have several topics that may of of = interest to APP and INT folks, specifically: Bufferbloat: "Dark" Buffers in the Internet Jim Gettys SPDY, TCP, and the Single Connection Throttle Mike Belshe See http://www.ietf.org/proceedings/80/agenda/tsvarea.txt Lars= --Apple-Mail-20-636054128 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMyNTE1MTAwMVowIwYJKoZIhvcNAQkE MRYEFOSngU+HyeZGtM/On3tbP0/omTunMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AIP5uHP/Ywe1tgO96162mYUVX6KUlzYBZa4+aCewWvK0kqoMDE9eAbEcemQWVR0gYUzD88oSiteN OIob/6yRhgcEz61OZ2nGFxJVfqOHk+oMyCgFPTn+rhz49RKjsjgq1aUAXjEyOqEX9TK19juOu1HK yoR+HW5CSJZ1rrCrDrKTCTJ1cQhd0wGXe9+x01F1TppckYPOK+VwF+xAyJdVj1sersf4I4cLwU4p WDQlUO9QNLNz60C6qxSN14Rk7LDGppnIfrthCRzs2VWBdzPlXgoZjAnapIoz5D3Ea3Is0qWxE+bd fGBJsX9TBhtKdOgqQGlgT3pftmPC+cw4tOEeH54AAAAAAAA= --Apple-Mail-20-636054128-- From hannes.tschofenig@gmx.net Sat Mar 26 00:25:39 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201A33A68EA for ; Sat, 26 Mar 2011 00:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DnOCd+1omLp for ; Sat, 26 Mar 2011 00:25:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id DB0E23A68E9 for ; Sat, 26 Mar 2011 00:25:36 -0700 (PDT) Received: (qmail invoked by alias); 26 Mar 2011 07:27:11 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp070) with SMTP; 26 Mar 2011 08:27:11 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19X9QIuurxX3fiYiA91Xrci/ln6o1kOow9EB+sEr5 dOxaHcqSrFpfjD Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4126.1300977355.111049@puncture> Date: Sat, 26 Mar 2011 08:27:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <498C386D-34DB-4E89-9D47-E387F0C84E01@gmx.net> References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D885482.2050006@ninebynine.org> <6266.1300784475.434865@puncture> <3F2B4909-DE99-4189-98BC-5E9DDCE3CAC5@gmx.net> <4126.1300977355.111049@puncture> To: Dave Cridland X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Pete Resnick , Graham Klyne , Dave CROCKER , General discussion of application-layer protocols Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 07:25:39 -0000 On Mar 24, 2011, at 4:35 PM, Dave Cridland wrote: > Sadly, probably very unlikely. Who's going to provide the kind of = leadership we'd need to have a coherent architecture for the internet, = instead of one that emerges driven by a few service providers? I guess you are touching a much larger issue that has very little todo = with the Web as such. You are essentially asking me (or the IAB) to get = rid of the big players in the market place. Ideally, you want to have = lots of small or medium size players but no one that dominates (like = Facebook does for social networks or Twitter does for microblogging).=20 Changing technical specifications will not help you to get to such a = desired state.=20 Ciao Hannes From alexey.melnikov@isode.com Sat Mar 26 02:27:25 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99E793A683B for ; Sat, 26 Mar 2011 02:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.103 X-Spam-Level: X-Spam-Status: No, score=-102.103 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKikF-ahBn7y for ; Sat, 26 Mar 2011 02:27:16 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id E0CDE3A6903 for ; Sat, 26 Mar 2011 02:27:15 -0700 (PDT) Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 26 Mar 2011 09:28:51 +0000 Message-ID: <4D8CEF4E.3070307@isode.com> Date: Fri, 25 Mar 2011 20:38:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Bjoern Hoehrmann , Tobias Gondrom References: <4D8BA19A.2040606@gondrom.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Content Types for Fonts? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 09:27:25 -0000 Bjoern Hoehrmann wrote: >* Tobias Gondrom wrote: > > >>http://www.ietf.org/id/draft-ietf-websec-mime-sniff-02.txt >> >>AFAIK fonts don't have registered mime/content types, so browsers >>already just use sniffing algorithms for them. >>And without them having a registered content/mime type, it's kind of a >>flawed logic to add this to the draft for mime sniffing. >> >> > >The draft refers to application/x-rar-compressed, application/x-gzip, >unknown/unknown, application/unknown, application/rss+xml, image/webp, >video/webm. They are all unregistered, and in case of the first two, >cannot be registered without changing BCP 13. > Right. >Are those a problem as-well? > Yes. >>On the other hand it might make sense to add content types for fonts to >>the IANA registry? >>http://www.iana.org/assignments/media-types/index.html >> >>Has that ever come up? Or are they already registered and I missed them? >>Or is this a bad idea? >> > >I don't think there is anything special about fonts that would make >that a bad idea compared to other kinds of resources. There has been >some interest in this and there have been some efforts, for example, >, but as far >as I am aware nobody has gone so far as to ask the IESG to actually >approve a font media type. > > I don't see any immediate problem with registering fonts. >(I think it might be best for the Applications Area Working Group to >draw up a list of common data formats with unregistered media types >and make a bulk specification that contains the absolute minimum to >register them all. > That is a fine idea, but who would volunteer to write such a spec? >If it were to do so, throwing in a couple of font >types should be no problem.) > > From derhoermi@gmx.net Sat Mar 26 02:40:40 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6FA3A690D for ; Sat, 26 Mar 2011 02:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7B6vDOQsF0B for ; Sat, 26 Mar 2011 02:40:39 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id D42913A6907 for ; Sat, 26 Mar 2011 02:40:38 -0700 (PDT) Received: (qmail invoked by alias); 26 Mar 2011 09:41:39 -0000 Received: from dslb-094-222-129-148.pools.arcor-ip.net (EHLO HIVE) [94.222.129.148] by mail.gmx.net (mp022) with SMTP; 26 Mar 2011 10:41:39 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18GIAUKDvUGWMOgcSVeVCGrN6PPOZ3TOJfVhBwO1+ dpDbX9Hh/iJcRZ From: Bjoern Hoehrmann To: Alexey Melnikov Date: Sat, 26 Mar 2011 10:41:32 +0100 Message-ID: References: <4D8BA19A.2040606@gondrom.org> <4D8CEF4E.3070307@isode.com> In-Reply-To: <4D8CEF4E.3070307@isode.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Content Types for Fonts? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 09:40:40 -0000 * Alexey Melnikov wrote: >Bjoern Hoehrmann wrote: >>(I think it might be best for the Applications Area Working Group to >>draw up a list of common data formats with unregistered media types >>and make a bulk specification that contains the absolute minimum to >>register them all. >> >That is a fine idea, but who would volunteer to write such a spec? Well, I would volunteer to review and contribute some information that would be necessary for some types, but I have no interest in arguing with others about some security considerations being inadequate or who is to go into the Contact Person field or what to put into bizarre fields like "Macintosh file type code", much less dealing with any legal issues that might crop up; otherwise I would probably already have tried to do this. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From evnikita2@gmail.com Sat Mar 26 11:03:11 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F763A67EC; Sat, 26 Mar 2011 11:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjq877uZZLdk; Sat, 26 Mar 2011 11:03:10 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id CEDBA3A67EB; Sat, 26 Mar 2011 11:03:09 -0700 (PDT) Received: by fxm15 with SMTP id 15so1997397fxm.31 for ; Sat, 26 Mar 2011 11:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=MxQTZCTjL/5Y7xwK6t8uTZ6ivTqgw5GrTNPkhlZqBnU=; b=nQOYTonSZWdyG3Uz40aOKChL3QGrtCj9Rkvsvx8EamjtR6lbzUXHp7KnHfz6/rqoY5 dD5jyG+JXWFonYLf3X+aThdFJvkHaa4toudSyszN9F5X9k9wA/Hs5ktDxYboZdDUJ93t uinMZfOvAsfjD2suKYw6vQNT/jWaZfTrAI/os= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=r3Fi0W7cZrgwREV3TmXsoXlEyGsceUf0yRkyAaY/wIJNEUq3UIjt1Ju+MnG99l/9SY Ityclizst08Mvksu28WSsxpJ/DczTTCJj4OQg8Ac18fzjpJwLbyKg5OueJh6AMGnmt77 UvbhA4kEnNQ8or//oCXhpU9Kekz0b5bcN9uKI= Received: by 10.223.15.141 with SMTP id k13mr2523659faa.30.1301162685225; Sat, 26 Mar 2011 11:04:45 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id 21sm852028fav.41.2011.03.26.11.04.42 (version=SSLv3 cipher=OTHER); Sat, 26 Mar 2011 11:04:44 -0700 (PDT) Message-ID: <4D8E2ADD.3010001@gmail.com> Date: Sat, 26 Mar 2011 20:05:17 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "uri-review@ietf.org" , URI , "apps-discuss@ietf.org" Content-Type: multipart/alternative; boundary="------------000105070004060406010207" Subject: [apps-discuss] FYI: RFC 6196 on Moving mailserver: URI Scheme to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 18:03:11 -0000 This is a multi-part message in MIME format. --------------000105070004060406010207 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello all. Just FYI. Mykyta. (Sorry of you receive multiple copies of this) > A new Request for Comments is now available in online RFC libraries. > > > RFC 6196 > > Title: Moving mailserver: URI Scheme to > Historic > Author: A. Melnikov > Status: Standards Track > Stream: IETF > Date: March 2011 > Mailbox: Alexey.Melnikov@isode.com > Pages: 3 > Characters: 5679 > Updates: RFC1738 > > I-D Tag: draft-melnikov-mailserver-uri-to-historic-00.txt > > URL: http://www.rfc-editor.org/rfc/rfc6196.txt > > This document registers the mailserver: URI scheme as historic in the > IANA URI registry. [STANDARDS-TRACK] > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > --------------000105070004060406010207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello all.  Just FYI.  Mykyta.

(Sorry of you receive multiple copies of this)

 
A new Request for Comments is now available in online RFC libraries.

        
        RFC 6196

        Title:      Moving mailserver: URI Scheme to 
                    Historic 
        Author:     A. Melnikov
        Status:     Standards Track
        Stream:     IETF
        Date:       March 2011
        Mailbox:    Alexey.Melnikov@isode.com
        Pages:      3
        Characters: 5679
        Updates:    RFC1738

        I-D Tag:    draft-melnikov-mailserver-uri-to-historic-00.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6196.txt

This document registers the mailserver: URI scheme as historic in the
IANA URI registry.  [STANDARDS-TRACK]

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

--------------000105070004060406010207-- From stpeter@stpeter.im Sun Mar 27 04:55:05 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A230228C111 for ; Sun, 27 Mar 2011 04:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pG-OoNvrxZ41 for ; Sun, 27 Mar 2011 04:55:04 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D39B03A67DB for ; Sun, 27 Mar 2011 04:55:04 -0700 (PDT) Received: from dhcp-12cb.meeting.ietf.org (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 07CEF4006D for ; Sun, 27 Mar 2011 05:58:10 -0600 (MDT) Message-ID: <4D8F25F7.3040607@stpeter.im> Date: Sun, 27 Mar 2011 13:56:39 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060409010704040107010008" Subject: [apps-discuss] Fwd: discussion about timezone database X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 11:55:05 -0000 This is a cryptographically signed message in MIME format. --------------ms060409010704040107010008 Content-Type: multipart/mixed; boundary="------------020007020707080809020901" This is a multi-part message in MIME format. --------------020007020707080809020901 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is just a reminder for folks in the apps area... -------- Original Message -------- Subject: discussion about timezone database Date: Sun, 27 Mar 2011 13:55:23 +0200 From: Peter Saint-Andre To: IETF discussion list Folks, there will be a discussion of draft-lear-iana-timezone-database and related issues this Wednesday at IETF 80 in Prague. The room will be Karlin 1 and the time slot is 08:00-09:00 local time. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------020007020707080809020901 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSWV0ZiBt YWlsaW5nIGxpc3QKSWV0ZkBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lldGYKCg== --------------020007020707080809020901-- --------------ms060409010704040107010008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMy NzExNTYzOVowIwYJKoZIhvcNAQkEMRYEFCF3XA/Na2zn7tqmkjdUlvk09yMHMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBvDM1VBbA3DJdh4+0woQMaSaeuGRdIM3RIAvN2M7S7lkna6cbotDnR7aAO cxu4UW+vY7ETfiDNnee65CCWLkbxXmdB3BfWzSeoidMzGrq74QC47KzBmmo5r9nCPd81JzEI cMbPAx9RF57myHSHfcb8bPdm2Hle3Fl2WcOz25UaPruvd+Iyba1cVKH0odYcicCYlAQ9WcIt Za2WewiH9vyK9uWmvuEn1MDfWWjaYyE+fTwS/u7Hh7aKvP4YOYgvWzdM973mx6IeROZX0SjR cGJEMYokPs+P903MmDFuJT6wornnCTUUD0swLPa7E/31c5z7xLuMYHSUNhuVlHh6kquVAAAA AAAA --------------ms060409010704040107010008-- From dhc@dcrocker.net Sun Mar 27 07:23:56 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D1328C153 for ; Sun, 27 Mar 2011 07:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2g4-6L-qjqf for ; Sun, 27 Mar 2011 07:23:55 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 32C3828C14D for ; Sun, 27 Mar 2011 07:23:55 -0700 (PDT) Received: from [130.129.87.14] (dhcp-570e.meeting.ietf.org [130.129.87.14]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p2REPO28032575 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 27 Mar 2011 07:25:31 -0700 Message-ID: <4D8F48D2.5010304@dcrocker.net> Date: Sun, 27 Mar 2011 16:25:22 +0200 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Apps Discuss References: <4D87612E.3090900@dcrocker.net> <350C1321-1FA8-444B-AFA5-ACD8F36EB0E8@neustar.biz> In-Reply-To: <350C1321-1FA8-444B-AFA5-ACD8F36EB0E8@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 27 Mar 2011 07:25:32 -0700 (PDT) Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 14:23:56 -0000 > Subject: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00 > Date: Sun, 27 Mar 2011 16:18:11 +0200 > From: Dave CROCKER > Reply-To: dcrocker@bbiw.net > Organization: Brandenburg InternetWorking > To: IETF Discussion Folks, I've just posted the above-cited review of the draft that is the basis for this thread, onto the IETF list, since it is time we all focus on the full community. Please direct any comments you might have to that larger forum. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From flefauch@cisco.com Sun Mar 27 07:32:41 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FF828C12B for ; Sun, 27 Mar 2011 07:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.087 X-Spam-Level: X-Spam-Status: No, score=-10.087 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q+qCDXQYkd7 for ; Sun, 27 Mar 2011 07:32:40 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 7FFE828C128 for ; Sun, 27 Mar 2011 07:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=1917; q=dns/txt; s=iport; t=1301236457; x=1302446057; h=from:subject:date:message-id:cc:to:mime-version; bh=ZXbVCfwB/cvVFweR3+qhTDqW9Eg8UlOUVI4YwZ6aP/c=; b=KpO6u1xTsPTkAIkDcEv8jr1H6hvz4FndUuKnuynA5dx84OHE54xmcxY5 4SznQr1JA55Sy0FNj9fgRIQ1kZ17ATluAXmRj8WcE+MBm7fqcXJ8qa48h XJA1fd05xa//j8lzp7E/ogXybeCabk1u5qIfcAjSXPtIJmEwSHlCZoQbg Y=; X-IronPort-AV: E=Sophos;i="4.63,251,1299456000"; d="scan'208,217";a="23339791" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 27 Mar 2011 14:34:16 +0000 Received: from ams-flefauch-8711.cisco.com (ams-flefauch-8711.cisco.com [10.55.161.194]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2REYChf023733; Sun, 27 Mar 2011 14:34:16 GMT From: Francois Le Faucheur Content-Type: multipart/alternative; boundary=Apple-Mail-72-806750605 Date: Sun, 27 Mar 2011 16:34:57 +0200 Message-Id: To: apps-discuss@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Sun, 27 Mar 2011 08:22:25 -0700 Cc: Le Faucheur Francois , Richard Woundy Subject: [apps-discuss] "CDN Interconnection" BOF announcement X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 14:32:41 -0000 --Apple-Mail-72-806750605 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, For information, a BOF on "Content Distribution Network Interconnection = (CDNI)" will take place on Thursday 31st March at 17:40. Agenda at: http://www.ietf.org/proceedings/80/agenda/cdni.html Details, I-Ds, list archive, etc can all be found from the IETF BOF = wiki: http://trac.tools.ietf.org/bof/trac/wiki/WikiStart If you plan attending, please familiarize yourself with the associated = material and discussions to date. Thanks Francois --Apple-Mail-72-806750605 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Details, I-Ds, list = archive, etc can all be found from the IETF BOF wiki:  http://trac.to= ols.ietf.org/bof/trac/wiki/WikiStart

If you = plan attending, please familiarize yourself with the associated material = and discussions to = date.

Thanks

Francois
X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070502050107060803080805" Subject: [apps-discuss] final agenda and slides for IETF 80 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 22:22:46 -0000 This is a cryptographically signed message in MIME format. --------------ms070502050107060803080805 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks, I've updated the agenda based on discussions today (removed discussion of MIME & the Web, added discussion of virtual desktop infrastructures). I've also uploaded PDF slides for all of the presentations that will use them. Visit http://tools.ietf.org/agenda/80/ to obtain all the materials. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms070502050107060803080805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMy NzIyMjQxOFowIwYJKoZIhvcNAQkEMRYEFNV/zY74NBuKWmly8Mqod9hOHR4CMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCArRBjWF4dgVE8wn5JSc2hXQh8hFcJdsqyv8EiFeHhKBaWKN1a6Wlr/zaY NXVnvVGoAbX6LdK7bA+1pjM7ZV0AFiCTO4P0Gvtt578CsoZX7XaQqX4JrpjTgayJReAhKp21 uJc7Cf1zbIEHa7tyTrZcpdc99oHk9oGTCglA0wkdMcnDI0bjtDLRLWvCBP4hKmEB3QaaXz5W YUWBo4R4JdY3wVWXB2wE16ilySnuQhrNqduakY8E/ZavYk1bZXjSeXErhrMvY9H6on5gtnw8 IdkelHBXMkUnDz2xBIYkwzeukvWNDU8qO7LpdyN9Qu6YJ+FVTklsY1ECbRmRHvNVW0TBAAAA AAAA --------------ms070502050107060803080805-- From hannes.tschofenig@gmx.net Mon Mar 28 04:53:03 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920893A685B for ; Mon, 28 Mar 2011 04:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDtp1IZgcFLy for ; Mon, 28 Mar 2011 04:52:56 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 9B5393A6814 for ; Mon, 28 Mar 2011 04:52:52 -0700 (PDT) Received: (qmail invoked by alias); 28 Mar 2011 11:54:26 -0000 Received: from dhcp-9039.meeting.ietf.org (EHLO dhcp-9039.meeting.ietf.org) [130.129.8.57] by mail.gmx.net (mp069) with SMTP; 28 Mar 2011 13:54:26 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+rOcM++firqftbtaEeyNoooL/J1XnhoQEh46lpET GcnWn/WlY/FC/F Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Hannes Tschofenig In-Reply-To: <498C386D-34DB-4E89-9D47-E387F0C84E01@gmx.net> Date: Mon, 28 Mar 2011 13:54:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D885482.2050006@ninebynine.org> <6266.1300784475.434865@puncture> <3F2B4909-DE99-4189-98BC-5E9DDCE3CAC5@gmx.net> <4126.1300977355.111049@puncture> <498C386D-34DB-4E89-9D47-E387F0C84E01@gmx.net> To: Dave Cridland X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Pete Resnick , Hannes Tschofenig , Graham Klyne , Dave Crocker , General discussion of application-layer protocols Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 11:53:03 -0000 Dave,=20 I just found this quote on "Professional XMPP Programming with = JavaScript and jQuery" http://professionalxmpp.com/=20 " The book's quite inspiring. Very few books on programming make me want = to actually program something. " =97Dave Cridland, Isode Is this a different Dave Cridland? For those who have not read through the book it talks about how to = implement XMPP-based protocols in JavaScript.=20 Ciao Hannes On Mar 26, 2011, at 8:27 AM, Hannes Tschofenig wrote: >=20 > On Mar 24, 2011, at 4:35 PM, Dave Cridland wrote: >=20 >> Sadly, probably very unlikely. Who's going to provide the kind of = leadership we'd need to have a coherent architecture for the internet, = instead of one that emerges driven by a few service providers? >=20 > I guess you are touching a much larger issue that has very little todo = with the Web as such. You are essentially asking me (or the IAB) to get = rid of the big players in the market place. Ideally, you want to have = lots of small or medium size players but no one that dominates (like = Facebook does for social networks or Twitter does for microblogging).=20 >=20 > Changing technical specifications will not help you to get to such a = desired state.=20 >=20 > Ciao > Hannes >=20 From dave@cridland.net Mon Mar 28 05:45:30 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C5533A6A70 for ; Mon, 28 Mar 2011 05:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFjpDwk1SY8W for ; Mon, 28 Mar 2011 05:45:29 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 357573A6931 for ; Mon, 28 Mar 2011 05:45:29 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 8839F116808F; Mon, 28 Mar 2011 13:47:02 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7Q6YznJxcKg; Mon, 28 Mar 2011 13:47:00 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 8F5121168067; Mon, 28 Mar 2011 13:47:00 +0100 (BST) References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com> <4D885482.2050006@ninebynine.org> <6266.1300784475.434865@puncture> <3F2B4909-DE99-4189-98BC-5E9DDCE3CAC5@gmx.net> <4126.1300977355.111049@puncture> <498C386D-34DB-4E89-9D47-E387F0C84E01@gmx.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <4126.1301316420.581055@puncture> Date: Mon, 28 Mar 2011 13:47:00 +0100 From: Dave Cridland To: Hannes Tschofenig , Graham Klyne , Dave CROCKER , General discussion of application-layer protocols , Pete Resnick , Hannes Tschofenig Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:45:30 -0000 On Mon Mar 28 12:54:22 2011, Hannes Tschofenig wrote: > Is this a different Dave Cridland? > > No, same one. > For those who have not read through the book it talks about how to > implement XMPP-based protocols in JavaScript. That's a delightfully simplified view of that book, but more accurately, it discusses using an existing XMPP library (Strophe.js) which communicates over BOSH (an open-standard method for wrapping bidirectional streams in HTTP POST requests) to create web applications which operate over standards-based protocols. In other words, it's discussing using open-standards in the web environment. It doesn't talk about throwing out the very notion of open-standards. As I said before, your suggestion that one could use Strophe.js instead of open-standards was therefore highly misleading, and very much counter to your argument that end-user application protocols have no place in this world. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From tobias.gondrom@gondrom.org Mon Mar 28 06:35:36 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04F33A6841 for ; Mon, 28 Mar 2011 06:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.361 X-Spam-Level: X-Spam-Status: No, score=-95.361 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4cts+8MyQy0 for ; Mon, 28 Mar 2011 06:35:35 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id E40F83A6978 for ; Mon, 28 Mar 2011 06:35:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=GXQajhoGupUayHnPZqsJrcf7fTAA+hmBQfInkdwPpkf4IbISAXF3xDYUxMjs3qQ1T5Um+P4oultTQk6fglgBeEsYiYcR7lD2TYELn5XUodokZGEUS5IeCi6a/BblTfFj; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:X-Enigmail-Version:Content-Type; Received: (qmail 1950 invoked from network); 28 Mar 2011 15:36:31 +0200 Received: from dhcp-573b.meeting.ietf.org (HELO seraphim.heaven) (130.129.87.59) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 28 Mar 2011 15:36:31 +0200 Message-ID: <4D90812E.7020506@gondrom.org> Date: Mon, 28 Mar 2011 13:38:06 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: apps-discuss@ietf.org X-Priority: 4 (Low) X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------020802010408030700030008" Subject: [apps-discuss] FYI: Presentation on "do-not-track" in websec meeting on Wednesday X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:35:36 -0000 This is a multi-part message in MIME format. --------------020802010408030700030008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, as we did not have time at the apps area meeting today for open mic, but it might be of interest for the broader app community: FYI there will be a presentation about "do-not-track" at the websec meeting on Wednesday 13:00 in Congress Hall III. http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt Best regards, Tobias -------- Original Message -------- Subject: [websec] Fwd: I-D ACTION: draft-mayer-do-not-track-00.txt Date: Thu, 17 Mar 2011 13:27:30 +0000 From: Alissa Cooper To: websec@ietf.org FYI for those that want to have a look -- this draft is on the agenda for the websec meeting in Prague. There has been a bit of discussion of the draft taking place on the ietf-privacy mailing list: http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00004.html . Alissa Begin forwarded message: > A new Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Do Not Track: A Universal Third-Party Web > Tracking Opt Out > Author(s) : J. Mayer, et al > Filename : draft-mayer-do-not-track-00.txt > Pages : 6 > Date : 2011-03-07 > > This document defines the syntax and semantics of Do Not Track, an > HTTP header-based mechanism that enables users to express > preferences > about third-party web tracking. It also provides a standard for how > web services should comply with such user preferences. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec --------------020802010408030700030008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

as we did not have time at the apps area meeting today for open mic, but it might be of interest for the broader app community: FYI there will be a presentation about "do-not-track" at the websec meeting on Wednesday 13:00 in Congress Hall III.

http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt

Best regards, Tobias



-------- Original Message --------
Subject: [websec] Fwd: I-D ACTION: draft-mayer-do-not-track-00.txt
Date: Thu, 17 Mar 2011 13:27:30 +0000
From: Alissa Cooper <acooper@cdt.org>
To: websec@ietf.org 


FYI for those that want to have a look -- this draft is on the agenda  
for the websec meeting in Prague.

There has been a bit of discussion of the draft taking place on the  
ietf-privacy mailing list: http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00004.html 
.

Alissa

Begin forwarded message:

> A new Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
>
>    Title         : Do Not Track: A Universal Third-Party Web  
> Tracking Opt Out
>    Author(s)     : J. Mayer, et al
>    Filename      : draft-mayer-do-not-track-00.txt
>    Pages         : 6
>    Date          : 2011-03-07
>
> This document defines the syntax and semantics of Do Not Track, an
>   HTTP header-based mechanism that enables users to express  
> preferences
>   about third-party web tracking.  It also provides a standard for how
>   web services should comply with such user preferences.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/













_______________________________________________
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
--------------020802010408030700030008-- From stpeter@stpeter.im Tue Mar 29 15:49:35 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11E028C0FF for ; Tue, 29 Mar 2011 15:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HRqz+e52N3T for ; Tue, 29 Mar 2011 15:49:34 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 96C5328C0F4 for ; Tue, 29 Mar 2011 15:49:34 -0700 (PDT) Received: from dhcp-12cb.meeting.ietf.org (dhcp-12cb.meeting.ietf.org [130.129.18.203]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D528D40022 for ; Tue, 29 Mar 2011 16:52:55 -0600 (MDT) Message-ID: <4D92625E.70804@stpeter.im> Date: Wed, 30 Mar 2011 00:51:10 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050002030705000900050301" Subject: [apps-discuss] Fwd: Fwd: discussion about timezone database X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 22:49:35 -0000 This is a cryptographically signed message in MIME format. --------------ms050002030705000900050301 Content-Type: multipart/mixed; boundary="------------040802080608000407010409" This is a multi-part message in MIME format. --------------040802080608000407010409 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Another reminder in case you've forgotten. :) -------- Original Message -------- Subject: Fwd: discussion about timezone database Date: Sun, 27 Mar 2011 13:56:39 +0200 From: Peter Saint-Andre To: apps-discuss@ietf.org This is just a reminder for folks in the apps area... -------- Original Message -------- Subject: discussion about timezone database Date: Sun, 27 Mar 2011 13:55:23 +0200 From: Peter Saint-Andre To: IETF discussion list Folks, there will be a discussion of draft-lear-iana-timezone-database and related issues this Wednesday at IETF 80 in Prague. The room will be Karlin 1 and the time slot is 08:00-09:00 local time. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------040802080608000407010409 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSWV0ZiBt YWlsaW5nIGxpc3QKSWV0ZkBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lldGYKCg== --------------040802080608000407010409-- --------------ms050002030705000900050301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMy OTIyNTExMFowIwYJKoZIhvcNAQkEMRYEFPpX1qrisyL4dNrzqXBoeU49JGeRMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQA6pp156rXOnVKcByyGlXwXBLemSuVolir2yBj7xiS03Q5+sYyHeDLRkJG1 KdMalQU+shWFnzi0wb4kU68L7URGEI/meU3mYxkTj2AFm9a5sCdsUp4+4mF0fzW0ijmLhMFQ oeXorULqkcfzD7r4+BPbpZF/Q7O1ySgbqnUz/Dlhdve/3tvfOU+SSN1QWiwrDFRseDJx0oes 5i3BspKHEQ7Z1318coqtYa4NGsVFJ3JD2YTvu4D8AYiiAPA+aVLTIgGTbmr4piPUoWiyTZRa LS4ELddamXq4oOeTEbIx2ZBuj83RSqLwCBqi4oJgHhuGGEk9CmGdkXRKsKiVNzPMQr9TAAAA AAAA --------------ms050002030705000900050301-- From dhc@dcrocker.net Wed Mar 30 01:06:49 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 644C328C0EF for ; Wed, 30 Mar 2011 01:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vDAJN+5e9pv for ; Wed, 30 Mar 2011 01:06:48 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 98D003A6B32 for ; Wed, 30 Mar 2011 01:06:48 -0700 (PDT) Received: from [130.129.87.14] (dhcp-570e.meeting.ietf.org [130.129.87.14]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p2U88KSS019247 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 30 Mar 2011 01:08:27 -0700 Message-ID: <4D92E4EF.5070101@dcrocker.net> Date: Wed, 30 Mar 2011 10:08:15 +0200 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Apps Discuss References: <20110307204522.19709.7100.idtracker@localhost> <347C4029-DF05-4A7C-B88D-C7F270882C4B@mnot.net> <8B0A9FCBB9832F43971E38010638454F0400BF05F5@SISPE7MB1.commscope.com> <90C41DD21FB7C64BB94121FBBC2E7234465642FC44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0451876D-1582-4831-B258-C3AC6367CB3A@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234465642FC48@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234465642FEFF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D8CEE14.9080807@redhat.com> <4D8F403C.2050208@dcrocker.net> <4D90E027.4090801@redhat.com> <4D91960D.8020600@dcrocker.net> <4D91FC7F.20009@redhat.com> In-Reply-To: <4D91FC7F.20009@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 30 Mar 2011 01:08:27 -0700 (PDT) Subject: [apps-discuss] DOSETA discussion list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:06:49 -0000 Apologies for not having announced this during the Monday morning Apps Area presentation. The discussion list for DOSETA is at: d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net