From stpeter@stpeter.im Tue Dec 1 10:37:52 2009 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 227CF3A692A for ; Tue, 1 Dec 2009 10:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOQpjZCIYcXt for ; Tue, 1 Dec 2009 10:37:51 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 05AFA3A6903 for ; Tue, 1 Dec 2009 10:37:51 -0800 (PST) Received: from dhcp-64-101-72-196.cisco.com (dhcp-64-101-72-196.cisco.com [64.101.72.196]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1247140D16; Tue, 1 Dec 2009 11:37:42 -0700 (MST) Message-ID: <4B156275.5040805@stpeter.im> Date: Tue, 01 Dec 2009 11:37:41 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "tom.petch" Subject: Re: * was Re: Server Identity Verification in Application Protocols References: <4AC6786E.2020101@stpeter.im> <001a01ca46a3$ff8377e0$0601a8c0@allison> In-Reply-To: <001a01ca46a3$ff8377e0$0601a8c0@allison> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070700080100080307040009" 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, 01 Dec 2009 18:37:52 -0000 This is a cryptographically signed message in MIME format. --------------ms070700080100080307040009 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit My apologies once again for the delayed reply. On 10/6/09 4:05 AM, tom.petch wrote: > This specification disallows the use of * to wildcard the reference identity. > > syslog over TLS not only uses this, but also allows the use of a wildcard > where it would not be allowed in the subjectAltName. > > I would see this as quite common in networking scenarios, where the access > is many to many, and so would like a less severe prescription against it. One approach would be to allow "profiling" of the rules in this spec. For example, we could add text such as the following: ### This specification defines several dimensions that are legitimately a matter of application profiling: 1. In the case of domain names, whether the reference identity can contain the wildcard character '*' (ASCII 42) as the least significant domain label (e.g., "*.example.com"). 2. In the case of domain names, whether the reference identity can contain the wildcard character '*' (ASCII 42) as one of the characters in the least significant domain label fragment (e.g., "foo*.example.com"). Application protocols that re-use this specification rather than define their own certificate rules need to specify whether they allow wildcards in the ways just described. ### We might also want to say that such use of wildcards defaults is "not allowed" unless otherwise specified by the using protocol. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms070700080100080307040009 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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 hvcNAQkFMQ8XDTA5MTIwMTE4Mzc0MVowIwYJKoZIhvcNAQkEMRYEFHtT0gDgNR1ZvKDwq8DM fshPPv1vMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAWk6cN7HbVL3DFoent73gqYHlUvkieclb1PVutjkb 64E7nthuc+thbTVIT3cHiVQS3T0QUsui4PioEUlUap7m1pVAnIY/H17bu1lQZR4m9VPIjgkQ yAdKAFJm412YscRDa3QPzNvFCmWC5DzSdxmzQ6iYYPbzNEGlDmVP2OK5JJCWw1jJ219r0PMX /QB5CByD/WIuj/tRC2iYiOF0pT+NpDfmaWTQ1CESJDBzOKMSFGbOqtZ/9hm/whvopmkihx79 o/LIFR0WVCOrLobMjogdqtqeepSTX3KrkSaOrV+tuW1uyvugvZd2mGR0+GQMPs/UOVbMvVF6 9gX+mXaFyAtWFwAAAAAAAA== --------------ms070700080100080307040009-- From stpeter@stpeter.im Tue Dec 1 10:47:58 2009 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 23CCD3A6984 for ; Tue, 1 Dec 2009 10:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwf4t1pAuED8 for ; Tue, 1 Dec 2009 10:47:56 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8B9A228C16E for ; Tue, 1 Dec 2009 10:47:15 -0800 (PST) Received: from dhcp-64-101-72-196.cisco.com (dhcp-64-101-72-196.cisco.com [64.101.72.196]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D980040D16; Tue, 1 Dec 2009 11:47:07 -0700 (MST) Message-ID: <4B1564AA.4010800@stpeter.im> Date: Tue, 01 Dec 2009 11:47:06 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Kurt Zeilenga Subject: Re: client was Re: Server Identity Verification in Application Protocols References: <4AC6786E.2020101@stpeter.im> <001b01ca46a4$017b0220$0601a8c0@allison> <75930B09-C7DD-46D6-A336-B1A80ADF7CDF@Isode.com> <000401ca476f$f93013e0$0601a8c0@allison> <001501ca4cce$8b359900$0601a8c0@allison> <05CEDCDF-97B5-41C0-9578-BA8030756312@Isode.com> In-Reply-To: <05CEDCDF-97B5-41C0-9578-BA8030756312@Isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080509020701020106030509" 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, 01 Dec 2009 18:47:58 -0000 This is a cryptographically signed message in MIME format. --------------ms080509020701020106030509 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 10/14/09 9:11 AM, Kurt Zeilenga wrote: > I would find it less objectionable for this I-D to simply say something > like: > "This document details a process for client verification of the > server's identity. It is possibly that this process be used in server > verification of a client's identity, however this document does not > consider or detail how this might be done." After thinking about Kurt's argument further and discussing the topic at IETF 76, I agree that verification of client identities is out of scope for this I-D. Interesting problem, but to be discussed elsewhere. In my working copy, I have the following text: Note: This document applies only to server identities, only to TLS, and only to the PKI. Similar considerations might apply to client identities (e.g., for mutual authentication), to security protocols such as [IPSEC] and [DTLS], and to keys or certificates created outside the context of the PKI (e.g., where a dependency on Certificate Revocation Lists or the Online Certificate Status Protocol might introduce unacceptable latency or denial of service attacks). Indeed, some aspects of the encapsulation and verification rules provided in this document might apply to those scenarios, as well; however, those scenarios are outside the scope of this document and need to be addressed by separate specifications. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms080509020701020106030509 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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 hvcNAQkFMQ8XDTA5MTIwMTE4NDcwNlowIwYJKoZIhvcNAQkEMRYEFCCkxzSolYzYUFmmug5C fdpKtEBDMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAT/9ts82wF3LzzjdAJvC1JxHX/PiqDvRBjp/4Tyup ViyTvNL+DmS6dsAXIajn2wFPFwqCE/S4GVVM1YYrKoGFJs/nJaKK27kyy6cZItUA9nZFxSPf rIdoAhcEfJMSW9+kBzFz/C76IBm6djouTlut8SAer2+BcAGMeq5s6U8bw+QKZpw18zGVQGkf e5hROjeuWkCSRNym6sFVTC2axZ37p8Ezn5xRxitA/OkHCc/phmNDIJedn4PV7J+LoJIjDtqY ZFOMwE3n7FqLbDG2OU3C5x+3u59SYwSKAUMo0xFI06SQ4bQcVE8+8/YM6tTH7VtpcHKI4dG1 91Lu0GsOSR7JmAAAAAAAAA== --------------ms080509020701020106030509-- From mnot@mnot.net Tue Dec 1 22:01:03 2009 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 0C5403A6805 for ; Tue, 1 Dec 2009 22:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 tagged_above=-999 required=5 tests=[AWL=-3.148, 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 vbYCEacWbehl for ; Tue, 1 Dec 2009 22:01:02 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 3C8FE3A67F5 for ; Tue, 1 Dec 2009 22:01:02 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.211.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D82C622E247 for ; Wed, 2 Dec 2009 01:00:47 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: draft-nottingham-http-link-relation-07 progress Date: Wed, 2 Dec 2009 17:00:44 +1100 Message-Id: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> To: Apps Discuss Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 06:01:03 -0000 Based on Last Call feedback, as well as discussions with members of the = HTML5 WG, I've taken another pass at this spec. There's a complete change listing at the end of the spec, as well as a = diff, but the biggest change is in the registry itself; it now allows = extension "fields" to be registered by third parties, to aid in = deploying applications that want to leverage the registry. See: http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt and = http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from-6.dif= f.html Cheers, -- Mark Nottingham http://www.mnot.net/ From eran@hueniverse.com Tue Dec 1 23:30:45 2009 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 524223A6A0D for ; Tue, 1 Dec 2009 23:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 TqYdvc2A84A1 for ; Tue, 1 Dec 2009 23:30:44 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 349853A69EE for ; Tue, 1 Dec 2009 23:30:44 -0800 (PST) Received: (qmail 11798 invoked from network); 2 Dec 2009 07:30:34 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Dec 2009 07:30:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 2 Dec 2009 00:30:32 -0700 From: Eran Hammer-Lahav To: Mark Nottingham Date: Wed, 2 Dec 2009 00:30:42 -0700 Subject: RE: draft-nottingham-http-link-relation-07 progress Thread-Topic: draft-nottingham-http-link-relation-07 progress Thread-Index: AcpzFNHPEcDSgaHYTraEVgsJIZpwFgAAn1kA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209F9C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> In-Reply-To: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> 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: Wed, 02 Dec 2009 07:30:45 -0000 Overall I like the use of 'well-defined' as qualifier instead of 'Commonly-= used', and the fact a registered relation type can be protocol specific. Bu= t the changes take away from the usefulness of the registry by making it a = suggestion, not a requirement for using short relation types. > Section 4 > Link relation types can also be used to indicate that the target=09 > resource has particular attributes, or exhibits particular=09 > behaviours; for example, a "service" link implies that the identified=09 > resource is part of a defined protocol (in this case, a service=09 > description). I would rather make it clear that this is a subjective description in the s= ame way the 'type' attribute is used. Relation types are not the proper way= to provide metadata for *another* resource. > Section 4.1 > > Well-defined relation types SHOULD be registered as tokens for > convenience and to promote reuse. This specification establishes an > IANA registry of such relation types; see Section 6.2. ... > 4.2. Extension Relation Types > > Applications that don't wish to register a relation type may use an > extension relation type, which is a URI [RFC3986] that uniquely > identifies the relation type. This suggests that the entire registry is optional, even for non-URI (exten= sion) relation types. That registration is just a better way of going about= it, but in no way required. The only stick we have to motivate people to r= egister is to say they violate a standard (the carrot is a record in the re= gistry for future fame and glory). With this language, I am not sure why an= yone would bother. Then in section 5: > Note that extension relation types are REQUIRED to be absolute URIs > in Link headers, and MUST be quoted if they contain a semicolon (";") > or comma (","). This suggests that in HTTP Link header, you MUST register short-name relati= on types which contradicts the above SHOULD. Back to 4.2: > Registered relation types MUST NOT constrain the media type of the > context IRI, and MUST NOT constrain the available representation > media types of the target IRI. However, they MAY specify the > behaviours and properties of the target resource (e.g., allowable > methods, request and response media types which must be supported). I am not sure what you mean by "MUST NOT constrain the available representa= tion media types of the target IRI". A registered relation type should be a= ble to mandate a specific target media type, which is how most protocols us= e links. Does this mean a protocol is allowed to limit its use of links wit= h specific 'type' attributes, but not to limit the registration of the rela= tion type to such media types? EHL > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Mark Nottingham > Sent: Tuesday, December 01, 2009 10:01 PM > To: Apps Discuss > Subject: draft-nottingham-http-link-relation-07 progress >=20 > Based on Last Call feedback, as well as discussions with members of the > HTML5 WG, I've taken another pass at this spec. >=20 > There's a complete change listing at the end of the spec, as well as a di= ff, but > the biggest change is in the registry itself; it now allows extension "fi= elds" to > be registered by third parties, to aid in deploying applications that wan= t to > leverage the registry. >=20 > See: > http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt > and > http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from- > 6.diff.html >=20 > Cheers, >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From jpanzer@google.com Tue Dec 1 23:35:56 2009 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 AB2CA3A6A32 for ; Tue, 1 Dec 2009 23:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.942 X-Spam-Level: X-Spam-Status: No, score=-105.942 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZP4DJhNF4A3X for ; Tue, 1 Dec 2009 23:35:55 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 178EE3A6821 for ; Tue, 1 Dec 2009 23:35:54 -0800 (PST) Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id nB27ZiEw022977 for ; Wed, 2 Dec 2009 07:35:45 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259739345; bh=p9oFdtboP4oQ1Vx1SXDWJbvyX3E=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=EBWVPvfE3bpKIni+rJ4hemrLTWnldAjFAPnfJ5cifH1rPlk3ZLL1P3tpURCFyDbId EOG+DLJUA3xrFyQQlwqzA== 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=Q7dGNaFupfT/nlgHl8azLJjBZPtD2y6qMKEY/0fU5ApO9H65KYxYFnhMbD2krgLV1 KCj54GnvSQuDrwGZOYbYA== Received: from pzk39 (pzk39.prod.google.com [10.243.19.167]) by zps36.corp.google.com with ESMTP id nB27Ze6o023845 for ; Tue, 1 Dec 2009 23:35:41 -0800 Received: by pzk39 with SMTP id 39so1148750pzk.15 for ; Tue, 01 Dec 2009 23:35:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.187.3 with SMTP id k3mr13413740waf.82.1259739339530; Tue, 01 Dec 2009 23:35:39 -0800 (PST) In-Reply-To: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> From: John Panzer Date: Tue, 1 Dec 2009 23:33:47 -0800 Message-ID: Subject: Re: draft-nottingham-http-link-relation-07 progress To: Mark Nottingham Content-Type: multipart/alternative; boundary=0016e64cca0cd7a4240479b9eb50 X-System-Of-Record: true Cc: 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: Wed, 02 Dec 2009 07:35:56 -0000 --0016e64cca0cd7a4240479b9eb50 Content-Type: text/plain; charset=ISO-8859-1 Why the change to case-insensitive comparisons for URIs used as link relations? ("When extension relation types are compared, they MUST be compared as URIs in a case-insensitive fashion, character-by-character.") -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Tue, Dec 1, 2009 at 10:00 PM, Mark Nottingham wrote: > Based on Last Call feedback, as well as discussions with members of the > HTML5 WG, I've taken another pass at this spec. > > There's a complete change listing at the end of the spec, as well as a > diff, but the biggest change is in the registry itself; it now allows > extension "fields" to be registered by third parties, to aid in deploying > applications that want to leverage the registry. > > See: > http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt > and > > http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from-6.diff.html > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --0016e64cca0cd7a4240479b9eb50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Why the change to case-insensitive comparisons for URIs used as link r= elations? =A0("When extension relation typ= es are compared, they MUST be compared as URIs in a case-insensitive fashion, charact= er-by-character.")=A0=


--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer



On Tue, Dec 1, 2009 at 10:00 PM, Mark No= ttingham <mnot@mnot.n= et> wrote:
Based on Last Call feedback, as well as discussions with members of the HTM= L5 WG, I've taken another pass at this spec.

There's a complete change listing at the end of the spec, as well as a = diff, but the biggest change is in the registry itself; it now allows exten= sion "fields" to be registered by third parties, to aid in deploy= ing applications that want to leverage the registry.

See:
=A0http://www.mnot.net/drafts/draft-nottingham-http= -link-header-07.txt
and
=A0http://www.mnot.net/drafts/draft-no= ttingham-http-link-header-07-from-6.diff.html

Cheers,

--
Mark Nottingham =A0 =A0 = http://www.mnot.net/

_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--0016e64cca0cd7a4240479b9eb50-- From alexey.melnikov@isode.com Wed Dec 2 02:20:34 2009 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 E26AA3A69FF for ; Wed, 2 Dec 2009 02:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmTz32rZ-3-U for ; Wed, 2 Dec 2009 02:20:34 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D00143A6A73 for ; Wed, 2 Dec 2009 02:20:33 -0800 (PST) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 2 Dec 2009 10:20:25 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4B163F65.305@isode.com> Date: Wed, 02 Dec 2009 10:20:21 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Peter Saint-Andre Subject: Re: * was Re: Server Identity Verification in Application Protocols References: <4AC6786E.2020101@stpeter.im> <001a01ca46a3$ff8377e0$0601a8c0@allison> <4B156275.5040805@stpeter.im> In-Reply-To: <4B156275.5040805@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; 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: Wed, 02 Dec 2009 10:20:35 -0000 Peter Saint-Andre wrote: >My apologies once again for the delayed reply. > >On 10/6/09 4:05 AM, tom.petch wrote: > > >>This specification disallows the use of * to wildcard the reference identity. >> >>syslog over TLS not only uses this, but also allows the use of a wildcard >>where it would not be allowed in the subjectAltName. >> >>I would see this as quite common in networking scenarios, where the access >>is many to many, and so would like a less severe prescription against it. >> >> >One approach would be to allow "profiling" of the rules in this spec. >For example, we could add text such as the following: > >### > >This specification defines several dimensions that are legitimately a >matter of application profiling: > > 1. In the case of domain names, whether the reference identity can >contain the wildcard character '*' (ASCII 42) as the least significant >domain label (e.g., "*.example.com"). > > 2. In the case of domain names, whether the reference identity can >contain the wildcard character '*' (ASCII 42) as one of the characters >in the least significant domain label fragment (e.g., "foo*.example.com"). > > (with a regular participant hat on): I am not sure that the 2nd choice should be recommended at all. But your suggested text looks fine to me otherwise. >Application protocols that re-use this specification rather than define >their own certificate rules need to specify whether they allow wildcards >in the ways just described. > > >### > >We might also want to say that such use of wildcards defaults is "not >allowed" unless otherwise specified by the using protocol. > > This is fine as well. From alexey.melnikov@isode.com Wed Dec 2 02:21:31 2009 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 A012E3A67FB for ; Wed, 2 Dec 2009 02:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 jsikhFoZ70cd for ; Wed, 2 Dec 2009 02:21:30 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 732033A69FF for ; Wed, 2 Dec 2009 02:21:30 -0800 (PST) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 2 Dec 2009 10:21:22 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4B163F9E.50104@isode.com> Date: Wed, 02 Dec 2009 10:21:18 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Peter Saint-Andre Subject: Re: client was Re: Server Identity Verification in Application Protocols References: <4AC6786E.2020101@stpeter.im> <001b01ca46a4$017b0220$0601a8c0@allison> <75930B09-C7DD-46D6-A336-B1A80ADF7CDF@Isode.com> <000401ca476f$f93013e0$0601a8c0@allison> <001501ca4cce$8b359900$0601a8c0@allison> <05CEDCDF-97B5-41C0-9578-BA8030756312@Isode.com> <4B1564AA.4010800@stpeter.im> In-Reply-To: <4B1564AA.4010800@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Kurt Zeilenga , 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, 02 Dec 2009 10:21:31 -0000 Peter Saint-Andre wrote: >On 10/14/09 9:11 AM, Kurt Zeilenga wrote: > > >>I would find it less objectionable for this I-D to simply say something >>like: >> "This document details a process for client verification of the >>server's identity. It is possibly that this process be used in server >>verification of a client's identity, however this document does not >>consider or detail how this might be done." >> >> >After thinking about Kurt's argument further and discussing the topic at >IETF 76, I agree that verification of client identities is out of scope >for this I-D. Interesting problem, but to be discussed elsewhere. > >In my working copy, I have the following text: > > Note: This document applies only to server identities, only to > TLS, and only to the PKI. Similar considerations might apply to > client identities (e.g., for mutual authentication), to security > protocols such as [IPSEC] and [DTLS], and to keys or certificates > created outside the context of the PKI (e.g., where a dependency > on Certificate Revocation Lists or the Online Certificate Status > Protocol might introduce unacceptable latency or denial of service > attacks). Indeed, some aspects of the encapsulation and > verification rules provided in this document might apply to those > scenarios, as well; however, those scenarios are outside the scope > of this document and need to be addressed by separate > specifications. > I like that. From dhc@dcrocker.net Wed Dec 2 06:08:53 2009 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 9322A3A6ACA for ; Wed, 2 Dec 2009 06:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WG2MHW-ZnVCk for ; Wed, 2 Dec 2009 06:08:52 -0800 (PST) Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:20e:2eff:fec8:eb01]) by core3.amsl.com (Postfix) with ESMTP id 63BA33A6A5C for ; Wed, 2 Dec 2009 06:08:52 -0800 (PST) Received: from [192.168.1.104] (adsl-67-127-57-40.dsl.pltn13.pacbell.net [67.127.57.40]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id nB2E8bwa028879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 06:08:42 -0800 Message-ID: <4B1674D8.1080601@dcrocker.net> Date: Wed, 02 Dec 2009 06:08:24 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: client was Re: Server Identity Verification in Application Protocols References: <4AC6786E.2020101@stpeter.im> <001b01ca46a4$017b0220$0601a8c0@allison> <75930B09-C7DD-46D6-A336-B1A80ADF7CDF@Isode.com> <000401ca476f$f93013e0$0601a8c0@allison> <001501ca4cce$8b359900$0601a8c0@allison> <05CEDCDF-97B5-41C0-9578-BA8030756312@Isode.com> <4B1564AA.4010800@stpeter.im> <4B163F9E.50104@isode.com> In-Reply-To: <4B163F9E.50104@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10103/Tue Dec 1 19:59:01 2009 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, 02 Dec 2009 06:08:43 -0800 (PST) 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, 02 Dec 2009 14:08:53 -0000 Alexey Melnikov wrote: >> In my working copy, I have the following text: >> >> Note: This document applies only to server identities, only to >> TLS, and only to the PKI. Similar considerations might apply to >> client identities (e.g., for mutual authentication), to security >> protocols such as [IPSEC] and [DTLS], and to keys or certificates >> created outside the context of the PKI (e.g., where a dependency >> on Certificate Revocation Lists or the Online Certificate Status >> Protocol might introduce unacceptable latency or denial of service >> attacks). Indeed, some aspects of the encapsulation and >> verification rules provided in this document might apply to those >> scenarios, as well; however, those scenarios are outside the scope >> of this document and need to be addressed by separate >> specifications. >> > I like that. The beginning of the paragraph says what is in scope. The second half of the last sentence says that everything else is outside of scope. So it might not be essential to clarify what: "some aspects of the encapsulation and verification rules provided in this document might apply to those scenarios" means, but I do not understand it at all. "aspect applies" seems to be what is causing my confusion. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Sandra.Murphy@cobham.com Tue Dec 1 17:42:27 2009 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 869683A69CE; Tue, 1 Dec 2009 17:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBGM+SvdSS2z; Tue, 1 Dec 2009 17:42:26 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 2CE063A6972; Tue, 1 Dec 2009 17:42:04 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id nB21fr6T009865; Tue, 1 Dec 2009 19:41:53 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nB21fqIh005738; Tue, 1 Dec 2009 19:41:53 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 20:41:52 -0500 Date: Tue, 1 Dec 2009 20:41:51 -0500 (Eastern Standard Time) From: Sandra Murphy To: secdir@ietf.org, mnot@mnot.net, eran@hueniverse.com, apps-discuss@ietf.org Subject: review of draft-nottingham-site-meta-04 Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 02 Dec 2009 01:41:52.0649 (UTC) FILETIME=[9F75B790:01CA72F0] X-Mailman-Approved-At: Wed, 02 Dec 2009 08:03:13 -0800 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 01:42:27 -0000 This is a review of draft-nottingham-site-meta-04 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft defines a new registry for applications that wish to use a well-known URI for some purpose, for example, a URI for a policy or metadata that would be specific to each application site. A registry is needed to prevent conflicts among the URIs defined or conflicts with other resources. I have no security concerns with the draft or the idea of a registry of well-known URIs. Comments: Note that this specification defines neither how to determine the authority to use for a particular context, nor the scope of the metadata discovered by dereferencing the well-known URI; both should be defined by the application itself. I'm not sure what "authority to use for a particular context", but I presume that it means that each application should consider the authorization model of who should have the authority to use the well-known URI at each host/site. This sounds lke a general security concern, but it is not verbatim reflected in the security considerations section (the scope part is mentioned, not the "authority to use".) Note: given that I say below that it would be impossible to be complete in the security concerns that might arise in any particular application, this is NOT a recommendation that the text should change. Security Considerations section As this is a definition of a registry, there's not much to be said about what the security considerations there might be. The section notes two possible security concerns. No statement is made about possible solutions to these security concerns. The first is that access to the server might give an attacker the ability to modify what is stored at the URI. Depending on the application and the way the well-known URI is used, that could represent a security concern, obviously. There's nothing to be said here about solutions, given that the use is still to be defined. The second possibility mentioned is DNS rebinding: Because most URI schemes rely on DNS to resolve names, they are vulnerable to "DNS rebinding" attacks, whereby a request can be directed to a server under the control of an attacker. My understanding is that DNS rebinding allows the attacker to rebind a name it controls to a local address. So it is the directing to a server that is under the control of the attacker, not the server itself. I'm not sure that is what the text here is saying. DNS rebinding here would be a concern if the well-known URI provided some access that would be useful to an attacker. That would be a subject for the application to consider, so I'm not saying that it needs to be mentioned here. Recommendations for protection against DNS rebinding have to do with the browser or the enterprise, not the application, so I don't think they need to be mentioned here. I could see that there might be other ways that the existence of a well-known URI could be a concern, depending on how the application used that file (DDOS if the use caused transmission, exposure if the use caused access to sensitive data, whatever). But I don't think that this document could possibly be complete in discussing all the security concerns these unknown applications with their unknown uses of the URI could have. In general, I think this section could be replaced with just guidelines about what the specification of a new well-known URI should discuss or consider. Consider the authorization model, consider corruption, exposure, etc. of the URI file, consider vulnerability to DNS rebinding attacks, etc. IANA considerations section The draft mentions several things that a specification of a new well-known URI should discuss or include. Is the IANA resonsible for ensuring that a specification for a new well-known URI meets the stipulations made here? Or maybe the Designated Expert does that? --Sandy From algermissen1971@mac.com Wed Dec 2 01:03:53 2009 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 E35A83A6A0F for ; Wed, 2 Dec 2009 01:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.535 X-Spam-Level: X-Spam-Status: No, score=-5.535 tagged_above=-999 required=5 tests=[AWL=-1.936, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb9Wv6dl34P5 for ; Wed, 2 Dec 2009 01:03:52 -0800 (PST) Received: from asmtpout018.mac.com (asmtpout018.mac.com [17.148.16.93]) by core3.amsl.com (Postfix) with ESMTP id C24963A6908 for ; Wed, 2 Dec 2009 01:03:52 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.2.102] ([84.144.115.143]) by asmtp018.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KU0007SSP64M300@asmtp018.mac.com> for discuss@apps.ietf.org; Wed, 02 Dec 2009 01:03:44 -0800 (PST) Message-id: <6DBD3C00-AEAC-4AC8-8263-B97A15FD4903@mac.com> From: Jan Algermissen To: John Panzer In-reply-to: Subject: Re: draft-nottingham-http-link-relation-07 progress Date: Wed, 02 Dec 2009 10:03:40 +0100 References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Wed, 02 Dec 2009 08:03:13 -0800 Cc: 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: Wed, 02 Dec 2009 09:03:54 -0000 On Dec 2, 2009, at 8:33 AM, John Panzer wrote: > Why the change to case-insensitive comparisons for URIs used as link > relations? ("When extension relation types are compared, they MUST > be compared as URIs in a case-insensitive fashion, character-by- > character.") Additional comment: isn't there a spec that can be referenced that specifies URI equality rules? "When extension relation types are compared, they MUST be compared according to the equality rules defined by X" Jan > > > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > > > > On Tue, Dec 1, 2009 at 10:00 PM, Mark Nottingham > wrote: > Based on Last Call feedback, as well as discussions with members of > the HTML5 WG, I've taken another pass at this spec. > > There's a complete change listing at the end of the spec, as well as > a diff, but the biggest change is in the registry itself; it now > allows extension "fields" to be registered by third parties, to aid > in deploying applications that want to leverage the registry. > > See: > http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt > and > http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from-6.diff.html > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -------------------------------------- Jan Algermissen Mail: algermissen@acm.org Blog: http://algermissen.blogspot.com/ Home: http://www.jalgermissen.com -------------------------------------- From eran@hueniverse.com Wed Dec 2 08:30:57 2009 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 E6F0B28C21C for ; Wed, 2 Dec 2009 08:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 meh19PNwTIeH for ; Wed, 2 Dec 2009 08:30:56 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 8384C28C1F9 for ; Wed, 2 Dec 2009 08:30:56 -0800 (PST) Received: (qmail 5703 invoked from network); 2 Dec 2009 16:30:47 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Dec 2009 16:30:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 2 Dec 2009 09:30:20 -0700 From: Eran Hammer-Lahav To: Jan Algermissen , John Panzer Date: Wed, 2 Dec 2009 09:30:30 -0700 Subject: RE: draft-nottingham-http-link-relation-07 progress Thread-Topic: draft-nottingham-http-link-relation-07 progress Thread-Index: AcpzaPZHkoQAs9TARvS7Yr3x4K+DUgAA3oZA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378520A0E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <6DBD3C00-AEAC-4AC8-8263-B97A15FD4903@mac.com> In-Reply-To: <6DBD3C00-AEAC-4AC8-8263-B97A15FD4903@mac.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 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: Wed, 02 Dec 2009 16:30:58 -0000 Unfortunately no. There is no standard way (I'm aware of) to canonicalize a= URI in a consistent way. This is why specs like OAuth have to spell out ho= w to perform percent encoding and other transformations to ensure a consist= ent string. EHL > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Jan Algermissen > Sent: Wednesday, December 02, 2009 1:04 AM > To: John Panzer > Cc: Apps Discuss > Subject: Re: draft-nottingham-http-link-relation-07 progress >=20 >=20 > On Dec 2, 2009, at 8:33 AM, John Panzer wrote: >=20 > > Why the change to case-insensitive comparisons for URIs used as link > > relations? ("When extension relation types are compared, they MUST be > > compared as URIs in a case-insensitive fashion, character-by- > > character.") >=20 > Additional comment: isn't there a spec that can be referenced that specif= ies > URI equality rules? >=20 > "When extension relation types are compared, they MUST be compared > according to the equality rules defined by X" >=20 > Jan >=20 >=20 >=20 > > > > > > -- > > John Panzer / Google > > jpanzer@google.com / abstractioneer.org / @jpanzer > > > > > > > > On Tue, Dec 1, 2009 at 10:00 PM, Mark Nottingham > > wrote: > > Based on Last Call feedback, as well as discussions with members of > > the HTML5 WG, I've taken another pass at this spec. > > > > There's a complete change listing at the end of the spec, as well as a > > diff, but the biggest change is in the registry itself; it now allows > > extension "fields" to be registered by third parties, to aid in > > deploying applications that want to leverage the registry. > > > > See: > > http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt > > and > > > > http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from- > 6 > > .diff.html > > > > Cheers, > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > > Apps-Discuss mailing list > > Apps-Discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > _______________________________________________ > > Apps-Discuss mailing list > > Apps-Discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > -------------------------------------- > Jan Algermissen >=20 > Mail: algermissen@acm.org > Blog: http://algermissen.blogspot.com/ > Home: http://www.jalgermissen.com > -------------------------------------- >=20 >=20 >=20 > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From julian.reschke@gmx.de Wed Dec 2 08:43:51 2009 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 2FC303A6870 for ; Wed, 2 Dec 2009 08:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.666 X-Spam-Level: X-Spam-Status: No, score=-4.666 tagged_above=-999 required=5 tests=[AWL=-2.067, 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 dFEaRl8AUXkF for ; Wed, 2 Dec 2009 08:43:47 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D8F3B3A67AC for ; Wed, 2 Dec 2009 08:43:46 -0800 (PST) Received: (qmail invoked by alias); 02 Dec 2009 16:43:35 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 02 Dec 2009 17:43:35 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19daowtwt9dpjqvNGSE/c7uw6CrjMg2VDoa8rvhuA vK/tWJmLPT5aHo Message-ID: <4B16992E.3050000@gmx.de> Date: Wed, 02 Dec 2009 17:43:26 +0100 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: Eran Hammer-Lahav Subject: Re: draft-nottingham-http-link-relation-07 progress References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <6DBD3C00-AEAC-4AC8-8263-B97A15FD4903@mac.com> <90C41DD21FB7C64BB94121FBBC2E7234378520A0E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378520A0E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.66 Cc: 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: Wed, 02 Dec 2009 16:43:51 -0000 Eran Hammer-Lahav wrote: > Unfortunately no. There is no standard way (I'm aware of) to canonicalize a URI in a consistent way. This is why specs like OAuth have to spell out how to perform percent encoding and other transformations to ensure a consistent string. > ... ? BR, Julian From eran@hueniverse.com Wed Dec 2 10:03:50 2009 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 328323A6912 for ; Wed, 2 Dec 2009 10:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 uks5fZzU0a48 for ; Wed, 2 Dec 2009 10:03:49 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 59E543A68BB for ; Wed, 2 Dec 2009 10:03:49 -0800 (PST) Received: (qmail 21686 invoked from network); 2 Dec 2009 18:03:40 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Dec 2009 18:03:40 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 2 Dec 2009 11:03:34 -0700 From: Eran Hammer-Lahav To: Julian Reschke Date: Wed, 2 Dec 2009 11:03:45 -0700 Subject: RE: draft-nottingham-http-link-relation-07 progress Thread-Topic: draft-nottingham-http-link-relation-07 progress Thread-Index: Acpzbpro7B5en5kvRX+2jqdITi+PxgACtBcw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378520A1E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <6DBD3C00-AEAC-4AC8-8263-B97A15FD4903@mac.com> <90C41DD21FB7C64BB94121FBBC2E7234378520A0E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B16992E.3050000@gmx.de> In-Reply-To: <4B16992E.3050000@gmx.de> 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 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 18:03:50 -0000 It's a good start but not enough. The text itself points out the various pr= oblems with normalization but does not address all of them with normative l= anguage. Normalization must be nothing but a long list of MUSTs and MUST NO= Ts. When we first pointed developers to 3986 for OAuth normalization needs, not= hing worked... EHL > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Wednesday, December 02, 2009 8:43 AM > To: Eran Hammer-Lahav > Cc: Jan Algermissen; John Panzer; Apps Discuss > Subject: Re: draft-nottingham-http-link-relation-07 progress >=20 > Eran Hammer-Lahav wrote: > > Unfortunately no. There is no standard way (I'm aware of) to canonicali= ze a > URI in a consistent way. This is why specs like OAuth have to spell out h= ow to > perform percent encoding and other transformations to ensure a consistent > string. > > ... >=20 > ? >=20 > BR, Julian From mnot@mnot.net Wed Dec 2 17:14:31 2009 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 2916E3A680A for ; Wed, 2 Dec 2009 17:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=-2.699, 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 b155tqKJvFff for ; Wed, 2 Dec 2009 17:14:29 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 734113A6822 for ; Wed, 2 Dec 2009 17:14:25 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.211.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8A25F22E247; Wed, 2 Dec 2009 20:14:06 -0500 (EST) Subject: Re: draft-nottingham-http-link-relation-07 progress Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209F9C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 3 Dec 2009 12:14:03 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <90C41DD21FB7C64BB94121FBBC2E72343785209F9C@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav 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: Thu, 03 Dec 2009 01:14:31 -0000 I think the text is pretty clear; if you don't want to register a = relation type, you need to use an extension relation type, whose syntax = is constrained to that of a URI. I actually am considering getting rid of extension relation types = altogether; we haven't seen them in the wild, and the barriers to = registration are considerably lower. Combine this with the carrot of = machine-readable registry information (with application-specific = fields), and I think there's quite a strong motivation to register. Cheers, On 02/12/2009, at 6:30 PM, Eran Hammer-Lahav wrote: >>=20 >> 4.2. Extension Relation Types >>=20 >> Applications that don't wish to register a relation type may use an >> extension relation type, which is a URI [RFC3986] that uniquely >> identifies the relation type. >=20 > This suggests that the entire registry is optional, even for non-URI = (extension) relation types. That registration is just a better way of = going about it, but in no way required. The only stick we have to = motivate people to register is to say they violate a standard (the = carrot is a record in the registry for future fame and glory). With this = language, I am not sure why anyone would bother. -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Wed Dec 2 17:15:24 2009 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 CA4293A6358 for ; Wed, 2 Dec 2009 17:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.96 X-Spam-Level: X-Spam-Status: No, score=-4.96 tagged_above=-999 required=5 tests=[AWL=-2.361, 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 SLXoRuUH32kC for ; Wed, 2 Dec 2009 17:15:23 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id C17613A683B for ; Wed, 2 Dec 2009 17:15:23 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.211.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 236AE22E255; Wed, 2 Dec 2009 20:15:08 -0500 (EST) Subject: Re: draft-nottingham-http-link-relation-07 progress Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Thu, 3 Dec 2009 12:15:08 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> To: John Panzer X-Mailer: Apple Mail (2.1077) Cc: 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: Thu, 03 Dec 2009 01:15:24 -0000 This was requested by the HTML5 folks, since rel values historically are = case-insensitive. I agree that it feels a bit weird, but it doesn't seem harmful, and is = necessary for backwards compatibility. Cheers, On 02/12/2009, at 6:33 PM, John Panzer wrote: > Why the change to case-insensitive comparisons for URIs used as link = relations? ("When extension relation types are compared, they MUST be = compared as URIs in a case-insensitive fashion, = character-by-character.")=20 >=20 >=20 > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer >=20 >=20 >=20 > On Tue, Dec 1, 2009 at 10:00 PM, Mark Nottingham = wrote: > Based on Last Call feedback, as well as discussions with members of = the HTML5 WG, I've taken another pass at this spec. >=20 > There's a complete change listing at the end of the spec, as well as a = diff, but the biggest change is in the registry itself; it now allows = extension "fields" to be registered by third parties, to aid in = deploying applications that want to leverage the registry. >=20 > See: > http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt > and > = http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from-6.dif= f.html >=20 > Cheers, >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Wed Dec 2 17:16:16 2009 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 D58E53A680A for ; Wed, 2 Dec 2009 17:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[AWL=-2.099, 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 ASlBdStW3UMA for ; Wed, 2 Dec 2009 17:16:16 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 1CEEB3A6358 for ; Wed, 2 Dec 2009 17:16:16 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.211.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0AD5022E247; Wed, 2 Dec 2009 20:16:06 -0500 (EST) Subject: Re: draft-nottingham-http-link-relation-07 progress Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209F9C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 3 Dec 2009 12:16:06 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <90C41DD21FB7C64BB94121FBBC2E72343785209F9C@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav 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: Thu, 03 Dec 2009 01:16:17 -0000 Huh? I don't see how you get that out of that text. On 02/12/2009, at 6:30 PM, Eran Hammer-Lahav wrote: > Then in section 5: >=20 >> Note that extension relation types are REQUIRED to be absolute URIs >> in Link headers, and MUST be quoted if they contain a semicolon = (";") >> or comma (","). >=20 > This suggests that in HTTP Link header, you MUST register short-name = relation types which contradicts the above SHOULD. -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Wed Dec 2 17:17:12 2009 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 28AD23A680A for ; Wed, 2 Dec 2009 17:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.488 X-Spam-Level: X-Spam-Status: No, score=-4.488 tagged_above=-999 required=5 tests=[AWL=-1.889, 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 766T7z0tAS4G for ; Wed, 2 Dec 2009 17:17:11 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 13E793A67B3 for ; Wed, 2 Dec 2009 17:17:11 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.211.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9B6DA22E247; Wed, 2 Dec 2009 20:17:01 -0500 (EST) Subject: Re: draft-nottingham-http-link-relation-07 progress Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209F9C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 3 Dec 2009 12:17:00 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <367DAD8E-C86B-4100-BAD0-067DE6E6FBA2@mnot.net> References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <90C41DD21FB7C64BB94121FBBC2E72343785209F9C@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav 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: Thu, 03 Dec 2009 01:17:12 -0000 It must not constrain them; i.e., it can't say "you can only have these = media types there." This doesn't preclude it from mandating that a = particular type is available. Cheers, On 02/12/2009, at 6:30 PM, Eran Hammer-Lahav wrote: > Back to 4.2: >=20 >> Registered relation types MUST NOT constrain the media type of the >> context IRI, and MUST NOT constrain the available representation >> media types of the target IRI. However, they MAY specify the >> behaviours and properties of the target resource (e.g., allowable >> methods, request and response media types which must be supported). >=20 > I am not sure what you mean by "MUST NOT constrain the available = representation media types of the target IRI". A registered relation = type should be able to mandate a specific target media type, which is = how most protocols use links. Does this mean a protocol is allowed to = limit its use of links with specific 'type' attributes, but not to limit = the registration of the relation type to such media types? -- Mark Nottingham http://www.mnot.net/ From eran@hueniverse.com Wed Dec 2 18:02:41 2009 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 F285728C0E2 for ; Wed, 2 Dec 2009 18:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 XmUD7RkycSvt for ; Wed, 2 Dec 2009 18:02:40 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id A9C5328C0DF for ; Wed, 2 Dec 2009 18:02:39 -0800 (PST) Received: (qmail 31411 invoked from network); 3 Dec 2009 02:02:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Dec 2009 02:02:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 2 Dec 2009 19:02:27 -0700 From: Eran Hammer-Lahav To: Mark Nottingham Date: Wed, 2 Dec 2009 19:01:28 -0700 Subject: RE: draft-nottingham-http-link-relation-07 progress Thread-Topic: draft-nottingham-http-link-relation-07 progress Thread-Index: AcpztjLEAeSle4MyQ42IMGUMkaTVIwABjmEg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378520A45A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <90C41DD21FB7C64BB94121FBBC2E72343785209F9C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 03 Dec 2009 02:02:41 -0000 It was late and I was not paying attention... I read it as 'Non-extension relation...'. EHL > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Wednesday, December 02, 2009 5:16 PM > To: Eran Hammer-Lahav > Cc: apps-discuss@ietf.org > Subject: Re: draft-nottingham-http-link-relation-07 progress >=20 > Huh? I don't see how you get that out of that text. >=20 >=20 > On 02/12/2009, at 6:30 PM, Eran Hammer-Lahav wrote: >=20 > > Then in section 5: > > > >> Note that extension relation types are REQUIRED to be absolute URIs > >> in Link headers, and MUST be quoted if they contain a semicolon (";") > >> or comma (","). > > > > This suggests that in HTTP Link header, you MUST register short-name > relation types which contradicts the above SHOULD. >=20 >=20 > -- > Mark Nottingham http://www.mnot.net/ From eran@hueniverse.com Wed Dec 2 18:05:38 2009 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 3E1543A69A4 for ; Wed, 2 Dec 2009 18:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 ioDFUNMLV6lb for ; Wed, 2 Dec 2009 18:05:37 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 191E93A69B9 for ; Wed, 2 Dec 2009 18:05:37 -0800 (PST) Received: (qmail 31949 invoked from network); 3 Dec 2009 02:05:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Dec 2009 02:05:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 2 Dec 2009 19:05:28 -0700 From: Eran Hammer-Lahav To: Mark Nottingham Date: Wed, 2 Dec 2009 19:05:41 -0700 Subject: RE: draft-nottingham-http-link-relation-07 progress Thread-Topic: draft-nottingham-http-link-relation-07 progress Thread-Index: Acpzte150nirFF2ZSUibnpJfQh/H4AABpy2w Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378520A45C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <90C41DD21FB7C64BB94121FBBC2E72343785209F9C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 03 Dec 2009 02:05:38 -0000 I disagree. You define two classes of relations types and explain their syntax. But you= then make the registration part a SHOULD. It is not clear if the SHOULD is= about the need to register short names, or a guidance on when to consider = not using an extension and registering instead. As for removing the extension type, there are still plenty of cases when a = relation type is so specific, it should not be registered. EHL > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Wednesday, December 02, 2009 5:14 PM > To: Eran Hammer-Lahav > Cc: apps-discuss@ietf.org > Subject: Re: draft-nottingham-http-link-relation-07 progress >=20 > I think the text is pretty clear; if you don't want to register a relatio= n type, > you need to use an extension relation type, whose syntax is constrained t= o > that of a URI. >=20 > I actually am considering getting rid of extension relation types altoget= her; > we haven't seen them in the wild, and the barriers to registration are > considerably lower. Combine this with the carrot of machine-readable > registry information (with application-specific fields), and I think ther= e's quite > a strong motivation to register. >=20 > Cheers, >=20 > On 02/12/2009, at 6:30 PM, Eran Hammer-Lahav wrote: >=20 > >> > >> 4.2. Extension Relation Types > >> > >> Applications that don't wish to register a relation type may use an > >> extension relation type, which is a URI [RFC3986] that uniquely > >> identifies the relation type. > > > > This suggests that the entire registry is optional, even for non-URI > (extension) relation types. That registration is just a better way of goi= ng > about it, but in no way required. The only stick we have to motivate peop= le > to register is to say they violate a standard (the carrot is a record in = the > registry for future fame and glory). With this language, I am not sure wh= y > anyone would bother. >=20 >=20 > -- > Mark Nottingham http://www.mnot.net/ From stpeter@stpeter.im Wed Dec 2 18:35:24 2009 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 9B8DD3A690A for ; Wed, 2 Dec 2009 18:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLVnOAmUDUpq for ; Wed, 2 Dec 2009 18:35:23 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B5C613A6909 for ; Wed, 2 Dec 2009 18:35:23 -0800 (PST) Received: from squire.local (dsl-175-112.dynamic-dsl.frii.net [216.17.175.112]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 06DA440332; Wed, 2 Dec 2009 19:35:14 -0700 (MST) Message-ID: <4B1723E1.9020108@stpeter.im> Date: Wed, 02 Dec 2009 19:35:13 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: * was Re: Server Identity Verification in Application Protocols References: <4AC6786E.2020101@stpeter.im> <001a01ca46a3$ff8377e0$0601a8c0@allison> <4B156275.5040805@stpeter.im> <4B163F65.305@isode.com> In-Reply-To: <4B163F65.305@isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060802060407070600080904" 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, 03 Dec 2009 02:35:24 -0000 This is a cryptographically signed message in MIME format. --------------ms060802060407070600080904 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/2/09 3:20 AM, Alexey Melnikov wrote: > Peter Saint-Andre wrote: > >> My apologies once again for the delayed reply. >> >> On 10/6/09 4:05 AM, tom.petch wrote: >> >> >>> This specification disallows the use of * to wildcard the reference >>> identity. >>> >>> syslog over TLS not only uses this, but also allows the use of a >>> wildcard >>> where it would not be allowed in the subjectAltName. >>> >>> I would see this as quite common in networking scenarios, where the >>> access >>> is many to many, and so would like a less severe prescription against >>> it. >>> >> One approach would be to allow "profiling" of the rules in this spec. >> For example, we could add text such as the following: >> >> ### >> >> This specification defines several dimensions that are legitimately a >> matter of application profiling: >> >> 1. In the case of domain names, whether the reference identity can >> contain the wildcard character '*' (ASCII 42) as the least significant >> domain label (e.g., "*.example.com"). >> >> 2. In the case of domain names, whether the reference identity can >> contain the wildcard character '*' (ASCII 42) as one of the characters >> in the least significant domain label fragment (e.g., >> "foo*.example.com"). >> >> > (with a regular participant hat on): > I am not sure that the 2nd choice should be recommended at all. > But your suggested text looks fine to me otherwise. I tend to agree, but I wasn't sure that we wanted to prohibit the foo* matching because I thought some folks on this list argued for allowing it in some circumstances. I'll check the list archives on this point. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms060802060407070600080904 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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 hvcNAQkFMQ8XDTA5MTIwMzAyMzUxM1owIwYJKoZIhvcNAQkEMRYEFOrSo053Y8X4wPZAXPIi gwEDZJD9MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAkOMbhmm7J224QejXTy/i5c6RvvmXVn4O9W5n8ZBo 6jI8uoymTwlTSjaRpupV1riYyP05owtwCLpmN0MxS9q9ONHnlG4r/K2Twh39G3OwJqltGvc9 jq/ldBNhsrPWQPnocZQA6b/xoU/GeP7JALVdFoRqaf50LaZw51cG4eUwtaJ+PlL048PpgE0R cxlvHs4Bs2qEewdzshk8uHjbBa7aaH5JCw0Wpsd01iyiVh7exJd68rXW+84NquqrAhw5c5/5 AtROFQRb85GwiJ3UkwVMIpF+LW2UsVIEmTaWCwAGneMLq+g2Z393BHEi/cPRUbBRDbLLhTq5 LD/F2+xpTkRNBwAAAAAAAA== --------------ms060802060407070600080904-- From mnot@mnot.net Wed Dec 2 18:49:08 2009 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 9B1483A6926 for ; Wed, 2 Dec 2009 18:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.317 X-Spam-Level: X-Spam-Status: No, score=-4.317 tagged_above=-999 required=5 tests=[AWL=-1.718, 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 Q2mWUXOPkgcR for ; Wed, 2 Dec 2009 18:49:07 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id A779C3A68B4 for ; Wed, 2 Dec 2009 18:49:07 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.211.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 72BA422E1F3 for ; Wed, 2 Dec 2009 21:48:58 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: W3C web security mailing list Date: Thu, 3 Dec 2009 13:48:55 +1100 References: To: Apps Discuss Message-Id: <420C9CB6-5891-4F29-AA5A-4DB96654E1CA@mnot.net> Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 02:49:08 -0000 FYI. See also: http://www.w3.org/Security/wiki/Main_Page Cheers, Begin forwarded message: > Resent-From: ietf-http-wg@w3.org > From: Thomas Roessler > Date: 2 December 2009 1:56:37 AM AEDT > To: Mark Nottingham > Cc: Thomas Roessler , Tyler Close , = HTTP Working Group > Subject: W3C web security mailing list (Re: HTTPbis and the Same = Origin Policy) > archived-at: = >=20 > On 1 Dec 2009, at 04:25, Mark Nottingham wrote: >=20 >> This is important, but as mentioned firmly out of the scope of the = HTTPbis WG.=20 >>=20 >> There's currently a lot of discussion along these lines both at the = IETF and the W3C, and I expect that a new mailing list will be announced = shortly to serve as a home for topics like this. >=20 > That announcement just went out: > = http://lists.w3.org/Archives/Public/public-web-security/2009Dec/0000.html >=20 > You're more than welcome to continue this thread on that list. >=20 > Additionally, here is a wiki page that attempt to collect most of the = reference links that came up in this thread: > http://www.w3.org/Security/wiki/Same_Origin_Policy >=20 >=20 >=20 -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Wed Dec 2 21:49:55 2009 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 3A85F3A68AA; Wed, 2 Dec 2009 21:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[AWL=-1.586, 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 CFniCijyLTdL; Wed, 2 Dec 2009 21:49:54 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 4972D3A6961; Wed, 2 Dec 2009 21:49:18 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.211.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4C35022E1F3; Thu, 3 Dec 2009 00:49:00 -0500 (EST) Subject: Re: review of draft-nottingham-site-meta-04 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Thu, 3 Dec 2009 16:48:57 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sandra Murphy X-Mailer: Apple Mail (2.1077) Cc: apps-discuss@ietf.org, secdir@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, 03 Dec 2009 05:49:55 -0000 Hi Sandra, Responses inline.=20 On 02/12/2009, at 12:41 PM, Sandra Murphy wrote: >=20 > Note that this specification defines neither how to determine the > authority to use for a particular context, nor the scope of the > metadata discovered by dereferencing the well-known URI; both should > be defined by the application itself. >=20 > I'm not sure what "authority to use for a particular context", but I = presume that it means that each application should consider the = authorization model of who should have the authority to use the = well-known URI at each host/site. This sounds lke a general security = concern, but it is not verbatim reflected in the security considerations = section (the scope part is mentioned, not the "authority to use".) = Note: given that I say below that it would be impossible to be complete = in the security concerns that might arise in any particular application, = this is NOT a recommendation that the text should change. Not quite. It's basically saying that, given a particular application = context using arbitrary network resources, it's up to you to determine = what the appropriate URI authority (e.g., 'example.com' in = 'http://www.example.com/.well-known/foo') should be. > The second possibility mentioned is DNS rebinding: >=20 > Because most URI schemes rely on DNS to resolve names, they are > vulnerable to "DNS rebinding" attacks, whereby a request can be > directed to a server under the control of an attacker. >=20 > My understanding is that DNS rebinding allows the attacker to rebind a = name it controls to a local address. So it is the directing to a server = that is under the control of the attacker, not the server itself. I'm = not sure that is what the text here is saying. DNS rebinding here would = be a concern if the well-known URI provided some access that would be = useful to an attacker. That would be a subject for the application to = consider, so I'm not saying that it needs to be mentioned here. >=20 > Recommendations for protection against DNS rebinding have to do with = the browser or the enterprise, not the application, so I don't think = they need to be mentioned here. I agree; DNS rebinding was brought up as a concern during review, but = AIUI it's more of a concern for applications using well-known locations, = if they choose to try to address that problem. It may be that they just = pass a warning upstream to their implementers/users. > I could see that there might be other ways that the existence of a = well-known URI could be a concern, depending on how the application used = that file (DDOS if the use caused transmission, exposure if the use = caused access to sensitive data, whatever). But I don't think that this = document could possibly be complete in discussing all the security = concerns these unknown applications with their unknown uses of the URI = could have. >=20 > In general, I think this section could be replaced with just = guidelines about what the specification of a new well-known URI should = discuss or consider. Consider the authorization model, consider = corruption, exposure, etc. of the URI file, consider vulnerability to = DNS rebinding attacks, etc. I think that's a good suggestion.=20 > IANA considerations section >=20 > The draft mentions several things that a specification of a new = well-known URI should discuss or include. Is the IANA resonsible for = ensuring that a specification for a new well-known URI meets the = stipulations made here? Or maybe the Designated Expert does that? The designated expert. Cheers and thanks for the review, -- Mark Nottingham http://www.mnot.net/ From pjkeane@gmail.com Wed Dec 2 21:53:06 2009 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 587AD3A67D6 for ; Wed, 2 Dec 2009 21:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 MlwxR-R5cyW9 for ; Wed, 2 Dec 2009 21:53:05 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 3E3633A67A6 for ; Wed, 2 Dec 2009 21:53:05 -0800 (PST) Received: by pwi5 with SMTP id 5so49977pwi.29 for ; Wed, 02 Dec 2009 21:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=S67mR0aI/pq9hDQmltx6jRXyFBM7cvk69T4RZYUNYZQ=; b=lkeQbXLyCmiN/DXaMjJ6GI3cYzirIiLBB4lPGWRA90V5spzqV1qzFGW5tQgNkUSCoZ u39AfoM8Xd6lZHEewaAqRJBnDPSGZRjlSq/2sZlffKotFjdA+lZx0kaEbbJS05sLtDbm afo8PdkRnMqKlZwsDd5hOYmZ9vMcyRaILgvYM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=HhS4kKb63YJcClylYcYxDykYaISxmbpczbQ4jqdKlfZ+eI/LtQg6dt+yFYrsxing57 s99+wJvuwPDXdKQ1E1DmpR7N3jvhSixNcT7mHU+qofntKzyZaexQzlU8gkH744HocmHk 0n1OjpNksvllEScHlawQKfBQh6nSjSQBfknZ0= MIME-Version: 1.0 Sender: pjkeane@gmail.com Received: by 10.115.103.23 with SMTP id f23mr1831122wam.226.1259819574655; Wed, 02 Dec 2009 21:52:54 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378520A45C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <90C41DD21FB7C64BB94121FBBC2E72343785209F9C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378520A45C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 2 Dec 2009 23:52:54 -0600 X-Google-Sender-Auth: 09600dc1ebd7eb45 Message-ID: <8158ad750912022152g645b53a3k57e1e328e0dffb23@mail.gmail.com> Subject: Re: draft-nottingham-http-link-relation-07 progress From: Peter Keane To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64cc5b83a7c6d0479cc9a4c 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, 03 Dec 2009 05:53:06 -0000 --0016e64cc5b83a7c6d0479cc9a4c Content-Type: text/plain; charset=UTF-8 On Wed, Dec 2, 2009 at 8:05 PM, Eran Hammer-Lahav wrote: > I disagree. > > You define two classes of relations types and explain their syntax. But you > then make the registration part a SHOULD. It is not clear if the SHOULD is > about the need to register short names, or a guidance on when to consider > not using an extension and registering instead. > > As for removing the extension type, there are still plenty of cases when a > relation type is so specific, it should not be registered. > > +1 (re: v. specific rel types that ought not be registered) --peter keane > EHL > > > -----Original Message----- > > From: Mark Nottingham [mailto:mnot@mnot.net] > > Sent: Wednesday, December 02, 2009 5:14 PM > > To: Eran Hammer-Lahav > > Cc: apps-discuss@ietf.org > > Subject: Re: draft-nottingham-http-link-relation-07 progress > > > > I think the text is pretty clear; if you don't want to register a > relation type, > > you need to use an extension relation type, whose syntax is constrained > to > > that of a URI. > > > > I actually am considering getting rid of extension relation types > altogether; > > we haven't seen them in the wild, and the barriers to registration are > > considerably lower. Combine this with the carrot of machine-readable > > registry information (with application-specific fields), and I think > there's quite > > a strong motivation to register. > > > > Cheers, > > > > On 02/12/2009, at 6:30 PM, Eran Hammer-Lahav wrote: > > > > >> > > >> 4.2. Extension Relation Types > > >> > > >> Applications that don't wish to register a relation type may use an > > >> extension relation type, which is a URI [RFC3986] that uniquely > > >> identifies the relation type. > > > > > > This suggests that the entire registry is optional, even for non-URI > > (extension) relation types. That registration is just a better way of > going > > about it, but in no way required. The only stick we have to motivate > people > > to register is to say they violate a standard (the carrot is a record in > the > > registry for future fame and glory). With this language, I am not sure > why > > anyone would bother. > > > > > > -- > > Mark Nottingham http://www.mnot.net/ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --0016e64cc5b83a7c6d0479cc9a4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 2, 2009 at 8:05 PM, Eran Hammer-= Lahav <eran@hue= niverse.com> wrote:
I disagree.

You define two classes of relations types and explain their syntax. But you= then make the registration part a SHOULD. It is not clear if the SHOULD is= about the need to register short names, or a guidance on when to consider = not using an extension and registering instead.

As for removing the extension type, there are still plenty of cases when a = relation type is so specific, it should not be registered.


+1 (re: v. specific rel t= ypes that ought not be registered)

--peter keane
=C2=A0
EHL

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mn= ot.net]
> Sent: Wednesday, December 02, 2009 5:14 PM
> To: Eran Hammer-Lahav
> Cc: apps-discuss@ietf.org=
> Subject: Re: draft-nottingham-= http-link-relation-07 progress
>
> I think the text is pretty clear; if you don't want to register a = relation type,
> you need to use an extension relation type, whose syntax is constraine= d to
> that of a URI.
>
> I actually am considering getting rid of extension relation types alto= gether;
> we haven't seen them in the wild, and the barriers to registration= are
> considerably lower. Combine this with the carrot of machine-readable > registry information (with application-specific fields), and I think t= here's quite
> a strong motivation to register.
>
> Cheers,
>
> On 02/12/2009, at 6:30 PM, Eran Hammer-Lahav wrote:
>
> >>
> >> 4.2. =C2=A0Extension Relation Types
> >>
> >> =C2=A0Applications that don't wish to register a relation= type may use an
> >> extension relation type, which is a URI [RFC3986] that unique= ly
> >> identifies the relation type.
> >
> > This suggests that the entire registry is optional, even for non-= URI
> (extension) relation types. That registration is just a better way of = going
> about it, but in no way required. The only stick we have to motivate p= eople
> to register is to say they violate a standard (the carrot is a record = in the
> registry for future fame and glory). With this language, I am not sure= why
> anyone would bother.
>
>
> --
> Mark Nottingham =C2=A0 =C2=A0 http://www.mnot.net/

