From stpeter@stpeter.im Thu Apr 1 11:58:44 2010 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 9ED2F3A697B for ; Thu, 1 Apr 2010 11:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 MaOP+YhAxnzf for ; Thu, 1 Apr 2010 11:58:42 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1D5453A6A6F for ; Thu, 1 Apr 2010 11:58:40 -0700 (PDT) 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 7EECC40D3A; Thu, 1 Apr 2010 12:59:11 -0600 (MDT) Message-ID: <4BB4ECFD.9090307@stpeter.im> Date: Thu, 01 Apr 2010 12:59:09 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: weighting transports X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030302040406000506010409" 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, 01 Apr 2010 18:58:44 -0000 This is a cryptographically signed message in MIME format. --------------ms030302040406000506010409 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sometimes a client needs to determine which transport or technology an application server prefers for a given service type. For examples, an email service might be provided via both POP and IMAP or a website might be available via both TCP and SCTP. The approach taken in draft-daboo-srv-email is to check multiple SRV records (here IMAP would be preferred): _imap._tcp SRV 0 1 143 imap.example.com. _pop3._tcp SRV 10 1 110 pop3.example.com. The approach taken in draft-yourtchenko-tran-announce-dns is to define a new DNS RR (here SCTP would be preferred): _http.www XPORT 5 _sctp XPORT 9 _tcp I think it would be good to come to rough consensus (if possible) on a preferred approach in the Applications Area. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms030302040406000506010409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDQwMTE4NTkwOVowIwYJKoZIhvcNAQkEMRYEFCmVGhrYtYYFrzv4gaFl IK5s68w/MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEANgPTyr/Q1l8eZ6uopMMPPY4CzPfx2KXZgs6jluaS 64fHybux528cJ6x9rvdYNx/ixFR5APVJiK2nLmF2kCTyFdfdYoJYTp+QlEtGdlG1PEmzbiKQ RCrY4lrPw8WLgbHVfGu8uAW6NScO8W8HfkITplcle42s5qwaq58LKiwxm1a5PZ60KcGYV0lY JLnvAYnFm0soMx9IFfXe9nYm4DtWI0XhPyVQXWjb26m1FOayE8OVQsL229hP965b/ErmfdhZ rdxegpQkY8YlIZ6XviefNneGoObn420fwdnwAbUs3qzcFTDPyDodIx39zWd4qfdPW+MfLJJ1 5NNhjy2UkpOy6gAAAAAAAA== --------------ms030302040406000506010409-- From tim.kosse@filezilla-project.org Thu Apr 1 12:32:02 2010 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 35C1C3A69BA for ; Thu, 1 Apr 2010 12:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.019 X-Spam-Level: X-Spam-Status: No, score=0.019 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, 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 r19ESDlCyCLa for ; Thu, 1 Apr 2010 12:32:01 -0700 (PDT) Received: from filezilla-project.org (cl-1464.dus-01.de.sixxs.net [IPv6:2a01:198:200:5b7::2]) by core3.amsl.com (Postfix) with ESMTP id 45B4D3A6836 for ; Thu, 1 Apr 2010 12:32:01 -0700 (PDT) Received: from [2a01:198:458::59] by filezilla-project.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NxQ7w-00048D-OU; Thu, 01 Apr 2010 21:32:29 +0200 Message-ID: <4BB4F4C5.6070909@filezilla-project.org> Date: Thu, 01 Apr 2010 21:32:21 +0200 From: Tim Kosse User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Daniel Stenberg Subject: Re: FTP Extensions for Cryptographic Hashes (draft-bryan-ftp-hash) References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC93D1AC241D49ABE1F02F535" Cc: =?UTF-8?B?QWxmcmVkIEjDjm5lcw==?= , john+ietf@jck.com, apps-discuss@ietf.org 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, 01 Apr 2010 19:32:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC93D1AC241D49ABE1F02F535 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2010-03-24 22:59, Daniel Stenberg wrote: > You use 550 as response code when the user isn't allowed to use the HAS= H > command, but I find that 550 is otherwise often used for file-not-found= > in both SIZE, RETR and other responses. It is very common for servers to return 550 for "Permission/access denied". Even RFC 959 gives an example with a "550 Access denied" reply to STOR. Also, RFC 3659 states that a 550 reply to SIZE "MUST NOT be taken by the client as an indication that the file cannot be transferred [...] A server may generate this error for other reasons [...]" > Wouldn't it make sense to have a "file not found" response for when you= > try to HASH a non-existing file? Wouldn't it make sense to re-use the > same error code (550) for that as other command use? Yes, for "file not found" 550 should be used. > Maybe the "HASH not allowed" case can use 552 or 553? If I interpret RFC 959 correctly, 550 should be used for all errors not having a dedicated 55z reply code. It gives 552 as "Exceeded storage allocation" and 553 as "File name not allowed". That pretty much rules out 552 for "permission denied" and 553 does not seem fitting either. So I would just use 550 for both "File not found" as well as "Permission denied". Frankly said, I doubt that FTP clients would even care about a difference. It's possible to create FTP clients that only care about the first digit of a reply, whereas a person would always look at the text and not the exact code. Regards, Tim Kosse --------------enigC93D1AC241D49ABE1F02F535 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAku09MgACgkQ8N9+lcqiUkV3EQCgjW1oiq4D8Ll2P9YgjD5d6WUw 3r8An3L3in3nQoRyTy4T99NExr1bF2aT =Mg7F -----END PGP SIGNATURE----- --------------enigC93D1AC241D49ABE1F02F535-- From A.Hoenes@TR-Sys.de Thu Apr 1 12:54:27 2010 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 DA9073A6A4C for ; Thu, 1 Apr 2010 12:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.818 X-Spam-Level: X-Spam-Status: No, score=-94.818 tagged_above=-999 required=5 tests=[AWL=0.942, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, 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 i0cT6Bjd0BEx for ; Thu, 1 Apr 2010 12:54:26 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id C5CAB3A6A22 for ; Thu, 1 Apr 2010 12:54:25 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA106811668; Thu, 1 Apr 2010 21:54:28 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA28916; Thu, 1 Apr 2010 21:54:26 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004011954.VAA28916@TR-Sys.de> Subject: draft-bryan-ftp-hash-00 -- items for discussion To: apps-discuss@ietf.org Date: Thu, 1 Apr 2010 21:54:26 +0200 (MESZ) In-Reply-To: References: <201003231642.RAA04676@TR-Sys.de> X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit 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, 01 Apr 2010 19:54:28 -0000 I have been asked to respin on apps-discuss a summary of concerns raised in the pre-draft stage for draft-bryan-ftp-hash-00 and communicated to the authors after draft submisison. Here we go ... -------- forwarded content of message to the authors ------- It looks like the concerns raised so far have not been adressed. [ Thus, the first part of Appendix C, which pretends "no known issues", sounds ironical. :-) ] In particular: a) untypical use of a command with a file path argument *and* another argument -- consider using: OPTS HASH HASH b) underspecification of the representation of the file that shall undergo the hash calculation; a canonical form of the file is essential here for interoperability; I already have discussed some of the options that came to my mind: using the current transfer mode settings, defining a specific overriding set of mode settings, or requiring a single specific set of mode settings to be active (or a small choice of such). I cannot imagine how verification would be possible without a well defined canonical file representation in a heterogenous systems environment where e.g. one system uses record-oriented file storage and another one uses byte-stream storage with either or convention, one system pads records with blanks to an alignment boundary and another system truncates trailing blanks on file lines, ... (all that behavior exists in my office!) Further, I'd like to draw your attention to RFC 5797 and the FTP Commands and Extensions IANA Registry it has established now, at ). So you might wish to amend your proposal with substantial IANA considerations for the registration of the proposed extension and the associated FEAT strings. Also, it might make sense to give reference to prior work; I'm aware of an old expired I-D, draft-twine-ftpmd5-00, May 2002. Typos: - Abstract: s/intergrity/integrity/ - Sect.1: s/from a FTP server/from an FTP server/ Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From anthonybryan@gmail.com Thu Apr 1 14:10:49 2010 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 747863A698D for ; Thu, 1 Apr 2010 14:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.431 X-Spam-Level: * X-Spam-Status: No, score=1.431 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 Y9ifUKHJ6qNv for ; Thu, 1 Apr 2010 14:10:47 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id CFA473A6888 for ; Thu, 1 Apr 2010 14:10:46 -0700 (PDT) Received: by gyh4 with SMTP id 4so659206gyh.31 for ; Thu, 01 Apr 2010 14:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FhcWLjwLqGHactyWSAi59e0d1Bfj8DEaNmtb9LTijsM=; b=teKuLN7KZf2LBZIM0UJFhxnaARtAWrN6Y/CqxKGUGg9rbIbGdr0RAuRCuRVF7wzJPJ ebjjDERPZEeMYr+5BPcrV/p4m3xxojMUMPwJP05lPzGriOyunZr2QtPdml84tn8c1N+d bsNF8/WdELrk2WLtDjY2pCKLD3IB7LuvRf894= 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=jxxwCgUWyICGW0NOokQnHffqDkSBwXINXp/YhgGJUrHdnSDZjJNiJOXCnr5f5hb2yc rPARr2P8/Z2IyEg0QpEBVi3DrmCvz2uxf9FEqEMhp9rtJvkUuhW/RqfPsqfF+TVqXu7I 3gAiwZ11RwfdQ+W9LZZdMnzGbr7Zt/Oil6Z/g= MIME-Version: 1.0 Received: by 10.231.144.70 with HTTP; Thu, 1 Apr 2010 14:11:15 -0700 (PDT) In-Reply-To: <201004011954.VAA28916@TR-Sys.de> References: <201003231642.RAA04676@TR-Sys.de> <201004011954.VAA28916@TR-Sys.de> Date: Thu, 1 Apr 2010 17:11:15 -0400 Received: by 10.101.184.7 with SMTP id l7mr3453557anp.214.1270156275734; Thu, 01 Apr 2010 14:11:15 -0700 (PDT) Message-ID: Subject: Re: draft-bryan-ftp-hash-00 -- items for discussion From: Anthony Bryan To: =?ISO-8859-1?Q?Alfred_H=CEnes?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org 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, 01 Apr 2010 21:10:49 -0000 On Thu, Apr 1, 2010 at 3:54 PM, Alfred H=CEnes wrote: > I have been asked to respin on apps-discuss a summary of concerns > raised in the pre-draft stage for draft-bryan-ftp-hash-00 and > communicated to the authors after draft submisison. > > Here we go ... Thanks, Alfred. > -------- forwarded content of message to the authors ------- > > It looks like the concerns raised so far have not been adressed. > [ Thus, the first part of Appendix C, which pretends "no known issues", > =A0sounds ironical. =A0:-) =A0] > > In particular: > > a) untypical use of a command with a file path argument *and* > =A0 another argument -- consider using: > =A0 =A0 =A0 =A0OPTS HASH > =A0 =A0 =A0 =A0HASH > > b) underspecification of the representation of the file that shall > =A0 undergo the hash calculation; a canonical form of the file is > =A0 essential here for interoperability; I already have discussed > =A0 some of the options that came to my mind: using the current > =A0 transfer mode settings, defining a specific overriding set of > =A0 mode settings, or requiring a single specific set of mode > =A0 settings to be active (or a small choice of such). > =A0 I cannot imagine how verification would be possible without > =A0 a well defined canonical file representation in a heterogenous > =A0 systems environment where e.g. one system uses record-oriented > =A0 file storage and another one uses byte-stream storage with either > =A0 or convention, one system pads records with blanks > =A0 to an alignment boundary and another system truncates trailing > =A0 blanks on file lines, ... (all that behavior exists in my office!) We'll work on these. Other issues Daniel Stenberg has mentioned that we will address: - Should there be a way to request a partial file hash (similar to Content-MD5)? [At least one of the nonstandard hash commands supports this.] - Correct response code to use for completion and errors. - Need to include some more general advice on algorithms just in case algorithm X is found to be broken the day after this draft is released. - The FTP server's right to refuse to calculate the hash is of course important to help against DOS risks. > Further, I'd like to draw your attention to RFC 5797 and the > FTP Commands and Extensions IANA Registry it has established now, at > =A0 =A0 =A0 =A0 =A0 =A0ftp-commands-extensions.xhtml> ). > So you might wish to amend your proposal with substantial IANA > considerations for the registration of the proposed extension and > the associated FEAT strings. Ah yes, here's what we have now: 5. IANA Considerations This new command is added to the "FTP Commands and Extensions" registry created by [RFC5797]. Command Name: HASH Description: Cryptographic Hash of a file FEAT String: HASH Command Type: Service execution Conformance Requirements: Optional Reference: This specification > Also, it might make sense to give reference to prior work; > I'm aware of an old expired I-D, draft-twine-ftpmd5-00, May 2002. Didn't know about that, added it. Apache Ftp Server supports it. I've also been told that wuftpd supports SITE CHECKSUM. Here is the expanded list of software that supports a nonstandard FTP hash type command (XMD5, XSHA1, SITE SHOHASH, etc): * Akamai NetStorage * Apache Ftp Server (supports draft-twine-ftpmd5) * Cerberus FTP server * FileCOPA FTP Server * FireFTP * Gene6 FTP Server * GoldenGate FTP (Ftp Full Java Server) * IceWarp FTP Server * JAFS * MOVEit DMZ * Nofeel FTP server * Null FTP * ProFTPD module mod_digest * SmartFTP client * Starksoft Ftp Component for .NET / Mono * RaidenFTPD32 FTP server * WS_FTP client / server * wuftpd ('SITE CHECKMETHOD' and 'SITE CHECKSUM') * zFTPServer --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From eran@hueniverse.com Thu Apr 1 16:23:35 2010 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 262B03A6877 for ; Thu, 1 Apr 2010 16:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 H3fgq1eBMXFl for ; Thu, 1 Apr 2010 16:23:33 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BF26E3A67FD for ; Thu, 1 Apr 2010 16:23:32 -0700 (PDT) Received: (qmail 5802 invoked from network); 1 Apr 2010 23:24:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Apr 2010 23:24:03 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 1 Apr 2010 16:24:02 -0700 From: Eran Hammer-Lahav To: Peter Saint-Andre Date: Thu, 1 Apr 2010 16:23:50 -0700 Subject: Re: weighting transports Thread-Topic: weighting transports Thread-Index: AcrR8mnIc3yASvJ9Sp27lrtD5oDzlA== Message-ID: <8FA27CA0-37DD-420B-A7D6-A187618FFCE5@hueniverse.com> References: <4BB4ECFD.9090307@stpeter.im> In-Reply-To: <4BB4ECFD.9090307@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" 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, 01 Apr 2010 23:23:35 -0000 The discussion should not be limited to DNS. I'm sure there will soon =20 be other protocol to access mail that are HTTP based. EHL On Apr 1, 2010, at 14:59, "Peter Saint-Andre" =20 wrote: > Sometimes a client needs to determine which transport or technology an > application server prefers for a given service type. For examples, an > email service might be provided via both POP and IMAP or a website =20 > might > be available via both TCP and SCTP. > > The approach taken in draft-daboo-srv-email is to check multiple SRV > records (here IMAP would be preferred): > > _imap._tcp SRV 0 1 143 imap.example.com. > _pop3._tcp SRV 10 1 110 pop3.example.com. > > The approach taken in draft-yourtchenko-tran-announce-dns is to =20 > define a > new DNS RR (here SCTP would be preferred): > > _http.www XPORT 5 _sctp > XPORT 9 _tcp > > I think it would be good to come to rough consensus (if possible) =20 > on a > preferred approach in the Applications Area. > > Peter > > --=20 > Peter Saint-Andre > https://stpeter.im/ > > > > > From Nicolas.Williams@sun.com Thu Apr 1 16:46:58 2010 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 E79683A686B for ; Thu, 1 Apr 2010 16:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.239 X-Spam-Level: X-Spam-Status: No, score=-5.239 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 IhP5NeB5jnNT for ; Thu, 1 Apr 2010 16:46:58 -0700 (PDT) Received: from rcsinet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by core3.amsl.com (Postfix) with ESMTP id 01F2C3A67FD for ; Thu, 1 Apr 2010 16:46:57 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o31NlQLv015100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Apr 2010 23:47:27 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o31FHhcx015908; Thu, 1 Apr 2010 23:47:25 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 140172581270165557; Thu, 01 Apr 2010 16:45:57 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Apr 2010 16:45:56 -0700 Date: Thu, 1 Apr 2010 18:45:52 -0500 From: Nicolas Williams To: Eran Hammer-Lahav Subject: Re: weighting transports Message-ID: <20100401234551.GO4225@Sun.COM> References: <4BB4ECFD.9090307@stpeter.im> <8FA27CA0-37DD-420B-A7D6-A187618FFCE5@hueniverse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8FA27CA0-37DD-420B-A7D6-A187618FFCE5@hueniverse.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BB5308E.001C,ss=1,fgs=0 Cc: "apps-discuss@ietf.org" 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, 01 Apr 2010 23:46:59 -0000 On Thu, Apr 01, 2010 at 04:23:50PM -0700, Eran Hammer-Lahav wrote: > The discussion should not be limited to DNS. I'm sure there will soon > be other protocol to access mail that are HTTP based. DNS is the discovery protocol. I think the idea is that you'd do some set of DNS queries and then pick a result. With a new RR you might do a single query. With SRV RRs you'd have to do one query per-transport. So if you have IMAP, POP3, MailDAV (just made that up), and even mbox-over-NFS (even more contrived), some of these over TCP and SCTP, then you might have to do this many queries before you give up or pick one: _maildav._tcp _imap._tcp _imap._sctp _pop3._tcp _nfsmbox._tcp (would we want to have _nfsv4/_nfsv3 labels here?) That's a lot of queries. In practice we all just configure our MUAs and that's that. And even if we wanted to do discovery our MUAs would do at most two or three queries (to heck with SCTP, and search for just two or three application protocols). IMO three queries is tolerable. Much more and an "XPORT" RR begins to sound highly desirable. Nico -- From alexey.melnikov@isode.com Thu Apr 1 19:28:17 2010 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 E7F403A6A41 for ; Thu, 1 Apr 2010 19:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.539 X-Spam-Level: X-Spam-Status: No, score=0.539 tagged_above=-999 required=5 tests=[AWL=0.768, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 Vf4aPHIsBNtp for ; Thu, 1 Apr 2010 19:28:17 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 124113A6403 for ; Thu, 1 Apr 2010 19:28:17 -0700 (PDT) Received: from [92.40.21.159] (92.40.21.159.sub.mbb.three.co.uk [92.40.21.159]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 2 Apr 2010 03:18:53 +0100 Message-ID: <4BB55409.4090008@isode.com> Date: Fri, 02 Apr 2010 03:18:49 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: Nicolas Williams Subject: Re: weighting transports References: <4BB4ECFD.9090307@stpeter.im> <8FA27CA0-37DD-420B-A7D6-A187618FFCE5@hueniverse.com> <20100401234551.GO4225@Sun.COM> In-Reply-To: <20100401234551.GO4225@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" 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, 02 Apr 2010 02:28:18 -0000 Nicolas Williams wrote: > On Thu, Apr 01, 2010 at 04:23:50PM -0700, Eran Hammer-Lahav wrote: > >> The discussion should not be limited to DNS. I'm sure there will soon >> be other protocol to access mail that are HTTP based. >> > > DNS is the discovery protocol. > > I think the idea is that you'd do some set of DNS queries and then pick > a result. With a new RR you might do a single query. With SRV RRs > you'd have to do one query per-transport. > > So if you have IMAP, POP3, MailDAV (just made that up), and even > mbox-over-NFS (even more contrived), some of these over TCP and SCTP, > then you might have to do this many queries before you give up or pick > one: > > _maildav._tcp > _imap._tcp > _imap._sctp > _pop3._tcp > _nfsmbox._tcp (would we want to have _nfsv4/_nfsv3 labels here?) > > That's a lot of queries. In practice we all just configure our MUAs and > that's that. And even if we wanted to do discovery our MUAs would do at > most two or three queries (to heck with SCTP, and search for just two or > three application protocols). IMO three queries is tolerable. Much > more and an "XPORT" RR begins to sound highly desirable. > Right. I think we need to balance deployability of new RRs versa use of existing mechanisms. I would rather have a good enough solution now, than a better solution in 2 years and do nothing in short term. From Nicolas.Williams@sun.com Thu Apr 1 20:06:11 2010 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 9A14F3A6830 for ; Thu, 1 Apr 2010 20:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.625 X-Spam-Level: X-Spam-Status: No, score=-4.625 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, UNPARSEABLE_RELAY=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 c7P0TCVDwG81 for ; Thu, 1 Apr 2010 20:06:10 -0700 (PDT) Received: from rcsinet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by core3.amsl.com (Postfix) with ESMTP id AF23C3A67C0 for ; Thu, 1 Apr 2010 20:06:10 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o3236eS5022354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Apr 2010 03:06:41 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o31MMMgj009447; Fri, 2 Apr 2010 03:06:39 GMT Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 132316291270177552; Thu, 01 Apr 2010 20:05:52 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Apr 2010 20:05:51 -0700 Date: Thu, 1 Apr 2010 22:05:47 -0500 From: Nicolas Williams To: Alexey Melnikov Subject: Re: weighting transports Message-ID: <20100402030546.GP4225@Sun.COM> References: <4BB4ECFD.9090307@stpeter.im> <8FA27CA0-37DD-420B-A7D6-A187618FFCE5@hueniverse.com> <20100401234551.GO4225@Sun.COM> <4BB55409.4090008@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BB55409.4090008@isode.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BB55F40.0079,ss=1,fgs=0 Cc: "apps-discuss@ietf.org" 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, 02 Apr 2010 03:06:11 -0000 On Fri, Apr 02, 2010 at 03:18:49AM +0100, Alexey Melnikov wrote: > Right. > I think we need to balance deployability of new RRs versa use of > existing mechanisms. I would rather have a good enough solution now, > than a better solution in 2 years and do nothing in short term. Agreed. SRV may not be as cool, but it does the job. If the new thing will become painfully necessary then we should start now on getting it done. But I suspect that as new protocols come along they'll mostly obsolete older ones. MailDAV, done right, should displace POP3 for good, and eventually IMAP too, leaving us with a simpler discovery problem. From alexey.melnikov@isode.com Thu Apr 1 20:28:49 2010 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 783B43A691B for ; Thu, 1 Apr 2010 20:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.462 X-Spam-Level: X-Spam-Status: No, score=0.462 tagged_above=-999 required=5 tests=[AWL=0.691, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 jUsyy97zYxC0 for ; Thu, 1 Apr 2010 20:28:46 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 54C733A68AF for ; Thu, 1 Apr 2010 20:28:46 -0700 (PDT) Received: from [92.40.21.159] (92.40.21.159.sub.mbb.three.co.uk [92.40.21.159]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 2 Apr 2010 04:29:18 +0100 Message-ID: <4BB56488.30909@isode.com> Date: Fri, 02 Apr 2010 04:29:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: Nicolas Williams Subject: Re: weighting transports References: <4BB4ECFD.9090307@stpeter.im> <8FA27CA0-37DD-420B-A7D6-A187618FFCE5@hueniverse.com> <20100401234551.GO4225@Sun.COM> <4BB55409.4090008@isode.com> <20100402030546.GP4225@Sun.COM> In-Reply-To: <20100402030546.GP4225@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" 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, 02 Apr 2010 03:28:49 -0000 Nicolas Williams wrote: > On Fri, Apr 02, 2010 at 03:18:49AM +0100, Alexey Melnikov wrote: > >> Right. >> I think we need to balance deployability of new RRs versa use of >> existing mechanisms. I would rather have a good enough solution now, >> than a better solution in 2 years and do nothing in short term. >> > Agreed. SRV may not be as cool, but it does the job. If the new thing > will become painfully necessary then we should start now on getting it > done. But I suspect that as new protocols come along they'll mostly > obsolete older ones. Or the new discovery protocol may obsolete the old one. > MailDAV, done right, should displace POP3 for > good, and eventually IMAP too, We shall see about that ;-). > leaving us with a simpler discovery > problem. > From andy@hxr.us Fri Apr 2 06:29:53 2010 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 517B43A694F for ; Fri, 2 Apr 2010 06:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 iiAvlgUj6odv for ; Fri, 2 Apr 2010 06:29:52 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 709D13A69B5 for ; Fri, 2 Apr 2010 06:29:52 -0700 (PDT) Received: from zx80.arin.net ([::ffff:192.149.252.11]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 02 Apr 2010 09:30:24 -0400 id 015AC513.4BB5F170.00004563 Subject: Re: weighting transports Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Andrew Newton In-Reply-To: <8FA27CA0-37DD-420B-A7D6-A187618FFCE5@hueniverse.com> Date: Fri, 2 Apr 2010 09:30:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <05B16BF0-83CF-4A28-ADF0-E970423A9521@hxr.us> References: <4BB4ECFD.9090307@stpeter.im> <8FA27CA0-37DD-420B-A7D6-A187618FFCE5@hueniverse.com> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1077) Cc: apps-discuss@ietf.org 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, 02 Apr 2010 13:29:53 -0000 On Apr 1, 2010, at 14:59, "Peter Saint-Andre" =20 wrote: > Sometimes a client needs to determine which transport or technology an > application server prefers for a given service type. For examples, an > email service might be provided via both POP and IMAP or a website =20 > might > be available via both TCP and SCTP. >=20 > The approach taken in draft-daboo-srv-email is to check multiple SRV > records (here IMAP would be preferred): >=20 > _imap._tcp SRV 0 1 143 imap.example.com. > _pop3._tcp SRV 10 1 110 pop3.example.com. >=20 > The approach taken in draft-yourtchenko-tran-announce-dns is to =20 > define a > new DNS RR (here SCTP would be preferred): >=20 > _http.www XPORT 5 _sctp > XPORT 9 _tcp >=20 > I think it would be good to come to rough consensus (if possible) =20 > on a > preferred approach in the Applications Area. >=20 > Peter I glanced at both drafts and did not see a discussion about why neither = RFC 3958 nor RFC 4848 are sufficient for the purposes being described. = Perhaps that is a discussion I missed elsewhere. I believe Philip Hallam-Baker put forward a very similar SRV proposal = years ago but don't recall what happened to it. Personally, I think it is time for the IETF to consider a new record = type to simplify this type of DNS discovery if NAPTR and SRV records are = considered too cumbersome for this purpose. -andy= From dhc@dcrocker.net Fri Apr 2 09:39:41 2010 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 405813A68DB for ; Fri, 2 Apr 2010 09:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 s1qXms5uMQaj for ; Fri, 2 Apr 2010 09:39:40 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 095653A68AE for ; Fri, 2 Apr 2010 09:39:38 -0700 (PDT) Received: from [192.168.1.14] (adsl-67-127-191-90.dsl.pltn13.pacbell.net [67.127.191.90]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o32Ge6uq031683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Apr 2010 09:40:12 -0700 Message-ID: <4BB61DE1.9070601@dcrocker.net> Date: Fri, 02 Apr 2010 09:40:01 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Re: weighting transports References: <4BB4ECFD.9090307@stpeter.im> In-Reply-To: <4BB4ECFD.9090307@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10695/Fri Apr 2 04:02:09 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 02 Apr 2010 09:40:13 -0700 (PDT) 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: Fri, 02 Apr 2010 16:39:41 -0000 On 4/1/2010 11:59 AM, Peter Saint-Andre wrote: > I think it would be good to come to rough consensus (if possible) on a > preferred approach in the Applications Area. The premise of these mechanisms is that a random client needs to 'discover' the set of supported mechanisms at a random server. I add the 'random's in there because anything with prior arrangement is likely to include the necessary configuration information as part of the arrangement process. Adoption of a new mechanism like this requires compelling, immediate need. Do we see it now? Where? If there is no immediate need, why is anyone going to adopt it? So a mechanism like these needs to be needed by random client/server pairs, at Internet scale. Before deciding which mechanism is preferred, we ought to determine whether it is needed. Otherwise, we'd be standardizing based purely on theoretical, rather than actual, need, and that usually does not turn out well. Using a new RR creates a second adoption barrier. Although the cleanest approach for new types of queries, the track record for new RRs has been extremely poor. On the other hand, at the last IETF, I seem to recall hearing assurances that really, truly, finally, new RRs are no longer difficult to deploy widely. I've no idea whether this latest assurance is valid. If it is, that's great. But we ought to develop a broader sense of this point. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dwing@cisco.com Fri Apr 2 10:02:56 2010 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 969DA3A68EA for ; Fri, 2 Apr 2010 10:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.159 X-Spam-Level: X-Spam-Status: No, score=-9.159 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 h5GuDSmxcTlk for ; Fri, 2 Apr 2010 10:02:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9B2383A6898 for ; Fri, 2 Apr 2010 10:02:54 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8IAF/AtUurR7H+/2dsb2JhbACHV4EUkl5xnGiYYoUFBIMk X-IronPort-AV: E=Sophos;i="4.51,354,1267401600"; d="scan'208";a="507723692" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2010 17:03:28 +0000 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o32H3SJn022121; Fri, 2 Apr 2010 17:03:28 GMT From: "Dan Wing" To: , References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> Subject: RE: weighting transports Date: Fri, 2 Apr 2010 10:03:27 -0700 Message-ID: <002801cad286$6a77fee0$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4BB61DE1.9070601@dcrocker.net> Thread-Index: AcrSgz0I9o+ZvuukSj+TaTKIE2qlrwAAo74Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 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, 02 Apr 2010 17:02:56 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Dave CROCKER > Sent: Friday, April 02, 2010 9:40 AM > To: apps-discuss@ietf.org > Subject: Re: weighting transports > > > > On 4/1/2010 11:59 AM, Peter Saint-Andre wrote: > > I think it would be good to come to rough consensus (if > possible) on a > > preferred approach in the Applications Area. > > > The premise of these mechanisms is that a random client needs > to 'discover' the > set of supported mechanisms at a random server. I add the > 'random's in there > because anything with prior arrangement is likely to include > the necessary > configuration information as part of the arrangement process. > > Adoption of a new mechanism like this requires compelling, > immediate need. Do > we see it now? Where? HTTP over SCTP, http://tools.ietf.org/html/draft-wing-http-new-tech-00#section-3 -d > If there is no immediate need, why is > anyone going to adopt it? > > So a mechanism like these needs to be needed by random > client/server pairs, at > Internet scale. > > Before deciding which mechanism is preferred, we ought to > determine whether it > is needed. Otherwise, we'd be standardizing based purely on > theoretical, rather > than actual, need, and that usually does not turn out well. > > Using a new RR creates a second adoption barrier. Although > the cleanest > approach for new types of queries, the track record for new > RRs has been > extremely poor. On the other hand, at the last IETF, I seem > to recall hearing > assurances that really, truly, finally, new RRs are no longer > difficult to > deploy widely. I've no idea whether this latest assurance is > valid. If it is, > that's great. But we ought to develop a broader sense of this point. > > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From phoffman@imc.org Fri Apr 2 10:03:37 2010 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 56BFD3A68C2 for ; Fri, 2 Apr 2010 10:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.709 X-Spam-Level: X-Spam-Status: No, score=-3.709 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, 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 5o1T6vOQEfOA for ; Fri, 2 Apr 2010 10:03:36 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0CDB33A68EA for ; Fri, 2 Apr 2010 10:03:26 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o32H3qoc062638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Apr 2010 10:03:53 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4BB61DE1.9070601@dcrocker.net> References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> Date: Fri, 2 Apr 2010 10:03:51 -0700 To: dcrocker@bbiw.net, apps-discuss@ietf.org From: Paul Hoffman Subject: Re: weighting transports Content-Type: text/plain; charset="us-ascii" 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, 02 Apr 2010 17:03:37 -0000 At 9:40 AM -0700 4/2/10, Dave CROCKER wrote: >The premise of these mechanisms is that a random client needs to 'discover' the set of supported mechanisms at a random server. I add the 'random's in there because anything with prior arrangement is likely to include the necessary configuration information as part of the arrangement process. > >Adoption of a new mechanism like this requires compelling, immediate need. Do we see it now? Where? If there is no immediate need, why is anyone going to adopt it? > >So a mechanism like these needs to be needed by random client/server pairs, at Internet scale. I'm with Dave on this one. When reading the initial proposal, I could not think of a real reason for it to exist. It does *not* make service deployments easier unless the central party knows for sure that the client has the new capability, but I don't see a way to test that. What are the actual use cases? From dcrocker@bbiw.net Fri Apr 2 12:01:54 2010 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 61DBC3A6CBD for ; Fri, 2 Apr 2010 12:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 Zz4drlntX1nV for ; Fri, 2 Apr 2010 12:01:53 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 0A6AD3A6AC5 for ; Fri, 2 Apr 2010 11:34:31 -0700 (PDT) Received: from [192.168.1.14] (adsl-67-127-191-90.dsl.pltn13.pacbell.net [67.127.191.90]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o32IYx6r005320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Apr 2010 11:35:04 -0700 Message-ID: <4BB638CE.1080403@bbiw.net> Date: Fri, 02 Apr 2010 11:34:54 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dan Wing Subject: Re: weighting transports References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <002801cad286$6a77fee0$c6f0200a@cisco.com> In-Reply-To: <002801cad286$6a77fee0$c6f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10695/Fri Apr 2 04:02:09 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 02 Apr 2010 11:35:05 -0700 (PDT) Cc: apps-discuss@ietf.org 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, 02 Apr 2010 19:01:54 -0000 On 4/2/2010 10:03 AM, Dan Wing wrote: >> Adoption of a new mechanism like this requires compelling, >> immediate need. Do >> we see it now? Where? > > HTTP over SCTP, > http://tools.ietf.org/html/draft-wing-http-new-tech-00#section-3 Really? Is there a pressing, immediate problem in using HTTP over SCTP? Do we have a solid portion of the community currently suffering from the lack of a guidance mechanism to resolve this? And, by the way, the query mechanism has to be cheaper than a simple test of alternative transports. Trying an SCTP-based connection and then trying a TCP-based one is pretty cheap, particularly given the relatively long-term reality that querying the DNS will provide a negative response, since a random server's entries won't support this feature... And by the way, the proposals seem to be all-or-nothing for a domain name, rather than guiding towards different transports according to different criteria. For example, I suspect that choosing SCTP is more important fro some content than other? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dwing@cisco.com Fri Apr 2 12:26:53 2010 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 E40343A6B79 for ; Fri, 2 Apr 2010 12:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.694 X-Spam-Level: X-Spam-Status: No, score=-8.694 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, 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 o+zsLRNuS4ZB for ; Fri, 2 Apr 2010 12:26:52 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 93DE33A6B76 for ; Fri, 2 Apr 2010 11:53:45 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8IAK7ZtUurR7H+/2dsb2JhbACHV4EUkmBxm1GYY4UFBIMk X-IronPort-AV: E=Sophos;i="4.51,354,1267401600"; d="scan'208";a="109515254" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2010 18:54:19 +0000 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o32IsJC5014487; Fri, 2 Apr 2010 18:54:19 GMT From: "Dan Wing" To: "'Dave CROCKER'" References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <002801cad286$6a77fee0$c6f0200a@cisco.com> <4BB638CE.1080403@bbiw.net> Subject: RE: weighting transports Date: Fri, 2 Apr 2010 11:54:19 -0700 Message-ID: <00b001cad295$e6e04d20$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4BB638CE.1080403@bbiw.net> Thread-Index: AcrSkzx32r/9gfwLQY+mKEd3+RjOeQAAL6pA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: apps-discuss@ietf.org 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, 02 Apr 2010 19:26:54 -0000 > On 4/2/2010 10:03 AM, Dan Wing wrote: > >> Adoption of a new mechanism like this requires compelling, > >> immediate need. Do > >> we see it now? Where? > > > > HTTP over SCTP, > > http://tools.ietf.org/html/draft-wing-http-new-tech-00#section-3 > > Really? Is there a pressing, immediate problem in using HTTP > over SCTP? Do we > have a solid portion of the community currently suffering > from the lack of a guidance mechanism to resolve this? No, Dave, we don't. I am trying to get SCTP off the ground, and I am trying to avoid sending zillions of probes (SCTP INITs) to do it. > And, by the way, the query mechanism has to be cheaper than a > simple test of alternative transports. > > Trying an SCTP-based connection and > then trying a TCP-based one is pretty cheap, Yes, that is the plan short term and already discussed in draft-wing-http-new-tech-00. However, there can't be any delay between attempting SCTP versus attempting TCP -- or else we get into the exact problem we have today with poor-quality IPv6 connections (currently being discussed on dnsop). draft-yourtchenko-tran-announce-dns-01 is because we are worried about the longer term: when we need SCTP, TCP, SCTPoverUDP (for NAT or firewall traversal), SCTPoverTCP (for NAT or firewall traversal), and IPv6 and IPv4. That is a lot of probes. Throw in a new, fancy transport protocol, or a host trying all of its source addresses, and that is a lot of probes. > particularly given the relatively long-term > reality that querying the DNS will provide a negative > response, since a random server's entries won't support > this feature... An argument for negative caching in the DNS recursive resolvers. > And by the way, the proposals seem to be all-or-nothing for a > domain name, > rather than guiding towards different transports according to > different > criteria. For example, I suspect that choosing SCTP is more > important fro some > content than other? That can be accomplished -- XPORT is per-hostname, not per domainname. -d > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net From dcrocker@bbiw.net Fri Apr 2 13:33:37 2010 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 2772A3A6AFC for ; Fri, 2 Apr 2010 13:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, 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 uEPOXwHYmeXk for ; Fri, 2 Apr 2010 13:33:35 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id B144A3A6C4D for ; Fri, 2 Apr 2010 13:11:04 -0700 (PDT) Received: from [192.168.1.14] (adsl-67-127-191-90.dsl.pltn13.pacbell.net [67.127.191.90]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o32KBXwF009597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Apr 2010 13:11:38 -0700 Message-ID: <4BB64F71.6080701@bbiw.net> Date: Fri, 02 Apr 2010 13:11:29 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dan Wing Subject: Re: weighting transports References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <002801cad286$6a77fee0$c6f0200a@cisco.com> <4BB638CE.1080403@bbiw.net> <00b001cad295$e6e04d20$c6f0200a@cisco.com> In-Reply-To: <00b001cad295$e6e04d20$c6f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10695/Fri Apr 2 04:02:09 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 02 Apr 2010 13:11:39 -0700 (PDT) Cc: apps-discuss@ietf.org 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, 02 Apr 2010 20:33:37 -0000 On 4/2/2010 11:54 AM, Dan Wing wrote: >> On 4/2/2010 10:03 AM, Dan Wing wrote: >>>> Adoption of a new mechanism like this requires compelling, immediate >>>> need. Do we see it now? Where? >>> >>> HTTP over SCTP, >>> http://tools.ietf.org/html/draft-wing-http-new-tech-00#section-3 >> >> Really? Is there a pressing, immediate problem in using HTTP over SCTP? >> Do we have a solid portion of the community currently suffering from the >> lack of a guidance mechanism to resolve this? > > No, Dave, we don't. I am trying to get SCTP off the ground, and I am trying > to avoid sending zillions of probes (SCTP INITs) to do it. Sorry, I thought you were responding to the point I made that you quoted, about compelling immediate need. Yours is an example of a double-dependency adoption barrier. It's not a question of whether the goal is worthy but of whether potential adopters will be sufficiently motivated to overcome both hurdles. Note that achieving utility is not a single-adopter issue. Adopters among clients and servers -- in sufficient number -- are needed, to achieve meaningful utility. >> And, by the way, the query mechanism has to be cheaper than a simple test >> of alternative transports. >> >> Trying an SCTP-based connection and then trying a TCP-based one is pretty >> cheap, > > Yes, that is the plan short term and already discussed in > draft-wing-http-new-tech-00. However, there can't be any delay between > attempting SCTP versus attempting TCP -- or else we get into the exact > problem we have today with poor-quality IPv6 connections (currently being > discussed on dnsop). V6 makes this a three-barrier adoption problem. > draft-yourtchenko-tran-announce-dns-01 is because we are worried about the > longer term: when we need SCTP, TCP, SCTPoverUDP (for NAT or firewall > traversal), SCTPoverTCP (for NAT or firewall traversal), and IPv6 and IPv4. > That is a lot of probes. Throw in a new, fancy transport protocol, or a host > trying all of its source addresses, and that is a lot of probes. As we've seen with v6, folks do not deploy and use new mechanisms out of a sense of possible loong-term need. >> particularly given the relatively long-term reality that querying the DNS >> will provide a negative response, since a random server's entries won't >> support this feature... > > An argument for negative caching in the DNS recursive resolvers. That helps with re-queries, not new queries. The rate of new queries by a client tends to be significant. >> And by the way, the proposals seem to be all-or-nothing for a domain name, >> rather than guiding towards different transports according to different >> criteria. For example, I suspect that choosing SCTP is more important fro >> some content than other? > > That can be accomplished -- XPORT is per-hostname, not per domainname. Except that I describe a per-service differentiation of need, not per-host. Maybe that's not the right chacterization, but it highlights the need to be very careful about making sure that a proposed facility really does satisfy real-world usage scenarios, including proper granularity. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dwing@cisco.com Fri Apr 2 14:30:06 2010 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 9F0423A6AC6 for ; Fri, 2 Apr 2010 14:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.628 X-Spam-Level: X-Spam-Status: No, score=-8.628 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, 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 dfjoioRaceNx for ; Fri, 2 Apr 2010 14:30:05 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3D7D63A6A3E for ; Fri, 2 Apr 2010 14:11:40 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQNAAf6tUurR7H+/2dsb2JhbACHV4EUjGULAoVwcZsYmF6FBQSDJA X-IronPort-AV: E=Sophos;i="4.51,355,1267401600"; d="scan'208";a="507860499" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2010 21:12:14 +0000 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o32LCEwB027047; Fri, 2 Apr 2010 21:12:14 GMT From: "Dan Wing" To: "'Dave CROCKER'" References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <002801cad286$6a77fee0$c6f0200a@cisco.com> <4BB638CE.1080403@bbiw.net> <00b001cad295$e6e04d20$c6f0200a@cisco.com> <4BB64F71.6080701@bbiw.net> Subject: RE: weighting transports Date: Fri, 2 Apr 2010 14:12:14 -0700 Message-ID: <013701cad2a9$2b1605d0$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4BB64F71.6080701@bbiw.net> Thread-Index: AcrSoLb7OF2TDcECSaWmHxNkXUTWPgABzdMg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: apps-discuss@ietf.org 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, 02 Apr 2010 21:30:06 -0000 > On 4/2/2010 11:54 AM, Dan Wing wrote: > >> On 4/2/2010 10:03 AM, Dan Wing wrote: > >>>> Adoption of a new mechanism like this requires > compelling, immediate > >>>> need. Do we see it now? Where? > >>> > >>> HTTP over SCTP, > >>> http://tools.ietf.org/html/draft-wing-http-new-tech-00#section-3 > >> > >> Really? Is there a pressing, immediate problem in using > HTTP over SCTP? > >> Do we have a solid portion of the community currently > suffering from the > >> lack of a guidance mechanism to resolve this? > > > > No, Dave, we don't. I am trying to get SCTP off the > ground, and I am trying > > to avoid sending zillions of probes (SCTP INITs) to do it. > > > Sorry, I thought you were responding to the point I made that > you quoted, about > compelling immediate need. Yours is an example of a > double-dependency adoption > barrier. > > It's not a question of whether the goal is worthy but of whether > potential adopters will be sufficiently motivated to overcome > both hurdles. > Note that achieving utility is not a single-adopter issue. > Adopters among > clients and servers -- in sufficient number -- are needed, to > achieve meaningful utility. An already-raised point, on the TAE mailing list and our Bar-BoFs, has been how we might avoid/reduce the combinatorial explosion of lots of probes. draft-yourtchenko-tran-announce-dns is our response to that concern. You are saying the concern is not legitimate until there is an explosion, and that when the explosion occurs we (the IETF) should then worry about that combinatorial explosion and how to mitigate it. > >> And, by the way, the query mechanism has to be cheaper > than a simple test > >> of alternative transports. > >> > >> Trying an SCTP-based connection and then trying a > TCP-based one is pretty > >> cheap, > > > > Yes, that is the plan short term and already discussed in > > draft-wing-http-new-tech-00. However, there can't be any > delay between > > attempting SCTP versus attempting TCP -- or else we get > into the exact > > problem we have today with poor-quality IPv6 connections > (currently being > > discussed on dnsop). > > V6 makes this a three-barrier adoption problem. > > > draft-yourtchenko-tran-announce-dns-01 is because we are > worried about the > > longer term: when we need SCTP, TCP, SCTPoverUDP (for NAT > or firewall > > traversal), SCTPoverTCP (for NAT or firewall traversal), > and IPv6 and IPv4. > > That is a lot of probes. Throw in a new, fancy transport > protocol, or a host > > trying all of its source addresses, and that is a lot of probes. > > As we've seen with v6, folks do not deploy and use new > mechanisms out of a sense of possible loong-term need. I also do not expect anyone to deploy SCTP or DCCP from a sense of community-good. Rather, there are other reasons new transports provide value to applications (e.g., quicker response times) or to application developers (e.g., record oriented versus stream oriented). > >> particularly given the relatively long-term reality that > querying the DNS > >> will provide a negative response, since a random server's > entries won't > >> support this feature... > > > > An argument for negative caching in the DNS recursive resolvers. > > That helps with re-queries, not new queries. Negative caching does help with new queries, because many people use the same DNS recursive resolver (belonging to their ISP, or belonging to opendns.org or Google or whatever) and many people access the same popular websites (facebook, cnn, etc.). > The rate of new queries by a client tends to be significant. By that argument, probes would be costly. > >> And by the way, the proposals seem to be all-or-nothing > for a domain name, > >> rather than guiding towards different transports according > to different > >> criteria. For example, I suspect that choosing SCTP is > more important fro > >> some content than other? > > > > That can be accomplished -- XPORT is per-hostname, not per > > domainname. > > Except that I describe a per-service differentiation of need, > not per-host. I don't know what you mean by 'per-service', sorry. > Maybe that's not the right chacterization, but it highlights > the need to be very > careful about making sure that a proposed facility really > does satisfy > real-world usage scenarios, including proper granularity. An example would be helpful. -d From leslie@thinkingcat.com Fri Apr 2 15:16:36 2010 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 54E5D3A67FC; Fri, 2 Apr 2010 15:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.281 X-Spam-Level: * X-Spam-Status: No, score=1.281 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 p2LzE4sBrLV0; Fri, 2 Apr 2010 15:16:35 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 91D473A6405; Fri, 2 Apr 2010 15:16:35 -0700 (PDT) Received: from beethoven.local ([::ffff:173.71.206.39]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Fri, 02 Apr 2010 18:17:08 -0400 id 015AC51C.4BB66CE4.00007542 Message-ID: <4BB66CDC.5010906@thinkingcat.com> Date: Fri, 02 Apr 2010 18:17:00 -0400 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "=?UTF-8?B?QWxmcmVkIO+/vQ==?=" Subject: Re: New Version Notification for draft-hakala-rfc3187bis-isbn-urn-00 (fwd) References: <201003221327.OAA02242@TR-Sys.de> In-Reply-To: <201003221327.OAA02242@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: urn-nid@ietf.org, apps-discuss@ietf.org 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, 02 Apr 2010 22:16:36 -0000 Hi Alfred, Since this update will be processed using the "newer" NID process, outlined in 3406, it does need to have "Namespace Considerations" and "Community Considerations" sections. I realize much of the material is covered implicitly, but it needs to be called out and addressed explicitly in sections of those names. Thanks, Leslie. Alfred � wrote: > Folks, > we have posted a RFC 3187-bis initial draft (see below). > > This work is part of the PersID project to establish an international > network of stable resolution services for Persistent Identifiers (URNs), > in particular for Bibliographic identifiers. > > To give this work a more solid ground, updates to the basic URN-related > documents (RFC 2141 and RFC 3406) and URN namespace-specific RFCs are > planned, and brought to the IETF, in order to bring these documents > in alignment with current IETF Full Standards and IANA procedures. > > The ultimate goal is to establish a dedicated 'urnbis' WG in the IETF, > hopefully by this summer, with an ambitious schedule to bring revised > documents initially targetting PS / BCP status to the IESG, with the > goal of fast progression of RFC 2141-bis on the Standards Track. > > > Kind regards, > Alfred H�nes. > -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From phoffman@imc.org Fri Apr 2 15:59:02 2010 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 D35463A68DA for ; Fri, 2 Apr 2010 15:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.312 X-Spam-Level: X-Spam-Status: No, score=-4.312 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, 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 s5NsmYdg69zo for ; Fri, 2 Apr 2010 15:59:02 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 222593A6800 for ; Fri, 2 Apr 2010 15:59:02 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o32Mkgl5077779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Apr 2010 15:46:43 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4BB4ECFD.9090307@stpeter.im> References: <4BB4ECFD.9090307@stpeter.im> Date: Fri, 2 Apr 2010 15:46:40 -0700 To: "apps-discuss@ietf.org" From: Paul Hoffman Subject: Layer explosion (was: Re: weighting transports) Content-Type: text/plain; charset="us-ascii" 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, 02 Apr 2010 22:59:02 -0000 This discussion has now gone off in many directions. Peter started off with two questions, only one of which was matched in the subject line: At 12:59 PM -0600 4/1/10, Peter Saint-Andre wrote: >Sometimes a client needs to determine which transport or technology an >application server prefers for a given service type. For examples, an >email service might be provided via both POP and IMAP or a website might >be available via both TCP and SCTP. POP and IMAP are application protocols. TCP and SCTP are transports. Dan then spread it to more transports (SCTPoverUDP and SCTPoverTCP), and also the internet layer (IPv4 and IPv6). We now have combinations of 7, 4, and 3. I suggest that not one size of solution will fit all three best. Dan pointed out the current discussion in the DNSOP WG, and that is proving that there is not strong consensus on how to use the DNS for differentiating on what to answer for layer 3 addresses for a host name. I can imagine the same problems for layer 4 and 7, much less 3-and-4, 4-and-7, and 3-and-4-and-7. From dcrocker@bbiw.net Fri Apr 2 16:00:46 2010 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 AE17B3A691C for ; Fri, 2 Apr 2010 16:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.105 X-Spam-Level: X-Spam-Status: No, score=-5.105 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 xaky4ZSNr6R9 for ; Fri, 2 Apr 2010 16:00:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id F2CFE3A68DA for ; Fri, 2 Apr 2010 16:00:37 -0700 (PDT) Received: from [192.168.1.14] (adsl-67-127-191-90.dsl.pltn13.pacbell.net [67.127.191.90]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o32N15Pe016785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Apr 2010 16:01:11 -0700 Message-ID: <4BB6772D.5030106@bbiw.net> Date: Fri, 02 Apr 2010 16:01:01 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dan Wing Subject: Re: weighting transports References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <002801cad286$6a77fee0$c6f0200a@cisco.com> <4BB638CE.1080403@bbiw.net> <00b001cad295$e6e04d20$c6f0200a@cisco.com> <4BB64F71.6080701@bbiw.net> <013701cad2a9$2b1605d0$c6f0200a@cisco.com> In-Reply-To: <013701cad2a9$2b1605d0$c6f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10698/Fri Apr 2 13:42:25 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 02 Apr 2010 16:01:12 -0700 (PDT) Cc: apps-discuss@ietf.org 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, 02 Apr 2010 23:00:46 -0000 >> it highlights >> the need to be very >> careful about making sure that a proposed facility really >> does satisfy >> real-world usage scenarios, including proper granularity. > > An example would be helpful. S/MIME and PGP vs. DKIM -- that's the only 'granularity' example I can think of. As for the challenge of getting potential adopters motivated, how about: PEM/MOSS; IPv6; IRI; IPSec; DNSSec; PKIX; Diameter; Simple; Enum. All have been well-intentioned, pursued diligently, and started a long time ago. None has (yet) satisfied their claimed goal, though some have found useful niches and a couple of obvious ones might finally be reaching critical mass, after 15-18 years. Since the cost of developing a standards is millions of dollars it seems worth validating who will consume the work when it is available. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dwing@cisco.com Fri Apr 2 16:47:03 2010 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 7E10A3A6781 for ; Fri, 2 Apr 2010 16:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] 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 7xSEONBYrZhp for ; Fri, 2 Apr 2010 16:47:02 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 45BAB3A68EE for ; Fri, 2 Apr 2010 16:47:02 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8IAFoetkurR7Hu/2dsb2JhbACHV4EUkmFxm0uYVYUFBIMk X-IronPort-AV: E=Sophos;i="4.51,355,1267401600"; d="scan'208";a="507948611" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2010 23:47:36 +0000 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o32Nla2m002519; Fri, 2 Apr 2010 23:47:36 GMT From: "Dan Wing" To: "'Dave CROCKER'" References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <002801cad286$6a77fee0$c6f0200a@cisco.com> <4BB638CE.1080403@bbiw.net> <00b001cad295$e6e04d20$c6f0200a@cisco.com> <4BB64F71.6080701@bbiw.net> <013701cad2a9$2b1605d0$c6f0200a@cisco.com> <4BB6772D.5030106@bbiw.net> Subject: RE: weighting transports Date: Fri, 2 Apr 2010 16:47:36 -0700 Message-ID: <01cf01cad2be$df8d5080$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4BB6772D.5030106@bbiw.net> Thread-Index: AcrSuGQtRdHY765SRTqYwQXEJz1RVgAA03mw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: apps-discuss@ietf.org 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, 02 Apr 2010 23:47:03 -0000 > >> it highlights the need to be very > >> careful about making sure that a proposed facility really > >> does satisfy > >> real-world usage scenarios, including proper granularity. > > > > An example would be helpful. > > S/MIME and PGP vs. DKIM -- that's the only 'granularity' > example I can think of. > > As for the challenge of getting potential adopters motivated, > how about: > PEM/MOSS; IPv6; IRI; IPSec; DNSSec; PKIX; Diameter; Simple; Enum. > > All have been well-intentioned, pursued diligently, and > started a long time ago. > None has (yet) satisfied their claimed goal, though some > have found useful > niches and a couple of obvious ones might finally be reaching > critical mass, after 15-18 years. > > Since the cost of developing a standards is millions of > dollars it seems worth validating who will consume the > work when it is available. The IETF standardized SCTP a decade ago. We could just add it to the list of 'failures' at http://trac.tools.ietf.org/misc/outcomes, or sit and wait and wonder why The Industry has not adopted the technology. However, I would rather take advantage of the millions of dollars that have already been spent on SCTP to help get SCTP deployed on the Internet. Towards that end, yes, we can have SCTP- and TCP-capable clients probe for both SCTP and TCP. And, if they think they are behind a non-SCTP-capable NAT (which is most likely true), they can also probe for SCTP-over-UDP. I believe that is necessary, and I co-authored an Internet Draft describing exactly that: draft-wing-http-new-tech. Such probing is what the SCTP-enabled Firefox build at http://pel.cis.udel.edu does. But at the Dublin IETF meeting during the TAE Bar-BoF, I received feedback that probing will explode with more transports (including SCTP over UDP), and was asked to look at how to reduce probing. Mailing list archives are at https://www.ietf.org/mailman/listinfo/tae or you can talk with any of the principals that were there, such as for example Bryan Ford who was worried about this specific problem. The consumers of the work will be SCTP-enabled clients, which are using TCP today, that want or need to reduce their SCTP (and SCTP-over-UDP) probes across the Internet. So far there is an SCTP-enabled fork of the Firefox browser http://pel.cis.udel.edu So far we have received guidance that SRV is not the direction to go from Ted Hardie [1] and John Klensin [2], [1] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00095.html [2] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00096.html Your guidance appears to be "don't bother us, we have standardized things that have received little use. Just send probes." -d From dwing@cisco.com Fri Apr 2 17:11:17 2010 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 CC9E73A6A2D for ; Fri, 2 Apr 2010 17:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.162 X-Spam-Level: X-Spam-Status: No, score=-9.162 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 DONSm45oG7f6 for ; Fri, 2 Apr 2010 17:11:15 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2851A3A68EE for ; Fri, 2 Apr 2010 17:11:05 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8IADcktkurR7Hu/2dsb2JhbACHV4EUkmFxm1KYVIUFBIMk X-IronPort-AV: E=Sophos;i="4.51,355,1267401600"; d="scan'208";a="507959612" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2010 00:11:40 +0000 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o330BerN016901; Sat, 3 Apr 2010 00:11:40 GMT From: "Dan Wing" To: "'Paul Hoffman'" , References: <4BB4ECFD.9090307@stpeter.im> Subject: RE: Layer explosion (was: Re: weighting transports) Date: Fri, 2 Apr 2010 17:11:40 -0700 Message-ID: <01d901cad2c2$3c004720$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcrSuCy+OXyZClyHQl6OI1uebYVDGwACUOUg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 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, 03 Apr 2010 00:11:18 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul Hoffman > Sent: Friday, April 02, 2010 3:47 PM > To: apps-discuss@ietf.org > Subject: Layer explosion (was: Re: weighting transports) > > This discussion has now gone off in many directions. Peter > started off with two questions, only one of which was matched > in the subject line: > > At 12:59 PM -0600 4/1/10, Peter Saint-Andre wrote: > >Sometimes a client needs to determine which transport or > technology an > >application server prefers for a given service type. For examples, an > >email service might be provided via both POP and IMAP or a > website might > >be available via both TCP and SCTP. > > POP and IMAP are application protocols. > > TCP and SCTP are transports. > > Dan then spread it to more transports (SCTPoverUDP and > SCTPoverTCP), and also the internet layer (IPv4 and IPv6). > > We now have combinations of 7, 4, and 3. Actually, I only pointed out the IPv4/IPv6 problem to show that probing can be involved on IPv6, too. Today, we have content providers that are reluctant to put AAAA records on their servers. "Reluctant" is putting it mildly. AAAA is how we know a server is running IPv6. But we are not probing for IPv6; instead, connections are attempted and time out (after multiple seconds) and then fall back to IPv4. Over and over and over, taking many seconds to display a webpage. I would like to get SCTP deployed (to replace TCP where it makes sense), but we need to do that without the same issues currently suffered with IPv6. Active probing is a reasonable answer to meet that desire. But there have been concerns about that additional network traffic. -d > I suggest that not one size of solution will fit all three > best. Dan pointed out the current discussion in the DNSOP WG, > and that is proving that there is not strong consensus on how > to use the DNS for differentiating on what to answer for > layer 3 addresses for a host name. I can imagine the same > problems for layer 4 and 7, much less 3-and-4, 4-and-7, and > 3-and-4-and-7. > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From phoffman@imc.org Fri Apr 2 17:42:30 2010 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 70CD33A6909 for ; Fri, 2 Apr 2010 17:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.514 X-Spam-Level: X-Spam-Status: No, score=-4.514 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, 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 q9k0hlRdapvE for ; Fri, 2 Apr 2010 17:42:29 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0CF563A68FA for ; Fri, 2 Apr 2010 17:42:25 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o330gvGi082117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Apr 2010 17:42:59 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <01d901cad2c2$3c004720$c6f0200a@cisco.com> References: <4BB4ECFD.9090307@stpeter.im> <01d901cad2c2$3c004720$c6f0200a@cisco.com> Date: Fri, 2 Apr 2010 17:42:56 -0700 To: "Dan Wing" , From: Paul Hoffman Subject: RE: Layer explosion (was: Re: weighting transports) Content-Type: text/plain; charset="us-ascii" 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, 03 Apr 2010 00:42:30 -0000 At 5:11 PM -0700 4/2/10, Dan Wing wrote: >Actually, I only pointed out the IPv4/IPv6 problem to show >that probing can be involved on IPv6, too. Sure can. And if any of the application protocols that will be available over TCP and SCTP on IPv4, will be available on both IPv4 and IPv6 within a few years. >Today, we have content providers that are reluctant to put >AAAA records on their servers. "Reluctant" is putting it >mildly. AAAA is how we know a server is running IPv6. But >we are not probing for IPv6; instead, connections are >attempted and time out (after multiple seconds) and then >fall back to IPv4. Over and over and over, taking many >seconds to display a webpage. Yep. That's the difference between "probe" and "try/timeout/fallback". >I would like to get SCTP deployed (to replace TCP where it >makes sense), but we need to do that without the same issues >currently suffered with IPv6. Active probing is a reasonable >answer to meet that desire. But there have been concerns >about that additional network traffic. There are tradeoffs to probing, but for picking between different transports, I believe that probing is a better tradeoff than "devise some DNS scheme and wait for it to be deployed and hope we got it right" or "new transports are only for new application protocols". Probing is even more attractive if the client caches the results (maybe even with TTLs coming from extensions the transport). The increased traffic of occasional cached probes will be way less than the malicious probing done all the time today. From Nicolas.Williams@sun.com Fri Apr 2 18:49:18 2010 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 962703A6809 for ; Fri, 2 Apr 2010 18:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.251 X-Spam-Level: X-Spam-Status: No, score=-5.251 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 0JckABpeKKyC for ; Fri, 2 Apr 2010 18:49:17 -0700 (PDT) Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by core3.amsl.com (Postfix) with ESMTP id AFC143A67D3 for ; Fri, 2 Apr 2010 18:49:14 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o331nBdX009597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 3 Apr 2010 01:49:13 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o32GFSx5007087; Sat, 3 Apr 2010 01:49:11 GMT Received: from abhmt017.oracle.com by acsmt353.oracle.com with ESMTP id 143351131270259248; Fri, 02 Apr 2010 18:47:28 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Apr 2010 18:47:27 -0700 Date: Fri, 2 Apr 2010 20:47:22 -0500 From: Nicolas Williams To: Dan Wing Subject: Re: Layer explosion (was: Re: weighting transports) Message-ID: <20100403014722.GG4225@Sun.COM> References: <4BB4ECFD.9090307@stpeter.im> <01d901cad2c2$3c004720$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01d901cad2c2$3c004720$c6f0200a@cisco.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BB69E97.0110,ss=1,fgs=0 Cc: 'Paul Hoffman' , apps-discuss@ietf.org 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, 03 Apr 2010 01:49:18 -0000 On Fri, Apr 02, 2010 at 05:11:40PM -0700, Dan Wing wrote: > Today, we have content providers that are reluctant to put > AAAA records on their servers. "Reluctant" is putting it > mildly. AAAA is how we know a server is running IPv6. But > we are not probing for IPv6; instead, connections are > attempted and time out (after multiple seconds) and then > fall back to IPv4. Over and over and over, taking many > seconds to display a webpage. The obvious thing to do on the client side is to parallelize. Try iPv4 and IPv6 both (and SCTP and TCP and SCTP-over-UDP). Whichever finishes first wins the first time, and the others, when they complete or timeout, go in a cache. Next time you pick the best that you remember being available. Of course, that just consumes more server resources on the first try. And if your cache becomes invalid then you get timeouts. Also, whether SCTP works or not will depend on where the client is and can't really be cached reliably on a mobile device, nor can it be discovered via DNS or anything other than probing. But aside from that parallelized probing should work, so much so that I can't see why bother with new discovery schemes. > I would like to get SCTP deployed (to replace TCP where it > makes sense), but we need to do that without the same issues > currently suffered with IPv6. Active probing is a reasonable > answer to meet that desire. But there have been concerns > about that additional network traffic. If you can cache then the extra network traffic will be in the noise. Actually, even if you don't cache the extra network traffic will be in the noise (for protocols like IMAP we're talking bulk data, which overwhelms any SCTP INIT or TCP SYN packets). I'd worry more about the server, but only if you can't cache. Nico -- From dwing@cisco.com Fri Apr 2 19:11:53 2010 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 4B2023A683C for ; Fri, 2 Apr 2010 19:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.19 X-Spam-Level: X-Spam-Status: No, score=-9.19 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 Q8Edmcw7++bK for ; Fri, 2 Apr 2010 19:11:52 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 553083A6807 for ; Fri, 2 Apr 2010 19:11:51 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8IABpAtkurR7Hu/2dsb2JhbACHVoEUkmBxmlCYS4UFBIMk X-IronPort-AV: E=Sophos;i="4.51,356,1267401600"; d="scan'208";a="176932947" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 03 Apr 2010 02:11:50 +0000 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o332BnGa018581; Sat, 3 Apr 2010 02:11:50 GMT From: "Dan Wing" To: "'Paul Hoffman'" , References: <4BB4ECFD.9090307@stpeter.im> <01d901cad2c2$3c004720$c6f0200a@cisco.com> Subject: RE: Layer explosion (was: Re: weighting transports) Date: Fri, 2 Apr 2010 19:11:49 -0700 Message-ID: <01fe01cad2d3$053767d0$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcrSxpw7ZtfvEfPmTSSlrGp5RM9FkgADCfCQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 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, 03 Apr 2010 02:11:53 -0000 > -----Original Message----- > From: Paul Hoffman [mailto:phoffman@imc.org] > Sent: Friday, April 02, 2010 5:43 PM > To: Dan Wing; apps-discuss@ietf.org > Subject: RE: Layer explosion (was: Re: weighting transports) > > At 5:11 PM -0700 4/2/10, Dan Wing wrote: > >Actually, I only pointed out the IPv4/IPv6 problem to show > >that probing can be involved on IPv6, too. > > Sure can. And if any of the application protocols that will > be available over TCP and SCTP on IPv4, will be available on > both IPv4 and IPv6 within a few years. > > >Today, we have content providers that are reluctant to put > >AAAA records on their servers. "Reluctant" is putting it > >mildly. AAAA is how we know a server is running IPv6. But > >we are not probing for IPv6; instead, connections are > >attempted and time out (after multiple seconds) and then > >fall back to IPv4. Over and over and over, taking many > >seconds to display a webpage. > > Yep. That's the difference between "probe" and "try/timeout/fallback". > > >I would like to get SCTP deployed (to replace TCP where it > >makes sense), but we need to do that without the same issues > >currently suffered with IPv6. Active probing is a reasonable > >answer to meet that desire. But there have been concerns > >about that additional network traffic. > > There are tradeoffs to probing, but for picking between > different transports, I believe that probing is a better > tradeoff than "devise some DNS scheme and wait for it to be > deployed and hope we got it right" or "new transports are > only for new application protocols". Probing is even more > attractive if the client caches the results (maybe even with > TTLs coming from extensions the transport). The increased > traffic of occasional cached probes will be way less than the > malicious probing done all the time today. Great. We will probe. As I said, that is what is already described in draft-wing-http-new-tech. The DNS proposal is an OPTIMIZATION, to reduce the need to probe so much. It is not, as you summarize, "devise some DNS scheme and wait for it to be deployed and hope we got it right". -d From scott.brim@gmail.com Fri Apr 2 19:16:11 2010 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 373173A68C7 for ; Fri, 2 Apr 2010 19:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 YufVG8qG-jIc for ; Fri, 2 Apr 2010 19:16:10 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id D515D3A67B3 for ; Fri, 2 Apr 2010 19:15:50 -0700 (PDT) Received: by qyk11 with SMTP id 11so2576607qyk.13 for ; Fri, 02 Apr 2010 19:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=zui/82f+hzkYaJLZV3E3bC0k2AklHC6Tqdl9amTF7gg=; b=ipX9ngO24c7+cHXNFWhLdFATYmQ5n81NyLRTeZ4MInEq7EpacAhrlhCaaZjbxtvd/Y MPLoPyQxCz48fkjPffFe+ZnA6Mn3sqIzK8yek6qPYKv0OOmjP/Q2PdLc+TGUPqBroSZ+ +ZLwnNDIo24h4jy1PBPftUrXTwThg8PTgPw2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Iw6VvQEe1uUXfey2CMAy6OzrLIY11D44XHEApEmJQSa4+tyCApg0VJEzHxct7k9ZLX awuLnbI1OSf+ML1INuazxrlqYt0CUKEASFr3DzbiRYusOxEq8go0rPaKmWh0l2OHA4WQ AJZNIPaZ55sJyDUaAeFdEbZFJuS+02K3iqon8= Received: by 10.224.110.77 with SMTP id m13mr960543qap.106.1270260947538; Fri, 02 Apr 2010 19:15:47 -0700 (PDT) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 5sm1626223qwh.55.2010.04.02.19.15.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 19:15:46 -0700 (PDT) Message-ID: <4BB6A4D0.6000009@gmail.com> Date: Fri, 02 Apr 2010 22:15:44 -0400 From: Scott Brim User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Nicolas Williams Subject: Re: Layer explosion References: <4BB4ECFD.9090307@stpeter.im> <01d901cad2c2$3c004720$c6f0200a@cisco.com> <20100403014722.GG4225@Sun.COM> In-Reply-To: <20100403014722.GG4225@Sun.COM> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Paul Hoffman' , apps-discuss@ietf.org 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, 03 Apr 2010 02:16:11 -0000 Nicolas Williams allegedly wrote on 04/02/2010 21:47 EDT: > The obvious thing to do on the client side is to parallelize. Try iPv4 > and IPv6 both (and SCTP and TCP and SCTP-over-UDP). Whichever finishes > first wins the first time, and the others, when they complete or > timeout, go in a cache. Next time you pick the best that you remember > being available. > > Of course, that just consumes more server resources on the first try. and "first tries" will be relatively rare compared to "later tries". > And if your cache becomes invalid then you get timeouts. Only if your cache is absolute, yes-or-no. http-new-tech suggests weighted preferences. > Also, whether > SCTP works or not will depend on where the client is and can't really be > cached reliably on a mobile device, nor can it be discovered via DNS or > anything other than probing. If you are roaming within cellular operators, there is a high likelihood that if SCTP works in one cell it will work in another. There is also reasonable likelihood that if it works in one WiFi hotspot you visit that it will work in the next ... but again, what you cache is not an absolute choice but a behavior modifier that learns with use. > If you can cache then the extra network traffic will be in the noise. > Actually, even if you don't cache the extra network traffic will be in > the noise (for protocols like IMAP we're talking bulk data, which > overwhelms any SCTP INIT or TCP SYN packets). :-) Scott From dwing@cisco.com Fri Apr 2 19:26:07 2010 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 473FF3A68F2 for ; Fri, 2 Apr 2010 19:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.213 X-Spam-Level: X-Spam-Status: No, score=-9.213 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 fiK4xK4wy8wk for ; Fri, 2 Apr 2010 19:26:06 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2B2813A68EC for ; Fri, 2 Apr 2010 19:23:39 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEIANtDtkurR7Ht/2dsb2JhbACHVoEUkmFxmkiYTYUGBIMk X-IronPort-AV: E=Sophos;i="4.51,356,1267401600"; d="scan'208";a="507999994" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2010 02:23:38 +0000 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o332NcuD026698; Sat, 3 Apr 2010 02:23:38 GMT From: "Dan Wing" To: "'Nicolas Williams'" References: <4BB4ECFD.9090307@stpeter.im> <01d901cad2c2$3c004720$c6f0200a@cisco.com> <20100403014722.GG4225@Sun.COM> Subject: RE: Layer explosion (was: Re: weighting transports) Date: Fri, 2 Apr 2010 19:23:37 -0700 Message-ID: <01ff01cad2d4$ab51e090$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20100403014722.GG4225@Sun.COM> Thread-Index: AcrSz961FU5qx1QBQoKFB/dZQBtn/AAAyh+A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: 'Paul Hoffman' , apps-discuss@ietf.org 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, 03 Apr 2010 02:26:07 -0000 > On Fri, Apr 02, 2010 at 05:11:40PM -0700, Dan Wing wrote: > > Today, we have content providers that are reluctant to put > > AAAA records on their servers. "Reluctant" is putting it > > mildly. AAAA is how we know a server is running IPv6. But > > we are not probing for IPv6; instead, connections are > > attempted and time out (after multiple seconds) and then > > fall back to IPv4. Over and over and over, taking many > > seconds to display a webpage. > > The obvious thing to do on the client side is to parallelize. > Try iPv4 > and IPv6 both (and SCTP and TCP and SCTP-over-UDP). > Whichever finishes > first wins the first time, and the others, when they complete or > timeout, go in a cache. Next time you pick the best that you remember > being available. Yes, that's what we describe in draft-wing-http-new-tech already. > Of course, that just consumes more server resources on the first try. Yes, exactly. Especially if the SCTP connection finishes. The TCP connection now has to be abandoned by the client (RST). > And if your cache becomes invalid then you get timeouts. > Also, whether > SCTP works or not will depend on where the client is and > can't really be > cached reliably on a mobile device, nor can it be discovered > via DNS or > anything other than probing. Completely agreed we will always need to do some probing. That is where we (the industry) went wrong with IPv6-versus-IPv4 for time-critical applications such as web browsing. I am trying to avoid that mistake with SCTP. > But aside from that parallelized probing > should work, so much so that I can't see why bother with new discovery > schemes. It is an optimization. An optimization to avoid probing when the probing will not be successful. > > I would like to get SCTP deployed (to replace TCP where it > > makes sense), but we need to do that without the same issues > > currently suffered with IPv6. Active probing is a reasonable > > answer to meet that desire. But there have been concerns > > about that additional network traffic. > > If you can cache then the extra network traffic will be in the noise. > Actually, even if you don't cache the extra network traffic will be in > the noise (for protocols like IMAP we're talking bulk data, which > overwhelms any SCTP INIT or TCP SYN packets). I'd worry more > about the server, but only if you can't cache. HTTP and the many servers used by today's modern web page is my concern, far more than POP or IMAP. HTTP retrieves objects from many servers, in order to get around the client's server connection limit, and each of those would suffer a probe from every client. Successful probes (where both SCTP and TCP work) would incur a "wasted" TCP connection on the server that is abandoned by the client. -d From Nicolas.Williams@sun.com Sat Apr 3 19:01:52 2010 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 E8D893A67EA for ; Sat, 3 Apr 2010 19:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 QU3lo0U+0kBh for ; Sat, 3 Apr 2010 19:01:52 -0700 (PDT) Received: from rcsinet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by core3.amsl.com (Postfix) with ESMTP id 6D2BE3A67E2 for ; Sat, 3 Apr 2010 19:01:51 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o3421jrG006432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Apr 2010 02:01:47 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o340qq8s025579; Sun, 4 Apr 2010 02:01:43 GMT Received: from abhmt007.oracle.com by acsmt353.oracle.com with ESMTP id 144760201270346478; Sat, 03 Apr 2010 19:01:18 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 03 Apr 2010 19:01:17 -0700 Date: Sat, 3 Apr 2010 21:01:13 -0500 From: Nicolas Williams To: Dan Wing Subject: Re: Layer explosion (was: Re: weighting transports) Message-ID: <20100404020112.GH4225@Sun.COM> References: <4BB4ECFD.9090307@stpeter.im> <01d901cad2c2$3c004720$c6f0200a@cisco.com> <20100403014722.GG4225@Sun.COM> <01ff01cad2d4$ab51e090$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ff01cad2d4$ab51e090$c6f0200a@cisco.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BB7F309.00E7,ss=1,fgs=0 Cc: 'Paul Hoffman' , apps-discuss@ietf.org 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, 04 Apr 2010 02:01:53 -0000 On Fri, Apr 02, 2010 at 07:23:37PM -0700, Dan Wing wrote: > > On Fri, Apr 02, 2010 at 05:11:40PM -0700, Dan Wing wrote: > > And if your cache becomes invalid then you get timeouts. Also, > > whether SCTP works or not will depend on where the client is and > > can't really be cached reliably on a mobile device, nor can it be > > discovered via DNS or anything other than probing. > > Completely agreed we will always need to do some probing. That is > where we (the industry) went wrong with IPv6-versus-IPv4 for > time-critical applications such as web browsing. I am trying to > avoid that mistake with SCTP. You have a very different view of the world than I do then. IMO the problem with IPv6 was most definitely not about discovery, but about the difficulty of getting any sort of incremental deployment going comined with the rise of NAT, which pushed off the addressing problems with IPv4, and the lack of other sufficiently compelling reasons to move off IPv4. > > But aside from that parallelized probing > > should work, so much so that I can't see why bother with new discovery > > schemes. > > It is an optimization. An optimization to avoid probing when the > probing will not be successful. Is it really? Consider: 1 DNS lookup + N parallel connects vs 2 serial DNS lookups and 1 serial connect. The parallel case ought to win. OTOH, if you can reduce the cost of the DNS lookups for discovery and name resolution so that one query will do then discovery could at least match the performance of probing, but at probably only at significant architectural cost. > > If you can cache then the extra network traffic will be in the noise. > > Actually, even if you don't cache the extra network traffic will be in > > the noise (for protocols like IMAP we're talking bulk data, which > > overwhelms any SCTP INIT or TCP SYN packets). I'd worry more > > about the server, but only if you can't cache. > > HTTP and the many servers used by today's modern web page is my > concern, far more than POP or IMAP. HTTP retrieves objects from > many servers, in order to get around the client's server connection > limit, and each of those would suffer a probe from every client. > Successful probes (where both SCTP and TCP work) would incur > a "wasted" TCP connection on the server that is abandoned by the > client. That HTTP isn't usually used for bulk isn't really important, since when it isn't used for bulk it's used in many serial connections in a short space of time... which means that you can cache effectively for long enough that the overhead of probing will still be in the noise. The more I think about this the more I think that if there was a simple API for asynchronously and concurrently connecting to one service in N ways then probing would win outright and that would be that. Servers would have to cope, but then, they already have to cope with SYN DoS attacks, so I'm not terribly concerned, and besides, probing overhead will be in the noise for well-behaved clients. Nico -- From dhc2@dcrocker.net Sun Apr 4 10:51:46 2010 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 26BF33A68F8 for ; Sun, 4 Apr 2010 10:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, 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 7OewlXodDl2g for ; Sun, 4 Apr 2010 10:51:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id F281D3A68DB for ; Sun, 4 Apr 2010 10:51:44 -0700 (PDT) Received: from [192.168.1.14] (adsl-67-127-191-90.dsl.pltn13.pacbell.net [67.127.191.90]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o34HpaEX007739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Apr 2010 10:51:41 -0700 Message-ID: <4BB8D1A8.2040600@dcrocker.net> Date: Sun, 04 Apr 2010 10:51:36 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dan Wing Subject: Re: weighting transports References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <002801cad286$6a77fee0$c6f0200a@cisco.com> <4BB638CE.1080403@bbiw.net> <00b001cad295$e6e04d20$c6f0200a@cisco.com> <4BB64F71.6080701@bbiw.net> <013701cad2a9$2b1605d0$c6f0200a@cisco.com> <4BB6772D.5030106@bbiw.net> <01cf01cad2be$df8d5080$c6f0200a@cisco.com> In-Reply-To: <01cf01cad2be$df8d5080$c6f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10699/Fri Apr 2 19:04:40 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 04 Apr 2010 10:51:42 -0700 (PDT) Cc: apps-discuss@ietf.org 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, 04 Apr 2010 17:51:46 -0000 Dan, On 4/2/2010 4:47 PM, Dan Wing wrote: > The IETF standardized SCTP a decade ago. We could just add it to the list of > 'failures'... or sit and wait and wonder why The Industry has not adopted the > technology. This is what's called a false dichotomy. It asserts only two alternatives -- which can be as arbitrary as these two -- and ignores all the others that are available. It is an expression of frustration used when attempting to terminate debate and prematurely force adoption of one of the alternatives, without consideration of the underlying issues or tradeoffs. I now believe the deeper question is persistent validity of URLs, across changes to the infrastructure. For example, should a URL become invalid because a different transport is used? The answer needs to be no. Yet the view that the URL scheme would change when a new transport is used will produce that unfortunate result. It's not that Ted's concern about the possibility of divergent results based on using different library packages is wrong, it's that the proposed solution with different URIs is clearly the wrong result. Having an application protocol run over a different transport does not create a different service; it should not render the URI invalid. I've pushed back on your proposal not because I think you are pursuing an unattainable or unproductive goal but because its success has too many critical dependencies and too little compelling near-term value for adopters. The hard work is in reducing dependencies and increasing perceived value. Ignoring barriers to adoption seems to account for the failure of most otherwise-appealing efforts. The idea that a URI scheme couples application protocol with transport is really an architectural form of source-routing. One of the architectural wins for Internet design has been hiding details from upper layers. (For that matter, "http://" has this problem for the application layer, whereas "mailtto://" does not. It's the difference between using protocol names versus service names. We need to be careful about forcing the wrong set of changes on existing behaviors.) As of right now, I'd be interested in a review of the reason SRV records aren't perfect dealing with the choice between TCP and SCTP. I thought that that was the one of the reasons SRVs were created. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Nicolas.Williams@sun.com Sun Apr 4 13:08:54 2010 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 40EF63A67EF for ; Sun, 4 Apr 2010 13:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 PeYt4xxKjqEX for ; Sun, 4 Apr 2010 13:08:53 -0700 (PDT) Received: from rcsinet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by core3.amsl.com (Postfix) with ESMTP id 213AC3A69A8 for ; Sun, 4 Apr 2010 13:08:52 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o34K8nvd004460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Apr 2010 20:08:50 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o34JoT4a016149; Sun, 4 Apr 2010 20:08:48 GMT Received: from abhmt013.oracle.com by acsmt355.oracle.com with ESMTP id 145491681270411612; Sun, 04 Apr 2010 13:06:52 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 04 Apr 2010 13:06:52 -0700 Date: Sun, 4 Apr 2010 15:06:47 -0500 From: Nicolas Williams To: Dan Wing Subject: Re: Layer explosion (was: Re: weighting transports) Message-ID: <20100404200647.GJ4225@Sun.COM> References: <4BB4ECFD.9090307@stpeter.im> <01d901cad2c2$3c004720$c6f0200a@cisco.com> <01fe01cad2d3$053767d0$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01fe01cad2d3$053767d0$c6f0200a@cisco.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BB8F1D1.0006,ss=1,fgs=0 Cc: 'Paul Hoffman' , apps-discuss@ietf.org 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, 04 Apr 2010 20:08:54 -0000 On Fri, Apr 02, 2010 at 07:11:49PM -0700, Dan Wing wrote: > Great. We will probe. As I said, that is what is already > described in draft-wing-http-new-tech. > > The DNS proposal is an OPTIMIZATION, to reduce the need to > probe so much. It is not, as you summarize, "devise some DNS > scheme and wait for it to be deployed and hope we got it > right". I don't believe it'd actually optimize anything, except, _pehaps_ implementation complexity. Nico -- From A.Hoenes@TR-Sys.de Mon Apr 5 04:48:21 2010 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 B05813A67D1; Mon, 5 Apr 2010 04:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.449 X-Spam-Level: X-Spam-Status: No, score=-97.449 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 5tJeo8y4Vl2n; Mon, 5 Apr 2010 04:48:21 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id EC3D33A68E8; Mon, 5 Apr 2010 04:48:19 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA131838067; Mon, 5 Apr 2010 13:47:47 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id NAA04211; Mon, 5 Apr 2010 13:47:46 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004051147.NAA04211@TR-Sys.de> Subject: Re: New Version Notification for draft-hakala-rfc3187bis-isbn-urn-00 (fwd) To: leslie@thinkingcat.com Date: Mon, 5 Apr 2010 13:47:45 +0200 (MESZ) In-Reply-To: <4BB66CDC.5010906@thinkingcat.com> from Leslie Daigle at Apr "2, " 2010 "06:17:00" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: urn-nid@ietf.org, apps-discuss@ietf.org 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, 05 Apr 2010 11:48:21 -0000 > Hi Alfred, > > Since this update will be processed using the "newer" NID process, > outlined in 3406, it does need to have "Namespace Considerations" and > "Community Considerations" sections. I realize much of the material > is covered implicitly, but it needs to be called out and addressed > explicitly in sections of those names. > > Thanks, > Leslie. Good catch; thanks! This indeed is the -00 individual draft version posted to start discussion and attract interested parties and individuals, and as fodder for the IETF WG installation process planned by PersID with my editorial and procedural support, so I did not expect it to be perfect at the first time. :-) Kind regards, Alfred. P.S. (at large): Please direct follow-up messages to run-nid AT ietf.org, as indicated in the draft; thanks! From ajs@shinkuro.com Mon Apr 5 10:56:43 2010 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 EBB513A6888 for ; Mon, 5 Apr 2010 10:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_50=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 55Y8nrWFlsfn for ; Mon, 5 Apr 2010 10:56:42 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 212293A679C for ; Mon, 5 Apr 2010 10:56:42 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 69ABA1ECB4E8 for ; Mon, 5 Apr 2010 17:56:39 +0000 (UTC) Date: Mon, 5 Apr 2010 13:56:37 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Subject: Re: weighting transports Message-ID: <20100405175637.GG55035@shinkuro.com> References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BB61DE1.9070601@dcrocker.net> User-Agent: Mutt/1.5.18 (2008-05-17) 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, 05 Apr 2010 17:56:44 -0000 On Fri, Apr 02, 2010 at 09:40:01AM -0700, Dave CROCKER wrote: > extremely poor. On the other hand, at the last IETF, I seem to recall > hearing assurances that really, truly, finally, new RRs are no longer > difficult to deploy widely. I've no idea whether this latest assurance > is valid. If it is, that's great. But we ought to develop a broader > sense of this point. I'm not sure from whom you heard this, but here's approximately everything I know about the getting of and deploying new DNS RRTYPEs. 1. Getting a new RRTYPE is done by expert review. Some of the experts on the panel have not been as fast as we'd like about turnaround, but we've had more than one successful assignment of RRTYPE numbers under this process over the past little while. In at least one case, and maybe two, there were many people who thought the RRTYPE in question was a Bad Idea. Didn't matter. They met the criteria, so they're in. 2. Practically every deployed name server in the world can deal with unknown RRTYPEs any more. There are some exceptions, of course. But I do not believe that anyone who seriously needs a new RRTYPE is going to be prevented from using it because of the lack of support in an authority or infrastructure-grade recursive nameserver. 3. There is a distressing number of middleboxes on the Internet that do hideous things to DNS packets. This includes brilliant behaviour (I have actually seen this) such as treating every single DNS request as a lookup for A records, which means that if you ask for anything else at a name you either get nothing or an A record back. These are in decline, but their population is not negligible. You should assume users will sometimes have such a thing in the way. As DNSSEC deployment becomes more widespread, we may find some of these getting replaced because of how they break DNSSEC. 4. The OS APIs to get anything meaningful out of the DNS are not there, and when they are they're often not used much. That is, if you want to look up your favourite RRTYPE on many OSes, you're stuck doing all the resolution yourself either because the underlying system doesn't do it right, or else getting the system to do it right is harder than just implementing some minimal resolver yourself. 5. Application people shouldn't have to care about the DNS anyway: it's too far down the stack. So the pressure to change (4) isn't there. (I don't speak authoritatively on this one, but someone gave me a compelling argument to this effect over lunch in Anaheim, and I think I agree.) So, depending on what you want your new RRTYPE for, it's either trivial to get and deploy or else just short of impossible. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dhc@dcrocker.net Mon Apr 5 11:10:47 2010 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 A03533A69F8 for ; Mon, 5 Apr 2010 11:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 zxravSC7QPD2 for ; Mon, 5 Apr 2010 11:10:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 835263A6943 for ; Mon, 5 Apr 2010 11:10:45 -0700 (PDT) Received: from [192.168.1.14] (adsl-67-127-191-90.dsl.pltn13.pacbell.net [67.127.191.90]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o35IAcHL021882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Apr 2010 11:10:43 -0700 Message-ID: <4BBA279E.8060909@dcrocker.net> Date: Mon, 05 Apr 2010 11:10:38 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Sullivan Subject: Re: weighting transports References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <20100405175637.GG55035@shinkuro.com> In-Reply-To: <20100405175637.GG55035@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10703/Mon Apr 5 10:07:08 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 05 Apr 2010 11:10:43 -0700 (PDT) Cc: apps-discuss@ietf.org 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, 05 Apr 2010 18:10:47 -0000 Andrew, Thanks for the followup. On 4/5/2010 10:56 AM, Andrew Sullivan wrote: > 3. There is a distressing number of middleboxes on the Internet that > do hideous things to DNS packets. ... You should assume > users will sometimes have such a thing in the way. That would seem to be a rather fundamental, current barrier to the utility of new RRs. No? > 4. The OS APIs to get anything meaningful out of the DNS are not > there, and when they are they're often not used much. Seems like another fundamental, current barrier. > 5. Application people shouldn't have to care about the DNS anyway: > it's too far down the stack. Not really. Beyond mapping name to IP Address, the DNS is of increasing use for assorted other application-related mapping services. (It won't be a surprise that I'll cite DKIM.) > So, depending on what you want your new RRTYPE for, it's either > trivial to get and deploy or else just short of impossible. Ack. Might be useful to to characterize each, as guidance for work that expects to use the DNS. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From lear@cisco.com Mon Apr 5 11:18:30 2010 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 485813A6886 for ; Mon, 5 Apr 2010 11:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=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 Y5yd7NYPNl9G for ; Mon, 5 Apr 2010 11:18:29 -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 8E6E73A659A for ; Mon, 5 Apr 2010 11:18:28 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8CAHLGuUuQ/uCWe2dsb2JhbACDE5g4FQEBCwsiBhyeL4hFj1SEGW4E X-IronPort-AV: E=Sophos;i="4.51,366,1267401600"; d="scan'208,217";a="5199139" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 05 Apr 2010 17:43:15 +0000 Received: from dhcp-10-61-98-175.cisco.com (dhcp-10-61-98-175.cisco.com [10.61.98.175]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o35IIP7G015995; Mon, 5 Apr 2010 18:18:25 GMT Message-ID: <4BBA2971.9030406@cisco.com> Date: Mon, 05 Apr 2010 20:18:25 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.2pre) Gecko/20100302 Lanikai/3.1b1 MIME-Version: 1.0 To: Andrew Sullivan Subject: Re: weighting transports References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <20100405175637.GG55035@shinkuro.com> In-Reply-To: <20100405175637.GG55035@shinkuro.com> Content-Type: multipart/alternative; boundary="------------060808090905070205020006" Cc: apps-discuss@ietf.org 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, 05 Apr 2010 18:18:30 -0000 This is a multi-part message in MIME format. --------------060808090905070205020006 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Andrew, You left off a huge additional reason: * Nobody's provisioning software supports a new RRtype and the time it takes to deploy such provisioning tools is measured in eons. Wasn't SRV done in the Paleolithic Era? ;-) This is why we have any number of uses of TXT... Eliot --------------060808090905070205020006 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Andrew,