_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--0016e64cc5b83a7c6d0479cc9a4c-- From julian.reschke@gmx.de Thu Dec 3 04:20:49 2009 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 E65E33A68CC for ; Thu, 3 Dec 2009 04:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.634 X-Spam-Level: X-Spam-Status: No, score=-4.634 tagged_above=-999 required=5 tests=[AWL=-2.035, 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 wmvba7No1dv7 for ; Thu, 3 Dec 2009 04:20:49 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B697B3A6826 for ; Thu, 3 Dec 2009 04:20:48 -0800 (PST) Received: (qmail invoked by alias); 03 Dec 2009 12:20:39 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp044) with SMTP; 03 Dec 2009 13:20:39 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18Z/rRpIm0ZJg/CZEOVm3wHqTK6DX3VkNajduD/MC 4Xzj+GH4CF7ioF Message-ID: <4B17AD11.3000205@gmx.de> Date: Thu, 03 Dec 2009 13:20:33 +0100 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: Peter Keane Subject: Re: draft-nottingham-http-link-relation-07 progress References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <90C41DD21FB7C64BB94121FBBC2E72343785209F9C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378520A45C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <8158ad750912022152g645b53a3k57e1e328e0dffb23@mail.gmail.com> In-Reply-To: <8158ad750912022152g645b53a3k57e1e328e0dffb23@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 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, 03 Dec 2009 12:20:50 -0000 Peter Keane wrote: > > On Wed, Dec 2, 2009 at 8:05 PM, Eran Hammer-Lahav > wrote: > > I disagree. > > You define two classes of relations types and explain their syntax. > But you then make the registration part a SHOULD. It is not clear if > the SHOULD is about the need to register short names, or a guidance > on when to consider not using an extension and registering instead. > > As for removing the extension type, there are still plenty of cases > when a relation type is so specific, it should not be registered. > > > +1 (re: v. specific rel types that ought not be registered) > > --peter keane Absolutely. BR, Julian From A.Hoenes@TR-Sys.de Fri Dec 4 04:54:52 2009 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 B85393A6A03; Fri, 4 Dec 2009 04:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.788 X-Spam-Level: * X-Spam-Status: No, score=1.788 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 HFmcp2nVmbUx; Fri, 4 Dec 2009 04:54:51 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id A11E13A68CC; Fri, 4 Dec 2009 04:54:48 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA262591216; Fri, 4 Dec 2009 13:53:36 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id NAA26080; Fri, 4 Dec 2009 13:53:18 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200912041253.NAA26080@TR-Sys.de> Subject: recent change to draft-reschke-rfc2731bis (in IESG) To: julian.reschke@greenbytes.de, jak@ucop.edu Date: Fri, 4 Dec 2009 13:53:17 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: ietf@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, 04 Dec 2009 12:54:52 -0000 Julian, one detail of the recent change leading to draft-reschke-rfc2731bis-05 seems to be ill-advised -- and that is to be taken literally [*]. Whenever a new RFC Obsoletes a previous one, making a *Normative* reference to the obsoleted RFC is nonsensical -- it effectively produces a new normative down-reference; that would be like sitting on the knot you are going to saw off. The "Instructions to RFC Authors" (available from the RFC Editor Homepage) say in Section 2.7 (2nd para): ---- begin quote ---- Within an RFC, references to other documents fall into two general ! categories: "normative" and "informative". Normative references ! specify documents that must be read to understand or implement the ! technology in the new RFC, or whose technology must be present for ! the technology in the new RFC to work. An informative reference is not normative; rather, it provides only additional information. For example, an informative reference might provide background or historical information. Material in an informative reference is not required to implement the technology in the RFC. ---- end quote ---- Making a obsoleting an old document is not compatible with saying in the same new RFC that it depends on the former, that it "must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work.". The hole point of rfc2731bis is to say that RFC 2731 should *not* be used. Therefore, I hope that the DISCUSS [*] that has caused the ref. to RFC 2731 being promoted to Normative can be reconsidered. On the other hand, it seems acceptable to Normatively refer to the current document of origin outside of the IETF that is to be considered as the normative successor of RFC 2731. Hence, in rfc2731bis-05, the following change should be applied (and I hope that the IESG concurs with the "Instructions to RFC Authors"): OLD: +++ |4. Normative References [DC-HTML] Johnston, P. and A. Powell, "Expressing Dublin Core metadata using HTML/XHTML meta and link elements", Dublin Core Metadata Initiative , August 2008, . | [RFC2731] Kunze, J., "Encoding Dublin Core Metadata in HTML", RFC 2731, December 1999. [1] NEW: +++ |4. References | |4.1. Normative References [DC-HTML] Johnston, P. and A. Powell, "Expressing Dublin Core metadata using HTML/XHTML meta and link elements", Dublin Core Metadata Initiative , August 2008, . | |4.2. Informative References | [RFC2731] Kunze, J., "Encoding Dublin Core Metadata in HTML", RFC 2731, December 1999. [1] 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 | +------------------------+--------------------------------------------+ [*] https://datatracker.ietf.org/idtracker/draft-reschke-rfc2731bis/comment/105607/ From Sandra.Murphy@cobham.com Wed Dec 2 22:28:03 2009 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 D1F123A67F5; Wed, 2 Dec 2009 22:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNn5Qw9iOOFe; Wed, 2 Dec 2009 22:28:02 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 95A193A68CF; Wed, 2 Dec 2009 22:28:02 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id nB36RnBX027281; Thu, 3 Dec 2009 00:27:51 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nB36Rlki025044; Thu, 3 Dec 2009 00:27:47 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 01:27:46 -0500 Date: Thu, 3 Dec 2009 01:27:41 -0500 (Eastern Standard Time) From: Sandra Murphy To: Mark Nottingham Subject: Re: review of draft-nottingham-site-meta-04 In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 03 Dec 2009 06:27:46.0806 (UTC) FILETIME=[BA8C1960:01CA73E1] X-Mailman-Approved-At: Fri, 04 Dec 2009 08:12:48 -0800 Cc: apps-discuss@ietf.org, secdir@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, 03 Dec 2009 06:28:04 -0000 On Thu, 3 Dec 2009, Mark Nottingham wrote: > Hi Sandra, > > Responses inline. > > On 02/12/2009, at 12:41 PM, Sandra Murphy wrote: >> >> Note that this specification defines neither how to determine the >> authority to use for a particular context, nor the scope of the >> metadata discovered by dereferencing the well-known URI; both should >> be defined by the application itself. >> >> I'm not sure what "authority to use for a particular context", but I presume that it means that each application should consider the authorization model of who should have the authority to use the well-known URI at each host/site. This sounds lke a general security concern, but it is not verbatim reflected in the security considerations section (the scope part is mentioned, not the "authority to use".) Note: given that I say below that it would be impossible to be complete in the security concerns that might arise in any particular application, this is NOT a recommendation that the text should change. > > Not quite. It's basically saying that, given a particular application context using arbitrary network resources, it's up to you to determine what the appropriate URI authority (e.g., 'example.com' in 'http://www.example.com/.well-known/foo') should be. Ooops, yes, sorry. I forgot when reading that that there is a special meaning for "authority" in this context. > >> The second possibility mentioned is DNS rebinding: >> >> Because most URI schemes rely on DNS to resolve names, they are >> vulnerable to "DNS rebinding" attacks, whereby a request can be >> directed to a server under the control of an attacker. >> >> My understanding is that DNS rebinding allows the attacker to rebind a name it controls to a local address. So it is the directing to a server that is under the control of the attacker, not the server itself. I'm not sure that is what the text here is saying. DNS rebinding here would be a concern if the well-known URI provided some access that would be useful to an attacker. That would be a subject for the application to consider, so I'm not saying that it needs to be mentioned here. >> >> Recommendations for protection against DNS rebinding have to do with the browser or the enterprise, not the application, so I don't think they need to be mentioned here. > > I agree; DNS rebinding was brought up as a concern during review, but AIUI it's more of a concern for applications using well-known locations, if they choose to try to address that problem. It may be that they just pass a warning upstream to their implementers/users. > > >> I could see that there might be other ways that the existence of a well-known URI could be a concern, depending on how the application used that file (DDOS if the use caused transmission, exposure if the use caused access to sensitive data, whatever). But I don't think that this document could possibly be complete in discussing all the security concerns these unknown applications with their unknown uses of the URI could have. >> >> In general, I think this section could be replaced with just guidelines about what the specification of a new well-known URI should discuss or consider. Consider the authorization model, consider corruption, exposure, etc. of the URI file, consider vulnerability to DNS rebinding attacks, etc. > > I think that's a good suggestion. > > >> IANA considerations section >> >> The draft mentions several things that a specification of a new well-known URI should discuss or include. Is the IANA resonsible for ensuring that a specification for a new well-known URI meets the stipulations made here? Or maybe the Designated Expert does that? > > > The designated expert. > > Cheers and thanks for the review, > > -- > Mark Nottingham http://www.mnot.net/ > > From julian.reschke@greenbytes.de Fri Dec 4 05:12:34 2009 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 998DE3A688E; Fri, 4 Dec 2009 05:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 m38EJdA7+31v; Fri, 4 Dec 2009 05:12:32 -0800 (PST) Received: from donbot.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by core3.amsl.com (Postfix) with ESMTP id C83A33A6824; Fri, 4 Dec 2009 05:12:30 -0800 (PST) Received: from [192.168.1.105] (unknown [192.168.1.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by donbot.greenbytes.de (Postfix) with ESMTPSA id D22F3C4C92A; Fri, 4 Dec 2009 14:12:20 +0100 (CET) Message-ID: <4B190AAE.5030907@greenbytes.de> Date: Fri, 04 Dec 2009 14:12:14 +0100 From: Julian Reschke Organization: greenbytes GmbH 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: =?UTF-8?B?QWxmcmVkIO+/vQ==?= Subject: Re: recent change to draft-reschke-rfc2731bis (in IESG) References: <200912041253.NAA26080@TR-Sys.de> In-Reply-To: <200912041253.NAA26080@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 04 Dec 2009 08:12:48 -0800 Cc: jak@ucop.edu, apps-discuss@ietf.org, ietf@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, 04 Dec 2009 13:12:34 -0000 Hi Alfred, I absolutely agree with you. I'll be happy to undo the change if the IESG agrees. Best regards, Julian Alfred � wrote: > Julian, > one detail of the recent change leading to draft-reschke-rfc2731bis-05 > seems to be ill-advised -- and that is to be taken literally [*]. > > Whenever a new RFC Obsoletes a previous one, making a *Normative* > reference to the obsoleted RFC is nonsensical -- it effectively > produces a new normative down-reference; that would be like sitting > on the knot you are going to saw off. > > The "Instructions to RFC Authors" (available from the RFC Editor > Homepage) say in Section 2.7 (2nd para): > > ---- begin quote ---- > Within an RFC, references to other documents fall into two general > ! categories: "normative" and "informative". Normative references > ! specify documents that must be read to understand or implement the > ! technology in the new RFC, or whose technology must be present for > ! the technology in the new RFC to work. An informative reference > is not normative; rather, it provides only additional information. > For example, an informative reference might provide background or > historical information. Material in an informative reference is > not required to implement the technology in the RFC. > ---- end quote ---- > > Making a obsoleting an old document is not compatible with saying > in the same new RFC that it depends on the former, that it "must > be read to understand or implement the technology in the new RFC, > or whose technology must be present for the technology in the > new RFC to work.". > > The hole point of rfc2731bis is to say that RFC 2731 should *not* > be used. Therefore, I hope that the DISCUSS [*] that has caused the > ref. to RFC 2731 being promoted to Normative can be reconsidered. > > On the other hand, it seems acceptable to Normatively refer to the > current document of origin outside of the IETF that is to be > considered as the normative successor of RFC 2731. > > Hence, in rfc2731bis-05, the following change should be applied > (and I hope that the IESG concurs with the "Instructions to > RFC Authors"): > > OLD: > +++ > > |4. Normative References > > [DC-HTML] Johnston, P. and A. Powell, "Expressing Dublin Core > metadata using HTML/XHTML meta and link elements", Dublin > Core Metadata Initiative , August 2008, > . > | > [RFC2731] Kunze, J., "Encoding Dublin Core Metadata in HTML", > RFC 2731, December 1999. > > [1] > > NEW: > +++ > > |4. References > | > |4.1. Normative References > > [DC-HTML] Johnston, P. and A. Powell, "Expressing Dublin Core > metadata using HTML/XHTML meta and link elements", Dublin > Core Metadata Initiative , August 2008, > . > | > |4.2. Informative References > | > [RFC2731] Kunze, J., "Encoding Dublin Core Metadata in HTML", > RFC 2731, December 1999. > > [1] > > > Kind regards, > Alfred H�nes. > -- bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht Münster: HRB5782 From lisa.dusseault@gmail.com Fri Dec 4 16:32:43 2009 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 D88843A65A6 for ; Fri, 4 Dec 2009 16:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, 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 tmA5VHcGCdQj for ; Fri, 4 Dec 2009 16:32:42 -0800 (PST) Received: from mail-vw0-f193.google.com (mail-vw0-f193.google.com [209.85.212.193]) by core3.amsl.com (Postfix) with ESMTP id 999103A68C7 for ; Fri, 4 Dec 2009 16:32:42 -0800 (PST) Received: by vws31 with SMTP id 31so1425260vws.29 for ; Fri, 04 Dec 2009 16:32:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=vn8q7l1THQm5VxfBrrB6/kMO2R9+7u9+5F6+8F79IXE=; b=GjRt8HMIlbcrspWP7gOJ6Mn/ajxhDsrJQnHr2J7AIReWHXwNi3tGF/xSf/KQbFN+1n dKHdjeOkKt/6qD2+YJOrtlW0gedLwfZ3r6YyjOI0Go7+KwuSzvIRfm7jUgnYHxTkHE1k gOMZnRN3RDHvq0HHxVgwUtMPhvAFkDNmsGzZc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=R06S2spiy8xSdgvTz/j4B/gnLOP1VU6T2Vn0aF1cugbduLBpojObydKl2ALKhKj+Bm JSB2vdjX/3Og+mO0cxPsb36sZk0BQs9UR0qRfjfNCOhRmgn25EEMplVHXSvlUKqqFNvV z9+3sWLhQhh5Rq8cP2oxeyOuB7WkGMEF+cSh0= MIME-Version: 1.0 Received: by 10.220.126.165 with SMTP id c37mr5022343vcs.16.1259973149050; Fri, 04 Dec 2009 16:32:29 -0800 (PST) Date: Fri, 4 Dec 2009 16:32:29 -0800 Message-ID: Subject: Lisa's Apps Area Activity Report for Nov 2009 From: Lisa Dusseault To: "Lisa Dusseault's Chairs" , Apps Discuss Content-Type: multipart/alternative; boundary=0016e68f9b63f9ca0e0479f05b70 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 00:32:43 -0000 --0016e68f9b63f9ca0e0479f05b70 Content-Type: text/plain; charset=ISO-8859-1 *News, Updates* APPAREA met in Hiroshima: http://www.ietf.org/proceedings/09nov/minutes/apparea.txt HTTP-STATE WG charter finished IETF review and IESG Evaluation, and waiting on a few edits & input responses HYBI still in chartering process 6LOWAPP still in chartering process W3C Web security mailing list and wiki opened: http://www.w3.org/Security/wiki/Main_Page *Document Status and Progress* *Active documents, my action:* - draft-bryan-metalink (PS): AD Evaluation - draft-ietf-idnabis-bidi (PS): WG is debating last two open issues, post IETF Last Call - draft-ietf-idnabis-protocol (PS): as above - draft-ietf-idnabis-defs (PS): as above - draft-ietf-idnabis-tables (PS): as above - draft-ietf-idnabis-rationale (Info): as above - draft-ietf-idnabis-mappings (Info): as above - draft-freed-sieve-in-xml (PS): Trying to clear last DISCUSS - draft-giralt-schac-ns (Info): Need to get expert review from namespace experts - draft-hammer-oauth (Info): IESG Evaluation, one DISCUSS to clear *Active documents, waiting on other:* - draft-bryan-http-digest-algorithm-values-update (Info): IETF Last Call - draft-larmouth-oid-uri (PS): Revised ID Needed (response to expert review & my own questions) - draft-morg-status-in-list (PS): IESG Evaluation sched for Dec 17 - draft-melnikov-imap-keywords (PS): IESG Evaluation deferred until Dec 17 - draft-nottingham-site-meta (PS): IESG Evaluation deferred until Dec 17 - draft-montemurro-gsma-imei-urn (Exp): New version of draft expected - draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review and writeup - draft-nottingham-http-link- header (PS): Waiting for revision from authors Finished processing -- new in RFC Ed queue and new RFCs RFC 5536: Netnews Article Format RFC5537: Netnews Architecture and Protocols *WG Status* ALTO: adopted draft-penno-alto-protocol as a wg item CALSIFY: WGLC for draft-ietf-calsify-rfc2447bis-07 started HTTPBIS: Resolving direct WG issues one by one; discussing various non-WG issues like cross-site scripting also. IDNABIS: WG hotly debating 2 issues that were reopened by feedback during IETF Last Call. Also made formal request for input from Unicode Technical Committee. OAUTH: Discussing direction of WG at a high level. New drafts promised shortly. SIEVE: no activity --0016e68f9b63f9ca0e0479f05b70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
News, Updates
APPAREA met in Hiroshima: http://w= ww.ietf.org/proceedings/09nov/minutes/apparea.txt
HTTP-STATE WG char= ter finished IETF review and IESG Evaluation, and waiting on a few edits &a= mp; input responses
HYBI still in chartering process
6LOWAPP still in chartering process
= W3C Web security mailing list and wiki opened: http://www.w3.org/Security/wiki= /Main_Page

Document Status and Progress
Active documents, my action:<= br>- draft-bryan-metalink (PS): AD Evaluation
- draft-ietf-idnabis-bidi = (PS): WG is debating last two open issues, post IETF Last Call
- draft-i= etf-idnabis-protocol (PS): as above
- draft-ietf-idnabis-defs (PS): as above
- draft-ietf-idnabis-tables (PS): as above
- draft-ietf-idnabis-rational= e (Info): as above
- draft-ietf-idnabis-mappings (Info): as above
- d= raft-freed-sieve-in-xml (PS): Trying to clear last DISCUSS
- draft-giral= t-schac-ns (Info): Need to get expert review from namespace experts
- draft-hammer-oauth (Info): IESG Evaluation, one DISCUSS to clear

<= br>Active documents, waiting on other:
- draft-bryan-http-digest-= algorithm-values-update (Info): IETF Last Call
- draft-larmouth-oid-uri = (PS): Revised ID Needed (response to expert review & my own questions)<= br> - draft-morg-status-in-list (PS): IESG Evaluation sched for Dec 17
- draft-melnikov-imap-keywords (PS): IESG Evaluation deferred until Dec 17<= br>- draft-nottingham-site-meta (PS): IESG Evaluation deferred until Dec 17=
- draft-montemurro-gsma-imei-urn (Exp): New version of draft expected - draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review and= writeup
- draft-nottingham-http-link-
header (PS): Waiting for revi= sion from authors

Finished processing -- new in RFC Ed queue and new= RFCs
RFC 5536: Netnews Article Format
RFC5537: Netnews Architecture and Proto= cols

WG Status

ALTO: adopted draft-penno-alto-protocol as a wg= item
CALSIFY: WGLC for draft-ietf-calsify-rfc2447bis-07 started
HTTP= BIS: Resolving direct WG issues one by one; discussing various non-WG issue= s like cross-site scripting also.
IDNABIS: WG hotly debating 2 issues that were reopened by feedback during I= ETF Last Call. Also made formal request for input from Unicode Technical Co= mmittee.
OAUTH: Discussing direction of WG at a high level.=A0 New draft= s promised shortly.
SIEVE: no activity