You left off a huge additional reason:

  • Nobody's provisioning software supports a new RRtype and the time it takes to deploy such provisioning tools is measured in eons.  Wasn't SRV done in the Paleolithic Era?  ;-)
This is why we have any number of uses of TXT...

Eliot

--------------060808090905070205020006-- From ajs@shinkuro.com Mon Apr 5 11:23:52 2010 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 C4EC53A6886 for ; Mon, 5 Apr 2010 11:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.116 X-Spam-Level: X-Spam-Status: No, score=0.116 tagged_above=-999 required=5 tests=[AWL=0.856, BAYES_20=-0.74] 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 vrjjd40YOwLM for ; Mon, 5 Apr 2010 11:23:47 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id ED0963A659A for ; Mon, 5 Apr 2010 11:23:44 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BB2921ECB4E8 for ; Mon, 5 Apr 2010 18:23:42 +0000 (UTC) Date: Mon, 5 Apr 2010 14:23:40 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Subject: Re: weighting transports Message-ID: <20100405182340.GJ55035@shinkuro.com> References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <20100405175637.GG55035@shinkuro.com> <4BBA279E.8060909@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBA279E.8060909@dcrocker.net> User-Agent: Mutt/1.5.18 (2008-05-17) 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, 05 Apr 2010 18:23:52 -0000 On Mon, Apr 05, 2010 at 11:10:38AM -0700, Dave CROCKER wrote: > On 4/5/2010 10:56 AM, Andrew Sullivan wrote: >> 3. There is a distressing number of middleboxes on the Internet that >> do hideous things to DNS packets. ... You should assume >> users will sometimes have such a thing in the way. > > That would seem to be a rather fundamental, current barrier to the > utility of new RRs. No? It depends on what you want to do with them. If you know your application is going to be able to work around these things, then maybe not. If you know your application just can't be deployed in such environments (it's not like such environments only screw with DNS packets, and have no other ideas about what is "allowed"), then probably not. But you need to take it into account, for sure. >> 4. The OS APIs to get anything meaningful out of the DNS are not >> there, and when they are they're often not used much. > > Seems like another fundamental, current barrier. It would appear that the consumers of OS APIs are the needed source of pressure on this topic. OS vendors aren't going to listen to DNS weenies telling them, "We have all these neato things you could expose. Why not do so?" They're maybe going to listen to application authors saying, "We want to be able to do _x_." And I bet that they'll really pay attention if a number of applications start installing alt_resolver_lib so that they can get the functionality they want. Anyway, the community on this list is in a better position to push for this than I am. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ajs@shinkuro.com Mon Apr 5 11:26:09 2010 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 285B53A6886 for ; Mon, 5 Apr 2010 11:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.984 X-Spam-Level: X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[AWL=1.615, 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 pORR5hpomDqT for ; Mon, 5 Apr 2010 11:26:08 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 6B3033A6853 for ; Mon, 5 Apr 2010 11:26:07 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 46C2E1ECB4E8 for ; Mon, 5 Apr 2010 18:26:05 +0000 (UTC) Date: Mon, 5 Apr 2010 14:26:03 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Subject: Re: weighting transports Message-ID: <20100405182603.GK55035@shinkuro.com> References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <20100405175637.GG55035@shinkuro.com> <4BBA2971.9030406@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBA2971.9030406@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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, 05 Apr 2010 18:26:09 -0000 On Mon, Apr 05, 2010 at 08:18:25PM +0200, Eliot Lear wrote: > > * Nobody's provisioning software supports a new RRtype and the time > it takes to deploy such provisioning tools is measured in eons. > Wasn't SRV done in the Paleolithic Era? ;-) Really? What provisioning software is this? Most of the DNS libraries I'm familiar with are perfectly capable of coping with unknown RRTYPEs in exactly the same way that the DNS servers are. The unknown type was in fact also done in the Paleolithic Era, and if people just can't handle it these days I think they ought to be embarrassed to call themselves capable of "provisioning". A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From lear@cisco.com Mon Apr 5 11:34:21 2010 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 636A328C141 for ; Mon, 5 Apr 2010 11:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_40=-0.185] 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 SYsusecLKyQf for ; Mon, 5 Apr 2010 11:34:20 -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 B45C428C11B for ; Mon, 5 Apr 2010 11:34:13 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8CAPbJuUuQ/uCWe2dsb2JhbACDE5g4FQEBCwsiBhyeKohFj1aBK4JubgQ X-IronPort-AV: E=Sophos;i="4.51,366,1267401600"; d="scan'208";a="5199492" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 05 Apr 2010 17:59:00 +0000 Received: from dhcp-10-61-98-175.cisco.com (dhcp-10-61-98-175.cisco.com [10.61.98.175]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o35IYARc018383; Mon, 5 Apr 2010 18:34:10 GMT Message-ID: <4BBA2D22.1070700@cisco.com> Date: Mon, 05 Apr 2010 20:34:10 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.2pre) Gecko/20100302 Lanikai/3.1b1 MIME-Version: 1.0 To: Andrew Sullivan Subject: Re: weighting transports References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <20100405175637.GG55035@shinkuro.com> <4BBA2971.9030406@cisco.com> <20100405182603.GK55035@shinkuro.com> In-Reply-To: <20100405182603.GK55035@shinkuro.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org 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, 05 Apr 2010 18:34:21 -0000 On 4/5/10 8:26 PM, Andrew Sullivan wrote: > On Mon, Apr 05, 2010 at 08:18:25PM +0200, Eliot Lear wrote: >> * Nobody's provisioning software supports a new RRtype and the time >> it takes to deploy such provisioning tools is measured in eons. >> Wasn't SRV done in the Paleolithic Era? ;-) > Really? Really. > What provisioning software is this? In the enterprise space this varies from commercial tools to shell scripts to perl. Quite all over the map. Once up and running IT departments are loathe to change it because of the critical purpose it serves in the network, and the fact that you have to hold a voodoo ceremony involving puppets and pins after you make any changes because of the nature of the beast. > Most of the DNS > libraries I'm familiar with are perfectly capable of coping with > unknown RRTYPEs in exactly the same way that the DNS servers are. You've missed the key word "provisioning". It's great that the server can handle an unknown type. But most tools that call it can't. Eliot From ajs@shinkuro.com Mon Apr 5 11:44:07 2010 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 2B1EF3A68D9 for ; Mon, 5 Apr 2010 11:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.046 X-Spam-Level: X-Spam-Status: No, score=-0.046 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_40=-0.185] 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 NZMKUnVY4FMb for ; Mon, 5 Apr 2010 11:44:06 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id A17AC3A659A for ; Mon, 5 Apr 2010 11:44:05 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1647A1ECB4E8 for ; Mon, 5 Apr 2010 18:44:03 +0000 (UTC) Date: Mon, 5 Apr 2010 14:44:01 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Subject: Re: weighting transports Message-ID: <20100405184401.GO55035@shinkuro.com> References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <20100405175637.GG55035@shinkuro.com> <4BBA2971.9030406@cisco.com> <20100405182603.GK55035@shinkuro.com> <4BBA2D22.1070700@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBA2D22.1070700@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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, 05 Apr 2010 18:44:07 -0000 On Mon, Apr 05, 2010 at 08:34:10PM +0200, Eliot Lear wrote: > In the enterprise space this varies from commercial tools to shell > scripts to perl. Quite all over the map. Once up and running IT > departments are loathe to change it because of the critical purpose it > serves in the network, and the fact that you have to hold a voodoo > ceremony involving puppets and pins after you make any changes because > of the nature of the beast. So what you're really saying is that the existing tool doesn't handle the unknown RRTYPE or your new special RRTYPE; they won't modify it for the general case because, well, they won't; and the new RRTYPE isn't valuable enough to them to make the feature worth the cost. That's ok: that's a trade-off they're making. I've worked in plenty of shops like this, too, and the usual answer is that everyone gets crappier behaviour than they might otherwise. They either live with it or leave to work in a company where they can get their work done. Handling of unknown RRTYPEs is not quite as old as I recalled. Only 2003. To me, that says that if it's actually useful in your case, then you should use it & be prepared for what happens when it fails. >> Most of the DNS >> libraries I'm familiar with are perfectly capable of coping with >> unknown RRTYPEs in exactly the same way that the DNS servers are. > > You've missed the key word "provisioning". It's great that the server > can handle an unknown type. But most tools that call it can't. No, I didn't miss it. Handing data _in_ to a DNS server requires DNS libraries, too. And that's provisioning, where I come from. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Joe.Hildebrand@webex.com Mon Apr 5 12:02:25 2010 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 E4F503A6A4B for ; Mon, 5 Apr 2010 12:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.118 X-Spam-Level: X-Spam-Status: No, score=-102.118 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, 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 qet-ALCElY22 for ; Mon, 5 Apr 2010 12:02:25 -0700 (PDT) Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by core3.amsl.com (Postfix) with SMTP id 249D63A6A3B for ; Mon, 5 Apr 2010 12:02:17 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 12:02:15 -0700 Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Mon, 5 Apr 2010 19:01:26 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 05 Apr 2010 13:01:30 -0600 Subject: Re: weighting transports From: Joe Hildebrand To: Andrew Sullivan , Message-ID: Thread-Topic: weighting transports Thread-Index: AcrU7SZtviswlEHERmaOA3QTzlfTLAABUAMv In-Reply-To: <20100405182340.GJ55035@shinkuro.com> IM-ID: xmpp:jhildebr@cisco.com Presence-ID: xmpp:jhildebr@cisco.com Jabber-ID: jhildebr@cisco.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Apr 2010 19:02:15.0390 (UTC) FILETIME=[818917E0:01CAD4F2] 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, 05 Apr 2010 19:02:26 -0000 On 4/5/10 12:23 PM, "Andrew Sullivan" wrote: > It would appear that the consumers of OS APIs are the needed source of > pressure on this topic. OS vendors aren't going to listen to DNS > weenies telling them, "We have all these neato things you could > expose. Why not do so?" They're maybe going to listen to application > authors saying, "We want to be able to do _x_." And I bet that > they'll really pay attention if a number of applications start > installing alt_resolver_lib so that they can get the functionality > they want. Anyway, the community on this list is in a better position > to push for this than I am. I'd settle for being able to do SRV lookups, as a start. For example, the .Net framework still only allows A (and maybe AAAA) lookups, without resorting to hand-implementation of DNS or P/Invoke to get to the Win32 API, where the call in question isn't supported on all OS versions. Is there an alt_resolver_lib yet that meets all of the requirements? I still have that doc around somewhere that lists them all out. Regardless, I doubt that it's possible to put enough pressure on some vendors to get them to support generic/new RRs in their API. To do it *well* (i.e. in such a way that a typical VB programmer can use the method), the library needs to parse the results and give them back in an easily-digestible form. That means work for each new RR type, which has to be scheduled and delivered in a multi-year product cycle. Having an escape mechanism for these new RRs is useful and interesting, but hard to document, and easy for a typical programmer to mess up in use, leading to support costs. Therefore, I still fall squarely in the camp of "impossible to deploy" for application-layer protocols. -- Joe Hildebrand From Nicolas.Williams@sun.com Mon Apr 5 12:12:40 2010 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 CF1F63A67A4 for ; Mon, 5 Apr 2010 12:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.065 X-Spam-Level: X-Spam-Status: No, score=-5.065 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_50=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 qgjNvlpatFGd for ; Mon, 5 Apr 2010 12:12:38 -0700 (PDT) Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by core3.amsl.com (Postfix) with ESMTP id C1ACE3A6A46 for ; Mon, 5 Apr 2010 12:12:38 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by acsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o35JCYF9019520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Apr 2010 19:12:36 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o35IMU3l019499; Mon, 5 Apr 2010 19:12:33 GMT Received: from abhmt018.oracle.com by acsmt354.oracle.com with ESMTP id 137900841270494714; Mon, 05 Apr 2010 12:11:54 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Apr 2010 12:11:53 -0700 Date: Mon, 5 Apr 2010 14:11:49 -0500 From: Nicolas Williams To: Andrew Sullivan Subject: Re: weighting transports Message-ID: <20100405191148.GR4225@Sun.COM> References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <20100405175637.GG55035@shinkuro.com> <4BBA2971.9030406@cisco.com> <20100405182603.GK55035@shinkuro.com> <4BBA2D22.1070700@cisco.com> <20100405184401.GO55035@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100405184401.GO55035@shinkuro.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BBA3622.009D,ss=1,fgs=0 Cc: apps-discuss@ietf.org 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, 05 Apr 2010 19:12:40 -0000 On Mon, Apr 05, 2010 at 02:44:01PM -0400, Andrew Sullivan wrote: > On Mon, Apr 05, 2010 at 08:34:10PM +0200, Eliot Lear wrote: > > In the enterprise space this varies from commercial tools to shell > > scripts to perl. Quite all over the map. Once up and running IT > > departments are loathe to change it because of the critical purpose it > > serves in the network, and the fact that you have to hold a voodoo > > ceremony involving puppets and pins after you make any changes because > > of the nature of the beast. > > So what you're really saying is that the existing tool doesn't handle > the unknown RRTYPE or your new special RRTYPE; they won't modify it > for the general case because, well, they won't; and the new RRTYPE > isn't valuable enough to them to make the feature worth the cost. Imagine a tool like UName*It or Moira. You won't find much on UName*It online so I'll give you a brief description: an object-oriented RDBMS specifically designed for naming data (DNS, NIS, LDAP, ...). It encourages one to fully normalize one's schema, which means new RR types require changing the schema. Q: How would you handle new RR types with such a tool? A new RR type's RDATA might reference a variety of objects, and these relationships need to be modelled appropriately if you're to take advanatage of the RDBMS' referential integrity features. A: Modify the schema, and also any scripts that generate/update name service data from the DB. Q: What if you're working with something less advanced? A: Modify whatever scripts/programs make it up. Q: What if you get this tool from a vendor? A: File a bug/RFE, wait. Q: What if you're getting service from a provider who's getting their provisioning system from some other vendor? A: File a bug/RFE, wait for the provider to... file a bug/RFE, and wait. Q: What if you're part of a captive audience? A: Wait, and wait, and wait, then wait some more. Or find a way to vote with your feet/money. In any case, adoption isn't instantaneous. Nico -- From ajs@shinkuro.com Mon Apr 5 12:21:10 2010 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 EB8033A6A4D for ; Mon, 5 Apr 2010 12:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.529 X-Spam-Level: X-Spam-Status: No, score=-0.529 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_05=-1.11] 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 TJWicyn-AEsO for ; Mon, 5 Apr 2010 12:21:08 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 629DD3A6A36 for ; Mon, 5 Apr 2010 12:20:47 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6007E1ECB4E8 for ; Mon, 5 Apr 2010 19:20:44 +0000 (UTC) Date: Mon, 5 Apr 2010 15:20:39 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Subject: Re: weighting transports Message-ID: <20100405192039.GA56132@shinkuro.com> References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <20100405175637.GG55035@shinkuro.com> <4BBA2971.9030406@cisco.com> <20100405182603.GK55035@shinkuro.com> <4BBA2D22.1070700@cisco.com> <20100405184401.GO55035@shinkuro.com> <20100405191148.GR4225@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100405191148.GR4225@Sun.COM> User-Agent: Mutt/1.5.18 (2008-05-17) 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, 05 Apr 2010 19:21:10 -0000 On Mon, Apr 05, 2010 at 02:11:49PM -0500, Nicolas Williams wrote: > Q: How would you handle new RR types with such a tool? A new RR type's > RDATA might reference a variety of objects, and these relationships > need to be modelled appropriately if you're to take advanatage of the > RDBMS' referential integrity features. > A: Modify the schema, and also any scripts that generate/update name > service data from the DB. Well, maybe. Another way would be to implement the unknown type in the tool, with opaque (i.e. RRTYPE id only) types and just a blob of data on the right hand side. (And yes, this bugs me too, having come to this game as a database geek. But that's what the unknown type is like.) > In any case, adoption isn't instantaneous. I wasn't trying to suggest it was. On the other hand, all of these complaints are the sort of thing we hear about every other technology, too, yet I don't notice people refusing to implement stuff on the grounds that there won't be instantaneous worldwide adoption. It's only some protocols (the DNS is among them) where we hear that using new features is "impossible". I have a feeling that part of the conviction of "impossibility" comes from years of having to deal with obstreperous DNS weenies who made everything harder than it had to be. I'm content to accept that there's a hangover from that. It's for the most part gone, however. That does not mean, in any case, that I believe the world has magically made new DNS RRTYPEs easy. It does mean that one barrier has been removed. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Nicolas.Williams@sun.com Mon Apr 5 12:27:12 2010 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 CE1A328C0FE for ; Mon, 5 Apr 2010 12:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 jyJoWP2zhPnN for ; Mon, 5 Apr 2010 12:27:11 -0700 (PDT) Received: from rcsinet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by core3.amsl.com (Postfix) with ESMTP id 40F4428C134 for ; Mon, 5 Apr 2010 12:26:28 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o35JQJ4p027101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Apr 2010 19:26:25 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o35AuJ9v016362; Mon, 5 Apr 2010 19:26:15 GMT Received: from abhmt006.oracle.com by acsmt353.oracle.com with ESMTP id 147919711270495500; Mon, 05 Apr 2010 12:25:00 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Apr 2010 12:25:00 -0700 Date: Mon, 5 Apr 2010 14:24:55 -0500 From: Nicolas Williams To: Andrew Sullivan Subject: Re: weighting transports Message-ID: <20100405192455.GT4225@Sun.COM> References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <20100405175637.GG55035@shinkuro.com> <4BBA2971.9030406@cisco.com> <20100405182603.GK55035@shinkuro.com> <4BBA2D22.1070700@cisco.com> <20100405184401.GO55035@shinkuro.com> <20100405191148.GR4225@Sun.COM> <20100405192039.GA56132@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100405192039.GA56132@shinkuro.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BBA395B.00CD,ss=1,fgs=0 Cc: apps-discuss@ietf.org 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, 05 Apr 2010 19:27:12 -0000 On Mon, Apr 05, 2010 at 03:20:39PM -0400, Andrew Sullivan wrote: > On Mon, Apr 05, 2010 at 02:11:49PM -0500, Nicolas Williams wrote: > > > Q: How would you handle new RR types with such a tool? A new RR type's > > RDATA might reference a variety of objects, and these relationships > > need to be modelled appropriately if you're to take advanatage of the > > RDBMS' referential integrity features. > > A: Modify the schema, and also any scripts that generate/update name > > service data from the DB. > > Well, maybe. Another way would be to implement the unknown type in > the tool, with opaque (i.e. RRTYPE id only) types and just a blob of > data on the right hand side. (And yes, this bugs me too, having come > to this game as a database geek. But that's what the unknown type is > like.) Yes, but this way you lose the referential integrity features of the RDBMS w.r.t. the new RR's RDATA. That's not cool, and it's a non-answer to the question posed (I specifically menaioned referential integrity in the question for a reason :) > > In any case, adoption isn't instantaneous. > > I wasn't trying to suggest it was. On the other hand, all of these > complaints are the sort of thing we hear about every other technology, > too, yet I don't notice people refusing to implement stuff on the > grounds that there won't be instantaneous worldwide adoption. It's > only some protocols (the DNS is among them) where we hear that using > new features is "impossible". > > I have a feeling that part of the conviction of "impossibility" comes > from years of having to deal with obstreperous DNS weenies who made > everything harder than it had to be. I'm content to accept that > there's a hangover from that. It's for the most part gone, however. > That does not mean, in any case, that I believe the world has > magically made new DNS RRTYPEs easy. It does mean that one barrier > has been removed. In this case the alternative to new RR types is parallelized probing. And because SCTP might not go through midlle-boxes and DNS cannot possible know when there are such middle boxes between a client and some target, there's really little choice but to probe. The remainder of the discussion (e.g., this sub-thread), is interesting but tangential. Nico -- From dhc@dcrocker.net Mon Apr 5 12:34:18 2010 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 5CD013A69BF for ; Mon, 5 Apr 2010 12:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, 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 H95JukLFIj6Z for ; Mon, 5 Apr 2010 12:34:17 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id AE7E13A6847 for ; Mon, 5 Apr 2010 12:34:11 -0700 (PDT) Received: from [192.168.1.14] (adsl-67-127-191-90.dsl.pltn13.pacbell.net [67.127.191.90]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o35JY4LA029006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Apr 2010 12:34:09 -0700 Message-ID: <4BBA3B2C.9080908@dcrocker.net> Date: Mon, 05 Apr 2010 12:34:04 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: RR vs. underscore References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10703/Mon Apr 5 10:07:08 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 05 Apr 2010 12:34:10 -0700 (PDT) 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, 05 Apr 2010 19:34:18 -0000 On 4/5/2010 12:01 PM, Joe Hildebrand wrote: > I'd settle for being able to do SRV lookups, as a start. While a new RR is the cleanest approach for extending DNS response data semantics, it has been a barrier for 20+ years. One can bemoan this or one can try to deal with it. Underscore-based naming such as RFC 2782 -- _ldap._tcp.example.com and RFC 4871 -- foo.bar._domainkey.example.com has fared considerably better, although as Joe notes, there are still limitations. In effect, an underscore name defines an scoped attribute space for the associated parent domain. An RR record is a type of attribute. Hence, there seems to be an equivalence between using RRs and using underscore-based names with a limited set of RRs, such as SRV and TXT. My question is whether there are semantic or performance problems that render use of underscore names meaningfully inferior to use of new RRs? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Nicolas.Williams@sun.com Mon Apr 5 12:42:14 2010 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 35CFD3A69B5 for ; Mon, 5 Apr 2010 12:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 Vz8JXVNGbIGt for ; Mon, 5 Apr 2010 12:42:13 -0700 (PDT) Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by core3.amsl.com (Postfix) with ESMTP id 61A5C3A6965 for ; Mon, 5 Apr 2010 12:42:13 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o35Jg1QC030405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Apr 2010 19:42:03 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o35IYYCE002286; Mon, 5 Apr 2010 19:41:58 GMT Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 137969161270496428; Mon, 05 Apr 2010 12:40:28 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Apr 2010 12:40:27 -0700 Date: Mon, 5 Apr 2010 14:40:23 -0500 From: Nicolas Williams To: dcrocker@bbiw.net Subject: Re: RR vs. underscore Message-ID: <20100405194023.GV4225@Sun.COM> References: <4BBA3B2C.9080908@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBA3B2C.9080908@dcrocker.net> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BBA3D08.00A2,ss=1,fgs=0 Cc: apps-discuss@ietf.org 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, 05 Apr 2010 19:42:14 -0000 On Mon, Apr 05, 2010 at 12:34:04PM -0700, Dave CROCKER wrote: > My question is whether there are semantic or performance problems > that render use of underscore names meaningfully inferior to use of > new RRs? IMO, not really. The main issue is that the format of the text in a TXT RR's RDATA is dependent on the domainname of the RR. This complicates... referential integrity in provisioning. (It's not a barrier to provisioning though.) It's also the case, IMO, that specification of a new RR's RDATA is likely to be more formal than specification of a TXT RR's payload format, but I've no data to back this up, and my preference for formal specification is arguably just that: a personal preference. Nico -- From patrik@frobbit.se Mon Apr 5 12:43:27 2010 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 85E273A6965 for ; Mon, 5 Apr 2010 12:43:27 -0700 (PDT) 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 My2y9C-nDwRq for ; Mon, 5 Apr 2010 12:43:26 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id 622AE3A67B7 for ; Mon, 5 Apr 2010 12:43:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id D5975AA359A7; Mon, 5 Apr 2010 21:43:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vT9wTshlSAEz; Mon, 5 Apr 2010 21:43:23 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::dead:beef] (unknown [IPv6:2a02:80:3ffc::dead:beef]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id DAEE7AA3598D; Mon, 5 Apr 2010 21:43:22 +0200 (CEST) Subject: Re: RR vs. underscore Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-22-131618353" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4BBA3B2C.9080908@dcrocker.net> Date: Mon, 5 Apr 2010 21:43:14 +0200 Content-Transfer-Encoding: 7bit Message-Id: <78FB2E5F-55AB-4CC2-8933-D4241DB10368@frobbit.se> References: <4BBA3B2C.9080908@dcrocker.net> To: dcrocker@bbiw.net X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1078) Cc: apps-discuss@ietf.org 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, 05 Apr 2010 19:43:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-22-131618353 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 5 apr 2010, at 21.34, Dave CROCKER wrote: > On 4/5/2010 12:01 PM, Joe Hildebrand wrote: >> I'd settle for being able to do SRV lookups, as a start. >=20 > While a new RR is the cleanest approach for extending DNS response = data semantics, it has been a barrier for 20+ years. I think we should be able to overcome the issues with new RR types. Just = because it was hard say before year 2000 does not imply it is (as) hard = today. I.e. please be careful with arguments like these. That said, prefixes of owner names is one way of "expanding" the DNS, = although it has some issues. Se RFC 5507. 5507 Design Choices When Expanding the DNS. IAB, P. Faltstrom, Ed., R. Austein, Ed., P. Koch, Ed.. April 2009. (Format: TXT=3D44045 bytes) (Status: INFORMATIONAL) Patrik --Apple-Mail-22-131618353 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFLuj1SrMabGguI180RAiWmAJ0ebRI04o4eViS2Wd5v2LQ9M+uVzACfaMOG 2dzF4ZWzFJTfYuFYyl06I+0= =uPrh -----END PGP SIGNATURE----- --Apple-Mail-22-131618353-- From dhc@dcrocker.net Mon Apr 5 12:53:35 2010 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 2D0943A67B7 for ; Mon, 5 Apr 2010 12:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.777 X-Spam-Level: X-Spam-Status: No, score=-4.777 tagged_above=-999 required=5 tests=[AWL=-1.078, BAYES_50=0.001, MIME_8BIT_HEADER=0.3, 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 hQCcBjTN9YHn for ; Mon, 5 Apr 2010 12:53:34 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id D5BE03A698E for ; Mon, 5 Apr 2010 12:53:32 -0700 (PDT) Received: from [192.168.1.14] (adsl-67-127-191-90.dsl.pltn13.pacbell.net [67.127.191.90]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o35JrMv9029900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Apr 2010 12:53:27 -0700 Message-ID: <4BBA3FB2.8070408@dcrocker.net> Date: Mon, 05 Apr 2010 12:53:22 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: RR vs. underscore References: <4BBA3B2C.9080908@dcrocker.net> <78FB2E5F-55AB-4CC2-8933-D4241DB10368@frobbit.se> In-Reply-To: <78FB2E5F-55AB-4CC2-8933-D4241DB10368@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.92/10703/Mon Apr 5 10:07:08 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 05 Apr 2010 12:53:28 -0700 (PDT) Cc: dcrocker@bbiw.net, apps-discuss@ietf.org 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, 05 Apr 2010 19:53:35 -0000 On 4/5/2010 12:40 PM, Nicolas Williams wrote: > IMO, not really. The main issue is that the format of the text in a TXT RR's > RDATA is dependent on the domainname of the RR. This complicates... > referential integrity in provisioning. Please explain how. There is a dependence onthe underscore name, not the root name. Note that the alternative is dependence on the RR "name". It's easy to construct software which makes the difference large and insurmountable, but it's also easy to construct it in a way that isn't. So, what makes one worse or the other better? (It's not a barrier to > provisioning though.) It's also the case, IMO, that specification of a new > RR's RDATA is likely to be more formal than specification of a TXT RR's > payload format, You think the method of labeling affects quality of the specification writing? I'll disagree. On 4/5/2010 12:43 PM, Patrik Fältström wrote: > I think we should be able to overcome the issues with new RR types. Just > because it was hard say before year 2000 does not imply it is (as) hard > today. I.e. please be careful with arguments like these. I think we should too. But a long track-record of failing to do that cannot realistically be ignored. The point is not that it was hard 20 years ago, it is that it has /continued/ to be difficult. Note that I started by citing the latest assurances that all was now well with the use of RRs and an experience DNS-o-phile provided a counter-view. I'm merely trying to take that expert input and look for a way to work with it. Feel free to counter Andrew's details. But separately, please note that I asked a question about relative performance and functionality, not about personal preference. I am simply looking for an honest technical comparison of two design approaches. Technical. Not religious. > Se RFC 5507. > > 5507 Design Choices When Expanding the DNS. IAB, P. Faltstrom, Ed., R. > Austein, Ed., P. Koch, Ed.. April 2009. (Format: TXT=44045 bytes) (Status: > INFORMATIONAL) Yes. Thanks. I should have included that citation in my query. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Joe.Hildebrand@webex.com Mon Apr 5 12:58:04 2010 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 13D043A69FC for ; Mon, 5 Apr 2010 12:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.325 X-Spam-Level: X-Spam-Status: No, score=-103.325 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, 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 EhaN2YBYeUFT for ; Mon, 5 Apr 2010 12:58:03 -0700 (PDT) Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by core3.amsl.com (Postfix) with SMTP id 9E15B3A6A6E for ; Mon, 5 Apr 2010 12:58:00 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 12:57:58 -0700 Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Mon, 5 Apr 2010 19:56:56 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 05 Apr 2010 13:57:00 -0600 Subject: Re: RR vs. underscore From: Joe Hildebrand To: , Message-ID: Thread-Topic: RR vs. underscore Thread-Index: AcrU9vyXlg+ZgKz9QnqR0TWLlmoILQAAyq6u In-Reply-To: <4BBA3B2C.9080908@dcrocker.net> IM-ID: xmpp:jhildebr@cisco.com Presence-ID: xmpp:jhildebr@cisco.com Jabber-ID: jhildebr@cisco.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Apr 2010 19:57:58.0685 (UTC) FILETIME=[4A4B6CD0:01CAD4FA] 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, 05 Apr 2010 19:58:04 -0000 On 4/5/10 1:34 PM, "Dave CROCKER" wrote: > On 4/5/2010 12:01 PM, Joe Hildebrand wrote: >> I'd settle for being able to do SRV lookups, as a start. > > My question is whether there are semantic or performance problems that render > use of underscore names meaningfully inferior to use of new RRs? The underscores themselves aren't a problem, but the tight coupling with transport protocol in the case of SRV can be an issue, as we've been discussing on another thread. If I was to do "SRV-lite" for XMPP federation, I might do a TXT record at _xmpp-server._lite.example.com that returns a list of records each of which has priority, transport, port, and host IPv4/IPv6. You SHOULD NOT return two records with the same priority, but if you do, the recipient can pick either. All of the load-balancing stuff in SRV is a pain to implement, and it's rarely used due to the availability of network-layer load balancing. I'd recommend skipping an extra A/AAAA lookup, and just return a different TXT in priority order for that case as well. Moving out of _tcp has the extra side-benefit that when you're deploying into a broken Microsoft AD DNS, your results don't have to include all of the AD servers every time, which means you've got a shot at staying under one MTU. If I'm a deployment that implements XMPP over SCTP, TCP, and HTTP (heh. Only mostly kidding about this), I just have different TXT records, in order of the deployment's preference. The client runs through the list in priority order, using the draft-wing-http-new-tech approach, but skipping the methods it doesn't implement or can't access at the moment. -- Joe Hildebrand From Nicolas.Williams@sun.com Mon Apr 5 13:04:18 2010 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 984413A6948 for ; Mon, 5 Apr 2010 13:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 Ktwni05ciqcd for ; Mon, 5 Apr 2010 13:04:17 -0700 (PDT) Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by core3.amsl.com (Postfix) with ESMTP id 6264B3A688D for ; Mon, 5 Apr 2010 13:04:17 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o35K3vob019360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Apr 2010 20:03:58 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o354EFg8026265; Mon, 5 Apr 2010 20:03:56 GMT Received: from abhmt014.oracle.com by acsmt355.oracle.com with ESMTP id 148013861270497751; Mon, 05 Apr 2010 13:02:31 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Apr 2010 13:02:30 -0700 Date: Mon, 5 Apr 2010 15:02:25 -0500 From: Nicolas Williams To: dcrocker@bbiw.net Subject: Re: RR vs. underscore Message-ID: <20100405200225.GX4225@Sun.COM> References: <4BBA3B2C.9080908@dcrocker.net> <78FB2E5F-55AB-4CC2-8933-D4241DB10368@frobbit.se> <4BBA3FB2.8070408@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBA3FB2.8070408@dcrocker.net> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BBA422C.0185,ss=1,fgs=0 Cc: apps-discuss@ietf.org 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, 05 Apr 2010 20:04:18 -0000 On Mon, Apr 05, 2010 at 12:53:22PM -0700, Dave CROCKER wrote: > On 4/5/2010 12:40 PM, Nicolas Williams wrote: > >IMO, not really. The main issue is that the format of the text in a TXT RR's > >RDATA is dependent on the domainname of the RR. This complicates... > >referential integrity in provisioning. > > Please explain how. It means that you need to examine the name of the RR to decide how to decode the RDATA so that you can model the object correctly in your RDBMS. Nothing spectacularly hard. > So, what makes one worse or the other better? Nothing (remember, I started my reply to that same question with "IMO, not really"). > (It's not a barrier to > >provisioning though.) It's also the case, IMO, that specification of a new > >RR's RDATA is likely to be more formal than specification of a TXT RR's > >payload format, > > You think the method of labeling affects quality of the specification writing? Possibly. Some authors will use ABNF, some will use languages much less formal, or just English to describe the payload. Nico -- From jpanzer@google.com Mon Apr 5 13:24:48 2010 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 0D92928C146 for ; Mon, 5 Apr 2010 13:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.821 X-Spam-Level: X-Spam-Status: No, score=-100.821 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_AMP2B=2.555, 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 ORfFlz+WJXLk for ; Mon, 5 Apr 2010 13:24:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id D207B28C1DD for ; Mon, 5 Apr 2010 13:12:45 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [10.3.21.11]) by smtp-out.google.com with ESMTP id o35KCd6L008539 for ; Mon, 5 Apr 2010 13:12:39 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270498360; bh=T/QxLyDYSQONDYkdiJPNJjSQzTA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=yj0O1C34BJdkJyumicfECTpmgtKgLxlRGWFhUgQ5Dl/xGSM1nc9J5ChUHoVdH6D2I JbmEdS9lu5EsbsroDW77Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=Za4p/o4m8sbR7/Wa3L7ztroynByubq0cXsbz9/VrOL8MMKtljna7zJudrvqmGEjri BQbSFxAhw9rurn0kQO/NA== Received: from pwi2 (pwi2.prod.google.com [10.241.219.2]) by hpaq11.eem.corp.google.com with ESMTP id o35KCb9H022902 for ; Mon, 5 Apr 2010 22:12:37 +0200 Received: by pwi2 with SMTP id 2so3078822pwi.28 for ; Mon, 05 Apr 2010 13:12:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.14 with HTTP; Mon, 5 Apr 2010 13:12:16 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723438E20DAD23@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723438E20DAD23@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Mon, 5 Apr 2010 13:12:16 -0700 Received: by 10.141.4.17 with SMTP id g17mr3093500rvi.166.1270498356275; Mon, 05 Apr 2010 13:12:36 -0700 (PDT) Message-ID: Subject: Re: Query on discovery algoritm for LRDD (draft-hammer-discovery-04) To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=000e0cd1095636a97a048382f333 X-System-Of-Record: true Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" , "salmon-protocol@googlegroups.com" 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, 05 Apr 2010 20:24:48 -0000 --000e0cd1095636a97a048382f333 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 27, 2010 at 2:41 PM, Eran Hammer-Lahav wrote: > > > > -----Original Message----- > > From: John Panzer [mailto:jpanzer@google.com] > > Sent: Friday, March 26, 2010 10:08 AM > > > This is my attempt to translate > > http://tools.ietf.org/html/draft-hammer-discovery-04 into an actionable > > algorithm, as a first step in attempting to write a truly general > resource > > discovery library that matches the latest spec. > > It is written under the assumption that a client may wish to query for > sets of > > links with a given relvalue, and is not going to wish to retrieve and > re-parse > > host-meta files any more often than necessary. Feedback welcomed! > > > > Definitions > > > > startURI: Starting point for discovery; input into the discovery process. > > Discovery produces metadata for startURI. > > > > metadata: A collection of links and properties for the resource. > > > > link: An abstract edge between the startURI resource and another resource > > identified by a field href. Has a rel field indicating the relationship > from > > startURI to href. Has a lrdd_pri field indicating ordering within the rel > value. > > Has a secure boolean field indicating whether it was retrieved securely. > Can > > be annotated with arbitrary properties. > > > > property: A piece of metadata about a resource less structured than a > link. > > Only present for XRD-derived data. Has a secure boolean field indicating > > whether it was retrieved securely. > > Link headers and elements can include extension parameters that are either > rel-specific or document specific. These will be in the form of key/value > pairs but in which the key is a short name, not a URI (like XRD > type). In markup the can have a namespace. > > I generally prefer people used the XRD facility instead of > extending the link schema (for header format). > > > Algorithm > > > > Determine priority order (Host-priority or Resource-priority): > > > > lookup HostMetaLRDD(startURI) > > What does this do in this context? Your Function below is aimed for getting > metadata, not just raw host-meta. > In this context, this should be something like RawHostMeta(). > > > if above lookup fails because Host(startURI) is not available, priority = > > Resource Else, does result contain > > XRD/Property@type=http://lrdd.net/priority/resource? If yes, then > priority > > = Resource. Otherwise, priority = Host > > > > If priority = Host: > > // priority order is host-meta, HTTP Link, elements > > metadata = lookup HostMetaLRDD(startURI, 1) > > augment metadata with result of lookup HeaderLinks(startURI, 2) > > augment metadata with lookup ResourceLinks(startURI, 3) > > > > If priority = Resource: > > // priority order is elements, HTTP Link, host-meta > > metadata = lookup ResourceLinks(startURI, 1) > > augment metadata with result of lookup HeaderLinks(startURI, 2) > > augment metadata with lookup HostMetaLRDD(startURI, 3) > > > > where > > > > HostMetaLRDD(uri, pri) is: > > Revalidate local XRD data cache for hostof(uri)/.well-known/host-meta. > > How do you handle http vs https? > What is the default ordering in which to try? I'd much prefer to make https:// the default scheme for the "hostof(x)" above, failing back to http:// with a flag indicating content was not verified by a certificate. NB: In starting to write code for all this, I'm finding it useful to use nonstandard ids like foo@localhost:8080 in order to preserve my sanity. This means "pretend you're foo@localhost, and use 8080 as the default HTTP port for host-meta discovery, and switch off security checks too". In particular I end up having to swap around between foo@localhost:8080, foo@localhost:8081, foo@localhost:8082,... dynamically quite a bit to simulate cross-domain calls, so a static configuration would be quite annoying/unusable. Fortunately most of the stack I'm using doesn't care about this, but the port needs to be passed down a few levels and get through some regexps. Not sure how best to do this for real without compromising security -- perhaps allow this only for "localhost"... > Follow redirections. > ...while ensuring that one's security flag gets reset to 0 if any redirects pass through http... > Validate host-meta is valid for the desired host. > What's the procedure here? Just match Subject and Alias against the host? > > > Find the first link with rel="lrdd" in host-meta document (call > > the href value lrdd_url) > > Apply template... > Ah right, you don't have an href until you apply(template, uri) --> href. > > > Revalidate local XRD data cache for lrdd_url,annotating each link > > with lrdd_pri=pri > > Return metadata (non-lrdd links and properties) for lrdd_uri > > > > > > HeaderLinks(uri, pri) is: > > If uri is not dereferenceable (e.g., acct:) return empty set > > If you URI is not http/https, or if a GET/HEAD returns a response that does > not contains a representation for the requested resource. See: > http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-09#section-6.1 > > What if it returns a 403 Forbidden? Or a 5xx Temporary Server error? Or just times out? > > Revalidate local resource link cache for uri > > Retrieve Link: headers for resource from cache, annotating > > each link with lrdd_pri=pri > > Return links to caller > > > > ResourceLinks(uri, pri) is: > > If uri is not dereferenceable (e.g., acct:) return empty set > > Revalidate local resource link cache for uri > > Retrieve MIME-type-specific set of links known for resource, annotating > > each > > link with lrdd_pri=pri > > Return links to caller > > > > > > augment X with Y with priority pri is: > > For each set of links y in Y sharing link relation r: > > if r=="lrdd", and X does not already > > contain a link with rel="lrdd": > > augment X with results of: > > Revalidate local XRD data cache for first href for rel="lrdd", > > annotating each link with lrdd_pri=pri > > Augment X with resulting metadata from href > > else, > > add list of links y to X. > > Add all properties in Y to X. > > > > > > NB: Some link types can contain space-separated rel values, which are > > interpreted as a series of links with each of the space-separated rel > value > > names in the above algorithm. > > > > NB: Ordering of links and properties from each source with the same > rel/type > > values is retained throughout, with the caveat that HTTP headers do not > > have a guaranteed stable order. > > > > Security is not shown here, but is based on either TLS used throughout > the > > retrievals or (for XRD) the XRD signature specification. Content type > specific > > security may also be used to verify links within content (e.g., Magic > > Signatures over link elements). When set, the secure boolean indicates > that > > a specific link or property was retrieved securely; when not set, it > indicates > > that the retrieval path contained one or more insecure steps. The > algorithm > > will also reject data that is red-flagged (e.g., if a CRL check shows > that a > > certificate has been revoked as opposed to merely expiring). (?) > > > > Result: > > > > An ordered collection of metadata, consisting of links and properties, > each of > > which is annotated with its lrdd_pri in case it matters. There is at > most one > > rel="lrdd" link in the collection which identifies the specific LRDD > document > > used, if any, and any metadata from that lrdd document is transcluded > into > > the metadata collection. > > There can be more than one LRDD document, but only one is used from each > source. There should not be any rel='lrdd' in the collection because it is > either expanded or dropped (not first). > This algorithm was just tracking the address of the one that was expanded (not 100% necessary but useful for debuggability). I think that "Any "lrdd" links other than the first MUST be ignored." in section 3, step 2, is confusing: I had interpreted "first" as the first one encountered globally, but your note implies that you can have up to 3 LRDD documents to peek inside (one from each source). I'm not sure that the limitation of one LRDD link per source helps anything in the algorithm in this case. > > > A client which wishes to coalesce links and properties found in all three > > places within a given rel or type value can just query the collection for > the > > desired rel or type and retrieve collections of links or properties. > > > > Once retrieved, the set of metadata can be queried. An important/useful > > query is to retrieve the list of links with a given rel value: > > > > get_links(metadata, rel) # Get sequence of links with given rel value, > or > > empty list if not found. > > > > Sometimes you may require that only the first set of links found > > count: > > > > get_top_priority_links(metadata, rel) # Get sequence of links with given > rel > > value, ignoring all but the first set found > > > > ...and of course you can do a similar query for properties. > > EHL > > --000e0cd1095636a97a048382f333 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Mar 27, 2010 at 2:41 PM, Eran Hammer-Lahav <eran@hueniverse.com> wro= te:


> -----Original Message-----
> From: John Panzer [mailto:jpanze= r@google.com]
> Sent: Friday, March 26, 2010 10:08 AM

> This is my attempt to translate
> http://tools.ietf.org/html/draft-hammer-discovery-04 into = an actionable
> algorithm, as a first step in attempting to write a truly general reso= urce
> discovery library that matches the latest spec.
> It is written under the assumption that a client may wish to query for= sets of
> links with a given relvalue, and is not going to wish to retrieve and = re-parse
> host-meta files any more often than necessary. =A0Feedback welcomed! >
> Definitions
>
> startURI: Starting point for discovery; input into the discovery proce= ss.
> Discovery produces metadata for startURI.
>
> metadata: A collection of links and properties for the resource.
>
> link: An abstract edge between the startURI resource and another resou= rce
> identified by a field href. =A0Has a rel field indicating the relation= ship from
> startURI to href. Has a lrdd_pri field indicating ordering within the = rel value.
> Has a secure boolean field indicating whether it was retrieved securel= y. =A0Can
> be annotated with arbitrary properties.
>
> property: A piece of metadata about a resource less structured than a = link.
> Only present for XRD-derived data. =A0Has a secure boolean field indic= ating
> whether it was retrieved securely.

Link headers and elements can include extension parameters that are e= ither rel-specific or document specific. These will be in the form of key/v= alue pairs but in which the key is a short name, not a URI (like XRD <Pr= operty> type). In markup the can have a namespace.

I generally prefer people used the XRD <Property> facility instead of= extending the link schema (for header format).

> Algorithm
>
> Determine priority order (Host-priority or Resource-priority):
>
> lookup HostMetaLRDD(startURI)

What does this do in this context? Your Function below is aimed for g= etting metadata, not just raw host-meta.

In this context, this should be something like RawHostMeta().
=A0

> if above lookup fails because Host(startURI) is not available, priorit= y =3D
> Resource Else, does result contain
> XRD/Property@type=3Dhttp://lrdd.net/priority/resource? =A0If yes, then priori= ty
> =3D Resource. =A0Otherwise, priority =3D Host
>
> If priority =3D Host:
> =A0 // priority order is host-meta, HTTP Link, <Link> elements > =A0 metadata =3D lookup HostMetaLRDD(startURI, 1)
> =A0 augment metadata with result of lookup HeaderLinks(startURI, 2) > =A0 augment metadata with lookup ResourceLinks(startURI, 3)
>
> If priority =3D Resource:
> =A0 // priority order is <Link> elements, HTTP Link, host-meta > =A0 metadata =3D lookup ResourceLinks(startURI, 1)
> =A0 augment metadata with result of lookup HeaderLinks(startURI, 2) > =A0 augment metadata with lookup HostMetaLRDD(startURI, 3)
>
> where
>
> HostMetaLRDD(uri, pri) is:
> =A0 Revalidate local XRD data cache for hostof(uri)/.well-known/host-m= eta.

How do you handle http vs https?

= What is the default ordering in which to try? =A0I'd much prefer to mak= e https:// the default scheme for the "hostof(x)" above, failing = back to http:// with a flag indicating content was not verified by a certif= icate.

NB: =A0In starting to write code for all this, I'm = finding it useful to use nonstandard ids like foo@localhost:8080 in order t= o preserve my sanity. =A0This means "pretend you're foo@localhost,= and use 8080 as the default HTTP port for host-meta discovery, and switch = off security checks too". =A0In particular I end up having to swap aro= und between foo@localhost:8080, foo@localhost:8081, foo@localhost:8082,... = dynamically quite a bit to simulate cross-domain calls, so a static configu= ration would be quite annoying/unusable. =A0Fortunately most of the stack I= 'm using doesn't care about this, but the port needs to be passed d= own a few levels and get through some regexps. =A0Not sure how best to do t= his for real without compromising security -- perhaps allow this only for &= quot;localhost"...
=A0
Follow redirections.

...while ensuring = that one's security flag gets reset to 0 if any redirects pass through = http...
=A0
Validate host-meta is valid for the desired host.

=
What's the procedure here? =A0Just match Subject and Alias a= gainst the host?
=A0

> =A0 Find the first link with rel=3D"lrdd" in host-meta docum= ent (call
> =A0 =A0 the href value lrdd_url)

Apply template...

Ah right, you d= on't have an href until you apply(template, uri) --> href.
=A0

> =A0 Revalidate local XRD data cache for lrdd_url,annotating each link<= br> > =A0 =A0 with lrdd_pri=3Dpri
> =A0 Return metadata (non-lrdd links and properties) for lrdd_uri
>
>
> HeaderLinks(uri, pri) is:
> =A0 If uri is not dereferenceable (e.g., acct:) return empty set

If you URI is not http/https, or if a GET/HEAD returns a response tha= t does not contains a representation for the requested resource. See: http://tools.ietf.org/html/draft-ietf-httpbis-p2-se= mantics-09#section-6.1


What if it returns a 403 Forbidden? =A0Or a 5xx Temporary Server er= ror? =A0Or just times out?

=A0
> =A0 Revalidate local resource link cache for uri
> =A0 Retrieve Link: headers for resource from cache, annotating
> =A0 =A0 each link with lrdd_pri=3Dpri
> =A0 Return links to caller
>
> ResourceLinks(uri, pri) is:
> =A0 If uri is not dereferenceable (e.g., acct:) return empty set
> =A0 Revalidate local resource link cache for uri
> =A0 Retrieve MIME-type-specific set of links known for resource, annot= ating
> each
> =A0 =A0 link with lrdd_pri=3Dpri
> =A0 Return links to caller
>
>
> augment X with Y with priority pri is:
> =A0 For each set of links y in Y sharing link relation r:
> =A0 =A0 if r=3D=3D"lrdd", and X does not already
> =A0 =A0 =A0 contain a link with rel=3D"lrdd":
> =A0 =A0 =A0 augment X with results of:
> =A0 =A0 =A0 =A0 Revalidate local XRD data cache for first href for rel= =3D"lrdd",
> =A0 =A0 =A0 =A0 =A0 annotating each link with lrdd_pri=3Dpri
> =A0 =A0 =A0 =A0 Augment X with resulting metadata from href
> =A0 =A0 else,
> =A0 =A0 =A0 add list of links y to X.
> =A0 =A0 =A0 Add all properties in Y to X.
>
>
> NB: Some link types can contain space-separated rel values, which are<= br> > interpreted as a series of links with each of the space-separated rel = value
> names in the above algorithm.
>
> NB: Ordering of links and properties from each source with the same re= l/type
> values is retained throughout, with the caveat that HTTP headers do no= t
> have a guaranteed stable order.
>
> Security is not shown here, but is based on either TLS used throughout= the
> retrievals or (for XRD) the XRD signature specification. =A0Content ty= pe specific
> security may also be used to verify links within content (e.g., Magic<= br> > Signatures over link elements). =A0When set, the secure boolean indica= tes that
> a specific link or property was retrieved securely; when not set, it i= ndicates
> that the retrieval path contained one or more insecure steps. =A0The a= lgorithm
> will also reject data that is red-flagged (e.g., if a CRL check shows = that a
> certificate has been revoked as opposed to merely expiring). =A0(?) >
> Result:
>
> An ordered collection of metadata, consisting of links and properties,= each of
> which is annotated with its lrdd_pri in case it matters. =A0There is a= t most one
> rel=3D"lrdd" link in the collection which identifies the spe= cific LRDD document
> used, if any, and any metadata from that lrdd document is transcluded = into
> the metadata collection.

There can be more than one LRDD document, but only one is used = from each source. There should not be any rel=3D'lrdd' in the colle= ction because it is either expanded or dropped (not first).

This algorithm was just tracking the address of the one= that was expanded (not 100% necessary but useful for debuggability).
=

I think that "Any "lrdd" links other tha= n the first MUST be ignored." in section 3, step 2, is confusing: =A0I= had interpreted "first" as the first one encountered globally, b= ut your note implies that you can have up to 3 LRDD documents to peek insid= e (one from each source).

I'm not sure that the limitation of one LRDD link p= er source helps anything in the algorithm in this case.
=A0
=

> A client which wishes to coalesce links and properties found in all th= ree
> places within a given rel or type value can just query the collection = for the
> desired rel or type and retrieve collections of links or properties. >
> Once retrieved, the set of metadata can be queried. =A0An important/us= eful
> query is to retrieve the list of links with a given rel value:
>
> get_links(metadata, rel) =A0# Get sequence of links with given rel val= ue, or
> empty list if not found.
>
> Sometimes you may require that only the first set of links found
> count:
>
> get_top_priority_links(metadata, rel) =A0# Get sequence of links with = given rel
> value, ignoring all but the first set found
>
> ...and of course you can do a similar query for properties.

EHL


--000e0cd1095636a97a048382f333-- From ajs@shinkuro.com Mon Apr 5 14:35:52 2010 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 6917628C0F1 for ; Mon, 5 Apr 2010 14:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_05=-1.11] 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 At4ogSO4JJ4n for ; Mon, 5 Apr 2010 14:35:51 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 69CF028C0EB for ; Mon, 5 Apr 2010 14:35:51 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A44331ECB4E8 for ; Mon, 5 Apr 2010 21:35:48 +0000 (UTC) Date: Mon, 5 Apr 2010 17:35:43 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Subject: Re: weighting transports Message-ID: <20100405213543.GA56655@shinkuro.com> References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <20100405175637.GG55035@shinkuro.com> <4BBA2971.9030406@cisco.com> <20100405182603.GK55035@shinkuro.com> <4BBA2D22.1070700@cisco.com> <20100405184401.GO55035@shinkuro.com> <20100405191148.GR4225@Sun.COM> <20100405192039.GA56132@shinkuro.com> <20100405192455.GT4225@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100405192455.GT4225@Sun.COM> User-Agent: Mutt/1.5.18 (2008-05-17) 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, 05 Apr 2010 21:35:52 -0000 On Mon, Apr 05, 2010 at 02:24:55PM -0500, Nicolas Williams wrote: > Yes, but this way you lose the referential integrity features of the > RDBMS w.r.t. the new RR's RDATA. That's not cool, and it's a non-answer > to the question posed (I specifically menaioned referential integrity in > the question for a reason :) Oh, come on. Now what you're asking for is that old software be infinitely forward-compatible. Moreover, the plain fact is that the DNS is not a relational database, and it is nowise plain to me that every possible use of every DNS RRTYPE is going to fit properly into a referential model, even if you really wanted it to. TXT records overloaded to handle everything under the sun won't maintain referential integrity either except in the boring sense that your tools can claim it's there. All the important checks that you'd actually want are going to be hidden inside the semantics of the TXT record as privately defined by some other trick (like underscore labels). I find it passing belief that people who'd be exercised about missing referential integrity for opaque datatypes would be just fine with a conflation of data value and data typing. (On the other hand, I once consulted for someone whose "database experts" had written mainline runs-80%-of-the time queries with 14 -- no exaggeration -- CASE statements in them. "This fit the data model." I know there's a hammer around here somewhere . . .) > In this case the alternative to new RR types is parallelized probing. Or both, of course. You try one, see whether it's working for you, and if not you fall back to the thing you don't like to do. Why do we have to chose? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ajs@shinkuro.com Mon Apr 5 14:41:10 2010 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 6BF8528C100 for ; Mon, 5 Apr 2010 14:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[AWL=1.197, 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 wAylmWMyYVRv for ; Mon, 5 Apr 2010 14:41:09 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 8AE2D3A6A8D for ; Mon, 5 Apr 2010 14:41:08 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 522F81ECB4E8 for ; Mon, 5 Apr 2010 21:41:06 +0000 (UTC) Date: Mon, 5 Apr 2010 17:41:04 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Subject: Re: RR vs. underscore Message-ID: <20100405214104.GB56655@shinkuro.com> References: <4BBA3B2C.9080908@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4BBA3B2C.9080908@dcrocker.net> User-Agent: Mutt/1.5.18 (2008-05-17) 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, 05 Apr 2010 21:41:10 -0000 On Mon, Apr 05, 2010 at 12:34:04PM -0700, Dave CROCKER wrote: > While a new RR is the cleanest approach for extending DNS response data > semantics, it has been a barrier for 20+ years. […] > Underscore-based naming . . . has fared considerably better Note that in my original remarks that (regrettably, I now think) revived this discussion, I included an example where underscores wouldn't help either: the stupid middlebox just thinks that it is only ever replying to A queries, so it doesn't matter what you ask it. The same is, alas, apparently true (I've heard this before) in the VB APIs, so you just can't get anything useful out of the DNS as far as the application is concerned. Arguing about whether to use a new RRTYPE or whether to lard up existing RRTYPEs with additional semantics using underscore names is, in my view, a distraction from that more central problem: some implementers of things that stand between your application and the DNS have made foolish simplifying assumptions about what you might want. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From tim.kosse@filezilla-project.org Mon Apr 5 14:43:37 2010 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 19EA23A68E9 for ; Mon, 5 Apr 2010 14:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 MhNoDyy7UbpI for ; Mon, 5 Apr 2010 14:43:36 -0700 (PDT) Received: from filezilla-project.org (cl-1464.dus-01.de.sixxs.net [IPv6:2a01:198:200:5b7::2]) by core3.amsl.com (Postfix) with ESMTP id F0C5B3A689C for ; Mon, 5 Apr 2010 14:43:35 -0700 (PDT) Received: from [2a01:198:458::59] by filezilla-project.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Nyu4t-0002Ts-0Z for apps-discuss@ietf.org; Mon, 05 Apr 2010 23:43:31 +0200 Message-ID: <4BBA597C.8070307@filezilla-project.org> Date: Mon, 05 Apr 2010 23:43:24 +0200 From: Tim Kosse User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Re: draft-bryan-ftp-hash-00 -- items for discussion References: <201003231642.RAA04676@TR-Sys.de> <201004011954.VAA28916@TR-Sys.de> In-Reply-To: <201004011954.VAA28916@TR-Sys.de> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig66980D00E4EAF5F251211968" 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, 05 Apr 2010 21:43:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig66980D00E4EAF5F251211968 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, On 2010-04-01 21:54, Alfred =EF=BF=BD wrote: > a) untypical use of a command with a file path argument *and* > another argument -- consider using: > OPTS HASH > HASH we are currently preparing a new version of the draft which uses this proposed syntax. > b) underspecification of the representation of the file that shall > undergo the hash calculation; a canonical form of the file is > essential here for interoperability > [...] some of the options that came to my mind: using the current > transfer mode settings, defining a specific overriding set of > mode settings, or requiring a single specific set of mode > settings to be active (or a small choice of such). Unfortunately neither option is perfect. Considering the most common use cases however I would go with the latter options, using a specific set of mode settings. A related issue are partial hashes. In some situations it might be useful to only get the hash of a portion of a file. It could for example be used to find out where two files differ, in order to only transfer the mismatching part instead of the whole file. Having two many parameters however would make caching difficult and might impose heavy load on servers which is not desirable. > Further, I'd like to draw your attention to RFC 5797 and the > FTP Commands and Extensions IANA Registry it has established now, at > ftp-commands-extensions.xhtml> ). The "IANA Considerations" section will be updated in the next version of the draft. Regards, Tim Kosse --------------enig66980D00E4EAF5F251211968 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAku6WXwACgkQ8N9+lcqiUkV8lQCY+sfPsxO7RBZ/OrpuVTpizG5u JwCfRzfGJHX3VXUC9VVvga1+rRkaOsM= =xhyp -----END PGP SIGNATURE----- --------------enig66980D00E4EAF5F251211968-- From Nicolas.Williams@sun.com Mon Apr 5 14:49:44 2010 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 905A43A67E1 for ; Mon, 5 Apr 2010 14:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 kG+yKv7odfkP for ; Mon, 5 Apr 2010 14:49:43 -0700 (PDT) Received: from rcsinet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by core3.amsl.com (Postfix) with ESMTP id 6380D3A68E9 for ; Mon, 5 Apr 2010 14:49:43 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o35LndKX028188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Apr 2010 21:49:40 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o35EiTms003558; Mon, 5 Apr 2010 21:49:38 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 148274981270504175; Mon, 05 Apr 2010 14:49:35 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Apr 2010 14:49:34 -0700 Date: Mon, 5 Apr 2010 16:49:30 -0500 From: Nicolas Williams To: Andrew Sullivan Subject: Re: weighting transports Message-ID: <20100405214929.GF4225@Sun.COM> References: <4BB61DE1.9070601@dcrocker.net> <20100405175637.GG55035@shinkuro.com> <4BBA2971.9030406@cisco.com> <20100405182603.GK55035@shinkuro.com> <4BBA2D22.1070700@cisco.com> <20100405184401.GO55035@shinkuro.com> <20100405191148.GR4225@Sun.COM> <20100405192039.GA56132@shinkuro.com> <20100405192455.GT4225@Sun.COM> <20100405213543.GA56655@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100405213543.GA56655@shinkuro.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BBA5AF3.0007,ss=1,fgs=0 Cc: apps-discuss@ietf.org 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, 05 Apr 2010 21:49:44 -0000 On Mon, Apr 05, 2010 at 05:35:43PM -0400, Andrew Sullivan wrote: > On Mon, Apr 05, 2010 at 02:24:55PM -0500, Nicolas Williams wrote: > > Yes, but this way you lose the referential integrity features of the > > RDBMS w.r.t. the new RR's RDATA. That's not cool, and it's a non-answer > > to the question posed (I specifically menaioned referential integrity in > > the question for a reason :) > > Oh, come on. Now what you're asking for is that old software be > infinitely forward-compatible. Moreover, the plain fact is that the No, I'm stating that there exist barriers to deployment of new RRs. > DNS is not a relational database, and it is nowise plain to me that > every possible use of every DNS RRTYPE is going to fit properly into a > referential model, even if you really wanted it to. TXT records That does not mean that DNS data that one maintains cannot be modelled as an object-relational database. I supported (for internal customers) a product that did just that. Excluding NAPTR (which always gives me headaches), probably incorrectly, I can't think of any RR that can't be generated from an RDBMS that models DNS data as relational. > overloaded to handle everything under the sun won't maintain > referential integrity either except in the boring sense that your > tools can claim it's there. All the important checks that you'd > actually want are going to be hidden inside the semantics of the TXT > record as privately defined by some other trick (like underscore > labels). I find it passing belief that people who'd be exercised > about missing referential integrity for opaque datatypes would be just > fine with a conflation of data value and data typing. (On the other I'm Ok with TXT RRs provided there are clear rules for determining the format of the text payload given the RR name. (I'm also Ok with free-form text payloads if they are intended for human consumption.) > hand, I once consulted for someone whose "database experts" had > written mainline runs-80%-of-the time queries with 14 -- no > exaggeration -- CASE statements in them. "This fit the data model." > I know there's a hammer around here somewhere . . .) The database I mentioned had no such problems. (It's open source now, under GPL, so you can always go look at it yourself. It's getting dated now, but it's still in use.) > > In this case the alternative to new RR types is parallelized probing. > > Or both, of course. You try one, see whether it's working for you, > and if not you fall back to the thing you don't like to do. Why do we > have to chose? For all the reasons given earlier. From ajs@shinkuro.com Mon Apr 5 15:07:10 2010 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 3F43D3A69EE for ; Mon, 5 Apr 2010 15:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=1.077, 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 xKIm95icGTGv for ; Mon, 5 Apr 2010 15:07:09 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 28F123A68AE for ; Mon, 5 Apr 2010 15:07:06 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6BC991ECB4E8 for ; Mon, 5 Apr 2010 22:07:03 +0000 (UTC) Date: Mon, 5 Apr 2010 18:07:01 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Subject: Re: weighting transports Message-ID: <20100405220701.GD56655@shinkuro.com> References: <20100405175637.GG55035@shinkuro.com> <4BBA2971.9030406@cisco.com> <20100405182603.GK55035@shinkuro.com> <4BBA2D22.1070700@cisco.com> <20100405184401.GO55035@shinkuro.com> <20100405191148.GR4225@Sun.COM> <20100405192039.GA56132@shinkuro.com> <20100405192455.GT4225@Sun.COM> <20100405213543.GA56655@shinkuro.com> <20100405214929.GF4225@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100405214929.GF4225@Sun.COM> User-Agent: Mutt/1.5.18 (2008-05-17) 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, 05 Apr 2010 22:07:10 -0000 On Mon, Apr 05, 2010 at 04:49:30PM -0500, Nicolas Williams wrote: > I'm Ok with TXT RRs provided there are clear rules for determining the > format of the text payload given the RR name. (I'm also Ok with > free-form text payloads if they are intended for human consumption.) I'm sure you've heard this broken record before, but inside the protocol, that requirement can't be met. The very nature of a TXT record is that there is no restriction on what you might put in it. So it's now a matter of registration policy what the RDATA of the TXT record at a given owner name may be. So now you have two places that control the allowable values for the RRs you allow in: there are the protocol-defined rules about what goes in a resource record, and then there are localized rules (some of them in protocol documents) that specify special handling of some of those protocol-defined resource records, if the data in them is just so. Now, from a practical point of view, of course, we can do that, filthy hack though it be. I rather think Mssrs Codd, Date, and the rest of them would start to get a little annoyed if you told them that, in order to find out just how you're supposed to handle a given row of data inside the database you have to look at a particular datum, and draw some conclusions from that. In a typed database like the DNS, it ought to give data people the heebie-jeebies to hear that the solution to datatype extensibility is to subtype all the data and overload one datatype. _Especially_ when overloading that datatype won't allow everyone to use it (because they can't see anything except A or maybe AAAA records) and when there is in fact an existing datatype extension mechanism. Also, of course, just to make things more entertaining, the underscore mechanism has been used in two slightly different ways. > > Or both, of course. You try one, see whether it's working for you, > > and if not you fall back to the thing you don't like to do. Why do we > > have to chose? > > For all the reasons given earlier. I must have missed the argument where someone explained why an application couldn't have both mechanisms available, and make intellingent decisions about what it's going to be able to do depending on its environment. (I mean, every single network application for at least the past 10 years has had to cope with NAT this way. No?) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Nicolas.Williams@sun.com Mon Apr 5 15:14:47 2010 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 65AE93A69EE for ; Mon, 5 Apr 2010 15:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 wmN5UfzYLb4t for ; Mon, 5 Apr 2010 15:14:41 -0700 (PDT) Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by core3.amsl.com (Postfix) with ESMTP id D30483A6896 for ; Mon, 5 Apr 2010 15:14:35 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o35MEVtK013106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Apr 2010 22:14:33 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o35MEUZ2007961; Mon, 5 Apr 2010 22:14:31 GMT Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 148326291270505566; Mon, 05 Apr 2010 15:12:46 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Apr 2010 15:12:46 -0700 Date: Mon, 5 Apr 2010 17:12:41 -0500 From: Nicolas Williams To: Andrew Sullivan Subject: Re: weighting transports Message-ID: <20100405221241.GG4225@Sun.COM> References: <4BBA2971.9030406@cisco.com> <20100405182603.GK55035@shinkuro.com> <4BBA2D22.1070700@cisco.com> <20100405184401.GO55035@shinkuro.com> <20100405191148.GR4225@Sun.COM> <20100405192039.GA56132@shinkuro.com> <20100405192455.GT4225@Sun.COM> <20100405213543.GA56655@shinkuro.com> <20100405214929.GF4225@Sun.COM> <20100405220701.GD56655@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100405220701.GD56655@shinkuro.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BBA60C7.0158,ss=1,fgs=0 Cc: apps-discuss@ietf.org 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, 05 Apr 2010 22:14:47 -0000 On Mon, Apr 05, 2010 at 06:07:01PM -0400, Andrew Sullivan wrote: > On Mon, Apr 05, 2010 at 04:49:30PM -0500, Nicolas Williams wrote: > > > I'm Ok with TXT RRs provided there are clear rules for determining the > > format of the text payload given the RR name. (I'm also Ok with > > free-form text payloads if they are intended for human consumption.) > > I'm sure you've heard this broken record before, but inside the > protocol, that requirement can't be met. The very nature of a TXT > record is that there is no restriction on what you might put in it. If a protocol says that _foo._bar.. IN TXT must have a text payload with such and such format, then that is what will be expected by the clients that look for TXT RRs named _foo._bar... Sure, they might get garbage, but how is that not true of any other RRs? (e.g., I might get an IP address in an A RR RDATA, and it might be well be a useless one.) > Now, from a practical point of view, of course, we can do that, filthy > hack though it be. I rather think Mssrs Codd, Date, and the rest of > them would start to get a little annoyed if you told them that, in > order to find out just how you're supposed to handle a given row of > data inside the database you have to look at a particular datum, and > draw some conclusions from that. In a typed database like the DNS, it > ought to give data people the heebie-jeebies to hear that the solution > to datatype extensibility is to subtype all the data and overload one > datatype. _Especially_ when overloading that datatype won't allow > everyone to use it (because they can't see anything except A or maybe > AAAA records) and when there is in fact an existing datatype extension > mechanism. Also, of course, just to make things more entertaining, > the underscore mechanism has been used in two slightly different ways. I don't think of DNS as a database. I think of DNS as serving data generated by a database (and also updated dynamically). > > For all the reasons given earlier. > > I must have missed the argument where someone explained why an > application couldn't have both mechanisms available, and make > intellingent decisions about what it's going to be able to do > depending on its environment. (I mean, every single network > application for at least the past 10 years has had to cope with NAT > this way. No?) It adds unnecessary complexity to solve... what problem? Probing seems like good enough to me. From ajs@shinkuro.com Mon Apr 5 15:55:12 2010 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 6EA053A6876 for ; Mon, 5 Apr 2010 15:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[AWL=0.979, 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 TMVXtHL1ccUk for ; Mon, 5 Apr 2010 15:55:11 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 208D93A69EE for ; Mon, 5 Apr 2010 15:55:11 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id ECCFF1ECB4E8 for ; Mon, 5 Apr 2010 22:55:07 +0000 (UTC) Date: Mon, 5 Apr 2010 18:55:02 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Subject: Re: weighting transports Message-ID: <20100405225502.GA57008@shinkuro.com> References: <20100405182603.GK55035@shinkuro.com> <4BBA2D22.1070700@cisco.com> <20100405184401.GO55035@shinkuro.com> <20100405191148.GR4225@Sun.COM> <20100405192039.GA56132@shinkuro.com> <20100405192455.GT4225@Sun.COM> <20100405213543.GA56655@shinkuro.com> <20100405214929.GF4225@Sun.COM> <20100405220701.GD56655@shinkuro.com> <20100405221241.GG4225@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100405221241.GG4225@Sun.COM> User-Agent: Mutt/1.5.18 (2008-05-17) 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, 05 Apr 2010 22:55:12 -0000 On Mon, Apr 05, 2010 at 05:12:41PM -0500, Nicolas Williams wrote: > If a protocol says that _foo._bar.. IN TXT must have a text > payload with such and such format, then that is what will be expected by > the clients that look for TXT RRs named _foo._bar. But it is not what the DNS protocol requires. That is, it is syntactically correct for someone to put something else in the RDATA for that TXT record, and any DNS server will serve it up. This is a fantastic vector for attacks as a result. > get garbage, but how is that not true of any other RRs? (e.g., I might > get an IP address in an A RR RDATA, and it might be well be a useless > one.) But you won't get random binary data poisoning caches, because well-built caches will detect a malformed resource record and refuse to cache it. > I don't think of DNS as a database. I think of DNS as serving data > generated by a database (and also updated dynamically). Hrm. I suspect you and I have different meanings of the word "database". DNS is certainly not a relational database. But I think you'll find that the DNS protocol documents and people working on it have commonly referred to the DNS as a distributed database, or else "having" a distributed database (this is not the same thing as the "database" in your usage above, which in my reading is approximately the zone data or, in old-fashioned terms, the "zone file" at the "master server"). > It adds unnecessary complexity to solve... what problem? Probing seems > like good enough to me. I thought the problem was that probing was maybe too costly in at least some circumstances. That was the argument I thought I heard from Dan Wing. Though I get the impression he gave up and will fall back to probing. So maybe you're right: this really is a waste of time. Sorry. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Nicolas.Williams@sun.com Mon Apr 5 16:02:17 2010 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 F20BB28B23E for ; Mon, 5 Apr 2010 16:02:16 -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.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 UsrKdSqsIC8t for ; Mon, 5 Apr 2010 16:02:16 -0700 (PDT) Received: from rcsinet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by core3.amsl.com (Postfix) with ESMTP id A61FC3A6A24 for ; Mon, 5 Apr 2010 16:02:15 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o35N2Cdx017974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Apr 2010 23:02:13 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o35IRjQW021362; Mon, 5 Apr 2010 23:02:12 GMT Received: from abhmt003.oracle.com by acsmt353.oracle.com with ESMTP id 148417691270508481; Mon, 05 Apr 2010 16:01:21 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Apr 2010 16:01:21 -0700 Date: Mon, 5 Apr 2010 18:01:16 -0500 From: Nicolas Williams To: Andrew Sullivan Subject: Re: weighting transports Message-ID: <20100405230116.GJ4225@Sun.COM> References: <4BBA2D22.1070700@cisco.com> <20100405184401.GO55035@shinkuro.com> <20100405191148.GR4225@Sun.COM> <20100405192039.GA56132@shinkuro.com> <20100405192455.GT4225@Sun.COM> <20100405213543.GA56655@shinkuro.com> <20100405214929.GF4225@Sun.COM> <20100405220701.GD56655@shinkuro.com> <20100405221241.GG4225@Sun.COM> <20100405225502.GA57008@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100405225502.GA57008@shinkuro.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BBA6BF4.0069,ss=1,fgs=0 Cc: apps-discuss@ietf.org 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, 05 Apr 2010 23:02:17 -0000 On Mon, Apr 05, 2010 at 06:55:02PM -0400, Andrew Sullivan wrote: > On Mon, Apr 05, 2010 at 05:12:41PM -0500, Nicolas Williams wrote: > > > If a protocol says that _foo._bar.. IN TXT must have a text > > payload with such and such format, then that is what will be expected by > > the clients that look for TXT RRs named _foo._bar. > > But it is not what the DNS protocol requires. That is, it is > syntactically correct for someone to put something else in the RDATA > for that TXT record, and any DNS server will serve it up. This is a > fantastic vector for attacks as a result. Sure. But that's not important. > > get garbage, but how is that not true of any other RRs? (e.g., I might > > get an IP address in an A RR RDATA, and it might be well be a useless > > one.) > > But you won't get random binary data poisoning caches, because > well-built caches will detect a malformed resource record and refuse > to cache it. You should expect random binary data and not let it poison you. > > I don't think of DNS as a database. I think of DNS as serving data > > generated by a database (and also updated dynamically). > > Hrm. I suspect you and I have different meanings of the word > "database". DNS is certainly not a relational database. But I think > you'll find that the DNS protocol documents and people working on it > have commonly referred to the DNS as a distributed database, or else > "having" a distributed database (this is not the same thing as the > "database" in your usage above, which in my reading is approximately > the zone data or, in old-fashioned terms, the "zone file" at the > "master server"). Yes, but it's so... basic. > > It adds unnecessary complexity to solve... what problem? Probing seems > > like good enough to me. > > I thought the problem was that probing was maybe too costly in at > least some circumstances. That was the argument I thought I heard > from Dan Wing. Though I get the impression he gave up and will fall > back to probing. So maybe you're right: this really is a waste of > time. Sorry. I'd agree except that if the middle-boxes-drop-SCTP problem is real (and I believe it is, but I don't use SCTP much, so I don't know from first-hand experience) then only probing will help you. Caching will more than alleviate the extra probing overhead in most cases, and servers had better be able to cope anyways. Nico -- From dhc@dcrocker.net Mon Apr 5 16:13:39 2010 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 AC5EE3A6842 for ; Mon, 5 Apr 2010 16:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.867 X-Spam-Level: X-Spam-Status: No, score=-5.867 tagged_above=-999 required=5 tests=[AWL=0.732, 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 PmGurcB-t6fz for ; Mon, 5 Apr 2010 16:13:38 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 472F23A63D3 for ; Mon, 5 Apr 2010 16:13:38 -0700 (PDT) Received: from [192.168.1.14] (adsl-67-127-191-90.dsl.pltn13.pacbell.net [67.127.191.90]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o35NDUEe006717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Apr 2010 16:13:36 -0700 Message-ID: <4BBA6E9B.1080707@dcrocker.net> Date: Mon, 05 Apr 2010 16:13:31 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Sullivan Subject: Re: weighting transports References: <20100405182603.GK55035@shinkuro.com> <4BBA2D22.1070700@cisco.com> <20100405184401.GO55035@shinkuro.com> <20100405191148.GR4225@Sun.COM> <20100405192039.GA56132@shinkuro.com> <20100405192455.GT4225@Sun.COM> <20100405213543.GA56655@shinkuro.com> <20100405214929.GF4225@Sun.COM> <20100405220701.GD56655@shinkuro.com> <20100405221241.GG4225@Sun.COM> <20100405225502.GA57008@shinkuro.com> In-Reply-To: <20100405225502.GA57008@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10703/Mon Apr 5 10:07:08 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 05 Apr 2010 16:13:36 -0700 (PDT) Cc: apps-discuss@ietf.org 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, 05 Apr 2010 23:13:39 -0000 On 4/5/2010 3:55 PM, Andrew Sullivan wrote: > On Mon, Apr 05, 2010 at 05:12:41PM -0500, Nicolas Williams wrote: > >> If a protocol says that _foo._bar.. IN TXT must have a text >> payload with such and such format, then that is what will be expected by >> the clients that look for TXT RRs named _foo._bar. > > But it is not what the DNS protocol requires. That is, it is > syntactically correct for someone to put something else in the RDATA > for that TXT record, and any DNS server will serve it up. This is a > fantastic vector for attacks as a result. First, the uses of TXT records at an underscore leaf are specified by additional documents. The fact that the core DNS engine doesn't care is largely the reason that the underscore convention is appealing. As for being an attack vector, it is the business of the additional documents to explore such possibilities. If one goes wandering into underscore name space without having any idea what further specifications apply, well, that would be unfortunate. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From patrik@frobbit.se Mon Apr 5 22:45:49 2010 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 A72793A68C1 for ; Mon, 5 Apr 2010 22:45:49 -0700 (PDT) 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 RpnQp6AI23WA for ; Mon, 5 Apr 2010 22:45:48 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id 0C7363A68B0 for ; Mon, 5 Apr 2010 22:45:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id C1146AA4F66B; Tue, 6 Apr 2010 07:45:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mpt2BWms8dHW; Tue, 6 Apr 2010 07:45:42 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::dead:beef] (unknown [IPv6:2a02:80:3ffc::dead:beef]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 2F6A0AA4F65B; Tue, 6 Apr 2010 07:45:42 +0200 (CEST) Subject: Re: weighting transports Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-25-167765596" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4BBA6E9B.1080707@dcrocker.net> Date: Tue, 6 Apr 2010 07:45:41 +0200 Content-Transfer-Encoding: 7bit Message-Id: <7E942027-337D-4112-90B8-A9E8472B7255@frobbit.se> References: <20100405182603.GK55035@shinkuro.com> <4BBA2D22.1070700@cisco.com> <20100405184401.GO55035@shinkuro.com> <20100405191148.GR4225@Sun.COM> <20100405192039.GA56132@shinkuro.com> <20100405192455.GT4225@Sun.COM> <20100405213543.GA56655@shinkuro.com> <20100405214929.GF4225@Sun.COM> <20100405220701.GD56655@shinkuro.com> <20100405221241.GG4225@Sun.COM> <20100405225502.GA57008@shinkuro.com> <4BBA6E9B.1080707@dcrocker.net> To: dcrocker@bbiw.net X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1078) Cc: apps-discuss@ietf.org 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, 06 Apr 2010 05:45:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-25-167765596 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 6 apr 2010, at 01.13, Dave CROCKER wrote: > First, the uses of TXT records at an underscore leaf are specified by = additional documents. The fact that the core DNS engine doesn't care is = largely the reason that the underscore convention is appealing. The core DNS engine do not care about new RR types, as it can handle = unknown RR Types (as compared to say 10 years ago). This is why I = reacted on your comment on "it has been hard for 20 years", as it was = hard 10 years ago. It is not hard to add new RR types now. > As for being an attack vector, it is the business of the additional = documents to explore such possibilities. Too easy to say. Just look at the various attacks we have regarding = layering in other protocols. > If one goes wandering into underscore name space without having any = idea what further specifications apply, well, that would be unfortunate. The main problems with underscores are two: 1. You can not have two records with the same owner and same class. You = want that sometimes, as there are RR Types that do by definition have = the same owner as already existing records. Such as the DNSSEC records. 2. You can have a zone cut at the periods, and in some cases you = explicitly do not want a zone cut between records. See the trouble with = the NS record sets for Microsoft AD that create quite some problems at = the moment. The best path forward is to define a new RR Type, and reusing TXT is = just not good at all. Using an underscore name is of course the only selector you have IF = records have the same RR Type as SRV, so that is "sort of ok", but then = the RR Type is still structured. One should NOT do neither (no underscore, no special RR Type). Patrik --Apple-Mail-25-167765596 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFLusqFrMabGguI180RAoU3AJ9BSvX6hGvbVsEwkGO/AVSl/hpo+wCZAQJ3 rm0x8zgr/ffdsS5DJDKdbvU= =dFBL -----END PGP SIGNATURE----- --Apple-Mail-25-167765596-- From patrik@frobbit.se Mon Apr 5 23:01:07 2010 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 DB15C3A6812 for ; Mon, 5 Apr 2010 23:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 SWk96cdx6mwG for ; Mon, 5 Apr 2010 23:01:05 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id 4D6FF3A67D2 for ; Mon, 5 Apr 2010 23:01:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 2E8E4AA4FF7C; Tue, 6 Apr 2010 08:01:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opU7hdjQ1zDQ; Tue, 6 Apr 2010 08:01:00 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::dead:beef] (unknown [IPv6:2a02:80:3ffc::dead:beef]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 52B99AA4FF6E; Tue, 6 Apr 2010 08:00:59 +0200 (CEST) Subject: Re: weighting transports Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-26-168678048" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100405175637.GG55035@shinkuro.com> Date: Tue, 6 Apr 2010 08:00:53 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <20100405175637.GG55035@shinkuro.com> To: Andrew Sullivan X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1078) Cc: apps-discuss@ietf.org 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, 06 Apr 2010 06:01:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-26-168678048 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 5 apr 2010, at 19.56, Andrew Sullivan wrote: > I'm not sure from whom you heard this, but here's approximately > everything I know about the getting of and deploying new DNS RRTYPEs. >=20 > 1. Getting a new RRTYPE is done by expert review. Some of the > experts on the panel have not been as fast as we'd like about > turnaround, but we've had more than one successful assignment of > RRTYPE numbers under this process over the past little while. In at > least one case, and maybe two, there were many people who thought the > RRTYPE in question was a Bad Idea. Didn't matter. They met the > criteria, so they're in. Correct. > 2. Practically every deployed name server in the world can deal with > unknown RRTYPEs any more. There are some exceptions, of course. But > I do not believe that anyone who seriously needs a new RRTYPE is going > to be prevented from using it because of the lack of support in an > authority or infrastructure-grade recursive nameserver. Those nameservers that do not support unknown resource record types (or = the new RR Types of course) should be replaced for other reasons. The = number of attacks that have been invented the last 10-15 years is quite = significant. And various projects exists in the world to ensure that for = example Bind version 8 or earlier is removed from the net. > 3. There is a distressing number of middleboxes on the Internet that > do hideous things to DNS packets. This includes brilliant behaviour > (I have actually seen this) such as treating every single DNS request > as a lookup for A records, which means that if you ask for anything > else at a name you either get nothing or an A record back. These are > in decline, but their population is not negligible. You should assume > users will sometimes have such a thing in the way. As DNSSEC > deployment becomes more widespread, we may find some of these getting > replaced because of how they break DNSSEC. This of course has impact on the new RR Type, but also lookup of other = RR Types that are not A. The software dnsmasq for example is widely = deployed and do not support TXT, SRV etc without changes in the = configuration and in some cases patches. But, those things will not be changed if not IETF do not only say for = real that unknown RR Types are needed (IETF has already said so) but = also start requiring that for good deployment. > 4. The OS APIs to get anything meaningful out of the DNS are not > there, and when they are they're often not used much. That is, if you > want to look up your favourite RRTYPE on many OSes, you're stuck doing > all the resolution yourself either because the underlying system > doesn't do it right, or else getting the system to do it right is > harder than just implementing some minimal resolver yourself. If one want to look up anything else than standard address records, you = must almost always dive down one layer deeper in the resolver code -- or = like Firefox include your own resolver. This INCLUDE the TXT record. I.e. the code I have written during the years do not make any difference = in the code itself whether I want TXT, SRV or a new RR Type I write = myself. > 5. Application people shouldn't have to care about the DNS anyway: > it's too far down the stack. So the pressure to change (4) isn't > there. (I don't speak authoritatively on this one, but someone gave > me a compelling argument to this effect over lunch in Anaheim, and I > think I agree.) Application people do have to care, because as soon as you want to do = something more than call libcurl and fetch some blob over HTTP, you have = to do quite a lot by yourself. But, that is not hard, and definitely not the hardest part of any = software one is writing. Specifically when using the resolver library = that is included in the operating system. I would add 6. here, and that is the provisioning that many people are = talking about. Provisioning of new RR Types might be confusing for some = people. *Specifically* people that are active in the IETF and similar = organisations because those individuals are the (few) ones that still = edit the zone files by hand in a text editor, and understanding the = encoding of unknown RR Types is not easy. It is not even easy to find = the documentation! I think the people that come up with new RR Types can = make it easier for people by giving examples. I.e. the following is not = very easy to understand is it: paf> dig frobbit.se TYPE64999 +short \# 15 763D73706631202B6D78202D616C6C For provisioning systems, people have to add support for new RR Types, = or at least support unknown RR Types just like I show in the example = above. There is a reason why the DNS world started requiring unknown RR Types = say 10-15 years ago, and I do not like seeing people still fighting = against when we are so close to get it there. Patrik --Apple-Mail-26-168678048 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFLus4WrMabGguI180RAjUnAJ4/STNEGrX39Q7dYoXQOC/JbIh87QCgiuym qDpcqGCxlRALhAfQtKTHgHM= =4/Nl -----END PGP SIGNATURE----- --Apple-Mail-26-168678048-- From daniel@haxx.se Tue Apr 6 01:15:49 2010 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 2EFF43A69A3 for ; Tue, 6 Apr 2010 01:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 v2ANRL6+cV5I for ; Tue, 6 Apr 2010 01:15:48 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by core3.amsl.com (Postfix) with ESMTP id C4C313A67C0 for ; Tue, 6 Apr 2010 01:15:47 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with ESMTP id o368FZAj018557; Tue, 6 Apr 2010 10:15:35 +0200 Date: Tue, 6 Apr 2010 10:15:35 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Tim Kosse Subject: Re: draft-bryan-ftp-hash-00 -- items for discussion In-Reply-To: <4BBA597C.8070307@filezilla-project.org> Message-ID: References: <201003231642.RAA04676@TR-Sys.de> <201004011954.VAA28916@TR-Sys.de> <4BBA597C.8070307@filezilla-project.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: apps-discuss@ietf.org 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, 06 Apr 2010 08:15:49 -0000 On Mon, 5 Apr 2010, Tim Kosse wrote: > A related issue are partial hashes. In some situations it might be useful to > only get the hash of a portion of a file. It could for example be used to > find out where two files differ, in order to only transfer the mismatching > part instead of the whole file. > > Having two many parameters however would make caching difficult and might > impose heavy load on servers which is not desirable. Perhaps it will make sense to allow the server to deny answering to partial hashes? Or even include the range in the response so that the client can see what data range the checksum is for. It wouldn't be completely strange to me to use the REST position as start position for the hash calculation. -- / daniel.haxx.se From duerst@it.aoyama.ac.jp Tue Apr 6 02:58:46 2010 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 7C8F43A697D for ; Tue, 6 Apr 2010 02:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.81 X-Spam-Level: ** X-Spam-Status: No, score=2.81 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 NAFrONkWq5kS for ; Tue, 6 Apr 2010 02:58:45 -0700 (PDT) Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id B64783A698C for ; Tue, 6 Apr 2010 02:58:42 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id o369wTuL028703 for ; Tue, 6 Apr 2010 18:58:29 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 2c74_7949_f3bf7a7a_4162_11df_9937_001d096c566a; Tue, 06 Apr 2010 18:58:29 +0900 Received: from [IPv6:::1] ([133.2.210.1]:51592) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 6 Apr 2010 18:58:30 +0900 Message-ID: <4BBB05C0.9040604@it.aoyama.ac.jp> Date: Tue, 06 Apr 2010 18:58:24 +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.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: Andrew Sullivan Subject: Re: weighting transports References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <20100405175637.GG55035@shinkuro.com> <4BBA2971.9030406@cisco.com> <20100405182603.GK55035@shinkuro.com> <4BBA2D22.1070700@cisco.com> <20100405184401.GO55035@shinkuro.com> <20100405191148.GR4225@Sun.COM> <20100405192039.GA56132@shinkuro.com> In-Reply-To: <20100405192039.GA56132@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org 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, 06 Apr 2010 09:58:46 -0000 On 2010/04/06 4:20, Andrew Sullivan wrote: > I wasn't trying to suggest it was. On the other hand, all of these > complaints are the sort of thing we hear about every other technology, > too, yet I don't notice people refusing to implement stuff on the > grounds that there won't be instantaneous worldwide adoption. It's > only some protocols (the DNS is among them) where we hear that using > new features is "impossible". I think quite a bit of this may have to do with the fact that in most cases, seen from the application involved, DNS is a secondary technology. As an example, to deploy DKIM, one needs to deploy the DKIM software itself (in mail servers and possibly clients) and one needs to decide and deploy some way to put the necessary information into DNS. It means pushing up two hills, one that's familiar to the application people, and another (DNS) that's not. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From wmaton@ryouko.imsb.nrc.ca Tue Apr 6 06:01:14 2010 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 2DCEB3A67A7 for ; Tue, 6 Apr 2010 06:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 G98Tc8vYtkf8 for ; Tue, 6 Apr 2010 06:01:13 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2001:410:9000:127::10]) by core3.amsl.com (Postfix) with ESMTP id A9E3D3A6452 for ; Tue, 6 Apr 2010 06:01:09 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.3/8.14.3) with ESMTP id o36D0nG9016552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Apr 2010 09:00:54 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.3/8.14.3/Submit) with ESMTP id o36D0noF016549 for ; Tue, 6 Apr 2010 09:00:49 -0400 Date: Tue, 6 Apr 2010 09:00:49 -0400 (EDT) From: "William F. Maton Sotomayor" To: Apps-Discuss@ietf.org Subject: Re: FTP Extensions for Cryptographic Hashes (draft-bryan-ftp-hash) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="-159118721-1769907042-1269825217=:16829" Content-ID: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 13:01:14 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---159118721-1769907042-1269825217=:16829 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hi Anthony =09Nice draft. FYI, I'm semi-maintaining the venerable wu-ftpd codebase,= =20 largely for my own purposes as well as to collate the various patches I hav= e=20 come across the 'net. FYI, wu-ftpd supprts the following to do something= =20 similar (I think it's had that for ages now?) : | SITE check_login SP CHECKMETHOD SP method CRLF | SITE check_login SP CHECKMETHOD CRLF | SITE check_login SP CHECKSUM SP pathname CRLF | SITE check_login SP CHECKSUM CRLF Right now the code 'cheats' its way to doing it like this: 1) Which ones we support: reply(200, "Current checksum method: MD5 (RFC1321)"); reply(200, "Current checksum method: CRC (POSIX)"); 2) Making calls to installed programs in the paths. And of course in English: o Added 'SITE CHECKMETHOD' and 'SITE CHECKSUM'. SITE CHECKMETHOD [CRC|POSIX|MD5|RFC1321] =09Sets or displays the current check method. If no parameter is =09given, displays the current method; otherwise the method is set to =09the given algorithm. CRC and POSIX are equivalent and are the =09output of the GNU cksum(1) utility. MD5 and RFC1321 are equivalent =09and are the output of the GNU md5sum(1) utility. The default check =09method is RFC1321 (MD5). =09SITE CHECKSUM [] =09Calculates the checksum for the named file. If no file is given, =09the last file transferred (uploaded or download) is used. If no =09file has yet been transferred, reports an error. The current =09CHECKMETHOD is used to calculate the checksum. Looking at the code it seems to have been introduced sometime in 1998. FYI, more on this at my site: =09http://www.wfms.org/wu-ftpd/ I'll have a second look at your draft and see if I can offer up any more=20 comments. Thanks! On Wed, 24 Mar 2010, Anthony Bryan wrote: > Hi, >=20 > This ID proposes a feature where FTP clients can request the hash of a > file. A number of FTP clients and servers have implemented multiple > commands (XMD5, XSHA1, SITE SHOHASH, etc) that are not formally > specified, leading to non-interoperability and confusion. >=20 > We have talked to FTP application authors that are interested in this > feature. Others have previously resisted implementing this feature > because it isn't formally specified. >=20 > We already have some issues from Alfred Hoenes and John Klensin to > address. If you are interested, please review & reply. >=20 > thanks, > --=20 > (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] > )) Easier, More Reliable, Self Healing Downloads >=20 >=20 > A new version of I-D, draft-bryan-ftp-hash-00.txt has been > successfully submitted by Anthony Bryan and posted to the IETF > repository. >=20 > Filename: =A0 =A0 =A0 =A0draft-bryan-ftp-hash > Revision: =A0 =A0 =A0 =A000 > Title: =A0 =A0 =A0 =A0 =A0 FTP Extensions for Cryptographic Hashes > Creation_date: =A0 2010-03-23 > WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission > Number_of_pages: 7 >=20 > Abstract: > The specification for the File Transfer Protocol does not include > methods to obtain cryptographic hashes of files. =A0Cryptographic > hashes can be used to identify files and verify integrity. > Unfortunately, because of the desire for this feature, multiple > commands that are not formally specified have been implemented in FTP > applications leading to non-interoperability and confusion. =A0This > specification documents an optional command where FTP clients can > request the cryptographic hash of a file from a FTP server. > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > wfms ---159118721-1769907042-1269825217=:16829-- From ajs@shinkuro.com Tue Apr 6 06:48:21 2010 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 690063A68D7 for ; Tue, 6 Apr 2010 06:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.828, 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 F-oMQIBWVI4r for ; Tue, 6 Apr 2010 06:48:20 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 820E73A67E3 for ; Tue, 6 Apr 2010 06:48:20 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C50C71ECB4E8 for ; Tue, 6 Apr 2010 13:48:17 +0000 (UTC) Date: Tue, 6 Apr 2010 09:48:15 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Subject: Re: weighting transports Message-ID: <20100406134815.GC59970@shinkuro.com> References: <20100405184401.GO55035@shinkuro.com> <20100405191148.GR4225@Sun.COM> <20100405192039.GA56132@shinkuro.com> <20100405192455.GT4225@Sun.COM> <20100405213543.GA56655@shinkuro.com> <20100405214929.GF4225@Sun.COM> <20100405220701.GD56655@shinkuro.com> <20100405221241.GG4225@Sun.COM> <20100405225502.GA57008@shinkuro.com> <20100405230116.GJ4225@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100405230116.GJ4225@Sun.COM> User-Agent: Mutt/1.5.18 (2008-05-17) 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, 06 Apr 2010 13:48:21 -0000 On Mon, Apr 05, 2010 at 06:01:16PM -0500, Nicolas Williams wrote: > > But you won't get random binary data poisoning caches, because > > well-built caches will detect a malformed resource record and refuse > > to cache it. > > You should expect random binary data and not let it poison you. Of course. And a good datatype structure allows you to do early, primitive and fast checks without ever having to look at the elements of the data structure. The underscore-plus-local-rules trick means you actually have to parse part of the data before you can even check the data for syntactic correctness. > > you'll find that the DNS protocol documents and people working on it > > have commonly referred to the DNS as a distributed database, or else > > Yes, but it's so... basic. It may be basic, but it seems to me it is a leading candidate for "most successfully deployed distributed database", and I think we shouldn't take that lightly. There are _plenty_ of things to hate about the DNS, but I don't want to make those things worse by refusing to use the features it offers. > I'd agree except that if the middle-boxes-drop-SCTP problem is real (and > I believe it is, but I don't use SCTP much, so I don't know from > first-hand experience) then only probing will help you. Caching will > more than alleviate the extra probing overhead in most cases, and > servers had better be able to cope anyways. I agree with this, but I think there are really two problems we have to solve here. Part of the reason I'm advocating some pressure from applications actually to use the features already available in the DNS is because I think they help us solve a long-term problem. The short-term problem is deployment of new things (such as SCTP). For each such case, we have two options: probe or lookup. Now, because of the existing breakage, we can't rely on lookup. So we're stuck probing. The problem is that if we _only_ ever stick to probing this way, then we'll never get to the point where lookups will work. So, we'll keep adding more probes. That seems to me to be a bad long-term plan, so I think it would be nice to start using lookups where we can, in order to create a virtuous circle in which more lookups become usable as more people want to use them. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Tue Apr 6 11:00:57 2010 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 11F3C3A699E for ; Tue, 6 Apr 2010 11:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.185 X-Spam-Level: X-Spam-Status: No, score=-8.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 L+ETyNZHPV+u for ; Tue, 6 Apr 2010 11:00:56 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 944423A69AE for ; Tue, 6 Apr 2010 11:00:51 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoIALsTu0urRN+K/2dsb2JhbACHWYEUkk5xoiuZBYJqCIIXBIMk X-IronPort-AV: E=Sophos;i="4.51,373,1267401600"; d="scan'208";a="510314477" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 06 Apr 2010 18:00:49 +0000 Received: from dwingwxp01 (sjc-vpn7-888.cisco.com [10.21.147.120]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o36I0abA003017; Tue, 6 Apr 2010 18:00:42 GMT From: "Dan Wing" To: References: <4BB4ECFD.9090307@stpeter.im> <4BB61DE1.9070601@dcrocker.net> <002801cad286$6a77fee0$c6f0200a@cisco.com> <4BB638CE.1080403@bbiw.net> <00b001cad295$e6e04d20$c6f0200a@cisco.com> <4BB64F71.6080701@bbiw.net> <013701cad2a9$2b1605d0$c6f0200a@cisco.com> <4BB6772D.5030106@bbiw.net> <01cf01cad2be$df8d5080$c6f0200a@cisco.com> <4BB8D1A8.2040600@dcrocker.net> Subject: RE: weighting transports Date: Tue, 6 Apr 2010 11:00:34 -0700 Message-ID: <013c01cad5b3$155dc6d0$7893150a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcrUH30ERTLLFgLiR7W6NnuA1AudiABkpgbA In-Reply-To: <4BB8D1A8.2040600@dcrocker.net> Cc: apps-discuss@ietf.org 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, 06 Apr 2010 18:00:57 -0000 > -----Original Message----- > From: Dave CROCKER [mailto:dhc2@dcrocker.net] > Sent: Sunday, April 04, 2010 10:52 AM > To: Dan Wing > Cc: apps-discuss@ietf.org > Subject: Re: weighting transports > > Dan, > > > On 4/2/2010 4:47 PM, Dan Wing wrote: > > The IETF standardized SCTP a decade ago. We could just add > it to the list of > > 'failures'... or sit and wait and wonder why The Industry > has not adopted the > > technology. > > This is what's called a false dichotomy. It asserts only two > alternatives -- > which can be as arbitrary as these two -- and ignores all the > others that are > available. It is an expression of frustration used when > attempting to terminate > debate and prematurely force adoption of one of the > alternatives, without > consideration of the underlying issues or tradeoffs. > > I now believe the deeper question is persistent validity of > URLs, across changes > to the infrastructure. For example, should a URL become > invalid because a > different transport is used? > > The answer needs to be no. Yet the view that the URL scheme > would change when a > new transport is used will produce that unfortunate result. > > It's not that Ted's concern about the possibility of > divergent results based on > using different library packages is wrong, it's that the > proposed solution with > different URIs is clearly the wrong result. It sounds like you were reading a -01 (or later) of draft-jennings-http-srv. The later versions do propose a different URI. However, that was not what I cited. Cullen's original proposal (-00) to which Ted (and John) were commenting, did _not_ have a different URI. It uses the same URI. Cullen's draft-jennings-http-srv-00 was submitted July 5, 2008 and Ted and John's comments were on July 7. > Having an > application protocol run > over a different transport does not create a different > service; it should not > render the URI invalid. > > I've pushed back on your proposal not because I think you are > pursuing an > unattainable or unproductive goal but because its success has > too many critical > dependencies and too little compelling near-term value for adopters. > > The hard work is in reducing dependencies and increasing > perceived value. > Ignoring barriers to adoption seems to account for the failure of most > otherwise-appealing efforts. > > The idea that a URI scheme couples application protocol with > transport is really > an architectural form of source-routing. One of the > architectural wins for > Internet design has been hiding details from upper layers. > > (For that matter, "http://" has this problem for the > application layer, whereas > "mailtto://" does not. It's the difference between using > protocol names versus > service names. We need to be careful about forcing the wrong > set of changes on > existing behaviors.) > > > As of right now, I'd be interested in a review of the reason > SRV records aren't > perfect dealing with the choice between TCP and SCTP. I > thought that that was > the one of the reasons SRVs were created. Sure, that can easily added to the I-D. Big difference is that: * SRV requires a separate DNS query for each transport a client supports. * the earlier proposal to use SRV (draft-jennings-http-srv-00) for HTTP was rejected by Ted Hardie and John Klensin. -d > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net From stpeter@stpeter.im Tue Apr 6 13:29:04 2010 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 5C0803A696C; Tue, 6 Apr 2010 13:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.576, 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 9v0m2MQrbJZ6; Tue, 6 Apr 2010 13:29:03 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1EB793A6A3B; Tue, 6 Apr 2010 13:25:41 -0700 (PDT) Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 38CCD40E15; Tue, 6 Apr 2010 14:25:38 -0600 (MDT) Message-ID: <4BBB98C0.5080600@stpeter.im> Date: Tue, 06 Apr 2010 14:25:36 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: IETF discussion list Subject: new URN discussion list X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090304020208020100090602" Cc: urn-nid@ietf.org, uri@w3.org, urn@ietf.org, uri-review@ietf.org, "apps-discuss@ietf.org" 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, 06 Apr 2010 20:29:04 -0000 This is a cryptographically signed message in MIME format. --------------ms090304020208020100090602 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As a venue for discussion about possible revisions to the definition of Uniform Resource Names (URNs), the IETF Applications Area has created a new email list urn@ietf.org, to which you can subscribe as follows: https://www.ietf.org/mailman/listinfo/urn mailto:urn-request@ietf.org?body=3Dsubscribe Please note that the urn@ietf.org list is for discussion regarding the definition of URNs. We shall continue to use the urn-nid@ietf.org list for review of Namespace Identifiers (NIDs). Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090304020208020100090602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDQwNjIwMjUzNlowIwYJKoZIhvcNAQkEMRYEFOrsKSgQdcN/hRIEq50Z ayF8Ub+WMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAhvdmScRCwtIAhn6PbAmnSURWRTNnc0pBgMurrwga MULdOhko8n1mLmnL+yTWblRlKFQJK2gBUdWLKU3zMUrLEpU4jPFUcfOP/a9EX08theD86p2f vuup5Sx0LaFwLUn6hp8ZR7I3ruG7blloC9lE9+GYdX0v5d4sf8nirzju1bcDA2lkN5SZpHYZ B4KiM+4FKjHtPoOsXCUWpc7JSRrOt8DHQvFh05Px/y07131mHb+ri8bNO/ureUI7eLat3lAC Bt9GhmJ9N38WE8IzCUyPuX8O9M+uzoURSqTr72tZEhCYhN2/oMNUfe5E+eQlbC6lnXO0Qf8k YP7cNcf5+60k3wAAAAAAAA== --------------ms090304020208020100090602-- From Nicolas.Williams@sun.com Tue Apr 6 14:56:17 2010 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 7223A3A69A4 for ; Tue, 6 Apr 2010 14:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.347 X-Spam-Level: X-Spam-Status: No, score=-5.347 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_20=-0.74, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 iTIoDSgFPtJB for ; Tue, 6 Apr 2010 14:56:16 -0700 (PDT) Received: from rcsinet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by core3.amsl.com (Postfix) with ESMTP id 726FF3A699A for ; Tue, 6 Apr 2010 14:56:16 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o36Lu9Pt010493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Apr 2010 21:56:12 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o35MVd31023418; Tue, 6 Apr 2010 21:56:08 GMT Received: from abhmt019.oracle.com by acsmt353.oracle.com with ESMTP id 141186581270590909; Tue, 06 Apr 2010 14:55:09 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Apr 2010 14:55:09 -0700 Date: Tue, 6 Apr 2010 16:55:05 -0500 From: Nicolas Williams To: Andrew Sullivan Subject: Re: weighting transports Message-ID: <20100406215504.GF4225@Sun.COM> References: <20100405191148.GR4225@Sun.COM> <20100405192039.GA56132@shinkuro.com> <20100405192455.GT4225@Sun.COM> <20100405213543.GA56655@shinkuro.com> <20100405214929.GF4225@Sun.COM> <20100405220701.GD56655@shinkuro.com> <20100405221241.GG4225@Sun.COM> <20100405225502.GA57008@shinkuro.com> <20100405230116.GJ4225@Sun.COM> <20100406134815.GC59970@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100406134815.GC59970@shinkuro.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BBBADF9.0094,ss=1,fgs=0 Cc: apps-discuss@ietf.org 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, 06 Apr 2010 21:56:17 -0000 On Tue, Apr 06, 2010 at 09:48:15AM -0400, Andrew Sullivan wrote: > On Mon, Apr 05, 2010 at 06:01:16PM -0500, Nicolas Williams wrote: > > > But you won't get random binary data poisoning caches, because > > > well-built caches will detect a malformed resource record and refuse > > > to cache it. > > > > You should expect random binary data and not let it poison you. > > Of course. And a good datatype structure allows you to do early, > primitive and fast checks without ever having to look at the elements > of the data structure. The underscore-plus-local-rules trick means > you actually have to parse part of the data before you can even check > the data for syntactic correctness. Not at resolvers, and not at caching DNS servers. > > > you'll find that the DNS protocol documents and people working on it > > > have commonly referred to the DNS as a distributed database, or else > > > > Yes, but it's so... basic. > > It may be basic, but it seems to me it is a leading candidate for > "most successfully deployed distributed database", and I think we > shouldn't take that lightly. There are _plenty_ of things to hate > about the DNS, but I don't want to make those things worse by refusing > to use the features it offers. I understand that. The point is that it's too easy to edit one zone file and forget to make a corresponding edit elsewhere, or even to make two corresponding edits in the same zone file. Which is why people layer provisioning tools on top of DNS. Referential integrity matters. (15 years ago in my then sysadmin era a huge proportion of the problems I dealt with on a daily basis were referential integrity problems in name service data. DNS, NIS, even X.400 (don't ask). When we deployed UName*It all those problems went away. Note: this all happened at a different employer than my current one.) To the "when all you have is a hammer..." comment, my riposte is that one does still, from time to time, come across bonafide nails needing hammering. Layering a DB over DNS is a time-tested solution. > > I'd agree except that if the middle-boxes-drop-SCTP problem is real (and > > I believe it is, but I don't use SCTP much, so I don't know from > > first-hand experience) then only probing will help you. Caching will > > more than alleviate the extra probing overhead in most cases, and > > servers had better be able to cope anyways. > > I agree with this, but I think there are really two problems we have > to solve here. Part of the reason I'm advocating some pressure from > applications actually to use the features already available in the DNS > is because I think they help us solve a long-term problem. And I agree with that. I throuroughly dislike the most portable (in the sense of reliably being available) resolver APIs. Their biggest problems, besides being unwieldy and unnecessarily hard to use, is the lack of async, MT-safe/hot support and support for new RR types. Additionally, some RR types (e.g., SRV) deserve RR type-specific APIs. If good DNS resolver APIs existed and were widely adopted we could solve many more problems more easily. And we'd see resistance to new RR types on account of "deployment infeasibility" drop dramatically if not entirely. > The short-term problem is deployment of new things (such as SCTP). > For each such case, we have two options: probe or lookup. Now, > because of the existing breakage, we can't rely on lookup. So we're > stuck probing. Sadly, yes. On the plus side: we agree ;) > The problem is that if we _only_ ever stick to probing this way, then > we'll never get to the point where lookups will work. So, we'll keep > adding more probes. That seems to me to be a bad long-term plan, so I > think it would be nice to start using lookups where we can, in order > to create a virtuous circle in which more lookups become usable as > more people want to use them. I agree, with the caveat that even if lookups worked, if probing is faster then it could still win out. For example, if this new XPORT RR requires multiple DNS queries (one for the XPORT RR, then one for at least one, if not each name listed in it) prior to connecting, then that'd already be slower than probing (where you'd do one RR lookup + N concurrent connects). Nico -- From ajs@shinkuro.com Wed Apr 7 08:17:51 2010 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 4669C28C13A for ; Wed, 7 Apr 2010 08:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.598, 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 eAFjg23VlxTC for ; Wed, 7 Apr 2010 08:17:47 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 87A543A689F for ; Wed, 7 Apr 2010 08:15:54 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 73FC31ECB4E8 for ; Wed, 7 Apr 2010 15:15:51 +0000 (UTC) Date: Wed, 7 Apr 2010 11:15:49 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Subject: Re: weighting transports Message-ID: <20100407151549.GO485@shinkuro.com> References: <20100405192039.GA56132@shinkuro.com> <20100405192455.GT4225@Sun.COM> <20100405213543.GA56655@shinkuro.com> <20100405214929.GF4225@Sun.COM> <20100405220701.GD56655@shinkuro.com> <20100405221241.GG4225@Sun.COM> <20100405225502.GA57008@shinkuro.com> <20100405230116.GJ4225@Sun.COM> <20100406134815.GC59970@shinkuro.com> <20100406215504.GF4225@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100406215504.GF4225@Sun.COM> User-Agent: Mutt/1.5.18 (2008-05-17) 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, 07 Apr 2010 15:17:51 -0000 On Tue, Apr 06, 2010 at 04:55:05PM -0500, Nicolas Williams wrote: > And I agree with that. I throuroughly dislike the most portable (in the > sense of reliably being available) resolver APIs. Their biggest > problems, besides being unwieldy and unnecessarily hard to use, is the > lack of async, MT-safe/hot support and support for new RR types. > Additionally, some RR types (e.g., SRV) deserve RR type-specific APIs. > > If good DNS resolver APIs existed and were widely adopted we could solve > many more problems more easily. And we'd see resistance to new RR types > on account of "deployment infeasibility" drop dramatically if not > entirely. Ok, this is useful feedback. Thanks. If this or that language had such an extended API available, do you think people would start to use it instead of the supplied one? That is, suppose that there were alt-resolver libs for (say) Python, VB/.Net, or pick your favourite language (and that they were well-tested, reliable, fast, and had some evidence of being supported over the long term). What are the chances people would pick them up? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Nicolas.Williams@sun.com Wed Apr 7 08:38:17 2010 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 ED3E13A692B for ; Wed, 7 Apr 2010 08:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 ShlEN44QNe-z for ; Wed, 7 Apr 2010 08:38:17 -0700 (PDT) Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by core3.amsl.com (Postfix) with ESMTP id 0C6703A6929 for ; Wed, 7 Apr 2010 08:38:16 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o37Fc9en022711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Apr 2010 15:38:12 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3741nUv006485; Wed, 7 Apr 2010 15:38:08 GMT Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 143278311270654656; Wed, 07 Apr 2010 08:37:36 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Apr 2010 08:37:36 -0700 Date: Wed, 7 Apr 2010 10:37:31 -0500 From: Nicolas Williams To: Andrew Sullivan Subject: Re: weighting transports Message-ID: <20100407153731.GJ4225@Sun.COM> References: <20100405192455.GT4225@Sun.COM> <20100405213543.GA56655@shinkuro.com> <20100405214929.GF4225@Sun.COM> <20100405220701.GD56655@shinkuro.com> <20100405221241.GG4225@Sun.COM> <20100405225502.GA57008@shinkuro.com> <20100405230116.GJ4225@Sun.COM> <20100406134815.GC59970@shinkuro.com> <20100406215504.GF4225@Sun.COM> <20100407151549.GO485@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100407151549.GO485@shinkuro.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BBCA6E0.0158,ss=1,fgs=0 Cc: apps-discuss@ietf.org 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, 07 Apr 2010 15:38:18 -0000 On Wed, Apr 07, 2010 at 11:15:49AM -0400, Andrew Sullivan wrote: > On Tue, Apr 06, 2010 at 04:55:05PM -0500, Nicolas Williams wrote: > > And I agree with that. I throuroughly dislike the most portable (in the > > sense of reliably being available) resolver APIs. Their biggest > > problems, besides being unwieldy and unnecessarily hard to use, is the > > lack of async, MT-safe/hot support and support for new RR types. > > Additionally, some RR types (e.g., SRV) deserve RR type-specific APIs. > > Ok, this is useful feedback. Thanks. If this or that language had > such an extended API available, do you think people would start to use > it instead of the supplied one? That is, suppose that there were > alt-resolver libs for (say) Python, VB/.Net, or pick your favourite > language (and that they were well-tested, reliable, fast, and had some > evidence of being supported over the long term). What are the chances > people would pick them up? I live in the world of C. Decent resolver APIs for C are crucial because: a) C is used for much of the user-land of many an operating system, b) most high-level languages have foreign function call interfaces suitable for calling C functions, therefore you'll have the most reach with C. Async operation means using something like libevent, which is very portable (Windows, Solaris, Linux, *BSD, ...) and bundled in most operating systems nowadays. MT-safety can probably be achieved without using threading and synchronization APIs if you: a) ensure there's no shared global state, b) use async I/O for everything, c) declare that objects are accessible by one thread at a time and leave synchronization to the caller, d) open separate sockets for each instantiation of the library, e) allow multiple instantiations of the library in one process. Done that way you'll get MT-hot for free. A hint: use the libevent interfaces that take an eventbase *. I know, C is probably not what you were thinking of. But if you want to change the world, then that's where you'll start. Nico -- From dhc@dcrocker.net Wed Apr 7 09:25:29 2010 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 9664A3A6999 for ; Wed, 7 Apr 2010 09:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.861 X-Spam-Level: X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 dzXx1k2TX9tu for ; Wed, 7 Apr 2010 09:25:28 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id CA9193A6B50 for ; Wed, 7 Apr 2010 09:24:06 -0700 (PDT) Received: from [192.168.1.2] (adsl-67-127-54-167.dsl.pltn13.pacbell.net [67.127.54.167]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o37GNtcJ013256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Apr 2010 09:24:00 -0700 Message-ID: <4BBCB197.2070203@dcrocker.net> Date: Wed, 07 Apr 2010 09:23:51 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: weighting transports References: <20100405182603.GK55035@shinkuro.com> <4BBA2D22.1070700@cisco.com> <20100405184401.GO55035@shinkuro.com> <20100405191148.GR4225@Sun.COM> <20100405192039.GA56132@shinkuro.com> <20100405192455.GT4225@Sun.COM> <20100405213543.GA56655@shinkuro.com> <20100405214929.GF4225@Sun.COM> <20100405220701.GD56655@shinkuro.com> <20100405221241.GG4225@Sun.COM> <20100405225502.GA57008@shinkuro.com> <4BBA6E9B.1080707@dcrocker.net> <7E942027-337D-4112-90B8-A9E8472B7255@frobbit.se> In-Reply-To: <7E942027-337D-4112-90B8-A9E8472B7255@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.92/10712/Wed Apr 7 05:50:26 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 07 Apr 2010 09:24:01 -0700 (PDT) Cc: apps-discuss@ietf.org 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, 07 Apr 2010 16:25:29 -0000 On 4/5/2010 10:45 PM, Patrik Fältström wrote: > On 6 apr 2010, at 01.13, Dave CROCKER wrote: > >> First, the uses of TXT records at an underscore leaf are specified by >> additional documents. The fact that the core DNS engine doesn't care is >> largely the reason that the underscore convention is appealing. > > The core DNS engine do not care about new RR types, as it can handle unknown > RR Types (as compared to say 10 years ago). This is why I reacted on your > comment on "it has been hard for 20 years", as it was hard 10 years ago. It > is not hard to add new RR types now. Unfortunately, the deployed base of client resolver software needs to be counted as part of the "DNS engine", if we are going to evaluate end-to-end viability. That one or another component of the DNS works well is nice, but what is required is end-to-end behavior. Client software /does/ care about RR types. It's the reason a many/most client will handle the underscore model but not the new RR model (assuming the client will handle TXT RRs and, more recently, SRV RRs.) And as Andrew has pointed out, middleboxes also need to be counted as part of the core DNS engine, since they get in the way. >> As for being an attack vector, it is the business of the additional >> documents to explore such possibilities. > > Too easy to say. Just look at the various attacks we have regarding layering > in other protocols. Where else should the attack analysis be put, except with the specification that opens the vector? Other than that venue for the analysis, where and when should it be performed? >> If one goes wandering into underscore name space without having any idea >> what further specifications apply, well, that would be unfortunate. > > The main problems with underscores are two: > > 1. You can not have two records with the same owner and same class. You want > that sometimes, as there are RR Types that do by definition have the same > owner as already existing records. Such as the DNSSEC records. I should probably fully understand what you've said here, but I'm sorry to say I don't. First, I do not know what mean by the "owner" of a record. And I particularly do not know what you mean about having two records with the same owner and same class, in terms of affecting the choice between new RR and underscore-based enhancement. Second, the premise behind the underscore model is that it defines a leaf space that is more constrained than an arbitrary DNS leaf. If you find a TXT record underneath a DKIM node, it's for DKIM. It's not for a vcard or for SPF or for anything else. So the question is whether your "sometimes" observation applies under these administratively constrained nodes. > 2. You can have a zone cut at the periods, and in some cases you explicitly > do not want a zone cut between records. See the trouble with the NS record > sets for Microsoft AD that create quite some problems at the moment. Hmmm. I suspect your are using the word "record" differently than I understand it for the DNS. I thought it meant an RR instance. Wikipedia certainly seems to think this, too: Since zone cuts are limited to name-space boundaries, and cannot occur in the middle of a leaf node, I do not understand how the problem you are describing can occur. Beyond this, perhaps you are raising the concern that a zone cut could theoretically occur below the base domain name and the associated underscore name? While, yes, the core DNS allows that, it would be remarkably silly and counterproductive for anyone to administer their DNS that way. In other words, yes, use of underscore naming modifies the "effective" semantics of the DNS. That's a pretty scary fact, but most in-place modifications that lay new semantics on top of old semantics are scary. The reactions to the design of MIME for email were similarly distinctive. In terms of clean computer science design, layering enhancements like this can be remarkably ugly. Such is the constraint of modifying a running system. > The best path forward is to define a new RR Type, and reusing TXT is just not > good at all. Speaking of "too asy to say", I think this assertion qualifies. We still do not see the path for end-to-end viability. I'm not arguing cleanliness. I'm arguing operational viability. > Using an underscore name is of course the only selector you have IF records > have the same RR Type as SRV, so that is "sort of ok", but then the RR Type > is still structured. > > One should NOT do neither (no underscore, no special RR Type). ack. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From simon.perreault@viagenie.ca Wed Apr 7 09:36:55 2010 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 2A9D93A6ABE for ; Wed, 7 Apr 2010 09:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 E3A-DJ58VZAE for ; Wed, 7 Apr 2010 09:36:54 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id F22C03A6994 for ; Wed, 7 Apr 2010 09:36:41 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 61BBE210FD for ; Wed, 7 Apr 2010 12:36:38 -0400 (EDT) Message-ID: <4BBCB495.3050308@viagenie.ca> Date: Wed, 07 Apr 2010 12:36:37 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3 MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Re: weighting transports References: <20100405192455.GT4225@Sun.COM> <20100405213543.GA56655@shinkuro.com> <20100405214929.GF4225@Sun.COM> <20100405220701.GD56655@shinkuro.com> <20100405221241.GG4225@Sun.COM> <20100405225502.GA57008@shinkuro.com> <20100405230116.GJ4225@Sun.COM> <20100406134815.GC59970@shinkuro.com> <20100406215504.GF4225@Sun.COM> <20100407151549.GO485@shinkuro.com> <20100407153731.GJ4225@Sun.COM> In-Reply-To: <20100407153731.GJ4225@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 07 Apr 2010 16:36:55 -0000 On 2010-04-07 11:37, Nicolas Williams wrote: > I live in the world of C. Decent resolver APIs for C are crucial > because: a) C is used for much of the user-land of many an operating > system, b) most high-level languages have foreign function call > interfaces suitable for calling C functions, therefore you'll have the > most reach with C. Async operation means using something like libevent, > which is very portable (Windows, Solaris, Linux, *BSD, ...) and bundled > in most operating systems nowadays. > > MT-safety can probably be achieved without using threading and > synchronization APIs if you: a) ensure there's no shared global state, > b) use async I/O for everything, c) declare that objects are accessible > by one thread at a time and leave synchronization to the caller, d) open > separate sockets for each instantiation of the library, e) allow > multiple instantiations of the library in one process. Done that way > you'll get MT-hot for free. A hint: use the libevent interfaces that > take an eventbase *. I also have been looking for exactly this kind of library very recently. I didn't find any open-source one that would fit the bill (C, async, MT-safe, and support for new RR types), so I ended up writing my own with the minimal set of features I needed. If somebody with a clue wrote a complete one and made it available under a BSD license, the world would be a better place. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From Nicolas.Williams@sun.com Wed Apr 7 09:44:59 2010 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 D58E53A69A5 for ; Wed, 7 Apr 2010 09:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 qetyFi72JCik for ; Wed, 7 Apr 2010 09:44:59 -0700 (PDT) Received: from rcsinet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by core3.amsl.com (Postfix) with ESMTP id F1A983A67F6 for ; Wed, 7 Apr 2010 09:44:58 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o37GiipR022487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Apr 2010 16:44:45 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o371mxqK009697; Wed, 7 Apr 2010 16:44:42 GMT Received: from abhmt005.oracle.com by acsmt354.oracle.com with ESMTP id 143474331270658594; Wed, 07 Apr 2010 09:43:14 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Apr 2010 09:43:13 -0700 Date: Wed, 7 Apr 2010 11:43:08 -0500 From: Nicolas Williams To: dcrocker@bbiw.net Subject: Re: weighting transports Message-ID: <20100407164308.GR4225@Sun.COM> References: <20100405192039.GA56132@shinkuro.com> <20100405192455.GT4225@Sun.COM> <20100405213543.GA56655@shinkuro.com> <20100405214929.GF4225@Sun.COM> <20100405220701.GD56655@shinkuro.com> <20100405221241.GG4225@Sun.COM> <20100405225502.GA57008@shinkuro.com> <4BBA6E9B.1080707@dcrocker.net> <7E942027-337D-4112-90B8-A9E8472B7255@frobbit.se> <4BBCB197.2070203@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBCB197.2070203@dcrocker.net> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BBCB67B.0098,ss=1,fgs=0 Cc: apps-discuss@ietf.org 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, 07 Apr 2010 16:44:59 -0000 On Wed, Apr 07, 2010 at 09:23:51AM -0700, Dave CROCKER wrote: > Unfortunately, the deployed base of client resolver software needs > to be counted as part of the "DNS engine", if we are going to > evaluate end-to-end viability. That one or another component of the > DNS works well is nice, but what is required is end-to-end behavior. > > Client software /does/ care about RR types. It's the reason a > many/most client will handle the underscore model but not the new RR > model (assuming the client will handle TXT RRs and, more recently, > SRV RRs.) +1 > And as Andrew has pointed out, middleboxes also need to be counted > as part of the core DNS engine, since they get in the way. I worry less about middle boxes than about end node resolver functionality. Yes, broken middle boxes will mean that probing will continue to be necessary: end node resolvers can workaround broken middle boxes, yes, but they shouldn't want to, and discovering the presence of broken middle boxes may require a timeout, which is Bad News for user-facing apps. But pressure to fix broken middle boxes won't materialize until until end node resolver support for new RR types does. Resolver support has to come first. (There's relatively few DNS middle boxes from any one point on the Internet, and many are run by providers that have business relationships with their users or other incentives to keep them happy. Broken middle boxes are one killer app from being fixed, but the killer app will have to come first.) > >One should NOT do neither (no underscore, no special RR Type). > > ack. Well, if probing is deployed and works then we may well do neither. I see no need to do more than what works. (Yes, what works may seem architecturally impure, but when you consider broken IP middle boxes, architectural purity goes out the window.) Nico -- From Nicolas.Williams@sun.com Wed Apr 7 10:10:00 2010 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 19B4A3A6979 for ; Wed, 7 Apr 2010 10:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.319 X-Spam-Level: X-Spam-Status: No, score=-5.319 tagged_above=-999 required=5 tests=[AWL=-1.135, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 5gUrkusI5hip for ; Wed, 7 Apr 2010 10:09:59 -0700 (PDT) Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by core3.amsl.com (Postfix) with ESMTP id 252323A6811 for ; Wed, 7 Apr 2010 10:09:56 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o37H7Nnq008963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Apr 2010 17:09:45 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o36HFL8E008968; Wed, 7 Apr 2010 16:50:59 GMT Received: from abhmt012.oracle.com by acsmt355.oracle.com with ESMTP id 143490761270659005; Wed, 07 Apr 2010 09:50:05 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Apr 2010 09:50:05 -0700 Date: Wed, 7 Apr 2010 11:50:00 -0500 From: Nicolas Williams To: Simon Perreault Subject: Re: weighting transports Message-ID: <20100407165000.GS4225@Sun.COM> References: <20100405214929.GF4225@Sun.COM> <20100405220701.GD56655@shinkuro.com> <20100405221241.GG4225@Sun.COM> <20100405225502.GA57008@shinkuro.com> <20100405230116.GJ4225@Sun.COM> <20100406134815.GC59970@shinkuro.com> <20100406215504.GF4225@Sun.COM> <20100407151549.GO485@shinkuro.com> <20100407153731.GJ4225@Sun.COM> <4BBCB495.3050308@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBCB495.3050308@viagenie.ca> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BBCB7F4.00BB,ss=1,fgs=0 Cc: apps-discuss@ietf.org 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, 07 Apr 2010 17:10:00 -0000 On Wed, Apr 07, 2010 at 12:36:37PM -0400, Simon Perreault wrote: > If somebody with a clue wrote a complete one and made it available > under a BSD license, the world would be a better place. Some intellectual property is best protected, some is best given away. If the DNS had been patented back in 1986, and licensed illiberally and not freely (as in $0), then we'd still have been copying hosts files until fairly recently. Some technology is useless unless everyone adopts it, while some technology gives one an edge especially when not everyone has adopted it. DNS _resolver_ technology, IMO, falls into the "best given away freely" bucket. But someone has to fund such work, and must consider the cost of opportunity. This is why we're stuck with ancient resolver technology that's widely deployed even though much better resolvers with much narrower applicability (because not written in C for C and non-C apps, or because not liberally licensed) may be available. It's not hard to predict that this state of affairs will continue indefinitely. When people say that "it's very hard to get new RR types widely deployed" what they mean is something like the above (plus broken middle box problems). Nico -- From Joe.Hildebrand@webex.com Wed Apr 7 10:14:25 2010 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 C15CE3A6868 for ; Wed, 7 Apr 2010 10:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.2 X-Spam-Level: X-Spam-Status: No, score=-103.2 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, 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 BZRYcarN6PFN for ; Wed, 7 Apr 2010 10:14:23 -0700 (PDT) Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by core3.amsl.com (Postfix) with SMTP id 34CA63A697C for ; Wed, 7 Apr 2010 10:14:09 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Apr 2010 10:14:06 -0700 Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Wed, 7 Apr 2010 17:13:20 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 07 Apr 2010 11:13:19 -0600 Subject: Re: weighting transports From: Joe Hildebrand To: Nicolas Williams , Simon Perreault Message-ID: Thread-Topic: weighting transports Thread-Index: AcrWdSohnSxp+lnsTsGAq48QAOe3HwAAHQ83 In-Reply-To: <20100407165000.GS4225@Sun.COM> IM-ID: xmpp:jhildebr@cisco.com Presence-ID: xmpp:jhildebr@cisco.com Jabber-ID: jhildebr@cisco.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Apr 2010 17:14:06.0288 (UTC) FILETIME=[BA8E3500:01CAD675] Cc: apps-discuss@ietf.org 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, 07 Apr 2010 17:14:26 -0000 Simon, would you be interested in just putting your code up on github with a BSD or MIT license, and telling anyone who complains that they should just contribute? Sometimes a starting point is all that's needed. On 4/7/10 10:50 AM, "Nicolas Williams" wrote: > On Wed, Apr 07, 2010 at 12:36:37PM -0400, Simon Perreault wrote: >> If somebody with a clue wrote a complete one and made it available >> under a BSD license, the world would be a better place. > > Some intellectual property is best protected, some is best given away. > If the DNS had been patented back in 1986, and licensed illiberally and > not freely (as in $0), then we'd still have been copying hosts files > until fairly recently. Some technology is useless unless everyone > adopts it, while some technology gives one an edge especially when not > everyone has adopted it. > > DNS _resolver_ technology, IMO, falls into the "best given away freely" > bucket. But someone has to fund such work, and must consider the cost > of opportunity. This is why we're stuck with ancient resolver > technology that's widely deployed even though much better resolvers with > much narrower applicability (because not written in C for C and non-C > apps, or because not liberally licensed) may be available. > > It's not hard to predict that this state of affairs will continue > indefinitely. > > When people say that "it's very hard to get new RR types widely > deployed" what they mean is something like the above (plus broken middle > box problems). > > Nico > -- > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Joe Hildebrand From julian.reschke@gmx.de Thu Apr 8 07:58:37 2010 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 E371C3A6855 for ; Thu, 8 Apr 2010 07:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.374 X-Spam-Level: X-Spam-Status: No, score=-5.374 tagged_above=-999 required=5 tests=[AWL=-2.775, 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 Vq0fB1ETFIVM for ; Thu, 8 Apr 2010 07:58:37 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CCC393A67A6 for ; Thu, 8 Apr 2010 07:58:36 -0700 (PDT) Received: (qmail invoked by alias); 08 Apr 2010 14:58:31 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.119]) [217.91.35.233] by mail.gmx.net (mp056) with SMTP; 08 Apr 2010 16:58:31 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18ekhQYIhce7hSlyjTY3oASfVqoaLk19lK+8SwV2y jK6Gm9EWM5DuuS Message-ID: <4BBDEF11.6020008@gmx.de> Date: Thu, 08 Apr 2010 16:58:25 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: IETF Apps Discuss Subject: draft-abarth-mime-sniff, confused by Section 1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 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, 08 Apr 2010 14:58:38 -0000 Hi, has: However, if a user agent does interpret a low-privilege media type, such as image/gif, as a high-privilege media type, such as text/html, the user agent has created a privilege escalation vulnerability in the server. "in the server"? How does this affect the server? Best regards, Julian From eran@hueniverse.com Fri Apr 9 21:45:54 2010 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 E465F3A69B4 for ; Fri, 9 Apr 2010 21:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 OOPRbsbGcqsI for ; Fri, 9 Apr 2010 21:45:54 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id B7A7E3A6AC7 for ; Fri, 9 Apr 2010 21:45:53 -0700 (PDT) Received: (qmail 4309 invoked from network); 10 Apr 2010 04:45:48 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Apr 2010 04:45:48 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 9 Apr 2010 21:45:49 -0700 From: Eran Hammer-Lahav To: Chuck Mortimore , OAuth WG Date: Fri, 9 Apr 2010 21:45:46 -0700 Subject: Re: [OAUTH-WG] Native applications capable of handling callbacks Thread-Topic: [OAUTH-WG] Native applications capable of handling callbacks Thread-Index: AcrYIt9HqbEa8GrhW0eQRvN1PulFkwARc/du Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" 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, 10 Apr 2010 04:45:55 -0000 (+apps-discuss as this is of general interest to the area) On 4/9/10 1:26 PM, "Chuck Mortimore" wrote: > A number of the modern application platforms (Android, iPhone, iPad) have > support for registering custom url schemes for native applications. Th= is > allows them to receive callbacks from web browsers, without resorting to = copy > paste, or window title polling. For instance, the authorization server= may > redirect the devices browser to: >=20 > HTTP/1.1 302 Found > Location: myapp://oauth_callback?code=3Di1WsRn1uB1 >=20 > This results in the application launching and the URL being passed to it= =B9s > callback handler. >=20 > There are a few issues I see with handling these in current form: >=20 > * The Web Callback flow is not appropriate, as the client secret cannot b= e > secured=20 > * The Native Application flow best describes these types of clients, but > doesn=B9t handle the flow > * The User Agent flow would likely work, but the description would lead > implementers away from this, and I=B9d be concerned that the implementati= ons may > gravitate towards handling cross domain javascript tunneling >=20 > I believe all of the pieces are here to support this, but I=B9d be intere= sted in > seeing stronger guidance for implementers on how to handle these clients. >=20 > - cmort The first problem with including this approach in an IETF specification is that it indirectly violates IETF standards, namely the rules governing how new URI schemes should be discussed, approved, and registered. This is also of interest to the W3C TAG. The way this should probably be done is by registering a new URN scheme lik= e app which will look something like: app:application_name:comma_delimited_parameters With application_name either a domain-name-namespaced value (e.g. app:microsoft.com:excel:parameters) or registry based. But without such a mechanism (feel free to offer other ideas), to suggest i= n an IETF standard that developers should go and make up random URI schemes for their clients is both bad policy and not likely to pass Last Call. If this group has the appetite for such a feature, I would be happy to draf= t a very short proposal for such a new URN scheme, which we can then publish separately or include in the OAuth spec. In practice, until companies like Apple and Microsoft (the two leading OS vendors), and Google (with Android) support such a generic application URN, people will continue to do so. But if we propose a standard path, we can then mention the "abusive" practice and declare it deprecated, pointing people to the right way of doing it. That will help in getting adoption lon= g term. Thoughts? EHL From tim.kosse@filezilla-project.org Sat Apr 10 12:08:19 2010 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 732303A6845 for ; Sat, 10 Apr 2010 12:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 DyT3v2BAyuRO for ; Sat, 10 Apr 2010 12:08:18 -0700 (PDT) Received: from filezilla-project.org (cl-1464.dus-01.de.sixxs.net [IPv6:2a01:198:200:5b7::2]) by core3.amsl.com (Postfix) with ESMTP id E43CA3A67F3 for ; Sat, 10 Apr 2010 12:08:17 -0700 (PDT) Received: from [2a01:198:458::59] by filezilla-project.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1O0g2M-0006Rb-8H; Sat, 10 Apr 2010 21:08:10 +0200 Message-ID: <4BC0CC95.6010304@filezilla-project.org> Date: Sat, 10 Apr 2010 21:08:05 +0200 From: Tim Kosse User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Daniel Stenberg Subject: Re: draft-bryan-ftp-hash-00 -- items for discussion References: <201003231642.RAA04676@TR-Sys.de> <201004011954.VAA28916@TR-Sys.de> <4BBA597C.8070307@filezilla-project.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0D4B648FDCFD2ECB9BA9B3E6" Cc: apps-discuss@ietf.org 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, 10 Apr 2010 19:08:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0D4B648FDCFD2ECB9BA9B3E6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2010-04-06 10:15, Daniel Stenberg wrote: > Perhaps it will make sense to allow the server to deny answering to > partial hashes? Yes, that should be allowed if there is support for partial hashes. > Or even include the range in the response so that the > client can see what data range the checksum is for. Seems redundant to me, if a client would query a specific range, it already knows that range. > It wouldn't be > completely strange to me to use the REST position as start position for= > the hash calculation. This would probably limit us to MODE S as the semantics of REST are somewhat more complex in the other modes. Also, have a look at how REST is defined in RFC 3659. In particular: > The REST command must be the last command issued before the data > transfer command that is to cause a restarted, rather than a > complete, file transfer. The effect of issuing a REST command at an= y > other time is undefined. [...] > Because of this, a user-PI that has issued a REST command, but that > has not successfully transmitted the following data transfer command= > for any reason, should send another REST command before the next dat= a > transfer command. If that transfer is not to be restarted, then > "REST 0" should be issued. We would have to extend the semantics of REST in this case. Note that many clients send the REST command as keep-alive command. As such changing REST may have unintended side effects with such clients. Tim --------------enig0D4B648FDCFD2ECB9BA9B3E6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvAzJUACgkQ8N9+lcqiUkVUhwCeNr+OePoVIjyg/NUQdGtiY4w6 qT0AoN+7EZpc+iLV9o6xk46KJGKEM0ei =GMSs -----END PGP SIGNATURE----- --------------enig0D4B648FDCFD2ECB9BA9B3E6-- From daniel@haxx.se Sat Apr 10 14:02:44 2010 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 9659D3A67A3 for ; Sat, 10 Apr 2010 14:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=0.745, 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 C8b5MQETCCV2 for ; Sat, 10 Apr 2010 14:02:42 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by core3.amsl.com (Postfix) with ESMTP id 30F963A677D for ; Sat, 10 Apr 2010 14:02:41 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with ESMTP id o3AL2LDg019903; Sat, 10 Apr 2010 23:02:21 +0200 Date: Sat, 10 Apr 2010 23:02:21 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Tim Kosse Subject: Re: draft-bryan-ftp-hash-00 -- items for discussion In-Reply-To: <4BC0CC95.6010304@filezilla-project.org> Message-ID: References: <201003231642.RAA04676@TR-Sys.de> <201004011954.VAA28916@TR-Sys.de> <4BBA597C.8070307@filezilla-project.org> <4BC0CC95.6010304@filezilla-project.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: apps-discuss@ietf.org 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, 10 Apr 2010 21:02:44 -0000 On Sat, 10 Apr 2010, Tim Kosse wrote: >> It wouldn't be completely strange to me to use the REST position as start >> position for the hash calculation. > > This would probably limit us to MODE S as the semantics of REST are somewhat > more complex in the other modes. > > Also, have a look at how REST is defined in RFC 3659. In particular: Oh, obviously I hadn't done my home work and retract that idea. I think all those additional details make REST a bad choice to (ab)use for partial hashes. Thanks! -- / daniel.haxx.se From ietf@adambarth.com Sun Apr 11 21:09:55 2010 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 14BD83A67A4 for ; Sun, 11 Apr 2010 21:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=1.269, 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 D2-WdeDBXtHR for ; Sun, 11 Apr 2010 21:09:54 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 3A9663A6781 for ; Sun, 11 Apr 2010 21:09:54 -0700 (PDT) Received: by qyk11 with SMTP id 11so4469912qyk.13 for ; Sun, 11 Apr 2010 21:09:46 -0700 (PDT) Received: by 10.229.192.7 with SMTP id do7mr2650170qcb.71.1271045385878; Sun, 11 Apr 2010 21:09:45 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by mx.google.com with ESMTPS id v37sm5578288qce.18.2010.04.11.21.09.44 (version=SSLv3 cipher=RC4-MD5); Sun, 11 Apr 2010 21:09:44 -0700 (PDT) Received: by ywh38 with SMTP id 38so2631877ywh.29 for ; Sun, 11 Apr 2010 21:09:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.177.225 with HTTP; Sun, 11 Apr 2010 21:09:24 -0700 (PDT) In-Reply-To: <4BBDEF11.6020008@gmx.de> References: <4BBDEF11.6020008@gmx.de> From: Adam Barth Date: Sun, 11 Apr 2010 21:09:24 -0700 Received: by 10.150.187.8 with SMTP id k8mr3144396ybf.219.1271045384196; Sun, 11 Apr 2010 21:09:44 -0700 (PDT) Message-ID: Subject: Re: draft-abarth-mime-sniff, confused by Section 1 To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss 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, 12 Apr 2010 04:09:55 -0000 On Thu, Apr 8, 2010 at 7:58 AM, Julian Reschke wrot= e: > has: > > =A0 However, if a user agent does interpret a low-privilege media type, > =A0 such as image/gif, as a high-privilege media type, such as text/html, > =A0 the user agent has created a privilege escalation vulnerability in > =A0 the server. > > "in the server"? How does this affect the server? Because the user agent has misinterpreted what the server said. On the web, servers need to be careful what they say because the same origin policy imbues their words (HTTP responses) with their authority. If a user agent misinterprets an image as HTML, the server will become vulnerable to cross-site scripting. Adam From anthonybryan@gmail.com Sun Apr 11 21:59:52 2010 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 7E4553A68E9 for ; Sun, 11 Apr 2010 21:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 cztjWLB4wKlO for ; Sun, 11 Apr 2010 21:59:51 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 691B63A68E4 for ; Sun, 11 Apr 2010 21:59:51 -0700 (PDT) Received: by iwn27 with SMTP id 27so4376781iwn.5 for ; Sun, 11 Apr 2010 21:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YNjlNkt0REwLo468UVulrzTCgcrQvc8LBoc20PTMM/k=; b=WUrTvmhusudKk2HFUNAL6yjhkELd0xj73r8x2zohk5CN97IEuo0cNkufJSPTZprDdf JZ9B8uCuMIC13UUoA0wIqEDU8Moc6SU+bS2CTZi5g7weEsd+fKawr+fCkM2GhQ2vro8z DpZauHBhlpGe4QngtBSPL2kWrVD3njYnAO2es= 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=neF19aVSfHdAx4p0VRIEk4a1WBbTYu8Yf7QEL/N7Zl097S/TXub0Y72oAIm1kiE2o6 6F6U1fS8+MPdqo0HrbUpmW6W7ff/VqrMkXz0eKsWtWXN8VmNbZN1PeKlewPSe1mY4ta3 ipPQZ80jZXjxIH1bGnw0PucjNt+mlt2iE5Wu0= MIME-Version: 1.0 Received: by 10.231.171.13 with HTTP; Sun, 11 Apr 2010 21:59:42 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Apr 2010 00:59:42 -0400 Received: by 10.231.152.75 with SMTP id f11mr1644960ibw.50.1271048382363; Sun, 11 Apr 2010 21:59:42 -0700 (PDT) Message-ID: Subject: Re: FTP Extensions for Cryptographic Hashes (draft-bryan-ftp-hash) From: Anthony Bryan To: wmaton@ryouko.imsb.nrc.ca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps-Discuss@ietf.org 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, 12 Apr 2010 04:59:52 -0000 On Tue, Apr 6, 2010 at 9:00 AM, William F. Maton Sotomayor wrote: > > Hi Anthony > > =A0 =A0 =A0 =A0Nice draft. =A0FYI, I'm semi-maintaining the venerable wu-= ftpd > codebase, largely for my own purposes as well as to collate the various > patches I have come across the 'net. =A0FYI, wu-ftpd supprts the followin= g to > do something similar (I think it's had that for ages now?) : > > =A0 =A0| SITE check_login SP CHECKMETHOD SP method CRLF > =A0 =A0| SITE check_login SP CHECKMETHOD CRLF > =A0 =A0| SITE check_login SP CHECKSUM SP pathname CRLF > =A0 =A0| SITE check_login SP CHECKSUM CRLF > > Right now the code 'cheats' its way to doing it like this: > > 1) Which ones we support: > > =A0 =A0 =A0 =A0reply(200, "Current checksum method: MD5 (RFC1321)"); > =A0 =A0 =A0 =A0reply(200, "Current checksum method: CRC (POSIX)"); > > 2) Making calls to installed programs in the paths. > > And of course in English: > > o =A0Added 'SITE CHECKMETHOD' and 'SITE CHECKSUM'. > > =A0 =A0 =A0 =A0SITE CHECKMETHOD [CRC|POSIX|MD5|RFC1321] > > =A0 =A0 =A0 =A0Sets or displays the current check method. =A0If no parame= ter is > =A0 =A0 =A0 =A0given, displays the current method; otherwise the method i= s set to > =A0 =A0 =A0 =A0the given algorithm. =A0CRC and POSIX are equivalent and a= re the > =A0 =A0 =A0 =A0output of the GNU cksum(1) utility. =A0MD5 and RFC1321 are= equivalent > =A0 =A0 =A0 =A0and are the output of the GNU md5sum(1) utility. =A0The de= fault check > =A0 =A0 =A0 =A0method is RFC1321 (MD5). > > =A0 =A0 =A0 =A0SITE CHECKSUM [] > > =A0 =A0 =A0 =A0Calculates the checksum for the named file. =A0If no file = is given, > =A0 =A0 =A0 =A0the last file transferred (uploaded or download) is used. = =A0If no > =A0 =A0 =A0 =A0file has yet been transferred, reports an error. =A0The cu= rrent > =A0 =A0 =A0 =A0CHECKMETHOD is used to calculate the checksum. > > Looking at the code it seems to have been introduced sometime in 1998. > > FYI, more on this at my site: > > =A0 =A0 =A0 =A0http://www.wfms.org/wu-ftpd/ > > I'll have a second look at your draft and see if I can offer up any more > comments. =A0Thanks! Hi William, great to hear from someone familiar with current implementations! (I added wuftpd to the appendix listing apps supporting alternate hash commands). We've put out an -01 revision, and you can see diffs here. tools.ietf.org/html/draft-bryan-ftp-hash If you have any more comments, please let us know. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From julian.reschke@gmx.de Mon Apr 12 06:57:02 2010 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 F13333A67E3 for ; Mon, 12 Apr 2010 06:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.928 X-Spam-Level: X-Spam-Status: No, score=-3.928 tagged_above=-999 required=5 tests=[AWL=-2.818, BAYES_05=-1.11] 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 wykCaSIMnjSP for ; Mon, 12 Apr 2010 06:57:02 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C436C3A67D9 for ; Mon, 12 Apr 2010 06:57:01 -0700 (PDT) Received: (qmail invoked by alias); 12 Apr 2010 13:56:55 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.116]) [217.91.35.233] by mail.gmx.net (mp054) with SMTP; 12 Apr 2010 15:56:55 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/sV49A8h/s55PQxChXKiR66HKk+0ZUV33nuyPaT4 vUy4ZAdbj9lUdC Message-ID: <4BC326A6.1050601@gmx.de> Date: Mon, 12 Apr 2010 15:56:54 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Adam Barth Subject: Re: draft-abarth-mime-sniff, confused by Section 1 References: <4BBDEF11.6020008@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57999999999999996 Cc: IETF Apps Discuss 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, 12 Apr 2010 13:57:03 -0000 On 12.04.2010 06:09, Adam Barth wrote: > On Thu, Apr 8, 2010 at 7:58 AM, Julian Reschke wrote: >> has: >> >> However, if a user agent does interpret a low-privilege media type, >> such as image/gif, as a high-privilege media type, such as text/html, >> the user agent has created a privilege escalation vulnerability in >> the server. >> >> "in the server"? How does this affect the server? > > Because the user agent has misinterpreted what the server said. On > the web, servers need to be careful what they say because the same > origin policy imbues their words (HTTP responses) with their > authority. If a user agent misinterprets an image as HTML, the server > will become vulnerable to cross-site scripting. I see what you mean, but I still think is misleading. A server that relies on UAs implementing the same-origin policy will be vulnerable anyway. So the vulnerability is already there, it just becomes easier to exploit (compared, for instance, to attack the server using specially crafted scripts doing the HTTP request). Best regards, Julian From eran@hueniverse.com Tue Apr 13 09:24:57 2010 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 23B233A686D for ; Tue, 13 Apr 2010 09:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.153 X-Spam-Level: X-Spam-Status: No, score=-1.153 tagged_above=-999 required=5 tests=[AWL=-1.154, BAYES_50=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 m5KzZEwpsVBM for ; Tue, 13 Apr 2010 09:24:55 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 6790D3A6801 for ; Tue, 13 Apr 2010 09:24:55 -0700 (PDT) Received: (qmail 27322 invoked from network); 13 Apr 2010 16:24:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Apr 2010 16:24:46 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 13 Apr 2010 09:24:15 -0700 From: Eran Hammer-Lahav To: John Panzer Date: Tue, 13 Apr 2010 09:24:12 -0700 Subject: Re: Query on discovery algoritm for LRDD (draft-hammer-discovery-04) Thread-Topic: Query on discovery algoritm for LRDD (draft-hammer-discovery-04) Thread-Index: AcrU/Ft2ku5wWsAYQvePduVl+9sMTgGKWTVT Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" , "salmon-protocol@googlegroups.com" 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, 13 Apr 2010 16:24:57 -0000 On 4/5/10 1:12 PM, "John Panzer" wrote: > On Sat, Mar 27, 2010 at 2:41 PM, Eran Hammer-Lahav > wrote: >>=20 >>=20 >>> -----Original Message----- >>> From: John Panzer [mailto:jpanzer@google.com] >>> Sent: Friday, March 26, 2010 10:08 AM >>=20 >>> This is my attempt to translate >>> http://tools.ietf.org/html/draft-hammer-discovery-04 into an actionable >>> algorithm, as a first step in attempting to write a truly general resou= rce >>> discovery library that matches the latest spec. >>> It is written under the assumption that a client may wish to query for = sets >>> of >>> links with a given relvalue, and is not going to wish to retrieve and >>> re-parse >>> host-meta files any more often than necessary. =A0Feedback welcomed! >>>=20 >>> Definitions >>>=20 >>> startURI: Starting point for discovery; input into the discovery proces= s. >>> Discovery produces metadata for startURI. >>>=20 >>> metadata: A collection of links and properties for the resource. >>>=20 >>> link: An abstract edge between the startURI resource and another resour= ce >>> identified by a field href. =A0Has a rel field indicating the relations= hip >>> from >>> startURI to href. Has a lrdd_pri field indicating ordering within the r= el >>> value. >>> Has a secure boolean field indicating whether it was retrieved securely= . >>> =A0Can >>> be annotated with arbitrary properties. >>>=20 >>> property: A piece of metadata about a resource less structured than a l= ink. >>> Only present for XRD-derived data. =A0Has a secure boolean field indica= ting >>> whether it was retrieved securely. >>=20 >> Link headers and elements can include extension parameters that are eith= er >> rel-specific or document specific. These will be in the form of key/valu= e >> pairs but in which the key is a short name, not a URI (like XRD >> type). In markup the can have a namespace. >>=20 >> I generally prefer people used the XRD facility instead of >> extending the link schema (for header format). >>=20 >>> Algorithm >>>=20 >>> Determine priority order (Host-priority or Resource-priority): >>>=20 >>> lookup HostMetaLRDD(startURI) >>=20 >> What does this do in this context? Your Function below is aimed for gett= ing >> metadata, not just raw host-meta. >=20 > In this context, this should be something like RawHostMeta(). > =A0 >>=20 >>> if above lookup fails because Host(startURI) is not available, priority= =3D >>> Resource Else, does result contain >>> XRD/Property@type=3Dhttp://lrdd.net/priority/resource? =A0If yes, then = priority >>> =3D Resource. =A0Otherwise, priority =3D Host >>>=20 >>> If priority =3D Host: >>> =A0 // priority order is host-meta, HTTP Link, elements >>> =A0 metadata =3D lookup HostMetaLRDD(startURI, 1) >>> =A0 augment metadata with result of lookup HeaderLinks(startURI, 2) >>> =A0 augment metadata with lookup ResourceLinks(startURI, 3) >>>=20 >>> If priority =3D Resource: >>> =A0 // priority order is elements, HTTP Link, host-meta >>> =A0 metadata =3D lookup ResourceLinks(startURI, 1) >>> =A0 augment metadata with result of lookup HeaderLinks(startURI, 2) >>> =A0 augment metadata with lookup HostMetaLRDD(startURI, 3) >>>=20 >>> where >>>=20 >>> HostMetaLRDD(uri, pri) is: >>> =A0 Revalidate local XRD data cache for hostof(uri)/.well-known/host-me= ta. >>=20 >> How do you handle http vs https? >=20 > What is the default ordering in which to try? =A0I'd much prefer to make > https:// the default scheme for the "hostof(x)" above, failing back to ht= tp:// > with a flag indicating content was not verified by a certificate. Given recent discussions I'm inclined to change the draft to "SHOULD try https:// first, then http:// second". > NB: =A0In starting to write code for all this, I'm finding it useful to u= se > nonstandard ids like foo@localhost:8080 in order to preserve my sanity. = =A0This > means "pretend you're foo@localhost, and use 8080 as the default HTTP por= t for > host-meta discovery, and switch off security checks too". =A0In particula= r I end > up having to swap around between foo@localhost:8080, foo@localhost:8081, > foo@localhost:8082,... dynamically quite a bit to simulate cross-domain c= alls, > so a static configuration would be quite annoying/unusable. =A0Fortunatel= y most > of the stack I'm using doesn't care about this, but the port needs to be > passed down a few levels and get through some regexps. =A0Not sure how be= st to > do this for real without compromising security -- perhaps allow this only= for > "localhost"... > =A0 >> Follow redirections. >=20 > ...while ensuring that one's security flag gets reset to 0 if any redirec= ts > pass through http... > =A0 >> Validate host-meta is valid for the desired host. >=20 > What's the procedure here? =A0Just match Subject and Alias against the ho= st? Match the URI of the resource being discovered to the element of the host-meta file. >>=20 >>> =A0 Find the first link with rel=3D"lrdd" in host-meta document (call >>> =A0 =A0 the href value lrdd_url) >>=20 >> Apply template... >=20 > Ah right, you don't have an href until you apply(template, uri) --> href. > =A0 >>=20 >>> =A0 Revalidate local XRD data cache for lrdd_url,annotating each link >>> =A0 =A0 with lrdd_pri=3Dpri >>> =A0 Return metadata (non-lrdd links and properties) for lrdd_uri >>>=20 >>>=20 >>> HeaderLinks(uri, pri) is: >>> =A0 If uri is not dereferenceable (e.g., acct:) return empty set >>=20 >> If you URI is not http/https, or if a GET/HEAD returns a response that d= oes >> not contains a representation for the requested resource. See: >> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-09#section-6.= 1 >>=20 >=20 > What if it returns a 403 Forbidden? =A0Or a 5xx Temporary Server error? = =A0Or just > times out? Then you don't use Link headers for LRDD. The next draft will make this clear. Basically, if the Link is not about what you asked for, don't use it= . A Link in a 403 response is between an anonymous resource and a target. > =A0 >>> =A0 Revalidate local resource link cache for uri >>> =A0 Retrieve Link: headers for resource from cache, annotating >>> =A0 =A0 each link with lrdd_pri=3Dpri >>> =A0 Return links to caller >>>=20 >>> ResourceLinks(uri, pri) is: >>> =A0 If uri is not dereferenceable (e.g., acct:) return empty set >>> =A0 Revalidate local resource link cache for uri >>> =A0 Retrieve MIME-type-specific set of links known for resource, annota= ting >>> each >>> =A0 =A0 link with lrdd_pri=3Dpri >>> =A0 Return links to caller >>>=20 >>>=20 >>> augment X with Y with priority pri is: >>> =A0 For each set of links y in Y sharing link relation r: >>> =A0 =A0 if r=3D=3D"lrdd", and X does not already >>> =A0 =A0 =A0 contain a link with rel=3D"lrdd": >>> =A0 =A0 =A0 augment X with results of: >>> =A0 =A0 =A0 =A0 Revalidate local XRD data cache for first href for rel= =3D"lrdd", >>> =A0 =A0 =A0 =A0 =A0 annotating each link with lrdd_pri=3Dpri >>> =A0 =A0 =A0 =A0 Augment X with resulting metadata from href >>> =A0 =A0 else, >>> =A0 =A0 =A0 add list of links y to X. >>> =A0 =A0 =A0 Add all properties in Y to X. >>>=20 >>>=20 >>> NB: Some link types can contain space-separated rel values, which are >>> interpreted as a series of links with each of the space-separated rel v= alue >>> names in the above algorithm. >>>=20 >>> NB: Ordering of links and properties from each source with the same rel= /type >>> values is retained throughout, with the caveat that HTTP headers do not >>> have a guaranteed stable order. >>>=20 >>> Security is not shown here, but is based on either TLS used throughout = the >>> retrievals or (for XRD) the XRD signature specification. =A0Content typ= e >>> specific >>> security may also be used to verify links within content (e.g., Magic >>> Signatures over link elements). =A0When set, the secure boolean indicat= es that >>> a specific link or property was retrieved securely; when not set, it >>> indicates >>> that the retrieval path contained one or more insecure steps. =A0The al= gorithm >>> will also reject data that is red-flagged (e.g., if a CRL check shows t= hat a >>> certificate has been revoked as opposed to merely expiring). =A0(?) >>>=20 >>> Result: >>>=20 >>> An ordered collection of metadata, consisting of links and properties, = each >>> of >>> which is annotated with its lrdd_pri in case it matters. =A0There is at= most >>> one >>> rel=3D"lrdd" link in the collection which identifies the specific LRDD >>> document >>> used, if any, and any metadata from that lrdd document is transcluded i= nto >>> the metadata collection. >>=20 >> There can be more than one LRDD document, but only one is used from each >> source. There should not be any rel=3D'lrdd' in the collection because i= t is >> either expanded or dropped (not first). >=20 > This algorithm was just tracking the address of the one that was expanded= (not > 100% necessary but useful for debuggability). >=20 > I think that "Any "lrdd" links other than the first MUST be ignored." in > section 3, step 2, is confusing: =A0I had interpreted "first" as the firs= t one > encountered globally, but your note implies that you can have up to 3 LRD= D > documents to peek inside (one from each source). >=20 > I'm not sure that the limitation of one LRDD link per source helps anythi= ng in > the algorithm in this case. I tend to agree. The extra code to iterate through multiple LRDD links in a single source is minimal. But it does add complexity and can slow down the client if the server goes nuts breaking its metadata over multiple LRDD documents. >>=20 >>> A client which wishes to coalesce links and properties found in all thr= ee >>> places within a given rel or type value can just query the collection f= or >>> the >>> desired rel or type and retrieve collections of links or properties. >>>=20 >>> Once retrieved, the set of metadata can be queried. =A0An important/use= ful >>> query is to retrieve the list of links with a given rel value: >>>=20 >>> get_links(metadata, rel) =A0# Get sequence of links with given rel valu= e, or >>> empty list if not found. >>>=20 >>> Sometimes you may require that only the first set of links found >>> count: >>>=20 >>> get_top_priority_links(metadata, rel) =A0# Get sequence of links with g= iven >>> rel >>> value, ignoring all but the first set found >>>=20 >>> ...and of course you can do a similar query for properties. >>=20 >> EHL >>=20 >=20 >=20 From cmortimore@salesforce.com Sat Apr 10 13:03:09 2010 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 A0A763A688C; Sat, 10 Apr 2010 13:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 9s2Acep9kBR6; Sat, 10 Apr 2010 13:03:02 -0700 (PDT) Received: from exprod8og115.obsmtp.com (exprod8og115.obsmtp.com [64.18.3.30]) by core3.amsl.com (Postfix) with SMTP id 9FED13A677D; Sat, 10 Apr 2010 13:03:01 -0700 (PDT) Received: from source ([204.14.239.238]) by exprod8ob115.postini.com ([64.18.7.12]) with SMTP ID DSNKS8DZcQxI6zll0XMnzHxyw2L5MSh6vpLo@postini.com; Sat, 10 Apr 2010 13:02:58 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Sat, 10 Apr 2010 13:02:56 -0700 From: Chuck Mortimore To: Eran Hammer-Lahav , OAuth WG Date: Sat, 10 Apr 2010 13:02:57 -0700 Subject: Re: [OAUTH-WG] Native applications capable of handling callbacks Thread-Topic: [OAUTH-WG] Native applications capable of handling callbacks Thread-Index: AcrYIt9HqbEa8GrhW0eQRvN1PulFkwARc/duACAIQsA= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7E6278134EEcmortimoresalesforcecom_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 15 Apr 2010 08:04:05 -0700 Cc: "apps-discuss@ietf.org" 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, 10 Apr 2010 20:03:09 -0000 --_000_C7E6278134EEcmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable While I agree it's a bit of an abusive practice, it is a pervasive one, and= I'm worried about our ability to actually change the behavior of these pla= tforms ( Mozilla is in the list as well ). So - it's a bit of a trade off. I certainly don't want to add anything to= the spec that won't get approved. On the other hand, pragmatically, I'm m= ostly concerned with securing these devices and how my customer's credentia= ls are used with them. I know the pattern of usage emerged on-top of Oau= th 1; I suspect it will emerge in Oauth2, so I'd be inclined to offer some = guidance. I'll defer to your advise on how best to handle it within the IETF and the = spec... -cmort On 4/9/10 9:45 PM, "Eran Hammer-Lahav" wrote: (+apps-discuss as this is of general interest to the area) On 4/9/10 1:26 PM, "Chuck Mortimore" wrote: > A number of the modern application platforms (Android, iPhone, iPad) have > support for registering custom url schemes for native applications. Th= is > allows them to receive callbacks from web browsers, without resorting to = copy > paste, or window title polling. For instance, the authorization server= may > redirect the devices browser to: > > HTTP/1.1 302 Found > Location: myapp://oauth_callback?code=3Di1WsRn1uB1 > > This results in the application launching and the URL being passed to it'= s > callback handler. > > There are a few issues I see with handling these in current form: > > * The Web Callback flow is not appropriate, as the client secret cannot b= e > secured > * The Native Application flow best describes these types of clients, but > doesn't handle the flow > * The User Agent flow would likely work, but the description would lead > implementers away from this, and I'd be concerned that the implementation= s may > gravitate towards handling cross domain javascript tunneling > > I believe all of the pieces are here to support this, but I'd be interest= ed in > seeing stronger guidance for implementers on how to handle these clients. > > - cmort The first problem with including this approach in an IETF specification is that it indirectly violates IETF standards, namely the rules governing how new URI schemes should be discussed, approved, and registered. This is also of interest to the W3C TAG. The way this should probably be done is by registering a new URN scheme lik= e app which will look something like: app:application_name:comma_delimited_parameters With application_name either a domain-name-namespaced value (e.g. app:microsoft.com:excel:parameters) or registry based. But without such a mechanism (feel free to offer other ideas), to suggest i= n an IETF standard that developers should go and make up random URI schemes for their clients is both bad policy and not likely to pass Last Call. If this group has the appetite for such a feature, I would be happy to draf= t a very short proposal for such a new URN scheme, which we can then publish separately or include in the OAuth spec. In practice, until companies like Apple and Microsoft (the two leading OS vendors), and Google (with Android) support such a generic application URN, people will continue to do so. But if we propose a standard path, we can then mention the "abusive" practice and declare it deprecated, pointing people to the right way of doing it. That will help in getting adoption lon= g term. Thoughts? EHL --_000_C7E6278134EEcmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Native applications capable of handling callbacks</TI= TLE> </HEAD> <BODY> <FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-size:11pt'>While I agree i= t’s a bit of an abusive practice, it is a pervasive one, and I’= m worried about our ability to actually change the behavior of these platfo= rms ( Mozilla is in the list as well ).   <BR> <BR> So – it’s a bit of a trade off.   I certainly donR= 17;t want to add anything to the spec that won’t get approved.  = On the other hand, pragmatically, I’m mostly concerned with securing = these devices and how my customer’s credentials are used with them. &= nbsp;  I know the pattern of usage emerged on-top of Oauth 1; I s= uspect it will emerge in Oauth2, so I’d be inclined to offer some gui= dance.   <BR> <BR> I’ll defer to your advise on how best to handle it within the IETF an= d the spec...<BR> <BR> -cmort<BR> <BR> <BR> On 4/9/10 9:45 PM, "Eran Hammer-Lahav" <<a href=3D"eran@hueniv= erse.com">eran@hueniverse.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-= size:11pt'>(+apps-discuss as this is of general interest to the area)<BR> <BR> On 4/9/10 1:26 PM, "Chuck Mortimore" <<a href=3D"cmortimore@sa= lesforce.com">cmortimore@salesforce.com</a>> wrote:<BR> <BR> > A number of the modern application platforms (Android, iPhone, iPad) h= ave<BR> > support for registering custom url schemes for native applications. &n= bsp;  This<BR> > allows them to receive callbacks from web browsers, without resorting = to copy<BR> > paste, or window title polling.    For instance, the au= thorization server may<BR> > redirect the devices browser to:<BR> ><BR> > HTTP/1.1 302 Found<BR> > Location: myapp://oauth_callback?code=3Di1WsRn1uB1<BR> ><BR> > This results in the application launching and the URL being passed to = it’s<BR> > callback handler.<BR> ><BR> > There are a few issues I see with handling these in current form:<BR> ><BR> > * The Web Callback flow is not appropriate, as the client secret canno= t be<BR> > secured<BR> > * The Native Application flow best describes these types of clients, b= ut<BR> > doesn’t handle the flow<BR> > * The User Agent flow would likely work, but the description would lea= d<BR> > implementers away from this, and I’d be concerned that the imple= mentations may<BR> > gravitate towards handling cross domain javascript tunneling<BR> ><BR> > I believe all of the pieces are here to support this, but I’d be= interested in<BR> > seeing stronger guidance for implementers on how to handle these clien= ts.<BR> ><BR> > - cmort<BR> <BR> The first problem with including this approach in an IETF specification is<= BR> that it indirectly violates IETF standards, namely the rules governing how<= BR> new URI schemes should be discussed, approved, and registered. This is also= <BR> of interest to the W3C TAG.<BR> <BR> The way this should probably be done is by registering a new URN scheme lik= e<BR> app which will look something like:<BR> <BR> app:application_name:comma_delimited_parameters<BR> <BR> With application_name either a domain-name-namespaced value (e.g.<BR> app:microsoft.com:excel:parameters) or registry based.<BR> <BR> But without such a mechanism (feel free to offer other ideas), to suggest i= n<BR> an IETF standard that developers should go and make up random URI schemes<B= R> for their clients is both bad policy and not likely to pass Last Call.<BR> <BR> If this group has the appetite for such a feature, I would be happy to draf= t<BR> a very short proposal for such a new URN scheme, which we can then publish<= BR> separately or include in the OAuth spec.<BR> <BR> In practice, until companies like Apple and Microsoft (the two leading OS<B= R> vendors), and Google (with Android) support such a generic application URN,= <BR> people will continue to do so. But if we propose a standard path, we can<BR= > then mention the "abusive" practice and declare it deprecated, po= inting<BR> people to the right way of doing it. That will help in getting adoption lon= g<BR> term.<BR> <BR> Thoughts?<BR> <BR> EHL<BR> <BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C7E6278134EEcmortimoresalesforcecom_-- From beaton@google.com Mon Apr 12 10:42:36 2010 Return-Path: <beaton@google.com> 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 ADC043A69B5; Mon, 12 Apr 2010 10:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 XyV-z0Lc8lMh; Mon, 12 Apr 2010 10:42:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id BE37B3A6A1F; Mon, 12 Apr 2010 10:42:26 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [10.3.21.14]) by smtp-out.google.com with ESMTP id o3CHgJOX005034; Mon, 12 Apr 2010 19:42:20 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1271094140; bh=mk0/iZYTSKTgZfMWcKuz2GZMg5g=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=JgifI1YiWnuqc2V6MlshcOJcRWMYxOTFV1C12ZggkrZa2Me1KsJgIXSjpAKbLcdQa 3Ddpc0U9mpoPLjaT6nJRQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=PqpHtvvmnpHsnPSGn1FDRxR0jnF2XQgypxkleB4ROoYz4L9sG42WZlW0Fuzt+rEDz nVC9LtHo138fqK1U7ex5w== Received: from vws17 (vws17.prod.google.com [10.241.21.145]) by hpaq14.eem.corp.google.com with ESMTP id o3CHgHvZ012927; Mon, 12 Apr 2010 19:42:18 +0200 Received: by vws17 with SMTP id 17so38186vws.23 for <multiple recipients>; Mon, 12 Apr 2010 10:42:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.124.2 with HTTP; Mon, 12 Apr 2010 10:42:16 -0700 (PDT) In-Reply-To: <C7E62781.34EE%cmortimore@salesforce.com> References: <C7E5508A.32008%eran@hueniverse.com> <C7E62781.34EE%cmortimore@salesforce.com> Date: Mon, 12 Apr 2010 10:42:16 -0700 Received: by 10.220.107.73 with SMTP id a9mr2235119vcp.65.1271094136318; Mon, 12 Apr 2010 10:42:16 -0700 (PDT) Message-ID: <l2sdaf5b9571004121042uf9b1943dz2c69678ebfde1111@mail.gmail.com> Subject: Re: [OAUTH-WG] Native applications capable of handling callbacks From: Brian Eaton <beaton@google.com> To: Chuck Mortimore <cmortimore@salesforce.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Mailman-Approved-At: Thu, 15 Apr 2010 08:04:05 -0700 Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, OAuth WG <oauth@ietf.org> X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 12 Apr 2010 17:42:36 -0000 On Sat, Apr 10, 2010 at 1:02 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote: > While I agree it=92s a bit of an abusive practice, it is a pervasive one,= and > I=92m worried about our ability to actually change the behavior of these > platforms ( Mozilla is in the list as well ). > > So =96 it=92s a bit of a trade off. =A0=A0I certainly don=92t want to add= anything to > the spec that won=92t get approved. =A0On the other hand, pragmatically, = I=92m > mostly concerned with securing these devices and how my customer=92s > credentials are used with them. =A0=A0=A0I know the pattern of usage emer= ged > on-top of Oauth 1; I suspect it will emerge in Oauth2, so I=92d be inclin= ed to > offer some guidance. > > I=92ll defer to your advise on how best to handle it within the IETF and = the > spec... Agreed. This is a hard problem, and developers need guidance on what kind of solutions work in practice. From lshepard@facebook.com Wed Apr 14 10:38:09 2010 Return-Path: <lshepard@facebook.com> 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 074D53A681F; Wed, 14 Apr 2010 10:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[AWL=-1.089, BAYES_40=-0.185, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 AqgSxLktM+8G; Wed, 14 Apr 2010 10:38:00 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 4EDD528C107; Wed, 14 Apr 2010 10:37:57 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.198]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o3EHbDbf003671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Apr 2010 10:37:13 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.682.1; Wed, 14 Apr 2010 10:36:48 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Wed, 14 Apr 2010 10:32:53 -0700 From: Luke Shepard <lshepard@facebook.com> To: Chuck Mortimore <cmortimore@salesforce.com>, Eran Hammer-Lahav <eran@hueniverse.com>, OAuth WG <oauth@ietf.org> Date: Wed, 14 Apr 2010 10:32:49 -0700 Subject: RE: [OAUTH-WG] Native applications capable of handling callbacks Thread-Topic: [OAUTH-WG] Native applications capable of handling callbacks Thread-Index: AcrYIt9HqbEa8GrhW0eQRvN1PulFkwARc/duACAIQsAAw54l0A== Message-ID: <2513A610118CC14C8E622C376C8DEC93D54D66DB82@SC-MBXC1.TheFacebook.com> References: <C7E5508A.32008%eran@hueniverse.com> <C7E62781.34EE%cmortimore@salesforce.com> In-Reply-To: <C7E62781.34EE%cmortimore@salesforce.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2513A610118CC14C8E622C376C8DEC93D54D66DB82SCMBXC1TheFac_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-14_12:2010-02-06, 2010-04-14, 2010-04-14 signatures=0 X-Mailman-Approved-At: Thu, 15 Apr 2010 08:04:05 -0700 Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org> X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 14 Apr 2010 17:38:09 -0000 --_000_2513A610118CC14C8E622C376C8DEC93D54D66DB82SCMBXC1TheFac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, I missed this thread. It dovetails with my objections raised in the = other thread ("Combining the native application and user-agent flows") The question of whether OAuth should support custom URL protocols seems a b= it academic. In practice, major providers will probably allow them if there= is demand from developers. The goal of this group is to establish a pragma= tic, widely adopted authentication protocol - not to wage a IETF campaign a= gainst browser vendors to force compliance to standards. Additionally, in my email I laid out a few ways for an entirely client app = to handle a callback without using custom protocols. For instance: - Use a scheme like "about:blank" (does that count as a custom sch= eme or is it supported by the IETF?) - Host a static callback themselves. For many apps it's much easie= r to host a single, static callback than a dynamic server endpoint. - Use a callback hosted by the provider (i.e., http://facebook.com= /universal_callback In practice, this is how desktop and mobile clients work to access Facebook= today. The Native Application flow is basically like the third option abo= ve (callback hosted by provider), but without the flexibility of the first = two. We should just get rid of that flow and use the "User-agent" flow. (I = would prefer something like "Client-side App flow" but I understand that th= e naming here is pretty difficult) From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C= huck Mortimore Sent: Saturday, April 10, 2010 1:03 PM To: Eran Hammer-Lahav; OAuth WG Cc: apps-discuss@ietf.org Subject: Re: [OAUTH-WG] Native applications capable of handling callbacks While I agree it's a bit of an abusive practice, it is a pervasive one, and= I'm worried about our ability to actually change the behavior of these pla= tforms ( Mozilla is in the list as well ). So - it's a bit of a trade off. I certainly don't want to add anything to= the spec that won't get approved. On the other hand, pragmatically, I'm m= ostly concerned with securing these devices and how my customer's credentia= ls are used with them. I know the pattern of usage emerged on-top of Oau= th 1; I suspect it will emerge in Oauth2, so I'd be inclined to offer some = guidance. I'll defer to your advise on how best to handle it within the IETF and the = spec... -cmort On 4/9/10 9:45 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote: (+apps-discuss as this is of general interest to the area) On 4/9/10 1:26 PM, "Chuck Mortimore" <cmortimore@salesforce.com> wrote: > A number of the modern application platforms (Android, iPhone, iPad) have > support for registering custom url schemes for native applications. Th= is > allows them to receive callbacks from web browsers, without resorting to = copy > paste, or window title polling. For instance, the authorization server= may > redirect the devices browser to: > > HTTP/1.1 302 Found > Location: myapp://oauth_callback?code=3Di1WsRn1uB1 > > This results in the application launching and the URL being passed to it'= s > callback handler. > > There are a few issues I see with handling these in current form: > > * The Web Callback flow is not appropriate, as the client secret cannot b= e > secured > * The Native Application flow best describes these types of clients, but > doesn't handle the flow > * The User Agent flow would likely work, but the description would lead > implementers away from this, and I'd be concerned that the implementation= s may > gravitate towards handling cross domain javascript tunneling > > I believe all of the pieces are here to support this, but I'd be interest= ed in > seeing stronger guidance for implementers on how to handle these clients. > > - cmort The first problem with including this approach in an IETF specification is that it indirectly violates IETF standards, namely the rules governing how new URI schemes should be discussed, approved, and registered. This is also of interest to the W3C TAG. The way this should probably be done is by registering a new URN scheme lik= e app which will look something like: app:application_name:comma_delimited_parameters With application_name either a domain-name-namespaced value (e.g. app:microsoft.com:excel:parameters) or registry based. But without such a mechanism (feel free to offer other ideas), to suggest i= n an IETF standard that developers should go and make up random URI schemes for their clients is both bad policy and not likely to pass Last Call. If this group has the appetite for such a feature, I would be happy to draf= t a very short proposal for such a new URN scheme, which we can then publish separately or include in the OAuth spec. In practice, until companies like Apple and Microsoft (the two leading OS vendors), and Google (with Android) support such a generic application URN, people will continue to do so. But if we propose a standard path, we can then mention the "abusive" practice and declare it deprecated, pointing people to the right way of doing it. That will help in getting adoption lon= g term. Thoughts? EHL --_000_2513A610118CC14C8E622C376C8DEC93D54D66DB82SCMBXC1TheFac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"= > <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <title>Re: [OAUTH-WG] Native applications capable of handling callbacks</ti= tle> <style> <!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:"Lucida Grande"; panose-1:0 0 0 0 0 0 0 0 0 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:557472488; mso-list-type:hybrid; mso-list-template-ids:272143400 142877726 67698691 67698693 67698689 67698= 691 67698693 67698689 67698691 67698693;} @list l0:level1 {mso-level-start-at:0; mso-level-number-format:bullet; mso-level-text:-; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:"Calibri","sans-serif"; mso-fareast-font-family:Calibri;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>Sorry, I missed this thread. It dovetails with my objections raised in the other thread (“Combining the native application and use= r-agent flows”)<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>The question of whether OAuth should support custom URL protocols seems a bit academic. In practice, major providers will probably allow them if there is demand from developers. The goal of this group is to establish a pragmatic, widely adopted authentication protocol – not t= o wage a IETF campaign against browser vendors to force compliance to standards.<o:p= ></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'><br> Additionally, in my email I laid out a few ways for an entirely client app = to handle a callback without using custom protocols. For instance:<o:p></o:p></span><= /p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 = lfo1'><![if !supportLists]><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'= ><span style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New Roman"'>&nb= sp;         </span></span></span><![endif]><span style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'>Use a scheme like “about:blank” (does that count= as a custom scheme or is it supported by the IETF?)<o:p></o:p></span></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 = lfo1'><![if !supportLists]><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'= ><span style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New Roman"'>&nb= sp;         </span></span></span><![endif]><span style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'>Host a static callback themselves. For many apps it’s = much easier to host a single, static callback than a dynamic server endpoint.<o:= p></o:p></span></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 = lfo1'><![if !supportLists]><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'= ><span style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New Roman"'>&nb= sp;         </span></span></span><![endif]><span style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'>Use a callback hosted by the provider (i.e., <a href=3D"http://facebook.com/universal_callback">http://facebook.com/univers= al_callback</a><o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>In practice, this is how desktop and mobile clients work to access Facebook today. The Native Application flow is basically like  = the third option above (callback hosted by provider), but without the flexibility of = the first two. We should just get rid of that flow and use the “User-agen= t” flow. (I would prefer something like “Client-side App flow” but I und= erstand that the naming here is pretty difficult)<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in'> <p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma= ","sans-serif"'>From:</span></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] <b>On Behalf Of </b>= Chuck Mortimore<br> <b>Sent:</b> Saturday, April 10, 2010 1:03 PM<br> <b>To:</b> Eran Hammer-Lahav; OAuth WG<br> <b>Cc:</b> apps-discuss@ietf.org<br> <b>Subject:</b> Re: [OAUTH-WG] Native applications capable of handling callbacks<o:p></o:p></span></p> </div> </div> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span style=3D'font-siz= e:11.0pt; font-family:"Lucida Grande","serif"'>While I agree it’s a bit of an a= busive practice, it is a pervasive one, and I’m worried about our ability to= actually change the behavior of these platforms ( Mozilla is in the list as well ).   <br> <br> So – it’s a bit of a trade off.   I certainly donR= 17;t want to add anything to the spec that won’t get approved.  On the other hand= , pragmatically, I’m mostly concerned with securing these devices and h= ow my customer’s credentials are used with them.    I know t= he pattern of usage emerged on-top of Oauth 1; I suspect it will emerge in Oauth2, so = I’d be inclined to offer some guidance.   <br> <br> I’ll defer to your advise on how best to handle it within the IETF an= d the spec...<br> <br> -cmort<br> <br> <br> On 4/9/10 9:45 PM, "Eran Hammer-Lahav" <<a href=3D"eran@hueniverse.com">eran@hueniverse.com</a>> wrote:</span><o:p>= </o:p></p> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span style=3D'font-siz= e:11.0pt; font-family:"Lucida Grande","serif"'>(+apps-discuss as this is of general interest to the area)<br> <br> On 4/9/10 1:26 PM, "Chuck Mortimore" <<a href=3D"cmortimore@salesforce.com">cmortimore@salesforce.com</a>> wrote:= <br> <br> > A number of the modern application platforms (Android, iPhone, iPad) h= ave<br> > support for registering custom url schemes for native applications.    This<br> > allows them to receive callbacks from web browsers, without resorting = to copy<br> > paste, or window title polling.    For instance, the authorization server may<br> > redirect the devices browser to:<br> ><br> > HTTP/1.1 302 Found<br> > Location: myapp://oauth_callback?code=3Di1WsRn1uB1<br> ><br> > This results in the application launching and the URL being passed to = it’s<br> > callback handler.<br> ><br> > There are a few issues I see with handling these in current form:<br> ><br> > * The Web Callback flow is not appropriate, as the client secret canno= t be<br> > secured<br> > * The Native Application flow best describes these types of clients, b= ut<br> > doesn’t handle the flow<br> > * The User Agent flow would likely work, but the description would lea= d<br> > implementers away from this, and I’d be concerned that the imple= mentations may<br> > gravitate towards handling cross domain javascript tunneling<br> ><br> > I believe all of the pieces are here to support this, but I’d be interested in<br> > seeing stronger guidance for implementers on how to handle these clien= ts.<br> ><br> > - cmort<br> <br> The first problem with including this approach in an IETF specification is<= br> that it indirectly violates IETF standards, namely the rules governing how<= br> new URI schemes should be discussed, approved, and registered. This is also= <br> of interest to the W3C TAG.<br> <br> The way this should probably be done is by registering a new URN scheme lik= e<br> app which will look something like:<br> <br> app:application_name:comma_delimited_parameters<br> <br> With application_name either a domain-name-namespaced value (e.g.<br> app:microsoft.com:excel:parameters) or registry based.<br> <br> But without such a mechanism (feel free to offer other ideas), to suggest i= n<br> an IETF standard that developers should go and make up random URI schemes<b= r> for their clients is both bad policy and not likely to pass Last Call.<br> <br> If this group has the appetite for such a feature, I would be happy to draf= t<br> a very short proposal for such a new URN scheme, which we can then publish<= br> separately or include in the OAuth spec.<br> <br> In practice, until companies like Apple and Microsoft (the two leading OS<b= r> vendors), and Google (with Android) support such a generic application URN,= <br> people will continue to do so. But if we propose a standard path, we can<br= > then mention the "abusive" practice and declare it deprecated, pointing<br> people to the right way of doing it. That will help in getting adoption lon= g<br> term.<br> <br> Thoughts?<br> <br> EHL<br> <br> </span><o:p></o:p></p> </div> </body> </html> --_000_2513A610118CC14C8E622C376C8DEC93D54D66DB82SCMBXC1TheFac_-- From ietf@adambarth.com Thu Apr 15 12:09:55 2010 Return-Path: <ietf@adambarth.com> 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 1D8063A6966 for <apps-discuss@core3.amsl.com>; Thu, 15 Apr 2010 12:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.275 X-Spam-Level: X-Spam-Status: No, score=0.275 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_50=0.001, 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 XVV8JmrCvIHm for <apps-discuss@core3.amsl.com>; Thu, 15 Apr 2010 12:09:52 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id DE1AF3A681F for <apps-discuss@ietf.org>; Thu, 15 Apr 2010 12:09:52 -0700 (PDT) Received: by pvf33 with SMTP id 33so1143719pvf.31 for <apps-discuss@ietf.org>; Thu, 15 Apr 2010 12:09:43 -0700 (PDT) Received: by 10.114.30.6 with SMTP id d6mr611741wad.135.1271358583422; Thu, 15 Apr 2010 12:09:43 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id 23sm1523618pzk.6.2010.04.15.12.09.41 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Apr 2010 12:09:41 -0700 (PDT) Received: by pwj2 with SMTP id 2so1418959pwj.31 for <apps-discuss@ietf.org>; Thu, 15 Apr 2010 12:09:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.177.225 with HTTP; Thu, 15 Apr 2010 12:09:20 -0700 (PDT) In-Reply-To: <4BC326A6.1050601@gmx.de> References: <4BBDEF11.6020008@gmx.de> <l2z5c4444771004112109x6e3e77ebw5d38758e66d68d8a@mail.gmail.com> <4BC326A6.1050601@gmx.de> From: Adam Barth <ietf@adambarth.com> Date: Thu, 15 Apr 2010 12:09:20 -0700 Received: by 10.115.113.31 with SMTP id q31mr758345wam.1.1271358580480; Thu, 15 Apr 2010 12:09:40 -0700 (PDT) Message-ID: <v2r5c4444771004151209p34f81b41y832c0feeb73ce125@mail.gmail.com> Subject: Re: draft-abarth-mime-sniff, confused by Section 1 To: Julian Reschke <julian.reschke@gmx.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss <apps-discuss@ietf.org> X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 15 Apr 2010 19:09:55 -0000 On Mon, Apr 12, 2010 at 6:56 AM, Julian Reschke <julian.reschke@gmx.de> wro= te: > On 12.04.2010 06:09, Adam Barth wrote: >> On Thu, Apr 8, 2010 at 7:58 AM, Julian Reschke<julian.reschke@gmx.de> >> =A0wrote: >>> >>> <http://tools.ietf.org/html/draft-abarth-mime-sniff-04#section-1> =A0ha= s: >>> >>> =A0 However, if a user agent does interpret a low-privilege media type, >>> =A0 such as image/gif, as a high-privilege media type, such as text/htm= l, >>> =A0 the user agent has created a privilege escalation vulnerability in >>> =A0 the server. >>> >>> "in the server"? How does this affect the server? >> >> Because the user agent has misinterpreted what the server said. =A0On >> the web, servers need to be careful what they say because the same >> origin policy imbues their words (HTTP responses) with their >> authority. =A0If a user agent misinterprets an image as HTML, the server >> will become vulnerable to cross-site scripting. > > I see what you mean, but I still think is misleading. > > A server that relies on UAs implementing the same-origin policy will be > vulnerable anyway. So the vulnerability is already there, it just becomes > easier to exploit (compared, for instance, to attack the server using > specially crafted scripts doing the HTTP request). I don't understand what you mean when you say "a server that relies on UAs implementing the same-origin policy will be vulnerable anyway." For example, bankofamerica.com relies on the UA implementing the same-origin policy. Is it vulnerable? I guess the answer to that question depends on which threats we're considering. Adam From julian.reschke@gmx.de Thu Apr 15 12:17:46 2010 Return-Path: <julian.reschke@gmx.de> 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 95EB83A690B for <apps-discuss@core3.amsl.com>; Thu, 15 Apr 2010 12:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.15 X-Spam-Level: X-Spam-Status: No, score=-4.15 tagged_above=-999 required=5 tests=[AWL=-1.551, 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 E-dZld3oS1gy for <apps-discuss@core3.amsl.com>; Thu, 15 Apr 2010 12:17:45 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D4A853A694A for <apps-discuss@ietf.org>; Thu, 15 Apr 2010 12:17:41 -0700 (PDT) Received: (qmail invoked by alias); 15 Apr 2010 19:17:31 -0000 Received: from p508FCE13.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.206.19] by mail.gmx.net (mp058) with SMTP; 15 Apr 2010 21:17:31 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+9kDZh5o69HBEX48fRZwN4/4jfjKNoFFXFH3Tbgf M4q/sB02/cORMl Message-ID: <4BC76643.7070604@gmx.de> Date: Thu, 15 Apr 2010 21:17:23 +0200 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Adam Barth <ietf@adambarth.com> Subject: Re: draft-abarth-mime-sniff, confused by Section 1 References: <4BBDEF11.6020008@gmx.de> <l2z5c4444771004112109x6e3e77ebw5d38758e66d68d8a@mail.gmail.com> <4BC326A6.1050601@gmx.de> <v2r5c4444771004151209p34f81b41y832c0feeb73ce125@mail.gmail.com> In-Reply-To: <v2r5c4444771004151209p34f81b41y832c0feeb73ce125@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.65000000000000002 Cc: IETF Apps Discuss <apps-discuss@ietf.org> X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 15 Apr 2010 19:17:46 -0000 On 15.04.2010 21:09, Adam Barth wrote: > ... > I don't understand what you mean when you say "a server that relies on > UAs implementing the same-origin policy will be vulnerable anyway." > For example, bankofamerica.com relies on the UA implementing the > same-origin policy. Is it vulnerable? I guess the answer to that > question depends on which threats we're considering. > ... What I'm trying to say is that if a server relies in a client not doing certain things then it's vulnerable when a client does these things anyway. So that could be hand-crafted client sending requests that a browser wouldn't send. Maybe it just shows that most of my past I was involved in non-browser interactions over HTTP, so I'm trained not to rely on the niceness of clients. Best regards, Julian From ietf@adambarth.com Thu Apr 15 13:44:56 2010 Return-Path: <ietf@adambarth.com> 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 B88013A69F3 for <apps-discuss@core3.amsl.com>; Thu, 15 Apr 2010 13:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=1.300, 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 XUWge5KeXkXu for <apps-discuss@core3.amsl.com>; Thu, 15 Apr 2010 13:44:55 -0700 (PDT) Received: from mail-pz0-f193.google.com (mail-pz0-f193.google.com [209.85.222.193]) by core3.amsl.com (Postfix) with ESMTP id 62BF73A68E1 for <apps-discuss@ietf.org>; Thu, 15 Apr 2010 13:44:55 -0700 (PDT) Received: by pzk31 with SMTP id 31so810031pzk.31 for <apps-discuss@ietf.org>; Thu, 15 Apr 2010 13:44:46 -0700 (PDT) Received: by 10.142.61.35 with SMTP id j35mr518680wfa.124.1271364286458; Thu, 15 Apr 2010 13:44:46 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by mx.google.com with ESMTPS id 22sm1583555pzk.13.2010.04.15.13.44.45 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Apr 2010 13:44:45 -0700 (PDT) Received: by pvf33 with SMTP id 33so1235956pvf.31 for <apps-discuss@ietf.org>; Thu, 15 Apr 2010 13:44:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.177.225 with HTTP; Thu, 15 Apr 2010 13:44:24 -0700 (PDT) In-Reply-To: <4BC76643.7070604@gmx.de> References: <4BBDEF11.6020008@gmx.de> <l2z5c4444771004112109x6e3e77ebw5d38758e66d68d8a@mail.gmail.com> <4BC326A6.1050601@gmx.de> <v2r5c4444771004151209p34f81b41y832c0feeb73ce125@mail.gmail.com> <4BC76643.7070604@gmx.de> From: Adam Barth <ietf@adambarth.com> Date: Thu, 15 Apr 2010 13:44:24 -0700 Received: by 10.141.91.2 with SMTP id t2mr1066743rvl.111.1271364284518; Thu, 15 Apr 2010 13:44:44 -0700 (PDT) Message-ID: <l2k5c4444771004151344o38a1cc11m25c8f93f3b1f738a@mail.gmail.com> Subject: Re: draft-abarth-mime-sniff, confused by Section 1 To: Julian Reschke <julian.reschke@gmx.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss <apps-discuss@ietf.org> X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 15 Apr 2010 20:44:56 -0000 On Thu, Apr 15, 2010 at 12:17 PM, Julian Reschke <julian.reschke@gmx.de> wr= ote: > On 15.04.2010 21:09, Adam Barth wrote: >> ... >> I don't understand what you mean when you say "a server that relies on >> UAs implementing the same-origin policy will be vulnerable anyway." >> For example, bankofamerica.com relies on the UA implementing the >> same-origin policy. =A0Is it vulnerable? =A0I guess the answer to that >> question depends on which threats we're considering. >> ... > > What I'm trying to say is that if a server relies in a client not doing > certain things then it's vulnerable when a client does these things anywa= y. > > So that could be hand-crafted client sending requests that a browser > wouldn't send. > > Maybe it just shows that most of my past I was involved in non-browser > interactions over HTTP, so I'm trained not to rely on the niceness of > clients. Typically the way web sites defend themselves against these sorts of threats is by authenticating the remote user agent, e.g. with a cookie. If a user want to use a non-standard user agent, they are free to send whatever HTTP requests they like. However, the damage that these users can do is typically contained to messing with their own account (e.g., bank account at bankofamerica.com). Honest users, like me, use a normal user agent and rely upon my user agent and bankofamerica.com to protect my account. Another way of looking at this situation is that your statement applies equally well to cross-site scripting (XSS). A server only has to worry about XSS if they rely upon the UA to implement the same-origin policy. However, XSS is consistently ranked the #1 security problem for web applications (e.g., <http://www.owasp.org/index.php/Top_10_2007>). Therefore, a great many web applications must be relying upon the UA enforcing the same-origin policy. Adam From anthonybryan@gmail.com Fri Apr 16 12:02:29 2010 Return-Path: <anthonybryan@gmail.com> 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 72A6D28C16A for <apps-discuss@core3.amsl.com>; Fri, 16 Apr 2010 12:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_50=0.001, 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 tziZfyYnewFl for <apps-discuss@core3.amsl.com>; Fri, 16 Apr 2010 12:02:21 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 29BC228C17D for <apps-discuss@ietf.org>; Fri, 16 Apr 2010 12:02:00 -0700 (PDT) Received: by iwn27 with SMTP id 27so1613918iwn.5 for <apps-discuss@ietf.org>; Fri, 16 Apr 2010 12:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pyAi0XC5HjAnUv3erlCa0yqVm2lTt0AqzzjLQgxwzc0=; b=CQZ7T1dOvt3K/E11XDuSsO1J7jQI3tai5JB2hmgG7p+tRv9qRE9fFgsOlnYFHzHVuc meSsLSDqJzsl6w6Dr/hBi3Csk2eAQi5yd8qBOi0Hnplmg/uL9CiboBsb32eGadPUKbr0 PKutvzL7a25h++RH6ufb4J41NiJE3+9yhKbTo= 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=Y2mV3YIDmxyTrVew5lnAVTV6/L0iVOICAH148cDwKX3K0ijKaxtU0ATXkeafezZ1Ns Xe4uFokA+Bxz795CN9+vtCyky8hOvTM9EndpUxPoBac2Fcj2WILVJR0UiV+PYcaGSvqG bh8Tss7R8N+gzDelHLacpS5GmIUF/poDkaXgg= MIME-Version: 1.0 Received: by 10.231.171.13 with HTTP; Fri, 16 Apr 2010 12:01:49 -0700 (PDT) In-Reply-To: <201004011954.VAA28916@TR-Sys.de> References: <201003231642.RAA04676@TR-Sys.de> <201004011954.VAA28916@TR-Sys.de> Date: Fri, 16 Apr 2010 15:01:49 -0400 Received: by 10.231.144.197 with SMTP id a5mr686190ibv.5.1271444509928; Fri, 16 Apr 2010 12:01:49 -0700 (PDT) Message-ID: <m2ibb9e09ee1004161201xca0e4d80k930f3ce96517c42f@mail.gmail.com> Subject: Re: draft-bryan-ftp-hash-00 -- items for discussion From: Anthony Bryan <anthonybryan@gmail.com> To: =?ISO-8859-1?Q?Alfred_H=CEnes?= <ah@tr-sys.de>, Tim Kosse <tim.kosse@filezilla-project.org>, Daniel Stenberg <daniel@haxx.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 16 Apr 2010 19:02:29 -0000 On Thu, Apr 1, 2010 at 3:54 PM, Alfred H=CEnes <ah@tr-sys.de> wrote: > > -------- forwarded content of message to the authors ------- > > In particular: > > a) untypical use of a command with a file path argument *and* > =A0 another argument -- consider using: > =A0 =A0 =A0 =A0OPTS HASH <hash> > =A0 =A0 =A0 =A0HASH <filepath> Our current draft uses this. Thanks for the feedback! > b) underspecification of the representation of the file that shall > =A0 undergo the hash calculation; a canonical form of the file is > =A0 essential here for interoperability; I already have discussed > =A0 some of the options that came to my mind: using the current > =A0 transfer mode settings, defining a specific overriding set of > =A0 mode settings, or requiring a single specific set of mode > =A0 settings to be active (or a small choice of such). > =A0 I cannot imagine how verification would be possible without > =A0 a well defined canonical file representation in a heterogenous > =A0 systems environment where e.g. one system uses record-oriented > =A0 file storage and another one uses byte-stream storage with either > =A0 <NL> or <CRLF> convention, one system pads records with blanks > =A0 to an alignment boundary and another system truncates trailing > =A0 blanks on file lines, ... (all that behavior exists in my office!) Our current draft includes this: The HASH command is useful for files transmitted in Image type mode (TYPE I) and Stream transfer mode (MODE S). Does that address this issue sufficiently? > Further, I'd like to draw your attention to RFC 5797 and the > FTP Commands and Extensions IANA Registry it has established now, at > =A0<http://www.IANA.ORG/assignments/ftp-commands-extensions/ > =A0 =A0 =A0 =A0 =A0ftp-commands-extensions.xhtml> ). > So you might wish to amend your proposal with substantial IANA > considerations for the registration of the proposed extension and > the associated FEAT strings. Added to our current version. > Also, it might make sense to give reference to prior work; > I'm aware of an old expired I-D, draft-twine-ftpmd5-00, May 2002. I was able to find 2 servers that support this method. In total, there are at least nine non-standard FTP checksum/hash commands: XCRC, MD5/MMD5, XMD5, XSHA, XSHA1, XSHA256, XSHA512, SITE SHOHASH, SITE CHE= CKSUM Over 45 FTP servers/clients support these 9 commands. Also, interested parties might want to read Robert McMurray's blog post on IIS, "Automatically Creating Checksum Files for FTP Uploads": "I had a great question in the publishing forums on forums.iis.net, where someone was asking if FTP 7 supported the XCRC command. The short answer is that the XCRC command is not supported, but I came up with a way to create an FTP provider that supports something like it. " http://blogs.msdn.com/robert_mcmurray/archive/2009/07/30/automatically-crea= ting-checksum-files-for-ftp-uploads.aspx And finally, here is some feedback on our draft from those implementing the nonstandard hash commands. zFTPServer: Interesting... a nice complement (or even replacement) for the XCRC and XMD5 commands... Apache FTP server: This looks good. We should have these defined years ago, but better late than never! --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From A.Hoenes@TR-Sys.de Thu Apr 22 01:36:57 2010 Return-Path: <A.Hoenes@TR-Sys.de> 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 3EC403A688D; Thu, 22 Apr 2010 01:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.076 X-Spam-Level: X-Spam-Status: No, score=-96.076 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 4WMDrVzkTPkr; Thu, 22 Apr 2010 01:36:56 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 975143A6813; Thu, 22 Apr 2010 01:36:54 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA239065367; Thu, 22 Apr 2010 10:36:07 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id KAA03118; Thu, 22 Apr 2010 10:36:06 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@TR-Sys.de> Message-Id: <201004220836.KAA03118@TR-Sys.de> Subject: Re: [urn] new URN discussion list To: apps-discuss@ietf.org, uri-review@ietf.org, urn-nid@ietf.org, uri@w3.org Date: Thu, 22 Apr 2010 10:36:05 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: urn@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 22 Apr 2010 08:36:57 -0000 [[ apologies for cross-posting once more; please direct follow-up messages to urn@ietf.org -- thanks! ]] At Tue, 06 Apr 2010 14:25:36 -0600, Peter Saint-Andre <stpeter at stpeter.im> wrote: > As a venue for discussion about possible revisions to the definition of > Uniform Resource Names (URNs), the IETF Applications Area has created a > new email list urn at ietf.org, to which you can subscribe as follows: > > https://www.ietf.org/mailman/listinfo/urn > > mailto:urn-request at ietf.org?body=subscribe > > Please note that the urn at ietf.org list is for discussion > regarding the definition of URNs. We shall continue to use the > urn-nid at ietf.org list for review of Namespace Identifiers (NIDs). Please note that, accordingly, discussion now should happen on urn@ietf.org regarding: - the draft charter for a "URNbis" WG (target: BoF at IETF 78) (first draft to be submitted soon) and - the following Internet-Drafts: o draft-ah-rfc2141bis-urn (updated definition of the 'URN' URI Scheme, revision of RFC 2141 -- the -01 draft version will point to the new list), o draft-hakala-rfc3187bis-isbn-urn (revised URN namespace definition for 'ISBN' including ISNB-13 -- the -01 draft version will point to the new list), o draft-hakala-rfc3188bis-nbn-urn (revised URN namespace definition for 'NBN', -00 version to be submitted soon). The appropriate functional lists (uri-review and urn-nid) will be consulted again as soon as the process has advanced enough, according to RFC 4395 (BCP 35) and RFC 3406 (BCP 66), respectively. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From julian.reschke@gmx.de Fri Apr 30 03:06:38 2010 Return-Path: <julian.reschke@gmx.de> 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 4F46828C1DF for <apps-discuss@core3.amsl.com>; Fri, 30 Apr 2010 03:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.213 X-Spam-Level: X-Spam-Status: No, score=-4.213 tagged_above=-999 required=5 tests=[AWL=-1.614, 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 RMgtLIfZaKkI for <apps-discuss@core3.amsl.com>; Fri, 30 Apr 2010 03:06:37 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5498C3A6B35 for <apps-discuss@ietf.org>; Fri, 30 Apr 2010 03:06:33 -0700 (PDT) Received: (qmail invoked by alias); 30 Apr 2010 10:06:18 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.116]) [217.91.35.233] by mail.gmx.net (mp062) with SMTP; 30 Apr 2010 12:06:18 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/W7Ax4wZPWqDPBHsB7lKshEDIZXzQREsIw55cP34 Mzihry+cChk9gu Message-ID: <4BDAAB8E.1040803@gmx.de> Date: Fri, 30 Apr 2010 12:06:06 +0200 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: IETF Apps Discuss <apps-discuss@ietf.org> Subject: Re: I-D Action:draft-reschke-rfc2231-in-http-12.txt References: <20100430091502.0B34C28C183@core3.amsl.com> In-Reply-To: <20100430091502.0B34C28C183@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55000000000000004 Cc: HTTP Working Group <ietf-http-wg@w3.org> X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Apr 2010 10:06:38 -0000 Hi, this (post-IESG-review) draft fixes a few typos, removes lowercase BCP14 keywords where they shouldn't appear, and clarifies that although the encoding defined is compatible to a subset of RFC 2231, it really is fully defining it (so the reference to RFC 2231 is really informative) -- the latter point also caused the title change. Best regards, Julian On 30.04.2010 11:15, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters > Author(s) : J. Reschke > Filename : draft-reschke-rfc2231-in-http-12.txt > Pages : 14 > Date : 2010-04-30 > > By default, message header field parameters in Hypertext Transfer > Protocol (HTTP) messages can not carry characters outside the ISO- > 8859-1 character set. RFC 2231 defines an encoding mechanism for use > in Multipurpose Internet Mail Extensions (MIME) headers. This > document specifies an encoding suitable for use in HTTP header fields > which is compatible to a profile of the encoding defined in RFC 2231. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-reschke-rfc2231-in-http-12.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From stpeter@stpeter.im Fri Apr 30 14:37:08 2010 Return-Path: <stpeter@stpeter.im> 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 324013A6A42 for <apps-discuss@core3.amsl.com>; Fri, 30 Apr 2010 14:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 mSRBpU-Xqqw7 for <apps-discuss@core3.amsl.com>; Fri, 30 Apr 2010 14:37:07 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 309083A69EB for <apps-discuss@ietf.org>; Fri, 30 Apr 2010 14:37:07 -0700 (PDT) Received: from squire.local (dsl-228-154.dynamic-dsl.frii.net [216.17.228.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9F52240E16 for <apps-discuss@ietf.org>; Fri, 30 Apr 2010 15:36:52 -0600 (MDT) Message-ID: <4BDB4D73.2050405@stpeter.im> Date: Fri, 30 Apr 2010 15:36:51 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: BCP on SSL/TLS certificates X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060609070707090300010008" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Apr 2010 21:37:08 -0000 This is a cryptographically signed message in MIME format. --------------ms060609070707090300010008 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello AppsArea! Today, Jeff Hodges and I finally pushed out version -04 of our proposed BCP on SSL/TLS certificates, which I presented about in Anaheim: http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-04 This is meant to be a very practical set of best practices about the implementation and deployment of certificate-based SSL/TLS for HTTP, LDAP, IMAP, XMPP, and other application protocols. The meat of the document is only 14 pages, so I hope that some apps folks will have time to read it. Please send your feedback to the certid@ietf.org list: https://www.ietf.org/mailman/listinfo/certid Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060609070707090300010008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDQzMDIxMzY1MVowIwYJKoZIhvcNAQkEMRYEFOwQOnPhq19W5oms8caL bSR7wt/aMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAJ5Z5ERQngx4skvArUzkHPAd6hNJvw3Zu6n8i3A/E 5vlw8WO3EaZxEy7wfPCthLz1To9BhoEOx0pMIYFmoEDsyWHpXLcANReNSjtrO2F7cPUXAIx4 1KPJv1z9bfDrOo/wYmnndcyqkXIJ0zDtlWFBGBJAbrz+u46DDd/8AQS/JiQgrcoERctq46lm kjDFG0XWbLia5ppaOTSeN+dI7VNuzemLkL/b3gNNF1mS3i4PQQ5jUVkFB2/C7NQa3OKxy6Ze JCLYdcQoIS+2isBoceIFEvuu7S+Xo+WDiAhGrJQIwkejAC/phOzPL68erklKIEb7FSRWQDsD tzB9URcQXKSveAAAAAAAAA== --------------ms060609070707090300010008--