--0016e68f9b63f9ca0e0479f05b70-- From julian.reschke@gmx.de Sun Dec 6 10:33:47 2009 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 191CB3A697D for ; Sun, 6 Dec 2009 10:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.418 X-Spam-Level: X-Spam-Status: No, score=-5.418 tagged_above=-999 required=5 tests=[AWL=-0.819, BAYES_00=-2.599, GB_I_LETTER=-2] 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 m3H26jRmTbrR for ; Sun, 6 Dec 2009 10:33:45 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9BFB33A697C for ; Sun, 6 Dec 2009 10:33:44 -0800 (PST) Received: (qmail invoked by alias); 06 Dec 2009 18:33:32 -0000 Received: from p508FC91B.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.201.27] by mail.gmx.net (mp005) with SMTP; 06 Dec 2009 19:33:32 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+wU9Z6C0Kw355bSZMUsQTnu+Mvzy2FItcfHbbM3c jZUqUHph1DVb9o Message-ID: <4B1BF8FA.2080201@gmx.de> Date: Sun, 06 Dec 2009 19:33:30 +0100 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: Mark Nottingham Subject: Re: draft-nottingham-http-link-relation-07 progress References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> In-Reply-To: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.46 Cc: 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: Sun, 06 Dec 2009 18:33:47 -0000 Mark Nottingham wrote: > Based on Last Call feedback, as well as discussions with members of the HTML5 WG, I've taken another pass at this spec. > > There's a complete change listing at the end of the spec, as well as a diff, but the biggest change is in the registry itself; it now allows extension "fields" to be registered by third parties, to aid in deploying applications that want to leverage the registry. > ... Thanks, Mark. Comments below: 3. Links This specification does not place restrictions on the cardinality of links; there can be multiple links from and to a particular IRI, and multiple links of different types between two given IRIs. Likewise, the relative ordering of links in any particular serialisation, or between serialisations (e.g., the Link header and in-content links) is not specified or significant in this specification; applications that wish to consider ordering significant MAY do so. s/MAX/can/ That being said, see TimBL's comment in . 4.1. Registered Relation Types Well-defined relation types SHOULD be registered as tokens for convenience and to promote reuse. This specification establishes an IANA registry of such relation types; see Section 6.2. Compared to earlier drafts, this seems to suggest that any well-defined relation should be registered. Previously we had "Commonly-used relation types with a clear meaning that are shared across applications can be registered as tokens for convenience and to promote reuse." (draft 06) Is this really a change we want to make? If yes, what would be the feedback for the relations defined by CMIS (currently using extension types), such as "http://docs.oasis-open.org/ns/cmis/link/200908/typedescendants" (see )? 4.2. Extension Relation Types Applications that don't wish to register a relation type may use an extension relation type, which is a URI [RFC3986] that uniquely identifies the relation type. Although the URI MAY point to a resource that contains a definition of the semantics of the relation type, clients SHOULD NOT automatically access that resource to avoid overburdening its server. s/MAY/can/ When extension relation types are compared, they MUST be compared as URIs in a case-insensitive fashion, character-by-character. Should we add guidance about how to mint the URIs then, such as "prefer all-lowercase"? 5. The Link Header Field Each link-value conveys one target IRI as a URI-Reference (after conversion to one, if necessary; see [RFC3987], Section 3.1) inside angle brackets ("<>"). If the URI-Reference is relative, parsers MUST resolve it as per [RFC3986], Section 5. Note that any base IRI from the body's content is not applied. (maybe clarify "body" here) The relation type of a link is conveyed in the "rel" parameter's value. The "rev" parameter has also been used for this purpose historically by some formats, and MAY be accommodated as a link- extension, but its use is neither encouraged nor defined by this specification. Jonathan Rees points out in that this makes it sound as if rev and rel are synonymous. 5.1. Examples NOTE: Non-ASCII characters used in prose for examples are encoded using the format "Backslash-U with Delimiters", defined in Section 5.1 of [RFC5137]. I think this note needs to be removed; it's not true anymore. The example below shows an instance of the Link header encoding multiple links, and also the use of RFC 2231 encoding to encode both non-ASCII characters and language information. Link: ; rel="previous"; title*=UTF-8'de'letztes%20Kapitel, ; rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel Here, the second link has a title encoded in UTF-8, uses the German language ("de"), and contains the Unicode code point U+00E4 ("LATIN SMALL LETTER A WITH DIAERESIS"). "Here, both links have titles encoded in UTF-8, use the German language ("d"), and the second one contains the Unicode code point..." 6.2. Link Relation Type Registry [[ Note to RFC Editor: Entries in the Atom registry that are not listed below at the time that IANA implements this change (i.e., those that are registered before this document comes into effect) should be referred to the Designated Expert. ]] Not sure that the RFC Editor is the right audience here; shouldn't it be the IESG? 6.2.1. Registering new Link Relation Types Within at most 14 days of the request, the Designated Expert will either approve or deny the registration request, communicating this (I think 14 days is really short; if the designated expert lived in Germany, for instance, being on vacation for two weeks in a row wouldn't be THAT exceptional). decision to the review list. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days MAY be brought to the IESG's attention (using the iesg@iesg.org mailing list) for resolution. s/MAY/can/ 7. Security Considerations Applications that take advantage of typed links should consider the attack vectors opened by automatically following, trusting, or otherwise using links gathered from HTTP headers. In particular, Link headers that use the "anchor" parameter to associate a link's context with another resource should be treated with due caution. (maybe the case where anchor is needed on a non-GET response without Content-Location response should be mentioned as a case where anchor actually is needed; maybe this belongs somewhere else though). Appendix B. Notes on Using the Link Header with HTML4 HTML4 also has a "rev" parameter for links that allows a link's relation to be reversed. The Link header does not define a corresponding "rev" parameter to allow the expression of these links in HTTP headers, due to the confusion this mechanism causes as well as conflicting interpretations among HTML versions. I think the part about the "conflicting interpretations" should be explained somewhere for future reference (I'm still not sure I understand it). Individual applications of linking will therefore need to define their extension links should be serialised into HTML4. s/define their/define how their/? That being said, shouldn't we state a default? Best regards, Julian From tatsuhiro.t@gmail.com Wed Dec 9 05:06:56 2009 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 F38D43A69B2 for ; Wed, 9 Dec 2009 05:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+5uvREByLXV for ; Wed, 9 Dec 2009 05:06:54 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id DCD223A696B for ; Wed, 9 Dec 2009 05:06:53 -0800 (PST) Received: by gxk28 with SMTP id 28so6068521gxk.9 for ; Wed, 09 Dec 2009 05:06:40 -0800 (PST) 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:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=TWv800r0A0NbJ4hLPVV4laAOmIqY2q0DU3JWMEeMX08=; b=gCdLeOk07ZTQZzzOSKihSILOtiFvhBmxjHg7JQmaYfbZq16mYvYThrRAxJNhZpWdfU O3c5NJ/hibSF0Zlto2XnkwLTK2ODtPc9NPBepephStnq7CZeDCRB2Dz/y4+9oDAGf1yK hJxnis+CUnxhGUb052cyItwsnVFT9B/T35QNs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=LsYY+ywrn5TOHyLJe0v5LnuJGwZkdeOXcyA4HIuMPTvIYRigixVnFTlirEglpSxedO RGSigTIX763pqogmyNCFYNnQbERBf/VY/FVoZPbjLESP1A1u4ZjLllW+vktt5whEgn0e 1qXgqIvUBdxi/Sy6LCjUg9uZQDjtowDlSNsos= Received: by 10.101.55.11 with SMTP id h11mr2249341ank.50.1260363994959; Wed, 09 Dec 2009 05:06:34 -0800 (PST) Received: from ?192.168.0.11? (kng11-p49.flets.hi-ho.ne.jp [220.156.5.49]) by mx.google.com with ESMTPS id 23sm3459207yxe.54.2009.12.09.05.06.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Dec 2009 05:06:33 -0800 (PST) Message-ID: <4B1FA0D6.80809@gmail.com> Date: Wed, 09 Dec 2009 22:06:30 +0900 From: Tatsuhiro Tsujikawa User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Re: Update regarding draft-bryan-metalink (intro section) X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 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: Wed, 09 Dec 2009 13:06:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, > On Fri, Nov 27, 2009 at 5:11 PM, Peter Pöml wrote: >> >> I'm sending an update to the introductory section of the >> draft-bryan-metalink I-D. The changes are: >> >> - mention the multi-protocol (HTTP, FTP, P2P) nature of Metalinks. >> - describe how verification in Metalinks can solve issues trusting content >> replicas on mirror servers >> - distinguish more clearly between human users and user agents >> - various minor improvements. > > This last week we received some healthy review from Lisa and Eran, > document shepherd. > > We addressed most issues in an interim version that can be found at > http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ > but await clarifications on a few others. > > The other remaining issues: > > 1) Can we use Creative Commons for machine readable alternative to our > license element (Sec 4.2.8)? > Sorry, I don't understand. Do you mean adding new element for "Creative Commons"? What does it look like? > 2) Do we need to use ABNF for the generator element (4.2.4)? > > We talked about using this from HTTP > > product = token ["/" product-version] > product-version = token > I think yes, it is clearer than current form which explains in English text. Or can we borrow it 3.8 Product Tokens from rfc2616 or something similar? > 3) metaurl element's type attribute value (4.2.10.2). It uses MIME > type, but "torrent" is defined. > The thing is application/x-bittorrent is used for BitTorrent's mime type widely but it is not officially registered in IANA, right? I prefer MIME type than inventing new name. > 4) signature element's type attribute value (4.2.15.1). pgp is defined. > Same thing as bittorrent case. I prefer "application/pgp-signature", which sounds like more "official". Using MIME type will be useful when we will add new signature algorithm. We don't have to invent new name. > 5) We allow one or more OS elements. Should we allow one or more > license and language elements? > According to http://www.ietf.org/id/draft-bryan-metalink-24.txt, multiple OS elements are allowed under file element. Some programs are licensed under dual or more licenses, so I think it would be good to allow multiple license elements. For language element, we can use several of them for movies or DVD contents which might be restricted (or partially modified to suite their laws) by region code. One region contains several countries, so multi language elements are nice in this case. > And here is the intro with only a few small changes: > > Metalink is an XML-based document format that describes a file or > list of files to be downloaded from a server. Metalinks can list a > number of files, each with an extensible set of attached metadata. > Each listed file can have a description, checksum, and a list of URIs > that it is available from. > > Often, identical copies of a file are accessible in multiple > locations on the Internet over a variety of protocols (FTP, HTTP, and > Peer-to-Peer). In some cases, users are shown a list of these > multiple download locations (mirror servers) and must manually select > one based on geographical location, priority, or bandwidth. This is > done to distribute the load across multiple servers, and to give > human users the opportunity to choose a download location that they > expect to work best for them. > > At times, individual servers can be slow, outdated, or unreachable, > but this can not be determined until the download has been initiated. > This can lead to the user canceling the download and needing to > restart it. During downloads, errors in transmission can corrupt the > file. There are no easy ways to repair these files. For large > downloads this can be especially troublesome. Any of the number of > problems that can occur during a download lead to frustration on the > part of users, and bandwith wasted with retransmission. > > Knowledge about availability of a download on mirror servers can be > acquired and maintained by the operators of the origin server, or by > third a party. This knowledge, together with checksums, digital > signatures, and more can be stored in a machine-readable Metalink > file. The Metalink file can transfer this knowledge to the user > agent, which can peruse it in automatic ways or present the > information to a human user. User agents can fall back to alternate > mirrors if the current one has an issue. Thereby, clients are > enabled to work their way to a successful download even under adverse > circumstances. All this can be done transparently to the human user > and the download is much more reliable and efficient. In contrast, a > traditional HTTP redirect to one mirror conveys only comparatively > minimal information - a referral to a single server, and there is no > provision in the HTTP protocol to handle failures. > > Other features that some clients provide include multi-source > downloads, where chunks of a file are downloaded from multiple > mirrors (and optionally, Peer-to-Peer) simultaneously, which > frequently results in a faster download. Metalinks can leverage > HTTP, FTP and Peer-to-Peer protocols together, because regardless > over which protocol the Metalink was obtained, it can make a resource > accessible through other protocols. If the Metalink was obtained > > from a trusted source, included verification metadata can solve trust > issues when downloading files from replica servers operated by third > parties. Metalinks also provide structured information about > downloads that can be indexed by search engines. > Looks good for me. I find one typo "bandwith"(Thunderbird found it;) ), I'll fix it in svn. Best regards, Tatsuhiro Tsujikawa -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksfoNYACgkQfoQD1dZzw2ZEbQCg21eW5PNVEJQ1u2CB/P08p1KG o+oAn3uCrqrsgdDat0ZJL+kh16wMHy0E =UiUe -----END PGP SIGNATURE----- From julian.reschke@gmx.de Sun Dec 13 02:16:25 2009 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 09D5D3A6767 for ; Sun, 13 Dec 2009 02:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.16 X-Spam-Level: X-Spam-Status: No, score=-4.16 tagged_above=-999 required=5 tests=[AWL=-1.561, 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 Vp+mLESsDWwk for ; Sun, 13 Dec 2009 02:16:24 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4CEB83A63EB for ; Sun, 13 Dec 2009 02:16:23 -0800 (PST) Received: (qmail invoked by alias); 13 Dec 2009 10:09:30 -0000 Received: from p508FF0CA.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.240.202] by mail.gmx.net (mp051) with SMTP; 13 Dec 2009 11:09:30 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/+JytfgSD+N4ZwE4TJNgdtbGwTckZ34HlkWpYaXD WHVrtXa02SjNDw Message-ID: <4B24BD59.30107@gmx.de> Date: Sun, 13 Dec 2009 11:09:29 +0100 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@ietf.org, Apps Discuss Subject: XML related issues in metalink, was: Last Call: draft-bryan-metalink (The Metalink Download Description Format) to Proposed Standard References: <20091211185920.C2E8D3A6999@core3.amsl.com> In-Reply-To: <20091211185920.C2E8D3A6999@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.54 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 10:16:25 -0000 The IESG wrote: > The IESG has received a request from an individual submitter to consider > the following document: > > - 'The Metalink Download Description Format ' > as a Proposed Standard > ... Hi, I did a quick check on a few XML related issues, and found: 1) References to W3C specs - the references currently use many different formats (for seriesName/value), it would be great if those were consistent (I recommend to use the format used for "REC-xml" for compactness) - the up-to-date check yielded: REC-xml-20060816: [FirstEdition] obsoleted by REC-xml-20081126 REC-xml-infoset-20040204: [REC] ok REC-xml-names-20060816: [FirstEdition] obsoleted by REC-xml-names-20091208 REC-xmlbase-20010627: [FirstEdition] obsoleted by REC-xmlbase-20090128 REC-xmldsig-core-20080610: [REC] ok (where the out-of-date xml-names reference is excused :-). 2) RNC - was there an automated check that the collected RNC and the fragments are in sync? For "metalinkFile" I see a difference in ordering which may indicate that this didn't always happen (the difference appears to be irrelevant, but who knows...) - I found the RNC to miss a few characters (commas, closing braces), which indicates it may not have been checked recently. I recommend to do that, and also to validate the examples in the spec against the RNC. 3) XML vs whitespace I'm not sure I understand the whitespace treatment. One example has: ftp://ftp.example.com/example.ext while the prose says in Section 3: "Note that there MUST NOT be any white space in a Date construct or in any IRI." I personally would prefer that whitespace is NOT ignorable, but in any case this should be stated somewhere more clearly. (Note I didn't review the spec, I just did a few XML related checks) Best regards, Julian From anthonybryan@gmail.com Sun Dec 13 11:34:54 2009 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 B26E73A691D for ; Sun, 13 Dec 2009 11:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.363 X-Spam-Level: X-Spam-Status: No, score=-4.363 tagged_above=-999 required=5 tests=[AWL=-1.764, 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 xIwI4vdkBb3z for ; Sun, 13 Dec 2009 11:34:53 -0800 (PST) Received: from mail-iw0-f197.google.com (mail-iw0-f197.google.com [209.85.223.197]) by core3.amsl.com (Postfix) with ESMTP id 811DB3A6918 for ; Sun, 13 Dec 2009 11:34:53 -0800 (PST) Received: by iwn35 with SMTP id 35so1566898iwn.4 for ; Sun, 13 Dec 2009 11:34:38 -0800 (PST) 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:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jp0FCHJvvnPi32dYyoDdlB4sEOMLfIJyaARrCoMDB3s=; b=JG4yYJ7hjPpjC4HiFT7UggbeN9Q30ZtfYy7ggCi2DlzlioiC+s1H80eYnr0L9l+UVb imdvcRH/rIQPMg3DsI309cqATUrnx5Lo8CLy07dhVp2iLPYW/WWrt2DTDKycvfRaizTa viaxBs/C5dpaoqfVnS3G0i13AALuZrUhmORN4= 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=MwU7MTl/xFkuiHb/dPd4DT4r0CyPCnJVIpUww1dRc1Xu0l0i+UP4xF/6+HN165CI9v qU8tVbGhDxB0BPxdk+PHbcNJIiZQAIBIiThPSKBzT5zfpyaCfp94UQ7MJjRB3sBQyPD1 Ep1NhnFZ0RYcsTEsdviTMR1tlIk3lgaxXeiIw= MIME-Version: 1.0 Received: by 10.231.146.2 with SMTP id f2mr1392007ibv.23.1260732878238; Sun, 13 Dec 2009 11:34:38 -0800 (PST) In-Reply-To: <4B24BD59.30107@gmx.de> References: <20091211185920.C2E8D3A6999@core3.amsl.com> <4B24BD59.30107@gmx.de> Date: Sun, 13 Dec 2009 14:34:38 -0500 Message-ID: Subject: Re: XML related issues in metalink, was: Last Call: draft-bryan-metalink (The Metalink Download Description Format) to Proposed Standard From: Anthony Bryan To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss , ietf@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, 13 Dec 2009 19:34:54 -0000 On Sun, Dec 13, 2009 at 5:09 AM, Julian Reschke wro= te: > The IESG wrote: >> >> The IESG has received a request from an individual submitter to consider >> the following document: >> >> - 'The Metalink Download Description Format ' >> =A0 as a Proposed Standard >> ... > > Hi, > > I did a quick check on a few XML related issues, and found: > > 1) References to W3C specs > > - the references currently use many different formats (for > seriesName/value), it would be great if those were consistent (I recommen= d > to use the format used for "REC-xml" for compactness) > > - the up-to-date check yielded: > > REC-xml-20060816: [FirstEdition] obsoleted by REC-xml-20081126 > REC-xml-infoset-20040204: [REC] ok > REC-xml-names-20060816: [FirstEdition] obsoleted by REC-xml-names-2009120= 8 > REC-xmlbase-20010627: [FirstEdition] obsoleted by REC-xmlbase-20090128 > REC-xmldsig-core-20080610: [REC] ok > > (where the out-of-date xml-names reference is excused :-). These references have been updated and made more consistent. > 2) RNC > > - was there an automated check that the collected RNC and the fragments a= re > in sync? For "metalinkFile" I see a difference in ordering which may > indicate that this didn't always happen (the difference appears to be > irrelevant, but who knows...) > > - I found the RNC to miss a few characters (commas, closing braces), whic= h > indicates it may not have been checked recently. I recommend to do that, = and > also to validate the examples in the spec against the RNC. Fixed. > 3) XML vs whitespace > > I'm not sure I understand the whitespace treatment. > > One example has: > > =A0 =A0 > =A0 =A0 =A0 ftp://ftp.example.com/example.ext > =A0 =A0 > > while the prose says in Section 3: "Note that there MUST NOT be any white > space in a Date construct or in any IRI." > > I personally would prefer that whitespace is NOT ignorable, but in any ca= se > this should be stated somewhere more clearly. Very helpful, your sentence was added: "All leading and trailing whitespace is part of the element content, and MUST be ignored. Consequently, it is disallowed for elements where the defined type does not allow whitespace, such as dates, integers, or IRIs." > (Note I didn't review the spec, I just did a few XML related checks) Thank you, Julian, for these needed checks! Your fresh eyes picked up things unnoticed. "It takes a whole village to raise a spec" :) For those interested, the txt, XML, and html updates in revision 25 are at http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From julian.reschke@gmx.de Sun Dec 13 11:40:17 2009 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 06D333A6864 for ; Sun, 13 Dec 2009 11:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.324 X-Spam-Level: X-Spam-Status: No, score=-4.324 tagged_above=-999 required=5 tests=[AWL=-1.725, 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 TwplyktoIwUT for ; Sun, 13 Dec 2009 11:40:16 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 10C753A67D3 for ; Sun, 13 Dec 2009 11:40:06 -0800 (PST) Received: (qmail invoked by alias); 13 Dec 2009 19:39:40 -0000 Received: from p508FF0CA.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.240.202] by mail.gmx.net (mp049) with SMTP; 13 Dec 2009 20:39:40 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Zou9CC5SZ2nl5Hy5oIovykXUSCC1b3TDqXQ2SfO QEMjWbZq6/j4vj Message-ID: <4B2542F9.5090402@gmx.de> Date: Sun, 13 Dec 2009 20:39:37 +0100 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: Anthony Bryan Subject: Re: XML related issues in metalink, was: Last Call: draft-bryan-metalink (The Metalink Download Description Format) to Proposed Standard References: <20091211185920.C2E8D3A6999@core3.amsl.com> <4B24BD59.30107@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.64 Cc: Apps Discuss , ietf@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, 13 Dec 2009 19:40:17 -0000 Anthony Bryan wrote: >> 3) XML vs whitespace >> >> I'm not sure I understand the whitespace treatment. >> >> One example has: >> >> >> ftp://ftp.example.com/example.ext >> >> >> while the prose says in Section 3: "Note that there MUST NOT be any white >> space in a Date construct or in any IRI." >> >> I personally would prefer that whitespace is NOT ignorable, but in any case >> this should be stated somewhere more clearly. > > Very helpful, your sentence was added: > > "All leading and trailing whitespace is part of the element content, > and MUST be ignored. Consequently, it is disallowed for elements where > the defined type does not allow whitespace, such as dates, integers, > or IRIs." Um, that should be "MUST NOT be ignored", right? > ... BR, Julian From anthonybryan@gmail.com Sun Dec 13 11:47:35 2009 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 D143A3A6929 for ; Sun, 13 Dec 2009 11:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.069 X-Spam-Level: X-Spam-Status: No, score=-4.069 tagged_above=-999 required=5 tests=[AWL=-1.470, 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 hek4UlTkzwqy for ; Sun, 13 Dec 2009 11:47:35 -0800 (PST) Received: from mail-iw0-f197.google.com (mail-iw0-f197.google.com [209.85.223.197]) by core3.amsl.com (Postfix) with ESMTP id 0A6F63A6922 for ; Sun, 13 Dec 2009 11:47:34 -0800 (PST) Received: by iwn35 with SMTP id 35so1570495iwn.4 for ; Sun, 13 Dec 2009 11:47:19 -0800 (PST) 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:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YpjpBqFqY84oav5qpGtLu0ZXvV+tSdC7EQt29jbqXMo=; b=nH/Grmx2I93GixUcimxmXSzfylxZUP7lzpBTJdqu1+dxuLr3EmzyLfgsG803NMHrTy mRgTQopSKMNKt+SY0RMNW6Xq3Oluqk1tZ9ugnr21KdCFnZjntRAYAgWI8CLMk2AsoRXK AQdajGqv/+TYdMMHiC9S6F8Y5dr0q+xaPbURg= 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=Jz4GEi7BbhXqKc/CjPTM5jlJloWlNkn7/sZUiBPKBPoltNLYlnA+utH14FuWa7akcv KCOf5YlivhoB3sLF9S6PgH/6TtOfBmVlw/1GXuCHM5GLbjN+L+xZ8AVz8MMx8EJAxdkV HO4QgLD8AQXcq1VX14yAaNs5Bcmni647CWADo= MIME-Version: 1.0 Received: by 10.231.48.210 with SMTP id s18mr1965970ibf.3.1260733639551; Sun, 13 Dec 2009 11:47:19 -0800 (PST) In-Reply-To: <4B2542F9.5090402@gmx.de> References: <20091211185920.C2E8D3A6999@core3.amsl.com> <4B24BD59.30107@gmx.de> <4B2542F9.5090402@gmx.de> Date: Sun, 13 Dec 2009 14:47:19 -0500 Message-ID: Subject: Re: XML related issues in metalink, was: Last Call: draft-bryan-metalink (The Metalink Download Description Format) to Proposed Standard From: Anthony Bryan To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss , ietf@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, 13 Dec 2009 19:47:35 -0000 On Sun, Dec 13, 2009 at 2:39 PM, Julian Reschke wro= te: > Anthony Bryan wrote: >>> >>> 3) XML vs whitespace >>> >>> I'm not sure I understand the whitespace treatment. >>> >>> One example has: >>> >>> =A0 >>> =A0 =A0 =A0ftp://ftp.example.com/example.ext >>> =A0 >>> >>> while the prose says in Section 3: "Note that there MUST NOT be any whi= te >>> space in a Date construct or in any IRI." >>> >>> I personally would prefer that whitespace is NOT ignorable, but in any >>> case >>> this should be stated somewhere more clearly. >> >> Very helpful, your sentence was added: >> >> "All leading and trailing whitespace is part of the element content, >> and MUST be ignored. Consequently, it is disallowed for elements where >> the defined type does not allow whitespace, such as dates, integers, >> or IRIs." > > Um, that should be "MUST NOT be ignored", right? Fixed. Thanks for re-re-re-re-checking my errors. (That's a full time job). You must want this to come out ok. :) --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From Martin.Thomson@andrew.com Sun Dec 13 15:51:50 2009 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 863273A6970 for ; Sun, 13 Dec 2009 15:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcEZpPBpzKjP for ; Sun, 13 Dec 2009 15:51:50 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 55ADC3A6874 for ; Sun, 13 Dec 2009 15:51:50 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:53442 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S134756AbZLMXrw (ORCPT ); Sun, 13 Dec 2009 17:47:52 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 13 Dec 2009 17:47:52 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 14 Dec 2009 07:47:49 +0800 From: "Thomson, Martin" To: Anthony Bryan , Julian Reschke Date: Mon, 14 Dec 2009 07:48:38 +0800 Subject: RE: XML related issues in metalink, was: Last Call: draft-bryan-metalink (The Metalink Download Description Format) to Proposed Standard Thread-Topic: XML related issues in metalink, was: Last Call: draft-bryan-metalink (The Metalink Download Description Format) to Proposed Standard Thread-Index: Acp8LRnXA4WXBi8rR76V8qiomWJxfAAHOLow Message-ID: <8B0A9FCBB9832F43971E38010638454F01D65BEDB7@SISPE7MB1.commscope.com> References: <20091211185920.C2E8D3A6999@core3.amsl.com> <4B24BD59.30107@gmx.de> <4B2542F9.5090402@gmx.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Apps Discuss , "ietf@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, 13 Dec 2009 23:51:50 -0000 PiA+Pj4gSSdtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGUgd2hpdGVzcGFjZSB0cmVhdG1lbnQu DQo+ID4+Pg0KPiA+Pj4gT25lIGV4YW1wbGUgaGFzOg0KPiA+Pj4NCj4gPj4+IMKgIDx1cmwgbG9j YXRpb249ImRlIiBwcmlvcml0eT0iMSI+DQo+ID4+PiDCoCDCoCDCoGZ0cDovL2Z0cC5leGFtcGxl LmNvbS9leGFtcGxlLmV4dA0KPiA+Pj4gwqAgPC91cmw+CQ0KLi4uDQo+ID4+DQo+ID4+ICJBbGwg bGVhZGluZyBhbmQgdHJhaWxpbmcgd2hpdGVzcGFjZSBpcyBwYXJ0IG9mIHRoZSBlbGVtZW50IGNv bnRlbnQsDQo+ID4+IGFuZCBNVVNUIGJlIGlnbm9yZWQuIENvbnNlcXVlbnRseSwgaXQgaXMgZGlz YWxsb3dlZCBmb3IgZWxlbWVudHMNCj4gd2hlcmUNCj4gPj4gdGhlIGRlZmluZWQgdHlwZSBkb2Vz IG5vdCBhbGxvdyB3aGl0ZXNwYWNlLCBzdWNoIGFzIGRhdGVzLCBpbnRlZ2VycywNCj4gPj4gb3Ig SVJJcy4iDQo+ID4NCj4gPiBVbSwgdGhhdCBzaG91bGQgYmUgIk1VU1QgTk9UIGJlIGlnbm9yZWQi LCByaWdodD8NCj4gDQo+IEZpeGVkLg0KDQpXaHkgaXMgd2hpdGVzcGFjZSBzbyBpbXBvcnRhbnQ/ ICBUaGUgYWx0ZXJuYXRpdmUgdG8gY29uc3RyYWluaW5nIHVzZSBhcyB5b3UgaGF2ZSBkb25lLCB3 aGljaCByZXF1aXJlcyB0aGF0IHlvdSBhbHNvICJmaXgiIGFsbCB0aGUgZXhhbXBsZXMsIGlzIHRv IHVzZSB0aGUgdHlwZSB0aGF0IGZpdHMgYmV0dGVyIHdpdGggdXNlciBleHBlY3RhdGlvbnM6IHRv a2VuLg0KDQpJbiB0aGUgKnZhbHVlIHNwYWNlKiBmb3IgdGhlIHRva2VuIHR5cGUsIHRoZSBhYm92 ZSBleGFtcGxlIGlzIHNpbXBseSAiZnRwOi8vZnRwLmV4YW1wbGUuY29tL2V4YW1wbGUuZXh0Iiwg d2l0aCBsZWFkaW5nIGFuZCB0cmFpbGluZyB3aGl0ZXNwYWNlIHN0cmlwcGVkLg0KDQpUaGVuIHlv dSBjYW4gcmVtb3ZlIHRoZSBmb2xsb3dpbmcgbm90ZToNCiAgIE5vdGUgdGhhdCB0aGVyZSBNVVNU IE5PVCBiZSBhbnkgd2hpdGUgc3BhY2UgaW4gYSBEYXRlIGNvbnN0cnVjdCBvciBpbg0KICAgYW55 IElSSS4gIFNvbWUgWE1MLWdlbmVyYXRpbmcgaW1wbGVtZW50YXRpb25zIGVycm9uZW91c2x5IGlu c2VydA0KICAgd2hpdGUgc3BhY2UgYXJvdW5kIHZhbHVlcyBieSBkZWZhdWx0LCBhbmQgc3VjaCBp bXBsZW1lbnRhdGlvbnMgd2lsbA0KICAgZ2VuZXJhdGUgaW52YWxpZCBNZXRhbGluayBEb2N1bWVu dHMuDQoNCi4uLiBhbmQgd2l0aCBpdCwgYXZvaWQgYWxsIHRoZSBlcnJvcnMgdGhhdCBpbmV2aXRh Ymx5IG9jY3VyIHdoZW4geW91IG1ha2Ugd2hpdGVzcGFjZSBzaWduaWZpY2FudC4gIFVubGVzcyB5 b3UgYmVsaWV2ZSB0aGF0IE1ldGFsaW5rIGRvY3VtZW50cyB3aWxsIG5ldmVyIGJlIGF1dGhvcmVk IGJ5IGFueXRoaW5nIG90aGVyIHRoYW4gc29mdHdhcmUuDQoNCkluIGxvb2tpbmcgaW50byB0aGlz LCBJIG5vdGVkIHRoaXM6DQogICAjIFVuY29uc3RyYWluZWQ7IGl0J3Mgbm90IGVudGlyZWx5IGNs ZWFyIGhvdyBJUkkgZml0IGludG8NCiAgICMgeHNkOmFueVVSSSBzbyBsZXQncyBub3QgdHJ5IHRv IGNvbnN0cmFpbiBpdCBoZXJlDQoNCkkgd29uZGVyIHdoeSB5b3UgaGF2ZW4ndCB0YWtlbiB0aGUg cGx1bmdlIG9uIHhzZDphbnlVUkksIGV2ZW4gaWYgeHNkOmFueVVSSSBoYXMgZHViaW91cyBvZmZp Y2lhbCBzdGF0dXMgd2l0aCByZWdhcmRzIHRvIElSSXMuICBJbiBwcmFjdGljZSwgSVJJcyBhcmUg Y29tbW9ubHkgcGxhY2VkIGluIHhzZDphbnlVUkkuICBUaGUgbGV4aWNhbCBzcGFjZSBhY2NvbW1v ZGF0ZXMgdGhlbSwgbm8gaW1wbGVtZW50YXRpb24gSSdtIGF3YXJlIG9mIHByZXZlbnRzIHVzZSBv ZiBJUklzLg0KDQotLU1hcnRpbg0K From poeml@cmdline.net Sun Dec 13 17:19:31 2009 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 AC81B3A697B for ; Sun, 13 Dec 2009 17:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.558 X-Spam-Level: X-Spam-Status: No, score=0.558 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, HELO_EQ_DE=0.35, 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 6sC1MtSehA1o for ; Sun, 13 Dec 2009 17:19:30 -0800 (PST) Received: from doozer.poeml.de (doozer.poeml.de [83.133.126.38]) by core3.amsl.com (Postfix) with ESMTP id 540443A67D8 for ; Sun, 13 Dec 2009 17:19:30 -0800 (PST) Received: from xdsl-87-79-55-182.netcologne.de ([87.79.55.182] helo=strbske.localdomain) by doozer.poeml.de with esmtpa (Exim 4.71) (envelope-from ) id 1NJzak-0002Et-S4 for apps-discuss@ietf.org; Mon, 14 Dec 2009 02:19:15 +0100 Message-Id: <45A9CE6B-BD31-4A92-B319-BA48913C37E2@cmdline.net> From: =?ISO-8859-1?Q?Peter_P=F6ml?= To: apps-discuss@ietf.org In-Reply-To: <4B1FA0D6.80809@gmail.com> Content-Type: multipart/signed; boundary=Apple-Mail-881--1021491728; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Update regarding draft-bryan-metalink (intro section) Date: Mon, 14 Dec 2009 02:19:09 +0100 References: <4B1FA0D6.80809@gmail.com> X-Mailer: Apple Mail (2.936) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 01:19:31 -0000 --Apple-Mail-881--1021491728 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, (comments inline) Am 09.12.2009 um 14:06 schrieb Tatsuhiro Tsujikawa: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, >> >> We addressed most issues in an interim version that can be found at >> http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ >> but await clarifications on a few others. >> >> The other remaining issues: >> >> 1) Can we use Creative Commons for machine readable alternative to >> our >> license element (Sec 4.2.8)? >> > > Sorry, I don't understand. Do you mean adding new element for > "Creative > Commons"? What does it look like? I also don't understand. Maybe I'm missing some context, but I wonder if there might be misunderstanding? Creative Commons would just be one out of many different licenses that might find their way into the license element. >> 2) Do we need to use ABNF for the generator element (4.2.4)? >> >> We talked about using this from HTTP >> >> product = token ["/" product-version] >> product-version = token >> > > I think yes, it is clearer than current form which explains in > English text. > Or can we borrow it 3.8 Product Tokens from rfc2616 or something > similar? That was where the concept comes from. I agree, using ABNF to achieve more clarity makes sense to me. >> 3) metaurl element's type attribute value (4.2.10.2). It uses MIME >> type, but "torrent" is defined. >> > > The thing is application/x-bittorrent is used for BitTorrent's mime > type > widely but it is not officially registered in IANA, right? > I prefer MIME type than inventing new name. [...] >> 4) signature element's type attribute value (4.2.15.1). pgp is >> defined. >> > > Same thing as bittorrent case. > I prefer "application/pgp-signature", which sounds like more > "official". > Using MIME type will be useful when we will add new signature > algorithm. > We don't have to invent new name. That's a very good idea to use a MIME type here - regardless of the fact that one of them isn't registered! >> 5) We allow one or more OS elements. Should we allow one or more >> license and language elements? >> > > According to http://www.ietf.org/id/draft-bryan-metalink-24.txt, > multiple OS elements are allowed under file element. > Some programs are licensed under dual or more licenses, so I think it > would be good to allow multiple license elements. > > For language element, we can use several of them for movies or DVD > contents which might be restricted (or partially modified to suite > their > laws) by region code. One region contains several countries, so multi > language elements are nice in this case. I agree it can be useful to allow multiple values here. Peter --Apple-Mail-881--1021491728 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILDTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggYoMIIFEKAD AgECAhEArLEHHcSGoVhS08MtvmGcHTANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0wOTExMTMwMDAw MDBaFw0xMDExMTMyMzU5NTlaMIHYMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLUGV0ZXIgUG9lbWwxIDAeBgkqhkiG9w0BCQEWEXBvZW1sQGNt ZGxpbmUubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAng3haq+1ZYwA1TOD3kLv yX1U2ZUuzDtK3L7nMj3I4bCLtxua4Lj+UoO/3BezeD9XoBdrWcwPEP+dWrQAttDqKB+KUJXbRfV2 +cSRDz0Hi5UiubwRlALUQPKqxmwo2x8gUMNUSbxpYnEv+ndW7vlEiGqY+1iDrW0/hgUeTr/B4Wwl eaNaHelxluYnbRTNZLBvACcVagp/3kiEKYtyVM8bHkeogL8a6S+vslbPTHHHKImVvailmGg6dzgQ JlKdhVLjMxEceOq7uvBJhgP28uqPBjJ6kL1X30zS5uh9A1usRWkGcCntHNDloeFxYX02fzHgRsIn 1X72mmmuH2O9uA442QIDAQABo4ICEzCCAg8wHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4E bn0wHQYDVR0OBBYEFOaoAFH8k172pBptvYYJw2Kj1y1FMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMC BSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1 cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9j YS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEig RoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRp b25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNv bW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTAcBgNVHREEFTATgRFwb2VtbEBjbWRsaW5lLm5ldDANBgkqhkiG9w0BAQUFAAOC AQEAaPppK+gaGs+zGbrvKepUx8tKKs4DHALdF0SyDpMGPHS2utUucxyisJNN/TLAHDYtr2sgLE5D bFVMzUMgc0ARe/eY5InTpJAI6L4JN9t4H6VQ9dsEiQdQpQxQvz79UFqgXanAC29dLwgg2YT9jwdR WtDTtK5WlFIxhT1TgfyxRF3/zQGPfhzw0fTqgmVQjm4zxGqDkhvELzNW5assgGJG0XPpxxoFX5UU wMujr13rHFVQ/pAcQsfC/CkNLlDnQQTky3y+8fwjXEbHfB5ysP+DOQlFF9lkyCA1xLCpD7bkYEgS jd+ycXcovZXWJY7nkq2rU1jIZExB9+0T+S92Naa6jDGCA/8wggP7AgEBMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEArLEH HcSGoVhS08MtvmGcHTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wOTEyMTQwMTE5MTBaMCMGCSqGSIb3DQEJBDEWBBSsjisHYmSiLq/n/Fi3 1WJlYTQJ3TCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEArLEHHcSGoVhS08MtvmGcHTCB1wYL KoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMO U2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCssQcdxIahWFLTwy2+YZwdMA0GCSqGSIb3DQEBAQUA BIIBAHsekf5cbqa19sKRPhCsa6cB0T7yGQyccuoAAbv16liIlO4qwEfYNhfBo/PXQ2yJ6PZtCgys rclm1WpyCQVEScNJ5AYHigfHM2SoprY4r2eC1ncat75W8iJglCeK5tvw4TVgy95PdKZgqFe8sX4e 4LMzNEqTqBfxg+CV4SEd4uOWsbTExhWXJlE+KSXgqBj6jIfYAc9R6Qrnouw/AI+dEiIhx98aAAW9 SnTEZkiWyI9aoL3LhuCaMLUwWVl/NEELBMH2wJzntoMOl8RWZqkXnYbOc4Q706FMiBfLR6VWZ4a5 Ai7LKuld+WM1mtjHWYwjg2bZyUOzLB5iACAR6gDsbtQAAAAAAAA= --Apple-Mail-881--1021491728-- From mnot@mnot.net Sun Dec 13 19:29:15 2009 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 97F663A6986 for ; Sun, 13 Dec 2009 19:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.887 X-Spam-Level: X-Spam-Status: No, score=-3.887 tagged_above=-999 required=5 tests=[AWL=-1.288, 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 2Bm+dg3zCWr1 for ; Sun, 13 Dec 2009 19:29:14 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 7B22B3A697E for ; Sun, 13 Dec 2009 19:29:14 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.61.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AA3BC509B4; Sun, 13 Dec 2009 22:28:54 -0500 (EST) Subject: Re: draft-nottingham-http-link-relation-07 progress Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4B1BF8FA.2080201@gmx.de> Date: Mon, 14 Dec 2009 14:28:51 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <78E6189B-66D1-4E38-9F89-31E33ACECD55@mnot.net> References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <4B1BF8FA.2080201@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1077) Cc: 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, 14 Dec 2009 03:29:15 -0000 Thanks, Julian. Most changes made (see links as before), some responses = inline: On 07/12/2009, at 5:33 AM, Julian Reschke wrote: >=20 > 4.1. Registered Relation Types >=20 > Well-defined relation types SHOULD be registered as tokens for > convenience and to promote reuse. This specification establishes an > IANA registry of such relation types; see Section 6.2. >=20 > Compared to earlier drafts, this seems to suggest that any = well-defined > relation should be registered. Previously we had >=20 > "Commonly-used relation types with a clear meaning that are shared > across applications can be registered as tokens for convenience and > to promote reuse." (draft 06) >=20 > Is this really a change we want to make? Thinking about this, I've come to a point where I have a hard time = justifying segregating the different types of relations. Much of the = demand for typed links seems to be for very specific relations, and = indeed a "good" relation is very tightly defined. As such, it's = difficult to say -- even for the Designated Expert, much less a = prospective relation author -- whether something is going to be commonly = used. Arbitrarily relegating application-specific relations to = extensions (with all of the negative connotations that brings -- = justified or not) doesn't seem to solve as many problems as it = potentially causes. > If yes, what would be the feedback > for the relations defined by CMIS (currently using extension types), = such > as "http://docs.oasis-open.org/ns/cmis/link/200908/typedescendants" = (see > = )? They need to be well-defined; some of them look like they are (at a = glance), and some do not (e.g., the 'changes' one seems quite muddy, on = the face of it). Beyond that, if I were DE, I'd probably ask for some of = them to be prefixed by 'cmis' to assure that they're not grabbing = potentially more generic semantics. Thoughts? > 6.2.1. Registering new Link Relation Types >=20 > Within at most 14 days of the request, the Designated Expert will > either approve or deny the registration request, communicating this >=20 > (I think 14 days is really short; if the designated expert lived in = Germany, for instance, being on vacation for two weeks in a row wouldn't = be THAT exceptional). This is why "Designated Expert(s)" is specified; the intent being that = there are at least two, mostly to assure that the deadline is met. Cheers, -- Mark Nottingham http://www.mnot.net/ From eran@hueniverse.com Sun Dec 13 23:05:54 2009 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 1C41B3A67B6 for ; Sun, 13 Dec 2009 23:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.072 X-Spam-Level: X-Spam-Status: No, score=-3.072 tagged_above=-999 required=5 tests=[AWL=-0.473, 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 KK9Y-4XIcylq for ; Sun, 13 Dec 2009 23:05:52 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id DCCFE3A688C for ; Sun, 13 Dec 2009 23:05:52 -0800 (PST) Received: (qmail 13069 invoked from network); 14 Dec 2009 07:05:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Dec 2009 07:05:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 14 Dec 2009 00:05:38 -0700 From: Eran Hammer-Lahav To: Mark Nottingham , Julian Reschke Date: Mon, 14 Dec 2009 00:05:40 -0700 Subject: RE: draft-nottingham-http-link-relation-07 progress Thread-Topic: draft-nottingham-http-link-relation-07 progress Thread-Index: Acp8bZcEqZXG6F2OQImvo/y1VdsnLgAHQrpA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343787C35074@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <4B1BF8FA.2080201@gmx.de> <78E6189B-66D1-4E38-9F89-31E33ACECD55@mnot.net> In-Reply-To: <78E6189B-66D1-4E38-9F89-31E33ACECD55@mnot.net> 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 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 07:05:54 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Mark Nottingham > Sent: Sunday, December 13, 2009 7:29 PM > To: Julian Reschke > Cc: Apps Discuss > Subject: Re: draft-nottingham-http-link-relation-07 progress >=20 > Thanks, Julian. Most changes made (see links as before), some responses > inline: >=20 > On 07/12/2009, at 5:33 AM, Julian Reschke wrote: > > > > 4.1. Registered Relation Types > > > > Well-defined relation types SHOULD be registered as tokens for > > convenience and to promote reuse. This specification establishes an > > IANA registry of such relation types; see Section 6.2. > > > > Compared to earlier drafts, this seems to suggest that any > > well-defined relation should be registered. Previously we had > > > > "Commonly-used relation types with a clear meaning that are shared > > across applications can be registered as tokens for convenience and > > to promote reuse." (draft 06) > > > > Is this really a change we want to make? >=20 > Thinking about this, I've come to a point where I have a hard time justif= ying > segregating the different types of relations. Much of the demand for type= d > links seems to be for very specific relations, and indeed a "good" relati= on is > very tightly defined. As such, it's difficult to say -- even for the Desi= gnated > Expert, much less a prospective relation author -- whether something is > going to be commonly used. Arbitrarily relegating application-specific > relations to extensions (with all of the negative connotations that bring= s -- > justified or not) doesn't seem to solve as many problems as it potentiall= y > causes. I would justify the two types of relations by their different review "cost"= . If someone doesn't want to bother with the registration process, and is s= atisfied with using a URI, let them. There are many cases in which a regist= ration would be an overkill or inappropriate (intranet applications, experi= mental, short-lived, undocumented or semi-private, etc.).=20 On the other hand, by providing a path to a registered short-name we encour= age better definition, documentation, and seeking community review. Even if= the relation type isn't commonly used, it provides a public documentation = of the use case. I also agree that it is hard to prove something is going t= o be widely useful. >=20 > > If yes, what would be the feedback > > for the relations defined by CMIS (currently using extension types), > > such as > > "http://docs.oasis-open.org/ns/cmis/link/200908/typedescendants" (see > v1.0.html#_Toc243712631>)? >=20 > They need to be well-defined; some of them look like they are (at a glanc= e), > and some do not (e.g., the 'changes' one seems quite muddy, on the face o= f > it). Beyond that, if I were DE, I'd probably ask for some of them to be > prefixed by 'cmis' to assure that they're not grabbing potentially more > generic semantics. >=20 > Thoughts? Maybe some recommendation in the spec about naming conventions? Something a= long the lines of non-novel names should not be used for very narrow cases. As long as the extension type is still available, I am supportive of this n= ew well-defined approach. But we might need to give the DE a bit more to wo= rk with. EHL From eran@hueniverse.com Sun Dec 13 23:11:04 2009 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 4E2F13A6994 for ; Sun, 13 Dec 2009 23:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[AWL=-0.619, 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 mRHJCC-RcA7b for ; Sun, 13 Dec 2009 23:11:03 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 78CD33A688C for ; Sun, 13 Dec 2009 23:11:03 -0800 (PST) Received: (qmail 18339 invoked from network); 14 Dec 2009 07:10:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Dec 2009 07:10:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 14 Dec 2009 00:10:50 -0700 From: Eran Hammer-Lahav To: =?iso-8859-1?Q?Peter_P=F6ml?= , "apps-discuss@ietf.org" Date: Mon, 14 Dec 2009 00:10:52 -0700 Subject: RE: Update regarding draft-bryan-metalink (intro section) Thread-Topic: Update regarding draft-bryan-metalink (intro section) Thread-Index: Acp8W3g1YNgcTZ8uT76W2unHj1TN1gAMIL5w Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343787C35076@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B1FA0D6.80809@gmail.com> <45A9CE6B-BD31-4A92-B319-BA48913C37E2@cmdline.net> In-Reply-To: <45A9CE6B-BD31-4A92-B319-BA48913C37E2@cmdline.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 07:11:04 -0000 > >> 1) Can we use Creative Commons for machine readable alternative to > >> our license element (Sec 4.2.8)? > >> > > > > Sorry, I don't understand. Do you mean adding new element for > > "Creative Commons"? What does it look like? >=20 > I also don't understand. Maybe I'm missing some context, but I wonder if > there might be misunderstanding? Creative Commons would just be one out > of many different licenses that might find their way into the license ele= ment. There seems to be value in supporting a machine-readable copyright element = in addition to the human-readable element you have today. It might just be = that we are not ready at this point to offer a list of token-identified lic= enses. But if most metalink implementations today already default to a smal= l set of licenses (MIT, BSD, etc.), is it worth defining such a list? EHL From julian.reschke@gmx.de Mon Dec 14 01:00:42 2009 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 A94493A680C for ; Mon, 14 Dec 2009 01:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.031 X-Spam-Level: X-Spam-Status: No, score=-4.031 tagged_above=-999 required=5 tests=[AWL=-2.032, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2buBnQT8Obio for ; Mon, 14 Dec 2009 01:00:41 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 71BA33A6809 for ; Mon, 14 Dec 2009 01:00:41 -0800 (PST) Received: (qmail invoked by alias); 14 Dec 2009 09:00:26 -0000 Received: from p508FC071.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.192.113] by mail.gmx.net (mp061) with SMTP; 14 Dec 2009 10:00:26 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/o3BREEQ7oCItSS6lwpMVuOCLUl9Z1MH/ZDcAbfa CaX8fPLaMyYo0h Message-ID: <4B25FEA8.5050408@gmx.de> Date: Mon, 14 Dec 2009 10:00:24 +0100 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: "Thomson, Martin" Subject: Re: XML related issues in metalink, was: Last Call: draft-bryan-metalink (The Metalink Download Description Format) to Proposed Standard References: <20091211185920.C2E8D3A6999@core3.amsl.com> <4B24BD59.30107@gmx.de> <4B2542F9.5090402@gmx.de> <8B0A9FCBB9832F43971E38010638454F01D65BEDB7@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F01D65BEDB7@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Cc: Apps Discuss , "ietf@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, 14 Dec 2009 09:00:42 -0000 Thomson, Martin wrote: > Why is whitespace so important? The alternative to constraining use as you have done, which requires that you also "fix" all the examples, is to use the type that fits better with user expectations: token. IMHO, what's important is to decide, to specify it properly, and to have examples consistent with it. And, optimally, test cases. > In the *value space* for the token type, the above example is simply "ftp://ftp.example.com/example.ext", with leading and trailing whitespace stripped. > > Then you can remove the following note: > Note that there MUST NOT be any white space in a Date construct or in > any IRI. Some XML-generating implementations erroneously insert > white space around values by default, and such implementations will > generate invalid Metalink Documents. > > ... and with it, avoid all the errors that inevitably occur when you make whitespace significant. Unless you believe that Metalink documents will never be authored by anything other than software. Well, by making it non-significant, you'll might get interop problems as well. > In looking into this, I noted this: > # Unconstrained; it's not entirely clear how IRI fit into > # xsd:anyURI so let's not try to constrain it here > > I wonder why you haven't taken the plunge on xsd:anyURI, even if xsd:anyURI has dubious official status with regards to IRIs. In practice, IRIs are commonly placed in xsd:anyURI. The lexical space accommodates them, no implementation I'm aware of prevents use of IRIs. I'll assume it's inherited from RFC 4287, and that the Atom WG had good reasons not to use xsd:anyURI... Best regards, Julian From julian.reschke@gmx.de Mon Dec 14 06:48:07 2009 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 9206D3A67E4 for ; Mon, 14 Dec 2009 06:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.787 X-Spam-Level: X-Spam-Status: No, score=-4.787 tagged_above=-999 required=5 tests=[AWL=-2.188, 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 2oaj6xqE5gSO for ; Mon, 14 Dec 2009 06:48:06 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1D0143A62C1 for ; Mon, 14 Dec 2009 06:48:05 -0800 (PST) Received: (qmail invoked by alias); 14 Dec 2009 14:47:51 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp027) with SMTP; 14 Dec 2009 15:47:51 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18mOx1IIqwmh8CQsT55KpW99WXNaxbjENftz1jBho uSyFmBHPJ58ihf Message-ID: <4B265015.3080208@gmx.de> Date: Mon, 14 Dec 2009 15:47:49 +0100 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: Mark Nottingham Subject: Re: draft-nottingham-http-link-relation-07 progress References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <4B1BF8FA.2080201@gmx.de> <78E6189B-66D1-4E38-9F89-31E33ACECD55@mnot.net> In-Reply-To: <78E6189B-66D1-4E38-9F89-31E33ACECD55@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: 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, 14 Dec 2009 14:48:07 -0000 Mark Nottingham wrote: > ... > On 07/12/2009, at 5:33 AM, Julian Reschke wrote: >> 4.1. Registered Relation Types >> >> Well-defined relation types SHOULD be registered as tokens for >> convenience and to promote reuse. This specification establishes an >> IANA registry of such relation types; see Section 6.2. >> >> Compared to earlier drafts, this seems to suggest that any well-defined >> relation should be registered. Previously we had >> >> "Commonly-used relation types with a clear meaning that are shared >> across applications can be registered as tokens for convenience and >> to promote reuse." (draft 06) >> >> Is this really a change we want to make? > > Thinking about this, I've come to a point where I have a hard time justifying segregating the different types of relations. Much of the demand for typed links seems to be for very specific relations, and indeed a "good" relation is very tightly defined. As such, it's difficult to say -- even for the Designated Expert, much less a prospective relation author -- whether something is going to be commonly used. Arbitrarily relegating application-specific relations to extensions (with all of the negative connotations that brings -- justified or not) doesn't seem to solve as many problems as it potentially causes. Two thoughts: - If we move from "must be of general use" to "almost anything goes", then I'm expecting many more attempts of registering short names. Are the DEs willing to handle that load? - Furthermore, this appears to be a rather big change compared to what earlier drafts said, so I think we'd need to go back to IETF LC. >> If yes, what would be the feedback >> for the relations defined by CMIS (currently using extension types), such >> as "http://docs.oasis-open.org/ns/cmis/link/200908/typedescendants" (see >> )? > > They need to be well-defined; some of them look like they are (at a glance), and some do not (e.g., the 'changes' one seems quite muddy, on the face of it). Beyond that, if I were DE, I'd probably ask for some of them to be prefixed by 'cmis' to assure that they're not grabbing potentially more generic semantics. > > Thoughts? > ... It's a bit ironic in that's exactly how CMIS started something like one year ago, until we told them that they should either use extension relations, or make the relations more generic :-). Best regards, Julian From lisa.dusseault@gmail.com Mon Dec 14 10:22:55 2009 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 6BC6E3A6A1C for ; Mon, 14 Dec 2009 10:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 258WULAus42U for ; Mon, 14 Dec 2009 10:22:54 -0800 (PST) Received: from mail-vw0-f193.google.com (mail-vw0-f193.google.com [209.85.212.193]) by core3.amsl.com (Postfix) with ESMTP id 73E513A6860 for ; Mon, 14 Dec 2009 10:22:54 -0800 (PST) Received: by vws31 with SMTP id 31so924786vws.29 for ; Mon, 14 Dec 2009 10:22:38 -0800 (PST) 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:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8oGySRAY5bAklRbVyha47ZwT1AIDeMkFLoK6iSN/M38=; b=qle8JTzT8hAy86qM0k85+3e6WzCAzVjcnsmoNr4mKyra93LodXpL/N+gL2b+3wgw97 a4Crhn1fqawsna11BTXz7kESmFxEVrGKeXGjbqr/3n+mIR2mCtaDzKf+7lzzjp0Q+OCb KDfnOQuycR3hbYmAvFgAiSkRGSmbCZIwync4o= 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=BOClTwP5RDZ5qkn5g+8agzo2p1V9qHK30T9uSO13Y0A9UZtku+X67rMud8JaJLHVNo wVoTRJQQ72awPPgPbfk9zqN1onI6jxzpnuj3dob4wcKRH4Sk+XE2ArbdBaMD26lyEhuw 9UJn1qgh5rJuFm4dYcPQyTlLuj7brUBsSKpMM= MIME-Version: 1.0 Received: by 10.220.124.223 with SMTP id v31mr979728vcr.29.1260814958594; Mon, 14 Dec 2009 10:22:38 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343787C35076@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B1FA0D6.80809@gmail.com> <45A9CE6B-BD31-4A92-B319-BA48913C37E2@cmdline.net> <90C41DD21FB7C64BB94121FBBC2E72343787C35076@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 14 Dec 2009 10:22:38 -0800 Message-ID: Subject: Re: Update regarding draft-bryan-metalink (intro section) From: Lisa Dusseault To: Eran Hammer-Lahav 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, 14 Dec 2009 18:22:55 -0000 Such a list could well be broadly useful, and certainly not limited just to this application. In the last 3.5 years I've seen at least three of our own standards that could have used token-identified licenses or copyright statements, and there are probably other non-IETF documents (W3C or other schemas) that could use just the same tokens. Lisa On Sun, Dec 13, 2009 at 11:10 PM, Eran Hammer-Lahav w= rote: >> >> 1) Can we use Creative Commons for machine readable alternative to >> >> our license element (Sec 4.2.8)? >> >> >> > >> > Sorry, I don't understand. Do you mean adding new element for >> > "Creative Commons"? What does it look like? >> >> I also don't understand. Maybe I'm missing some context, but I wonder if >> there might be misunderstanding? Creative Commons would just be one out >> of many different licenses that might find their way into the license el= ement. > > There seems to be value in supporting a machine-readable copyright elemen= t in addition to the human-readable element you have today. It might just b= e that we are not ready at this point to offer a list of token-identified l= icenses. But if most metalink implementations today already default to a sm= all set of licenses (MIT, BSD, etc.), is it worth defining such a list? > > EHL > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From eran@hueniverse.com Mon Dec 14 11:28:28 2009 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 4006428C14E for ; Mon, 14 Dec 2009 11:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.064 X-Spam-Level: X-Spam-Status: No, score=-3.064 tagged_above=-999 required=5 tests=[AWL=-0.465, 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 QrqdGEWUnoBL for ; Mon, 14 Dec 2009 11:28:26 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id DC8D728C148 for ; Mon, 14 Dec 2009 11:28:26 -0800 (PST) Received: (qmail 1360 invoked from network); 14 Dec 2009 19:28:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Dec 2009 19:28:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 14 Dec 2009 12:28:13 -0700 From: Eran Hammer-Lahav To: Lisa Dusseault Date: Mon, 14 Dec 2009 12:28:16 -0700 Subject: RE: Update regarding draft-bryan-metalink (intro section) Thread-Topic: Update regarding draft-bryan-metalink (intro section) Thread-Index: Acp86mwdHB4oD64cS12ipYQwCBAOHgACRpOg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343787C351EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B1FA0D6.80809@gmail.com> <45A9CE6B-BD31-4A92-B319-BA48913C37E2@cmdline.net> <90C41DD21FB7C64BB94121FBBC2E72343787C35076@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="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: Mon, 14 Dec 2009 19:28:28 -0000 I am happy to draft an I-D for such a registry if there is interest. EHL > -----Original Message----- > From: Lisa Dusseault [mailto:lisa.dusseault@gmail.com] > Sent: Monday, December 14, 2009 10:23 AM > To: Eran Hammer-Lahav > Cc: Peter P=F6ml; apps-discuss@ietf.org > Subject: Re: Update regarding draft-bryan-metalink (intro section) >=20 > Such a list could well be broadly useful, and certainly not limited just = to this > application. In the last 3.5 years I've seen at least three of our own s= tandards > that could have used token-identified licenses or copyright statements, a= nd > there are probably other non-IETF documents (W3C or other schemas) that > could use just the same tokens. >=20 > Lisa >=20 > On Sun, Dec 13, 2009 at 11:10 PM, Eran Hammer-Lahav > wrote: > >> >> 1) Can we use Creative Commons for machine readable alternative to > >> >> our license element (Sec 4.2.8)? > >> >> > >> > > >> > Sorry, I don't understand. Do you mean adding new element for > >> > "Creative Commons"? What does it look like? > >> > >> I also don't understand. Maybe I'm missing some context, but I wonder > >> if there might be misunderstanding? Creative Commons would just be > >> one out of many different licenses that might find their way into the > license element. > > > > There seems to be value in supporting a machine-readable copyright > element in addition to the human-readable element you have today. It migh= t > just be that we are not ready at this point to offer a list of token-iden= tified > licenses. But if most metalink implementations today already default to a > small set of licenses (MIT, BSD, etc.), is it worth defining such a list? > > > > EHL > > _______________________________________________ > > Apps-Discuss mailing list > > Apps-Discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > From poeml@cmdline.net Mon Dec 14 18:03:21 2009 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 99D483A6948; Mon, 14 Dec 2009 18:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_36=0.6, 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 UT2zXDIHB53B; Mon, 14 Dec 2009 18:03:20 -0800 (PST) Received: from doozer.poeml.de (doozer.poeml.de [83.133.126.38]) by core3.amsl.com (Postfix) with ESMTP id 7CCBF3A6941; Mon, 14 Dec 2009 18:03:20 -0800 (PST) Received: from xdsl-78-34-247-150.netcologne.de ([78.34.247.150] helo=strbske.localdomain) by doozer.poeml.de with esmtpa (Exim 4.71) (envelope-from ) id 1NKMkg-0001Wn-LH; Tue, 15 Dec 2009 03:03:02 +0100 Message-Id: From: =?ISO-8859-1?Q?Peter_P=F6ml?= To: "Thomson, Martin" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F01D65BEDB7@SISPE7MB1.commscope.com> Content-Type: multipart/signed; boundary=Apple-Mail-1113--932464016; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: XML related issues in metalink, was: Last Call: draft-bryan-metalink (The Metalink Download Description Format) to Proposed Standard Date: Tue, 15 Dec 2009 03:02:57 +0100 References: <20091211185920.C2E8D3A6999@core3.amsl.com> <4B24BD59.30107@gmx.de> <4B2542F9.5090402@gmx.de> <8B0A9FCBB9832F43971E38010638454F01D65BEDB7@SISPE7MB1.commscope.com> X-Mailer: Apple Mail (2.936) Cc: Apps Discuss , "ietf@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, 15 Dec 2009 02:03:21 -0000 --Apple-Mail-1113--932464016 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Martin, Am 14.12.2009 um 00:48 schrieb Thomson, Martin: >>>>> I'm not sure I understand the whitespace treatment. >>>>> >>>>> One example has: >>>>> >>>>> >>>>> ftp://ftp.example.com/example.ext >>>>> > ... >>>> >>>> "All leading and trailing whitespace is part of the element >>>> content, >>>> and MUST be ignored. Consequently, it is disallowed for elements >> where >>>> the defined type does not allow whitespace, such as dates, >>>> integers, >>>> or IRIs." >>> >>> Um, that should be "MUST NOT be ignored", right? >> >> Fixed. > > Why is whitespace so important? The alternative to constraining use > as you have done, which requires that you also "fix" all the > examples, is to use the type that fits better with user > expectations: token. > > In the *value space* for the token type, the above example is simply > "ftp://ftp.example.com/example.ext", with leading and trailing > whitespace stripped. > > Then you can remove the following note: > Note that there MUST NOT be any white space in a Date construct or > in > any IRI. Some XML-generating implementations erroneously insert > white space around values by default, and such implementations will > generate invalid Metalink Documents. > > ... and with it, avoid all the errors that inevitably occur when you > make whitespace significant. Unless you believe that Metalink > documents will never be authored by anything other than software. > > In looking into this, I noted this: > # Unconstrained; it's not entirely clear how IRI fit into > # xsd:anyURI so let's not try to constrain it here > > I wonder why you haven't taken the plunge on xsd:anyURI, even if > xsd:anyURI has dubious official status with regards to IRIs. In > practice, IRIs are commonly placed in xsd:anyURI. The lexical space > accommodates them, no implementation I'm aware of prevents use of > IRIs. Thanks for the interesting suggestion. Thought about it for a while, asked some people, but now I think that what matters most is that it's clearly specified, as Julian pointed out. I now think it's fine as it is. We still have to fix the examples. I'll do it now in svn. Peter --Apple-Mail-1113--932464016 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILDTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggYoMIIFEKAD AgECAhEArLEHHcSGoVhS08MtvmGcHTANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0wOTExMTMwMDAw MDBaFw0xMDExMTMyMzU5NTlaMIHYMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLUGV0ZXIgUG9lbWwxIDAeBgkqhkiG9w0BCQEWEXBvZW1sQGNt ZGxpbmUubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAng3haq+1ZYwA1TOD3kLv yX1U2ZUuzDtK3L7nMj3I4bCLtxua4Lj+UoO/3BezeD9XoBdrWcwPEP+dWrQAttDqKB+KUJXbRfV2 +cSRDz0Hi5UiubwRlALUQPKqxmwo2x8gUMNUSbxpYnEv+ndW7vlEiGqY+1iDrW0/hgUeTr/B4Wwl eaNaHelxluYnbRTNZLBvACcVagp/3kiEKYtyVM8bHkeogL8a6S+vslbPTHHHKImVvailmGg6dzgQ JlKdhVLjMxEceOq7uvBJhgP28uqPBjJ6kL1X30zS5uh9A1usRWkGcCntHNDloeFxYX02fzHgRsIn 1X72mmmuH2O9uA442QIDAQABo4ICEzCCAg8wHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4E bn0wHQYDVR0OBBYEFOaoAFH8k172pBptvYYJw2Kj1y1FMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMC BSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1 cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9j YS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEig RoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRp b25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNv bW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTAcBgNVHREEFTATgRFwb2VtbEBjbWRsaW5lLm5ldDANBgkqhkiG9w0BAQUFAAOC AQEAaPppK+gaGs+zGbrvKepUx8tKKs4DHALdF0SyDpMGPHS2utUucxyisJNN/TLAHDYtr2sgLE5D bFVMzUMgc0ARe/eY5InTpJAI6L4JN9t4H6VQ9dsEiQdQpQxQvz79UFqgXanAC29dLwgg2YT9jwdR WtDTtK5WlFIxhT1TgfyxRF3/zQGPfhzw0fTqgmVQjm4zxGqDkhvELzNW5assgGJG0XPpxxoFX5UU wMujr13rHFVQ/pAcQsfC/CkNLlDnQQTky3y+8fwjXEbHfB5ysP+DOQlFF9lkyCA1xLCpD7bkYEgS jd+ycXcovZXWJY7nkq2rU1jIZExB9+0T+S92Naa6jDGCA/8wggP7AgEBMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEArLEH HcSGoVhS08MtvmGcHTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wOTEyMTUwMjAyNTdaMCMGCSqGSIb3DQEJBDEWBBT5KnTPDGwdIb5PQfYF Lv4G9UgmpTCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEArLEHHcSGoVhS08MtvmGcHTCB1wYL KoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMO U2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCssQcdxIahWFLTwy2+YZwdMA0GCSqGSIb3DQEBAQUA BIIBAE1J0b0age0+4ijuLydkAAEfGUUw+ndjBkjIjqsndUuOkVu1Zt6BlSoOvAPhOtfVom+QrOO7 9K58hjUSktcFmgnrCKGX4AelvoPE0aly7u8lURKfQn8+2UoP50vlQuL+HbB3iD0Xuu3JS1OsH92p BhbIuEEl8pYIEahH+pYuRfR5dbllm8+XHvcQ6Pt01yJuB7y+SKtxklUs86jC7eepDkiKy98Lk2/j zh5mYpkvU4FUCGrw13yGYn4Ud4vEygjdRYUj5LRNGIBGGar4QHdSHAJWNBFkaeO++4o09mYpmM1H Gb3NzMZQflnYv0x2zfuhC+YTeTxJxXMyo8ltq193Ao8AAAAAAAA= --Apple-Mail-1113--932464016-- From anthonybryan@gmail.com Mon Dec 14 19:18:30 2009 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 5ECA73A691A for ; Mon, 14 Dec 2009 19:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.956 X-Spam-Level: X-Spam-Status: No, score=-3.956 tagged_above=-999 required=5 tests=[AWL=-1.357, 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 E1GGwSUlz3uT for ; Mon, 14 Dec 2009 19:18:28 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 682A13A6856 for ; Mon, 14 Dec 2009 19:18:28 -0800 (PST) Received: by iwn33 with SMTP id 33so2478142iwn.29 for ; Mon, 14 Dec 2009 19:18:12 -0800 (PST) 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:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ezAGxwImF63ckeRQHC71J3bnovlxQ7zmnxtU4cetEY4=; b=UDhgfSaC5UcWODF8NRpwSo+T/myalzKySDCG50IAqTOLeF7fYIpDDWzXOnr33dF5hf KdjJPPuVDgeSMHvdv3un4WgcoCMaQNfN5yOWMmIOHWtzpfG8Hje/gsXwkjIHWBtfS34U WahP4wGKEUjhAr/FscdZuebbb+bIJyjZo/MUo= 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=K0WtrbzPTdEKdKLFhXIfowwPQP5YXdFRmqo2quBcn8Cq+jVLwoNqXYmmZxZvLrP062 hfgi33zgFKXCRPpZzYpu+csG+b4gSy2JA9zLeHdwQYa95OblCre1wE+lPVa4YGlH27gz LmjgxOzx1tnT7JKNCzk4/dkrDxaim3CF2Z/24= MIME-Version: 1.0 Received: by 10.231.120.84 with SMTP id c20mr659888ibr.47.1260847092646; Mon, 14 Dec 2009 19:18:12 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343787C35076@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B1FA0D6.80809@gmail.com> <45A9CE6B-BD31-4A92-B319-BA48913C37E2@cmdline.net> <90C41DD21FB7C64BB94121FBBC2E72343787C35076@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 14 Dec 2009 22:18:12 -0500 Message-ID: Subject: Re: Update regarding draft-bryan-metalink (intro section) From: Anthony Bryan To: Eran Hammer-Lahav 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: Tue, 15 Dec 2009 03:18:30 -0000 On Mon, Dec 14, 2009 at 2:10 AM, Eran Hammer-Lahav wr= ote: >> >> 1) Can we use Creative Commons for machine readable alternative to >> >> our license element (Sec 4.2.8)? >> >> >> > >> > Sorry, I don't understand. Do you mean adding new element for >> > "Creative Commons"? What does it look like? >> >> I also don't understand. Maybe I'm missing some context, but I wonder if >> there might be misunderstanding? Creative Commons would just be one out >> of many different licenses that might find their way into the license el= ement. > > There seems to be value in supporting a machine-readable copyright elemen= t in addition to the human-readable element you have today. It might just b= e that we are not ready at this point to offer a list of token-identified l= icenses. But if most metalink implementations today already default to a sm= all set of licenses (MIT, BSD, etc.), is it worth defining such a list? Here are some that Metalink Editor lets users select. Unknown Commercial Shareware Public Domain GNU GPL 3, http://www.gnu.org/licenses/gpl.html GNU LGPL 3, http://www.gnu.org/licenses/lgpl.html GNU FDL 1.3, http://www.gnu.org/licenses/fdl.html Creative Common Public Domain, http://creativecommons.org/licenses/publicdo= main/ Creative Commons Music Sharing, http://creativecommons.org/licenses/by-nc-nd/2.0/deed-music Creative Commons Dev Nations (deprecated), http://creativecommons.org/licenses/devnations/2.0/ Creative Commons by-nc-nd, http://creativecommons.org/licenses/by-nc-nd/2.5= / Creative Commons by-nc-sa, http://creativecommons.org/licenses/by-nc-sa/3.0= / Creative Commons by-nc, http://creativecommons.org/licenses/by-nc/3.0/ Creative Commons by-nd, http://creativecommons.org/licenses/by-nd/2.5/ Creative Commons by-sa, http://creativecommons.org/licenses/by-sa/2.5/ Creative Commons by, http://creativecommons.org/licenses/by/2.5/ Creative Commons Sampling (deprecated), http://creativecommons.org/licenses/sampling/1.0/ Creative Commons Sampling+, http://creativecommons.org/licenses/sampling+/1= .0/ Creative Commons nc-sampling+, http://creativecommons.org/licenses/nc-sampling+/1.0/ BSD, http://opensource.org/licenses/bsd-license.php MIT, http://opensource.org/licenses/mit-license.php MPL 1.0, http://opensource.org/licenses/mozilla1.0.php MPL 1.1, http://opensource.org/licenses/mozilla1.1.php AFL 3.0, http://opensource.org/licenses/afl-3.0.php OSL 3.0, http://opensource.org/licenses/osl-3.0.php zlib/libpng, http://opensource.org/licenses/zlib-license.php Artistic License 1.0, http://opensource.org/licenses/artistic-license-1.0.p= hp Artistic License 2.0, http://opensource.org/licenses/artistic-license-2.0.p= hp --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From anthonybryan@gmail.com Mon Dec 14 19:24:53 2009 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 637C63A693F for ; Mon, 14 Dec 2009 19:24:53 -0800 (PST) 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.410, 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 PNXg1LRXnfm9 for ; Mon, 14 Dec 2009 19:24:52 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 61E523A67AE for ; Mon, 14 Dec 2009 19:24:52 -0800 (PST) Received: by iwn33 with SMTP id 33so2481101iwn.29 for ; Mon, 14 Dec 2009 19:24:36 -0800 (PST) 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:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IaI6jsFyNAZ5Yz6A2dmp0XoMVddz/LWQPdgYhQFdTQQ=; b=JS33/44t0A3UcE2EM0X2fT2Gw3Ik/wYvoYK0yDTxZ6t1XynTLuW10vxA+YXpKwIzgH B1HyY4EvUpSrSwyUvjO2xHY1ZR28Ges80LgHk+qb/Jj/GBfaM9Q6rzu9GeRATH8B1Pi2 wvVOGZBnqSfczLrTCVwMscL3JWKUX43Ybfe44= 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=q40BHa7FzhfMowRyyRsIZdWtu57mSqdCT/qjmm0Vtfq0p4K0s0sUbNpiwLISwAEiIZ u3hVgktZsKQbIYa3kHRPjlAsKau276Bswspy4RXG2nzWSYTcJA5qZJWHAe2DCjynW5gS +bJpGiS4ek2PtsBLSBmt6RHt2EPUW7WxHzuzc= MIME-Version: 1.0 Received: by 10.231.125.19 with SMTP id w19mr615717ibr.8.1260847476545; Mon, 14 Dec 2009 19:24:36 -0800 (PST) In-Reply-To: <45A9CE6B-BD31-4A92-B319-BA48913C37E2@cmdline.net> References: <4B1FA0D6.80809@gmail.com> <45A9CE6B-BD31-4A92-B319-BA48913C37E2@cmdline.net> Date: Mon, 14 Dec 2009 22:24:36 -0500 Message-ID: Subject: Re: Update regarding draft-bryan-metalink (intro section) From: Anthony Bryan To: =?ISO-8859-1?Q?Peter_P=F6ml?= 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: Tue, 15 Dec 2009 03:24:53 -0000 On Sun, Dec 13, 2009 at 8:19 PM, Peter P=F6ml wrote: > Hi, > > (comments inline) > > Am 09.12.2009 um 14:06 schrieb Tatsuhiro Tsujikawa: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >>> >>> We addressed most issues in an interim version that can be found at >>> http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ >>> but await clarifications on a few others. >>> >>> The other remaining issues: >>> >>> 1) Can we use Creative Commons for machine readable alternative to our >>> license element (Sec 4.2.8)? >>> >> >> Sorry, I don't understand. Do you mean adding new element for "Creative >> Commons"? What does it look like? > > I also don't understand. Maybe I'm missing some context, but I wonder if > there might be misunderstanding? Creative Commons would just be one out o= f > many different licenses that might find their way into the license elemen= t. My fault for not explaining. Creative Commons offers machine readable license info. >From what I can tell, this was in RDF ( http://xml.coverpages.org/CCommons-RDF-Schema200212.html ) but don't know if that's active anymore. It looks like they are using RDFa, embedded in HTML now so this no longer applies to us: http://wiki.creativecommons.org/RDFa >>> 2) Do we need to use ABNF for the generator element (4.2.4)? >>> >>> We talked about using this from HTTP >>> >>> =A0 =A0 product =A0 =A0 =A0 =A0 =3D token ["/" product-version] >>> =A0 =A0 product-version =3D token >>> >> >> I think yes, it is clearer than current form which explains in English >> text. >> Or can we borrow it 3.8 Product Tokens from rfc2616 or something similar= ? > > That was where the concept comes from. I agree, using ABNF to achieve mor= e > clarity makes sense to me. Great, can you add that? >>> 3) metaurl element's type attribute value (4.2.10.2). It uses MIME >>> type, but "torrent" is defined. >>> >> >> The thing is application/x-bittorrent is used for BitTorrent's mime type >> widely but it is not officially registered in IANA, right? >> I prefer MIME type than inventing new name. > > [...] >>> >>> 4) signature element's type attribute value (4.2.15.1). pgp is defined. >>> >> >> Same thing as bittorrent case. >> I prefer "application/pgp-signature", which sounds like more "official". >> Using MIME type will be useful when we will add new signature algorithm. >> We don't have to invent new name. > > That's a very good idea to use a MIME type here - regardless of the fact > that one of them isn't registered! To answer Tatsuhiro, correct, BitTorrent's MIME type is not officially registered, so some people are against allowing that. P2P, in general, seems to move fast & not worry about standardization much. For digital signatures, we can probably count on them having registered MIME types - if they use them. >>> 5) We allow one or more OS elements. Should we allow one or more >>> license and language elements? >>> >> >> According to http://www.ietf.org/id/draft-bryan-metalink-24.txt, >> multiple OS elements are allowed under file element. >> Some programs are licensed under dual or more licenses, so I think it >> would be good to allow multiple license elements. >> >> For language element, we can use several of them for movies or DVD >> contents which might be restricted (or partially modified to suite their >> laws) by region code. One region contains several countries, so multi >> language elements are nice in this case. > > I agree it can be useful to allow multiple values here. Ok. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From duerst@it.aoyama.ac.jp Mon Dec 14 21:12:03 2009 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 70F1E3A6848 for ; Mon, 14 Dec 2009 21:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_00=-2.599, 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 dv1AogP-hQMv for ; Mon, 14 Dec 2009 21:12:00 -0800 (PST) Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id E21D63A680B for ; Mon, 14 Dec 2009 21:11:54 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id nBF5BT6n020927 for ; Tue, 15 Dec 2009 14:11:39 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 034d_4d989ad2_e938_11de_a8ee_001d096c5782; Tue, 15 Dec 2009 14:11:29 +0900 Received: from [IPv6:::1] ([133.2.210.1]:54784) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 15 Dec 2009 14:11:29 +0900 Message-ID: <4B271A78.80002@it.aoyama.ac.jp> Date: Tue, 15 Dec 2009 14:11:20 +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.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Eran Hammer-Lahav Subject: Re: draft-nottingham-http-link-relation-07 progress References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <6DBD3C00-AEAC-4AC8-8263-B97A15FD4903@mac.com> <90C41DD21FB7C64BB94121FBBC2E7234378520A0E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B16992E.3050000@gmx.de> <90C41DD21FB7C64BB94121FBBC2E7234378520A1E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378520A1E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Apps Discuss , "public-iri@w3.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, 15 Dec 2009 05:12:03 -0000 I agree that RFC 3986 (and RFC 3987) are not of direct use for defining anything like a normalization of URIs (or IRIs). The main reason for this is that there are different contexts in which you may have different knowledge (e.g. of scheme specific default ports) and may prefer aggressive or cautionary normalization. The safe side of the normalization range is on different ends depending on what you are doing. As we are working on an update to RFC 3987, what I'm wondering is whether it may be possible to improve the text in RFC 3987 (which is mostly a copy of the one in RFC 3986, with some additions due to the bigger character repertoire) so that it becomes easier for an application such as OAuth to define what they need just with a few pointers (e.g. "from Section X of the IRI spec, use foo, baz, and frof normalizations but not bar") rather than defining everything ab initio. Would that help? Or does nobody care? Regards, Martin. On 2009/12/03 3:03, Eran Hammer-Lahav wrote: > It's a good start but not enough. The text itself points out the various problems with normalization but does not address all of them with normative language. Normalization must be nothing but a long list of MUSTs and MUST NOTs. > > When we first pointed developers to 3986 for OAuth normalization needs, nothing worked... > > EHL > >> -----Original Message----- >> From: Julian Reschke [mailto:julian.reschke@gmx.de] >> Sent: Wednesday, December 02, 2009 8:43 AM >> To: Eran Hammer-Lahav >> Cc: Jan Algermissen; John Panzer; Apps Discuss >> Subject: Re: draft-nottingham-http-link-relation-07 progress >> >> Eran Hammer-Lahav wrote: >>> Unfortunately no. There is no standard way (I'm aware of) to canonicalize a >> URI in a consistent way. This is why specs like OAuth have to spell out how to >> perform percent encoding and other transformations to ensure a consistent >> string. >>> ... >> >> ? >> >> BR, Julian > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From mnot@mnot.net Mon Dec 14 21:51:58 2009 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 E94E83A67E1 for ; Mon, 14 Dec 2009 21:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.744 X-Spam-Level: X-Spam-Status: No, score=-3.744 tagged_above=-999 required=5 tests=[AWL=-1.145, 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 hd9BLyRlQ+ra for ; Mon, 14 Dec 2009 21:51:58 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 0AC603A672E for ; Mon, 14 Dec 2009 21:51:57 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.61.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D0150509B4; Tue, 15 Dec 2009 00:51:37 -0500 (EST) Subject: Re: draft-nottingham-http-link-relation-07 progress Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4B265015.3080208@gmx.de> Date: Tue, 15 Dec 2009 16:51:34 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <4B1BF8FA.2080201@gmx.de> <78E6189B-66D1-4E38-9F89-31E33ACECD55@mnot.net> <4B265015.3080208@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1077) Cc: 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: Tue, 15 Dec 2009 05:51:59 -0000 On 15/12/2009, at 1:47 AM, Julian Reschke wrote: >=20 > Two thoughts: >=20 > - If we move from "must be of general use" to "almost anything goes", = then I'm expecting many more attempts of registering short names. Are = the DEs willing to handle that load? Since they're not selected yet, it's hard to say. However, "almost = anything goes" isn't a good characterisation; it's still specification = required... > - Furthermore, this appears to be a rather big change compared to what = earlier drafts said, so I think we'd need to go back to IETF LC. We've had enough changes that I think that's going to be necessary = anyway. >>> If yes, what would be the feedback >>> for the relations defined by CMIS (currently using extension types), = such >>> as "http://docs.oasis-open.org/ns/cmis/link/200908/typedescendants" = (see >>> = )? >> They need to be well-defined; some of them look like they are (at a = glance), and some do not (e.g., the 'changes' one seems quite muddy, on = the face of it). Beyond that, if I were DE, I'd probably ask for some of = them to be prefixed by 'cmis' to assure that they're not grabbing = potentially more generic semantics. >> Thoughts? >> ... >=20 > It's a bit ironic in that's exactly how CMIS started something like = one year ago, until we told them that they should either use extension = relations, or make the relations more generic :-). Perhaps, but I'd rather get it right. Cheers, -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Tue Dec 15 00:44:16 2009 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 457133A69AD for ; Tue, 15 Dec 2009 00:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.345 X-Spam-Level: X-Spam-Status: No, score=-4.345 tagged_above=-999 required=5 tests=[AWL=-1.746, 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 Xujn6MzC7Dty for ; Tue, 15 Dec 2009 00:44:15 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DD3073A69AF for ; Tue, 15 Dec 2009 00:44:14 -0800 (PST) Received: (qmail invoked by alias); 15 Dec 2009 08:44:01 -0000 Received: from p508FC260.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.194.96] by mail.gmx.net (mp012) with SMTP; 15 Dec 2009 09:44:01 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19llSAKJJllacRsHpGCX1J8lCu1BkAK1WHOwWtqjr dtk9Z5wfCvx496 Message-ID: <4B274C4D.5080907@gmx.de> Date: Tue, 15 Dec 2009 09:43:57 +0100 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: Eran Hammer-Lahav Subject: Re: Update regarding draft-bryan-metalink (intro section) References: <4B1FA0D6.80809@gmail.com> <45A9CE6B-BD31-4A92-B319-BA48913C37E2@cmdline.net> <90C41DD21FB7C64BB94121FBBC2E72343787C35076@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343787C35076@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 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, 15 Dec 2009 08:44:16 -0000 Eran Hammer-Lahav wrote: >>>> 1) Can we use Creative Commons for machine readable alternative to >>>> our license element (Sec 4.2.8)? >>>> >>> Sorry, I don't understand. Do you mean adding new element for >>> "Creative Commons"? What does it look like? >> I also don't understand. Maybe I'm missing some context, but I wonder if >> there might be misunderstanding? Creative Commons would just be one out >> of many different licenses that might find their way into the license element. > > There seems to be value in supporting a machine-readable copyright element in addition to the human-readable element you have today. It might just be that we are not ready at this point to offer a list of token-identified licenses. But if most metalink implementations today already default to a small set of licenses (MIT, BSD, etc.), is it worth defining such a list? > ... Sounds like a can of worms to me. How about considering an extension spec for his, and making sure that the Metalink extension model makes this possible? Best regards, Julian From tatsuhiro.t@gmail.com Tue Dec 15 06:37:58 2009 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 F0F5C3A69FC for ; Tue, 15 Dec 2009 06:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQeWKEYjQXc8 for ; Tue, 15 Dec 2009 06:37:57 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 1C18F3A67F1 for ; Tue, 15 Dec 2009 06:37:57 -0800 (PST) Received: by ywh15 with SMTP id 15so4214475ywh.5 for ; Tue, 15 Dec 2009 06:37:40 -0800 (PST) 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=qRn6gXei9Ddq20m9bHTkVVfWyUKSkgp759qoTQZAwkw=; b=vdKnzr7bjE2inSj29hjFO5FH8PxCtUyhXdhaEafJxA0/vNcYG9KokWWcfUZ05J8J7E IJIv44VEILi0iZ4S9UT4k9qlGXDWNHX47EHXqUZlsWNvr9yNCF2p1OAcds4CXc4OVbMH KYSwAzL1/UQtnuei50FLQGTYmJ1+DHA9Bj2Gs= 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=K6fa8aITwVvfXROKRgZZ6PEam8Ud6fCRgbnVgwFwc9QEp4EcA2GoHNzDTtxbZ/ilCt /Exlg5jd3INAKrYpLWE//eGPzzt80ULagpN0cPPprlbKEF+CWqSw0xSW99mSsBYlxs7z m5HtRdUE3NFbHirhYJ/z7jZxdoWXCK5LvgCfA= Received: by 10.150.241.5 with SMTP id o5mr1364847ybh.173.1260887860512; Tue, 15 Dec 2009 06:37:40 -0800 (PST) Received: from ?192.168.0.11? (kng30-p184.flets.hi-ho.ne.jp [121.102.203.184]) by mx.google.com with ESMTPS id 35sm2348086yxh.33.2009.12.15.06.37.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Dec 2009 06:37:38 -0800 (PST) Message-ID: <4B279F2F.9040305@gmail.com> Date: Tue, 15 Dec 2009 23:37:35 +0900 From: Tatsuhiro Tsujikawa User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: Anthony Bryan Subject: Re: Update regarding draft-bryan-metalink (intro section) References: <4B1FA0D6.80809@gmail.com> <45A9CE6B-BD31-4A92-B319-BA48913C37E2@cmdline.net> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 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, 15 Dec 2009 14:37:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Anthony Bryan wrote: > On Sun, Dec 13, 2009 at 8:19 PM, Peter Pöml wrote: >>>> 1) Can we use Creative Commons for machine readable alternative to our >>>> license element (Sec 4.2.8)? >>>> >>> Sorry, I don't understand. Do you mean adding new element for "Creative >>> Commons"? What does it look like? >> I also don't understand. Maybe I'm missing some context, but I wonder if >> there might be misunderstanding? Creative Commons would just be one out of >> many different licenses that might find their way into the license element. > > My fault for not explaining. Creative Commons offers machine readable > license info. > >>From what I can tell, this was in RDF ( > http://xml.coverpages.org/CCommons-RDF-Schema200212.html ) but don't > know if that's active anymore. It looks like they are using RDFa, > embedded in HTML now so this no longer applies to us: > http://wiki.creativecommons.org/RDFa > Thanks Anthony, I understand. I think machine readable license tag is good, but I think it is too much for Metalink I-D. It would be good it is defined in separate I-D so that everyone can refer to it. More license to come in the future, so the speed of license grows and evolution of Metalink I think differs. Metalink I-D have extension mechanism so we can adopt them easily. >>>> 2) Do we need to use ABNF for the generator element (4.2.4)? >>>> >>>> We talked about using this from HTTP >>>> >>>> product = token ["/" product-version] >>>> product-version = token >>>> >>> I think yes, it is clearer than current form which explains in English >>> text. >>> Or can we borrow it 3.8 Product Tokens from rfc2616 or something similar? >> That was where the concept comes from. I agree, using ABNF to achieve more >> clarity makes sense to me. > > Great, can you add that? > This is my draft: The "metalink:generator" element's content identifies the generating agent name and version used to generate a Metalink Document, for debugging and other purposes. metalinkGenerator = element metalink:generator { metalinkTextConstruct } metalink:generator element's content is defined as ABNF below. agent = token ["/" agent-version] agent-version = token token is of type text. Although any character allowed in text MAY appear in an agent-version, this token SHOULD only be used for a version identifier (i.e., successive versions of the same agent SHOULD only differ in the agent-version portion of the agent value). I replaced product with agent, since first paragraph refers "agent". Since "token" is not mentioned in Metalink I-D, we have to give its type. I just added "token is of type text", but I'm not confortable with it, so please suggest better one. The most part of last paragraph is borrowed from the last paragraph of RFC2616 3.8 Product Tokens. Best regards, Tatsuhiro Tsujikawa -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksnny8ACgkQfoQD1dZzw2ZEIACfdgFJOE/xa+C3jrFkOlWT1Di6 ItwAn2Q/NPrppgnWPsVm/hOaSl42zdx1 =IxjP -----END PGP SIGNATURE----- From ted.ietf@gmail.com Tue Dec 15 09:55:35 2009 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 58C783A68F2 for ; Tue, 15 Dec 2009 09:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCdxrdqUpoeH for ; Tue, 15 Dec 2009 09:55:33 -0800 (PST) Received: from mail-pz0-f188.google.com (mail-pz0-f188.google.com [209.85.222.188]) by core3.amsl.com (Postfix) with ESMTP id A86B23A6895 for ; Tue, 15 Dec 2009 09:55:33 -0800 (PST) Received: by pzk26 with SMTP id 26so73355pzk.4 for ; Tue, 15 Dec 2009 09:55:17 -0800 (PST) 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:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZclTjHi45wZglRwIZC4/C4k/c5iwx8/j6JIGSxskBLg=; b=NP542YY4M1hN8FjrSMTSR/iyiTnzpyi+fd96s0z8mnMfJjynFuvIdlkpDAsvdTJNqt tNrsiW9kHNjluuffJF5e5YiHtG4VkkF2QYV6UXtRrAXSCMpu5Guxp5y1kmNERPydJ4PM s9/wgrwCEe9K3bybA7R/79dSHK76y38gz7V/U= 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=QRDWpOQ4XFEQkJMCtPj4vd2KGxQhXkAhWljbNJBFLiJnN8zOj5YemS1/GISnDkYjIr rMYE81UfCpCY91nv7KbGJA8AspaHy5KZdlH8X//ImR7902ltxa90aXcTRkNb9ypiZ970 XSWYVQUobaxRgdsTADfjx9LNkiOtTa8QaDf6Y= MIME-Version: 1.0 Received: by 10.142.7.10 with SMTP id 10mr4350150wfg.137.1260899717672; Tue, 15 Dec 2009 09:55:17 -0800 (PST) In-Reply-To: <4B271A78.80002@it.aoyama.ac.jp> References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <6DBD3C00-AEAC-4AC8-8263-B97A15FD4903@mac.com> <90C41DD21FB7C64BB94121FBBC2E7234378520A0E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B16992E.3050000@gmx.de> <90C41DD21FB7C64BB94121FBBC2E7234378520A1E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B271A78.80002@it.aoyama.ac.jp> Date: Tue, 15 Dec 2009 09:55:17 -0800 Message-ID: <6e04e83a0912150955r1bb1673bi5d5d7bf9240fc7f4@mail.gmail.com> Subject: Re: draft-nottingham-http-link-relation-07 progress From: Ted Hardie To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss , "public-iri@w3.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, 15 Dec 2009 17:55:35 -0000 On Mon, Dec 14, 2009 at 9:11 PM, "Martin J. D=FCrst" wrote: > I agree that RFC 3986 (and RFC 3987) are not of direct use for defining > anything like a normalization of URIs (or IRIs). The main reason for this= is > that there are different contexts in which you may have different knowled= ge > (e.g. of scheme specific default ports) and may prefer aggressive or > cautionary normalization. The safe side of the normalization range is on > different ends depending on what you are doing. > > As we are working on an update to RFC 3987, what I'm wondering is whether= it > may be possible to improve the text in RFC 3987 (which is mostly a copy o= f > the one in RFC 3986, with some additions due to the bigger character > repertoire) so that it becomes easier for an application such as OAuth to > define what they need just with a few pointers (e.g. "from Section X of t= he > IRI spec, use foo, baz, and frof normalizations but not bar") rather than > defining everything ab initio. > > Would that help? Or does nobody care? > I think it would be very useful, partly because it would allow descriptions of comparison techniques to say "The FOO comparison starts with the application of the BAR normalization then applies the following steps". This simplifies the necessary description of the comparison methods, and it seems likely to improve the selection among comparison methods by protocol designers as well. Just my two cents, Ted > Regards, =A0 Martin. > > On 2009/12/03 3:03, Eran Hammer-Lahav wrote: >> >> It's a good start but not enough. The text itself points out the various >> problems with normalization but does not address all of them with normat= ive >> language. Normalization must be nothing but a long list of MUSTs and MUS= T >> NOTs. >> >> When we first pointed developers to 3986 for OAuth normalization needs, >> nothing worked... >> >> EHL >> >>> -----Original Message----- >>> From: Julian Reschke [mailto:julian.reschke@gmx.de] >>> Sent: Wednesday, December 02, 2009 8:43 AM >>> To: Eran Hammer-Lahav >>> Cc: Jan Algermissen; John Panzer; Apps Discuss >>> Subject: Re: draft-nottingham-http-link-relation-07 progress >>> >>> Eran Hammer-Lahav wrote: >>>> >>>> Unfortunately no. There is no standard way (I'm aware of) to >>>> canonicalize a >>> >>> URI in a consistent way. This is why specs like OAuth have to spell out >>> how to >>> perform percent encoding and other transformations to ensure a consiste= nt >>> string. >>>> >>>> ... >>> >>> ? >>> >>> BR, Julian >> >> _______________________________________________ >> Apps-Discuss mailing list >> Apps-Discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > -- > #-# Martin J. D=FCrst, Professor, Aoyama Gakuin University > #-# http://www.sw.it.aoyama.ac.jp =A0 mailto:duerst@it.aoyama.ac.jp > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From anthonybryan@gmail.com Tue Dec 15 12:59:20 2009 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 307883A68FF for ; Tue, 15 Dec 2009 12:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.692 X-Spam-Level: X-Spam-Status: No, score=-3.692 tagged_above=-999 required=5 tests=[AWL=-1.093, 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 I1M8+Eo3TdRQ for ; Tue, 15 Dec 2009 12:59:19 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 509B83A67E5 for ; Tue, 15 Dec 2009 12:59:19 -0800 (PST) Received: by iwn33 with SMTP id 33so214247iwn.29 for ; Tue, 15 Dec 2009 12:59:01 -0800 (PST) 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:message-id:subject:from:to:cc:content-type; bh=ACBa7jkMqGji2lmVa5/dX8LYzxjF3etZSqOqWZ/GgbA=; b=dWgaBtVyQO50Af1r6PPcLuK0Il/mUvBDu/eYBKAuNRKdfMTZFLCUcs6Ozov/KgXQfO VrSy6Bdwz/6x1G9B4HWhk/7ZGzgkBkGaAl3Kt3pkIUszVUa5WiZGdM5PqjarjDYlwnKj 8ucI86GBSfi7Njkb5i3rpoXhEqT9B0wsYUNww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=n/4fqg7AFP1kQC5p7KtJjtL024AKKJf7oYUenNwl5erPIVGhC1/c7oLvfbD/DIz8iL i//3s/1UYx4rgr/Qzt7OudZL0JdOU06Bydk1QwOt83zckPdWVZYgMfOYBK4rzdYTHBu/ Pb3oAaiN8UyTbV5W1ImaD8JUX/XOfZb/vp378= MIME-Version: 1.0 Received: by 10.231.156.85 with SMTP id v21mr32345ibw.38.1260910740914; Tue, 15 Dec 2009 12:59:00 -0800 (PST) In-Reply-To: <4B274C4D.5080907@gmx.de> References: <4B1FA0D6.80809@gmail.com> <45A9CE6B-BD31-4A92-B319-BA48913C37E2@cmdline.net> <90C41DD21FB7C64BB94121FBBC2E72343787C35076@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B274C4D.5080907@gmx.de> Date: Tue, 15 Dec 2009 15:59:00 -0500 Message-ID: Subject: Re: Update regarding draft-bryan-metalink (intro section) From: Anthony Bryan To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 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, 15 Dec 2009 20:59:20 -0000 On Tue, Dec 15, 2009 at 3:43 AM, Julian Reschke wrote: > Eran Hammer-Lahav wrote: >>>>> >>>>> 1) Can we use Creative Commons for machine readable alternative to >>>>> our license element (Sec 4.2.8)? >>>>> >>>> Sorry, I don't understand. Do you mean adding new element for >>>> "Creative Commons"? What does it look like? >>> >>> I also don't understand. Maybe I'm missing some context, but I wonder if >>> there might be misunderstanding? Creative Commons would just be one out >>> of many different licenses that might find their way into the license >>> element. >> >> There seems to be value in supporting a machine-readable copyright element >> in addition to the human-readable element you have today. It might just be >> that we are not ready at this point to offer a list of token-identified >> licenses. But if most metalink implementations today already default to a >> small set of licenses (MIT, BSD, etc.), is it worth defining such a list? > >> ... > > Sounds like a can of worms to me. > > How about considering an extension spec for his, and making sure that the > Metalink extension model makes this possible? Sounds good. License element removed from the metalink ID, extension spec later if there is interest. -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From anthonybryan@gmail.com Tue Dec 15 13:02:40 2009 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 824D13A6AE2 for ; Tue, 15 Dec 2009 13:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-1.029, 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 ZkrRnxvIKf5o for ; Tue, 15 Dec 2009 13:02:39 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 4A84A3A6AC9 for ; Tue, 15 Dec 2009 13:02:39 -0800 (PST) Received: by iwn33 with SMTP id 33so216520iwn.29 for ; Tue, 15 Dec 2009 13:02:23 -0800 (PST) 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:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uMDZ0vKR7aC47lTWC5ATGcyrvvWytUURInv4SGU49jg=; b=j+tARyr5VwZGdy9HlYemLfA0F7XDjgkQiOwlCAxEjGqbRWYGDc9FLM4vj8ORjhit36 ycHjV5qzMy6wwRnMuiHxAT4pu5TBZxMcyLsDESrjNpdW4P11Pv6xypzp3syFzFu6gLwV h2WFQHmb3I90Yn5addq/+94qCl7fs0a2Xfn5M= 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=j26h6g3jGMAv9SrCAiPf1XaLgmYxYxXpK13BSXU4wFwYt2ERZZ7IsfLS2luQI62iEF jJdpYFuIIeY6UEuddT8i7FHmzgaHmUA2mWj9h+0meXMYUFRpqypY4PBLrw1nnhTKGKj2 2pMKK24l/7L3pBuJZZzayt4nEP47qz+NXB8Ak= MIME-Version: 1.0 Received: by 10.231.157.83 with SMTP id a19mr33692ibx.41.1260910942870; Tue, 15 Dec 2009 13:02:22 -0800 (PST) In-Reply-To: <4B279F2F.9040305@gmail.com> References: <4B1FA0D6.80809@gmail.com> <45A9CE6B-BD31-4A92-B319-BA48913C37E2@cmdline.net> <4B279F2F.9040305@gmail.com> Date: Tue, 15 Dec 2009 16:02:22 -0500 Message-ID: Subject: Re: Update regarding draft-bryan-metalink (intro section) From: Anthony Bryan To: Tatsuhiro Tsujikawa 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: Tue, 15 Dec 2009 21:02:40 -0000 On Tue, Dec 15, 2009 at 9:37 AM, Tatsuhiro Tsujikawa wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Anthony Bryan wrote: >> On Sun, Dec 13, 2009 at 8:19 PM, Peter P=F6ml wrote: >>>>> 1) Can we use Creative Commons for machine readable alternative to ou= r >>>>> license element (Sec 4.2.8)? >>>>> >>>> Sorry, I don't understand. Do you mean adding new element for "Creativ= e >>>> Commons"? What does it look like? >>> I also don't understand. Maybe I'm missing some context, but I wonder i= f >>> there might be misunderstanding? Creative Commons would just be one > out of >>> many different licenses that might find their way into the license > element. >> >> My fault for not explaining. Creative Commons offers machine readable >> license info. >> >>>From what I can tell, this was in RDF ( >> http://xml.coverpages.org/CCommons-RDF-Schema200212.html ) but don't >> know if that's active anymore. It looks like they are using RDFa, >> embedded in HTML now so this no longer applies to us: >> http://wiki.creativecommons.org/RDFa >> > > Thanks Anthony, I understand. I think machine readable license tag is > good, but I think it is too much for Metalink I-D. It would be good it > is defined in separate I-D so that everyone can refer to it. More > license to come in the future, so the speed of license grows and > evolution of Metalink I think differs. > Metalink I-D have extension mechanism so we can adopt them easily. license element removed. :) >>>>> 2) Do we need to use ABNF for the generator element (4.2.4)? >>>>> >>>>> We talked about using this from HTTP >>>>> >>>>> =A0 =A0 product =A0 =A0 =A0 =A0 =3D token ["/" product-version] >>>>> =A0 =A0 product-version =3D token >>>>> >>>> I think yes, it is clearer than current form which explains in English >>>> text. >>>> Or can we borrow it 3.8 Product Tokens from rfc2616 or something > similar? >>> That was where the concept comes from. I agree, using ABNF to achieve > more >>> clarity makes sense to me. >> >> Great, can you add that? >> > > This is my draft: > > The "metalink:generator" element's content identifies the > generating agent name and version used to generate a Metalink > Document, for debugging and other purposes. > > metalinkGenerator =3D > =A0 element metalink:generator { > =A0 =A0 metalinkTextConstruct > =A0 } > > metalink:generator element's content is defined as ABNF below. > > agent =A0 =A0 =A0 =A0 =3D token ["/" agent-version] > agent-version =3D token > > token is of type text. Although any character allowed in text MAY > appear in an agent-version, this token SHOULD only be used for a > version identifier (i.e., successive versions of the same agent > SHOULD only differ in the agent-version portion of the agent > value). > > I replaced product with agent, since first paragraph refers "agent". > Since "token" is not mentioned in Metalink I-D, we have to give its > type. I just added "token is of type text", but I'm not confortable with > it, so please suggest better one. The most part of last paragraph is > borrowed from the last paragraph of RFC2616 3.8 Product Tokens. Thanks. I changed the one line to: metalink:generator element's content is defined below in ABNF notation [RFC5234]. And added RFC5234 to the normative references section. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From Martin.Thomson@andrew.com Tue Dec 15 14:27:58 2009 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 35C783A6B2A for ; Tue, 15 Dec 2009 14:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNygfj6B8gnq for ; Tue, 15 Dec 2009 14:27:58 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id E13913A68BE for ; Tue, 15 Dec 2009 14:27:57 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:5429 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S142069AbZLOW0n (ORCPT ); Tue, 15 Dec 2009 16:26:43 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 15 Dec 2009 16:26:42 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 16 Dec 2009 06:26:40 +0800 From: "Thomson, Martin" To: Julian Reschke Date: Wed, 16 Dec 2009 06:27:28 +0800 Subject: RE: XML related issues in metalink, was: Last Call: draft-bryan-metalink (The Metalink Download Description Format) to Proposed Standard Thread-Topic: XML related issues in metalink, was: Last Call: draft-bryan-metalink (The Metalink Download Description Format) to Proposed Standard Thread-Index: Acp8nCxfSvM26Z7VT96ee1slNux8TgBLublA Message-ID: <8B0A9FCBB9832F43971E38010638454F01D65BF2AD@SISPE7MB1.commscope.com> References: <20091211185920.C2E8D3A6999@core3.amsl.com> <4B24BD59.30107@gmx.de> <4B2542F9.5090402@gmx.de> <8B0A9FCBB9832F43971E38010638454F01D65BEDB7@SISPE7MB1.commscope.com> <4B25FEA8.5050408@gmx.de> In-Reply-To: <4B25FEA8.5050408@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Apps Discuss , "ietf@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, 15 Dec 2009 22:27:58 -0000 SW5saW5lLi4uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSnVsaWFu IFJlc2Noa2UgW21haWx0bzpqdWxpYW4ucmVzY2hrZUBnbXguZGVdDQo+IFNlbnQ6IE1vbmRheSwg MTQgRGVjZW1iZXIgMjAwOSA4OjAwIFBNDQo+IFRvOiBUaG9tc29uLCBNYXJ0aW4NCj4gQ2M6IEFu dGhvbnkgQnJ5YW47IEFwcHMgRGlzY3VzczsgaWV0ZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog WE1MIHJlbGF0ZWQgaXNzdWVzIGluIG1ldGFsaW5rLCB3YXM6IExhc3QgQ2FsbDogZHJhZnQtDQo+ IGJyeWFuLW1ldGFsaW5rIChUaGUgTWV0YWxpbmsgRG93bmxvYWQgRGVzY3JpcHRpb24gRm9ybWF0 KSB0byBQcm9wb3NlZA0KPiBTdGFuZGFyZA0KPiANCj4gVGhvbXNvbiwgTWFydGluIHdyb3RlOg0K PiA+IFdoeSBpcyB3aGl0ZXNwYWNlIHNvIGltcG9ydGFudD8gIFRoZSBhbHRlcm5hdGl2ZSB0byBj b25zdHJhaW5pbmcgdXNlDQo+IGFzIHlvdSBoYXZlIGRvbmUsIHdoaWNoIHJlcXVpcmVzIHRoYXQg eW91IGFsc28gImZpeCIgYWxsIHRoZSBleGFtcGxlcywNCj4gaXMgdG8gdXNlIHRoZSB0eXBlIHRo YXQgZml0cyBiZXR0ZXIgd2l0aCB1c2VyIGV4cGVjdGF0aW9uczogdG9rZW4uDQo+IA0KPiBJTUhP LCB3aGF0J3MgaW1wb3J0YW50IGlzIHRvIGRlY2lkZSwgdG8gc3BlY2lmeSBpdCBwcm9wZXJseSwg YW5kIHRvDQo+IGhhdmUgZXhhbXBsZXMgY29uc2lzdGVudCB3aXRoIGl0LiBBbmQsIG9wdGltYWxs eSwgdGVzdCBjYXNlcy4NCg0KSSB0ZW5kIHRvIGZhdm91ciBub24tc2lnbmlmaWNhbnQgd2hpdGVz cGFjZSAtIGl0IGZpdHMgd2l0aCBjb21tb24gZXhwZWN0YXRpb25zLiAgQWZ0ZXIgYWxsLCB0aGUg ZXhhbXBsZXMgc2VlbSB0byBhc3N1bWUgdGhhdC4NCg0KQnV0IGluIHRoZSBlbmQsIG1ha2luZyBh IGRlY2lzaW9uIGFuZCBzdGlja2luZyB0byBpdCBpcyB0aGUgYmVzdCBwbGFuLg0KDQo+IFdlbGws IGJ5IG1ha2luZyBpdCBub24tc2lnbmlmaWNhbnQsIHlvdSdsbCBtaWdodCBnZXQgaW50ZXJvcCBw cm9ibGVtcw0KPiBhcyB3ZWxsLg0KDQpJdCdzIFhNTC4gIE9mIGNvdXJzZSB0aGVyZSB3aWxsIGJl IHdoaXRlc3BhY2UgaXNzdWVzLg0KDQo+ID4gSW4gbG9va2luZyBpbnRvIHRoaXMsIEkgbm90ZWQg dGhpczoNCj4gPiAgICAjIFVuY29uc3RyYWluZWQ7IGl0J3Mgbm90IGVudGlyZWx5IGNsZWFyIGhv dyBJUkkgZml0IGludG8NCj4gPiAgICAjIHhzZDphbnlVUkkgc28gbGV0J3Mgbm90IHRyeSB0byBj b25zdHJhaW4gaXQgaGVyZQ0KPiA+DQo+ID4gSSB3b25kZXIgd2h5IHlvdSBoYXZlbid0IHRha2Vu IHRoZSBwbHVuZ2Ugb24geHNkOmFueVVSSSwgZXZlbiBpZg0KPiB4c2Q6YW55VVJJIGhhcyBkdWJp b3VzIG9mZmljaWFsIHN0YXR1cyB3aXRoIHJlZ2FyZHMgdG8gSVJJcy4gIEluDQo+IHByYWN0aWNl LCBJUklzIGFyZSBjb21tb25seSBwbGFjZWQgaW4geHNkOmFueVVSSS4gIFRoZSBsZXhpY2FsIHNw YWNlDQo+IGFjY29tbW9kYXRlcyB0aGVtLCBubyBpbXBsZW1lbnRhdGlvbiBJJ20gYXdhcmUgb2Yg cHJldmVudHMgdXNlIG9mIElSSXMuDQo+IA0KPiBJJ2xsIGFzc3VtZSBpdCdzIGluaGVyaXRlZCBm cm9tIFJGQyA0Mjg3LCBhbmQgdGhhdCB0aGUgQXRvbSBXRyBoYWQgZ29vZA0KPiByZWFzb25zIG5v dCB0byB1c2UgeHNkOmFueVVSSS4uLg0KDQpBaC4gIENhbid0IGFyZ3VlIHdpdGggaW5oZXJpdGVk IHdpc2RvbS4NCg0KPiANCj4gQmVzdCByZWdhcmRzLCBKdWxpYW4NCg0K From mat69@gmx.net Mon Dec 21 03:42:28 2009 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 58EB628C0EC for ; Mon, 21 Dec 2009 03:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[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 bwdfeSb8r4N8 for ; Mon, 21 Dec 2009 03:42:27 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9AF8128C0E1 for ; Mon, 21 Dec 2009 03:42:26 -0800 (PST) Received: (qmail invoked by alias); 21 Dec 2009 11:42:08 -0000 Received: from unknown (EHLO matthias-desktop.localnet) [93.83.106.50] by mail.gmx.net (mp025) with SMTP; 21 Dec 2009 12:42:08 +0100 X-Authenticated: #8538339 X-Provags-ID: V01U2FsdGVkX18iZCYILx4iBOAuuQC4FZZP+v55uC9GKphr4vw6sh tiGdJmsPydgIw6 From: Matthias Fuchs To: apps-discuss@ietf.org Subject: Metalink: Combine metalink:origin and metalink:dynamic Date: Mon, 21 Dec 2009 12:42:25 +0100 User-Agent: KMail/1.12.4 (Linux/2.6.31-ARCH; KDE/4.3.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2902845.LgSW5TNfv6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200912211242.33667.mat69@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.82 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 11:50:58 -0000 --nextPart2902845.LgSW5TNfv6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I think metalink:dynamic should rather be an attribute of metalink:origin=20 instead of an element itself. The reason for this is that when metalink:dynamic is set to true it is only= =20 useful if metalink:origin is also defined, while it would be useless if if= =20 origin was not defined. Making it an attribute would make sure that origin = is=20 always set when having a dynamic metalink. Cheers! matthias --nextPart2902845.LgSW5TNfv6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAksvXyEACgkQvK3LWbSvp5NlMAD+LBAyo65ncO9G2TlxdYHiNhiM RGe6FN3hnsvCP0ige+wA/3GhkYk78XoSEz1yuBmL9FzVWG9tsU5d3bNOWHq5+2Fh =BVm/ -----END PGP SIGNATURE----- --nextPart2902845.LgSW5TNfv6-- From anthonybryan@gmail.com Mon Dec 21 11:19:07 2009 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 EA0053A680C for ; Mon, 21 Dec 2009 11:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=-1.754, 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 sLC+2yJBmKdm for ; Mon, 21 Dec 2009 11:19:06 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id DCFCD3A67FA for ; Mon, 21 Dec 2009 11:19:05 -0800 (PST) Received: by iwn33 with SMTP id 33so3857560iwn.29 for ; Mon, 21 Dec 2009 11:18:47 -0800 (PST) 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:message-id:subject:from:to:cc:content-type; bh=rt+c5cpuOiQf42iqhl2p9s6AOGhoMDFb2ZxmIlnAup4=; b=ImUYHdxx8bEDtAjfEHxEZle74V2PA499ofKrxzLCzSbvJTvtF32h1gyD9tZQQuMku6 D+mMgTGmqj/3PGzJzja4cHsApGsVmcZeCaUz6s0xjd+YdHbix6CIDt9MnG4XTZD7nqwS VGLYcc5NpuXjT/jwYGs2lEDxoKqG2XkHRo7tM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=c3mQKft9wLo/aXee68UjzVD04eKsVp9FsAa5ESim0G5xmZHxVnRhbJWmYb1ZfQFazn rLNv5WcBulv9mDDXT5ZExFd1EfeEyou5asjb+OS2utnl0OFh9RZWM3FUAzRnwt8+4puI KUBgAfBciGMc+w4Az9b7LMquOS9geWvMv2Ok0= MIME-Version: 1.0 Received: by 10.231.122.36 with SMTP id j36mr996183ibr.21.1261423126858; Mon, 21 Dec 2009 11:18:46 -0800 (PST) In-Reply-To: <200912211242.33667.mat69@gmx.net> References: <200912211242.33667.mat69@gmx.net> Date: Mon, 21 Dec 2009 14:18:46 -0500 Message-ID: Subject: Re: Metalink: Combine metalink:origin and metalink:dynamic From: Anthony Bryan To: Matthias Fuchs Content-Type: text/plain; charset=ISO-8859-1 Cc: "Neil M." , 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, 21 Dec 2009 19:19:08 -0000 On Mon, Dec 21, 2009 at 6:42 AM, Matthias Fuchs wrote: > Hi, > > I think metalink:dynamic should rather be an attribute of metalink:origin > instead of an element itself. > > The reason for this is that when metalink:dynamic is set to true it is only > useful if metalink:origin is also defined, while it would be useless if if > origin was not defined. Making it an attribute would make sure that origin is > always set when having a dynamic metalink. Matthias, Very logical and fits in. I'm ashamed it wasn't already like this. :) Current values are true or false. Do you think on/off would be better, or a numeric value? This brings up the larger discussion of the XML format, which I would like to have more people comment/hammer on. Here is an example following the current draft: 2009-05-15T18:30:02Z http://releases.ubuntu.com/9.04/ubuntu-9.04-alternate-amd64.meta4 732282880 9.04 Ubuntu CD Image http://www.ubuntu.com/themes/ubuntu07/images/ubuntulogo.png Linux 3b5e9861910463374bb0d4ba9025bbb1 http://releases.ubuntu.com/9.04/ubuntu-9.04-alternate-amd64.iso.torrent http://ftp.leg.uct.ac.za/pub/linux/ubuntu-releases/9.04/ubuntu-9.04-alternate-amd64.iso http://ls.releases.ubuntu.com/9.04/ubuntu-9.04-alternate-amd64.iso http://zw.releases.ubuntu.com/9.04/ubuntu-9.04-alternate-amd64.iso http://na.releases.ubuntu.com/9.04/ubuntu-9.04-alternate-amd64.iso ftp://ftpserv.tudelft.nl/pub/Linux/releases.ubuntu.com/9.04/ubuntu-9.04-alternate-amd64.iso And here's an example from our older, community spec: Ubuntu http://www.ubuntu.com/ 9.04 Ubuntu CD Image http://www.ubuntu.com/themes/ubuntu07/images/ubuntulogo.png 732282880 Linux-x64 3b5e9861910463374bb0d4ba9025bbb1 http://releases.ubuntu.com/9.04/ubuntu-9.04-alternate-amd64.iso.torrent http://sz.releases.ubuntu.com/9.04/ubuntu-9.04-alternate-amd64.iso http://mz.releases.ubuntu.com/9.04/ubuntu-9.04-alternate-amd64.iso http://bw.releases.ubuntu.com/9.04/ubuntu-9.04-alternate-amd64.iso http://ubuntu.interhost.co.il/9.04/ubuntu-9.04-alternate-amd64.iso ftp://dl2.foss-id.web.id/iso/ubuntu/releases/9.04/ubuntu-9.04-alternate-amd64.iso -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From mat69@gmx.net Tue Dec 22 04:18:37 2009 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 9CA553A69F1 for ; Tue, 22 Dec 2009 04:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 nb0d-ga64Ofo for ; Tue, 22 Dec 2009 04:18:35 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5CFA03A6B08 for ; Tue, 22 Dec 2009 04:18:19 -0800 (PST) Received: (qmail invoked by alias); 22 Dec 2009 12:18:02 -0000 Received: from unknown (EHLO matthias-desktop.localnet) [93.83.106.50] by mail.gmx.net (mp012) with SMTP; 22 Dec 2009 13:18:02 +0100 X-Authenticated: #8538339 X-Provags-ID: V01U2FsdGVkX19gSnF3oYhg6nLmVthKENCHvDInjY1t+maOzX3pAc xqEPDdPRvA5cmV From: Matthias Fuchs To: Anthony Bryan Subject: Re: Metalink: Combine metalink:origin and metalink:dynamic Date: Tue, 22 Dec 2009 13:18:25 +0100 User-Agent: KMail/1.12.4 (Linux/2.6.31-ARCH; KDE/4.3.4; x86_64; ; ) References: <200912211242.33667.mat69@gmx.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2740470.Vh7gl0ib5I"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200912221318.35656.mat69@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Cc: Peter, "Neil M." , 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, 22 Dec 2009 12:18:38 -0000 --nextPart2740470.Vh7gl0ib5I Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Montag 21 Dezember 2009 20:18:46 schrieb Anthony Bryan: > On Mon, Dec 21, 2009 at 6:42 AM, Matthias Fuchs wrote: > > Hi, > > > > I think metalink:dynamic should rather be an attribute of metalink:orig= in > > instead of an element itself. > > > > The reason for this is that when metalink:dynamic is set to true it is > > only useful if metalink:origin is also defined, while it would be usele= ss > > if if origin was not defined. Making it an attribute would make sure th= at > > origin is always set when having a dynamic metalink. >=20 > Matthias, >=20 > Very logical and fits in. I'm ashamed it wasn't already like this. :) >=20 > Current values are true or false. Do you think on/off would be better, > or a numeric value? Personally I think we should use true and false. --nextPart2740470.Vh7gl0ib5I Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAkswuREACgkQvK3LWbSvp5POjwD/U63eYU2nUiKvTLlIZnm2oqxy D0I95ldDn7NHt3OcXV4A+wdsoxf8P51uDsPr/Yvvsklt3IoNV7/VCpADBDMrX1Yi =bWwR -----END PGP SIGNATURE----- --nextPart2740470.Vh7gl0ib5I-- From y.oiwa@aist.go.jp Thu Dec 24 03:30:03 2009 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 4BEF63A6887 for ; Thu, 24 Dec 2009 03:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.51 X-Spam-Level: ** X-Spam-Status: No, score=2.51 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 8xuTt76VTTqg for ; Thu, 24 Dec 2009 03:30:02 -0800 (PST) Received: from mx2s.aist.go.jp (mx2s.aist.go.jp [150.29.246.150]) by core3.amsl.com (Postfix) with ESMTP id BC5E83A6818 for ; Thu, 24 Dec 2009 03:30:01 -0800 (PST) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx2s.aist.go.jp with ESMTP id nBOBTdbf011014; Thu, 24 Dec 2009 20:29:39 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1261654182; bh=LltDmovMwqVy3C1lUF5sWg778HDUrsfyaCXch+2qfas=; h=From:Date:Message-ID; b=Kv23NXzY/M/F+fXf5fInEoiscMJRhffCTm6TwEUWZw5VRsWV2MwJuuy0mX4JE2pRh 6koAvaQpatRps0EzjIEqDLt+gAbWhlbtVr49SZNIA8GSung7FK5RNuA/bY9T2J7iBf n/oicQfldrQbVHvuSDpPvtYehbtp+L+EYhgR3URc= Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id nBOBSmO0015030; Thu, 24 Dec 2009 20:28:48 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id nBOBSkKp018357; Thu, 24 Dec 2009 20:28:46 +0900 (JST) env-from (y.oiwa@aist.go.jp) From: Yutaka OIWA To: apps-discuss@ietf.org, public-web-security@w3.org Subject: HTTP Mutual-auth proposal status / HTTP AUTH meet-up in Anaheim? Date: Thu, 24 Dec 2009 20:28:46 +0900 Message-ID: <87skb0lifl.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ietf-http-auth@osafoundation.org, ietf-http-wg@w3.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: public-web-security@w3.org, y.oiwa@aist.go.jp List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 11:34:12 -0000 Dear people on IETF apps-discuss/public-web-security mailing lists and other related lists, I would like to introduce our proposal on HTTP mutual authentication. (I directed the Reply-to: header to the newly-created public-web-security mailing list, but I also welcome private replies or those to other lists.) Our proposal brings a strong, password-based mutual authentication to the HTTP authentication protocol. Our aims are to overcome several deficiencies (both for security and usability) on current HTTP authentication mechanisms, and to replace weak form-based authentication, which are used in most current Web apps, with stronger HTTP protocol-supported authentications. We designed the protocol so that (a) it removes any threats related to password/secret stealing like phishing or other attacks, (b) it will be extremely easy-to-use, and (c) it can accept many Web applications which were not well-supported with current HTTP authentication architecture (in RFC 2617). We believe that this is a correct direction for the future of the Web application authentication. Our proposed draft spec is available from . We put a preprint paper on our concept at ArXiv , and a presentation in a past httpbis WG is also available from , I appreciate your reading and comments on those documents. Furthermore, we have published a running code of the protocol implementation for Mozilla Firefox, available from . A pre-compiled binary, server-side implementations and running demonstration are available in our website . I noticed that the registration for IETF 77 at Anaheim is now open. I would like to have a meet-up of people related to general HTTP authentication issues/proposals at Anaheim. I have been told from Lisa that there will be several HTTP-related WGs and BoFs expected in Anaheim, and I think there will be a good opportunity for us to meet up. If you have any good ideas, please let me know. Have nice holidays, register for IETF 77 and see you in Anaheim! -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From anthonybryan@gmail.com Thu Dec 24 12:48:14 2009 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 237483A6828 for ; Thu, 24 Dec 2009 12:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=-0.930, 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 2t9x-sEa1Ejw for ; Thu, 24 Dec 2009 12:48:12 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id C45E83A659B for ; Thu, 24 Dec 2009 12:48:12 -0800 (PST) Received: by iwn33 with SMTP id 33so5886795iwn.29 for ; Thu, 24 Dec 2009 12:47:52 -0800 (PST) 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:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GBdiAVRXe4AZiiUhcXO5h5IgUVuhMKoevzz316RzY+g=; b=Cuq+9sxcabiqRF30mZiBV+6gCZC3yAqhPc3+8aQUoXJuklpg4P3DwBiPX2UEnTpLPD mr6inadHiBFrECjCzmV4cEpR7H+IW/6NoH+8Phk9yqqIHZWrcBzug99gIhNA4fl0KzdA MeZ4LonniMdSb2ZpZVi4dqGhItZgbQ3tcgGBU= 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=c2nb8WTDYHWacgYYlPJbv+LVt5ghmcvtlkOawELXouSNCUkL/E6E+iF7sGXiz6muwy U0CvAFEZQD1dUXZp37Kuei5IJ4LRJI3FXenVdZL7NPwDysJrWMz+yd1odm6APyyrtrUr D9HiJZRRldzPKVNfRHbG7kAnCeXNllLBiP+Go= MIME-Version: 1.0 Received: by 10.231.190.83 with SMTP id g61mr816721iba.6.1261687671550; Thu, 24 Dec 2009 12:47:51 -0800 (PST) In-Reply-To: <87skb0lifl.fsf@bluewind.rcis.aist.go.jp> References: <87skb0lifl.fsf@bluewind.rcis.aist.go.jp> Date: Thu, 24 Dec 2009 15:47:51 -0500 Message-ID: Subject: Re: HTTP Mutual-auth proposal status / HTTP AUTH meet-up in Anaheim? From: Anthony Bryan To: y.oiwa@aist.go.jp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf-http-wg@w3.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: Thu, 24 Dec 2009 20:48:42 -0000 On Thu, Dec 24, 2009 at 6:28 AM, Yutaka OIWA wrote: > > Our proposed draft spec is available from > =A0 . > We put a preprint paper on our concept at ArXiv > =A0 , > and a presentation in a past httpbis WG is also available from > =A0 , > I appreciate your reading and comments on those documents. Hi Yutaka, I can not comment on the technical nature of your draft, but have a few suggestions that might make some sentences flow better. I capitalized words that I changed to draw notice to them, but these would be lowercase in the corrected text. Since I am not that familiar with what you are doing, make sure that these suggestions do not change the intended meaning of your text. They are mostly number or tense changes. 4.6 and 5, p17 diagram, INPUTTED not inputed Unlike THE Basic and Digest HTTP access authentication protocol [RFC2617], THIS protocol ensures that THE server knows the user's entity (encrypted password) upon successful authentication. ...successful authentication to steal THE user's sensitive information, THIS protocol prevents such attacks by providing users a way to... If there is no matching user found, the server SHOULD construct a fake w_B value, and let the protocol GO ON? CONTINUE? by sending A 401-B1 message. If the validation has failed, it means that the authentication has failed. (remove BEEN from has been failed) In a response to a req-B1 message, when C has received a 401-B0 message, it means that the authentication has failed, possibly due to the wrong password BEING given. (remove BEEN from has been failed, remove THAT from due to that the wrong password, change has been given to BEING given) If the verification has SUCCEEDED, C will process the body of the message. Both peers SHOULD reject any invalid UTF-8 sequences which CAUSE decoding ambiguities * C HAS not sent the same value in the same session. Step 7: Check whether there is an available sid for the authentication realm you EXPECT. Any kind of response OTHER than THOSE shown in THE above procedure SHOUL= D be interpreted as fatal communication error, and in such cases user clients MUST NOT process any data (contents and other content-related headers) sent from the server. 7.1 The value of this field MUST be a string THAT contains an absolute URL location. use of this header with 200-optional-B0 messages IS not recommended. 7.2 The value of this field MUST be a string THAT contains an absolute URL location. This FIELD SHOULD only be used with 200-B4 messages. 7.3 This FIELD will be used with 200-B4 messages. If this condition DOES not hold, the server MUST retry with another value of s_B. Just like Basic and Digest access authentication protocol, Mutual authentication protocol supports multiple, separate authentication realms to be set up inside each HOST. Depending on the "path" parameters given in the "401-B1" message (see Section 4), There may be several CANDIDATES... (lowercase there) In this case, it is difficult for the authenticating server to acquire the TLS key information which IS? used between the client and the proxy. In the Mutual authentication protocol, a session represented by a sid is generated by... (lowecase by) The client MAY send more than one REQUEST using a single session specified by the sid. In addition, for each SESSION,... When the user INPUTS the username and password, the client resends the request with a req-A1 header. If the validation FAILS?, the client MUST NOT process any content sent with the message, including the body part. If user-names have to BE kept secret against eavesdropping, the server must use full-scheme-type auth-domain parameter. Server-side STORAGE of user passwords IS advised... --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From julian.reschke@gmx.de Mon Dec 28 06:51:34 2009 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 E1E2D3A691D for ; Mon, 28 Dec 2009 06:51:34 -0800 (PST) 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=-2.026, 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 vVEGC+Xf1UqD for ; Mon, 28 Dec 2009 06:51:33 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 718543A6811 for ; Mon, 28 Dec 2009 06:51:32 -0800 (PST) Received: (qmail invoked by alias); 28 Dec 2009 14:51:12 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp067) with SMTP; 28 Dec 2009 15:51:12 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/YtWNrP4/YJQf2V5YfdF/RY9qfltQw6Rm5ah9f77 zczJtDpTEdjExE Message-ID: <4B38C5DE.50204@gmx.de> Date: Mon, 28 Dec 2009 15:51:10 +0100 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: Apps Discuss Subject: [Fwd: Last call for comments on draft-reschke-rfc2231-in-http-07] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 14:51:35 -0000 FYI -------- Original Message -------- To: HTTP Working Group Subject: Last call for comments on draft-reschke-rfc2231-in-http-07 References: <20091227183001.A776A3A68E0@core3.amsl.com> In-Reply-To: <20091227183001.A776A3A68E0@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I just updated draft-reschke-rfc2231-in-http with a short section explaining document history: Appendix A. Document History and Future Plans (to be removed by RFC Editor before publication) Problems with the internationalization of the HTTP Content- Disposition header field have been known for many years (see test cases at ). During IETF 72 (), the HTTPbis Working Group shortly discussed how to deal with the underspecification of (1) Content-Disposition, and its (2) internationalization aspects. Back then, there was rough consensus in the room to move the definition into a separate draft. This specification addresses problem (2), by defining a simple subset of the encoding format defined in RFC 2231. A separate specification, draft-reschke-rfc2183-in-http, is planned to address problem (1). Note that this approach was chosen because Content- Disposition is just an example for an HTTP header field using this kind of encoding. Another example is the currently proposed Link header field (draft-nottingham-http-link-header). This document is planned to be published on the IETF Standards Track, so that other standards-track level documents can depend on it, such as the new specification of Content-Disposition, or potentially future revisions of the HTTP Link Header specification. Also note that this document specifies a proper subset of the extensions defined in RFC 2231, but does not normatively refer to it. Thus, RFC 2231 can be revised separately, should the email community decide to. - I think this document is ready for an IETF Last Call, but before I request publication (*), I'd appreciate more review from HTTPbis WG members. Best regards, Julian (*) Planned in three weeks from now, on Jan 18, 2010. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Application of RFC 2231 Encoding to Hypertext Transfer Protocol (HTTP) Header Fields > Author(s) : J. Reschke > Filename : draft-reschke-rfc2231-in-http-07.txt > Pages : 13 > Date : 2009-12-27 > > 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 escaping mechanism for use > in Multipurpose Internet Mail Extensions (MIME) headers. This > document specifies a profile of that encoding suitable for use in > HTTP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-reschke-rfc2231-in-http-07.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 A.Hoenes@TR-Sys.de Mon Dec 28 09:33:11 2009 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 D75DF3A68DF; Mon, 28 Dec 2009 09:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.761 X-Spam-Level: * X-Spam-Status: No, score=1.761 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 VACM1qV8c-mD; Mon, 28 Dec 2009 09:33:11 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 52D4E3A689B; Mon, 28 Dec 2009 09:33:09 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA088031555; Mon, 28 Dec 2009 18:32:35 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA12969; Mon, 28 Dec 2009 18:32:33 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200912281732.SAA12969@TR-Sys.de> Subject: New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 (fwd) To: namedroppers@ops.ietf.org, apps-discuss@ietf.org, tsvwg@ietf.org Date: Mon, 28 Dec 2009 18:32:33 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: draft-ietf-tsvwg-iana-ports@cabernet.tools.IETF.ORG, port-srv-reg@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, 28 Dec 2009 17:33:11 -0000 Folks, as a result of the discussions at IETF 76 in Hiroshima, we have submitted the successor of draft-gudmundsson-dns-srv-iana-registry. This draft aligns with draft-ietf-tsvwg-iana-ports, the revised version of which is expected to be submitted soon, as well. Basically, draft-gudmundsson-dnsext-srv-clarify now aims at performing the normative updates and clarifications to RFC 2782 needed to get rid of the ambiguous/missing IANA considerations therein. It uses the revised and unified IANA registry for "Service Names and Port Numbers" (as defined in the upcoming version of draft-ietf-tsvwg-iana-ports): the IETF Transport Protocol names supported by that registry and the Service Names registered in it are the base elements to build the Service Prefix ("_Service._Proto" in RFC 2782) for the owner names of DNS SRV resource records. Further, this draft gives guidelines for service/protocol specification designers on how to make efficient, uniform use of DNS SRV based service discovery and spells out the related documentation requirements. For exceptional cases that cannot contend with the standard naming scheme for Service Labels due to specific requirements and the restrictions imposed on Service Names, an upwards-compatible extended naming scheme for Service Labels is proposed, as an aid for service/protocol designers that would want to adopt this scheme and will then have to precisely document its specific instantiation on a per-service base. The IANA-registered Service Name can still be identified unambiguously on the left-hand side of such Extended Service Labels. This draft targets PS because of the normative updates to RFC 2782. It will be accompanied by another draft (coming out soon) aiming at BCP that will "get rid of the cruft" of the sometimes confusing legacy of various 'service'-related IANA registries. In particular, that draft will freeze and deprecate the WKS IANA registry originally supplied for RFC 952 and give advice to the owners of legacy specifications (inside and outside the IETF) that have made use of SRV records in a "creative" manner that will no more be conformant under draft-gudmundsson-dnsext-srv-clarify and draft-ietf-tsvwg-iana-ports, on how to best migrate to conformant SRV record owner naming and use. 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 | +------------------------+--------------------------------------------+ ----- Forwarded message from IETF I-D Submission Tool ----- > From: IETF I-D Submission Tool > Message-Id: <20091228145348.6F20A3A6957@core3.amsl.com> > Date: Mon, 28 Dec 2009 06:53:48 -0800 (PST) > Subject: New Version Notification for > draft-gudmundsson-dnsext-srv-clarify-00 > > A new version of I-D, draft-gudmundsson-dnsext-srv-clarify-00.txt > has been successfuly submitted by Olafur Gudmundsson and posted > to the IETF repository. > > Filename: draft-gudmundsson-dnsext-srv-clarify > Revision: 00 > Title: Clarification of DNS SRV Owner Names > Creation_date: 2009-12-28 > WG ID: Independent Submission > Number_of_pages: 17 > > Abstract: > The DNS SRV record has been specified in RFC 2052 and RFC 2782 for > use in dynamic service discovery for a domain. These two RFCs did > not clearly specify an IANA registry for the names of the services > and their underlying protocols. This document clarifies RFC 2782 > regarding the formation and use of the Service Prefix in the owner > name of SRV records, based on the unified IANA registry for "Service > Names and Port Numbers". > > Status of this Memo > > ... > > The IETF Secretariat. ----- End of forwarded message from IETF I-D Submission Tool ----- From Jeff.Hodges@KingsMountain.com Mon Dec 28 16:22:52 2009 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 BA0823A690B for ; Mon, 28 Dec 2009 16:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.836 X-Spam-Level: X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 T98Yewci0SZc for ; Mon, 28 Dec 2009 16:22:51 -0800 (PST) Received: from outbound-mail-107.bluehost.com (outbound-mail-107.bluehost.com [69.89.22.7]) by core3.amsl.com (Postfix) with SMTP id A41323A67AB for ; Mon, 28 Dec 2009 16:22:51 -0800 (PST) Received: (qmail 2561 invoked by uid 0); 29 Dec 2009 00:22:32 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by outboundproxy3.bluehost.com with SMTP; 29 Dec 2009 00:22:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=CchVx70yPtE4JHY4cVIpm9j62YTTCfv3H5SisZRhzMfo8qCsdl09lOrNxAUbjPh8G8saA0PLp4HO6+4d3s97wiOs/7XKN8auClK0SXbH+ssGSQVO3S+xkM0jYTQ/iUJk; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.46]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NPPr6-0000P3-2N; Mon, 28 Dec 2009 17:22:32 -0700 Message-ID: <4B394BD4.3020104@KingsMountain.com> Date: Mon, 28 Dec 2009 16:22:44 -0800 From: =JeffH User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: apps-discuss@ietf.org, public-web-security@w3.org Subject: Re: HTTP Mutual-auth proposal status / HTTP AUTH meet-up in Anaheim? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: ietf-http-auth@osafoundation.org, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 00:22:53 -0000 [ I am replying to all lists because the info wrt on-going HTTP authn work in the IETF OAuth WG may not as yet be widely known; otherwise, apologies for cross-posting ] Oiwa-san, Thanks for sending out this announcement regarding your on-going work. Having a meetup of one form or another to discuss HTTP authentication will be useful. In regards of the working-group context though, I note that the feedback given on your presentation at IETF-74 in SF was that it was likely that the appropriate place to discuss this work would be the to-be-formed OAuth WG... from: http://www.ietf.org/proceedings/74/minutes/httpbis.txt: > > Mutual Authentication was covered with some questions from the audience. It > was pointed out that it may be most appropriate to take this work to the > to-be-formed OAuth WG, since it now appears that they're designing a > "two-legged" (i.e., normal client/server) HTTP authentication mechanism as > well. Indeed, the OAuth WG has now formed and its charter has this note down towards the end.. > The Working Group will also define a generally applicable > HTTP authentication mechanism (i.e., browser-based "2-leg" > scenerio). So I respectfully suggest re-sending your message to and taking discussion there -- and for those interested folks to subscribe to . Hope this helps, =JeffH From y.oiwa@aist.go.jp Mon Dec 28 22:50:56 2009 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 91C683A67AA; Mon, 28 Dec 2009 22:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.542 X-Spam-Level: X-Spam-Status: No, score=0.542 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 T73ITA7Tsi+6; Mon, 28 Dec 2009 22:50:55 -0800 (PST) Received: from mx1s.aist.go.jp (mx1s.aist.go.jp [150.29.246.134]) by core3.amsl.com (Postfix) with ESMTP id E95FC3A6939; Mon, 28 Dec 2009 22:50:54 -0800 (PST) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1s.aist.go.jp with ESMTP id nBT6oUal005971; Tue, 29 Dec 2009 15:50:30 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1262069433; bh=jpTtCVrvzJBSn4Lx28ThHqIQYybvAqEE9ohAw9hgBKI=; h=From:Date:Message-ID; b=WewKi9GeesK9Ph/be4WDJkmUWRCPVBO2uSbA6kiYAHOAp4OQqfFwAVHa8t51bqc8r Baq6iEsdQQ7qpHzbpzrD9S4Ry1fLcfKR4IivnOvzU65msYFqv4UniZF1c4CGguAemw K0zwWlZPJdEdj91ikK0LLkiRwqGB0qM4jTrzrj04= Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id nBT6oUNX028544; Tue, 29 Dec 2009 15:50:30 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp4.aist.go.jp with ESMTP id nBT6oSKI001072; Tue, 29 Dec 2009 15:50:28 +0900 (JST) env-from (y.oiwa@aist.go.jp) From: Yutaka OIWA To: =JeffH Subject: Re: HTTP Mutual-auth proposal status / HTTP AUTH meet-up in Anaheim? References: <4B394BD4.3020104@KingsMountain.com> Date: Tue, 29 Dec 2009 15:50:28 +0900 Message-ID: <874onal1e3.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ietf-http-auth@osafoundation.org, public-web-security@w3.org, oauth@ietf.org, apps-discuss@ietf.org, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 06:50:56 -0000 Dear Jeff, [ Sorry again for one more cross-posting response for an important comment, And please edit the reply addresses whenever appropriate ] (for people in OAuth ML: this is a reply to http://lists.w3.org/Archives/Public/ietf-http-wg/2009OctDec/0356.html) =JeffH writes: >Thanks for sending out this announcement regarding your on-going work. Having a >meetup of one form or another to discuss HTTP authentication will be useful. > > In regards of the working-group context though, I note that the feedback given > on your presentation at IETF-74 in SF was that it was likely that the > appropriate place to discuss this work would be the to-be-formed OAuth WG... (cut) > Indeed, the OAuth WG has now formed > and its charter has > this note down towards the end.. > > > The Working Group will also define a generally applicable > > HTTP authentication mechanism (i.e., browser-based "2-leg" > > scenerio). > > > So I respectfully suggest re-sending your message to and > taking discussion there -- and for those interested folks to subscribe to > . Thank you very much for the important comment. Yes, we were once suggested at San Francisco that we will be better redirected to OAuth WG, and I also attended for OAuth WG there. However, after that I felt getting lost between two WGs, because most of discussions in OAuth ML and WG meeting are focused on the OAuth related protocol only. Moreover, most of discussions on HTTP authentications (except OAuth) were still going on in httpbis ML. I wanted to talk people at IETF meetings for this, because I was not sure whether the redirection was accepted by the OAuth WG. But as there were no OAuth/httpbis WGs at Stockholm, we couldn't plan going there. Then I talked personally at Apparea meeting at Hiroshima in Japan (where we can go there easily and inexpensively :-)) and there I have been suggested to first introduce our proposal to apps-discuss ML. Coincidently, there comes a new mailing list well-suited for discussing a general HTTP security matters at a very good opportunity. These are the reasons why I sent the previous mail to these two MLs. I also included http and http-auth MLs to the Cc list, because I had sent our proposal previously to these, and because I thought that there might be people interested in generic HTTP authentication issues. I am still feeling unclear whether there is a consensus in the people's mind whether the scope of OAuth WG really includes "generic" HTTP authentication issues "unrelated to OAuth", because all contents in the WG charter (except one sentence Jeff has mentioned) seems to me only considering OAuth-related things. These are mostly unchanged from an older charter draft which had stated "generic HTTP auth is out of scope". In other words, I did read that sentence in the charter as "to define OAuth-based 2-leg auth scheme generally applicable to HTTP", considering other parts of the charter and other resources. That's why I have hesitated to break in on OAuth WG with our proposal without prior consent, and I will be happy if there will be a clear statement on that. Anyway, I will now forward my previous mail to the IETF OAuth ML, which should have been included in the CC list. I'll keep reading any MLs I have mentioned, including OAuth. # Please forgive me of late mail replies, as I am almost being drowned # to surging waves of English mails (especially in httpbis MLs)... I will of course attend all HTTP-related WGs at Anaheim, and I'm looking forward to talking to people there. Thanks again, -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From mnot@mnot.net Tue Dec 29 15:26:39 2009 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 069B13A6927 for ; Tue, 29 Dec 2009 15:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[AWL=-1.301, 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 VuyDwNBFNdQl for ; Tue, 29 Dec 2009 15:26:38 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 109213A67C0 for ; Tue, 29 Dec 2009 15:26:37 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.149.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E27AD22E253; Tue, 29 Dec 2009 18:26:10 -0500 (EST) Subject: Re: draft-nottingham-http-link-relation-07 progress Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343787C35074@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 30 Dec 2009 10:26:06 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <4B1BF8FA.2080201@gmx.de> <78E6189B-66D1-4E38-9F89-31E33ACECD55@mnot.net> <90C41DD21FB7C64BB94121FBBC2E72343787C35074@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1077) Cc: 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: Tue, 29 Dec 2009 23:26:39 -0000 On 14/12/2009, at 6:05 PM, Eran Hammer-Lahav wrote: > Maybe some recommendation in the spec about naming conventions? = Something along the lines of non-novel names should not be used for very = narrow cases. How about (after the other requirements on relation names): =20 They SHOULD be appropriate to the specificity of the relation; i.e., if = the semantics are highly specific to a particular application, the name = should reflect that, so that more general names are available for less = specific use. -- Mark Nottingham http://www.mnot.net/ From eran@hueniverse.com Tue Dec 29 22:43:51 2009 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 6D6DE3A659B for ; Tue, 29 Dec 2009 22:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.037 X-Spam-Level: X-Spam-Status: No, score=-3.037 tagged_above=-999 required=5 tests=[AWL=-0.438, 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 pzpGNJTOdk5T for ; Tue, 29 Dec 2009 22:43:50 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 67F1A3A6403 for ; Tue, 29 Dec 2009 22:43:50 -0800 (PST) Received: (qmail 405 invoked from network); 30 Dec 2009 06:43:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Dec 2009 06:43:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 29 Dec 2009 23:43:27 -0700 From: Eran Hammer-Lahav To: Mark Nottingham Date: Tue, 29 Dec 2009 23:43:35 -0700 Subject: RE: draft-nottingham-http-link-relation-07 progress Thread-Topic: draft-nottingham-http-link-relation-07 progress Thread-Index: AcqI3lON5YL4LbcERGuARJUOni7MKAAOrIKA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343787E67BFA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <4B1BF8FA.2080201@gmx.de> <78E6189B-66D1-4E38-9F89-31E33ACECD55@mnot.net> <90C41DD21FB7C64BB94121FBBC2E72343787C35074@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 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: Wed, 30 Dec 2009 06:43:51 -0000 I like this. This is where I think we are: -- Use a URI relation type when: * Don't want or cannot engage the community for the purpose of registering = a relation type * Using an internal or experimental relation type (similar to the original = purpose of the X- HTTP headers) * Defining a short-lived relation type (e.g. something for an event)=20 * Do not want to involve IANA / IETF in the process or politics of your sta= ndard * You like URIs better -- Use a "trademark-quality" registered short relation type for (i.e. a rel= ation type that is unique, not a trivial word, and unlikely to mean somethi= ng else): * A narrowly defined relation type * Protocol specific * Restricted in the media type of the linked resource * Restricted in link cardinality in the same place or multiple places (HTTP= Header, HTML element, etc.) * Use for other purposes will break something -- Use a generic term registered short relation type: * Generally applicable across context, protocols * Meaning is aligned with common expectations of technical people * Can have specialized processing rules of meaning in some cases without br= eaking something Are these examples right? I don't think we need to have them in the spec, b= ut it would be great if we can offer the DE's something to work with (as we= ll as the wider community to better understand how they should use this pro= cess). EHL > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Tuesday, December 29, 2009 3:26 PM > To: Eran Hammer-Lahav > Cc: Julian Reschke; Apps Discuss > Subject: Re: draft-nottingham-http-link-relation-07 progress >=20 >=20 > On 14/12/2009, at 6:05 PM, Eran Hammer-Lahav wrote: >=20 > > Maybe some recommendation in the spec about naming conventions? > Something along the lines of non-novel names should not be used for very > narrow cases. >=20 >=20 > How about (after the other requirements on relation names): >=20 > They SHOULD be appropriate to the specificity of the relation; i.e., if t= he > semantics are highly specific to a particular application, the name shoul= d > reflect that, so that more general names are available for less specific = use. >=20 >=20 > -- > Mark Nottingham http://www.mnot.net/ From lisa.dusseault@gmail.com Thu Dec 31 08:55:53 2009 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 B54AB3A6A37 for ; Thu, 31 Dec 2009 08:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 75rj0R6-ONF7 for ; Thu, 31 Dec 2009 08:55:52 -0800 (PST) Received: from mail-vw0-f193.google.com (mail-vw0-f193.google.com [209.85.212.193]) by core3.amsl.com (Postfix) with ESMTP id B9C703A6887 for ; Thu, 31 Dec 2009 08:55:52 -0800 (PST) Received: by vws31 with SMTP id 31so4295671vws.29 for ; Thu, 31 Dec 2009 08:55:29 -0800 (PST) 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:message-id:subject:from:to:content-type :content-transfer-encoding; bh=mMsSbKs7w/ovQp199W7J4z12avpLt7AuTPYGNjtB8KU=; b=EtOyl0R9jxpTPUDBT6pL/2CKGTOPH8omv4vNBsp/fw4T1hkScMh7OftP6kDdiXNNbL ztOxmBjggsqZoed8Bd/hBKdGrix34Ce0VdN2O/dDOeo1YrrtMpW+JJD2vKZWvi/lxel1 +6Uxyon0snayUZyWWt+oCEUuwCsk2Hlg37VWc= 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 :content-type:content-transfer-encoding; b=NIfv6y5qMhdzuES8oqwzATriG4KaFa1XcZbgUVG7LUU66L0SgcIVI8M0VYQYG40LsW ga2/NAzF02RhdeGvkFggIVyIR3ZMz6r09WYSC7TLudp54cGvvtwZpkNoIYQUFgbF9ahZ XK06uZFpf0zcgZ+2URStS+PTqYqY96WK28BGc= MIME-Version: 1.0 Received: by 10.220.65.200 with SMTP id k8mr1496567vci.56.1262278529733; Thu, 31 Dec 2009 08:55:29 -0800 (PST) In-Reply-To: <20091229224501.E41803A6848@core3.amsl.com> References: <20091229224501.E41803A6848@core3.amsl.com> Date: Thu, 31 Dec 2009 08:55:29 -0800 Message-ID: Subject: Fwd: I-D Action:draft-nottingham-site-meta-05.txt From: Lisa Dusseault To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 31 Dec 2009 16:55:53 -0000 FYI, This document is currently in IESG Evaluation with a few DISCUSS issues to be cleared. One of the ADs asked whether this draft had been widely reviewed and I wasn't sure it had been posted here though it has definitely been discussed on HTTPBIS and in W3C lists. This draft proposes a namespace for a mechanism that can be useful for HTTP-based applications, e.g. if it were available and accepted 5-10 years ago, it would have been an alternative for some of the bootstrapping problems of WebDAV and CalDAV. See also http://tools.ietf.org/html/draft-hammer-hostmeta-05 for an example of use of this namespace. Lisa ---------- Forwarded message ---------- From: Date: Tue, Dec 29, 2009 at 2:45 PM Subject: I-D Action:draft-nottingham-site-meta-05.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Defining Well-Known URIs =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Nottingham, E. Hammer-Lahav =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-nottingham-site-meta-05.txt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 8 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-12-29 This memo defines a path prefix for "well-known locations", "/.well- known/" in selected URI schemes. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. =A0Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. =A0It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 3, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. =A0All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. =A0Please review these documents carefully, as they describe your rights and restrictions with respect to this document. =A0Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-05.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 masinter@adobe.com Thu Dec 31 11:18:11 2009 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 604D63A68F2 for ; Thu, 31 Dec 2009 11:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 JAY80+9qIdYc for ; Thu, 31 Dec 2009 11:18:09 -0800 (PST) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by core3.amsl.com (Postfix) with SMTP id B47F93A68D0 for ; Thu, 31 Dec 2009 11:18:08 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKSzz42u18jdKjYN6HaqMdkR9aDDxwpdJ2@postini.com; Thu, 31 Dec 2009 11:17:49 PST Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id nBVJA918002483; Thu, 31 Dec 2009 11:10:09 -0800 (PST) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id nBVJHk07008942; Thu, 31 Dec 2009 11:17:46 -0800 (PST) Received: from nacas03.corp.adobe.com (10.8.189.121) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 31 Dec 2009 11:17:46 -0800 Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Thu, 31 Dec 2009 11:17:45 -0800 From: Larry Masinter To: Lisa Dusseault , Apps Discuss Date: Thu, 31 Dec 2009 11:17:42 -0800 Subject: RE: I-D Action:draft-nottingham-site-meta-05.txt Thread-Topic: I-D Action:draft-nottingham-site-meta-05.txt Thread-Index: AcqKOhRPicuasJ7QQlWwxKHcX49x4QAEpIXg Message-ID: References: <20091229224501.E41803A6848@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 31 Dec 2009 19:18:11 -0000 There's a lot of confusion about the use of the term "metadata". In this case, the term is being used for something that might more appropriately be seen as "default metadata for resources at a site" rather than "site metadata". I know it's not really the job of this document to clear up all of the confusion around metadata, but I think it would be better if this document were to include at least a sentence or two explaining how its use of "metadata" is not a close match, for example, to the=20 the primary definition in: http://en.wikipedia.org/wiki/Metadata or even=20 http://www.w3.org/DesignIssues/Metadata.html or=20 http://www.w3.org/2001/tag/group/track/issues/63 Larry -- http://larry.masinter.net -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Lisa Dusseault Sent: Thursday, December 31, 2009 8:55 AM To: Apps Discuss Subject: Fwd: I-D Action:draft-nottingham-site-meta-05.txt FYI, This document is currently in IESG Evaluation with a few DISCUSS issues to be cleared. One of the ADs asked whether this draft had been widely reviewed and I wasn't sure it had been posted here though it has definitely been discussed on HTTPBIS and in W3C lists. This draft proposes a namespace for a mechanism that can be useful for HTTP-based applications, e.g. if it were available and accepted 5-10 years ago, it would have been an alternative for some of the bootstrapping problems of WebDAV and CalDAV. See also http://tools.ietf.org/html/draft-hammer-hostmeta-05 for an example of use of this namespace. Lisa ---------- Forwarded message ---------- From: Date: Tue, Dec 29, 2009 at 2:45 PM Subject: I-D Action:draft-nottingham-site-meta-05.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Defining Well-Known URIs =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Nottingham, E. Hammer-Lahav =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-nottingham-site-meta-05.txt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 8 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-12-29 This memo defines a path prefix for "well-known locations", "/.well- known/" in selected URI schemes. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. =A0Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. =A0It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 3, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. =A0All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. =A0Please review these documents carefully, as they describe your rights and restrictions with respect to this document. =A0Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-05.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 _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From eran@hueniverse.com Thu Dec 31 13:15:24 2009 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 C97A83A68FB for ; Thu, 31 Dec 2009 13:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.034 X-Spam-Level: X-Spam-Status: No, score=-3.034 tagged_above=-999 required=5 tests=[AWL=-0.435, 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 qsQmx+USMFWb for ; Thu, 31 Dec 2009 13:15:23 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 507983A6900 for ; Thu, 31 Dec 2009 13:15:23 -0800 (PST) Received: (qmail 22474 invoked from network); 31 Dec 2009 21:15:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 31 Dec 2009 21:15:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 31 Dec 2009 14:15:00 -0700 From: Eran Hammer-Lahav To: Apps Discuss Date: Thu, 31 Dec 2009 14:15:14 -0700 Subject: RE: I-D Action:draft-nottingham-site-meta-05.txt Thread-Topic: I-D Action:draft-nottingham-site-meta-05.txt Thread-Index: AcqKOhRPicuasJ7QQlWwxKHcX49x4QAEpIXgAARqcMA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343787E67EDF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20091229224501.E41803A6848@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 31 Dec 2009 21:15:25 -0000 Thanks Larry. Metadata is a word or phrase, not a technical term. In the context of this = draft, it generally means "information about". One use case for these well-known locations may very well be "default metad= ata for resources at a site", which is close (but not exactly) what host-me= ta [1] is proposing. If someone defines a well-known location for "site met= adata", that would be an acceptable use case as well, assuming it is better= defined than just that. Both are valid and it would be wrong for the draft= to allow one but not the other. I don't see the need for the document to say anything more than it currentl= y does. It would be a waste of everyone's time if the process of reviewing = and approving registrations will involve a discussion of the metadata-ness = of the proposed document. EHL [1] http://tools.ietf.org/html/draft-hammer-hostmeta > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Larry Masinter > Sent: Thursday, December 31, 2009 11:18 AM > To: Lisa Dusseault; Apps Discuss > Subject: RE: I-D Action:draft-nottingham-site-meta-05.txt >=20 > There's a lot of confusion about the use of the term "metadata". In this = case, > the term is being used for something that might more appropriately be see= n > as "default metadata for resources at a site" rather than "site metadata"= . I > know it's not really the job of this document to clear up all of the conf= usion > around metadata, but I think it would be better if this document were to > include at least a sentence or two explaining how its use of "metadata" > is not a close match, for example, to the the primary definition in: > http://en.wikipedia.org/wiki/Metadata >=20 > or even > http://www.w3.org/DesignIssues/Metadata.html > or > http://www.w3.org/2001/tag/group/track/issues/63 >=20 > Larry > -- > http://larry.masinter.net >=20 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Lisa Dusseault > Sent: Thursday, December 31, 2009 8:55 AM > To: Apps Discuss > Subject: Fwd: I-D Action:draft-nottingham-site-meta-05.txt >=20 > FYI, >=20 > This document is currently in IESG Evaluation with a few DISCUSS issues t= o be > cleared. One of the ADs asked whether this draft had been widely reviewe= d > and I wasn't sure it had been posted here though it has definitely been > discussed on HTTPBIS and in W3C lists. This draft proposes a namespace f= or a > mechanism that can be useful for HTTP-based applications, e.g. if it were > available and accepted 5-10 years ago, it would have been an alternative = for > some of the bootstrapping problems of WebDAV and CalDAV. >=20 > See also http://tools.ietf.org/html/draft-hammer-hostmeta-05 for an > example of use of this namespace. >=20 > Lisa >=20 > ---------- Forwarded message ---------- > From: > Date: Tue, Dec 29, 2009 at 2:45 PM > Subject: I-D Action:draft-nottingham-site-meta-05.txt > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Defining Well-Known URIs > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Nottingham, E. Hammer-Lahav > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-nottingham-site-meta-05.tx= t > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 8 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-12-29 >=20 > This memo defines a path prefix for "well-known locations", "/.well- > known/" in selected URI schemes. >=20 > Status of this Memo >=20 > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering Task > Force (IETF), its areas, and its working groups. =A0Note that other group= s may > also distribute working documents as Internet- Drafts. >=20 > Internet-Drafts are draft documents valid for a maximum of six months and > may be updated, replaced, or obsoleted by other documents at any time. = =A0It > is inappropriate to use Internet-Drafts as reference material or to cite = them > other than as "work in progress." >=20 > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. >=20 > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. >=20 > This Internet-Draft will expire on July 3, 2010. >=20 > Copyright Notice >=20 > Copyright (c) 2009 IETF Trust and the persons identified as the document > authors. =A0All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal Provisions > Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of publicati= on of > this document. =A0Please review these documents carefully, as they descri= be > your rights and restrictions with respect to this document. =A0Code > Components extracted from this document must include Simplified BSD > License text as described in Section 4.e of the Trust Legal Provisions an= d are > provided without warranty as described in the BSD License. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-05.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Interne= t- > Draft. >=20 >=20 > _______________________________________________ > 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 > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss